Re: [gentoo-dev] Referencing bug reports in git
> > Someone end the bikeshed train please. Seconded.
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote: > Hi! > > On Wed, 08 Jul 2015, Ciaran McCreesh wrote: > > On Wed, 8 Jul 2015 20:07:34 +0200 > > Tobias Klausmann wrote: > > > In essence, assuming we can "just scale" to make CI work is > > > ignoring the matter of the slower archs. And I suspect the "it > > > works on amd64, fuck everyone else" is not something we want to > > > pick as a motto. > > > > "It works on amd64 on a clean build system" is a heck of a lot better > > than "it may or may not work on one developer's heavily modified > > box"... The point of testing is not to catch all problems. It's just > > there to catch some simple screwups, cheaply. > > Agreed. Still, in my experience, problems that are not seen on > amd64 are the vast majority of timesinks. Usually, by the time > non-amd64 shows up on a non-security bug, the Basic Bullshit™ has > been sorted. And even if it isn't: Arches are usually quick to > point it out and the rest of arches move on to the next bug. The > truly arch-dependent bugs are what wastes my time: > > For example: > > - dependencies not being keyworded for arch or ~arch but only > amd64/~amd64 > - dependencies not even building on ~arch, but on ~amd64 > - package assuming availability of gcc/ghc/Python-X.Y when > arch/~arch only has something for - my favourite: assuming udev is at version X for arch/~arch when > it has been broken there for roughly twelve kernel versions due > to udev/systemd upstream not caring. The information is one > equery-y command line away, but no, let's file that bug. > That's a failing of the arch team or the committer then - or whomever keyworded the package without testing the dependencies. That's why the keywording bugs happen when dependencies change - and yes, occasionally a dependency loses it's keywords and that may be where the issue comes from, I'm not sure. This used to be watched very closely, but I believe the tool being used broke at some point. What exactly do you mean, it's just one command line away but let's file the bug - yes a bug SHOULD be filed, so that the people know of the issue so it doesn't get repeated, over and over. > Having every arch team chase the deps for every package is very, > very frustrating, since it is so trivial a problem. We need a > tool that answers the question: "I want to mov cat/pkg-1.2.3 to > stable for arches a, b and c, what do I need?" for _every > package_. Some groups seem to have tooling for this, but it is > far from easily (obviously?) available, so every team gets to > re-discover dependency hell. Ruby is especially bad since > FEATURES=test make the depgraph explode (and sometimes circular). > > Regards, > Tobias > > The only fear I have about CI, is that we turn into every other distro out there where "it builds, ship it!" - I know I prefer to have our arm team actually test the packages more than just doing FEATURES=test (assuming the tests aren't broken on arm) emerge, although I know there are some people on the team who feel that it's too much to actually test all of the arm boards. For a long time, certain binary distros were compiling anything and everything, and if it built for other arches it was available. Even if there was no way it would possibly work on that arch. Regards, Steev
Re: [gentoo-dev] arm64
On Mon, 2015-01-26 at 14:10 +0800, Yixun Lan wrote:
> On 20:57 Sat 24 Jan , Tom Gall wrote:
> > Hi All,
> >
> > This is sort of a CFP in some ways but not quite that formal. I’ve been
> > throttled back on arm64 for a bit as the hardware I’ve had access to has
> > all been painfully remote and configured in ways that was less than optimal
> > for massive key wording efforts.
> >
> > That’s about to change.
> >
> > So if there are others out there who have the same interest be great to
> > coordinate efforts and get this moving along so we have arm64 stages and
> > start to pull together install instructions for the varies pieces of
> > hardware starting to show up.
> >
> Hi
> I've already keyworded a few ebuilds.. but unfortunately the hardware
> I'm using now can't be available for end user
>
> the arm64 profile is still experimental.. massive USEs have been masked [1]
> tests/verification are required.
>
> [1] ${PORTDIR}/profiles/arch/arm64/use.mask
>
So, I have a mustang board, I just have had 0 time to work on getting it
set up. And I'm currently in the midst of working on a new release, so
I don't know how long it's going to be til I have it setup for people to
use. The eventual goal is to get it set up with Gentoo, and have it
hosted by prometheanfire and giving access to anyone (Gentoo dev-wise)
who wants/needs it, with an emphasis on the ARM team.
Re: [gentoo-dev] Maintainer request: sys-apps/kmscon
On Wed, 2014-06-25 at 22:42 -0700, Matt Turner wrote: > alexxy added it more than a year ago to the tree as part of the x11 > herd, of which he isn't a maintainer. It hasn't been really seen any > attention and is broken with current versions of Mesa. I've pinged him > multiple times to see if he's planning to handle any of the > outstanding bugs. > > Someone please take over maintenance and fix up this package? > I'll try to make some room this weekend and see if I can't give it a go here.
Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference
On Mon, 2014-06-16 at 13:37 +, hasufell wrote:
> Chí-Thanh Christopher Nguyễn:
> > hasufell schrieb:
> >> No improvements so far. I am going to hardmask sys-devel/crossdev,
> >> unless someone can explain why we are still in broken stage.
> >>
> >> More packages are popping up that randomly break. Recent failures were
> >> related to tc-getBUILD_CC.
> >>
> >> This isn't stable in any way. I'm not blaming anyone, but that's what
> >> hardmasking is for. A working solution was declined, so...
> >
> > If I understand correctly, it is not the crossdev package being present on
> > the system, but the generated toolchains that cause the trouble.
> >
> > I think there are less intrusive options than hardmask, such as
> > pkg_pretend()
> > check or blocking offending packages from cross-${CTARGET} category.
> >
> >
> > Best regards,
> > Chí-Thanh Christopher Nguyễn
> >
> >
>
> There was a proposed solution which works perfectly fine: don't clutter
> PATH with crossdev links.
>
> If any embedded developer needs these tools in PATH he can add them
> temporarily (I'm pretty sure he knows how; an elog can be added as
> well), via wrapper scripts or whatnot. That's a reasonable trade-off.
>
> However, toolchain does not agree and I don't randomly touch other
> peoples packages (unless there is no response).
>
> So there are only two things left:
> * block crossdev within multilib eclasses (that sounds really wrong to me)
> * hardmask it, so we are able to communicate this problem to the user
>
I'm someone who uses crossdev (and the cross compilers) quite heavily -
can you point me to a bug that you're talking about? I'm not in the
toolchain, and while I agree that temporarily adding the cross
compiler(s) to the PATH is easy, for some of us, it's easier to allow
Gentoo to do so.
I'm not a huge fan of multilib, but at the same time, I'd like to not
see crossdev being hardmasked, just to prove your point. I don't have
near as much free time as I'd like, but I may try to squeeze some time
in to help out.
Re: [gentoo-dev] RFC: news item for upower
On Tue, 2014-06-03 at 18:43 +0300, Samuli Suominen wrote: > I find this useless at this time because the work is in-progress, but in > order to silence the loud minority, > please review the news item. > > Thanks! > > - Samuli > > I appreciate your work on this - and you may call them the loud minority - but this could definitely have been handled better. Instead of viewing their complaints as an annoyance, view it as a learning point to possibly realize that you're affecting a lot of desktops and people's updates are suddenly stopping. I realize that this was mentioned in the GWN, but not everyone subscribes to every possible news outlet for Gentoo even if they use Gentoo, and the only one that is "guaranteed" to get to them is a portage checkout, which is why news items are good, especially when something like this occurs. Instead of belittling the users because they are wasting so much of your time, try to empathize with them a bit and realize that they are running into an actual issue that could have been avoided easily with this news item. That said, the news item looks good to me, and yeah it may be a bit late now since this already happened.
Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium
On Tue, 2014-05-27 at 10:09 -0400, Ian Stakenvicius wrote: > I don't know how much chromium is built and tested on lesser-used > arches (ie: arm, hppa, ia64, etc), but if there are dev's that try and > maintain these keywords that aren't in the team, it might be a good > idea to leave src_test in place, for them. Well, Chromium is the only browser I use on my Chromebook - it takes about 5 hours to compile natively, but I don't run the tests on it. If it doesn't work... well, it doesn't work...
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
On Fri, 2014-02-28 at 19:18 +0200, Samuli Suominen wrote:
> On 28/02/14 19:01, Lars Wendler wrote:
> > On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:
> >
> >> On 28/02/14 16:41, Lars Wendler wrote:
> >>> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
> >>>
> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, if user hasn't
> set otherwise.
> So it could be configured like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
> This would be very helpful in preventing people from shooting
> themself in the foot
>
> The only problem is that I propably don't have enough python skills
> to make that happen w/
> sys-apps/portage. But does the suggestion make sense? Should I open
> a feature request bug?
>
> >>> No need for if the ebuild(s) would use sane installation paths.
> >>>
> >>> Please finally stop imposing your insane ideas upon us, thanks.
> >>>
> >> You should stop attacking people. Period.
> > Once you stop trying to make things worse in Gentoo I will consider
> > stopping my attacks... so it's up to you.
> >
>
> Is there anything you'd like to add before I open the comrel bug about
> baseless accusation of making things intentionally worse?
>
> - Samuli
>
I would like to add something - you had absolutely no problem attacking
him for putting in the work of splitting udev out to like it used to be,
but the second he says something even remotely "inciteful" (as an
innocent bystander, I didn't even understand why you felt attacked) - so
while you're opening one on him, please open one on yourself.
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
On Fri, 2014-02-28 at 19:32 -0600, William Hubbs wrote: > On Fri, Feb 28, 2014 at 07:09:08PM -0600, Steev Klimaszewski wrote: > > I'm not exactly a fan of systemd, though I know it has some uses, and > > I'm still curious as to why it installs/stores *configuration* data > > in /lib - if only from an upgrade point of view, we back up /etc, we > > back up /home - now we need to back up /lib, /usr/lib, /var, or whatever > > some random upstream decides is a good place to store configuration > > information!? > > Consider it default configuration information. Basically what they are > doing is, say you have a default udev rules file in > /lib/udev/rules.d/10-foobar.rules, which is provided by some package. > > Now you want to override that default. > > You override in /etc/udev/rules.d/10-foobar.rules instead of editing the > provided file. > > William Default configuration information makes somewhat more sense - it makes a bit more sense to store it where it has historically been, which was /usr/share, I think anyway, rather than having to dig around the system in arbitrary directories to find out what the default configurations are in the first place, but who am I to judge? :) The way that it's been presented throughout this thread made it seem like the network configurations when using e.g. networkd were being stored in there. As someone who uses the bare minimum of systemd (only to test Gnome 3.10 on ARM), it made no sense to me why it kept being brought up that systemd kept network configuration there, I wasn't familiar and that's why my initial response a while back asked if we were really storing configuration information there. So thank you for clarifying.
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
On Fri, 2014-02-28 at 10:31 -0500, Rich Freeman wrote: > > I think using INSTALL_MASK to kill a few inodes that probably don't > even have extents using a sledgehammer to kill a fly, and if you put > some holes in your walls in the process I_TOLD_YOU_SO. However, I > won't tell people they can't do it if they want to. It has a lot of > uses I'd consider more productive in setting up embedded systems and > such, and in those cases having a war of escalation with overrides on > top of overrides is just a PITA. > Please keep in mind that not every device that runs Gentoo has the ability to just pop new storage in with more space. The Beaglebone Black has 2GB eMMC. Some of the EfikaMX smarttops have 4GB PATA ssd. It's a PITA to deal with upstreams that have some interesting ideas, as well as maintainers that insist that the upstreams ideas are sound. Part of our "jobs" as Gentoo maintainers is to actually maintain software as it pertains to Gentoo, not to blindly copy what upstream does and call it a day. If something makes no sense, we should not point and scream UPSTREAM DOES IT, DISTROX DOES IT - if they do it, and all we are doing is blindly copying them, why not just run DISTROX!? I'm not exactly a fan of systemd, though I know it has some uses, and I'm still curious as to why it installs/stores *configuration* data in /lib - if only from an upgrade point of view, we back up /etc, we back up /home - now we need to back up /lib, /usr/lib, /var, or whatever some random upstream decides is a good place to store configuration information!? I get it, we all are busy, we have better things to do than patch things from upstream, but sometimes, it's a requirement. We wouldn't install a script that does rm -rf / with root permissions (assuming a non-hardened box where it would cause quite a bit of damage) - but we're okay with just randomly storing configuration data all over the system? Please consider these things before saying we're going to blindly follow upstream - if something is too hard for you to maintain, ask for some assistance in doing so. And please keep in mind that while we are all doing these things to scratch our own itches, there are other people's systems involved too that don't have the same luxuries we have. -- Steev
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On Tue, 2014-02-25 at 10:43 +0200, Samuli Suominen wrote: > Here is a bit better worded news item for the upgrade. I think I've > taken into account any concerns, but please check > the grammar part. Thanks! > > - Samuli CONFIG_DMIID isn't available for ARM. Can we make that warning go away if on ARM, so users don't pull their hair out? The first sentence in the second paragraph doesn't have a period at the end, and using "since" twice sounds odd to me when I read it out loud, but I don't think it's that big of an issue. Not related to the news file, since you aren't upstream, but wtf? They store *configuration* there as well? Or is that just a mis-wording? I'd also say, "using too wide of an INSTALL_MASK would be a mistake." instead of "using a too wide INSTALL_MASK would be a mistake."
Re: [gentoo-dev] News item draft for >=sys-fs/udev-209 upgrade
On Mon, 2014-02-24 at 07:32 +0200, Samuli Suominen wrote: > If it's okay, I'd want to post this fast, before adding KEYWORDS to > sys-fs/udev-209's ebuild > > SHOULD or NEEDS TO BE ? Honestly, this didn't read like much of a news announcement at all, and reads more like something I'd write when I want to tell myself something. The first paragraph of it should probably be rewritten.
Re: [gentoo-dev] RFD: new global USE flag gtk3
On Thu, 2014-02-20 at 03:59 -0500, Alexandre Rostovtsev wrote: > And this is an example of why everyone on the gnome team doesn't like > the "gtk3" flag. Because well-meaning developers will be looking at > their one corner of the portage tree, deciding that they are going to > handle the choice of gtk version without slotting, and not consider the > effect on the distro as a whole. > > You know what's going to happen now, after the QA team decision? > > First of all, lots of developers will start renaming "gtk" to "gtk3" in > their ebuilds' IUSE. > > Which means "gtk gtk3" will soon have to be added to USE in > targets/desktop/gnome/make.defaults (currently, the gnome profile > globally only has USE="gtk" because the "gtk3" flag is evil). > > And users of non-gnome profiles who use gnome applications will of > course manually add "gtk gtk3" to USE in their local make.conf. > > Unfortunately, at the same time, lots of other developers are going to > start adding support for building against gtk2 XOR gtk3. Because of > course "Gentoo is about choice", and the more choices, the merrier, and > the gtk3 flag has been declared as supported by the QA team. And that > means lots of REQUIRED_USE="^^ ( gtk gtk3 )". > > For the gnome team this results in a headache: maintaining a big list of > "-gtk" / "-gtk3" entries in targets/desktop/gnome/package.use so that > gnome users get a sensible choice and don't need to edit /etc/portage/* > just to emerge widely used desktop tools. > > But for non-gnome users who manually added USE=gtk3 to make.conf, this > means regular emerge conflicts after sync, forcing them to *guess* > whether "-gtk" or "-gtk3" in pacakge.use is the better choice. Maybe > with portage auto-suggesting the wrong solution just to add to the > wonderful user experience :/ > See, now this is an example of a good email as to why supporting both can be a hassle for more than just one desktop. Instead of telling me that I'm dumb for thinking it's a good idea to follow upstream's supported ideas, and that we should force one or the other. The KDE team seems to be able to deal with it just fine, but somehow it's impossible and hard for the GNOME team. Why is that? What does KDE do differently that makes it feasible?
Re: [gentoo-dev] RFD: new global USE flag gtk3
On Thu, 2014-02-20 at 09:11 +0100, Michał Górny wrote: > Dnia 2014-02-20, o godz. 01:44:17 > Steev Klimaszewski napisał(a): > > > On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote: > > > On 20/02/14 00:23, Ulrich Mueller wrote: > > > > Following up to today's QA meeting: The gtk3 USE flag is used by > > > > 27 packages, so I suggest making it a global flag: > > > > > > > > gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3 > > > > > > > > Ulrich > > > > > > that would suggest it's fine to use, and is anything but temporary > > > > > > -1 from here > > > > > MATE desktop (which I hope to bring in to Portage soon) can be built > > against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from > > me. > > Except that now users have to use USE='gtk gtk3' to get GUIs in random > applications that support only one toolkit. And then handle > REQUIRED_USE mess for packages that support choosing one of the two. > Sorry? Still better than forcing things on because it allows me to be lazy. > > Just because gtk+ 3 is the latest, does not mean it's the greatest, > > and I really wish people would realize that newest != bestest. > > Yet it's supported, unlike GTK+2. I really wish people would actually > step up to fix bugs when the time comes rather than shouting about their > right to choose. > Who is shouting about right to choose? In fact, I see only MATE in capital letters there, and that's because that's the way that it's written by upstream. Just because you enjoy forcing people to do things your way, doesn't mean everyone feels the need to be controlling. I'm cool with giving the users choice, it doesn't HAVE to be done, but I'm not so against it that I insist they follow my one true way...
Re: [gentoo-dev] RFD: new global USE flag gtk3
On Thu, 2014-02-20 at 10:40 +0200, Samuli Suominen wrote: > On 20/02/14 09:44, Steev Klimaszewski wrote: > > On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote: > >> On 20/02/14 00:23, Ulrich Mueller wrote: > >>> Following up to today's QA meeting: The gtk3 USE flag is used by > >>> 27 packages, so I suggest making it a global flag: > >>> > >>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3 > >>> > >>> Ulrich > >> that would suggest it's fine to use, and is anything but temporary > >> > >> -1 from here > >> > > MATE desktop (which I hope to bring in to Portage soon) can be built > > against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from > > me. Just because gtk+ 3 is the latest, does not mean it's the greatest, > > and I really wish people would realize that newest != bestest. > > > > > > Then you pick whatever is best supported for MATE, and ship it using that. > Later when they have completed their support for GTK+-3, and it's the > best supported, you ship that. It's not rocket science. > OR, since I'm the maintainer, I decide that I'm willing to deal with both, instead of you telling me that I need to pick one or the other. Upstream says both are supported and viable, and I'm willing to deal with the headaches. Just because you're unwilling doesn't mean others aren't. kthx.
Re: [gentoo-dev] RFD: new global USE flag gtk3
On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote: > On 20/02/14 00:23, Ulrich Mueller wrote: > > Following up to today's QA meeting: The gtk3 USE flag is used by > > 27 packages, so I suggest making it a global flag: > > > > gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3 > > > > Ulrich > > that would suggest it's fine to use, and is anything but temporary > > -1 from here > MATE desktop (which I hope to bring in to Portage soon) can be built against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from me. Just because gtk+ 3 is the latest, does not mean it's the greatest, and I really wish people would realize that newest != bestest.
Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)
On Sun, 2014-02-16 at 09:03 -0500, Rich Freeman wrote: > On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos wrote: > > Also, keeping the bugs assigned to package maintainers will still allow > > them to try to get that pending bugs fixed (or resolved in some way) as > > they will take care more about that specific package status. If we get > > that bugs assigned to arch teams, they will likely be ignored by both > > parts, getting worse. > > Well, that depends on your perspective. If they fix them by deleting > the old version, then whether they've made things better or worse is a > matter of philosophy. > > That's basically the counter-argument to removing old versions. If > the newer version doesn't work at all, then the old buggy version is > superior. It is better to have the bugs ignored, than to pester the > maintainer until the package is disabled entirely. > > Honestly, this whole conversation seems rather theoretical. What I > haven't heard from is the minor arch leads. Actually, looking at the > base project page, it seems like half of them don't even have leads. > Minor arch co-lead checking in. I haven't chimed in as I'm still pretty agitated with the PREVIOUS thread about this exact same topic. And by agitated, I mean I'm tired of it. If you guys wanna break the tree for us minor arches, go for it. It's obvious from the thread that people care not about making Gentoo the best distro that it can be, and entirely care about how pretty the graphs are, and how short their bug lists are. I'm tired of "fighting" about this. My position was made known, some agreed, some disagreed, but reiterating it over and over does nothing, and no new information is brought in by it. If you want to re-read it, feel free to read through the previous thread. > The other issue is that at least some devs have been stabilizing new > packages on minor archs for which the council decided to drop stable > keywords. How to handle that is on the next agenda as well. > > Basically all of this boils down to whether it is a good compromise to > redefine "stable" to something different on minor archs so that they > can make some use of the keyword, and do it without driving > maintainers nuts. I don't have a big problem with that, as long as it > is done in a way that doesn't place any burden on anybody who doesn't > use the minor arch (including bug wranglers, maintainers, etc). > > Rich >
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 2014-02-05 at 13:58 +0100, Tom Wijsman wrote: > Can we do something about our growing queue when fixing is insufficient? > > https://bugs.gentoo.org/chart.cgi?category=-All-&datefrom=&dateto=&label0=All%20Open&line0=320&name=320&subcategory=-All-&action=wrap > > PS: As a bonus, here's a nice view of our stabilization queue over time: > > https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linux&subcategory=Keywording+and+Stabilization&name=639&label0=All+Open&line0=639&datefrom=&dateto=&action-wrap=Chart+This+List > > Notice how the graph goes down near the dates the threads were made; > although, if you would draw an average it would appear to be growing. > There is far more to stabilizing than just closing the bugs. I've been working for over 2 months now on the GNOME stabilization on ARM. There has been a lot involved, including (but not limited to) rebuilding kernels for proper systemd integration, setting up systemd so that software would build (empathy won't build if systemd has no locale set (lol!) so much for systemd properly importing my settings from openrc) - building the software itself. Realizing that some things were built against the GPU opengl implementation instead of mesa's implementation, having to rebuild that software, and all it's dependencies. Then the process of actually attempting to get it to run, tracking down the junk in the logs - figuring out which messages can be ignored, which ones are actual errors (why exactly is it throwing an error message if that message can be ignored?) This is on multiple machines, because I'd like to cover softfp and hardfp. This takes time. Even if I were to build everything on my octa-core ARM server and just use the binpkgs, it still takes quite a bit of time to get through everything. And this is JUST for the default useflags. So you know what? I'm sick of hearing about "slow arches" - there's a LOT of shit that we have to do to make sure things ACTUALLY WORK, and based on your emails, you either have NO IDEA what all is involved in alternate arch work, or you're purposely being obtuse about it. Now, we COULD do like Ubuntu, and just say if it builds, it's stable. But I personally am against that, maybe that's okay with you. We used Ubuntu on ARM devices at my last job - I'm intimately familiar with their practices. We do not want to replicate that here in Gentoo land, or at least, I don't, not on ARM. Feel free to look at all the GL based apps that they have available on armel - and test how many of them actually run on the hardware. I'll wait for you to finish going through them all... Save the charts for upper management, they are the only ones who care what the pretty graphs look like instead of knowing the full details.
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 2014-02-05 at 05:52 -0500, Rich Freeman wrote: > On Tue, Feb 4, 2014 at 10:15 PM, Steev Klimaszewski wrote: > > > > You know what - this is pure and utter bullshit. Keeping it around for > > "slower" arches does NOT block progress. I have intimate knowledge with > > what ACTUALLY happens when people pull this bullshit - and that is a > > system that I can no longer actually work on. > > It isn't like deleted ebuilds magically disappear. You can always dig > them out of CVS and stick them in an overlay. It just isn't the > maintainer's problem. Any dev can also co-maintain a package and keep > the old version around. > > Main issue I could see with that is stuff we don't stick in cvs/git, > like large patches and non-upstream distfiles. That really does need > a better solution as has come up before on-list, but I think this is > really a different problem. > This is true, and normally I would have no problems digging out an old ebuild, although in this specific case, the old git ebuild will not work, and any ebuild that relies on the new git eclass will not work either... I understood the reason for the change, and it was and is definitely an unfortunate turn of events, though I finally opened a bug about it so we can hopefully track down why git 1.8+ doesn't work on arm uclibc (it works fine on x86/amd64 uclibc). > > I'm now going to take a break from Gentoo development because this > > thread has seriously caused my blood to boil based on comments from the > > peanut gallery (you) where things don't actually affect your day to day > > work, but your actions do affect mine. > > Email threads really aren't the venue for decision-making. They're a > great place to suggest ideas, and you have to look at them that way. > I've barely skimmed half the messages in this thread, mainly to look > for actual solution suggestions, and sometimes the first reply to one > contains some useful criticism. > > It looks like QA has actually intervened with an intended solution. > If you don't like it anybody can ask the council to intervene (looks > like there is less than a week to the next meeting). > > Simply debating the issues back and forth on an email list really > isn't like to change things much, and as you and others have pointed > out it can be an extremely frustrating activity. > > Rich > There is more to it than that. Normally discussions can be good, but when you try to talk to a brick wall, it's absolutely pointless.
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
Against my better judgment... On Wed, 2014-02-05 at 05:55 +0100, Tom Wijsman wrote: > On Tue, 04 Feb 2014 21:15:47 -0600 > Steev Klimaszewski wrote: > > > On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote: > > > On Tue, 04 Feb 2014 19:35:22 -0600 > > > Steev Klimaszewski wrote: > > > > > > > Alright, well, I've tried my best, I give up. Instead of having > > > > something working we should just remove ebuilds of working > > > > packages. > > > > > > s/should/could/ s/ebuilds/stable keyword or last stable version/ > > > > > > It is at the maintainer's discretion; and such decision is to make > > > it possible for a maintainer to move on when he or she can no longer > > > guarantee a working ebuild, to stop being progress-blocked by it. > > > > > > > You know what - this is pure and utter bullshit. > > Why is this pure and utter bullshit? Because I'm attempting to have a discussion with a brick wall. > > > Keeping it around for "slower" arches does NOT block progress. > > Why is keeping it around for "slower" arches not blocking progress? > Let's see... having the software at least available, versus not having access to it at all... which one is progress... THINK TOM THINK. > > I have intimate knowledge with what ACTUALLY happens when people pull > > this bullshit - and that is a system that I can no longer actually > > work on. > > That is also what happens when a maintainer keeps around old versions, > as well as old bugs and support for those old versions; as by doing so, > the attention towards newer versions is lost which causes much huger > breakage than the one you have just brought up. Manpower is limited. > And we attempted to come up with a solution for this, however due to the wording of a page on the interwebs that solution is 100% unacceptable *to you*, a person who is unaffected by it. > > And instead of working towards a fix that actually works > > for people who are ACTUALLY affected by the shitty policy, you hide > > behind definitions and pedantry. > > Why do you think this about the current and/or suggested solution(s)? > > > I'm now going to take a break from Gentoo development because this > > thread has seriously caused my blood to boil based on comments from > > the peanut gallery (you) where things don't actually affect your day > > to day work, but your actions do affect mine. > > Why? How and why are your actions affected by the QA team's actions? > Not the QA team's actions. YOURS. YOUR actions and responses in this thread. And the fact that the QA team allows you to continue to be on it, despite your obvious lack of interest in ACTUALLY having quality assurance. My actions are affected by it because I have to continue to attempt to discuss the issue with others who actually give a shit, and you just swoop in and say no, that absolutely is unacceptable as a solution (even though it doesn't affect me!) because this page here says that it can't - we can change that definition if you'd like. Instead of the line saying: The -* keyword is special. It is used to indicate package versions which are not worth trying to test on unlisted archs. Would changing it to read The -* keyword is special. It is used to indicate package versions which are not for use on unlisted archs. Would that make it acceptable?
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote: > On Tue, 04 Feb 2014 19:35:22 -0600 > Steev Klimaszewski wrote: > > > Alright, well, I've tried my best, I give up. Instead of having > > something working we should just remove ebuilds of working packages. > > s/should/could/ s/ebuilds/stable keyword or last stable version/ > > It is at the maintainer's discretion; and such decision is to make > it possible for a maintainer to move on when he or she can no longer > guarantee a working ebuild, to stop being progress-blocked by it. > You know what - this is pure and utter bullshit. Keeping it around for "slower" arches does NOT block progress. I have intimate knowledge with what ACTUALLY happens when people pull this bullshit - and that is a system that I can no longer actually work on. And instead of working towards a fix that actually works for people who are ACTUALLY affected by the shitty policy, you hide behind definitions and pedantry. I'm now going to take a break from Gentoo development because this thread has seriously caused my blood to boil based on comments from the peanut gallery (you) where things don't actually affect your day to day work, but your actions do affect mine.
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 2014-02-05 at 02:07 +0100, Tom Wijsman wrote: > On Tue, 04 Feb 2014 18:23:28 -0600 > Steev Klimaszewski wrote: > > > On Wed, 2014-02-05 at 01:08 +0100, Tom Wijsman wrote: > > > > > "The -* keyword is special. It is used to indicate package versions > > > which are not worth trying to test on unlisted archs." [1] > > > > > > You can keep rehashing about "winning", but all it does is break > > > policy. > > > > > > [1]: http://devmanual.gentoo.org/keywording > > > > > > > We are saying it is not for use on any but the listed arch, so don't > > try to. No? Or are we going to hinge this all on the definition of > > "test" in that statement? > > It has already been tested; and thus, it would be a policy breach to use > -* over dropping a keyword. It is also worth trying, when man power > allows; or are we going to hinge on the definition of "worth" as well? > > Looks like we are playing word games; I'll pick one, "unlisted" archs. > > The appropriate way to say that "it is not for use" on a particular > arch is to mask the package, a less appropriate way which is still > valid but less appreciated is to remove the keyword; but using the > wording "not for use" as "not worth trying to test" is bending policy. > Alright, well, I've tried my best, I give up. Instead of having something working we should just remove ebuilds of working packages.
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 2014-02-05 at 01:08 +0100, Tom Wijsman wrote: > "The -* keyword is special. It is used to indicate package versions > which are not worth trying to test on unlisted archs." [1] > > You can keep rehashing about "winning", but all it does is break policy. > > [1]: http://devmanual.gentoo.org/keywording > I would say, this is exactly that. We are saying it is not for use on any but the listed arch, so don't try to. No? Or are we going to hinge this all on the definition of "test" in that statement?
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Wed, 2014-01-29 at 03:15 +, Duncan wrote: > Tom Wijsman posted on Tue, 28 Jan 2014 14:11:48 +0100 as excerpted: > > [Seven J. Long wrote...] > > >> There's plenty of ways to stay on the bleeding-edge; throwing out the > >> baby with the bathwater will only tip you over it, and bork the distro > >> for the rest of us, and everyone down the line. > > > > Why do we have the baby in the first place? > > IOW, it's not throwing the "baby" out with the bathwater any longer, as > the "baby" long ago died of old age and is now a decaying corpse; there's > no "baby" to throw out any longer! > > Going with the analogy, that package has become an adult, grown old, got > sick, died, and now there are rather obvious and smelly signs of decay! > The neighbors complained (filed bugs) about the smell and when the > authorities investigated they found the decaying body (the bugs are > blocked pending removal of a long dead and should be gone version)! > > Yet some slow arch is insisting the corpse is not only alive and well, > but that it's still married to it, and the people coming to try and take > it away to the morgue aka VCS archives as part of the becoming-a-biohazard > cleanup (removing the package, thus unblocking those blocked bugs) are > somehow abusing their authority! > > Until the body becomes a biohazard (long dead package presence blocking > bug resolution), it's arguably the business of the deluded husband still > refusing to believe the death of his wife, but once it becomes a biohazard > the rest of the community is now threatened as well and something must be > done, thus this thread. > > [OK, the analogy triggered my imagination and I went with it...] > That got dark rather quickly... And the problem isn't that it's some dead thing around that no one wants, at least, no one except the team that it's the ONLY working version... so we go from having a decrepit but working version to... no alternative.
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Mon, 2014-01-27 at 09:52 -0500, Rich Freeman wrote: > On Mon, Jan 27, 2014 at 2:41 AM, Steev Klimaszewski wrote: > > It's not necessarily the STABLEREQs stopping, some of the issues are (at > > least on some arches!) that some of the unstable software doesn't quite > > work properly anymore, and we are failing at communicating. And in > > those cases, we on the arch teams should definitely be pointing this > > out, and filing bugs so that the issues can be sorted. > > Well, if the package or some version of it doesn't work at all, you > can always mask it on the arch or drop keywords. The arch team > doesn't need permission to do this stuff - the keywords and profiles > really "belong" to the arch team, and we just allow maintainers to do > their best job with them to make the job of the arch team easier. > Right, but, afaik, an "unstable" ebuild can go away at any point in time, and then we'd be back in this same place - newer ebuilds are around, older working ones are gone... > Obviously if you actually want the problem fixed that requires > bugs/etc. But you don't need a bug to drop a keyword and at least > make it clear that the package doesn't work. > Right, and this goes as a point towards splitting out the arm keywords, and maybe I'll bring it up at the next ARM team meeting... I don't think it would get much traction, but I suppose it wouldn't hurt to at least throw it out there and see what sticks. > Rich >
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Sun, 2014-01-26 at 16:35 -0500, Rich Freeman wrote: > On Sun, Jan 26, 2014 at 1:56 PM, Peter Stuge wrote: > > > > I don't think that's "completely optional" though, it sounds like a > > one-way function. If have ever stabilized a package once then must > > ensure a stable package forever. > > > > I think arbitrarily removing stable versions should also be an option, > > and I think package managers would be able to deal with that without > > much extra effort? > > Well, I think we certainly should be able to de-stabilize packages. > I've seen this happen in the past, especially when the need to not be > stable is inherent in the package itself (such as game clients that > need to be synchronized with servers - only one version will ever work > at any time buggy or not). > > Ideally this should really be the result of communication between the > maintainer and arch team. What we definitely don't want is a package > that gets stabilized, and then six months later the whole package is > back at ~arch, and then six months later there is a stable version > again, and so on. That just isn't, well, stable. > > However, if an arch team is feeling overwhelmed I'd strongly encourage > them to put out a bulletin telling maintainers to stop STABLEREQs for > non-system packages, or whatever other guidance they want to issue. > It has been pointed out that on these archs system packages often > don't work, so having those be stable at least lets them target > versions they want to fix up and lets users get a bootable system > without too much fuss. Falling back to a defensible position and all > that... > It's not necessarily the STABLEREQs stopping, some of the issues are (at least on some arches!) that some of the unstable software doesn't quite work properly anymore, and we are failing at communicating. And in those cases, we on the arch teams should definitely be pointing this out, and filing bugs so that the issues can be sorted. > But, nobody needs anybody's permission to do any of this. Ideally the > arch team should take the leadership to establish a policy on their > arch which is maintainable. If they don't do that, well, then > maintainers complain and we get threads like this one. The arch team > has the greatest interest in having the arch work - I'd strongly > support them in creating any policy for their arch that they can > follow-through on. > > Rich >
Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas
On Sun, 2014-01-26 at 21:00 +0100, Michał Górny wrote: > Hi again. > > If someone is interested in the results of my tests and benchmarks, > I've uploaded the initial version of my article on the topic in our > dev-space. > > http://dev.gentoo.org/~mgorny/tmp/squashfs-deltas.pdf > > I am terribly busy with the uni right now so it will take some time > before I continue working on it. I will try to provide a final > specification for the first attempt at the idea and ask infra if they > are ready to sacrifice the hardware for it. > > Further possible improvements: > > 1. switch to LZ4 (stronger compression, even faster) -- will require > a newer kernel (3.14?), > While the stronger compression, and being faster is definitely nice, having portage on squashfs is really nice on ARM devices, however the number of them that have a decently running kernel newer than 3.8 are few and far between, so I'd like to ask that this be held off as long as possible. I know these are just possible improvements, but doing so would definitely alienate a really good place where this would shine. > 2. dedicated SquashFS delta tool -- I'm working on it but > the format seems to be poorly documented so it will take some time :). >
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Fri, 2014-01-24 at 20:29 +0100, Tom Wijsman wrote: > On Fri, 24 Jan 2014 12:10:30 -0600 > Steev Klimaszewski wrote: > > > The problem isn't finding someone that has everything - we have people > > that test on ARMv5, some that test on ARMv6, we have some that test on > > ARMv7 - until ALL of them are tested, it doesn't get stabled on ARM. > > So again, it just shuffles around the work, and does nothing to > > address the actual problem which is manpower with people that have > > the slower machines to finish their testing. Unless you would like > > to suggest that we maybe just say fuck anyone using a slow machine? > > Consider how packages would rarely get stabilized if we had to wait for > all arches to test them first before adding any stable keyword at all. > Theoretical, again, as always, and not even worth considering because it doesn't reflect reality. > Organize first, then get more manpower; otherwise we say the F-word to > everyone with a faster machine. Joining arm with a slower configuration > and have everyone waiting on you is a working condition to avoid; so, > we could have the slower configuration stabilize at its own pace. > > Would we say F-word to 'em? No, we give them better working conditions. > We're all adults here, you can say fuck. And the entire point of the emails were that the slow arches were bringing us down, and we need to zomg stable fastar fastar fastar. For the record, the ARM team does just fine in stabling things in a reasonable amount of time, so no, we aren't going to change our working methods. The point of this email thread was we all need to stable faster, and slower arches need to just become unstable only, and fuck them. And I'm saying everyone needs to step back because stabling things faster and faster doesn't allow for proper testing. As QA, you should be focusing on making stable, actually stable, not more bleeding edge.
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Fri, 2014-01-24 at 18:26 +0100, Tom Wijsman wrote: > On Thu, 23 Jan 2014 21:52:47 -0600 > Steev Klimaszewski wrote: > > > The idea moves the work around, it doesn't lessen the workload at all. > > It is an idea to solve your actual problem, which isn't workload. > > You can easily find 7 people who have an armv7, and even v6, since the > > rpi is quite popular. > > They are easier to find than someone that has everything. > The problem isn't finding someone that has everything - we have people that test on ARMv5, some that test on ARMv6, we have some that test on ARMv7 - until ALL of them are tested, it doesn't get stabled on ARM. So again, it just shuffles around the work, and does nothing to address the actual problem which is manpower with people that have the slower machines to finish their testing. Unless you would like to suggest that we maybe just say fuck anyone using a slow machine? I disagree, and think we should take care of all of our users, not just the bleeding edge and fast users. > > Getting them into the arch team and willing to run stable and > > actually test programs is a whole other story, which lead to you > > saying: > > > > "People that have certain architectures can just add themselves, no > > extra work again." > > Which is for people already on the arm arch; consider the context you > quote this from, rather than assuming what is not explicitly stated. > That doesn't make any sense - if they are already on the arm arch team, they are already in the list. That wasn't the context of the quote AT ALL. And I told you when you said that it would allow people to add or remove themselves willy nilly, and that is NOT going to happen - and would NOT be good for QA. > > What you've thrown out as a possible solution is akin to taking a pile > > of peas on the plate and moving them around the plate so that the pile > > doesn't look so big. > > In other words, using separation to organize them properly. > > > It doesn't change the amount of work, but you do need to look in more > > places for the work. > > Which you can collect back into one place. > > > Finding people with the hardware is the main issue, and I think I > > mentioned before, some people are simply unwilling to invest in > > "slow" hardware, so we have to rely on the people who DO have it. > > And if that means things take longer to stable, well, why is that an > > issue? Stable is supposed to be that - stable. > > That is because you only look for people that have all the hardware. > No, we do not look ONLY for people that have all the hardware. But until it's tested on all of the arm arches, it doesn't get stabled. So your suggestion is "split it out to blah blah blah blah" - so that moves it around - but you know what? the slower machines are STILL going to take forever (because they are slow!) and the ebuilds will still need to stick around, because we will still be waiting. Problem NOT solved, problem just moved around a tiny bit. > > So, as QA, shouldn't you be doing something about that, rather than > > pointing to some URLs on the web, telling me I'm in the wrong for > > using the option that is supposed to handle that properly in my > > stable software? > > The problem lies in a different place than the software itself. > Spoken like a true QA person. Glad this is the type of person we have on our QA team. This is why everyone makes fun of our QA team, because we allow people in who don't actually give a shit about QA, only about covering up issues so they appear good but don't actually fix shit.
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Fri, 2014-01-24 at 04:04 +0100, Tom Wijsman wrote: > On Thu, 23 Jan 2014 18:04:19 -0600 > Steev Klimaszewski wrote: > > > Your "suggestion" was expanding the "arm" keyword to "armv4-linux", > > "armv5-linux", "armv6-linux", "armv6-hardfloat-linux", > > "armv7-softfp-linux", "armv7-hardfloat-linux", > > "armv7-hardfloat-uclibc-linux" - that is nowhere near a good solution. > > We've ran over the reasons and they have appeared as fit for this idea. > > It can be prejudged as "nowhere near a good solution"; but for it to > actually be that, it would need solid reasoning that people agree on. > > Reasoning is also needed to be able to figure out which conditions are > fit for another solution; that way, the other solutions could be shaped > with the help of that feedback to make the other solutions better. > > > The /dev/null comment was about wanting others to do the work and not > > contributing anything more than (imo) a stupid idea > > The idea moves work from one place to another, which yields the same > amount of work; your work statement seems like another topic, which you > are making basic assumptions on. Solutions to the stated actual problem > are neglected, as more time for research and consideration is needed. > > To get on the topic of your work statement; consider that one can find > 7 people whom each have one arm configuration much faster than one can > find 1 person that has all of them. > The idea moves the work around, it doesn't lessen the workload at all. You can easily find 7 people who have an armv7, and even v6, since the rpi is quite popular. Getting them into the arch team and willing to run stable and actually test programs is a whole other story, which lead to you saying: "People that have certain architectures can just add themselves, no extra work again." And that's a show stopper, just randomly adding yourself to an arch team and claiming you've tested it is a nonstarter. Considering if there IS an issue, we then have to track you down and figure out why/what is different in the configuration that it's failing for others. You being on the QA team even offering that up as an option makes it questionable as to why you're on the QA team. That should never even be thought of as an option. What you've thrown out as a possible solution is akin to taking a pile of peas on the plate and moving them around the plate so that the pile doesn't look so big. It doesn't change the amount of work, but you do need to look in more places for the work. Finding people with the hardware is the main issue, and I think I mentioned before, some people are simply unwilling to invest in "slow" hardware, so we have to rely on the people who DO have it. And if that means things take longer to stable, well, why is that an issue? Stable is supposed to be that - stable. > > if you aren't willing to put in the work, don't expect others to. > > If you are unwilling to work towards solutions, don't expect others to. > > > And yes, I see what you mean now re: my reply seeming off - it would > > seem when I hit group reply, for some reason, Evolution is putting > > Peter Stuge into the CC, and not Tom Wijsman (despite hitting group > > reply from your email. Maybe there should have been more testing of > > Gnome 3.8 before it was stabled on x86... > > http://www.unicom.com/pw/reply-to-harmful.html > http://woozle.org/~neale/papers/reply-to-still-harmful.html > I don't care of "reply to" is considered harmful, I care that something that worked with the previous stable is suddenly not working with the new stable. It obviously shows that it wasn't tested properly, and yet was marked stable. So, as QA, shouldn't you be doing something about that, rather than pointing to some URLs on the web, telling me I'm in the wrong for using the option that is supposed to handle that properly in my stable software?
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Fri, 2014-01-24 at 00:50 +0100, Tom Wijsman wrote: > On Thu, 23 Jan 2014 23:42:28 +0100 > Peter Stuge wrote: > > > Tom Wijsman wrote: > > > you shoot down solutions > > > > Maybe it wasn't a very good solution that deserved to be shot down. > > Maybe it was; what is needed here, is the feedback that makes it better. > > Work towards a very good solution deserves more than a plain /dev/null; > if they end up in /dev/null when provided, solutions appear unwelcome. > > Constructivism has to come from both sides to have an useful discussion. > Your "suggestion" was expanding the "arm" keyword to "armv4-linux", "armv5-linux", "armv6-linux", "armv6-hardfloat-linux", "armv7-softfp-linux", "armv7-hardfloat-linux", "armv7-hardfloat-uclibc-linux" - that is nowhere near a good solution. The /dev/null comment was about wanting others to do the work and not contributing anything more than (imo) a stupid idea - if you aren't willing to put in the work, don't expect others to. And yes, I see what you mean now re: my reply seeming off - it would seem when I hit group reply, for some reason, Evolution is putting Peter Stuge into the CC, and not Tom Wijsman (despite hitting group reply from your email. Maybe there should have been more testing of Gnome 3.8 before it was stabled on x86...
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Thu, 2014-01-23 at 20:13 +0100, Tom Wijsman wrote: > > I don't think that's what was being proposed, though. The question was > > really the old complaint about slow architectures; the "-* arch" > > solution sounds like the most reasonable definition of "dropping" > > keywords, in the absence of AT communication otherwise. > > Dropping keywords and specifying -* are a world apart of each other. > > The former means that it is not ready for wide stable or testing users, > the latter means that it has been tested to not work at all; > furthermore, we need to explicitly specify which arches in that case. > The complaint is slow to stable arches - by specifying "-* arch" it would signify that ONLY that arch uses that version of the ebuild - and it would be up to the arch team to remove it once they've stabled the new version - and considering the complaint is only about slow arches, there's nothing additional to specify in there - it's REMOVING arches that have stabled a newer version already, so they are unaffected. On the other hand, you're suggesting that we don't actually bother with stabling things - or actually testing that things are properly stable, allowing anyone to decide when something is stable, whether they have access to the hardware to actually test that it works. You and a few others keep talking in the theoretical while I've shown an actual problem but you and the others conveniently ignore ACTUAL problems in favor of your possible problems. Please stop.
Re: [gentoo-dev] Re: Add a KEYWORD representing any arch
On Sun, 2014-01-19 at 10:46 +0100, Ulrich Mueller wrote: > Now what problem are we trying to solve? As I see it, it is mainly > one of manpower, namely that some arch teams cannot keep up with > stable requests, and I doubt that any technical solution will help > to solve this. Introducing a "noarch" keyword or allowing "*" will > potentially cause problems with dependency resolution. > > Instead, we should come up with a clear set of rules under what > circumstances package maintainers are allowed to stabilise ebuilds > themselves on all architectures. > When they have machines that cover all architectures - assuming there is some sort of machine code at all. Otherwise, why even bother having stable keywords? Everyone keeps going on about how they will potentially have issues because something old is stable - I've thrown out that maybe we should (after a certain amount of time - when cleaning maybe?) remove all keywords except the only stable one, and then leaving it up to the slow arches. I know what the dev manual says, but I'd much rather have an old ebuild that's KEYWORDS="-* arm" than have that ebuild removed because a new one is KEYWORDS="arm" that doesn't work at all. Everyone else keeps talking in the theoretical, and I'm talking an actual issue. This affects me and my workflow and ask ryao about how he wanted to emerge git- to look into fixing it... -- steev
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, 2014-01-16 at 02:32 +, Robin H. Johnson wrote: > > In my testing, one known issue was that git on uclibc did (and still > > doesn't) work properly starting with git 1.8 - so I noted in the bug > > that this was the case, and to NOT stable it for arm. Unfortunately, > > someone else on the ARM team disregarded the note and stabled the new > > git, then the git maintainers dropped the old versions. Now on arm > > uclibc, git is entirely broken and unusable. > Ugh, this does suck. > It does, though it's specific to arm uclibc, as it works fine on amd64/x86 uclibc. And unfortunately, it seems like this type of thing is what people are proposing we move towards. Instead of working but old, not having access to the software at all. I know it's not the norm, nor is it typical, but the chance of this happening does exist, and I can't see how anyone would say, well, that's just the chance that people should take, unless they've never been bitten by a bug like this. > Wasn't there a proposal years ago to include the libc in the keyword? > There may have been, I'm not sure that's really the right step either though.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, 2014-01-15 at 13:07 -0600, William Hubbs wrote: > When you say "drop keywords" do you mean: > > 1) revert the old version back to ~arch or > 2) remove the old version. > > As a maintainer, I would rather do 2, because I do not want to backport > fixes to the old version. > > William > I'm not sure what he meant by drop keywords either, however, something that I would like to see (with my ARM hat on here) - is, if something is taking a while to stable for a certain arch, remove the keywords except for that existing arch. We actually ran into something along this issue with git. Now, arm is an interesting keyword, because for arm, when something needs to be stabled, we have to test armv4, armv5, armv6, armv6 hardfloat, armv7, armv7 hardfloat, armv7 uclibc. In my testing, one known issue was that git on uclibc did (and still doesn't) work properly starting with git 1.8 - so I noted in the bug that this was the case, and to NOT stable it for arm. Unfortunately, someone else on the ARM team disregarded the note and stabled the new git, then the git maintainers dropped the old versions. Now on arm uclibc, git is entirely broken and unusable. And no, adding more people to the arch team doesn't particularly help, as people are buying more and more armv7 so they test that, but not the rest of the versions - and no one wants to buy the older hardware "because it's so slow" - we know it's slow, that's why it takes time. I'd have definitely preferred that for git, that the 1.7 version stuck around with just KEYWORDS="-* arm" (and maybe even stabling 1.8 but leaving 1.7 in masked?) - I realize it was a bit of a special case because of the new git eclass. Unfortunately, debugging what's going on, is a bit above me, and the only other person I know who can/does work on it, is blueness, and he's quite busy.
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Tue, 2013-12-10 at 06:23 -0500, Rich Freeman wrote: > On Tue, Dec 10, 2013 at 5:31 AM, Steev Klimaszewski wrote: > > On Mon, 2013-12-09 at 20:33 -0500, Rich Freeman wrote: > > You're thinking with your x86/amd64 hat on here. > > Actually, I probably just underquoted. I am well-aware that there are > issues with ARM, hence my previous suggestion that it might make sense > to vary this by profile. > Definitely - but then we have to do everything in the profiles, and at least for ARM, there are currently 6 profiles, and we're considering introducing a 7th (neon), and we will need to add aarch64, which will be at least 2 more. I suppose we could do it in the base arm profile... > Let me try my post again, with a bit more quoting: > > On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina > wrote: > > What if he wants to > > put a stage3 on a disk for his amd64 box from his arm box? I'd love to > > see him emulate an amd64 from his arm to install dhcpcd. > ... > > I really don't like the idea of having no networking in the stage3 by > > default, however, I'm becoming more open minded on what qualifies as > > networking. What I'm wrestling with is this, what if I want to slap a > > stage3 on a device and then access it from the network? > > Almost nothing > > in my place has a monitor (amd64 and arm alike) and I use one of my two > > laptops to talk to everything else. > > Hit your head on the wall because it doesn't contain a kernel? > Stage3s in general aren't functional systems. > > Insofar as much as he was talking about ARM I get the point. Insofar > as he is taking about amd64, not so much. Which he was talking about > in that paragraph I can only guess at. > > But as I later said in the same email: > > If it actually had collisions with other network managers I think > there would be more of a case for removing it. > > After all, we stick openrc and portage (the PM) in the stage3 and you > don't exactly need those in order to run Gentoo... > > Rich > While you don't need those specifically to run Gentoo, the point of the stage3 is to have a workable base to start with. So people are very much free to yank out openrc and put in, say, systemd, and rip out portage and add in paludis, if they so choose, and make those available. And from the traffic I've seen on the systemd list, it looks like they are adding some sort of networking to systemd itself as well, so we probably will need a virtual at some point. My specific point of the email though, was you saying that a stage3 in general aren't functional - but they are - they are the very base of a functional system, and you simply add things on top, or replace things with your preferred methods. A stage1 or a stage2 isn't particularly functional.
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Mon, 2013-12-09 at 20:33 -0500, Rich Freeman wrote: > On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina > wrote: > > I really don't like the idea of having no networking in the stage3 by > > default, however, I'm becoming more open minded on what qualifies as > > networking. What I'm wrestling with is this, what if I want to slap a > > stage3 on a device and then access it from the network? > > Hit your head on the wall because it doesn't contain a kernel? > Stage3s in general aren't functional systems. You're thinking with your x86/amd64 hat on here. An ARM device can be booted with the kernel over networking (or even via usb, as is the case with most Android devices) and rootfs on local storage. Just because x86/amd64 doesn't do it, doesn't mean others can't/don't. What exactly is missing from a stage3 aside from a kernel? At this point on most ARM devices, it goes like this: extract stage3 edit inittab (and if needed) securetty create net.eth0 & symlink it to the default runlevel, along with openssh(assuming headless system) copy your kernel & modules into their proper places (if needed) put sdcard into arm device, watch it magically boot and work What you're proposing is: extract stage3 install qemu (assuming you don't have it yet) mount dev/proc chroot emerge a-network-manager set password (might as well, since you're chrooted) vim inittab nano inittab (and if needed) securetty exit chroot unmount dev/proc copy kernel & momdules to their proper places put sdcard into arm device, watch it magically boot and work Why exactly is the latter one better? the emerge a-network-manager step would be far faster on the device itself, even the RPi. I plan to look into the SUSE Qemu fork, as they've supposedly sped it up immensely (iirc it takes about a week to build gcc according to armin76 for aarch64) but even then, that would be a hack as their patches may or may not have been sent upstream - and they may be aarch64 specific and arm could still be slow as balls. So remember, just because your laptop/desktop can't do awesome stuff, doesn't mean other devices can't :)
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Mon, 2013-12-09 at 10:28 -0500, Rich Freeman wrote: > Ok, now the concern is becoming more clear. You're intending to boot > directly to the stage3 and not chroot into it, and so you want the > stage3 to be a fully-functional userspace, though you don't actually > need it to contain a kernel/bootloader. > A stage3 is pretty much fully functional if you just create net.ethX and ln it in the default runlevel. (It will currently use busybox's udhcpc for dhcp client) > How do you even log into the stage3? Do we not disable the root > password by default? You can easily echo a password into /mnt/gentoo/etc/shadow - see code listing 5.4 on http://dev.gentoo.org/~armin76/arm/beagleboneblack/install.xml > > Can you boot off of the minimal install image instead? Not sure if we > have one of those for ARM. Actually, any boot image that sets up a > network and supports chroot would work fine for your purposes. I do > realize that many (all?) ARM platforms don't have a flexible > bootloader like x86 typically does - so I'll let you speak to what > makes sense here. We don't really have any minimal boot images for ARM as each device is different. Some devices have a u-boot that will boot an sdcard, some require you to put u-boot on the sdcard, some require a button press while having u-boot on the sdcard... so on and so forth. I'm not sure we really want to put out an image for each card (though it is something I'd like to discuss if the arm@ team would freaking reply to the thread on arm@ about having a freaking team meeting) > > Following the handbook, the network is established by the boot CD and > all you do before chrooting is copy over your resolv.conf. In that > environment there is no need to have a networking system pre-installed > on the stage3. > You can do this with a qemu chroot on an amd64/x86 machine - but as ZC mentioned, it's slow - really slow - qemu emulates an arm processor running about 200mhz slow, and really NOT ideal at all. I currently suffer through it to build wpa_supplicant as a lot of my arm devices use wifi, but it really sucks. Even building on an rpi is faster than through qemu. > Oh, and if I'm not mistaken the stage3 is based on the system set > which is established by the profile, so if it made sense to keep > networking around for ARM that would be an option. > > Rich >
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Thu, 2013-12-05 at 09:01 +0100, Martin Gysel wrote: > if you're on x86/amd64 and want to prepare a sdcard for e.g. arm. you > extract the stage3 to the card but then you can't just chroot and emerge > netifrc... > on the other hand, as long as busybox' default config includes a dhcp > client one can always call it manually, unfortunately to do so. you need > to have access to the system which isn't always guaranteed without network. > so I strongly vote against exclude a default network stack for stage3. > why not introduce a stage3 set which includes @system and other > important packages like the default network stack? > > /martin Actually, it's quite easy to chroot into an arm rootfs on amd64/x86 if you have qemu or qemu-user installed. I do this on a daily basis. It's really not difficult at all. -- Steev
Re: [gentoo-dev] Re: vim and gvim package split
On Fri, 2013-11-01 at 16:52 +, Alessandro DE LAURENZIS wrote:
> Kent Fredric gmail.com> writes:
>
> > Useflags have their perks for giving variations on behaviour, but having 3
> > effective packages in one, governed by useflags, means you'll have 3 much
> > more tightly coupled packages, and the code will be much messier with
> > useflag conditionals to pull dependencies.
> >
> > If you imagine useflags like "if" statements, and ebuilds like independent
> > classes where "dependencies" are a kind of inheritance, you may find theres'
> > reasonable benefits for the maintenance side e.g.: people checking reverse
> > deps for QT don't have to worry about changes in QT breaking vim and gvim
> > because those packages are independent of QT interaction
> >
> >
> > Fixes that need to go in to make building vs QT mean only the qvim ebuild
> > gets updated and the rest are fine as-is.
> >
> > The only real downside is if you're building all 3 {q,g,}vim there's a
> > little compile time overhead as a result ( Though I'm not sure what the
> > difference is in real terms )
> >
> > But by having them seperate, we enjoy a more robust installation,
> > especially for people who only want one of the 3, then they're not
> > needlessly burdened by logic to handle things they're not using, which
> > could break.
> >
> > Not to mention you have to deal with overheads introduced by having to
> > work out the equivalent of all three of the above having vastly different
> > useflags and making useflags conditional upon each other as a result to
> > codify the same behaviour, again, further raising the odds that a situtation
> > will arise where things break and the dependencies/use flags are a mess.
>
> Kent,
>
> all your argumentations make sense, but actually only apply to vim-qt, which
> isn't in fact in the vim main tree.
>
> In other words: it's normal that vim and vim-qt are two different packages,
> but gvim is just vim with the GUI interface (neither an add-on nor a different
> project); playing with USE flags in /etc/portage/package.use should give easy
> access to all the possible options:
>
> - only vim ("-gtk");
> - gvim ("gtk");
> - qvim ("-gtk" for vim and vim-qt as package, having vim as dependency);
> - or even both ("gtk" for vim and vim-qt).
>
> What's wrong or complex (from a mantainer perspective) with this?
>
> Thanks for your comments
>
>
>
For binary package use, it's nice, as you may want to only install vim
on one machine, and gvim on a different one, but if you use the same
binhost that means you have to build vim rather than use the binary
packages.
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
-Original Message- From: Carlos Silva To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing Date: Wed, 6 Mar 2013 18:25:38 -0100 @@ -663,7 +696,7 @@ # This looks messy, but it is needed to handle multiple variables # being passed in the BUILD_* stuff where the variables also have - # spaces that must be preserved. If don't do this, then the stuff + # spaces that must be preserved. If dont do this, then the stuff # inside the variables gets used as targets for Make, which then # fails. eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \ ^^ Why did you remove the ' in don't ? Seems like it was an mistake? The rest looks fine to me, maybe Ryao can chime in, I know he was interested in module signing. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About unresolved bugs assigned to mobile for ages
On Mon, 2012-10-29 at 09:50 +, Markos Chandras wrote: > On Sun, Oct 28, 2012 at 12:26 PM, Pacho Ramos wrote: > > Hello > > > > I would like to know about mobile team status and also show that this > > team has important bugs assigned to them for a long time, some of them > > with patches (and reporters angry because of seeing things untouched for > > a long time). > > > > If anyone has time to join to the team and help, nice, if the team needs > > to drop from some packages maintainership due lack of manpower, please > > tell us what packages do you want up for grabs. > > > > Thanks > > I don't believe anyone is active in the mobile herd anymore. Probably > the packages need to be > moved to maintainer-needed@ so individual developers can take care of them. > As far as I know, I'm the only one in the mobile herd (actually I think it's 3 of us total), and I don't have the hardware to even test some things with it anymore (e.g. pcmciautils - which REALLY needs a fix and some lovin from someone) - I'd definitely agree that the mobile herd could go away, or if some people wanted to join and help out, that would be greatly appreciated.
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Just picking a random response to reply to. I'm not speaking officially, however, I'm pretty sure we at Genesi aren't going to pay Microsoft in order to boot our own boards.
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On Sun, Apr 25, 2010 at 5:42 PM, Alistair Bush wrote: Use common sense here. ^^ Seems pretty clear to me.
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On Fri, Apr 16, 2010 at 3:28 PM, Ciaran McCreesh wrote: > On Fri, 16 Apr 2010 16:23:48 -0400 > James Cloos wrote: >> OK. Let me rephrase. Portage does not need to validate local >> changes. > > Sure it does. If it doesn't, and your local changes affect metadata, > horrible things happen. Why not check the mtime on the overlay, if it is older than last sync time, not invalid. >> If a user uses a local eclass to override one in portage or in some >> remote overlay s/he follows, it is his/er responsibility to update >> it when the original undergoes major renovation. > > Users aren't responsible... And doing everything we can to make them not be isn't going to teach them anything. > -- > Ciaran McCreesh > Steev
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
memoserv
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On Mon, Nov 10, 2008 at 12:23 PM, Mart Raudsepp <[EMAIL PROTECTED]> wrote: > On E, 2008-11-10 at 13:13 -0500, Mark Loeser wrote: >> Removing Stable Ebuilds >> >> If an ebuild meets the time criteria above, and there are no technical issues >> preventing stabilization, then the maintainer MAY choose to delete an older >> version even if it is the most recent stable version for a particular arch. > > Even if that is a package that other packages depend on? Lets say I want > to delete an ancient version of gtk+, but arch ABC has that as the only > stable ebuild, while the rest are ~ABC. Do I remove it, as I may, and > break the whole stable tree of arch ABC, unkeyword hundreds of other > packages, or I'm just allowed to remove it but should really apply a > common sense as usual and you don't want to go into details in this > document? *MAY* choose - you don't *have* to do it - I'd prefer something along the lines of, may stablize it - if after a minimum of 30 days - maybe 90 days max - if the arch team hasn't had enough time to stablize it... when will they ever?
Re: [gentoo-dev] Re: "Slacking" arches - which are stable, which aren't?
On Sun, Oct 5, 2008 at 9:07 PM, Ryan Hill <[EMAIL PROTECTED]> wrote: > On Sun, 05 Oct 2008 20:44:51 -0500 > Jeremy Olexa <[EMAIL PROTECTED]> wrote: > >> I would suggest moving all the "slacking" arches to "experimental" >> until there is desire from the dev community (read: manpower) to >> support a stable tree again. Until then, it seems pretty pointless to >> keep assigning bugs to these arches and they just keep rotting there >> because no one gets around to them. >> >> 2 cents, >> -Jeremy > > ++ $473.57 > > My aim with the email wasn't to start up this discussion so much as to figure out which arches are supported by stable keywords, and which ones are okay to not request stable keywords so that bugs don't sit around for months without action on them. I know that vapier is pretty much the only dev with an sh or s390 box, but I know there are a couple of people with ARM, I was just hoping we had some sort of official list somewhere.
[gentoo-dev] "Slacking" arches - which are stable, which aren't?
Not wanting to start a huge war about what arches are slacking and which aren't - I asked in -dev on IRC and was told to check out profiles.desc - based on this information, I closed Bug 208917 which was about stablizing dbus-glib-0.74. The bug was opened on 04 Feb 2008, and as of today 05 Oct 2008, the only arches left to stable it are arm, sh, and s390 (and according to profiles.desc, they are all dev profiles) however hoffie said that didn't seem right since he knows things get requested for stable for those arches. So, IS there a definitive list somewhere of what arches are stable, and which aren't, and if so, where can it be found? I have no problem re-opening the bug, but as I stated in -dev, its been almost 8 months since the last *activity* on the bug, and I doubt that they are going to be stabling it any time soon. Thoughts? Helps?
Re: [gentoo-dev] Re: RFC: 0-day bump requests
On Mon, 2008-07-07 at 15:33 +, Duncan wrote: > Jim Ramsay <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Mon, 07 Jul 2008 10:10:14 -0400: > > > Here's an interesting solution for those who find it annoying though: > > Just file your own 0-day bump request in bugzilla. In theory some users > > would find this and just CC themselves on it. Other users could be > > shushed with the shame of the DUPLICATE. Everyone wins! Just picking a random one to reply to... As stated by the gnome herd - most of them are on the mailing lists, and for packages that I maintain, I tend to be on upstreams mailing list as well. While for the most part, 0day don't extremely bother me, the deluge of mail can be overwhelming at times (even using filters) 47 mailing lists including seperate folders for bugs that are specific to me, my herds, and other herds I am interested in, and playing catch up to all of that after 12 hours of work can get troublesome. Occasionally though, there are the packages that I have that don't have a mailing list, and its nice to know that there are users out there that actually a) use them and b) know that there is a bump before I do. So, really, if upstream has a mailing list/announces a 0 day is unwarranted, if not, then by all means please do. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Council nominations deadline
On Mon, 2008-06-16 at 23:04 -0600, Ryan Hill wrote: > Just for completenessess sake, i was nominated and declined. No one > likes my idea of teaming up with McDonalds to create the McGentoo meal > (each includes a free collectible developer bobblehead and > maintainer-needed bug). > Depends on the developer... can you get the entire set? Or is it just Spanky? Cuz I'd be all for it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]
On Thu, 2008-06-12 at 11:39 +0200, Fernando J. Pereda wrote: > On 12 Jun 2008, at 04:16, Brian Harring wrote: > > > > Why the exherbo/paludis/PMS folk decided to go this route to report, > > I'm not quite sure aside from assuming they're just griefers. > > s-exherbo/paludis/PMS-pkgcore-g and: > > http://fpereda.wordpress.com/2008/05/03/on-cooperating-and-paludis-vulnerability/ > > Except this one wasn't a lie. > > I wish there were more cooperation between all of us. But looks like > it is impossible with some of your people. > > - ferdy > Please stop whoring the url for that, its old already. There is a huge difference between that and knowingly witholding information because you "want to see unit tests done." Quit being a fuckwit. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Fri, 2007-09-21 at 11:37 -0700, Chris Gianelloni wrote: > ebuild when it is being merged. If this really is so objectionable, I'd > just assume WONTFIX the request and move on with it. > +1 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Vlastimil Babka wrote: dodoc calls should have || die and USE=doc should be tested before commiting a bump, IMHO Sorry, I didn't realize my 3 hour compile of $APPLICATION should die because TODO wasn't around. Vote against || die - it doesn't affect anything aside from misc docs not being installed, if its really that important, most people hit the website anyway. (But yes, they should be corrected and tested before committing) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: default desktop profile
Martin Schwier wrote: The gnome meta ebuild pulls in way too much stuff. I always have to copy it in my local overlay and have to remove epiphany, evolution, vino, ekiga and more. There are no use flags to control this and I expect many gnome users to use Firefox and Thunderbird instead of epiphany and evolution. (many, not all). If I use the official gnome ebuild instead of my edited one then 35 new packages will be pulled in. Well I think *that* is bloat! The libnotify useflag pulls in one 60k library that don't harm anyone. The official Gnome meta ebuild pulls in what upstream considers to be the Gnome Desktop - thats why it is there, the Gnome herd will *not* change that. As a convenience, they have provided the gnome-light meta ebuild. If Gnome pulls in too much, then take a look at gnome-light. If that pulls in too little, then continue to work on it in your overlay, the Gnome herd does not have time to create multiple ebuilds of the "official" upstream Gnome desktop just because some users don't want this or that, they provide it as a convenience, and that is all. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
Sven Köhler wrote: Why did you provocate this breakage? Which breakage? It didn't install a gzipped pci.ids here. That is with USE=hal. Crap... Oh! So USE="hal" forces pciutils not to use zlib? And so the check, which the hal ebuild performs, should be modified to check for USE="hal" rather than for USE="!zlib" ? Except that ONLY that version that recently went stable has the useflag. So the check will need to be modified (thanks carlo for that amazingly useful bug report!) but will still need to make sure that its not built with zlib for 2.2.6 until someone gets around to adding the hal useflag there as well, apparently. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] virtual/x11 cleanups
Hey all, Donnie wants to remove virtual/x11 (can ya blame him?) and since Josh_B has retired (for now! ;) ) I wanted to help Donnie out a bit, since he is busy and X is a massive undertaking... a "quick" grep of the tree excluding ChangeLog files shows 3319 occurrences of virtual/x11 still in the tree. I don't have a list as that is a lot of occurrences, so if you maintain something that uses X, please take a glance through your ebuilds and make sure they have the true package deps and perhaps help lighten Donnie's load. Thanks -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] have any developers subscribed to -project?
Dale wrote: > George Prowse wrote: >> Ned Ludd wrote: >>> On Fri, 2007-07-20 at 20:58 +0100, George Prowse wrote: >>> Do any devs subscribe to -project because no replies have yet to be heard from developers... >>> Please stop flooding my inbox. >>> >> It is an honest developer question because it was meant to have >> discussions between developers there and if no developers subscribe >> then what is the point of having it? You might as well just close it now >> > > I agree. They complain about us coming here for their input but they > won't come to where we are so we can get theirs. > > I posted this on -project and I'm going to post it here. This is my > answer to people being rude and disrespectful to us users. I'm making a > list of the people that say things they shouldn't, just like a post here > from kingtaco a day or so ago. People on that list will NOT be voted in > for anything by me and there may be others that will follow this list. > I'll make sure it is public and may even post the reason/post for the > addition to the list. So, if you want to continue acting the way some > few are, that's fine, but I have in the past few days decided to grow a > pair and will make sure every one knows my opinion. > > I feel it is time for a change with regard to a few people that give > everybody else and Gentoo a bad PR. This is my little contribution to > Gentoo. > > Dale > > :-) :-) No, we complain about non-technical posts showing up here... and guess what is... please take it to -project if it isn't technical. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Improving developer/user communication (was Re: net-im/pidgin protocols)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 not technical, take it to -project. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn9rz1c+EtXTHkJcRAqEiAJ91+dcEu2/q6F1K/QTkqaHgWJUl0QCeMh6u 3PfRN7OZ8rNFwiXEr//dg7I= =vuLo -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: QA issue: No stable skype in Tree
Steev Klimaszewski wrote: Steve Long wrote: Stephen Bennett wrote: Not everyone sees that as a reason not to use a potentially useful piece of software. We're not debian. Could you clarify whether this is indeed a Gentoo QA issue, or in fact a licensing issue? If the latter case, this discussion should prob'y go to the new -project ml if and when, or indeed the user forums. As for potentially useful, so was Internet Explorer, last time I looked at what you could do with its Object Model. I still ain't voting to bring it to Gentoo.. ;) It is neither a QA nor license issue, its an issue of the download being unavailable. Please read the full thread. And to reply to myself - its a licensing issue since we cannot mirror the distfile. However, I hardly find that "facist" - my own opinion, others vary of course - the main issue is simply that the download won't be available - if you even throw out the licensing issue of not mirroring, have you tried to install 2006.0 lately? (Yes, I know 2007.0 is out) - you can't even do a 2006.0 install if you use the portage and stage3 tarballs from the cd because those distfiles are no longer available. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: QA issue: No stable skype in Tree
Steve Long wrote: Stephen Bennett wrote: Not everyone sees that as a reason not to use a potentially useful piece of software. We're not debian. Could you clarify whether this is indeed a Gentoo QA issue, or in fact a licensing issue? If the latter case, this discussion should prob'y go to the new -project ml if and when, or indeed the user forums. As for potentially useful, so was Internet Explorer, last time I looked at what you could do with its Object Model. I still ain't voting to bring it to Gentoo.. ;) It is neither a QA nor license issue, its an issue of the download being unavailable. Please read the full thread. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Are you guys for real?
Jayson Vaughn wrote: > Ok, > Gentoo is over. As an outsider who has been following gentoo-dev and > other gentoo lists for a while, this is just completely nuts. > Is there any order or clear idea anymore for this distro? No other > distro seems to be as lost or confused as Gentoo is. And WTF is this > list going to discuss development? Do you guys develop ANYTHING? Or Do > you just bitch all day? Good bye Gentoo, when you grow up and know > what your goals are etc I'll be back. Love the distro, but Jesus the > politics and the bitching gets out. > > Just an observation from the outside. > > > > Are you for real? Normally its the dev's who scream and rant on the way out, not the users... -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] QA issue: No stable skype in Tree
Vlastimil Babka wrote: > Gustavo Felisberto wrote: >> Any alternatives? > > Drop it from stable completely, possibly package.mask or move to > overlay. Why should this closed-source rootkit be in stable? > Said the java dev Personally, I'd say if upstream doesn't provide downloads, nothing we can do, and yeah, suggest to users to try the unstable version until such a time that it could become stable... -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [RFC]: gentoo-politics ML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ilya A. Volynets-Evenbakh wrote: > Stephen Bennett wrote: >> On Tue, 12 Jun 2007 23:10:32 +0200 >> Benjamin Judas <[EMAIL PROTECTED]> wrote: >> >> >>> ...which means that he has a documented history of trolling not only >>> on mailinglists but also in irc-channels; not only against developers >>> but also against volunteering users. >>> >> So do most people on this list. >> > Which brings us back to actual subject of this thread (as opposed to talking > about Ciaran, we all love so much), which is - we need a separate list > for discussing > non-technical issues, which will, hopefully, reduce amount of flames, > and will allow > civil technical discussion to commence. > So this other list would allow non-civil discussions to continue and rage on? I mean, you wouldn't have to be civil to others on it, you could just join and start trolling everyone? (Please note, when I say "you" here, I mean collective people, not singling any person out) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbxks1c+EtXTHkJcRAhjfAJ9zzOoi+L6JNiByjsCPKghGo3BS2ACfeyOM MXVAcenApLFxrt3Na8qNa5c= =upnw -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC]: gentoo-politics ML
Ilya A. Volynets-Evenbakh wrote: > Steev Klimaszewski wrote: >> Ilya A. Volynets-Evenbakh wrote: >>> Marius Mauch wrote: >>>> Do you really think people would voluntarily use it? That's an >> honest question, maybe people are fair enough to do it, but I have >> serious doubts about it. It's of no use if people have to be told to >> move threads from -dev to that new list. >>>> >>> We might need some sort of enforcement for that particular purpose. >>> While I think that "behavior" proctors are inappropriate, I think that >>> people with ability to say "move this thread to gentoo-politics or >> else.." >>> for non-technical threads, as well as "stop failing to use logic in your >>> technical discussion or else..." with power to temporarily ban people >>> for non-compliance could be a useful thing. >>>> Marius >>>> >>>> >> No can do - temporarily banning is a bad thing, its censorship, and we >> can't have that, no sir. > I'll presume this to be irony. Oh. Sorry, can't have that on this list > today. > Please ban yourself for 24hours. Not irony, sarcasm, and no sir, I will not ban myself. The proctors could have though, but not since no one will listen to them and they have been completely undermined and made obsolete by an overzealous council member. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC]: gentoo-politics ML
Ciaran McCreesh wrote: > On Thu, 07 Jun 2007 11:50:02 -0500 > Steev Klimaszewski <[EMAIL PROTECTED]> wrote: >> No can do - temporarily banning is a bad thing, its censorship, and we >> can't have that, no sir. > > It's censorship when it's being done one-sidedly in order to skew an > argument based upon the prejudices of those doing the banning. > Correct you are, your technical knowledge is still sharp as a tack. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC]: gentoo-politics ML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ilya A. Volynets-Evenbakh wrote: > Marius Mauch wrote: >> Do you really think people would voluntarily use it? That's an honest >> question, maybe people are fair enough to do it, but I have serious doubts >> about it. It's of no use if people have to be told to move threads from -dev >> to that new list. >> > We might need some sort of enforcement for that particular purpose. > While I think that "behavior" proctors are inappropriate, I think that > people with ability to say "move this thread to gentoo-politics or else.." > for non-technical threads, as well as "stop failing to use logic in your > technical discussion or else..." with power to temporarily ban people > for non-compliance could be a useful thing. > >> Marius >> >> > No can do - temporarily banning is a bad thing, its censorship, and we can't have that, no sir. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGaDc51c+EtXTHkJcRAlS4AJ9iUXc8uMBSJa0CRzzL5IrbIjvRagCfYoNv BC0ftD75Sm5yFvRBPBoj2Dw= =EHWQ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: phasing out app-accessibility/festival
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William Hubbs wrote: > Hi all, > > app-accessibility/festival has not done a release upstream in some time. > We currently have several bugs against this package, including one > security bug. > > Since a lot of blind people are now using espeak as their software > speech synthesizer, and the new version of emacspeak (version 26, which > will be in portage pretty soon) can support espeak, I would like to know > this. > > Once emacspeak 26 is in the tree, I would like to move festival out of > accessibility, or remove it from the tree. > > If there is a reason to keep festival in the tree, > can someone please contact me and take over the package? > > Hi William, Could you point me to a noob's guide to espeak? I cannot seem to get it to output any speech. voyageur on IRC stated that it worked for him via 'aoss espeak "hello world"' - however, I don't have aoss. I inteded to test against kismet, but without being able to get it working standalone, I can't get it working with kismet. Thanks~! - -- Steev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGaA6p1c+EtXTHkJcRAg7DAJ9XRzZq8E0P6t9ygRQYEA7Zue4hRQCfSjPp QZFMpdnz75s+4UVb/3Xl7xE= =Wk3L -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Proctors - improve the concept or discard it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: > The Code of Conduct was written with the hopes that its existence would > help to curb the flamewars and other general nastiness between people > within the community. The proctors were created to enforce the Code of > Conduct. Their mandate was to be very fast moving and to try to keep > flames from spreading. For some time, I was working with the proctors. > I ended up disliking the bureaucratic direction they were taking and > chose to have myself removed from the group. Since that time, I have > pretty much felt that the proctors *have* taken it upon themselves to > single out and target particular individuals. Whether this was > intentional or not is really beside the point. The perception is all > that really matters, as it is all that gets propagated to the world. I > think this is something that people seem to forget. It doesn't matter > what the real truth is for anything. All that matters "to the world" is > what they perceive. If the perception is that Gentoo is nothing but a > bunch of guys waiting to flame people, it doesn't matter that there > might be 98% of the developer pool that has never engaged in a flamewar. > (Numbers completely made up...) > Not everyone had your perception either - in fact, it would appear that a lot of people have the same perception as me, which is that Neddy saw the potential of this thread to do exactly what has happened, and asked for people to NOT post for 24 hours. Certain individuals decided to respond anyways due to that being their nature, and they got banned. Suddenly because those people have a tendency to do this "proctors are out to get them" - perpetrated by the fact that it is them doing the same thing time and again, it is *NOT* singling anyone out, it is simply responding and attempting to curtail their efforts yet again. So while you have a certain perception - which appears to be the same as the ones the CoC was used against, whether that is good or bad, I have no idea - doesn't mean that *everyone* has your perception. >> While preventing it is a good goal in itself, writing a CoC based on an >> actual case which has only recently occurred, usually leads to this >> result and damages the whatever good intentions were involved because >> other people will see the similarities as well. > > The Code of Conduct wasn't written in response to a particular case. > The timing suggests that it was written against Ciaran. It wasn't. I > know this will sound a bit harsh, but if we really were trying to just > get rid of Ciaran, we would have just banned him and been done with it. > There wouldn't have been a point in creating yet another project and > staffing it. The goal *was* and still *is* to reduce the flames, no > matter what parties are involved. > >> More than that, it puts a strain on those who are entrusted with enforcing >> the CoC because they will try, with the best motives, to prevent anything >> like that happening again. And they will do it, as the proctors stated >> themselves, pro-actively. > > No, re-actively. If it were proactive, it would be done before the > flames started. The proctors *have* tried to react as quickly as > possible. The problem is that there are no published guidelines, and > decisions from the proctors are completely arbitrary to any outside > observer. I think they've failed. Again, I don't think that the guys > didn't have the best intentions, and I know that some people took my > voicing of their failure as a direct personal assault. It wasn't meant > that way, but I'm not going to apologize for my observations. I see no > point in apologizing for what *I* perceived, even if it does hurt a few > feelings. I just think people are being overly-sensitive. It's > Gentoo's curse. > Overly sensitive? Perhaps you should go re-read your email. And yes, I do believe an apology IS in order. Of course, my beliefs mean nothing, I am a lowly developer, you are a high and mighty council member who is above reproach for your actions. >> The problem is, though: In an asynchronous communications medium, you >> simply cannot pro-actively do anything without bordering on what some >> like to call censorship. You can only *re*act in such a situation. >> >> Even *trying* to act pro-actively will lead to unrest as we've only very >> recently seen it. If we accept my hypothesis of asynchronous >> communication and the implications I described, we come to the conclusion >> that reaction is the most likely way not to open Pandora's Box. > > Attempts to become more proactive were dismissed. One such attempt was > to enforce bans on all mediums. For example, if someone is banned for > 24 hours for their actions on IRC, they should be banned from all of our > media. Why? Because there's nothing keeping the person from just > moving "next door" and starting more problems. We've even seen it > happen in at least
Re: [gentoo-dev] Living in a bubble [gentoo-proctor] Warning^2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josh Sled wrote: > Grant Goodyear <[EMAIL PROTECTED]> writes: > >> got out of hand. Perhaps the goal was laudable, but the methods were >> not? (As an aside, I didn't realize that Roy's e-mail was supposed to >> be a proctor directive.) Or are people really looking for the proctors >> to get involved only when behavior is particularly egregious? Is there > > I find it disappointing (maybe "telling", if one is less charitable) that the > Proctors never censured the original poster for either the tone of the > message, nor the personal invective it contained, and still haven't. I'd > imagine clear violations of the CoC to result in at least a public > admonishment and warning. > The proctors have no power now, thanks to Chris publicly stabbing them in the back after they tried to assert some of their powers - they requested that no one respond to the thread for 24 hours, and people couldn't respect that simple request - and now with what Chris said, it just fuels the flames due to Council "backing" them - as Ciaran has already asserted in a mail earlier in the thread. Great job Chris, way to stick it to them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZvmA1c+EtXTHkJcRAhgZAJ92BOAq8cd+Tp1cxXSUC8sNvw5eUwCfeOeF Kh4cZO7lgVAleBC5s20zZmY= =0PzG -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Living in a bubble [gentoo-proctor] Warning^2
Mike Doty wrote: > Ciaran McCreesh wrote: >> On Wed, 6 Jun 2007 10:29:47 -0500 >> Grant Goodyear <[EMAIL PROTECTED]> wrote: >>> (As an aside, I didn't realize that Roy's e-mail was supposed to >>> be a proctor directive.) >> He changed the subject and signed "on behalf of gentoo-proctors". >> >>> Is there a way to fix the current system, or should it be chucked >>> entirely, as has been suggested? >> The problem is not so much the system as a small number of the >> proctors. Perhaps it should be restaffed with people who aren't so used >> to wielding god-like powers on the forums, where anyone who dares say >> anything that disagrees with a small clique's collective views can >> be banned permanently with no accountability. > Back to reality, go take a long walk off a short pier. > ++ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Living in a bubble [gentoo-proctor] Warning^2
Ciaran McCreesh wrote: > On Wed, 06 Jun 2007 10:44:49 -0500 > Steev Klimaszewski <[EMAIL PROTECTED]> wrote: >> Or... perhaps when asked not to respond to a thread for 24 hours, you >> could keep your fucking trap shut? > > If I'm asked by someone with a good reason, sure. If I'm told to by > someone on a power trip with a history of abusing authority who's making > insane claims about humour not being allowed and trying to achieve a > particular outcome to a discussion by censoring anyone who disagrees > with them, then no. > Technical prowess you have immensely, which is good because it makes up for your lack of common sense. I am done, and you are now killfiled. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Living in a bubble [gentoo-proctor] Warning^2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Wed, 6 Jun 2007 10:29:47 -0500 > Grant Goodyear <[EMAIL PROTECTED]> wrote: >> (As an aside, I didn't realize that Roy's e-mail was supposed to >> be a proctor directive.) > > He changed the subject and signed "on behalf of gentoo-proctors". > >> Is there a way to fix the current system, or should it be chucked >> entirely, as has been suggested? > > The problem is not so much the system as a small number of the > proctors. Perhaps it should be restaffed with people who aren't so used > to wielding god-like powers on the forums, where anyone who dares say > anything that disagrees with a small clique's collective views can > be banned permanently with no accountability. > Or... perhaps when asked not to respond to a thread for 24 hours, you could keep your fucking trap shut? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZtZx1c+EtXTHkJcRAosHAJ42XbbNLSEaOVeLtAcEvTFMrmhAvQCggR5l NKfMVHNa0HuInct529dbI0s= =s4+3 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Living in a bubble [gentoo-proctor] Warning^2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Piotr Jaroszyński wrote: > On Tuesday 05 of June 2007 23:13:48 Wernfried Haas wrote: >> So far we have temporarily suspended both ciaran's and geoman's account >> from posting and encourage everyone to do as Roy initially suggested. > > Haven't roy just said that jokes "should normally be avoided in international > forums such as are provided by Gentoo."? > Actually, if you read the snippet from Roy, he points out that the start of the mail says that it will likely start a flame war and requests that people not respond to this thread for 24 hours. I am responding, just as you have, because apparently, neither of us can follow a simple instruction. /me heads back to kindergarten... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZdlx1c+EtXTHkJcRAsKuAJ9kWogERJ13DWZlzXF7m7+YjIK8BACfUiih pDwonPmvDEvU07mdtbisl38= =TTYY -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [news-item] Paludis 0.24
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Færøy wrote: > On Sat, May 05, 2007 at 12:13:12AM +0200, Vlastimil Babka wrote: >> Isn't such use case just a replacement for elog? I thought news were >> supposed to be delivered before upgrading. Also "You should update your >> configuration files after upgrading." sounds like something one would >> read before upgrade... > > It'll only affect users after they upgrade. > Right which... seems to me something I would want to know *BEFORE* I upgraded... otherwise, yeah, elog does the same thing already... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGO7Xz1c+EtXTHkJcRAgPkAKCHU2QU+nFr3l+4kteNWD4mcVQ7swCfUy76 kEoMuymvLn9+kMtI7jUxnUo= =1JPW -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [PROCTORS] Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wernfried Haas wrote: > Just a general note to everyone in this thread: > I haven't had the time to read the posts in this thread, but proctors > have received complaints about behaviour within. For the time being, i > would ask all people participating to remember the CoC applies here > and act accordingly. > We will review the posts in this thread for CoC violations as soon as > possible. > > cheers, > Wernfried > Go get em tiger! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLnYh1c+EtXTHkJcRAspLAJ9HUhy/5oegWBYbfX7YEzeDU63bjQCdHn40 qNtMMhg8cm2jtotWYeUMaK8= =azL1 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Resignation
Bryan Østergaard wrote: On the contrary we warn people about not behaving badly and if that doesn't help despite many warnings and complaints being filed we finally take to firmer action which is exactly what have happened in this case. Regards, Bryan Østergaard Sorry, I am going to have to call bullshit. The only part of that statement that is remotely true is the last line of that paragraph. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] genlop-0.30.6 released
Chris Gianelloni wrote: On Sun, 2007-04-08 at 11:03 -0400, Michael Cummings wrote: Been a while, upstream moved on in life but we continued to get interested users filing bugs, so genlop-0.30.6 went into the tree this morning. Primarily a bug fix release based on what was open in bugs.gentoo.org. Enjoy :) Does this mean we're hosting the project now? No idea, but I've noticed a minor cosmetic bug in the display of time with genlop (both -t and -c) [EMAIL PROTECTED] ~ $ genlop -t mozilla-thunderbird * mail-client/mozilla-thunderbird Tue Aug 22 12:18:24 2006 >>> mail-client/mozilla-thunderbird-1.5.0.5 merge time: 1 hour, , 19 minutes and 40 seconds. Tue Sep 26 16:31:31 2006 >>> mail-client/mozilla-thunderbird-1.5.0.7 merge time: 2 hours, , 41 minutes and 48 seconds. Thu Nov 9 15:47:51 2006 >>> mail-client/mozilla-thunderbird-1.5.0.8 merge time: 3 hours, , 16 minutes and 8 seconds. Thu Dec 14 10:54:56 2006 >>> mail-client/mozilla-thunderbird-1.5.0.8 merge time: 2 hours, , 55 minutes and 51 seconds. Sun Dec 17 21:17:50 2006 >>> mail-client/mozilla-thunderbird-2.0_beta1 merge time: 2 hours, , 43 minutes and 29 seconds. Mon Dec 18 00:15:00 2006 >>> mail-client/mozilla-thunderbird-2.0_beta1 merge time: 2 hours, , 39 minutes and 5 seconds. Tue Feb 20 00:15:54 2007 >>> mail-client/mozilla-thunderbird-2.0_beta2 merge time: 3 hours, , 12 minutes and 54 seconds. Sun Apr 8 21:24:11 2007 >>> mail-client/mozilla-thunderbird-2.0.0.0_rc1 merge time: 3 hours, and 37 seconds. Mon Apr 9 00:36:46 2007 >>> mail-client/mozilla-thunderbird-2.0.0.0_rc1 merge time: 2 hours, , 48 minutes and 57 seconds. (The multiples of the same version are due to the bindist flag and forgetting which way its supposed to be to get the pretty icons) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] *DEVELOPMENT* mail list, right?
[EMAIL PROTECTED] wrote: *daemons/applications that crashed: dbus powersaved -> KPowersave Networkmanager -> KNetworkmanager Also, the new hald didn't want to start, because dbus had crashed because of the auto-hald-reload. So we need to prevent this before it goes stable: a) print out a big fat warning before doing the update / make the update interactive, so we make sure, the user knows about the dangers b) find a way, to postpone the reload until the next reboot / disable auto-reloading for the currently running session This were the only problems I could find so far. What I really liked about the update: didn't have to re-emerge (revdep-rebuild) a single package.. ;-) Regards, Elias P. Odd that dbus would crash/restart - hald uses dbus, not the other way around - however, dbus should be restarted to read the new (possibly) hald.conf - the real fix would be for the apps that use hal to NOT bomb when hal is yanked out from under them. Glad it was fairly painless for you. And it is good to know that some people are using KNetworkManager - I don't have a machine currently with KDE installed (my KDE machine died) and so I haven't tested it at all recently. -- Steev -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Firefox 1.5 series will get removed in 30 days
Chris Gianelloni wrote: On Thu, 2007-03-29 at 11:50 +0200, Christian Birchinger wrote: On Thu, Mar 29, 2007 at 12:23:49PM +0300, Petteri Räty wrote: If you read what you are quoting: Mozilla will drop support for that series from 24 April 2007 onwards. That's still almost a month + the time no security issues appear. This would be still better. How is prolonging the inevitable "better" exactly? I understand some people's reluctance, but the Mozilla team *knows* they'll have to remove the 1.5 series sometime on or after April 24th, anyway. Why should they bother keeping it in the tree? Because Portage sucks and it is oh so hard to add it into an overlay... /me runs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: gentoo-dev vs lkml?
Ciaran McCreesh wrote: Personally I understand why flameeyes took that to bugzilla; how else could he say he'd gone thru the appropriate channels? Devrel (a group, not an individual) weren't set up to respond quickly as others have informed us all. Case in point: you need to distinguish between flameeyes leaving (again) as a publicity stunt because his attempt to blackmail devrel failed and flameeyes' stated reason for leaving... It was an ultimatum. He goes or I go, it was not blackmail. FFS, can we please stop calling it blackmail? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] add bzip2/zlib to default USE in default-linux
Robin H. Johnson wrote: On Mon, Feb 26, 2007 at 01:46:40AM -0600, Steev Klimaszewski wrote: Luca Barbato wrote: T?th Csaba wrote: hal cannot install when one dependencie built with zlib USE flag.. Hal should be fixed then... lu We've already been arguing about this on the bug, can we please not bring it here... What bug # ? http://bugs.gentoo.org/show_bug.cgi?id=161057 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] add bzip2/zlib to default USE in default-linux
Luca Barbato wrote: Tóth Csaba wrote: hal cannot install when one dependencie built with zlib USE flag.. Hal should be fixed then... lu We've already been arguing about this on the bug, can we please not bring it here... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: portage idea - auto embed user patches
Steve Long wrote: Alec Warner wrote: http://dev.gentoo.org/~solar/bashrc At the bottom of solar's bashrc you will find some lines dealing with AUTOPATCH, I don't see the bashrc.autopatch in his dev space, but you can probably request it from him. Would it be possible to post that to this list? Then we've all got a searchable record of the best practise. try http://dev.gentoo.org/~solar/portage_misc -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Breaking your box with dbus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a heads up... This is part of the reason that dbus > .9x is still p.masked. We are moving from dbus-core back to dbus - dbus will NOT be a meta package for dbus > .9x. It will be the core daemon. You should be depending on either just the bindings you need (which will depend on dbus itself, or the bindings and dbus itself.) This is just an informative email, so that people know, even though its p.masked as I am sure it will cause some people some issues. Steev, on behalf of the Gentopia team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFRhr81c+EtXTHkJcRAliDAJ9+RobEZoyOdiu42cTvftMl1LFgeQCfdYgc 2GxUmFXw3Pn6nwgezJpMMvo= =VFQY -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Livecd, python, pyopengl and broken gtk installer
Dominique Michel wrote: > It seam at it is a big problem with the livecd. > >>From the forum: > QUOTE: The problem is you can't use the GTK installer due to this problem. It > crashes out and leaves you with no option but to wash, rinse, repeat, > re-crash. > > By saying they won't fix the bug the developers have decided to make the > graphical installer a waste of effort. In my case I went in and installed the > old fashoned way (never HAVE gotten that graphical POS to work), but for > anyone > who is trying out Gentoo and hasn't done this a few hundred times before > they're out of luck. > > Bad for them, bad for the community, bad for Gentoo, bad for Linux. > > Do these guys work in Redmond now? ENDQUOTE > > http://forums.gentoo.org/viewtopic-t-477582-start-25.html > >>From bugzilla: > > QUOTE: And we still won't and can't fix it. All the livecd stuff is just a > snapshot of portage tree in a given moment. There's been one use flag, changed > meanwhile -> emerge --sync, re-emerge python and stop ranting here. ENDQUOTE > > http://bugs.gentoo.org/show_bug.cgi?id=147809 > > I have done a search on bugzilla, and it is other bug report where problems > with the livecd have been fixed, so I just don't understand why this one want > be fixed, and I am just too tired to argue on it. It say all time the same > thing, do a sync and re emerge python. With the livecd?... > > So here is the problem: the livecd gtk installer is broken and it must be > fixed. But no one seam to be willing to do so. So, when I read such comments > on > the forum, I think at it will be better to remove this livecd from the > servers. > It is better to have no publicity as a bad publicity. > The gtk installer is NOT broken. Have you tried to install without the tk/tcl/tcltk use flag? Personally, I installed with the default flags set, in fact, I told it networkless install and was up and running in about 40 minutes (366MHz) - The installer works, but not every single USE flag combination can be tested. You can *always* change a flag after you have the system installed. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Timothy Redaelli (drizzt)
Petteri Räty wrote: > It's my pleasure to introduce to you Timothy "drizzt" Redaelli, the > latest addition joining to help out with the Gentoo/FreeBSD effort. > > He hails from Milan, Italy. He currently works as an embedded programmer > using ASM/C. It probably doesn't come as a surprise to anyone that he > was mentored by Flameeyes and is the latest addition to his minions. > > Timothy is skilled in system work, setting up and securing servers. He > is a staff member of GUFI (Gruppo Utenti FreeBSD Italia) and FreeSBIE > (FreeBSD LiveCD) and he maintains some packages of FreeBSD. > > So please welcome drizzt and give him the usual warm welcome. > > -- > Petteri Räty (betelgeuse) > > > Woohoo! Congrats Drizzt! Now I have more help with getting Gnome working on Gentoo/FreeBSD! Glad to see you are a dev. Now, get to work ;) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
Simon Stelling wrote: > Jakub Moc wrote: >>> The missing Stage3 is the real problem. >> Apparently... >> >> http://gentoo.osuosl.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/amd64/2006.1/stages/stage3-amd64-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/ppc/2006.1/ppc32/stages/stage3-ppc-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/ppc/2006.1/ppc64/stages/stage3-ppc64-32ul-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/ppc/2006.1/ppc64/stages/stage3-ppc64-64ul-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/sparc/2006.1/sparc32/stages/stage3-sparc-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/sparc/2006.1/sparc64/stages/stage3-sparc64-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/ia64/2006.1/stages/stage3-ia64-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/alpha/2006.1/stages/stage3-alpha-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/hppa/2006.1/stages/hppa2.0/stage3-hppa2.0-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/hppa/2006.1/stages/hppa1.1/stage3-hppa1.1-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/mips/2006.1/stages/mips3/stage3-mips3-2006.1.tar.bz2 >> http://gentoo.osuosl.org/releases/mips/2006.1/stages/mips4/stage3-mips4-2006.1.tar.bz2 > > Stop being stupid please, you're only making fun of yourself. I guess I > don't have to explain you how useful a URL is to a _networkless_ > installation, do I? > No... but didn't one download and burn that CD that is being used for the _networkless_ install? One could also download the stage needed, slap it on a usb key, and viola! Of course, the other option, is to use that crazy installer option "Networkless" - I could be wrong, but I do believe that is the option I would choose. (Actually I did this just the other day because of the issues I am having at home with my networking. And it worked splendidly on a P2 366 - so kudos to the releng team) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SCHEDULED DOWNTIME: {cvs,svn}.gentoo.org - 2006-10-05 - 1900UTC - 2300UTC
Chris White wrote: > On Monday 02 October 2006 13:30, Robin H. Johnson wrote: >> We'll keep status in the topic at #gentoo-dev while we're working on it. > > Alright, I'm starting a pool on how many people will still ask why cvs and > svn are down. Starts at $5, who'se in? > What about how soon after it goes down someone asks? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steev Klimaszewski wrote: > Simon Stelling wrote: >>> Hello all, >>> >>> I would like you to share your comments on the attached GLEP with me. >>> >>> Thanks in advance! >>> >>> >>> > > I think it is over engineering of a non-issue. And to expand, per blubb's request, all you are doing is moving /usr/portage/licenses out somewhere else on the filesystem. Now instead of one file per license, I need a minimum of 5 - the license ebuild, metadata, changelog, manifest and digest -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFEUBP1c+EtXTHkJcRAjreAJ0Wa1Jj5kmfd4iprrDUTDUbqORm8gCfbyV1 Ee8/WXmCWpMES+9qHjjUxWs= =IcFw -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: > Hello all, > > I would like you to share your comments on the attached GLEP with me. > > Thanks in advance! > > > I think it is over engineering of a non-issue. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFET2j1c+EtXTHkJcRAladAJ9r8VK6WUzjv9Pnextkh8b4N6xPFQCfX+pW 7EBxySyIomhsSDEL7noSFig= =6LAs -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monolithic X unsupported
Stephen P. Becker wrote: > Steev Klimaszewski wrote: >> Donnie Berkholz wrote: >>> Mike Frysinger wrote: >>>> how about a local USE flag like "all-the-junk-in-the-trunk" ? >>> Why? Just makes more work for us, for no apparent reason. I'd rather be >>> able to pull unused stuff from the tree after a while than add a new >>> option to install stuff nobody will ever run. >>> >>> Thanks, >>> Donnie >>> >> I think SpanKY just wants a junk-in-the-trunk useflag... > > Why won't we just call it spankysmom? > > -Steve Because then it would have to be global not local... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monolithic X unsupported
Donnie Berkholz wrote: > Mike Frysinger wrote: >> how about a local USE flag like "all-the-junk-in-the-trunk" ? > > Why? Just makes more work for us, for no apparent reason. I'd rather be > able to pull unused stuff from the tree after a while than add a new > option to install stuff nobody will ever run. > > Thanks, > Donnie > I think SpanKY just wants a junk-in-the-trunk useflag... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Who wants to tinker with a Palm Zire 71?
Noack, Sebastian wrote: > Hi, > > I have a Palm Zire 71 device, with Palm OS on it and a 400 MHz > ARM-Processor in it. Actually I don't use this device anymore, so if > somebody wants try to get Gentoo Linux run on it, I would give it to him. > > There is an SD/MMC-Slot which could become used to get data on the devie > an there is also an IR interface and a USB-Adapter. But the biggest > problem I see is that the OS is on a ROM, but maybe there would be a way > to manipulate the BIOS if it has one, to boot from somewhere on the RAM. > > In any case I guess it would require to maipulate the hardware. If > somebody here have the skills and motivation to try that, he or she > should tell me and I will send him or her my device. > > Best Regards > Sebastian Noack > I'd love to - if anyone else hasn't already claimed it :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Should patches sit withing the portage tree ?
Enrico Weigelt wrote: > Hi folks, > > > I'm interested in arguments whether patches should sit directly > within the portage tree or downloaded when needed. > > My feeling: downloading on demand is better. > > + makes the tree smaller, saves space, saves network traffic > - downloading lots of patches may take a little bit > > What do you think ? > > > cu I think you need to do more reading and stop posting random (obvious) trolls. You have stated many times in your other threads that you haven't read $threadabout documentation. Please do so, and then come back and ask, or, even better, use the proper mailing list, or even the forums. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
Enrico Weigelt wrote: > Not actually an eye-catching. Ummm, D, as opposed to U... Yeah, that catches my eye. I am weird like that though. > > To be fair, do *you* actually look through *all* the emerge > output if there's any "D" flag, without the risk of overlooking > it someday ? Yes, honestly, I DO look at it - I wouldn't be much of a system administrator if I didn't. I *always* *always* run emerge -uDpv world when I do an update world - and not only that - but I *always* *always* run emerge -av packagename/world - I never ever blindly run an emerge - even if it is the same one I just ran a -p on. I dunno, guess I am just careful like that. Obviously, not everyone wants to be vigilant - but if you aren't - then you don't get to whine about it when it breaks. well actually I guess you do... > > Why can't emerge shout out some more verbose text ? Something > really eye-catching ? > Well, why not look into color.map - and as has been mentioned in this or other flags, read the finely written documentation - in fact, I know of other distros who use OUR documentation when pointing out how to do things to others on THEIR distros. Documentation isn't exactly written because the doc writers were bored. It was written so things aren't constantly repeated as have been over and over and over...infinity. Seriously, stop trying to be lazy and be a responsible system admin. > cu No, cu! Steev -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Hiatus
Roy Marples wrote: On Saturday 15 July 2006 19:25, Henrik Brix Andersen wrote: As some of you already know, I will be taking a hiatus from Gentoo starting this weekend. While I am gone, the mobile herd is pretty much left without active developers. Uberlord and phreak have already adopted some of the more critical ebuilds, but quite a few are still "orphaned" as seen in this report from 'herdstat -dp brix': app-laptop/laptop-mode-tools app-laptop/radeontool app-laptop/tp_smapi net-misc/radvd I'll take these too net-wireless/madwifi-ng net-wireless/madwifi-ng-tools I'm very reluctant to take these - I do have the hardware, but it's on my home amd64 hardened server whose main connection is wireless and getting wired to is a PITA. Any other madwifi users want to step up and take these? I know there are a few of you ;) I could probably do madwifi-ng - I don't own the hardware personally, but my best friend, and co-worker has a card that I can use at any time, so I have it available to me. Only have x86 systems however. Steev -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev]
On Fri, 2006-07-14 at 01:02 +0100, Ser Gio wrote: > On Fri, 14 Jul 2006 00:19:44 +0200 > Jakub Moc <[EMAIL PROTECTED]> wrote: > > > Ser Gio wrote: > > > Hello, > > > > > > Why does x11-libs/gtk+-2.8.19 has the "X" useflag? The ebuild > > > doesn't look like it's using it. > > > > > > thanks, > > > Sérgio > > > > Because virtualx.eclass has it in IUSE and the ebuild inherits it. > > Yes, i noticed that. But, for the enduser, the X flag in gtk+ is > useless right? So, is it a bug? > > Regards, > Sérgio Martins Actually, as of 2.10, gtk+ CAN be built without X and using the framebuffer, so you can build gtk+ apps against the framebuffer (using them, is another story... although I hear GIMP works) so having it there isn't necessarily useless. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Future developer
On Fri, 2006-06-30 at 21:54 +0200, Paul de Vrieze wrote: > I'm proud to announce the arival of a future developer. His name is "Tom". He > arived last monday on 10:22 am (UTC+02). I and my wife will take care of > mentoring him to full developership ;-). > > In the meantime, he's got his own album on > http://www.cs.ru.nl/~pauldv/tom/ > > Paul > > ps. If I'm a bit away these days, it is due to me being preoccupied with my > mentoring task. > Congratulations! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, 2006-06-20 at 19:41 +0200, Simon Stelling wrote: > I don't know all the details, but assuming no app supports qt3 and qt4 at the > same time (i.e. you have two interfaces, one against each, which is pretty > senseless), wouldn't something like > > qt? ( || (=x11-libs/qt-3* =x11-libs/qt-4*)) > > be the best solution? It would allow the maintainer to set a reasonable > default, > but in case the user only has the other version, it would take that one. If > both > are installed, the one that the maintainer deemed the best is chosen. > > -- > Kind Regards, > > Simon Stelling > Gentoo/AMD64 Developer What about something like dbus? Qt3 and Qt4 bindings, for apps that use Qt3 and Qt4 (different applications using different versions of Qt) but still using the dbus bindings... -- gentoo-dev@gentoo.org mailing list
