Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Thursday 13 October 2011 01:33:07 Michał Górny wrote: > On Wed, 12 Oct 2011 23:20:23 -0400 Mike Frysinger wrote: > > On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: > > > How about if we add a `emerge --upgrade` target that is analogous to > > > `apt-get upgrade`? > > > > isn't that already done with @installed ? `emerge --upgrade > > @installed` > > Wouldn't that upgrade packages which are not needed by anything as > well? I.e. those which will be removed on next depclean. pretty sure that's what the OP wanted -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Wed, 12 Oct 2011 23:20:23 -0400 Mike Frysinger wrote: > On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: > > How about if we add a `emerge --upgrade` target that is analogous to > > `apt-get upgrade`? > > isn't that already done with @installed ? `emerge --upgrade > @installed` -mike Wouldn't that upgrade packages which are not needed by anything as well? I.e. those which will be removed on next depclean. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: Build dependencies and upgrades.
Rich Freeman posted on Wed, 12 Oct 2011 23:26:28 -0400 as excerpted: > On Wed, Oct 12, 2011 at 11:20 PM, Mike Frysinger > wrote: >> isn't that already done with @installed ? `emerge --upgrade >> @installed` > > Well, you'd arguably at least need a -N in there. Indeed. > Also, this doesn't work in stable portage - I assume this is something > available in the newer branch. Yes. @ denotes a set. Stable portage doesn't have sets in general yet, altho it is setup to recognize the two special sets, @system and @world (which for those sets only, for backward compatibility, may appear with or without the @). > In any case, if that is the "right thing" then we should update > our docs accordingly. Of course, that would need to wait for sets to stabilize. When that might be I haven't the foggiest, but it'd be nice to not have to be running hard-masked portage, again. (FWIW, my world file is entirely empty as all the packages formerly contained therein are now in custom sets, @local.admin, @local.fonts, @local.kde.base.kdebase.workspace, @local.xorg, etc, and those are in turn listed in the world-sets file, not world, which is for packages, not sets.) > Also - will doing an emerge -u @installed add those packages to @world - > ie do we need to throw a -1 in there, or is this behavior coded in as an > exception? Sets are recognized by the @ in front of them, and would normally be added to world-sets instead of world, but there's a number of special sets like @selected (@world minus packages only pulled in by @system) @system, @world, @installed, @live-rebuild (basically - versions), @preserved-rebuild, @security, @unavailable-binaries (AFAIK, @installed minus binpkg-available), @module-rebuild (external kernel modules), @x11- module-rebuild, etc. So yes, @installed is one of the special sets and therefore an exception. But... talking about -1 in context of --best (or whatever), I've always wondered why that wasn't the default, as well. Only add the package to @world if the user specifies to do so. That way a user can remerge an individual package (or set), without having to worry about whether it's going to be added to the world (world-sets) file, as it's only added when the option is specifically listed. But for that to work with --best, --best would have to be in EMERGE_DEFAULT_OPTIONS (with --best cancellable by later options if necessary), or people would be even MORE likely to forget to add the -1 for one-off emerges. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Build dependencies and upgrades.
On Tuesday 11 October 2011 14:50:27 Francisco Blas Izquierdo Riera (klondike) > This can be inconvenient since security issues fixed in those left over > packages won't be applied properly. `glsa-check -f affected`. i thought there was talk of an automatic @security set at some point, but not sure if that got anywhere. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Wednesday 12 October 2011 23:26:28 Rich Freeman wrote: > On Wed, Oct 12, 2011 at 11:20 PM, Mike Frysinger wrote: > > On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: > >> How about if we add a `emerge --upgrade` target that is analogous to > >> `apt-get upgrade`? > > > > isn't that already done with @installed ? `emerge --upgrade @installed` > > Well, you'd arguably at least need a -N in there. that's orthogonal to the issue and the target. the OP wanted to upgrade "all packages" which is @installed. if you want to rebuild when USE flags change, then use --newuse. no target should imply different option behavior. > Also, this doesn't work in stable portage - I assume this is something > available in the newer branch. it works for me, but i'm using latest portage (the _alpha## stuff). any proposed change would require an update anyways ... > Also - will doing an emerge -u @installed add those packages to @world > - ie do we need to throw a -1 in there, or is this behavior coded in > as an exception? i don't know about set behavior and the world file. it would make sense to me that "world" would special case @system and @installed and not add it to @world unlike other sets (i know that other sets do get added to world). Zac would know of course. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On 10/13/2011 03:10 AM, Matt Turner wrote: > On Wed, Oct 12, 2011 at 7:58 PM, Samuli Suominen wrote: >> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote: >>> Mike Frysinger schrieb: > The removed qutecom ebuild was not broken at any time. by splitting my reply, you changed the meaning. having qutecom in the tree with a depend on versions that i'm now removing breaks the depgraph. >>> >>> The depgraph is broken after the old versions are removed, not before. >> >> I'm not sure if you should have gentoo-x86 access anymore... This is scary. > > Come on. That's ridiculous, and nothing but trolling. Don't do that. > > Like in the pngcrush thread, miscommunications all around. > > Matt > (see my reply to Mike. I admit that came out way too blunt. sorry Chi-Thanh, Matt.)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On 10/13/2011 03:19 AM, Mike Frysinger wrote: > On Wednesday 12 October 2011 19:58:31 Samuli Suominen wrote: >> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote: >>> Mike Frysinger schrieb: > The removed qutecom ebuild was not broken at any time. by splitting my reply, you changed the meaning. having qutecom in the tree with a depend on versions that i'm now removing breaks the depgraph. >>> >>> The depgraph is broken after the old versions are removed, not before. >> >> I'm not sure if you should have gentoo-x86 access anymore... This is scary. > > this isn't helping the conversation > -mike you're right. sorry. that came out too harsh. lets rephrase this as: "This /topic should be in the end-quiz, and mentioned in the mentoring guide to cover basis as part of the KEYWORDS visibility handling." - Samuli
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Wed, Oct 12, 2011 at 11:20 PM, Mike Frysinger wrote: > On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: >> How about if we add a `emerge --upgrade` target that is analogous to >> `apt-get upgrade`? > > isn't that already done with @installed ? `emerge --upgrade @installed` Well, you'd arguably at least need a -N in there. Also, this doesn't work in stable portage - I assume this is something available in the newer branch. In any case, if that is the "right thing" then we should update our docs accordingly. Also - will doing an emerge -u @installed add those packages to @world - ie do we need to throw a -1 in there, or is this behavior coded in as an exception? Rich
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: > How about if we add a `emerge --upgrade` target that is analogous to > `apt-get upgrade`? isn't that already done with @installed ? `emerge --upgrade @installed` -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Build dependencies and upgrades.
Zac Medico posted on Wed, 12 Oct 2011 08:09:56 -0700 as excerpted: > On 10/12/2011 07:10 AM, Rich Freeman wrote: >> The defaults should be [safe] and the options should [flexibly >> allow less safety where judged necessary]. >> >> In my thinking the most conservative options right now are either >> emerge -uDN world or emerge -uDN --with-bdeps=y world. >> >> I'd almost prefer to see that -D, -N, and --with-bdeps go away, and >> that instead we add options like --shallow, --ignoreusechanges [...] >> I just think about Debian where you tell people run "apt-get update" >> and then "apt-get upgrade" and that is it. Their typical behavior is >> not specifying anything and you get everything updated. With Gentoo >> the equivalent is "emerge world" but when you do that you potentially >> miss a lot of stuff. >> >> (And I realize the --with-bdeps part of this is debatable.) I've privately thought similarly for quite some time, but rationalized it, as I expect many have, with the "gentoo isn't and never has been about babysitting" thing. We expect, even essentially demand, that our users actively assertively their own choices in such matters by choosing the options that make sense for them, because otherwise, there's basically no point to running the distro. But that doesn't mean we can't create a simple default that "just works" and is secure without all the arcane options. > How about if we add a `emerge --upgrade` target that is analogous to > `apt-get upgrade`? If we hide the new defaults behind a target like > --upgrade, rather than change the defaults globally, then it allows > people's existing scripted and habitual emerge commands to continue to > work in a backward compatible manner. This was exactly the point and suggestion that I expected Zac to make, and that I agree with just as strongly. Don't break existing working assumptions and scripts with new defaults, but do take advantage of the opportunity presented by this discussion to create a single sensible option that "just works" and does so safely. =:^) Meanwhile, Zac, if I may, another suggestion. In the manpage and other documentation of this option, specifically note that the intended purpose is a single option that "just works", and that as such, specific behavior of the option may change as portage itself changes. Thus, for scripts, etc, where unchanging specific behavior is intended, the individual specific options are recommended, instead. That way, a half decade or whatever down the line, when portage's best defaults have again changed, we won't be faced with the problem of creating a new "best single default option" to avoid breaking existing assumptions, because the explicit assumption about this option is that it will always do what's considered best, even if that changes its behavior over time, and people have the option of picking either unchanging behavior with individual options, if that's desired, or a single option that's always intended to give the best behavior, even if that changes over time. In that regard, perhaps call the option --best, or some such, so it can be used for upgrades, fetches, or whatever, and can be suggested for EMERGE_DEFAULT_OPTS, where --upgrade might not always be appropriate. Also, make it possible to override what --best might otherwise do with later options. So a command including --best --with-bdeps=n in that order would do what --best would do, except --with-bdeps=n would override it for that specific option. (Conversely, --with-bdeps=n --best would ignore the bdeps option since best overrode it.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 10:16 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Thus, the point I'd make and that I believe you were making is not that > Gentoo can't be different, or we'd obviously be doing a binary distro > like everyone else, but that we pick the differences which we value > enough to develop and maintain, and while the customization that building > from source allows is one of them, gentoo's not known as a "no-udev" > distro now, and making it so by default is in practice going to cost > resources that we simply don't have, so it's extremely unlikely to happen. Yup, that was basically what I was getting at. We need to pick our battles. Being so different that we have to patch half of our upstream packages to work with our userspace is just creating a mess. It is bad enough that we have to patch half of our upstream packages because they don't know how to make decent build systems. :) > > But gentoo /does/ value the ability of the administrator to make that > sort of choice for themselves, and gentoo would not be gentoo, if it > didn't try to preserve that choice where possible given development > resource constraints, because that is one of the points of > differentiation that gentoo has always focused on. Individual apps and > indeed, whole desktop environments, may require udev, but that doesn't > mean the gentoo machine admin isn't free to choose alternatives that > don't require it. I couldn't agree more. Certainly if anybody running an mdev system finds that some tweak to another package makes their life a lot easier and it doesn't otherwise increase the distro's maintenance burden a great deal, then they should submit a patch. Much of the power of Gentoo is that it gets out of the user's way when you want to do things differently. I think it will be a while before we see an mdev profile, however. Rich
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Wed, Oct 12, 2011 at 11:09 AM, Zac Medico wrote: > How about if we add a `emerge --upgrade` target that is analogous to > `apt-get upgrade`? If we hide the new defaults behind a target like > --upgrade, rather than change the defaults globally, then it allows > people's existing scripted and habitual emerge commands to continue to > work in a backward compatible manner. I think this is a good idea - and I wasn't seriously proposing that we just change those flags (if we were to do it we'd have to deprecate them slowly/etc). Perhaps define that --upgrade means "do the right thing (TM)" and that it shouldn't be used in scripts unless those using the script are willing to tolerate that this behavior could change over time. Rich
[gentoo-dev] Re: Suggestion for getting rid of udev
Rich Freeman posted on Wed, 12 Oct 2011 09:26:12 -0400 as excerpted: > My concern with something like dropping udev is that it would make us > different from every other desktop distro out there. I'm not aware of > any distro packaging Gnome/KDE without udev. Not having Redhat's > billions to me is a good reason to try to do things the same way that > Redhat does them - so that we're not re-inventing the wheel. I'm sure you didn't mean that the way it looks, or next, we'd certainly be switching to binary-by-default. However, you bring up a good point that I've seen repeated in one way or another in many discussions about Linux distros and how the compare and differ, and in particular, what makes the Linux ecosystem different from the Unix ecosystem before it, which ultimately so differentiated that each brand was effectively its own OS (as can still be seen in the various BSDs today, to some degree, as well as in the surviving commercial Unixen, despite POSIX and etc.). The point as I've seen it repeatedly made, is that what tends to keep the various Linuxen compatible is that while each distro does choose its own points of differentiation and does indeed differ in those points from most others, due to the forces of free/libre and open source, if one ends up really better, the others all adapt pretty much the same thing, *AND* perhaps more importantly, with f/l/os... --> Each point of difference requires a significant --> investment of time and energy from a distro's devs --> that they could otherwise avoid. That economy of efficiency forces distros to choose the points of distinction they REALLY value, and work on them, while in other areas, it's much more efficient to just go with the mainline flow, because being different requires WORK, both to achieve, and to maintain, especially at FLOSS development speed. (Of course, a subpoint can be mentioned as well, that in an all-volunteer community distro such as gentoo, to a rather large degree, the amount of resources the distro chooses to devote to any potential point of differentiation, depends on what individual developers choose to push as their own personal projects, and the degree to which they can motivate other devs and non-dev community volunteers to work with them toward that goal.) Thus, the point I'd make and that I believe you were making is not that Gentoo can't be different, or we'd obviously be doing a binary distro like everyone else, but that we pick the differences which we value enough to develop and maintain, and while the customization that building from source allows is one of them, gentoo's not known as a "no-udev" distro now, and making it so by default is in practice going to cost resources that we simply don't have, so it's extremely unlikely to happen. But gentoo /does/ value the ability of the administrator to make that sort of choice for themselves, and gentoo would not be gentoo, if it didn't try to preserve that choice where possible given development resource constraints, because that is one of the points of differentiation that gentoo has always focused on. Individual apps and indeed, whole desktop environments, may require udev, but that doesn't mean the gentoo machine admin isn't free to choose alternatives that don't require it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Wednesday 12 October 2011 19:58:31 Samuli Suominen wrote: > On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote: > > Mike Frysinger schrieb: > >>> The removed qutecom ebuild was not broken at any time. > >> > >> by splitting my reply, you changed the meaning. having qutecom in the > >> tree with a depend on versions that i'm now removing breaks the > >> depgraph. > > > > The depgraph is broken after the old versions are removed, not before. > > I'm not sure if you should have gentoo-x86 access anymore... This is scary. this isn't helping the conversation -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Wednesday 12 October 2011 19:27:41 Chí-Thanh Christopher Nguyễn wrote: > Mike Frysinger schrieb: > >> The removed qutecom ebuild was not broken at any time. > > > > by splitting my reply, you changed the meaning. having qutecom in the > > tree with a depend on versions that i'm now removing breaks the > > depgraph. > > The depgraph is broken after the old versions are removed, not before. which is what i said -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Wed, Oct 12, 2011 at 7:58 PM, Samuli Suominen wrote: > On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote: >> Mike Frysinger schrieb: The removed qutecom ebuild was not broken at any time. >>> >>> by splitting my reply, you changed the meaning. having qutecom in the tree >>> with a depend on versions that i'm now removing breaks the depgraph. >> >> The depgraph is broken after the old versions are removed, not before. > > I'm not sure if you should have gentoo-x86 access anymore... This is scary. Come on. That's ridiculous, and nothing but trolling. Don't do that. Like in the pngcrush thread, miscommunications all around. Matt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote: > Mike Frysinger schrieb: >>> The removed qutecom ebuild was not broken at any time. >> >> by splitting my reply, you changed the meaning. having qutecom in the tree >> with a depend on versions that i'm now removing breaks the depgraph. > > The depgraph is broken after the old versions are removed, not before. I'm not sure if you should have gentoo-x86 access anymore... This is scary.
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 09:09:24AM -0400, Walter Dnes wrote: > On Wed, Oct 12, 2011 at 05:32:05AM +, Nathan Phillip Brink wrote > > > You can already try out what using mdev instead of udev is like in > > Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use, > > remerge busybox. You must be sure to be using busybox-1.92.2 or later > > for bug #83301. > > Did you mean busybox-1.19.2? That's the latest ebuild in > /usr/portage, and it's still ~amd64 (~everything for that matter). Yes, Oops. -- binki Look out for missing or extraneous apostrophes! pgpKZ0WR9QjLJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Mike Frysinger schrieb: >> The removed qutecom ebuild was not broken at any time. > > by splitting my reply, you changed the meaning. having qutecom in the tree > with a depend on versions that i'm now removing breaks the depgraph. The depgraph is broken after the old versions are removed, not before. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Wednesday 12 October 2011 17:42:47 Chí-Thanh Christopher Nguyễn wrote: > Mike Frysinger schrieb: > > otherwise, Rich summed up things nicely in his later post. > > If you mean that common sense thing: if there is disagreement about it, > then it is obviously not common. you're mixing "common" with "absolute". so far, you're the only one who seems to think that this behavior is generally acceptable. > >> The second time the package was removed was even without mask or > >> announcement. > > > > well, it shouldn't have been re-added in the first place > > Why not? Nothing in the Gentoo documentation forbids adding an ebuild > which downgrades linux-headers or any other package. there is plenty of stupid stuff the documentation doesn't forbid. again, refer to Rich's post. qutecom is hardly an important package that it gets an exception. i'm sure all 3 Gentoo users were saddened by its demise. > And it is not that I dumped the package to rot there. In my email to > -devel I said that I was going to address the problem that suddenly > became so urgent. it doesn't matter if you intended on getting the issues fixed. the issue shouldn't have been reintroduced in the first place. nothing in this path necessitated adding bad packages back to the tree. > > your package is already broken, > > and removing the linux-headers would break that depgraph. > > The removed qutecom ebuild was not broken at any time. by splitting my reply, you changed the meaning. having qutecom in the tree with a depend on versions that i'm now removing breaks the depgraph. > runs fine with the packages in portage. It may trigger a linux-headers > downgrade, but if that really causes breakage in other packages (and I > am not convinced, as you gave only vague arguments, and a Google search > didn't turn up anything) i provided a hypothetical that is not unreasonable. if google could look up hypotheticals, then it's probably self-aware. > then it could be reason for masking. But not reason for removal. we don't generally keep masked things in the tree. it's broken, it gets masked, then it gets removed. this isn't complicated. > Only after all indeed uninstallable and needs to be fixed or treecleaned. the existence of other versions is irrelevant. your pkg is broken and needs to be fixed now regardless of what happens to old linux-headers versions. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Mike Frysinger schrieb: > otherwise, Rich summed up things nicely in his later post. If you mean that common sense thing: if there is disagreement about it, then it is obviously not common. >> The second time the package was removed was even without mask or >> announcement. > well, it shouldn't have been re-added in the first place Why not? Nothing in the Gentoo documentation forbids adding an ebuild which downgrades linux-headers or any other package. And it is not that I dumped the package to rot there. In my email to -devel I said that I was going to address the problem that suddenly became so urgent. > i would not consider broken packages (i.e. qutecom) in the tree as basis for > retaining the old versions of linux-headers. At no point I even suggested that old linux-headers versions be retained for qutecom. > your package is already broken, > and removing the linux-headers would break that depgraph. The removed qutecom ebuild was not broken at any time. It builds and runs fine with the packages in portage. It may trigger a linux-headers downgrade, but if that really causes breakage in other packages (and I am not convinced, as you gave only vague arguments, and a Google search didn't turn up anything) then it could be reason for masking. But not reason for removal. Only after all
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
On Wednesday 12 October 2011 15:57:45 Tomáš Chvátal wrote:
> 2011/10/12 Mike Frysinger:
> > On Wednesday 12 October 2011 15:44:53 Alec Warner wrote:
> >> If I want to add a patch to the list I might forget to to add the \
> >
> > admittedly, i hit this every once in a while, and with all the "|| die"
> > being implicit, it doesn't get caught right away. fortunately latest
> > portage will issue a QA warning at the end along the lines of "command
> > not found: ${FILESDIR}/${P}-my-new.patch". so one can hope the
> > maintainer tests their ebuilds and reviews QA output before committing
>
> That is the reason for the patch array implemented in the base eclass
> and why i want it in eapi5.
i'm aware of this being in base.eclass, but personally, i've avoided that
thing (and will continue to do so). if it's part of the EAPI, that'd be cool
and i'd probably start using it in my ebuilds.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
Hmm for the command-not-found, it should be fatal not just warning I suppose. I was not even aware of this fancy portage feature :) Tom
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
2011/10/12 Mike Frysinger :
> On Wednesday 12 October 2011 15:44:53 Alec Warner wrote:
>> If I want to add a patch to the list I might forget to to add the \
>
> admittedly, i hit this every once in a while, and with all the "|| die" being
> implicit, it doesn't get caught right away. fortunately latest portage will
> issue a QA warning at the end along the lines of "command not found:
> ${FILESDIR}/${P}-my-new.patch". so one can hope the maintainer tests their
> ebuilds and reviews QA output before committing ;).
> -mike
>
That is the reason for the patch array implemented in the base eclass
and why i want it in eapi5.
PATCHES=(
"patch1" # mycomment
"patch2" # another bug number
)
Example from wild:
PATCHES=(
"${FILESDIR}/${PN}-includes-libs-perl.patch"
"${FILESDIR}/${PN}-fix_wrong_linker_opts.patch"
"${FILESDIR}/${PN}-1.0.2-no_harfbuzz_tests.patxh"
)
See the typo on last patch.
>>> Preparing source in
>>> /var/tmp/portage/media-gfx/graphite2-1.0.3/work/graphite2-1.0.3 ...
* Applying graphite2-includes-libs-perl.patch ...
[ ok ]
* Applying graphite2-fix_wrong_linker_opts.patch ...
[ ok ]
* QA: File or directory
"/home/scarabeus/gentoo/gentoo-x86/media-gfx/graphite2/files/graphite2-1.0.2-no_harfbuzz_tests.patxh"
does not exist.
* QA: Check your PATCHES array or add missing file/directory.
* ERROR: media-gfx/graphite2-1.0.3 failed (prepare phase):
* Some patches failed. See above messages.
Which is why i really avoid calling epatch myself, the only reason is
to have conditional patches, which are root of all evil, because they
can be broken with update and you won't notice anyway.
Cheers
Tom
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
On Wednesday 12 October 2011 15:44:53 Alec Warner wrote:
> If I want to add a patch to the list I might forget to to add the \
admittedly, i hit this every once in a while, and with all the "|| die" being
implicit, it doesn't get caught right away. fortunately latest portage will
issue a QA warning at the end along the lines of "command not found:
${FILESDIR}/${P}-my-new.patch". so one can hope the maintainer tests their
ebuilds and reviews QA output before committing ;).
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
On Wed, Oct 12, 2011 at 12:33 PM, Mike Frysinger wrote:
> On Wednesday 12 October 2011 15:19:25 Samuli Suominen wrote:
>> On 10/12/2011 06:30 AM, Steven J Long wrote:
>> > Michał Górny wrote:
>> >> I don't think that passing multiple files to epatch actually improves
>> >> readability. Simple example:
>> >>
>> >> # bug #123456, foo, bar
>> >> epatch "${FILESDIR}"/${P}-foo.patch
>> >> # bug #234567, baz bazinga blah blah
>> >> epatch "${FILESDIR}"/${P}-baz.patch
>> >>
>> >> With multiple arguments, you can't put comments in the middle.
>> >
>> > ++ It's also a lot easier to remove the single patches when they're no
>> > longer needed.
>>
>> Removing an 'epatch foo' line is easier than 'foo \' ? You are kidding,
>> right?
>>
>> > In the context of configuring, building and installing a
>> > package, the extra overhead is miniscule, whereas the above is *much*
>> > easier to maintain.
>>
>> Based on what argument?
>>
>> Having the comments inside the patch allows everyone, including
>> _upstreams_ straight up see what's it for and link to the bug it's
>> coming from. Where as keeping them in ebuilds makes it Gentoo specific,
>> which is not what we are about.
>
> i personally prefer:
> epatch "${FILESDIR}"/${P}-foo.patch #12345
> epatch "${FILESDIR}"/${P}-bar.patch #19512 #91991
> epatch "${FILESDIR}"/${P}-fatcow.patch #19291
> because i personally like to have just the bug number there
>
> i know other people prefer to pass these all on one line:
> epatch \
> "${FILESDIR}"/${P}-foo.patch \
> "${FILESDIR}"/${P}-bar.patch \
> "${FILESDIR}"/${P}-fatcow.patch
The problem with the latter is the same problem I have w/python lists
and commas.
If I want to add a patch to the list I might forget to to add the \
epatch \
"${FILESDIR}"/${P}-foo.patch \
"${FILESDIR}"/${P}-last.patch # <-- Oops I forgot to add a \ here
"${FILESDIR}"/${P}-my-new.patch
Or I delete the last patch and forget to remove the \
epatch \
"${FILESDIR}"/${P}-foo.patch \
"${FILESDIR}"/${P}-bar.patch \ # <-- oops again!
>
> there is no standard here (i think they're more or less equally common) and
> maintainers are free to pick what they like best. arguing about the merits
> between the two above styles is a waste of everyone's time. go fix some bugs
> instead you lazy wankers :P.
I enjoy wasting time :)
>
> the one thing Samuli is correct about though and largely has nothing to do
> with style is that the patch itself needs to have all the relevant
> information. doing the following is wrong:
> # here i explain what the patch is for #12351
> epatch "${FILESDIR}"/${P}-bar.patch
> (and the bar patch contains only the diff)
>
> rather than rehash why you're wrong if you do the above, please read:
> http://dev.gentoo.org/~vapier/clean-patches
> -mike
>
Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On Wednesday 12 October 2011 15:38:47 Matt Turner wrote: > On Wed, Oct 12, 2011 at 3:13 PM, Mike Frysinger wrote: > > On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote: > >> Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto: > >> > - The fix_libtool_files.sh command is now part of the toolchain > >> > eclass, so > >> > > >> > doesn't need to be ran by users anymore > >> > >> Moreover, that should only be needed for very old installs: libstdc++.la > >> that caused the trouble in the first place hasn't been around for over > >> an year (maybe two? I lost count), and the auto-fix of .la files in > >> recent Portage versions make it even less necessary. > > > > well, that's not entirely accurate. like libtool, now that we've dropped > > libstdc++.la, the majority of issues have "gone away". but we still > > install .la files for the other (much more infrequently used) internal > > gcc libraries. > > > > although this might be something we want to address in gcc. i was fine > > with dropping the libstdc++.la even though it listed things in > > dependency_libs because the only correct way (imo) to link C++ code is > > with `g++`. using `gcc -lstdc++` is not supported. > > > > i think cases can be made for the other internal gcc libraries: > > - libgomp.la: build/link with -fopenmp, not -lgomp > > - libgfortran*.la: build/link with `gfortran`, not `gcc -lgfortran` > > - libgcj*.la: build/link with `gcj`, not `gcc -lgcj` > > - libobjc.la: use -lobjc to link, but dependency_libs='' > > - libffi.la: use -lffi to link, but dependency_libs='' > > - libmudflap.la: build/link with `gcc -fmudflap`, not `gcc -lmudflap` > > - libgij.la: build/link with `gij`, not `gcc -lgij` > > - libquadmath.la: only used by fortran, and dependency_libs='' > > gcc's Optimize Options page > (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) has an > example of linking C, C++, and FORTRAN code together, where it uses > g++ -lgfortran. Just thought I'd mention it. hmm, unusual, but good point. their example breaks when linking statically as fortran (always?) needs -lm, and with newer versions, -lquadmath. not sure how to address that other than leaving libgfortran.la in place :(. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On Wed, Oct 12, 2011 at 3:13 PM, Mike Frysinger wrote: > On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote: >> Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto: >> > - The fix_libtool_files.sh command is now part of the toolchain >> > eclass, so >> > >> > doesn't need to be ran by users anymore >> >> Moreover, that should only be needed for very old installs: libstdc++.la >> that caused the trouble in the first place hasn't been around for over >> an year (maybe two? I lost count), and the auto-fix of .la files in >> recent Portage versions make it even less necessary. > > well, that's not entirely accurate. like libtool, now that we've dropped > libstdc++.la, the majority of issues have "gone away". but we still install > .la files for the other (much more infrequently used) internal gcc libraries. > > although this might be something we want to address in gcc. i was fine with > dropping the libstdc++.la even though it listed things in dependency_libs > because the only correct way (imo) to link C++ code is with `g++`. using `gcc > -lstdc++` is not supported. > > i think cases can be made for the other internal gcc libraries: > - libgomp.la: build/link with -fopenmp, not -lgomp > - libgfortran*.la: build/link with `gfortran`, not `gcc -lgfortran` > - libgcj*.la: build/link with `gcj`, not `gcc -lgcj` > - libobjc.la: use -lobjc to link, but dependency_libs='' > - libffi.la: use -lffi to link, but dependency_libs='' > - libmudflap.la: build/link with `gcc -fmudflap`, not `gcc -lmudflap` > - libgij.la: build/link with `gij`, not `gcc -lgij` > - libquadmath.la: only used by fortran, and dependency_libs='' > -mike gcc's Optimize Options page (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) has an example of linking C, C++, and FORTRAN code together, where it uses g++ -lgfortran. Just thought I'd mention it. Matt
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
On Wednesday 12 October 2011 15:19:25 Samuli Suominen wrote:
> On 10/12/2011 06:30 AM, Steven J Long wrote:
> > Michał Górny wrote:
> >> I don't think that passing multiple files to epatch actually improves
> >> readability. Simple example:
> >>
> >> # bug #123456, foo, bar
> >> epatch "${FILESDIR}"/${P}-foo.patch
> >> # bug #234567, baz bazinga blah blah
> >> epatch "${FILESDIR}"/${P}-baz.patch
> >>
> >> With multiple arguments, you can't put comments in the middle.
> >
> > ++ It's also a lot easier to remove the single patches when they're no
> > longer needed.
>
> Removing an 'epatch foo' line is easier than 'foo \' ? You are kidding,
> right?
>
> > In the context of configuring, building and installing a
> > package, the extra overhead is miniscule, whereas the above is *much*
> > easier to maintain.
>
> Based on what argument?
>
> Having the comments inside the patch allows everyone, including
> _upstreams_ straight up see what's it for and link to the bug it's
> coming from. Where as keeping them in ebuilds makes it Gentoo specific,
> which is not what we are about.
i personally prefer:
epatch "${FILESDIR}"/${P}-foo.patch #12345
epatch "${FILESDIR}"/${P}-bar.patch #19512 #91991
epatch "${FILESDIR}"/${P}-fatcow.patch #19291
because i personally like to have just the bug number there
i know other people prefer to pass these all on one line:
epatch \
"${FILESDIR}"/${P}-foo.patch \
"${FILESDIR}"/${P}-bar.patch \
"${FILESDIR}"/${P}-fatcow.patch
there is no standard here (i think they're more or less equally common) and
maintainers are free to pick what they like best. arguing about the merits
between the two above styles is a waste of everyone's time. go fix some bugs
instead you lazy wankers :P.
the one thing Samuli is correct about though and largely has nothing to do
with style is that the patch itself needs to have all the relevant
information. doing the following is wrong:
# here i explain what the patch is for #12351
epatch "${FILESDIR}"/${P}-bar.patch
(and the bar patch contains only the diff)
rather than rehash why you're wrong if you do the above, please read:
http://dev.gentoo.org/~vapier/clean-patches
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation
On Saturday 08 October 2011 18:57:23 James Cloos wrote: > > "SV" == Sven Vermeulen writes: > SV> - Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds > SV> from that version onwards should not be needed > > That is not generally true. > > I use gcc-4.5 as my system gcc, but mostly use 4.6 when building things > outside of portage. I still run into compilation errors with C++ which > go away if I compile said code with 4.5. > > GCC’s C++ abi is only *mostly* forwards compatible, not *entirely*. i think you're hitting a bug that has nothing to do with the ABI compatibility. i.e. Bug 297685. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
On 10/12/2011 06:30 AM, Steven J Long wrote:
> Michał Górny wrote:
>> I don't think that passing multiple files to epatch actually improves
>> readability. Simple example:
>>
>> # bug #123456, foo, bar
>> epatch "${FILESDIR}"/${P}-foo.patch
>> # bug #234567, baz bazinga blah blah
>> epatch "${FILESDIR}"/${P}-baz.patch
>>
>> With multiple arguments, you can't put comments in the middle.
>>
> ++ It's also a lot easier to remove the single patches when they're no
> longer needed.
Removing an 'epatch foo' line is easier than 'foo \' ? You are kidding,
right?
> In the context of configuring, building and installing a
> package, the extra overhead is miniscule, whereas the above is *much*
> easier to maintain.
Based on what argument?
Having the comments inside the patch allows everyone, including
_upstreams_ straight up see what's it for and link to the bug it's
coming from. Where as keeping them in ebuilds makes it Gentoo specific,
which is not what we are about.
Re: [gentoo-dev] Re: Lastrite: media-gfx/pngcrush
В Втр, 11/10/2011 в 19:10 +0300, Samuli Suominen пишет: > > Samuli pretends here to act as a part of QA team (although he is not). > > Actually even whiteboard of stabilization bug tells #at _earliest_ 17 > > Oct" and thus there is really no sign for rush. This is the case where > > QA should voice and either explain why fast stabilization of libpng is > > so important or stop policy breakage. That said it became really common > > to break our own policies (with no attempts to amend policy). > > full stop. [snip history] > what does this has to with qa@ team? The only bodies that are allowed to avoid policies in Gentoo are QA and security teams. Since this issue has nothing to do with security the only option left is QA. > so no, you don't get to use this as anykind of weapon against me or > anyone else involved. Sorry, I never wanted to touch any weapons and I really appreciate your efforts. You really do tremendous job for Gentoo. But this is not the first thread where I ask you same question: what is the problem to follow policy? If it was a mistake what's the problem to sorry and update mask interval. If not... What will happen if you keep hard masked package for 30 days instead of 14? How this will affect libpng stabilization? The only thing that changes - we will have 56 non-development related mails less in our mailboxes. -- Peter.
Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote: > Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto: > > - The fix_libtool_files.sh command is now part of the toolchain > > eclass, so > > > > doesn't need to be ran by users anymore > > Moreover, that should only be needed for very old installs: libstdc++.la > that caused the trouble in the first place hasn't been around for over > an year (maybe two? I lost count), and the auto-fix of .la files in > recent Portage versions make it even less necessary. well, that's not entirely accurate. like libtool, now that we've dropped libstdc++.la, the majority of issues have "gone away". but we still install .la files for the other (much more infrequently used) internal gcc libraries. although this might be something we want to address in gcc. i was fine with dropping the libstdc++.la even though it listed things in dependency_libs because the only correct way (imo) to link C++ code is with `g++`. using `gcc -lstdc++` is not supported. i think cases can be made for the other internal gcc libraries: - libgomp.la: build/link with -fopenmp, not -lgomp - libgfortran*.la: build/link with `gfortran`, not `gcc -lgfortran` - libgcj*.la: build/link with `gcj`, not `gcc -lgcj` - libobjc.la: use -lobjc to link, but dependency_libs='' - libffi.la: use -lffi to link, but dependency_libs='' - libmudflap.la: build/link with `gcc -fmudflap`, not `gcc -lmudflap` - libgij.la: build/link with `gij`, not `gcc -lgij` - libquadmath.la: only used by fortran, and dependency_libs='' -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wednesday 12 October 2011 09:26:12 Rich Freeman wrote: > On Wed, Oct 12, 2011 at 12:40 AM, Walter Dnes wrote: > > Forking udev is probably not an option. The udev lead developer is a > > Redhat employee, and his direction seems to be to drag everybody in > > Redhat's direction. Our community doesn't have Redhat's billions. > > We should note that RedHat is already spending their billions to make > dracut smarter, and if initramfs is good enough for RHEL then it > should be good enough for us if somebody just has to have /usr on a > separate device and needs some of the fancier udev rules to work on > boot. For those who don't need dracut there was already a stated > desire to provide a simplified initramfs. And, for less complex > setups, you don't need it at all. i don't think this logic is that great. RHEL/Fedora do a lot of things that they consider desirable but which are simply their opinion on the topic. for a while there, they pretty much forced LVM down everyone's throat during the install. it's been a while since i last installed/maintained those distros (thankfully), but their initramfs setups were always way more flaky than they should have been and fairly difficult to recover from. the "firstboot" idea is another great example of "things not fully thought through ahead of time". systemd is a good choice for some, but its desire to be Linux-specific and require recent kernels is a limitation. if you want to use initramfs on your system, you certainly can. if you want to do lvm/whatever rootfs, then feel free. if you want to run systemd, np. you want to add bloat with firstboot, by all means. but a Gentoo system will not require any of these things (unless you choose to customize your own system in such a way) regardless of how much money other distros throw at their own ideas. note: i'm not advocating dropping udev by default as i think it's completely unrealistic, and unlike the other projects mentioned, has been widely adopted across pretty much all distros. it also doesn't really address the *underlying* problem: package rules that require /usr to be mounted. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Sunday 02 October 2011 16:40:18 Chí-Thanh Christopher Nguyễn wrote: > Another example from the X.org packages, installing the proprietary > ATI/NVidia drivers will cause downgrades for xorg-server on ~arch > systems. Nobody in his right mind is proposing to treeclean them because > of this. yes, this does cause issues for some, but i think we're willing to make exceptions when they're justified -- life isn't black & white after all. the user base is fairly large enough to accept the downsides here. it's also proprietary, so we don't have nearly as much chance of getting it fixed. conversely, i'd put forth that qutecom does not have a user base size to justify causing misbehavior (too bad we don't have installed package statistics to provide some data here), and the fact that it's open source means it should get fixed or get punted. otherwise, Rich summed up things nicely in his later post. > >> Not by surprise treecleaning of packages. > > > > as you were already shown, this wasn't really a surprise. it went > > through the normal announce process, albeit not the normal 30 day grace > > period. > > The whole process was a surprise to me because the masking and > treecleaning happened while I was on 20 days of devaway. I leave the > away message for a day more in case anyone wants to verify. > > And it was a surprise treecleaning because the mask and policy said 30 > days, but the removal happened before the 30 days were over. the use of "surprise" can be flexed here. yes, you were surprised it was punted, but that doesn't make it a "surprise treecleaning" to the larger community. the package has had an open bug for a while, was announced that it was going to be removed, and was cleaned ~17 days after the announcement. > The second time the package was removed was even without mask or > announcement. well, it shouldn't have been re-added in the first place > >>> further, when the newer version gets stabilized and then the older ones > >>> dropped, what then ? your package is broken. > >> > >> Yes, when the older one is dropped _that_ would be reason for > >> masking+removal. However I have not seen any plans of doing so. Actually > >> the current amd64 stable 2.6 versions are 35, 26 and 10 months old > >> respectively, I wouldn't expect that to happen any time soon. > > > > sorry, but that's irrelevant. the lack of tree-cleaning is more due to > > missing automatic generation of ChangeLog files. but if this is going to > > be a sticking point for you, i can simply clean the tree as soon as we > > get newer stable versions. > > If the old versions and reverse dependencies are dropped in accordance > with > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#do > c_chap7 then I won't complain. i would not consider broken packages (i.e. qutecom) in the tree as basis for retaining the old versions of linux-headers. your package is already broken, and removing the linux-headers would break that depgraph. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 1:49 PM, Ciaran McCreesh wrote: > On Wed, 12 Oct 2011 23:00:23 +0530 > Nirbheek Chauhan wrote: >> Then please continue with udev in package.mask and kindly stop trying >> to impose your workflow on the rest of the world. > > Isn't the point here that the desktop / GNOME OS guys are trying to > impose their deep integration, tight coupling workflow upon the rest of > the world? So, Gentoo is about choice and empowering the user, so I think that if somebody wants to offer patches that allow mdev to work better without adversely affecting udev use then I'd encourage devs to accept those patches. However, if Gentoo aims to make Gnome/KDE difficult to deploy with the default configuration we'll be shooting ourselves in the feet. I think a lot more people run KDE/Gnome on Gentoo than run Gentoo with /usr not on root but who are unwilling to run an initramfs. Rich
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan wrote: > Then please continue with udev in package.mask and kindly stop trying > to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 6:39 PM, Walter Dnes wrote: >> Goodbye desktop users then. >> >> We recently dropped HAL. Now all the magic that was done by HAL (and >> required udev anyway) is done through udev directly. > > My system worked just fine before HAL was introduced, thank you. I > always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask > and my system continued to work just fine, thank you. Given the great > HAL fiasco, the fact that HAL has been incorporated into udev is yet one > more reason for dropping udev . > Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. This thread is a waste of time. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 12 Oct 2011 09:09:49 -0400 "Walter Dnes" wrote: > > Goodbye desktop users then. > > > > We recently dropped HAL. Now all the magic that was done by HAL (and > > required udev anyway) is done through udev directly. > > My system worked just fine before HAL was introduced, thank you. I > always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask > and my system continued to work just fine, thank you. Given the great > HAL fiasco, the fact that HAL has been incorporated into udev is yet > one more reason for dropping udev . Thanks for your insight on the topic. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 6:09 AM, Walter Dnes wrote:
>> Goodbye desktop users then.
>>
>> We recently dropped HAL. Now all the magic that was done by HAL (and
>> required udev anyway) is done through udev directly.
>
> My system worked just fine before HAL was introduced, thank you. I
> always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask
> and my system continued to work just fine, thank you.
This is not about *your* system, it's about the general Gentoo
community systems. And in most cases, the functionality that mdev
provides is not even a fraction of what udev can do, like it or not.
I have a pair of bluetooth headphones; I turn them up and set them to
pair with something, and gnome-shell in GNOME 3 right away asks me if
it's OK to pair with them. I say yes, and the headphones are
immediately available in the desktop; thanks to PulseAudio, I can
transfer all my apps (or only some of them) to the headphones, without
even needing to pause the streams.
All of this without a single modification to a config file. It just
works. And that is thanks to udev (among several other pieces of the
stack).
mdev is designed for embedded systems (like busybox). By design it
cannot handle of the cases that udev handles, and so it is not suited
for a general purpose distribution like Gentoo. If you wan to try to
use it, that's your right of course. But don't ask the Gentoo devs to
do the work for you; do it yourself. And be aware that anyway the devs
will choose to stick with udev (like many have already said), because
they have to think about the general case, not an arbitrary particular
case.
Just the .02 ${CURRENCY} from an old Gentoo user happy with systemd,
dracut, udev, dbus, GNOME 3, and other really cool new technologies.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On 10/12/2011 07:10 AM, Rich Freeman wrote: > That leads me to another concern. The defaults should be the safe > options, and the options should be to make the actions less safe. > > In my thinking the most conservative options right now are either > emerge -uDN world or emerge -uDN --with-bdeps=y world. > > I'd almost prefer to see that -D, -N, and --with-bdeps go away, and > that instead we add options like --shallow, --ignoreusechanges, and > --without-bdeps be added (ok, those are lousy names but you get the > picture). The default without any option should be to do the "right" > thing for most people, and specifying an option should be to make the > system do something less conservative. > > I just think about Debian where you tell people run "apt-get update" > and then "apt-get upgrade" and that is it. Their typical behavior is > not specifying anything and you get everything updated. With Gentoo > the equivalent is "emerge world" but when you do that you potentially > miss a lot of stuff. > > (And I realize the --with-bdeps part of this is debatable.) How about if we add a `emerge --upgrade` target that is analogous to `apt-get upgrade`? If we hide the new defaults behind a target like --upgrade, rather than change the defaults globally, then it allows people's existing scripted and habitual emerge commands to continue to work in a backward compatible manner. -- Thanks, Zac
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Tue, Oct 11, 2011 at 7:27 PM, Duncan <1i5t5.dun...@cox.net> wrote: > That's probably why there's no mention in the docs other than the portage > manpage. Now that we have swift back, he's applying some much needed > attention to the docs tree and its coming back into shape. =:^) I definitely agree that the docs probably need a little improvement. Our docs should suggest to users the safest behavior for somebody who doesn't know what they're doing. That is, the behavior that leads to the fewest bug reports or list posts or general complaints. By all means give them less safe alternatives with some educational material (we empower our users). However, the first thing presented should be the safest default behavior. That leads me to another concern. The defaults should be the safe options, and the options should be to make the actions less safe. In my thinking the most conservative options right now are either emerge -uDN world or emerge -uDN --with-bdeps=y world. I'd almost prefer to see that -D, -N, and --with-bdeps go away, and that instead we add options like --shallow, --ignoreusechanges, and --without-bdeps be added (ok, those are lousy names but you get the picture). The default without any option should be to do the "right" thing for most people, and specifying an option should be to make the system do something less conservative. I just think about Debian where you tell people run "apt-get update" and then "apt-get upgrade" and that is it. Their typical behavior is not specifying anything and you get everything updated. With Gentoo the equivalent is "emerge world" but when you do that you potentially miss a lot of stuff. (And I realize the --with-bdeps part of this is debatable.) Rich
Re: [gentoo-dev] Re: Lastrite: media-gfx/pngcrush
On 10/12/2011 04:44 AM, Ryan Hill wrote: > On Tue, 11 Oct 2011 17:52:42 +0100 > Markos Chandras wrote: > >> Seems like none of you ever bothered to read the bug about pngcrush >> and what was discussed there. It is getting a little bit of a habit to >> escalate minor problems to flames in Gentoo. So feel free to >> write/say/do whatever you want(maybe add it to system@ set cause you >> all seem to love this package very very much). I am done with this >> thread since you all enjoy spreading flame bites around without even >> spending 1' to read the bug. > > I've read this whole thread and found that if we remove your posts then there > would have been no flaming whatsoever. > > I would call baseless claims and accusations flaming. Or an poor attempt of it. Still waiting for an apology from one or two persons involved in this thread, and hwoarang isn't one of them.
Re: [gentoo-dev] Build dependencies and upgrades.
On Tue, 2011-10-11 at 23:10 -0700, Zac Medico wrote: > On 10/11/2011 10:59 PM, Graham Murray wrote: > > Zac Medico writes: > > > >> On 10/11/2011 10:28 PM, Mike Gilbert wrote: > >>> Francisco raised a possibly valid point in his original message: though > >>> packages may not be currently used for anything, but they could contain > >>> un-patched security flaws. > >> > >> If they contain something that's accessed at runtime, then they should > >> be in RDEPEND or PDEPEND, no exceptions. > > > > But is it not possible that the flaw in the build-time dependency causes > > an insecurity to be built into the dependent package and that both have > > to be rebuilt as part of the security fix? > > For statically linked libraries, yes. However, --with-bdeps=y alone > won't help you with that. You'll also have to enable > --rebuild-if-new-rev=y in order to automatically rebuild the reverse > dependencies of the statically-linked library. And also for source code generators such as flex, bison, autoconf, cmake, et cætera -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur http://common-lisp.net/project/iolib/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 12:40 AM, Walter Dnes wrote: > Forking udev is probably not an option. The udev lead developer is a > Redhat employee, and his direction seems to be to drag everybody in > Redhat's direction. Our community doesn't have Redhat's billions. We should note that RedHat is already spending their billions to make dracut smarter, and if initramfs is good enough for RHEL then it should be good enough for us if somebody just has to have /usr on a separate device and needs some of the fancier udev rules to work on boot. For those who don't need dracut there was already a stated desire to provide a simplified initramfs. And, for less complex setups, you don't need it at all. My concern with something like dropping udev is that it would make us different from every other desktop distro out there. I'm not aware of any distro packaging Gnome/KDE without udev. Not having Redhat's billions to me is a good reason to try to do things the same way that Redhat does them - so that we're not re-inventing the wheel. Gentoo is still a fairly meta distro and if users want to remove udev they probably can do it without a great deal of hassle if they don't want hot more hotplugish experience and don't use the big desktop environments. It just doesn't make sense to make that a default. In the same way I don't mind a list of CFLAGS that spans 3 lines but I'd never advocate putting that into the default make.conf. Rich
Re: [gentoo-dev] Suggestion for getting rid of udev
On Tue, Oct 11, 2011 at 10:05:15PM -0700, Zac Medico wrote > Are you aware of the simple linuxrc approach that I suggested here? > > http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml Thanks for the pointer. I've got a spare box kicking around that I'll try this on. I really do want it to work. -- Walter Dnes
Re: [gentoo-dev] Suggestion for getting rid of udev
> Goodbye desktop users then. > > We recently dropped HAL. Now all the magic that was done by HAL (and > required udev anyway) is done through udev directly. My system worked just fine before HAL was introduced, thank you. I always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask and my system continued to work just fine, thank you. Given the great HAL fiasco, the fact that HAL has been incorporated into udev is yet one more reason for dropping udev . -- Walter Dnes
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 05:32:05AM +, Nathan Phillip Brink wrote > You can already try out what using mdev instead of udev is like in > Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use, > remerge busybox. You must be sure to be using busybox-1.92.2 or later > for bug #83301. Did you mean busybox-1.19.2? That's the latest ebuild in /usr/portage, and it's still ~amd64 (~everything for that matter). > # rc-update add mdev sysinit > # rc-update del udev sysinit > > But be 'ware that this isn't guaranteed to provide a successful boot > ;-). Thanks for the idea. I have a spare box kicking around that I can try it on. -- Walter Dnes
[gentoo-dev] last rites: games-roguelike/fargoal
+# Michael Sterrett (12 Oct 2011) +# Upstream has moved to commercial development and +# the latest version doesn't work with newer allegro. +# Masked for removal on 2011 +# bug #369271 +games-roguelike/fargoal
Re: [gentoo-dev] Re: Lastrite: media-gfx/pngcrush
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/12/11 02:44, Ryan Hill wrote: > On Tue, 11 Oct 2011 17:52:42 +0100 Markos Chandras > wrote: > >> Seems like none of you ever bothered to read the bug about >> pngcrush and what was discussed there. It is getting a little >> bit of a habit to escalate minor problems to flames in Gentoo. >> So feel free to write/say/do whatever you want(maybe add it to >> system@ set cause you all seem to love this package very very >> much). I am done with this thread since you all enjoy spreading >> flame bites around without even spending 1' to read the bug. > > I've read this whole thread and found that if we remove your posts > then there would have been no flaming whatsoever. > > I was dragged to this thread because people decided to make this public and have some fun trolling around instead of following the official policy which is either to contact QA or report me to devrel for messing around with their (the package belongs to graphics@ ONLY, got their approval before I do anything) packages. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOlT+pAAoJEPqDWhW0r/LCN3AP/1leeYdKCgEiE+XBG2OhdTg7 eGS/FTcv0P3/0o80ip2MtDzspNJ8sRsw0jYb8/WcgrOfzZ2CUsPQlEd0oo6bQwgU 04mcnzB7lFlBdJvC7n1AHG459q0v+aSj9iQnh2Xn0Adij9v/STab7mF7k2DGoxE/ muIQB2xEATNVSztj8Hk4dGR0eU7PWRpUY0tr6saY1pUPlMdj2CLPzhttsO2yViat JuC4FqprQVbMLz/ws70tFOh35Al54xJdN0xVluOemRfAngvj3CowAAXDbdAcbAZq gYXIWW49tyGPUqqe866/siHdpr6wq2HCP1XHZGuCoqqjt2q+n/aocoSpNovPyk04 lvnuZetQ3JDV/9X9aLt6X61/Vz4KeUAfD994s60oitXykh4CkQWgJQeTYBWeXq7f UIt6EQiPKdIGzfFG80ffNFR403BisW+DyS8wS2LPDcCoKK28iitaVhD8rVjdgrAs spU2HQRBYoNuBPHGVwKsw6d1dFANDsLqV21V6/R2gNPVIhsoCW50O+k9amTdG7zA TprqRPidYgMgjfjMkKJ1P8m7PIEIIe2tI4yxNc6BvpXUxxAgigAGTrv0Pw5+RmHS RHi2IaK3y0tv6JyGy4OmaUUY9FItyLZQWj+h5hKNWQuMTJhQwnEzCiYf6abKarlk 5W1Bu+z1UCLbvHwimevh =3UKE -END PGP SIGNATURE-
Re: [gentoo-dev] Suggestion for getting rid of udev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/12/11 05:40, Walter Dnes wrote: > Hi all > > The other option is to drop udev entirely. As an example, I > suggest looking at Alpine Linux http://alpinelinux.org/ It's a > lightweight server-oriented distro. It uses busybox's mdev instead > of udev, and some other mdev substitutes in place of standard > packages. It uses openrc. Furthermore, "previous versions of > Alpine were based on Gentoo" as per > http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package so > there should be no problem with us borrowing back from Alpine. > This is a joke right? All the desktop "infrastructure" depends on that. Are you suggesting to make Gentoo an embedded/server only distro? - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOlTzUAAoJEPqDWhW0r/LC2rAQAI9+GgYyUZqOPcL8dXa/oDJP 8zAn1w6aJfYW1MJOLlFxx48pYC4G64xencGKUGMyCKdwNGHxEYIAnLIB1fjEIwKz c5gFWjgZyOG1etDJblYtHUEdUDzqVz1EpFmyt/ASxJRsaCOTFv0NyG26tw4cumBT Gpkf/qSwENnSNo+HlMdjlqUzioiSa9afZe/4IkZRKH8NL3UOXEd8Ud605L5YDJoC uErGRamsdRP4XuNU9oB230QVHy2/7vsxZhtDJ3d22MHECF9rpdPfgmZ2zAmUe3ut /NPau8xZG/1udf6REcIZHcg8ERXMl5hO38GuYoyO8/gtxcLLcFaDVMzTzLdaoWg/ H6rB9HhbhZYy9049sPtA2VP+jfCCdriLWpi6G1/XyotgK2e0zgGUIATPskf+Ge5N Nb20Mr2fEbqTgd5SdcPDM4dq0y8at1u8WaAJDfvvy8mvEwwX42GZJK2wsMdY0x/k G85zKQm7pZNnk0V17czUcnkbO+D8Ormw/wImMLrA9KidmC2FbHgPj4qOYAR6Dsso 0i6gvgCai+y0cymTnSYM99xo4KAU/ZKcqGsNtbUKaJ1IwR3tPgGLwHb70NPZF3e5 ssxtG4Su4wo2WGfMfNcPgjTA9hbYW2JGM2s4TH9+V7BVv+wW9b7osyiplJ3f0X7l Kq7yoCCF499m/BMoTgot =cicu -END PGP SIGNATURE-
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 12 Oct 2011 00:40:23 -0400 "Walter Dnes" wrote: > The other option is to drop udev entirely. As an example, I suggest > looking at Alpine Linux http://alpinelinux.org/ It's a lightweight > server-oriented distro. It uses busybox's mdev instead of udev, and > some other mdev substitutes in place of standard packages. It uses > openrc. Furthermore, "previous versions of Alpine were based on > Gentoo" as per > http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package so there > should be no problem with us borrowing back from Alpine. Goodbye desktop users then. We recently dropped HAL. Now all the magic that was done by HAL (and required udev anyway) is done through udev directly. Dropping udev = dropping it all. This means that no *kit would work anymore, xorg will require explicit configuration, bluez may not work anymore as well. -- Best regards, Michał Górny signature.asc Description: PGP signature
