Re: [gentoo-dev] RFC: Last rites for $package ...
> Or you haven't talked to me or Beandog at all; since he has been > working on this a while (now with upgraded tools!). what i'd like to see is a system, to which one would give a package name, which then handles the removal (almost) automatically. that way devs would have an easier time actually removing some cruft and you guys would be freed from typing the same stuff over and over. this system could be responsible for sending the out last rites mails, masking the packages in package.mask etc... enrico would get his database for free, both listing those that are pending removal as well as a history of removals including the reason plus a pointer to the corresponding bug... don't know if that is what you are aiming at, but currently the process of removing a package is a true chore and i admire your dedication to it. (a big THANKS btw) regards bangert pgpF8znVcu4fw.pgp Description: PGP signature
[gentoo-dev] last rites for www-servers/spawn-fcgi and dev-libs/localizer
the packages www-servers/spawn-fcgi and dev-libs/localizer where originally added as support for lighttpd. in the meantime lighttpd provides the same functionality and no version of lighttpd depends on these packages anymore - in fact, they block. furthermore no other package has ever depended on these. masking them now - removal in 30 days. please direct objects, comments and whining to https://bugs.gentoo.org/show_bug.cgi?id=149599 thanks bangert pgpedK6QLAwP7.pgp Description: PGP signature
Re: [gentoo-dev] Profile masking and profiles package.mask
On Sat, 30 Sep 2006 06:40:07 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: | This is a discussion to follow up bug #149508 [1]. https://bugs.gentoo.org/show_bug.cgi?id=149536#c4 -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Profile masking and profiles package.mask
Ciaran McCreesh wrote: > On Sat, 30 Sep 2006 06:40:07 +0200 "Diego 'Flameeyes' Pettenò" > <[EMAIL PROTECTED]> wrote: > | This is a discussion to follow up bug #149508 [1]. > > https://bugs.gentoo.org/show_bug.cgi?id=149536#c4 If I were you, I'd rather not mention that bug. Really don't see what you are trying to say here with that link. Plus kindly note > *Important: do NOT use this thread for considerations on QA behaviour, > this is NOT what this post is thought for.* in the original mail. So now if you could move to the points mentioned by Flameeyes in his email, it would be really useful. Additionally, it would be nice if these discussions involved concerned arches and were not done ex post in future cases. Thanks. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Profile masking and profiles package.mask
On Sat, 30 Sep 2006 14:37:59 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: | Additionally, it would be nice if these discussions involved | concerned arches and were not done ex post in future cases. Uh, Jakub, part of the design of the devmanual was that it would be possible for the right people to update it to codify existing practice without arguments from the peanut gallery who like to claim that because they've been getting away with it it's allowed. See also conflicting USE flags and static metadata requirement... This isn't a change, it's a documentation of how things are. You've already wasted too much of other people's time on this. You're not getting any more of mine. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Profile masking and profiles package.mask
On Saturday 30 September 2006 14:25, Ciaran McCreesh wrote: > https://bugs.gentoo.org/show_bug.cgi?id=149536#c4 You bring up the point that you don't take any argument? The argument is still valid, nobody provided a reason for the change. I don't take anybody's word as a granted, so I don't care if Mike thinks the change is fine. I want some reasons. If you want to waste even more time, continue this way. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpxTna6Qastg.pgp Description: PGP signature
Re: [gentoo-dev] Profile masking and profiles package.mask
On Sat, 30 Sep 2006 14:40:44 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: | On Saturday 30 September 2006 14:25, Ciaran McCreesh wrote: | > https://bugs.gentoo.org/show_bug.cgi?id=149536#c4 | | You bring up the point that you don't take any argument? | | The argument is still valid, nobody provided a reason for the change. It is not a change in policy. It's a codification of existing practice. Unfortunately, since most of this stuff didn't get written up years ago when it happened, not everyone is aware of said practice and so a few profiles from developers who weren't around at the time don't honour it. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] OT noise (Was: Profile masking and profiles package.mask)
Ciaran McCreesh wrote: > On Sat, 30 Sep 2006 14:37:59 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > | Additionally, it would be nice if these discussions involved > | concerned arches and were not done ex post in future cases. > > Uh, Jakub, part of the design of the devmanual was that it would be > possible for the right people to update it to codify existing practice > without arguments from the peanut gallery who like to claim that > because they've been getting away with it it's allowed. See also > conflicting USE flags and static metadata requirement... This isn't a > change, it's a documentation of how things are. You still didn't bring in any argument, why am I not surprised? Plus don't pull in unrelated stuff into this debate. Plus getting devmanual changed on the fly and using it as a point in discussion five minutes later is not an acceptable practice for anyone who wants to debate things seriously. > You've already wasted too much of other people's time on this. You're > not getting any more of mine. Please, take this, your peanut galleries and other junk off-list, noone's interested. Thanks. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Profile masking and profiles package.mask
On Saturday 30 September 2006 15:14, Ciaran McCreesh wrote: > It is not a change in policy. It's a codification of existing practice. The behaviour of portage seems to ask you to differ on this. But you also seem to lose your point. I'm discussing the change of behaviour with respect to portage, not the change to devmanual. Why am I not questioning the change to devmanual? Because the bug there is just required by Plasmaroo who act as a proxy between QA and devmanual itself, and thus not up to discuss anymore than a CVS commit. But, the behaviour change for profiles (that currently, for bug or design, acts in a different way than your "existing practice" suggest) is up to debate, as I've found a few reasons not to back up such a change, and rather stick with the current behaviour. So, again, why should we change the behaviour, other than to fullfill your request? -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpZcqbRShoC1.pgp Description: PGP signature
Re: [gentoo-dev] Profile masking and profiles package.mask
On Sat, 30 Sep 2006 06:40:07 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: > This is a discussion to follow up bug #149508 [1]. > > The bug points to a behaviour change in handling of the profiles > file, that, in my opinion at least, needs to be discussed, as there > are profiles relying on the old behaviour (Gentoo/FreeBSD's to state > some). > > For what I can tell, the current behaviour has the advantage of > providing a different masking reason for packages that are *needed to > some version* for the profile to be complete, and for packages that > are know not to work on a profile. [snip] Personally I dislike the masking aspect of the packages file, as it's mostly redundant, problematic in some cases (e.g. requring a specific gcc versions masks all older gcc versions implicitly) and I think having a single file to serve two purposes (set "system" and masking packages) is crappy. Also overriding profile masks (yes, this is valid sometimes) isn't intuitive either as there is no "unmask" feature. This isn't connected to the mentioned bug at all btw. However I understand your reasoning about unmasking things with package.unmask, the question is how common that use case would be? Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] OT noise (Was: Profile masking and profiles package.mask)
seriously jakub, stop responding ... you have nothing technical to offer to the issue at hand let the people who work on portage handle it -mike pgpiPg7pzkzw4.pgp Description: PGP signature
Re: [gentoo-dev] OT noise (Was: Profile masking and profiles package.mask)
Mike Frysinger wrote: > seriously jakub, stop responding ... you have nothing technical to offer to > the issue at hand > > let the people who work on portage handle it > -mike Eh, the whole technical point here is that paludis behaviour differs from portage (and differs from pkgcore, FWIW). So, hiding the inconsistency via altering the profiles doesn't change anything. Plus, the point of the bug's flame fest was that bugzilla is not a proper place to request such behaviour changes, and definitely not a reason for QA to mess with the profiles. Sticking the stuff in package.mask won't make the inconsistent behaviour vanish in any way, it will just hide it. So, I'd kinda appreciate if concerned folks (including portage and relevant affected arches) were involved in this discussion, instead of sneaking the changes in under QA disguise. Thanks. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OT noise (Was: Profile masking and profiles package.mask)
On Saturday 30 September 2006 13:02, Jakub Moc wrote: > Eh, the whole technical point here is that paludis behaviour differs > from portage (and differs from pkgcore, FWIW). the technical point is what is the expected behavior of the packages file ... seems silly to duplicate masking across two different files what have you offered to this discussion ? nothing: so sit back and let the people who actually work on this stuff handle it -mike pgpICI92uDive.pgp Description: PGP signature
Re: [gentoo-dev] OT noise (Was: Profile masking and profiles package.mask)
Am Samstag, 30. September 2006 19:02 schrieb Jakub Moc: > Mike Frysinger wrote: > > seriously jakub, stop responding ... you have nothing technical to > > offer to the issue at hand > > > > let the people who work on portage handle it > > -mike > > Eh, the whole technical point here is that paludis behaviour differs > from portage (and differs from pkgcore, FWIW). This has little to do with why this change to the devmanual has been done. > So, hiding the inconsistency via altering the profiles doesn't change > anything. Plus, the point of the bug's flame fest was that bugzilla > is not a proper place to request such behaviour changes, and > definitely not a reason for QA to mess with the profiles. Sticking > the stuff in package.mask won't make the inconsistent behaviour > vanish in any way, it will just hide it. It is not a behaviour change imho. The "packages" file changed its meaning subtly after introducing cascading profiles. As ciaranm already pointed out: It is not meant to mask "<"-like versions anymore. It's meant to - Describe the system package set - Define which versions are _at least_ needed for a profile. > So, I'd kinda appreciate if concerned folks (including portage and > relevant affected arches) were involved in this discussion, instead > of sneaking the changes in under QA disguise. Release engineering arch coordinators, which happen to be the people who maintain the profiles below default-linux/ for their relevant arches, have been CCed and Chris already stated that he forgot/didn't realize to fix this problem for no-nptl/2.4's package.mask. Jakub: Please reevaluate the behaviour you showed on both the bug and this mailing list. I for one don't consider it anywhere near appropriate. This shall be no offense, just a comment in regard that you can do better. Danny -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Profile masking and profiles package.mask
On Saturday 30 September 2006 00:40, Diego 'Flameeyes' Pettenò wrote: > For what I can tell, the current behaviour has the advantage of providing a > different masking reason for packages that are *needed to some version* for > the profile to be complete, and for packages that are know not to work on a > profile. isnt that the point of putting a comment above a mask ? # this package wont work on this profile bar/foo # these versions are needed in this profile =cat/meow-1* > Example: Gentoo/FreeBSD relies on profiles masking for > sys-freebsd/freebsd-* packages, as you should *not* use freebsd-lib 6.2 on > the 6.1 profile, for instance; AMD64 no-multilib profiles use package.mask > to mask packages that are known to be broken on that profile. > > In case of Gentoo/FreeBSD, it also means to have 3x entries for forcing > versions of the packages on users. i dont get it ... if you mask the versions in package.mask, why do you need a packages entry at all ? fbsd/packages:sys-freebsd/freebsd-mk-defs fbsd/package.mask: fbsd/6.1/packages: fbsd/6.1/package.mask:>=sys-freebsd/freebsd-mk-defs-6.2 fbsd/6.2/packages: fbsd/6.2/package.mask: > Another reason I'd see for retain the current behaviour is that users are > known to unmask stuff via package.unmask to try "might-be-broken" versions. so what you're arguing is that we should retain the existing behavior because users might try to unmask something properly ? trying to protect users from shooting themselves in the foot by making the profile behavior more complicated is a waste of time -mike pgpFy0pw8RGlW.pgp Description: PGP signature
Re: [gentoo-dev] OT noise (Was: Profile masking and profiles package.mask)
Mike Frysinger wrote: > On Saturday 30 September 2006 13:02, Jakub Moc wrote: >> Eh, the whole technical point here is that paludis behaviour differs >> from portage (and differs from pkgcore, FWIW). > > the technical point is what is the expected behavior of the packages file ... > seems silly to duplicate masking across two different files > > what have you offered to this discussion ? nothing: so sit back and let the > people who actually work on this stuff handle it > -mike It's not duplicating, exactly the opposite. Sticking the stuff into per-profile package.mask is duplicating the information, because portage handles it just fine without any such duplication (that's the whole point of Flameeyes' original mail). Now if you want to change this, nothing wrong with that except when someone goes moaning to bugzilla and QA starts messing with the profiles without any discussion. This is not a QA issue. If you want to change this behaviour, go provide some reason why it should be done and either you persuade the folks involved or not. In addition, those two kinds of masking (masked by profile vs. masked by package.mask) are not duplicating each other, they behave quite differently. For the rest, sorry but replies as "stop wasting everyone's time" or "sit back and let people who actually work do it" as not much polite and don't offer anything to this discussion either. Thanks. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] How default route should be set by pppd
Hi fellow devs, I discovered that ppp-2.4.4 set a default route without a gateway. It is totally fine from IP routing point of view (the simple fact that route is through the point-to-point link is enough to know the next hop), except that openswan's %defaultroute need a default gateway in order to work. I'm about to apply a patch that would reverse to the old way of setting the default route. Any objections? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC about another *DEPEND variable
On Wednesday 27 September 2006 03:54, Brian Harring wrote: > On Wed, Sep 27, 2006 at 02:24:41AM -0400, Mike Frysinger wrote: > > as i said, if you have changed ABI without an ABI bump, then the upstream > > package maintainer is screwing everyone who uses the package, not just > > Gentoo ... so perhaps we should be talking to them to get the situation > > resolved for all consumers, not just Gentoo > > Happens however; afaik, we also weren't monkey patching ssl in the > past to preserve the abi either so it still is valid (although rare if > upstream is behaving) scenario. we've never monkey patched ssl so i dont really know what you're referring to > > > Bleh, this is getting back to exactly my point that it's unbounded > > > resolution. To support this, every step of execution would require > > > scanning for dangling nodes to punt; aside from invalidating -p's > > > output it *still* is a collision-protect hit. > > > > when the package upgrade detects an ABI change you recalculate the > > packages that need to be rebuilt ... > > Reiterating, this screws over any form of up front calculation; > dialup users/per minute connections can't rely on emerge -f to > actually fetch all involved sources, -p results ain't guranteed > valid, parallelization must now lock at each threads merge on the off > chance a recalc is forced. it does indeed prevent full up front calculation. we can always make the behavior configurable; revdep on the fly or allow people to break it up. the key being that their system will still continue to function as the ABI lib has been preserved automagically > > dangling nodes get recorded in the new package and considering these old > > files are not detrimental to the health of the system, you can do such a > > cleanup once at the end of the emerge > > It's not orphaning files, but your scheme doesn't work for any form of > interruption; failed builds, user intervention, etc, they all can > leave the lib stuck in the new contents. huh ? i outlined in a previous e-mail how by simply ordering the operations sanely, there is no race condition > Dealing with that possibility means the manager has to maintain on > disk a list of the refcount of each dangling libs to decrement, > unmerge has to modify said list, etc. which is already being done in the NEEDED file ... funny how unpainless it is to generate that file > > > It also involves changing vdb nodes from "installed and usable" to > > > "installed/usable" or "lingering" > > > > no ... the old versions get merged into the new one as their existence is > > purely hidden > > How exactly are they going to be hidden? A new file? If so, > backwards compatibility for vdb for transitioning in such a support > has to be addressed. purely hidden from the standpoint of any new package trying to use it ... since you're only installing the runtime ABI library, you cannot link against it or utilize it any way other than existing files > > > Tracking BINCOMPAT should *not* be that hard. > > > > it's one more thing to keep track of and considering all of the > > possibilities i outlined, a single maintainer can easily lose his sanity > > ... or you force wasted rebuilds on people when it's only needed in some > > circumstances > > How exactly is this forcing wasted rebuilds? You're stating that > maintainers are going to bump it willy nilly. As I said, it is a key > that would be bumped *as needed*, and would only affected pkgs that > specified that node as a binding dep (specially marked atom). no, i mean for example scenarios where a package provides more than one library (say libfoo and libbar) and only one of those changes ABI values (say libfoo.0 -> libfoo.1). if another package links against just libbar, you've got a pointless rebuild. > Seriously, maintainers ought to know *now* when they're forcing a > revdep on folks systems, I'm not seeing the massive overhead from > pushing that info into a var, nor am I seeing mass forced useless > rebuilds. there's a ton of things maintainers ought to know ... pretty soon our package maintainers are going to have to be gods if they want to write an ebuild as they're going to have to know every detail about the package inside and out > Realistically, just the same as the NEEDED solution has holes, the > maintaining dev can screw up and miss a BINCOMPAT bump. Difference is > that they can do something for BINCOMPAT; hell, QA checks can be > automated to catch missing BINCOMPAT bumps. what's the difference ? in my scenario they dont have to do anything because the bump would have been caught automatically ? > KEYWORDed arches bit, bit unlikely that the underlying arch is > actually going to screw with the soname, thus I'd want actual examples > backing it up. how about libc.so from glibc and libgcc.so from gcc ? or would you like other packages ? > Besides, again, for keywording, the dev *should* be compiling it, so > there is a way to catch it :P. A revbump isn't g
Re: [gentoo-dev] How default route should be set by pppd
On Saturday 30 September 2006 18:59, Alin Nastac wrote: > I discovered that ppp-2.4.4 set a default route without a gateway. It is > totally fine from IP routing point of view (the simple fact that route > is through the point-to-point link is enough to know the next hop), > except that openswan's %defaultroute need a default gateway in order to > work. So how does that look in the routing table? If say a DHCP client renewed it's lease and it set a new default route, would this have any effect? > I'm about to apply a patch that would reverse to the old way of setting > the default route. > Any objections? If it's p.masked then none :) Thanks -- Roy Marples <[EMAIL PROTECTED]> Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites: tuxracer/tuxracer-demo
Chris Gianelloni wrote: > games-arcade/tuxracer - the last open source version of the game > games-arcade/tuxracer-demo - the demo for the closed-source version > Good riddance, I say. ppracer for the win! :) -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC about another *DEPEND variable
On Sat, Sep 30, 2006 at 02:01:08PM -0400, Mike Frysinger wrote: > On Wednesday 27 September 2006 03:54, Brian Harring wrote: > > > > Bleh, this is getting back to exactly my point that it's unbounded > > > > resolution. To support this, every step of execution would require > > > > scanning for dangling nodes to punt; aside from invalidating -p's > > > > output it *still* is a collision-protect hit. > > > > > > when the package upgrade detects an ABI change you recalculate the > > > packages that need to be rebuilt ... > > > > Reiterating, this screws over any form of up front calculation; > > dialup users/per minute connections can't rely on emerge -f to > > actually fetch all involved sources, -p results ain't guranteed > > valid, parallelization must now lock at each threads merge on the off > > chance a recalc is forced. > > it does indeed prevent full up front calculation. we can always make the > behavior configurable; revdep on the fly or allow people to break it up. the > key being that their system will still continue to function as the ABI lib > has been preserved automagically Folks aren't that daft; you make it an optional component, it means a *proper* solution will never be pushed because the duct tape is in place already. If that's what folks want, sure, but what you're proposing is just sliding NEEDED in as the defacto solution without labeling it as such. > > > dangling nodes get recorded in the new package and considering these old > > > files are not detrimental to the health of the system, you can do such a > > > cleanup once at the end of the emerge > > > > It's not orphaning files, but your scheme doesn't work for any form of > > interruption; failed builds, user intervention, etc, they all can > > leave the lib stuck in the new contents. > > huh ? i outlined in a previous e-mail how by simply ordering the operations > sanely, there is no race condition Re-read your emails, and mine please. The scenario I pointed out was ctrl+c'ing the merge while it's doing a rebuild for lib1 to lib2. Now how does portage know that it needs to complete that upgrade for the next emerge action? How does it know to even scan for lib1, let alone punting? It's *not* simple, and I keep pointing out this issue (and you're missing it every damn time). Please address it, or point to where you have (gone over the thread and still not seeing anything even remotely touching this flaw). > > Dealing with that possibility means the manager has to maintain on > > disk a list of the refcount of each dangling libs to decrement, > > unmerge has to modify said list, etc. > > which is already being done in the NEEDED file ... funny how unpainless it is > to generate that file First of all, unpainless is painful. Which is apt, actually. Familiar with old style virtuals? That whole, "you have to walk the whole vdb to collect all old style virtuals" ? This is the same damn thing. There is no refcount maintained via NEEDED, just a list of libs a binary uses; you _still_ have to walk the damn vdb to build the refcount list. Now either you're forcing a fairly huge mapping in memory, or you're forcing a scan of the vdb for every pkg operation that has NEEDED entries it will install. So no, NEEDED doesn't cover this, and my point still stands. > > > > It also involves changing vdb nodes from "installed and usable" to > > > > "installed/usable" or "lingering" > > > > > > no ... the old versions get merged into the new one as their existence is > > > purely hidden > > > > How exactly are they going to be hidden? A new file? If so, > > backwards compatibility for vdb for transitioning in such a support > > has to be addressed. > > purely hidden from the standpoint of any new package trying to use it ... > since you're only installing the runtime ABI library, you cannot link against > it or utilize it any way other than existing files. Except for dlopen, but thats again besides my original point; how do you note to portage that the lib is one to watch so it can be punted? You're suggesting it get shoved into contents, and for portage to identify it, it has to do a revdep mapping on the fly to find it. This *sucks* massively, both from a speed and complexity standpoint; further, the lib isn't hidden from pkg ops (say quickpkging, or binpkging) in any way so the cruft spreads. That's surprisingly minor in comparison to implications of relying on refcounting to identify the lib to punt. If the lib to punt isn't tracked in some fashion, the only algo you're left with is attempting to find all libs that have a refcount of zero, and punt those- obviously, this is going to screw up just about every single dlopen based linkage, literally, suck an algo won't spot that python dlopen's it's modules, and would think the refcount was zero (thus the so could get booted). The response there is to add blacklists, directories to *not* inspect, which is a further hack to try and
Re: [gentoo-dev] How default route should be set by pppd
Roy Marples wrote: > So how does that look in the routing table? > "default dev ppp0 scope link" instead "default via a.b.c.d dev ppp0". > If say a DHCP client renewed it's lease and it set a new default route, would > this have any effect? > I guess a DHCP client would override the default route set through "defaultroute" pppd option (or not, depends on the client). > If it's p.masked then none :) > Why p.mask when the way I wanna set defaut route is as in stable version of net-dialup/ppp? Of course, 2.4.4-r2 will still be marked as testing for all arches. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: How default route should be set by pppd
> I discovered that ppp-2.4.4 set a default route without a gateway. It is > totally fine from IP routing point of view (the simple fact that route > is through the point-to-point link is enough to know the next hop), > except that openswan's %defaultroute need a default gateway in order to > work. > > I'm about to apply a patch that would reverse to the old way of setting > the default route. > Any objections? Why not? Such routes work perfectly here. I also use them for my PPTP tunnel: route add -net 1.2.3.4/24 dev ppp1 Works perfectly! I think it simply means: take all IP-packets with destination 1.2.3.4/24 and send them out through interface ppp1. We know such routes from local network-interfaces. Actually, i also always thought, that i must specify a gateway. But it seems, i was wrong. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: How default route should be set by pppd
> "default dev ppp0 scope link" instead "default via a.b.c.d dev ppp0". And? What the difference? For the P-t-P connection, there is not difference. There is only one destination, you can send the packets to: the ppp-server on the other side. Only for normal network-connections (eth0, ...), you have to tell the kernel, which host in the subnet he has to send the packets to, because usually there are many of them. signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Hi, I just had an unpleasant experience with -ffast-math and GCC 4.1.1 (it borked my LDAP authentication on several systems which worked with the same CFLAGS as long as GCC 3.4.6 was used). There is a lot of material out there about CFLAGS and Gentoo (google returns 387000 pages) but what's working for someone might not for another. There are flags that work for a GCC version and most ebuilds and don't work with another GCC version (my unfortunate experience) or some ebuilds. Flag combination/architecture/LDFLAGS might be an issue too. There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix was mentioned to me by robbat2) but they may not be advertised enough. I'd like to propose a paragraph to the GWN editor which presents some gotchas and good references on the subject. Here's a draft for review. You're welcomed to expand on the subject. --- Draft BEGIN --- CFLAGS Being able to tune the CFLAGS is part of one of the core principles of Gentoo: let the user be in control. Being in control brings both benefits and problems and CFLAGS tuning is not an exception. The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the landscape. Users that spent some time tuning their CFLAGS with gcc-3.4.6 might find out that an upgrade to gcc-4.1.1 leaves them with an unstable system. Example of this are : nss_ldap stopped working with -ffast-math ... Users with unsupported CFLAGS (see the CFLAGS matrix for example) might want to return to safe CFLAGS (see Safe CFLAGS) if recent updates caused them stability problems. On the other hand, more adventurous users might want to experiment with CFLAGS that didn't work properly with gcc-3.4.6... As always, the user is in control. --- Draft END --- If possible, I'd like to expand the list of 3.4.6 -> 4.1.1 upgrade problems which are linked to experimental CFLAGS. If you want to expand the subject to cover other tuning/stability gotchas that recent updates might have brought into the light, please feel free to do so. As English is not my native tongue, feel free to spell check too. Cheers, Lionel. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Le Sat, 30 Sep 2006 22:35:58 +0200, Lionel Bouton <[EMAIL PROTECTED]> a écrit : > Hi, I just had an unpleasant experience with -ffast-math and GCC 4.1.1 > (it borked my LDAP authentication on several systems which worked with > the same CFLAGS as long as GCC 3.4.6 was used). > > There is a lot of material out there about CFLAGS and Gentoo (google > returns 387000 pages) but what's working for someone might not for > another. There are flags that work for a GCC version and most ebuilds > and don't work with another GCC version (my unfortunate experience) or > some ebuilds. Flag combination/architecture/LDFLAGS might be an issue too. > > There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix > was mentioned to me by robbat2) but they may not be advertised enough. > I'd like to propose a paragraph to the GWN editor which presents some > gotchas and good references on the subject. > > Here's a draft for review. You're welcomed to expand on the subject. > > --- Draft BEGIN --- > > CFLAGS > > > > Being able to tune the CFLAGS is part of one of the core principles of > Gentoo: let the user be in control. Being in control brings both > benefits and problems and CFLAGS tuning is not an exception. > > > The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the > landscape. Users that spent some time tuning their CFLAGS with gcc-3.4.6 > might find out that an upgrade to gcc-4.1.1 leaves them with an unstable > system. Example of this are : > > nss_ldap stopped working with -ffast-math > ... > > > > Users with unsupported CFLAGS (see the link='http://gentoo-wiki.com/CFLAGS_matrix'>CFLAGS matrix for > example) might want to return to safe CFLAGS (see link='http://gentoo-wiki.com/Safe_Cflags'>Safe CFLAGS) if recent > updates caused them stability problems. On the other hand, more > adventurous users might want to experiment with CFLAGS that didn't work > properly with gcc-3.4.6... As always, the user is in control. > > > > --- Draft END --- > > If possible, I'd like to expand the list of 3.4.6 -> 4.1.1 upgrade > problems which are linked to experimental CFLAGS. If you want to expand > the subject to cover other tuning/stability gotchas that recent updates > might have brought into the light, please feel free to do so. As English > is not my native tongue, feel free to spell check too. > > Cheers, > > Lionel. My personal experience with other CFLAGS as the ones in the handbook is at gcc-4.1.1 have a better optimisation with the default gentoo CFLAGS. Even with -O2, the result is a faster system, and -O3 seam to be safer with math related applications as with gcc-3.4.*. But in the other hand, other flags seam to be more problematic as with gcc-3.4.*. And the new optimisations flags as the vectorisation flags are not easy to use, because the result depend on the code of the program. They can or not brake the code, and when the program run well, they can make it faster or slower. All depend of the size and complexity of the loops. And I think also of the arch. So my conclusion is: For system flags, just keep the default, and if you want to experiment, do profiling for each single program you want to optimize. Cheers, Dominique -- Dominique Michel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN
Lionel Bouton wrote: > There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix > was mentioned to me by robbat2) but they may not be advertised enough. Most of the info on that page is wrong. > I'd like to propose a paragraph to the GWN editor which presents some > gotchas and good references on the subject. Honestly, the only good reference is the Safe CFLAGS page. > If possible, I'd like to expand the list of 3.4.6 -> 4.1.1 upgrade > problems which are linked to experimental CFLAGS. If you want to expand > the subject to cover other tuning/stability gotchas that recent updates > might have brought into the light, please feel free to do so. As English > is not my native tongue, feel free to spell check too. The english and speeling seem fine. --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
On Saturday 30 September 2006 16:35, Lionel Bouton wrote: > There is a lot of material out there about CFLAGS `man gcc` always seemed fine to me in fact, lets read the -ffast-math section: -ffast-math This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math func- tions. this flag is never safe to use in CFLAGS > link='http://gentoo-wiki.com/CFLAGS_matrix' no way will our documentation link to gentoo-wiki.com > If possible, I'd like to expand the list of 3.4.6 -> 4.1.1 upgrade > problems which are linked to experimental CFLAGS i find maintaining a list of "safe" CFLAGS on a per-gcc basis to be a waste of time ... but that's just me -mike pgp0RbpprqNxt.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN
On Sat, Sep 30, 2006 at 03:48:53PM -0600, Ryan Hill wrote: > Lionel Bouton wrote: > > There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix > > was mentioned to me by robbat2) but they may not be advertised enough. > Most of the info on that page is wrong. The items on there that note breakages are reasonably correct. -fvisibility=hidden and -ffast-math DO cause breakages. -ftree-loop-linear likewise is broken on GCC4.1 last I checked. > > I'd like to propose a paragraph to the GWN editor which presents some > > gotchas and good references on the subject. > Honestly, the only good reference is the Safe CFLAGS page. The objective here was mainly to point out some things that users are doing that are causing breakages, leading to bugs that are ultimately marked INVALID after much tracing. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpQ5caJCq57I.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN
Robin H. Johnson wrote: > On Sat, Sep 30, 2006 at 03:48:53PM -0600, Ryan Hill wrote: >> Lionel Bouton wrote: >>> There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix >>> was mentioned to me by robbat2) but they may not be advertised enough. >> Most of the info on that page is wrong. > The items on there that note breakages are reasonably correct. > -fvisibility=hidden and -ffast-math DO cause breakages. > > -ftree-loop-linear likewise is broken on GCC4.1 last I checked. I thought he wanted flags that broke upgrading between GCC 3.4 and 4.1. tree-loop-linear wasn't in 3.4. If you want flags that just break stuff with 4.1 you can include -ftree-vectorize. >>> I'd like to propose a paragraph to the GWN editor which presents some >>> gotchas and good references on the subject. >> Honestly, the only good reference is the Safe CFLAGS page. > The objective here was mainly to point out some things that users are > doing that are causing breakages, leading to bugs that are ultimately > marked INVALID after much tracing. Like using CFLAGS not on the Safe CFLAGS page? ;) Monsieur Spanky wrote: > no way will our documentation link to gentoo-wiki.com It's not documentation, it's the GWN, which has linked to gentoo-wiki before. --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Mike Frysinger wrote the following on 30.09.2006 23:48 : > [...] > `man gcc` always seemed fine to me > > in fact, lets read the -ffast-math section: >-ffast-math >This option should never be turned on by any -O option since it can >result in incorrect output for programs which depend on an exact >implementation of IEEE or ISO rules/specifications for math func- >tions. > > this flag is never safe to use in CFLAGS > > Indeed, I'll add a reminder to adventurous users to check `man gcc` (I believe I added fast-math following an example somewhere on the web instead of checking the man page). >> link='http://gentoo-wiki.com/CFLAGS_matrix' >> > > no way will our documentation link to gentoo-wiki.com > > The GWN paragraph is mainly a 'heads-up' kind of thing, no more. Don't confuse the GuideXML extract with an official documentation extract, GWN uses GuideXML too :-) >> If possible, I'd like to expand the list of 3.4.6 -> 4.1.1 upgrade >> problems which are linked to experimental CFLAGS >> > > i find maintaining a list of "safe" CFLAGS on a per-gcc basis to be a waste > of > time ... but that's just me > That's not the idea. The main idea is to remind people that playing with CFLAGS is allowed, as long as you remember to revert to safe CFLAGS before reporting bugs. As I wasted one dev time by forgetting to check my CFLAGS, I merely thought that maybe this wasn't a common reflex for other users too (fast-math was the only unsafe flag I used, I'm pretty conservative and simply was mistaken because roughly 2 years ago I didn't check the proper source of information: the man page). Maybe very few bug reports are caused by inadequate CFLAGS. If my problem is an uncommon exception I won't press the matter further, there would be no point to do so. I'll wait and see if other devs are aware of common CFLAGS gotchas plaguing bugzilla. Lionel. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN
Lionel Bouton wrote: > I'll wait and see if other devs are aware of common CFLAGS gotchas > plaguing bugzilla. Flags such as -fforce-addr and -fweb that change the way registers are handled can often cause errors when compiling hand-optimised ASM on architectures with a very limited number of registers (ie. x86). This turns up a lot in video libraries or graphic processing apps like ffmpeg, xine-lib, or avidemux. --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OT noise (Was: Profile masking and profiles package.mask)
Danny van Dyk wrote: > Am Samstag, 30. September 2006 19:02 schrieb Jakub Moc: > >> Mike Frysinger wrote: >> >>> seriously jakub, stop responding ... you have nothing technical to >>> offer to the issue at hand >>> >>> let the people who work on portage handle it >>> -mike >>> >> Eh, the whole technical point here is that paludis behaviour differs >> from portage (and differs from pkgcore, FWIW). >> > This has little to do with why this change to the devmanual has been > done. > > >> So, hiding the inconsistency via altering the profiles doesn't change >> anything. Plus, the point of the bug's flame fest was that bugzilla >> is not a proper place to request such behaviour changes, and >> definitely not a reason for QA to mess with the profiles. Sticking >> the stuff in package.mask won't make the inconsistent behaviour >> vanish in any way, it will just hide it. >> > It is not a behaviour change imho. The "packages" file changed > its meaning subtly after introducing cascading profiles. > As ciaranm already pointed out: It is not meant to mask "<"-like > versions anymore. It's meant to > - Describe the system package set > - Define which versions are _at least_ needed for a profile. > > >> So, I'd kinda appreciate if concerned folks (including portage and >> relevant affected arches) were involved in this discussion, instead >> of sneaking the changes in under QA disguise. >> > Release engineering arch coordinators, which happen to be the people who > maintain the profiles below default-linux/ for their relevant arches, > have been CCed and Chris already stated that he forgot/didn't realize > to fix this problem for no-nptl/2.4's package.mask. > > Jakub: Please reevaluate the behaviour you showed on both the bug and > this mailing list. I for one don't consider it anywhere near > appropriate. This shall be no offense, just a comment in regard that > you can do better. > mike, danny, thanks for trying, but past reference showed that he likes to talk like a chicken who's head has been chopped of. This whole discussion made most of the people forget what it was about... good on ya jakub... > Danny > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Profile masking and profiles package.mask
On Saturday 30 September 2006 19:39, Mike Frysinger wrote: > isnt that the point of putting a comment above a mask ? > # this package wont work on this profile > bar/foo Indeed, but the problem is that the masks are all normalised in one big mask. Which means that users might want to unmask certain versions found in the top-level profile.mask, and also unmask some of the packages masked in a profile. > fbsd/packages:sys-freebsd/freebsd-mk-defs > fbsd/package.mask: > fbsd/6.1/packages: > fbsd/6.1/package.mask:>=sys-freebsd/freebsd-mk-defs-6.2 > fbsd/6.2/packages: > fbsd/6.2/package.mask: Actually, you need to mask < versions, too ... > so what you're arguing is that we should retain the existing behavior > because users might try to unmask something properly ? trying to protect > users from shooting themselves in the foot by making the profile behavior > more complicated is a waste of time Uh, it's not "making the profile behaviour more complicated", it's "retaining the current behaviour of profiles". But seems I'm in minority on this. Still, if we're going to change this behaviour, it's the case to do it properly, by also updating the behaviour of portage itself, and document this properly (as in, give a reasoning for this change of behaviour). Note to Danny: releng controls default-linux, okay, but there are other profiles than those, hardened and Gentoo/Alt. The decision should have been taken by all the three of us, not unilaterally. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpoypLYD5e1A.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Lionel Bouton wrote: Hi, I just had an unpleasant experience with -ffast-math and GCC 4.1.1 (it borked my LDAP authentication on several systems which worked with the same CFLAGS as long as GCC 3.4.6 was used). There is a lot of material out there about CFLAGS and Gentoo (google returns 387000 pages) but what's working for someone might not for another. There are flags that work for a GCC version and most ebuilds and don't work with another GCC version (my unfortunate experience) or some ebuilds. Flag combination/architecture/LDFLAGS might be an issue too. There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix was mentioned to me by robbat2) but they may not be advertised enough. I'd like to propose a paragraph to the GWN editor which presents some gotchas and good references on the subject. Here's a draft for review. You're welcomed to expand on the subject. --- Draft BEGIN --- CFLAGS Being able to tune the CFLAGS is part of one of the core principles of Gentoo: let the user be in control. Being in control brings both benefits and problems and CFLAGS tuning is not an exception. The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the landscape. Users that spent some time tuning their CFLAGS with gcc-3.4.6 might find out that an upgrade to gcc-4.1.1 leaves them with an unstable system. Example of this are : nss_ldap stopped working with -ffast-math ... Users with unsupported CFLAGS (see the CFLAGS matrix for example) might want to return to safe CFLAGS (see Safe CFLAGS) if recent updates caused them stability problems. On the other hand, more adventurous users might want to experiment with CFLAGS that didn't work properly with gcc-3.4.6... As always, the user is in control. --- Draft END --- If possible, I'd like to expand the list of 3.4.6 -> 4.1.1 upgrade problems which are linked to experimental CFLAGS. If you want to expand the subject to cover other tuning/stability gotchas that recent updates might have brought into the light, please feel free to do so. As English is not my native tongue, feel free to spell check too. Cheers, Lionel. I agree in principle because it would stop people using stupid CFLAGS. It should have an information section and a "use this CFLAG and dont ask us for help" section: Good Compiler Flag -floop-optimize Enables safe loop optimisation and is enabled in most -O$ Bad Compiler flag Sets |-fno-math-errno|, |-funsafe-math-optimizations|, |-fno-trapping-math|, |-ffinite-math-only|, |-fno-rounding-math| and |-fno-signaling-nans| Used to speed up math functions but causes major b0rkage because it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. Use this and dont bother asking for help. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN
On Sat, Sep 30, 2006 at 04:37:05PM -0600, Ryan Hill wrote: > I thought he wanted flags that broke upgrading between GCC 3.4 and 4.1. > tree-loop-linear wasn't in 3.4. If you want flags that just break > stuff with 4.1 you can include -ftree-vectorize. Thanks. > > The objective here was mainly to point out some things that users are > > doing that are causing breakages, leading to bugs that are ultimately > > marked INVALID after much tracing. > Like using CFLAGS not on the Safe CFLAGS page? ;) Not really. One needs to use some common sense as a developer in evaluating user CFLAGS - because there are plenty of flags that are safe, but aren't listed on that page. Several years ago, I wrote a package that was the forerunner of the 'Safe CFLAGS' page - genflags. It was close to unmaintable at the time however, so it's suffered a lot of bit-rot. With the advent of libcpuinfo, and x86info being written, it stands a much better chance of giving useful output, but that still does not supersede the common sense statement above. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpbjtxaOcfz0.pgp Description: PGP signature
