Re: [gentoo-dev] Unmasking modular X
On Tuesday 24 January 2006 09:34, RH wrote: On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote: A) You have commit access to gentoo-x86, AND B) you're comfortable with the porting process OR are adept with ebuilds and would like to help I'm up for being a volunteer here. Same for me. -- Christian Heim [EMAIL PROTECTED] Gentoo Linux Developer - vserver pgp3vExmVVQWR.pgp Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 2006-01-24 at 13:38 +0100, Christian Heim wrote: On Tuesday 24 January 2006 09:34, RH wrote: On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote: A) You have commit access to gentoo-x86, AND B) you're comfortable with the porting process OR are adept with ebuilds and would like to help I'm up for being a volunteer here. Same for me. Add me there -- Carlos r3pek Silva Gentoo Developer (kernel/amd64/mobile-phone) signature.asc Description: This is a digitally signed message part
[gentoo-dev] package.mask cleanups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I figured it was time for a bit of cleaning... I ended up writing a really crappy script for stable to do a check of whether package.mask entries were really referencing anything or not. Luckily Brian was able to write a much better one for bcportage. So the list of invalid masks is at [1]. The script source is at [2]. Please have a look and see if any of the packages are yours. Entries in package.mask should have a corresponding ebuild in the tree somewhere. I'd like to see the number of entries chopped by a fair margin. * Yes there is an exception thrown for kde-base/metadata.xml. I have nfc what the hell that is doing in package.mask, but I was told it was already fixed ;) - -Alec Warner (antarus) [1] http://dev.gentoo.org/~ferringb/stale-p.mask.list [2] http://dev.gentoo.org/~ferringb/stale-p.mask.py -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9Y29GzglR5RwbyYAQIJRw//UhlSU/KC1qyZKF8l51k6I+fVs8Bc6nz+ ZJ4IIjk1MCuHBfXWpfA0G9mpPrlxTvwZoSUW1DtRIH8GimB9aeRjjOi3V+7ph6+M SaWYgYCGmDhvk3TkbrZWHT56hIa5EJXpe7QswbjpOMA3Jtl7X/uC5h5VbeMEog2a E8fcQvO0K9lrxWEE/Rr+Ub+StigvRvtZjV1hxCr+0Hh1kHPWD4fb44z0BCTMha+m HeK2i/bFCgAzHMA+5dFUzcBnmXALMDphVtq1jPfVAiURBcnBhUqnIYp/y5Be7e8F 6sHd+iGVZiFt7EDOnzA4NFSphpf/rTMDRpnMa6oTlOXml9Ai7w4oJxzskI7+uBIr zMsprv9WvLIbyDR34//1WjPoPkNuDH1X4wG+E92tBjA/qWsH4xU4A4PvUkrm/BpA /MqweGM5nMD5SMST8/UlApr9dnmzm6G0Hs3ZnGW1tTVbJDJ05p5+bxDl6XgC+023 wFULR6FGgQO3HG+txiyCt0AHd2PrY2q6l1wOSZm3dd0nYmPIC7yOdDCBSC8KAra9 Fsw1+6UFWtZcQY43CDljr5bCY8IVD80OPy31S8lo4Lrg9OaQOwvCmfoIWi3tnsLy XhbNa2RehILTyLbpx8Rmf2ihe7yZkPfqX3gXbMpWxWq8tARA3dmrJZEyFnKbB1cC F7hsH+G4ToY= =cIlU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] vpopmail and company
Greetings,I just did an emerge --update world which upgraded vpopmail. This update was bad news. It switched vpopmail over to mysql based auths and storage of email which I didn't have mysql or vpopmail setup for. This gave me a lot of grief. Just and FYI. -- Darryl Wagoner - WA1GONEvil triumphs when good men do nothing.- Edmund Burke [1729-1797]
Re: [gentoo-dev] package.mask cleanups
On Tuesday 24 January 2006 14:17, Alec Warner wrote: I figured it was time for a bit of cleaning... I ended up writing a really crappy script for stable to do a check of whether package.mask entries were really referencing anything or not. Luckily Brian was able to write a much better one for bcportage. So the list of invalid masks is at [1]. The script source is at [2]. Please have a look and see if any of the packages are yours. Entries in package.mask should have a corresponding ebuild in the tree somewhere. I'd like to see the number of entries chopped by a fair margin. All of the KDE stuff is the upcoming 3.5.1 release which we are working on in p.mask until the official release. There *are* ebuilds for all this stuff in the tree right now. So that has chopped the number of entries by a fair margin, but for the script to be useful it should be able to detect they have valid ebuilds. pgpV8E3x76qAx.pgp Description: PGP signature
Re: [gentoo-dev] package.mask cleanups
On Tue, 24 Jan 2006 09:17:24 -0500 Alec Warner [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I figured it was time for a bit of cleaning... I ended up writing a really crappy script for stable to do a check of whether package.mask entries were really referencing anything or not. Luckily Brian was able to write a much better one for bcportage. Why are people so obsessed with cleaning package.mask all the time? Sure makes sense to remove three year old unused entries from time to time, but not everything that isn't actively used is invalid automatically (quite sure that kde-3.5.1 stuff is a preventive mask for example). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask cleanups
Alec Warner wrote: Please have a look and see if any of the packages are yours. It would probably be easier if you added the maintainer of each package to the list (it shouldn't be that difficult, but I'm not volunteering :-P). /Martin -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] package.mask cleanups
On Tuesday 24 January 2006 16:23, Marcus D. Hanwell wrote:
All of the KDE stuff is the upcoming 3.5.1 release which we are working on
in p.mask until the official release. There *are* ebuilds for all this
stuff in the tree right now. So that has chopped the number of entries by a
fair margin, but for the script to be useful it should be able to detect
they have valid ebuilds.
As KDE is way bigger than that is probably listing the packages that are still
at 3.5.0 and didn't get a verbump.
Dan probably did a for pkg in ${PORTDIR}/kde-base/*; do echo
=kde-base/$pkg-3.5.1*; done ${PORTDIR}/profiles/package.mask or a
variation on the theme, that's also why metadata.xml got listed, too.
I have a partial ruby script that might work to get the real kde packages to a
given version but it's still raw...
--
Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgp9yCfrxksIo.pgp
Description: PGP signature
Re: [gentoo-dev] package.mask cleanups
Marius Mauch wrote: On Tue, 24 Jan 2006 09:17:24 -0500 Alec Warner [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I figured it was time for a bit of cleaning... I ended up writing a really crappy script for stable to do a check of whether package.mask entries were really referencing anything or not. Luckily Brian was able to write a much better one for bcportage. Why are people so obsessed with cleaning package.mask all the time? Sure makes sense to remove three year old unused entries from time to time, but not everything that isn't actively used is invalid automatically (quite sure that kde-3.5.1 stuff is a preventive mask for example). Marius I was attempting to be helpful and filter out valid packages from the list. I could have been an ass and been like Yo I think package.mask is bloated go clean it and not given a list at all, but that is not very useful. I never said ( or meant for ) everything in that list to be cleaned, and perhaps I should have added a use your own descretion deal. The goal was to have a list that someone can quickly glance over and be like hmm I maintain one or two of those lets check it out. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] package.mask cleanups
Marcus D. Hanwell wrote: On Tuesday 24 January 2006 14:17, Alec Warner wrote: I figured it was time for a bit of cleaning... I ended up writing a really crappy script for stable to do a check of whether package.mask entries were really referencing anything or not. Luckily Brian was able to write a much better one for bcportage. So the list of invalid masks is at [1]. The script source is at [2]. Please have a look and see if any of the packages are yours. Entries in package.mask should have a corresponding ebuild in the tree somewhere. I'd like to see the number of entries chopped by a fair margin. All of the KDE stuff is the upcoming 3.5.1 release which we are working on in p.mask until the official release. There *are* ebuilds for all this stuff in the tree right now. So that has chopped the number of entries by a fair margin, but for the script to be useful it should be able to detect they have valid ebuilds. It may be Brian hadn't cvs up'd lately, I am not sure. On my box I don't see any kde-3.5.1 ebuilds for some random items that I plucked out of the list (qtsharp fex). Regardless, if it's a preventive mask or whatnot I'm not going to make you take it out or anything. The list is only meant to help spot old packages, or pkgmoved packages or whatnot. If you as the maintainer know the mask is valid, then don't touch it. If you as the maintainer know that package is long dead, then remove it. Thats basically it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Mon, 2006-01-23 at 23:06 -0800, Donnie Berkholz wrote: Earlier tonight, I discussed with halcy0n our differing opinions of the need for modular X to enter ~arch and break trees for some ~arch users. In my opinion, this is acceptable and beneficial, as ~arch users should already be those willing to help out. It will assist in learning which of the still-unported apps are actually in use and help compile a possible list of tree removal candidates. halcy0n, on the other hand, feels that any breakage of the ~arch tree is anathema. Funny enough, I kinda agree with both of you. I am currently working through the *enormous* number of packages in games-* but with the release forthcoming and also very busy. Any help here would be appreciated. I would hope to get as much of this done as possible *before* the packages go into ~arch, rather than after. It's my earnest hope that this proposal makes everyone happy, because I refuse to let modular X get old and rusty in package.mask while hundreds of unmaintained (or undermaintained, for whatever reason) applications hold it back. In our case, it is simply sheer numbers. We have a small group responsible for a large number of packages. We are definitely agreeable to getting some help with this, as we don't want to be the cause of holding back modular X in any way. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] package.mask cleanups
On Tuesday 24 January 2006 15:40, Diego 'Flameeyes' Pettenò wrote:
On Tuesday 24 January 2006 16:23, Marcus D. Hanwell wrote:
All of the KDE stuff is the upcoming 3.5.1 release which we are working
on in p.mask until the official release. There *are* ebuilds for all this
stuff in the tree right now. So that has chopped the number of entries by
a fair margin, but for the script to be useful it should be able to
detect they have valid ebuilds.
As KDE is way bigger than that is probably listing the packages that are
still at 3.5.0 and didn't get a verbump.
Dan probably did a for pkg in ${PORTDIR}/kde-base/*; do echo
=kde-base/$pkg-3.5.1*; done ${PORTDIR}/profiles/package.mask or a
variation on the theme, that's also why metadata.xml got listed, too.
Hadn't thought of that - a cursory check of a few from the list does indeed
show that they have not been bumped. Still I don't think it does any harm
having a few extra in p.mask - it is just a temporary mask until the release
and it is better to have too many in there than miss one.
Looks like your script has cut out the false positives quite effectively in
this case. They will all be gone once KDE 3.5.1 is released anyway.
pgpB5itYtzjlp.pgp
Description: PGP signature
[gentoo-dev] Ebuilds and USE flags
I am writing an ebuild for a program written in perl. This program has the dependency of gnuplot but with the png flag enabled. What is the gentoo way to enable this USE Flag for gnuplot when I emerge my program. cheers rene -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] package.mask cleanups
On 1/24/06, Alec Warner [EMAIL PROTECTED] wrote: Please have a look and see if any of the packages are yours. Entries in package.mask should have a corresponding ebuild in the tree somewhere. I'd like to see the number of entries chopped by a fair margin. I masked prelude stuff so that it wouldn't be a moving target and we can stabilize a 0.9.x release. For example, even though dev-libs/libprelude-0.9.3 does not match anything in the tree, if somebody bumps it to 0.9.4 ~arch users will still get 0.9.3. This should only go off after a 0.9.x release is stabilized or if a security bug comes up. Just FYI. Marcelo -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] package.mask cleanups
On Tue, 24 Jan 2006 10:45:40 -0500 Alec Warner [EMAIL PROTECTED] wrote: I was attempting to be helpful and filter out valid packages from the list. I could have been an ass and been like Yo I think package.mask is bloated go clean it and not given a list at all, but that is not very useful. I never said ( or meant for ) everything in that list to be cleaned, and perhaps I should have added a use your own descretion deal. The goal was to have a list that someone can quickly glance over and be like hmm I maintain one or two of those lets check it out. Sorry for hitting you with this, just that this is I thinkt he third call for cleaning package.mask in the last 10 months or so, always claiming that a mask that doesn't cover any ebuilds in the tree is invalid (and everytime people write their own scripts for it). One would think there might be more important things to do. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Ebuilds and USE flags
On Tuesday 24 January 2006 11:27, Rene Zbinden wrote: I am writing an ebuild for a program written in perl. This program has the dependency of gnuplot but with the png flag enabled. What is the gentoo way to enable this USE Flag for gnuplot when I emerge my program. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ebuilds and USE flags
Rene Zbinden wrote:
I am writing an ebuild for a program written in perl. This program has
the dependency of gnuplot but with the png flag enabled. What is the
gentoo way to enable this USE Flag for gnuplot when I emerge my program.
There is no active way, you could only check if the flag was enabled,
and fail if it was not, take this example from app-admin/moodss
pkg_setup() {
if ! built_with_use dev-lang/tcl threads ; then
eerror Tcl is missing threads support.
eerror Please add 'threads' to your USE flags, and re-emerge tcl.
die tcl needs threads support
fi
}
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] RFC: emerge snapshots
Hi all. During the last many months, more than once an idea occured in my mind, so I decided to share it. 2006-01-25T01:34 kalin $ dd if=/dev/brain of=gentoo-dev bs=1 count=3292 Do you think it will be good to have something like a snapshot of the installed packages? Something that will help when something unexpectedly breaks and you cannot fix it bu shuffling around its dependencies. Because s--t does happen; sometimes. Right now vmware-workstaion is broken and I am failing to understand why for the last few hours. But that is just an example, forget about it. So how can we get that thing? Let's call it emerge snapshot not to be confused with portage snapshots used during install. One way is to employ a version control system, say subversion, to keep the list of installed packages. It has to be updated during emerge. Also there should be a way to insert markers like OK, tested and working, going to try this fuzzy foo install, mark! All these should be timestamped. So after the _BANG_ my box is b0rked, it will be easy to retrace your steps by just doing `emerge --log 3` to see the last three labels/log entries: 35442006-01-01T12:12OK, tested and working 35452006-01-01T12:12going to try this fuzzy foo install, mark 35462006-01-01T12:12yay, new modular X is in ~arch (-: then `emerge --revert -r3544` and everything is smooth and runnig again. The behind the scenes actions to be taken by portage is to unmerge everything that was merged after -r3544 That was the easy part. Now what if some config file is b0rked? Solution 0 (slow, disk space): _before_ upgrading a package, or even before installing the same package in a new SLOT, do `quickpkg $PACKAGE` Solution 1 (better): Anybody? Some notes to consider: AFAIK, at present portage leaves most (all?) files that are in CONFIG_PROTECT on unmerge... is there any easy way to trace which files are left over in the system and delete them? Parsing the logs might help, but unless it is automated it will be error prone and cumbersome. Now imagine this timeline: r100 emerge foo r101 emerge --unmerge foo r102 Is there anything else to be taken care so that the system @r100 and @102 is the same? (sans system logs, user created files and the like) I guess all the tools and info are already in portage and by writing a bunch of scripts (to parse the logs mainly) it will be feasible to make it work. But if it is automated, this will give _HUGE_ advantages: 1. Users will be instructed to revert to a good point when something breaks. Probably an automated reporter can be hacked up 2. Bugs can easily be confirmed if there is enough CPU power (Give me your broken emerge snapshot and the one before that) 3. devs and trying-to-be-devs, testers will be able to test easily if package foo-2.3.4 does break something without the need of things like vmware (snapshots) 4. Any n00b will have the Ctrl+Z, Recycle bin, Trash bin, :undo whatever to their whole system 5. (dangerous) Experimenting on semi-production servers will be easy! 6. Given the above 5, Gentoo user base will grow enourmously: You have the flexibility, now you have stability. No need to dream, welcome to reality: it's called Gentoo! (from the 2006.3 release campaign :-) I know it is far from a GLEP, but let me first see how people feel about it. Even if not implemented as a whole (at first) it will greatly improve our Gentoo life. Any comments? It is an RFC after all :-) 2006-01-25T02:07 kalin $ -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
Donnie Berkholz [EMAIL PROTECTED] said: Ciaran McCreesh wrote: On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Here's my proposal for dealing with modular X entering ~arch. What's wrong with the original idea of just making any unported ebuild pull in all of modular X (minus drivers)? Yes, it means that some people will pick up unnecessary deps until all packages are ported, but it avoids anyone having to see flashy red errors. The problem with that is that it removes all motivation to ever port the packages. They'll just stay that way forever, where forever means until I threaten to remove that from the virtual, in which case we'll be in the same scenario we are now. Why? Because people have better things to do than fix stuff that isn't broken. It'd be nice if you reconsidered this as it will minimize any breakage that may occur. Knowing that 800 packages are broken, and going to unmask it knowing that just doesn't seem acceptable in my eyes. ~arch isn't meant to be things are known to be broken. It's meant to mean, we think all of this is ready to be stable, which it certainly won't be in this case. Thanks, -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpviiQ8OOriK.pgp Description: PGP signature
Re: [gentoo-dev] Removal of auto-use in portage-2.0.54
On Sat, 26 Nov 2005 17:12:45 +0200 Marius Mauch [EMAIL PROTECTED] wrote: Hi, As I said earlier, we'd like to get rid of the nasty auto-use feature, including the support for the USE_ORDER variable. Right now we intend this for 2.0.54 (might not be the final version number) unless there are major objections to it. Ok, I just disabled auto-use in make.globals in trunk, that means ~arch users will see the change starting with pre4. The code is still present so people who want to keep the feature can set USE_ORDER in make.conf accordingly to get it back, however that probably will only be temporary. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask cleanups
On Tuesday 24 January 2006 17:40, Diego 'Flameeyes' Pettenò wrote:
On Tuesday 24 January 2006 16:23, Marcus D. Hanwell wrote:
All of the KDE stuff is the upcoming 3.5.1 release which we are working
on in p.mask until the official release. There *are* ebuilds for all this
stuff in the tree right now. So that has chopped the number of entries by
a fair margin, but for the script to be useful it should be able to
detect they have valid ebuilds.
As KDE is way bigger than that is probably listing the packages that are
still at 3.5.0 and didn't get a verbump.
Dan probably did a for pkg in ${PORTDIR}/kde-base/*; do echo
=kde-base/$pkg-3.5.1*; done ${PORTDIR}/profiles/package.mask or a
variation on the theme, that's also why metadata.xml got listed, too.
Yeah... I'll be more careful next time.
--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpm7Fq8A1IJw.pgp
Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 2006-01-24 at 12:25 -0500, Mark Loeser wrote: The problem with that is that it removes all motivation to ever port the packages. They'll just stay that way forever, where forever means until I threaten to remove that from the virtual, in which case we'll be in the same scenario we are now. Why? Because people have better things to do than fix stuff that isn't broken. It'd be nice if you reconsidered this as it will minimize any breakage that may occur. Knowing that 800 packages are broken, and going to unmask it knowing that just doesn't seem acceptable in my eyes. ~arch isn't meant to be things are known to be broken. It's meant to mean, we think all of this is ready to be stable, which it certainly won't be in this case. I did some rough calculations and we are porting about 29 pkgs/day. At this rate it will take roughly 30 days to have all packages ported to ModX. spyderous wants it tomorrow, HalycOn wants it when all is ported. A (perhaps overly) simple solution is to split the difference. In 15 days ModX goes ~arch. 8 February -Lares -- Lares Moreau [EMAIL PROTECTED] | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: emerge snapshots
2 (already implemented) things you may find useful (unless you know them already of course): - adding buildpkg to your FEATURES builds binary packages, which makes it faster to revert to older versions if the new one cause problems. - dispatch-conf does a great job for the configuration files, especially when up- and downgrading packages. HTH, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpgd1UVEAHPN.pgp Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
Lares Moreau [EMAIL PROTECTED] said: I did some rough calculations and we are porting about 29 pkgs/day. At this rate it will take roughly 30 days to have all packages ported to ModX. spyderous wants it tomorrow, HalycOn wants it when all is ported. I didn't say all of it ported. It seems unreasonable to move it when we have atleast 800 packages that are not working though. I don't care the exact date that it happens, nor do I think we should aim for one. We should aim for when it will be done in a way that minimizes the breakage for all of our users. Yes, breakage will happen, but we can wait until its down to a more reasonable value. This huge push to get everything ported over only started recently, and I think we need more time. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpClp3YIPTv0.pgp Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Tue, Jan 24, 2006 at 01:44:28PM -0500, Mark Loeser wrote: We should aim for when it will be done in a way that minimizes the breakage for all of our users. Yes, breakage will happen, but we can wait until its down to a more reasonable value. And we probably should announce somewhere that this is going to happen (if not done already, haven't been following the modular X thing too closely). cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpZzarGhl8BK.pgp Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Here's my proposal for dealing with modular X entering ~arch. Yes, some packages are going to break. But I intend to keep this to a minimum on packages people care about, as measured by the existence of an open porting bug. So here's my plan: Before modular X enters ~arch, I will ensure that all porting bugs blocking #112675 are closed. As new bugs are filed, I will ensure that they are closed within 2 days, giving their maintainers that long to respond and close it themselves. After 2 days, I, or other members of the x11 team and any volunteers, will jump in and fix it ourselves. Earlier tonight, I discussed with halcy0n our differing opinions of the need for modular X to enter ~arch and break trees for some ~arch users. In my opinion, this is acceptable and beneficial, as ~arch users should already be those willing to help out. It will assist in learning which of the still-unported apps are actually in use and help compile a possible list of tree removal candidates. halcy0n, on the other hand, feels that any breakage of the ~arch tree is anathema. Please contact me if you'd like to be one of these volunteers. Requirements: A) You have commit access to gentoo-x86, AND B) you're comfortable with the porting process OR are adept with ebuilds and would like to help It's my earnest hope that this proposal makes everyone happy, because I refuse to let modular X get old and rusty in package.mask while hundreds of unmaintained (or undermaintained, for whatever reason) applications hold it back. Thanks, Donnie I think before you go forward with something like this you should give a suitable period of warning, it's going to create a lot of bug work for all of us. - -- === Mike Doty [EMAIL PROTECTED] Gentoo/AMD64 Strategic Lead PGP Key: 0xA797C7A7 Gentoo Developer Relations ===GPG Fingerprint=== 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD1oUV0K3RJaeXx6cRAg/2AKC3yopH5VUPjw+2BAPnD29Ippqw2gCfXRgu cL+GSnyiLPWxwOuwZIVpczw= =ze8X -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] guide/howto switching to slotted MySQL
Chris White wrote: On Monday 23 January 2006 10:06, Francesco Riosa wrote: Here there is a guide on howto switch to the slotted versions of MySQL. It's a first draft and to be totally usable some repoman commit are needed. You're probably better of putting this in bugzilla and assigning to the docs team. Please cc me as when you do make one. Chris White bug #120210, assigned and cc-ed :-) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Saturday 21 January 2006 00:25, Robin H. Johnson wrote: On Fri, Jan 20, 2006 at 07:10:02AM -0500, Mike Frysinger wrote: that depends, does your code actually have things like #ifdef DEBUG debug stuff #endif And likewise your code should NOT have some logic like the following in it's build system. if(debug mode) ignore user cflags and use our own cracked out cflags I've seen an upstream configure script where if you tell it you want debug mode, the only thing it does is force CFLAGS to '-O -march=i386' and not strip the binaries itself - this of course failed dismally when you tried to enable debugging on non-x86 platforms. Actually kde (and as such most kde apps) does all kinds of awkward stuff in it's configure script too with respect to adding the --enable-debug flag. Although it mostly involves making the compiler extremely noisy, and forcing in -g flags. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpSbjr63bzpH.pgp Description: PGP signature
Re: [gentoo-dev] Ada compiler: split complete, naming suggestions for gnat-gpl?
On Sunday 15 January 2006 19:54, George Shapovalov wrote: Ok, I got the answer from upstream and, as I expected, 2005 refers to the language specification and is not a release version. Upstream in fact is undecided at this point on what naming/versioning scheme it is going to use, so we need to come up with something.. Then 3.4.5.1 seems as good to me as 2005, probably even better (than the latter) since it is more descriptive (and is in fact easier to follow technically). Alternatively, if you use something low like 0.0_pre20050124, the upgrade path to whatever version name is chosen is easy and uncumbersome. Of course don't do this if it's likely to be years for a proper version to be chosen. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpT5nPWFwCm2.pgp Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
Mike Doty wrote: I think before you go forward with something like this you should give a suitable period of warning, it's going to create a lot of bug work for all of us. Have you seen my daily emails for the past week and a half? =) I have the feeling that it will create the most work for Jakub and whoever besides myself volunteers to help out with the porting. Most other groups, besides games, have very few packages, and if they're feeling lazy, they can just wait a day and get them fixed by us. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
Mark Loeser wrote: On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: What's wrong with the original idea of just making any unported ebuild pull in all of modular X (minus drivers)? Yes, it means that some people will pick up unnecessary deps until all packages are ported, but it avoids anyone having to see flashy red errors. The problem with that is that it removes all motivation to ever port the packages. They'll just stay that way forever, where forever means until I threaten to remove that from the virtual, in which case we'll be in the same scenario we are now. Why? Because people have better things to do than fix stuff that isn't broken. It'd be nice if you reconsidered this as it will minimize any breakage that may occur. Knowing that 800 packages are broken, and going to unmask it knowing that just doesn't seem acceptable in my eyes. ~arch isn't meant to be things are known to be broken. It's meant to mean, we think all of this is ready to be stable, which it certainly won't be in this case. No, it won't. It will just postpone the same breakage, as I said above. You haven't provided any logic or backup to your contrary statement, just said that somehow a large portion of the other 800 will magically get ported. Let me break this down again: of that 800, about 250 are unmaintained packages according to metadata.xml or lack thereof. About 200 are games. About 150 more belong to largely inactive herds. That's roughly 600 that we already know will not get ported in a timely fashion, if left to their maintainers, all because of lack of manpower. What do you propose to deal with them? All I've heard besides mine is proposals that delay the same breakage, not actually get anything fixed. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 2006-24-01 at 13:32 -0800, Donnie Berkholz wrote: Mark Loeser wrote: On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: What's wrong with the original idea of just making any unported ebuild pull in all of modular X (minus drivers)? Yes, it means that some people will pick up unnecessary deps until all packages are ported, but it avoids anyone having to see flashy red errors. The problem with that is that it removes all motivation to ever port the packages. They'll just stay that way forever, where forever means until I threaten to remove that from the virtual, in which case we'll be in the same scenario we are now. Why? Because people have better things to do than fix stuff that isn't broken. It'd be nice if you reconsidered this as it will minimize any breakage that may occur. Knowing that 800 packages are broken, and going to unmask it knowing that just doesn't seem acceptable in my eyes. ~arch isn't meant to be things are known to be broken. It's meant to mean, we think all of this is ready to be stable, which it certainly won't be in this case. No, it won't. It will just postpone the same breakage, as I said above. You haven't provided any logic or backup to your contrary statement, just said that somehow a large portion of the other 800 will magically get ported. Why not just postpone the unmasking by a few days... and lets say give 48h from now for all devs to fix their apps and have the volunteers finish off the rest. Btw, I'll volunteer to help if I have any free time this week. And then the unmasking can be much less painful. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 13:32:00 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: Mark Loeser wrote: On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: What's wrong with the original idea of just making any unported ebuild pull in all of modular X (minus drivers)? Yes, it means that some people will pick up unnecessary deps until all packages are ported, but it avoids anyone having to see flashy red errors. The problem with that is that it removes all motivation to ever port the packages. They'll just stay that way forever, where forever means until I threaten to remove that from the virtual, in which case we'll be in the same scenario we are now. Why? Because people have better things to do than fix stuff that isn't broken. It'd be nice if you reconsidered this as it will minimize any breakage that may occur. Knowing that 800 packages are broken, and going to unmask it knowing that just doesn't seem acceptable in my eyes. ~arch isn't meant to be things are known to be broken. It's meant to mean, we think all of this is ready to be stable, which it certainly won't be in this case. No, it won't. It will just postpone the same breakage, as I said above. You haven't provided any logic or backup to your contrary statement, just said that somehow a large portion of the other 800 will magically get ported. Let me break this down again: of that 800, about 250 are unmaintained packages according to metadata.xml or lack thereof. About 200 are games. About 150 more belong to largely inactive herds. That's roughly 600 that we already know will not get ported in a timely fashion, if left to their maintainers, all because of lack of manpower. What do you propose to deal with them? All I've heard besides mine is proposals that delay the same breakage, not actually get anything fixed. How about delaying it as long as n packages are ported per day? Kinda stupid idea, but it ensures that things won't get hold up due to unmaintained packages/inactive devs and might even speed the process up (that's an illusion probably). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Donnie Berkholz wrote: So here's my plan: Before modular X enters ~arch, I will ensure that all porting bugs blocking #112675 are closed. As new bugs are filed, I will ensure that they are closed within 2 days, giving their maintainers that long to respond and close it themselves. After 2 days, I, or other members of the x11 team and any volunteers, will jump in and fix it ourselves. I've thought a bit about this, and it just doesn't make sense to wait two days. There's no real good reasons why we shouldn't just fix things right away, and it'll probably make a lot of people concerned about ongoing tree breakage happier. Thanks, Donnie Well IMHO, you can do what you want and if any arch team doesn't like it they can always pmask it themselves in their arch profile. I will say I disagree with putting it into ~arch in the current state, although I agree with the rationale, and it IS your package(s), just as it's essentially their arch. I guess the deal here is to not encourage this type of behavior; intentially breaking ~arch all the time and then making the arch teams clean up so to speak. I don't believe this to be the case here, I just don't want to see it become commonplace ;) Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9awSGzglR5RwbyYAQIYAhAAiTkJ8Om/wHwrfdcvfGZbrVhu6glPTz0o 2vcZ2eY1B8ew5RXW9g+/ujZrCS6Bx0Sisi3nIJ94pxvwsmTvTtnKRcmYAZjxnwUD 3XS+UW3bRMjdpxksGeCFsRgq0ji3rwywrJ50DKySKjNMstO5is6ocK1coD3UzKMi /2wF62aV5onaSNGkxjtYAdM7GjkqLAlLNpE4+kUv876E4PZYIvJnBOBssi21xy+Y fsgQ07TGqJLSXZQ0I51ONfYc1H9UZdPyXI96UfFSsohuzIeoi1fyGgB8aNRpDb5v WQWTyM4aVK8vbDWp0k5oVAPva5Uuep0AIrWAr7mUlK8U6kAeCxfMbVQot84qSRlr 7S8uDZY/rvBz4MPh1JlVLuv6t2Q32KpE0S7Y0vIbZTuJCvkYBQL1n9/x0JSCqRLO 0yWg3HfdLD6xrvKOnOxJfQ2SwxzIz6hiaFRIWrqqgqLp5T78arc+9TR41ap8go+E PMVag4J0F5im8RxpDlahdOfsBk6dDANVgtslTwr8lLVoh8x4xjYgUJX+D9gnGGd6 E9UtnHhgnTIgnwr00ounVQlE11248ukze1J43fHomTpm59tMtTZnH/7rQc10BeHH aBPEUCTXotEjKCbgliwr7lHhcjDfhjvVLbxbWZY2w2MGbRMXXMV+1HUoLib5+XGj FO4wGHPXGHg= =2kL5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion
Mike Frysinger wrote: - we add an emerge flag (say '--debug-build') which adds nostrip to FEATURES and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS=-O -g and DEBUG_LDFLAGS=) I'm having a tough time finding this in the thread -- how can I ensure a certain group of packages are always built with debugging, if I don't want my whole box built that way? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: emerge snapshots
On Tue, 24 Jan 2006, Wernfried Haas wrote: - adding buildpkg to your FEATURES builds binary packages, which makes it faster to revert to older versions if the new one cause problems. You could also use quickpkg, i.e. write a script that interates through world and runs quickpkg on each atom. Quickpkg will drop a binary package in PKGDIR (which is set in /etc/make.conf). If you make a backup of PKGDIR and your world file, you have a crude packages backup which can be used to rebuild the box if need be. -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] vpopmail and company
On Tue, 24 Jan 2006, Darryl Wagoner wrote: I just did an emerge --update world which upgraded vpopmail. This update was bad news. It switched vpopmail over to mysql based auths and storage of email which I didn't have mysql or vpopmail setup for. This gave me a lot of grief. Just and FYI. Thats why we have --pretend ;-) -- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] sed vs gsed
I think the time is mature to ask for another step of Gentoo/ALT improvement ;) Currently ebuilds uses a sed syntax that's mostly GNU sed 4 compatible, but incompatible with BSD sed for instance. This is usually fine as we aliases sed to gsed in our bashrc so that the problem in sed calls is removed. The main problem happen with sed when called by xargs or by find, as that ignores the aliases set in bashrc. What I'd like to ask is, if possible, to start using gsed instead, that's present on both GNU and other userlands with current stable version of sed (4.1.4; ppc-macos has no problem as the 4.0.9 version uses gsed anyway). It might require to change the dependency over =sys-apps/sed-4.1.4, but that would help making portage a bit cleaner IMHO (instead of relying on sed being the executable you need, it make sure you're using a GNU sed version) and solves quite a few headaches for us. Comments about this? (Please don't tell me to do a GLEP about this) -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpOMEesMD2cG.pgp Description: PGP signature
Re: [gentoo-dev] RFC: emerge snapshots
A. Khattri wrote: On Tue, 24 Jan 2006, Wernfried Haas wrote: - adding buildpkg to your FEATURES builds binary packages, which makes it faster to revert to older versions if the new one cause problems. You could also use quickpkg, i.e. write a script that interates through world and runs quickpkg on each atom. Quickpkg will drop a binary package in PKGDIR (which is set in /etc/make.conf). If you make a backup of PKGDIR and your world file, you have a crude packages backup which can be used to rebuild the box if need be. Better create the list from /var/db/pkg/* , world file only own the file explicitly merged, leaving out any dependencies (fex libraries). The backup of the world file is still (and more) needed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Tuesday 24 January 2006 18:14, Diego 'Flameeyes' Pettenò wrote: What I'd like to ask is, if possible, to start using gsed instead, that's present on both GNU and other userlands with current stable version of sed (4.1.4; ppc-macos has no problem as the 4.0.9 version uses gsed anyway). if you're implying we change all calls from 'sed' to 'gsed' in ebuilds then the answer is no from my pov -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
Alec Warner wrote: Well IMHO, you can do what you want and if any arch team doesn't like it they can always pmask it themselves in their arch profile. I will say I disagree with putting it into ~arch in the current state, although I agree with the rationale, and it IS your package(s), just as it's essentially their arch. I guess the deal here is to not encourage this type of behavior; intentially breaking ~arch all the time and then making the arch teams clean up so to speak. I don't believe this to be the case here, I just don't want to see it become commonplace ;) I'm certainly not trying to put any extra work on the arch teams; this is conceptually arch-independent, and the only extra work should be on the x11 team and on maintainers of unported apps. But if there are archs that would rather not move to modular X, that's their prerogative. The way I look at it is, sometimes change comes at a price. I really hope they aren't any archs I use though, because I take a certain amount of pride in making the best and newest X available. When people remask it, it's like they're directly battling against the whole reason I'm involved in Gentoo. Thanks, Donnei signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
maillog: 24/01/2006-12:25:01(-0500): Mark Loeser types Donnie Berkholz [EMAIL PROTECTED] said: Ciaran McCreesh wrote: On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Here's my proposal for dealing with modular X entering ~arch. What's wrong with the original idea of just making any unported ebuild pull in all of modular X (minus drivers)? Yes, it means that some people will pick up unnecessary deps until all packages are ported, but it avoids anyone having to see flashy red errors. The problem with that is that it removes all motivation to ever port the packages. They'll just stay that way forever, where forever means until I threaten to remove that from the virtual, in which case we'll be in the same scenario we are now. Why? Because people have better things to do than fix stuff that isn't broken. It'd be nice if you reconsidered this as it will minimize any breakage that may occur. Knowing that 800 packages are broken, and going to unmask it knowing that just doesn't seem acceptable in my eyes. ~arch isn't meant to be things are known to be broken. It's meant to mean, we think all of this is ready to be stable, which it certainly won't be in this case. Don't let the numbers trick you, guys. Everything in app-xemacs/ is in that list only because xemacs is broken. Fix that one package and you get 115 packages done. I wonder how many others are like that. -- \Georgi Georgiev \ Professor: Now, be careful, Fry. And if \ / [EMAIL PROTECTED]/ you kill anyone, make sure to eat their/ \ http://www.gg3.net/ \ heart to gain their courage. Their rich\ / --- / tasty courage. / pgp8GtGOVpqyz.pgp Description: PGP signature
Re: [gentoo-dev] RFC: emerge snapshots
On Tue, 24 Jan 2006, Francesco Riosa wrote: Better create the list from /var/db/pkg/* , world file only own the file explicitly merged, leaving out any dependencies (fex libraries). Yes you're right - that is what I did last time I played with this. -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Wed, 25 Jan 2006 00:14:13 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: Comments about this? (Please don't tell me to do a GLEP about this) We've discussed this several times in the past, and every time the answer has been that in the ebuild environment `sed` is gnu sed-4. It's the only sane way to do things, since certain other platforms ship retarded versions of sed. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
Robin H. Johnson wrote: On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote: A) You have commit access to gentoo-x86, AND B) you're comfortable with the porting process OR are adept with ebuilds and would like to help I'm up for being a volunteer here. All devs who've volunteered, please /j #gentoo-x on IRC. We're collaborating there, and trying to avoid working on the same packages twice. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 00:32, Mike Frysinger wrote: if you're implying we change all calls from 'sed' to 'gsed' in ebuilds then the answer is no from my pov Can you at least read all my mails till the end before replying next time? I was referring mainly to the ones that calls sed from find and xargs and similar, the rest are a problem that's already worked around and for now is fine as they are. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpYzpSjMgMeO.pgp Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 00:48, Stephen Bennett wrote: We've discussed this several times in the past, and every time the answer has been that in the ebuild environment `sed` is gnu sed-4. It's the only sane way to do things, since certain other platforms ship retarded versions of sed. And as there's no current way to fix the invokation of sed from within xargs or find, I'm not going to ask to change _all_ the calls of sed, but just the ones done through those two or other scripts and things that won't honour aliases in bashrc. I have to remember you that the discussions in the past often asked us to redo things after a while. Being more strict and safe on the environment (wrt to find and xargs) is IMHO helping; there are already things that are more or less encapsulated and would be simple to get around (think of patch/gpatch that's encapsulated to epatch) if we really need to. But find, xargs and in general subshells not honouring bashrc are the main big problem. Other suggestions are of course welcome, if you have something constructive to say about that. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpQ93B5zYAwv.pgp Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Tuesday 24 January 2006 19:13, Diego 'Flameeyes' Pettenò wrote: On Wednesday 25 January 2006 00:32, Mike Frysinger wrote: if you're implying we change all calls from 'sed' to 'gsed' in ebuilds then the answer is no from my pov Can you at least read all my mails till the end before replying next time? it wouldnt matter in this case -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Tuesday 24 January 2006 19:17, Diego 'Flameeyes' Pettenò wrote: On Wednesday 25 January 2006 00:48, Stephen Bennett wrote: We've discussed this several times in the past, and every time the answer has been that in the ebuild environment `sed` is gnu sed-4. It's the only sane way to do things, since certain other platforms ship retarded versions of sed. And as there's no current way to fix the invokation of sed from within xargs or find yes there is add a 'sed' wrapper to the portage bin dir which simply does: exec gsed $@ , I'm not going to ask to change _all_ the calls of sed, but just the ones done through those two or other scripts and things that won't honour aliases in bashrc. that's a pita -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion
On Tuesday 24 January 2006 17:56, Donnie Berkholz wrote: Mike Frysinger wrote: - we add an emerge flag (say '--debug-build') which adds nostrip to FEATURES and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS=-O -g and DEBUG_LDFLAGS=) I'm having a tough time finding this in the thread -- how can I ensure a certain group of packages are always built with debugging, if I don't want my whole box built that way? that would require per-package env: http://bugs.gentoo.org/show_bug.cgi?id=44796 at which point you would just add 'FEATURES=debug-build' to whatever packages you want -mike -- gentoo-dev@gentoo.org mailing list
Re: Environement categories (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Tuesday 24 January 2006 01:44, Brian Harring wrote: Might I suggest this one just get shelved for a while? everything that gets shelved portage way stays that way for *quite* a while i would be ok with implementing the back end (i.e. FEATURES=debug-build) but putting off the front end (i.e. emerge --debug-build) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Mon, 23 Jan 2006 23:33:32 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | What's wrong with the original idea of just making any unported | ebuild pull in all of modular X (minus drivers)? Yes, it means that | some people will pick up unnecessary deps until all packages are | ported, but it avoids anyone having to see flashy red errors. | | The problem with that is that it removes all motivation to ever port | the packages. They'll just stay that way forever, where forever means | until I threaten to remove that from the virtual, in which case | we'll be in the same scenario we are now. Why? Because people have | better things to do than fix stuff that isn't broken. Ok. So... As far as I can see: * There is a clean upgrade solution available that will result in non-ported packages merely pulling in a load of extra unnecessary packages (that non-modular users have anyway). * The clean solution visibly illustrates that a package is unported. Users who are running ~arch can clearly see this, and can file bugs and (if they care) attempt a --nodeps installation. The bugs can be picked up by the package maintainers or the volunteers on this list. * The clean solution is the solution originally proposed to this list, and the reason we are using new style virtuals. * There is an alternate upgrade solution that means that any users who have an unported package will get their screen filled with several pages of incomprehensible bright red crap. * There are currently enough unported packages that many ~arch users will probably have one or two installed (assumption: many users have several utterly random non-mainstream packages installed). * Despite your original assurances to this list, you intend to go ahead and take the alternate solution, which will lead to one of the most user visible and hardest to fix breakages we've ever had. * You are doing this because you believe that it is better to get every package ported over extremely quickly rather than having the odd package with extra unnecessary listed dependencies, and you do not consider the impact upon our users to be relevant. Is my understanding correct? -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Wed, 25 Jan 2006 01:17:23 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | And as there's no current way to fix the invokation of sed from | within xargs or find, I'm not going to ask to change _all_ the calls | of sed, but just the ones done through those two or other scripts and | things that won't honour aliases in bashrc. If there are any hardcoded calls to /usr/bin/sed, it is reasonable for you to ask for them to be fixed. For any others, use a wrapper script. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] sed vs gsed
maillog: 25/01/2006-00:14:13(+0100): Diego 'Flameeyes' Pettenò types What I'd like to ask is, if possible, to start using gsed instead, that's present on both GNU and other userlands with current stable version of sed (4.1.4; ppc-macos has no problem as the 4.0.9 version uses gsed anyway). Am I stupid or did I miss something? [EMAIL PROTECTED] ~ $ emerge -p sed These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-apps/sed-4.1.4 [EMAIL PROTECTED] ~ $ gsed bash: gsed: command not found -- () Georgi Georgiev () Politicians should read science fiction, () ()[EMAIL PROTECTED]() not westerns and detective stories. -- () () http://www.gg3.net/ () Arthur C. Clarke () pgpp1yDakFigX.pgp Description: PGP signature
[gentoo-dev] Re: Unmasking modular X
Wernfried Haas posted [EMAIL PROTECTED], excerpted below, on Tue, 24 Jan 2006 19:52:29 +0100: On Tue, Jan 24, 2006 at 01:44:28PM -0500, Mark Loeser wrote: We should aim for when it will be done in a way that minimizes the breakage for all of our users. Yes, breakage will happen, but we can wait until its down to a more reasonable value. And we probably should announce somewhere that this is going to happen (if not done already, haven't been following the modular X thing too closely). There has been some coverage in GWN. Readers know modular-X is coming, have been invited to test it, and know how to get to it now (the modular-X HOWTO was linked), along with the fact that it's a big change and may cause some breakage. However, I do NOT believe a specific warning was given that it's going to happen on $DATE and ~arch users should know there might be a bit of breakage at that time. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 15:35:07 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: But if there are archs that would rather not move to modular X, that's their prerogative. The way I look at it is, sometimes change comes at a price. I really hope they aren't any archs I use though, because I take a certain amount of pride in making the best and newest X available. When people remask it, it's like they're directly battling against the whole reason I'm involved in Gentoo. As an arch team, SPARC would like to move to modular X. However if packages are broken by this unmasking, it *will* be masked on SPARC until such a time that this is fixed. Also a complaint will be filed with developer relations and QA as this blatantly and knowingly defies the policies regarding keywording that were put in place to intentionally prohibit this kind of behavior. I'm not trying to be a party pooper here, but breaking the portage tree should never be an acceptable answer. Cheers, -- Jason Wever Gentoo/Sparc Team Co-Lead signature.asc Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 00:16, Georgi Georgiev wrote: maillog: 25/01/2006-00:14:13(+0100): Diego 'Flameeyes' Pettenò types What I'd like to ask is, if possible, to start using gsed instead, that's present on both GNU and other userlands with current stable version of sed (4.1.4; ppc-macos has no problem as the 4.0.9 version uses gsed anyway). Am I stupid or did I miss something? well, i cant really verify you arent stupid, but ... [ebuild R ] sys-apps/sed-4.1.4 [EMAIL PROTECTED] ~ $ gsed bash: gsed: command not found Diego was mistaken here ... probably my fault because i lied to him at some point on irc, who knows for sure ... at any rate, the sed ebuild does not install 'gsed' on GNU systems -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 23:00:14 -0700 Joshua Baergen [EMAIL PROTECTED] wrote: | To be clear here: nothing will be broken. Xorg 7.0 will just not | provide virtual/x11 (and in fact blocks it), so there will be issues | with blocks showing up due to the upgrade path. Avoiding the upgrade | (and blockage) is very easy if necessary (eg, you use 200 unported | packages or something). That is exactly the issue. Your average ~arch user is going to get pages and pages of nasty red incomprehensible blocks simply because you're making Xorg 7 block the virtual rather than provide it. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
Ciaran McCreesh wrote: On Tue, 24 Jan 2006 23:00:14 -0700 Joshua Baergen [EMAIL PROTECTED] wrote: | To be clear here: nothing will be broken. Xorg 7.0 will just not | provide virtual/x11 (and in fact blocks it), so there will be issues | with blocks showing up due to the upgrade path. Avoiding the upgrade | (and blockage) is very easy if necessary (eg, you use 200 unported | packages or something). That is exactly the issue. Your average ~arch user is going to get pages and pages of nasty red incomprehensible blocks simply because you're making Xorg 7 block the virtual rather than provide it. Where are you getting this idea of pages and pages? Your previous statement was that the average ~arch users would likely have a couple of unported apps. Unless they're using 1-line terminals, this just doesn't translate to pages and pages for me. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
Ciaran McCreesh wrote: * There is a clean upgrade solution available that will result in non-ported packages merely pulling in a load of extra unnecessary packages (that non-modular users have anyway). * The clean solution visibly illustrates that a package is unported. Users who are running ~arch can clearly see this, and can file bugs and (if they care) attempt a --nodeps installation. The bugs can be picked up by the package maintainers or the volunteers on this list. Yes, for all 3 people who have a clue what it means when virtual/x11 gets pulled in. How many users do you seriously think will have a clue and think Oh, virtual/x11 is getting pulled in here. I must have a package that isn't ported to modular X somewhere in this list. Let me track it down and file a bug.? * The clean solution is the solution originally proposed to this list, and the reason we are using new style virtuals. No, this is wrong. The reason we are using new style virtuals is so we could have a versioning in what provides virtual/x11. Namely, 6.8 or older. * There is an alternate upgrade solution that means that any users who have an unported package will get their screen filled with several pages of incomprehensible bright red crap. Several pages? How is that coming from a single unported package? Also, it's not incomprehensible and shouldn't be to anyone on ~arch (or frankly, anywhere), because packages involving blockers regularly have to be dealt with. * There are currently enough unported packages that many ~arch users will probably have one or two installed (assumption: many users have several utterly random non-mainstream packages installed). Possible, but we can't prove this one way or the other. Certainly very few modular X users have encountered apps that are still unported, as evidenced by very few remaining blockers on #112675. And there are a fairly large number of * Despite your original assurances to this list, you intend to go ahead and take the alternate solution, which will lead to one of the most user visible and hardest to fix breakages we've ever had. Yes, I suggested handling this differently back in early August, when these things were in the planning stage. But even later that month, I posted saying that wasn't the best way to handle it. It's not difficult to imagine that things can change over the course of 6 months. * You are doing this because you believe that it is better to get every package ported over extremely quickly rather than having the odd package with extra unnecessary listed dependencies, and you do not consider the impact upon our users to be relevant. I consider ~arch users to have agreed to help test and fix new things. This is included. I would not do the same thing to our stable tree, or if we only had a stable tree. Yes, I do think it is better to have a quick solution and let some of our ~arch users see a couple of blocks, for which they will file bugs. Then these bugs will be fixed within a day, and those users will again have working systems. I don't see what the big deal is. By being ~arch users, they're already asking to use ebuilds that have a chance of breaking their systems permanently, let alone a single 'emerge sync'. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
Donnie Berkholz wrote: Possible, but we can't prove this one way or the other. Certainly very few modular X users have encountered apps that are still unported, as evidenced by very few remaining blockers on #112675. And there are a fairly large number of ... people using modular X already, from personal reports to me as well as reporters and CC members on modular X-related bug reports. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
Donnie Berkholz wrote: Please contact me if you'd like to be one of these volunteers. Requirements: A) You have commit access to gentoo-x86, AND B) you're comfortable with the porting process OR are adept with ebuilds and would like to help I've decided to give it a wait for a few days until unmasking while our new porting task force tears through lots of packages. With the task force, I feel enough visible, reasonable progress is being made to help me avoid being frustrated with the people saying I should wait for something that would never happen. If you want to join the task force, just hop on IRC and /j #gentoo-x. We can always use more help. Right now, we've got 12 people in there. Also, Robin's created a new script to tell exactly which apps are broken with modular X, and which ones only have something in their dep tree broken. A run of this script on yesterday's results shows that there are only 558 real broken modular packages out of 867 total. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Yes, for all 3 people who have a clue what it means when virtual/x11 | gets pulled in. How many users do you seriously think will have a clue | and think Oh, virtual/x11 is getting pulled in here. I must have a | package that isn't ported to modular X somewhere in this list. Let me | track it down and file a bug.? When users suddenly see lots of extra X packages being pulled in that they don't need, it'll be rather obvious (and trivial to track down with --tree). Especially if it's documented somewhere that packages that suddenly pull in lots of extra X packages usually means porting needed. | * The clean solution is the solution originally proposed to this | list, and the reason we are using new style virtuals. | | No, this is wrong. The reason we are using new style virtuals is so we | could have a versioning in what provides virtual/x11. Namely, 6.8 or | older. Uh, given that you can do that with old style virtuals, methinks that isn't the case... | * There are currently enough unported packages that many ~arch users | will probably have one or two installed (assumption: many users have | several utterly random non-mainstream packages installed). | | Possible, but we can't prove this one way or the other. Certainly very | few modular X users have encountered apps that are still unported, as | evidenced by very few remaining blockers on #112675. Sure, but that's because there are relatively few users using hard masked packages. When you add it to ~arch the number will go up massively. | * You are doing this because you believe that it is better to get | every package ported over extremely quickly rather than having the | odd package with extra unnecessary listed dependencies, and you do | not consider the impact upon our users to be relevant. | | I consider ~arch users to have agreed to help test and fix new things. | This is included. I would not do the same thing to our stable tree, or | if we only had a stable tree. | | Yes, I do think it is better to have a quick solution and let some of | our ~arch users see a couple of blocks, for which they will file bugs. | Then these bugs will be fixed within a day, and those users will again | have working systems. ...or you could do things as originally planned, and have no non-working systems at all and the only consequences for end users will be a small number of extra packages (that they previously had installed anyway as part of hugeass X) being pulled in. | I don't see what the big deal is. By being ~arch users, they're | already asking to use ebuilds that have a chance of breaking their | systems permanently, let alone a single 'emerge sync'. They are asking to use ebuilds that may have undetected issues. They are not asking to use things that we know fine well are broken. ~arch is for will hopefully go stable after further testing, not stuff that has a very high chance of screwing you over. You're deliberately causing nasty problems for ~arch users when there's a very easy, clean workaround with far lower consequences and the same end result. This is unacceptable. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Re: coreutils: deprecated behavior not so deprecated
Mike Frysinger wrote:
note: for those who think they can argue for support of these features to
be kept in Gentoo, you're barking up the wrong tree so dont waste your
time -mike
So, um, when can we expect all hell to break loose? Just a quick check on
my laptop:
media-video/mjpegtools-1.8.0-r1 (/usr/bin/anytovcd.sh)
77:awk '$4 == build {print $5}' | sed s/,// | head -1`
85:awk '/Audio:/ {print $8}' | head -${2} | tail -1`
93:awk '/Audio:/ {print $4}' | sed s/,// | head -${2} | tail -1`
101:awk '/Audio:/ {print $5}' | sed s/,// | head -${2} | tail -1`
107:echo `head -1 /tmp/tmp.y4m | awk '{print $4}' | cut -c 2-`
114:echo `head -1 /tmp/tmp.y4m | awk '{print $5}' | cut -c 2-`
121:echo `head -1 /tmp/tmp.y4m | awk '{print $6}' | cut -c 2-`
128:echo `head -1 /tmp/tmp.y4m | awk '{sub(W,,$2); sub(H,,$3);
print $2x$3}'`
135:awk '/Video:/ {print $4}' | sed s/,// | head -1`
327:FFMPEG_AUD_TRACK=`${FFMPEG} -i \${AUDIO_SRC}\ 21 | awk '/Audio:/
{sub(^#,,$2); print $2}' | awk -F[ '{print $1}' | head -${AUD_TRACK} |
tail -1`
gnome-base/gnome-libs-1.4.2 (/usr/bin/gnome-bug)
181:( [ -f /etc/SuSE-release ] head -1 /etc/SuSE-release) || \
media-video/xine-ui-0.99.3-r1 (/usr/bin/xine-bugreport)
613:short=`head -1 $tmpfile`
906:xine_executable=`echo $xine_executable1 | head -1`
925:xine_config=`echo $xine_configs | head -1`
935: xine_config=`echo $xine_configs | head -1`
1105: hdparm=`echo $found|head -1`
1148: xvinfo=`echo $found|head -1`
1149: XVIDEO=`$xvinfo|head -1`
1390: mailer=`echo $found|head -1`
media-video/xine-ui-0.99.3-r1 (/usr/bin/xine-check)
613:short=`head -1 $tmpfile`
906:xine_executable=`echo $xine_executable1 | head -1`
925:xine_config=`echo $xine_configs | head -1`
935: xine_config=`echo $xine_configs | head -1`
1105: hdparm=`echo $found|head -1`
1148: xvinfo=`echo $found|head -1`
1149: XVIDEO=`$xvinfo|head -1`
1390: mailer=`echo $found|head -1`
kde-base/kdenetwork-3.5.0 (/usr/kde/3.5/bin/krfb_httpd)
23: size=`xdpyinfo -display :0| grep dimensions:|head -1|sed -e
s/.*dimensions: *// -e s/ pixels.*//`
dev-php/php-4.4.0-r4 (/usr/lib/php/build/libtool.m4)
3358:
lt_cv_file_magic_test_file=`echo
/System/Library/Frameworks/System.framework/Versions/*/System
| head -1`
sys-apps/portage-2.0.54 (/usr/lib/portage/bin/find-requires)
28: head -1 $f | sed -e 's/^\#\![ ]*//' | cut -d -f1
dev-lang/python-2.4.2 (/usr/lib/python2.4/test/test_itertools.py)
114:# sort s | uniq -c | sort -rn | head -3
app-emulation/cedega-5.0.1 (/usr/lib/transgaming_cedega/system_detection.py)
207:pipeFile = os.popen(head -1 + filename)
gnome-base/gnome-vfs-1.0.5-r4 (/usr/lib/vfs/extfs/trpm)
151:name=`head -1 $name`
net-analyzer/nagios-plugins-1.4.2 (/usr/nagios/libexec/check_oracle)
183:loginchk3=` echo $loginchk | grep ORA- | head -1`
204: error=` echo $result | grep ORA- | head -1`
219: error=` echo $result | grep ORA- | head -1`
257: error=` echo $result | grep ORA- | head -1`
net-analyzer/nagios-plugins-1.4.2 (/usr/nagios/libexec/contrib/aix/check_io)
53: DATA=`head -1 /tmp/iotest.hndl`
net-analyzer/nagios-plugins-1.4.2
(/usr/nagios/libexec/contrib/aix/check_queue)
53: DATA=`head -1 /tmp/qtmp.hndl`
app-arch/tar-1.15.1 (/usr/sbin/backup-tar)
127:head -1|
app-arch/tar-1.15.1 (/usr/sbin/backup.sh)
263:| head -1 \
sys-kernel/gentoo-sources-2.6.14-r5
(/usr/src/linux-2.6.14-gentoo-r5/arch/frv/Makefile)
26:CCSPECS := $(shell $(CC) -v 21 | grep ^Reading specs from |
head -1 | cut -c20-)
sys-kernel/gentoo-sources-2.6.14-r5
(/usr/src/linux-2.6.14-gentoo-r5/drivers/char/speakup/install)
3:VERSION=v`head -2 /usr/src/linux/Makefile | \
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 15:53, Ciaran McCreesh wrote: On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | * The clean solution is the solution originally proposed to this | list, and the reason we are using new style virtuals. | | No, this is wrong. The reason we are using new style virtuals is so we | could have a versioning in what provides virtual/x11. Namely, 6.8 or | older. Uh, given that you can do that with old style virtuals, methinks that isn't the case... Only by modifying every ebuild that has a virtual/x11 dependency. The atom virtual/x11 cannot be limited to specific versions on its own with old style virtuals. | * You are doing this because you believe that it is better to get | every package ported over extremely quickly rather than having the | odd package with extra unnecessary listed dependencies, and you do | not consider the impact upon our users to be relevant. | | I consider ~arch users to have agreed to help test and fix new things. | This is included. I would not do the same thing to our stable tree, or | if we only had a stable tree. | | Yes, I do think it is better to have a quick solution and let some of | our ~arch users see a couple of blocks, for which they will file bugs. | Then these bugs will be fixed within a day, and those users will again | have working systems. ...or you could do things as originally planned, and have no non-working systems at all and the only consequences for end users will be a small number of extra packages (that they previously had installed anyway as part of hugeass X) being pulled in. The premise for not doing this is that packages will never be fixed, right? Why not make the modular X provide virtual/x11 and just institute a policy that no new packages can go into stable with a virtual/x11 dependency? It could even be easily enforcable if necessary. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
Ciaran McCreesh wrote: On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Yes, for all 3 people who have a clue what it means when virtual/x11 | gets pulled in. How many users do you seriously think will have a clue | and think Oh, virtual/x11 is getting pulled in here. I must have a | package that isn't ported to modular X somewhere in this list. Let me | track it down and file a bug.? When users suddenly see lots of extra X packages being pulled in that they don't need, it'll be rather obvious (and trivial to track down with --tree). Especially if it's documented somewhere that packages that suddenly pull in lots of extra X packages usually means porting needed. Where do they define lots? Many packages will legitimately pull in a large quantity of libs or apps that are not installed by someone emerging xorg-server, e.g. | * The clean solution is the solution originally proposed to this | list, and the reason we are using new style virtuals. | | No, this is wrong. The reason we are using new style virtuals is so we | could have a versioning in what provides virtual/x11. Namely, 6.8 or | older. Uh, given that you can do that with old style virtuals, methinks that isn't the case... Really? It's certainly not made clear. Has the ability existed for long? I can only find a single example of it in the virtuals files, which was added last summer. I don't make a habit of browsing through profiles every few months to see whether some new undocumented feature has appeared. There are no existing examples anywhere in the documentation I've seen, and only a vague hint that virtuals could be any DEPEND atom. Given that virtual dependencies couldn't work properly with versions, it was a carryover that virtuals could also not be provided by versioned things. I guarantee you that adding all of modular X to the virtual/x11 will make this drag out for years, and THAT is unacceptable to me. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
Jason Stubbs wrote: Only by modifying every ebuild that has a virtual/x11 dependency. The atom virtual/x11 cannot be limited to specific versions on its own with old style virtuals. Is that so? I guess this must be wrong, then: /usr/portage/profiles/base/virtuals:# Only have this for =pam-0.78, as we want to make use of the 'include' /usr/portage/profiles/base/virtuals:virtual/pam =sys-libs/pam-0.78 The premise for not doing this is that packages will never be fixed, right? Why not make the modular X provide virtual/x11 and just institute a policy that no new packages can go into stable with a virtual/x11 dependency? It could even be easily enforcable if necessary. How does that fix the stale, unmaintained here and upstream apps that are in stable now and have no ~arch ebuilds? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
On Wed, 25 Jan 2006 16:08:07 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Uh, given that you can do that with old style virtuals, methinks | that isn't the case... | | Only by modifying every ebuild that has a virtual/x11 dependency. The | atom virtual/x11 cannot be limited to specific versions on its own | with old style virtuals. Oh? There's at least one old style virtual that specifies a full dep atom rather than a package name. I know this because it broke my first virtuals parser that was expecting a straight name... | The premise for not doing this is that packages will never be fixed, | right? Why not make the modular X provide virtual/x11 and just | institute a policy that no new packages can go into stable with a | virtual/x11 dependency? It could even be easily enforcable if | necessary. Much more sensible. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: Environement categories (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Tue, Jan 24, 2006 at 08:06:12PM -0500, Mike Frysinger wrote: On Tuesday 24 January 2006 01:44, Brian Harring wrote: Might I suggest this one just get shelved for a while? everything that gets shelved portage way stays that way for *quite* a while If people don't give a damn about it, yes, that's true. Not the case here. i would be ok with implementing the back end (i.e. FEATURES=debug-build) but putting off the front end (i.e. emerge --debug-build) Front-end doesn't matter, it's the back-end that's the concern. Clean up the backend in stable, and it's fine- hence the shelve it; fix the backend instead of tagging it half way in. ~harring pgpnXO9Ud50CA.pgp Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 23:16:38 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Where do they define lots? Many packages will legitimately pull in a | large quantity of libs or apps that are not installed by someone | emerging xorg-server, e.g. Heck, add in a non-ported-package fake package hack if you really think ~arch users will have a hard time telling. | I guarantee you that adding all of modular X to the virtual/x11 will | make this drag out for years, and THAT is unacceptable to me. Why must it drag out for years? There's no difference in the speed of porting between the solutions. The only difference is the impact upon end users. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
Ciaran McCreesh wrote: On Tue, 24 Jan 2006 23:16:38 -0800 Donnie Berkholz | I guarantee you that adding all of modular X to the virtual/x11 will | make this drag out for years, and THAT is unacceptable to me. Why must it drag out for years? There's no difference in the speed of porting between the solutions. The only difference is the impact upon end users. And impact creates motivation. If it isn't literally broken, 95% of devs just have better things to do than fix it. Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 16:19, Donnie Berkholz wrote: Jason Stubbs wrote: Only by modifying every ebuild that has a virtual/x11 dependency. The atom virtual/x11 cannot be limited to specific versions on its own with old style virtuals. Is that so? I guess this must be wrong, then: /usr/portage/profiles/base/virtuals:# Only have this for =pam-0.78, as we want to make use of the 'include' /usr/portage/profiles/base/virtuals:virtual/pam =sys-libs/pam-0.78 Yep, portage simply removes the = and 0.78 parts and makes all versions of sys-libs/pam a provider of virtual/pam. Why there is no warning I don't know. The premise for not doing this is that packages will never be fixed, right? Why not make the modular X provide virtual/x11 and just institute a policy that no new packages can go into stable with a virtual/x11 dependency? It could even be easily enforcable if necessary. How does that fix the stale, unmaintained here and upstream apps that are in stable now and have no ~arch ebuilds? It wouldn't, but at least there'd be fewer packages to deal with in the final cleanup. It was just an innocent question though; as far as I can tell, emerging any application (ported or not) on a clean system will not break even after modular X is unmasked. It's a fine line between whether packages needlessly not working together due to incompatible (deep) dependencies is considered breakage or not though... /me steps away from the flames for fear of getting burned. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
Ciaran McCreesh wrote: On Wed, 25 Jan 2006 16:08:07 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | The premise for not doing this is that packages will never be fixed, | right? Why not make the modular X provide virtual/x11 and just | institute a policy that no new packages can go into stable with a | virtual/x11 dependency? It could even be easily enforcable if | necessary. Much more sensible. I've thought some about this. It would be acceptable to me for virtual/x11 to provide modular X deps, if we also instituted a repoman death upon any attempt to commit to a directory for which the best visible package is broken. This will accomplish the goal of discovering completely unmaintained packages but will fail in the goal of discovering which packages nobody uses. They'll still continue to rot in the tree, unmaintained, unused and taking up space in everybody's syncs. How's that sound? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 23:34:49 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Tue, 24 Jan 2006 23:16:38 -0800 Donnie Berkholz | | I guarantee you that adding all of modular X to the virtual/x11 | | will make this drag out for years, and THAT is unacceptable to me. | | Why must it drag out for years? There's no difference in the speed | of porting between the solutions. The only difference is the impact | upon end users. | | And impact creates motivation. If it isn't literally broken, 95% of | devs just have better things to do than fix it. This does not give you the right to deliberately break things for our users. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Order of operations: buildpkg
Mike Frysinger wrote: On Monday 23 January 2006 15:55, Simon Stelling wrote: Lares Moreau wrote: Many ebuilds fail due to failed QA. How difficult would it be to have the package create the tarball before the QA tests. If this were possible, QA could be slightly quicker, as there would be no need to rebuild the entire package, with features disabled, upon failure. I think you rather want to use FEATURES=keepwork than doing such ugly stuff. keepwork wouldnt accomplish anything wrt to what he wants this would prob do it though: ebuild ebuild install package qmerge Indeed, could someone shade a light on what happen to /var/db/pkg and world file when using ebuild this manner ? Could be rephrased as Does it act exactly the same way emerge does ? -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [gentoo-dev-portage] [PATCH] prevent world file corruption by writing atomically
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, There is dangerous handling of world file updates throughout portage. The attached patch wraps all world file updates in a write_atomic() function which is designed to prevent interprocess interference and prevent corruption when an 'out of space' error occurs. Brian pointed out that portage_util.writedict() already does a similar routine, but it is designed exclusively to write a dictionary object. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD1en2/ejvha5XGaMRAiWdAJ9z8qD4NAO5wj7kYnZOa8qSS1YTTACaAlFz uBy7olGkiAlYweTNv1iu0OY= =CJPG -END PGP SIGNATURE- Index: portage-2.1_pre/pym/portage_util.py === --- portage-2.1_pre.orig/pym/portage_util.py +++ portage-2.1_pre/pym/portage_util.py @@ -452,3 +452,31 @@ def unique_array(s): u.append(x) return u +def write_atomic(file_path, content): + Write a file atomically via os.rename(). Atomic replacement prevents + interprocess interference and prevents corruption of the target + file when an 'out of space' error occurs. + mystat = os.stat(file_path) + dirname,basename = os.path.split(file_path) + tmp_path=None + fd=None + try: + import tempfile + fd, tmp_path = tempfile.mkstemp(prefix=basename, dir=dirname) + os.write(fd,content) + os.close(fd) + os.chown(tmp_path, mystat.st_uid, mystat.st_gid) + os.chmod(tmp_path, mystat.st_mode) + os.rename(tmp_path,file_path) + finally: + # Make sure we've cleaned up even if an exception is raised. + if fd: + try: +os.close(fd) + except OSError, oe: +pass + if tmp_path: + try: +os.unlink(tmp_path) + except OSError, oe: +pass Index: portage-2.1_pre/pym/portage.py === --- portage-2.1_pre.orig/pym/portage.py +++ portage-2.1_pre/pym/portage.py @@ -5850,10 +5850,7 @@ class dblink: os.chown(pdir, 0, portage_gid) os.chmod(pdir, 02770) - myworld=open(self.myroot+WORLD_FILE,w) - for x in newworldlist: -myworld.write(x+\n) - myworld.close() + portage_util.write_atomic(os.path.join(self.myroot,WORLD_FILE),\n.join(newworldlist)) #do original postrm if myebuildpath and os.path.exists(myebuildpath): @@ -6862,10 +6859,7 @@ def do_upgrade(mykey): if processed: #update our internal mtime since we processed all our directives. mtimedb[updates][mykey]=os.stat(mykey)[stat.ST_MTIME] - myworld=open(/+WORLD_FILE,w) - for x in worldlist: - myworld.write(x+\n) - myworld.close() + portage_util.write_atomic(WORLD_FILE,\n.join(worldlist)) print def commit_mtimedb(): Index: portage-2.1_pre/bin/emaint === --- portage-2.1_pre.orig/bin/emaint +++ portage-2.1_pre/bin/emaint @@ -6,7 +6,7 @@ from optparse import OptionParser, Optio import re -import os, portage, portage_const +import os, portage, portage_const, portage_util class WorldHandler(object): def name(): @@ -39,7 +39,7 @@ class WorldHandler(object): def fix(self): errors = [] try: - open(portage_const.WORLD_FILE, w).write(\n.join(self.okay)) + portage_util.write_atomic(portage_const.WORLD_FILE,\n.join(self.okay)) except OSError: errors.append(portage_const.WORLD_FILE + could not be opened for writing) return errors Index: portage-2.1_pre/bin/regenworld === --- portage-2.1_pre.orig/bin/regenworld +++ portage-2.1_pre/bin/regenworld @@ -6,7 +6,7 @@ import sys sys.path.insert(0, /usr/lib/portage/pym) -import portage, string, re +import portage, portage_util, string, re __candidatematcher__ = re.compile(^[0-9]+: \\*\\*\\* emerge ) __noncandidatematcher__ = re.compile( sync( |$)| clean( |$)| search( |$)|--oneshot| unmerge( |$)) @@ -88,6 +88,4 @@ for mykey in biglist: print add to world:,myfavkey worldlist.append(myfavkey) -myfile=open(portage.WORLD_FILE, w) -myfile.write(string.join(worldlist, '\n')+'\n') -myfile.close() +portage_util.write_atomic(portage.WORLD_FILE,\n.join(worldlist)) Index: portage-2.1_pre/bin/emerge === --- portage-2.1_pre.orig/bin/emerge +++ portage-2.1_pre/bin/emerge @@ -1904,7 +1904,7 @@ class depgraph: myfavdict[myfavkey]=myfavkey print Recording,myfavkey,in \world\ favorites file... if not --fetchonly in myopts: -portage.writedict(myfavdict,portage.root+portage.WORLD_FILE,writekey=0) +portage_util.write_atomic(os.path.join(portage.root,portage.WORLD_FILE),\n.join(myfavdict.values())) portage.mtimedb[resume][mergelist]=mymergelist[:] @@ -2075,7 +2075,7 @@ class depgraph: myfavdict[myfavkey]=myfavkey print Recording,myfavkey,in \world\ favorites file... emergelog( === (+str(mergecount)+ of +str(len(mymergelist))+) Updating world file (+x[pkgindex]+)) -
[gentoo-portage-dev] confcache integration
Yo.
Looking to integrate confcache support into trunk some time in the
near future- had users testing it for about 2 months (give or take),
so far it's behaved pretty decently. A few packages eat themselves
when ran with --cache (bad autotooling), hence the addition of
restrict=confcache being added to the patch.
Either way, patch is attached, looking for any complaints regarding it
(or integrating confcache)- will be sending an email off to gentoo-dev
in the next few days to get feedback from the general dev populace,,
but sending this email to get feedback on the implementation in the
meantime.
~harring
Index: pym/portage.py
===
--- pym/portage.py (revision 2490)
+++ pym/portage.py (working copy)
@@ -2660,7 +2660,30 @@
print !!! Perhaps: rm -Rf,mysettings[BUILD_PREFIX]
print !!!,str(e)
return 1
-
+ try:
+ if confcache in features:
+ if not mysettings.has_key(CONFCACHE_DIR):
+ mysettings[CONFCACHE_DIR] =
os.path.join(mysettings[PORTAGE_TMPDIR], confcache)
+ if not
os.path.exists(mysettings[CONFCACHE_DIR]):
+
os.makedirs(mysettings[CONFCACHE_DIR], mode=0775)
+ os.chown(mysettings[CONFCACHE_DIR],
portage_uid, -1)
+ else:
+ st =
os.stat(mysettings[CONFCACHE_DIR])
+ if not (st.st_mode 0) == 0775:
+
os.chmod(mysettings[CONFCACHE_DIR], 0775)
+ if not st.st_uid == portage_uid:
+
os.chown(mysettings[CONFCACHE_DIR], portage_uid, -1)
+ for x in listdir(mysettings[CONFCACHE_DIR]):
+ p =
os.path.join(mysettings[CONFCACHE_DIR], x)
+ st = os.stat(p)
+ if not (st.st_mode 0) 07600 ==
0600:
+ os.chmod(p, (st.st_mode 0777)
| 0600)
+ if not st.st_uid == portage_uid:
+ os.chown(p, portage_uid, -1)
+
+ except OSError, e:
+ print !!! Failed resetting perms on confcachedir %s %
mysettings[CONFCACHE_DIR]
+ return 1
#try:
# mystat=os.stat(mysettings[CCACHE_DIR])
# if (mystat[stat.ST_GID]!=portage_gid) or
((mystat[stat.ST_MODE]02070)!=02070):
Index: bin/ebuild.sh
===
--- bin/ebuild.sh (revision 2490)
+++ bin/ebuild.sh (working copy)
@@ -459,7 +459,22 @@
LOCAL_EXTRA_ECONF=--libdir=${CONF_LIBDIR_RESULT}
${LOCAL_EXTRA_ECONF}
fi
- echo ${ECONF_SOURCE}/configure \
+ local TMP_CONFCACHE_DIR CONFCACHE_ARG
+ if hasq confcache $FEATURES ! hasq confcache $RESTRICT; then
+ CONFCACHE=$(type -p confcache)
+ if [ -z ${CONFCACHE} ]; then
+ ewarn disabling confcache, binary cannot be
found
+ else
+ CONFCACHE=${CONFCACHE/ /\ }
+
TMP_CONFCACHE_DIR=${CONFCACHE:+${CONFCACHE_DIR:-${PORTAGE_TMPDIR}/confcache}}
+ TMP_CONFCACHE_DIR=${TMP_CONFCACHE_DIR/ /\ }
+ CONFCACHE_ARG=--confcache-dir
+ fi
+ else
+ CONFCACHE=
+ fi
+
+ echo ${CONFCACHE} ${CONFCACHE_ARG} ${TMP_CONFCACHE_DIR}
${ECONF_SOURCE}/configure \
--prefix=/usr \
--host=${CHOST} \
--mandir=/usr/share/man \
@@ -470,7 +485,7 @@
$@ \
${LOCAL_EXTRA_ECONF}
- if ! ${ECONF_SOURCE}/configure \
+ if ! ${CONFCACHE} ${CONFCACHE_ARG} ${TMP_CONFCACHE_DIR}
${ECONF_SOURCE}/configure \
--prefix=/usr \
--host=${CHOST} \
--mandir=/usr/share/man \
pgpu5EBoUtgFS.pgp
Description: PGP signature
Re: [gentoo-portage-dev] Order of operations: buildpkg
On Tuesday 24 January 2006 03:43, Francesco Riosa wrote: Indeed, could someone shade a light on what happen to /var/db/pkg and world file when using ebuild this manner ? Could be rephrased as Does it act exactly the same way emerge does ? the 'qmerge' step would take care of updating /var/db/pkg -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Order of operations: buildpkg
On Tuesday 24 January 2006 14:19, Mike Frysinger wrote: On Tuesday 24 January 2006 03:43, Francesco Riosa wrote: Indeed, could someone shade a light on what happen to /var/db/pkg and world file when using ebuild this manner ? Could be rephrased as Does it act exactly the same way emerge does ? the 'qmerge' step would take care of updating /var/db/pkg -mike And yes it should, except that this does not clean out the /var/tmp/portage/pkgname-version directory. Use the clean command for that. If you find out the results are not the same it's a bug. (Of course package creates a package, which emerge might or might not do based on your config). The package step can also be skipped. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpEaqnF93Dos.pgp Description: PGP signature
Re: [gentoo-portage-dev] Order of operations: buildpkg
On Tue, 24 Jan 2006 08:19:22 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 24 January 2006 03:43, Francesco Riosa wrote: Indeed, could someone shade a light on what happen to /var/db/pkg and world file when using ebuild this manner ? Could be rephrased as Does it act exactly the same way emerge does ? the 'qmerge' step would take care of updating /var/db/pkg IIRC the thing it won't do is auto-clenaing the old entries though, need to run a emerge --clean afterwards. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] confcache integration
On Tue, 24 Jan 2006 04:50:31 -0800 Brian Harring [EMAIL PROTECTED] wrote: Yo. Looking to integrate confcache support into trunk some time in the near future- had users testing it for about 2 months (give or take), so far it's behaved pretty decently. A few packages eat themselves when ran with --cache (bad autotooling), hence the addition of restrict=confcache being added to the patch. Either way, patch is attached, looking for any complaints regarding it (or integrating confcache)- will be sending an email off to gentoo-dev in the next few days to get feedback from the general dev populace,, but sending this email to get feedback on the implementation in the meantime. That directory stuff really needs a wrapper function, it's duplicated way too often. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] confcache integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: Yo. Looking to integrate confcache support into trunk some time in the near future- had users testing it for about 2 months (give or take), so far it's behaved pretty decently. A few packages eat themselves when ran with --cache (bad autotooling), hence the addition of restrict=confcache being added to the patch. Either way, patch is attached, looking for any complaints regarding it (or integrating confcache)- will be sending an email off to gentoo-dev in the next few days to get feedback from the general dev populace,, but sending this email to get feedback on the implementation in the meantime. ~harring I don't see a manpage/make.conf patch in there :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9YzA2zglR5RwbyYAQKCTg/+NtqHZSIrApdkm6+TULFE2W2CIHQD9Vd8 VdLyKaDXOigsK460iZehY1pnxZRA8qes9Ed4H51kWL5HMCO/9FHyUZq2SAYHwQ/M moGMML+XyPanUc9Kvy2JREc/onzCbvPdYXkcJRNuE2XFhrfnKTXWin8JJBqyP7C/ 9S/NItRH+lAE6/1Az/6iJcSto0WscN/W18shwitCUB0igVUYcaBal4W3oJ6SvHEB NtX/xjL6zHTlS1iCsawVXAzgwcvFBNOSWilFobN6Qj2V1cn9a74Pio4axl33pEzK 6Mz4csL/UCZb/RisABOU03i3tTBEnehwgvKaD1BxHVfTUNwr8f9Oc1GdLJoZKlp8 H+4mZ7K82bhJ8CB0io9Zz5FZFUrp2cU2mQCh53vlVHZ2UlH+rAXaCLp2Lm0Fi1yQ 5cYyp0tH4eGNrYBrykZZ/gImaGYhIJ2RR8AETROltzRLk9bXq5dMgvWF2+38DdBI RqJKMYMmHSYJ/Ccp0kLs4G6xhOw5VXpRIdPMOFPOh76szdJX801s8S0ZHWAPcc7q /lkfnc9JwKcLSQIGth0IllEfhe3/OtaZoi+SDV0hIuOwJ0AgesUzNnUIa41pAfW5 npGTImc8kXYSp1JoDyflpUgsY6Cv2w48K96QUTWpj5oOPtu4l2t0wsof0boekFjP BR12OBv/wB4= =cCKG -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Order of operations: buildpkg
Paul de Vrieze wrote: On Tuesday 24 January 2006 14:19, Mike Frysinger wrote: On Tuesday 24 January 2006 03:43, Francesco Riosa wrote: Indeed, could someone shade a light on what happen to /var/db/pkg and world file when using ebuild this manner ? Could be rephrased as Does it act exactly the same way emerge does ? the 'qmerge' step would take care of updating /var/db/pkg -mike And yes it should, except that this does not clean out the /var/tmp/portage/pkgname-version directory. Use the clean command for that. If you find out the results are not the same it's a bug. (Of course package creates a package, which emerge might or might not do based on your config). The package step can also be skipped. Paul That's fine, these functions are intended for developer use that may need to still have the work/image dir in place. thanks everyone to address my worries . Francesco -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Mon, 23 Jan 2006 14:08:00 -0800
Brian Harring [EMAIL PROTECTED] wrote:
On Mon, Jan 23, 2006 at 07:44:44PM +0100, Marius Mauch wrote:
On Mon, 23 Jan 2006 03:47:11 -0800
Can't follow your thinking here. As said, the code won't corrupt any
data, at worst it will tell the user that it couldn't extract some
keys (and even that only if there would be such a stupid case which
itself has a chance of like 10^-10 or so, or can you name a single
case?).
Yeah, any extension of your code to pick up EAPI is going to false
positive on somewhere around a quarter of my vdb nodes- I use a
debug function from my bashrc for prefix testing (holdover from eapi
testing days). Why? Because the eapi var didn't exist (thus no env
assignment), the only possible match is in the middle of a here op-
debug_dump() {
...
echo HERE 2
EAPI=${EAPI-unset}
PF=$PF
CATEGORY=$CATEGORY
HERE
...
}
Setting EAPI to unset strikes me as corruption here, because now
portage will *never* do anything with that vdb node- the eapi differs
from what it supports (it's been set to effectively a random value),
thus I have to fix the vdb entry myself if I ever want to get rid of
it.
Guessing the response on that one is well, you're using the bashrc,
and yes, I am- the vdb code should be *robust*, not choking on a
users debug code.
Not even trying to comment on this one.
So what package contains filter-env then?
Portage- been in cvs/svn for over a year now :)
Not in trunk or any release (except the alpha snapshot). And I'm not
going to blindly copy unknown code from completely different codebases
and later be blamed for doing it improperly.
Aside from that, if the code is in debate (as this is), I really
don't think it should get slid into svn 2 weeks later effectively
unchanged- didn't write that original email just for the hell of
it :)
As said, I disagree with your assessment of the situation. If you
can name a single case where the code breaks or filter-env hits
the tree I might reconsider, but not before.
Well, if you disagreed with the original response, continue the
conversation prior to commiting- otherwise we see a commit, then a
rebuttal a few hours later. Not really how things should go for a
contested piece of code (at least when the only two to weigh in our
flat out opposed on it)- especially if the code's effect is
nontrivial and it hasn't had any actual peer review (only comment was
on your algo).
Interesting, you now count for two people? Or who is this second person
you're talking of? I still think you're making more out of this than it
really is. Also there really isn't a point in discussing a difference in
opinion IMO, such attempts lead nowhere. I considered your comment, but
couldn't come up with a reason why a theoretical issue should hold this
up.
Issues with the code.
Now we're getting somewhere.
1) Scans for metadata that didn't exist at the time of the ebuild's
installation, only possible match is unintended. Not good.
Not really sure what that's supposed to mean, assuming you mean that
nodes will lack SRC_URI/HOMEPAGE/... from env.bz2 is about as likely as
here doc statements containing them (and indicates a broken package
anyway).
2) your code is breaking upon *all* newlines, regardless if it's
in the middle of a variable assignment. Yes, bash does use $'' for
assignment, but you're relying (hoping really) that the variable has
been filtered by python portage and the ebuild defined var is
stomped. This is a bad idea- description comes to mind. Your code
seems to be aware of this possibility also, since it's doing rather
loose quote filtering.
Have to think about this.
3) Stop using regex all over the place. split/join is a helluva lot
faster, and collapses that nasty regex that attempts to remove
whitespace down to two lines (a one time translate, and the
split/join to kill whitespace).
Ok (cosmetics).
4) Code specifically tries to find, and remove variable chars-
this is *really* the wrong thing to do. If you're trying to work
around catching a var reference, either your parsing screwed up, or
you're mangling a DESCRIPTION value that you shouldn't be hosing.
define variable chars, otherwise doesn't make sense.
5) hardcoded vdb.
6) Non root aware VDB.
Ok (trivial)
7) Only is aware of environment.bz2- older portage versions differed
in this afaik (I *do* know PORT_ENV_FILE overloading for ebd I had to
address this case already, so it's out there).
Well, it's present as long as I can remember, but an sanity check
wouldn't hurt there.
8) perms on the new files?
Ok.
9) general code comments; 'if s != ', use 'if s:'. Catch the
exceptions for check mode, don't let vdbkeyhandler nuke world file
checking due to a potential exception. Right now, your code will TB
if ran by non-root for a check run rather then stating got to be
root.
a) hate theses
Re: [gentoo-portage-dev] confcache integration
On Tuesday 24 January 2006 21:50, Brian Harring wrote: +os.makedirs(mysettings[CONFCACHE_DIR], mode=0775) +os.chown(mysettings[CONFCACHE_DIR], portage_uid, -1) This will die when running as non-root, no? ebuild is now oft used by devs running as normal users which will be broken by this. No clues on the bash stuff; it seems there's an external confcache binary but I can't tell much beyond that. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [gentoo-dev-portage] [PATCH] prevent world file corruption by writing atomically
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: the atomic writing of data in writedict could be gutted out to a derivative of the file class; via that, same underlying atomic update code for writedict and wordfile updates... Hmm, override the constructor and close methods to handle the temp file creation and rename, respectively. That seems like a very elegant approach. I'll try that and update the patch. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD1nHS/ejvha5XGaMRAhcCAJ4v2ZoUux1lqDpq8z9URZfybZg2IgCfVwDK XPPGuL0jiv3RgO1xPCsGFt0= =E4NK -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] confcache integration
On Wed, 2006-01-25 at 00:30 +0900, Jason Stubbs wrote: On Tuesday 24 January 2006 21:50, Brian Harring wrote: +os.makedirs(mysettings[CONFCACHE_DIR], mode=0775) +os.chown(mysettings[CONFCACHE_DIR], portage_uid, -1) This will die when running as non-root, no? ebuild is now oft used by devs running as normal users which will be broken by this. Your right. I've hit that bug myself in the past switching between root merges and being a real life dev and running ebuild foo.build clean unpack compile; -- solar [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
