Re: [gentoo-dev] virtual/ffmpeg and media-video/libav
On 03/28/2011 07:25 PM, Alexis Ballier wrote: I hope my fears are unjustified but I'm not sure how the PMs would behave in the following cases: a deps on b and virtual/ffmpeg b deps on media-video/ffmpeg what happens when I want to install package 'a' on a fresh system ? the pm tries to pull the virtual and thus libav and sees a blocker with the non virtual one? same questions with: a deps on media-video/ffmpeg b deps on virtual/ffmpeg type 'emerge a b' That's handled by delayed evaluation since portage-2.1.7: https://bugs.gentoo.org/show_bug.cgi?id=264434 -- Thanks, Zac
Re: [gentoo-dev] RFC: postgresql.eselect
On Mon, 28 Mar 2011, Aaron W Swenson wrote: This module is to replace the existing one that is shipped with app-admin/eselect-postgresql-1.0.3. It is an entire rewrite. Some remarks: - Global scope code is a no-no in eselect modules, especially if it calls external programs or accesses external files. Your module will be sourced for commands like eselect modules list and there shouldn't be any global scope code being run on such occasions. - Don't use eval. It's almost always an indication that you're doing something wrong. - For tests, please use [[ ]] rather than [ ] throughout. - output and path-manipulation libraries are always loaded, so you need not (and in fact, you shouldn't) inherit them. - Don't hardcode terminal specific escape sequences (like \033[1m). Use the highlighting functions of the output library instead (which in turn use tput). - Suppressing stdout of commands like do_action env update is fine, but why suppress stderr? - Please avoid lines wider than 79 positions. See also eselect's README and the developer guide: http://sources.gentoo.org/cgi-bin/viewvc.cgi/eselect/trunk/README http://www.gentoo.org/proj/en/eselect/dev-guide.xml Ulrich
Re: [gentoo-dev] rfc: New global USE flag called ios, not same as ipod ?
On Ter, 2011-03-29 at 06:23 +0300, Samuli Suominen wrote: The magic number is often 5, this is 4 but it's only magic! ios (gnome-base/gvfs): ios (media-libs/libgpod): ios (media-sound/clementine): ios (sys-power/upower): Does this look proper? Enable imobiledevice support for Apple's iPhone, iPod, and iPad with iOS operating system. Hints from here: http://www.libimobiledevice.org/ http://en.wikipedia.org/wiki/IOS_(Apple) Not quite. ipod flag usually covers the old iPod versions without iOS. The iphone use flag covers some features present on the iPhone and not necessarily present on all iPods (with iOS). So yeah, the ios use flag makes sense to cover all devices with iOS ipod or iphone. Regards, -- Angelo Arrifano (miknix) Developer / GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] rfc: New global USE flag called ios, not same as ipod ?
On Ter, 2011-03-29 at 06:23 +0300, Samuli Suominen wrote: The magic number is often 5, this is 4 but it's only magic! ios (gnome-base/gvfs): ios (media-libs/libgpod): ios (media-sound/clementine): ios (sys-power/upower): Does this look proper? Enable imobiledevice support for Apple's iPhone, iPod, and iPad with iOS operating system. Hints from here: http://www.libimobiledevice.org/ http://en.wikipedia.org/wiki/IOS_(Apple) Not quite. ipod flag usually covers the old iPod versions without iOS. The iphone use flag covers some features present on the iPhone and not necessarily present on all iPods (with iOS). So yeah, the ios use flag makes sense to cover all devices with iOS ipod or iphone. Regards, -- Angelo Arrifano (miknix) Developer / GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] rfc: New global USE flag called ios, not same as ipod ?
On 03/29/2011 02:07 PM, Angelo Arrifano wrote: On Ter, 2011-03-29 at 06:23 +0300, Samuli Suominen wrote: The magic number is often 5, this is 4 but it's only magic! ios (gnome-base/gvfs): ios (media-libs/libgpod): ios (media-sound/clementine): ios (sys-power/upower): Does this look proper? Enable imobiledevice support for Apple's iPhone, iPod, and iPad with iOS operating system. Hints from here: http://www.libimobiledevice.org/ http://en.wikipedia.org/wiki/IOS_(Apple) Not quite. ipod flag usually covers the old iPod versions without iOS. The iphone use flag covers some features present on the iPhone and not necessarily present on all iPods (with iOS). So yeah, the ios use flag makes sense to cover all devices with iOS ipod or iphone. Regards, What do you mean by Not quite. when you basically confirmed everything I've said? BTW, There is no more USE=iphone in Portage.
Re: [gentoo-dev] rfc: New global USE flag called ios, not same as ipod ?
On Ter, 2011-03-29 at 14:16 +0300, Samuli Suominen wrote: On 03/29/2011 02:07 PM, Angelo Arrifano wrote: On Ter, 2011-03-29 at 06:23 +0300, Samuli Suominen wrote: The magic number is often 5, this is 4 but it's only magic! ios (gnome-base/gvfs): ios (media-libs/libgpod): ios (media-sound/clementine): ios (sys-power/upower): Does this look proper? Enable imobiledevice support for Apple's iPhone, iPod, and iPad with iOS operating system. Hints from here: http://www.libimobiledevice.org/ http://en.wikipedia.org/wiki/IOS_(Apple) Not quite. ipod flag usually covers the old iPod versions without iOS. The iphone use flag covers some features present on the iPhone and not necessarily present on all iPods (with iOS). So yeah, the ios use flag makes sense to cover all devices with iOS ipod or iphone. Regards, What do you mean by Not quite. when you basically confirmed everything I've said? Sorry, I was answering the question in the email's subject... I also apologize for the double reply, but that is evolution's fault. So yeah, thumbs up for new ios use flag.
Re: [gentoo-dev] rfc: New global USE flag called ios, not same as ipod ?
On 03/29/2011 02:21 PM, Angelo Arrifano wrote: On Ter, 2011-03-29 at 14:16 +0300, Samuli Suominen wrote: On 03/29/2011 02:07 PM, Angelo Arrifano wrote: On Ter, 2011-03-29 at 06:23 +0300, Samuli Suominen wrote: The magic number is often 5, this is 4 but it's only magic! ios (gnome-base/gvfs): ios (media-libs/libgpod): ios (media-sound/clementine): ios (sys-power/upower): Does this look proper? Enable imobiledevice support for Apple's iPhone, iPod, and iPad with iOS operating system. Hints from here: http://www.libimobiledevice.org/ http://en.wikipedia.org/wiki/IOS_(Apple) Not quite. ipod flag usually covers the old iPod versions without iOS. The iphone use flag covers some features present on the iPhone and not necessarily present on all iPods (with iOS). So yeah, the ios use flag makes sense to cover all devices with iOS ipod or iphone. Regards, What do you mean by Not quite. when you basically confirmed everything I've said? Sorry, I was answering the question in the email's subject... I also apologize for the double reply, but that is evolution's fault. So yeah, thumbs up for new ios use flag. Ok, thought so ;-) - Samuli
Re: [gentoo-dev] rfc: New global USE flag called ios, not same as ipod ?
Am Tue, 29 Mar 2011 06:23:04 +0300 schrieb Samuli Suominen ssuomi...@gentoo.org: The magic number is often 5, this is 4 but it's only magic! When I hear ios I first think of Cisco's IOS rather than Apple's. Is this an issue? -- Hanno Böck mail/jabber: ha...@hboeck.de GPG: BBB51E42 http://www.hboeck.de/ JETZT zu Ökostrom wechseln: http://atomausstieg-selber-machen.de
Re: [gentoo-dev] rfc: New global USE flag called ios, not same as ipod ?
On Ter, 2011-03-29 at 14:46 +0200, Hanno Böck wrote: Am Tue, 29 Mar 2011 06:23:04 +0300 schrieb Samuli Suominen ssuomi...@gentoo.org: The magic number is often 5, this is 4 but it's only magic! When I hear ios I first think of Cisco's IOS rather than Apple's. Is this an issue? Yes, it means you were not consumed by Apple madness yet :) Now seriously, people should check use flag descriptions before enabling them so IMHO this is not an issue. - Angelo
Re: [gentoo-dev] rfc: New global USE flag called ios, not same as ipod ?
On 03/29/2011 03:46 PM, Hanno Böck wrote: Am Tue, 29 Mar 2011 06:23:04 +0300 schrieb Samuli Suominen ssuomi...@gentoo.org: The magic number is often 5, this is 4 but it's only magic! When I hear ios I first think of Cisco's IOS rather than Apple's. Is this an issue? Yeah, good point. But I still don't think it's an issue. And I hope so too, because I've just committed that use.desc change like 5 mins ago ;-) - Samuli
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 29.3.2011 04:12, Alexis Ballier napsal(a): On Wednesday, March 23, 2011 11:23:48 AM Samuli Suominen wrote: On 03/23/2011 04:08 PM, Tomáš Chvátal wrote: Hi guys, As there is new ffmpeg fork that is a bit alive we should provide it as alternative to current media-video/ffmpeg. So libav is stored in media-video/libav (look at it, try to find issues and stuff). Virtual package is virtual/ffmpeg where now i implemented it to have versioned dependencies. So there is virtual/ffmpeg-0.6 virtual/ffmpeg- where the apps can decide what they need. Samuli pointed out that we do not slot ffmpeg nor support versioned deps and always demand everything to be working with latest. If you have strong opinion on that one please express it here so the virtual gets redesigned to just simple virtual/ffmpeg-0.1 without any version stated in it. I myself like the chance to express the version explicitly. Virtual itself provide access to all useflags currently used in eapi2 deps. More can be added when required. With the same logic we have always pulled in from master, instead of release trees (such as 0.5.x, 0.6.x). It's not legal to set versioned deps forcing downgrade on same stabilization level (stable, or ~arch) as that will just cause dependency conflict. Applies to any package. So just punt the just committed virtuals and just leave virtual/ffmpeg-0.ebuild. Anything that doesn't work with latest and is not fixed in reasonable time, gets lastrited like before. well, if you want to convert all the tree you'll need a versioned virtual because the = deps are still needed (and the virtual should also have = deps, not ~ nor =..* in order not to force a downgrade because of an outdated virtual) A. Well the virtuals can be versioned as i said previously, altho others convinced me that unversioned are desirable. If we would want versioned one we currently need 3 of them: 0.5 including only ffmpeg = 0.5 0.6 including libav or ffmpeg both = 0.6 0.7 including libav = 0.7_pre or ffmpeg = 0.6_p So what do you think. For the || dependencies order it should be lazy evaluated for 2 years now. Cheers Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2R17UACgkQHB6c3gNBRYc9eACfcheohzlRT9JRV27FdjSybk1C dyUAn1WPNzlxMDolYAqODZLo26y2Pcxk =0gYI -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, 27 Mar 2011 13:17:46 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That would never work with m-n packages that other packages *DEPEND on. jer
[gentoo-dev] GNOME 3.0 slotting done
Hi, this is just a quick heads up, because nirbheek forced me to do it. GNOME 2.0 slot deps should be fixed after about 1,000 commits and the tree is good to go for GNOME 3.0. Everyone adding non-slot deps on gtk+ or GNOME libs will be stabbed. Thank you for your attention. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On Tuesday, March 29, 2011 09:59:33 AM Tomáš Chvátal wrote: Dne 29.3.2011 04:12, Alexis Ballier napsal(a): On Wednesday, March 23, 2011 11:23:48 AM Samuli Suominen wrote: On 03/23/2011 04:08 PM, Tomáš Chvátal wrote: Hi guys, As there is new ffmpeg fork that is a bit alive we should provide it as alternative to current media-video/ffmpeg. So libav is stored in media-video/libav (look at it, try to find issues and stuff). Virtual package is virtual/ffmpeg where now i implemented it to have versioned dependencies. So there is virtual/ffmpeg-0.6 virtual/ffmpeg- where the apps can decide what they need. Samuli pointed out that we do not slot ffmpeg nor support versioned deps and always demand everything to be working with latest. If you have strong opinion on that one please express it here so the virtual gets redesigned to just simple virtual/ffmpeg-0.1 without any version stated in it. I myself like the chance to express the version explicitly. Virtual itself provide access to all useflags currently used in eapi2 deps. More can be added when required. With the same logic we have always pulled in from master, instead of release trees (such as 0.5.x, 0.6.x). It's not legal to set versioned deps forcing downgrade on same stabilization level (stable, or ~arch) as that will just cause dependency conflict. Applies to any package. So just punt the just committed virtuals and just leave virtual/ffmpeg-0.ebuild. Anything that doesn't work with latest and is not fixed in reasonable time, gets lastrited like before. well, if you want to convert all the tree you'll need a versioned virtual because the = deps are still needed (and the virtual should also have = deps, not ~ nor =..* in order not to force a downgrade because of an outdated virtual) A. Well the virtuals can be versioned as i said previously, altho others convinced me that unversioned are desirable. you were right to version them at the beginning for the above reasons If we would want versioned one we currently need 3 of them: 0.5 including only ffmpeg = 0.5 0.6 including libav or ffmpeg both = 0.6 I would only add these 2 here 0.7 including libav = 0.7_pre or ffmpeg = 0.6_p So what do you think. there is no 0.7 for the moment, so we do not really care; we'll add new virtual versions as the need comes; a quick look at your list shows 0.6 to be the highest required version by some packages. For the || dependencies order it should be lazy evaluated for 2 years now. Still, you're making the jump rather quickly by having a fork as the default implementation a couple of days after the fork. libav is 'new' and shiny, comes with better promises and everything, but why would they fork if they didnt ? :) Its already starting to be a mess with the versions differing... I can't wait to see the next API break... I really wish one of the 2 forks will die rather sooner than later. A.
[gentoo-dev] Please enhance your USE descriptions!
Hi, the descriptions of USE flags should explain what the USE is good for. In my opinion some thing like Enables foo intergration or Enables support for foo if it isn't totally clear what foo is, sucks!! There are many, many description which do not tell me as a user without googling what I could enable or not. That doesn't make gentoo very user friendly! So please enhance you descriptions!! Thanks justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 29.3.2011 16:05, Alexis Ballier napsal(a): Its already starting to be a mess with the versions differing... I can't wait to see the next API break... I really wish one of the 2 forks will die rather sooner than later. The versions differing is simple. There is planned 0.6.3 - if we just add 0.6.2_pSNAPSHOTDAY it would get overshadowed later. if we name it 0.7_pre 0.6 releases never gets to collide with it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2R7KEACgkQHB6c3gNBRYdHbQCcDZBJLjdwb4ZBC+3O4l3zi4qt vmcAni7gb6vQazQ2u9oYiovutNZGmk1c =yjLw -END PGP SIGNATURE-
Re: [gentoo-dev] Please enhance your USE descriptions!
Excerpts from justin's message of Tue Mar 29 16:24:57 +0200 2011: the descriptions of USE flags should explain what the USE is good for. In my opinion some thing like Enables foo intergration or Enables support for foo if it isn't totally clear what foo is, sucks!! There are many, many description which do not tell me as a user without googling what I could enable or not. That doesn't make gentoo very user friendly! So please enhance you descriptions!! I 100% agree with you! This is something what is always pissing me off when reading equery uses foo to find out how to set flags. I'm actually describing even global USE flags in my package's metadata.xml if their purpose might not be clear and I'd like to expect that from others. It is not a problem to write one sentence for each flag while you already know what flag does. Maybe it should even become our policy and not just recommendation? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Please enhance your USE descriptions!
On Tue, 29 Mar 2011 16:24:57 +0200 justin j...@gentoo.org wrote: if it isn't totally clear what foo is, sucks!! You could start by pointing out some good examples of bad descriptions. So please enhance you descriptions!! And when you do, also remove all exclamation marks. Not all Gentoo users are used to reading German. ;-) jer
Re: [gentoo-dev] Please enhance your USE descriptions!
On Ter, 2011-03-29 at 17:08 +0200, Amadeusz Żołnowski wrote: Excerpts from justin's message of Tue Mar 29 16:24:57 +0200 2011: the descriptions of USE flags should explain what the USE is good for. In my opinion some thing like Enables foo intergration or Enables support for foo if it isn't totally clear what foo is, sucks!! There are many, many description which do not tell me as a user without googling what I could enable or not. That doesn't make gentoo very user friendly! So please enhance you descriptions!! I 100% agree with you! This is something what is always pissing me off when reading equery uses foo to find out how to set flags. I'm actually describing even global USE flags in my package's metadata.xml if their purpose might not be clear and I'd like to expect that from others. It is not a problem to write one sentence for each flag while you already know what flag does. Maybe it should even become our policy and not just recommendation? Why do we have to turn everything into policies? This case would be easily solved by making a list of use flags that we find poorly described, then improving the description of each. - Angelo
Re: [gentoo-dev] Please enhance your USE descriptions!
Excerpts from Angelo Arrifano's message of Tue Mar 29 17:14:48 +0200 2011: On Ter, 2011-03-29 at 17:08 +0200, Amadeusz Żołnowski wrote: I'm actually describing even global USE flags in my package's metadata.xml if their purpose might not be clear and I'd like to expect that from others. It is not a problem to write one sentence for each flag while you already know what flag does. Maybe it should even become our policy and not just recommendation? Why do we have to turn everything into policies? This case would be easily solved by making a list of use flags that we find poorly described, then improving the description of each. It would be hard to find good descriptions. The problem is that even if flag has similar meaning in few packages, it usually adds a bit different functionality and that difference matters. User would like to know what he/she benefits or looses with enabling/disabling the flag. It's not just a matter of one click, it at least minutes of compilation. I think it's a task to package maintainers to review if current descriptions explain what flags in their packages bring to user. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Please enhance your USE descriptions!
On 2011-03-29 17:10, Jeroen Roovers wrote: You could start by pointing out some good examples of bad descriptions. A few regular expressions might help with that: /:(\w+) - (Enable|Add) support for \1$/ /:(\w+) - (Enable|Add) \1( support)?$/ For example: app-admin/puppet:shadow - Enable shadow support app-editors/tea:hacking - Enable hacking support app-emulation/q4wine:icoutils - Enable icoutils support app-misc/roadnav:openstreetmap - Enable openstreetmap support app-misc/roadnav:scripting - Enable scripting support app-office/abiword-plugins:thesaurus - Enable thesaurus support app-office/abiword:thesaurus - Enable thesaurus support app-pda/barry:boost - Enable boost support pgpz4DicObooB.pgp Description: PGP signature
Re: [gentoo-dev] Please enhance your USE descriptions!
Le mardi 29 mars 2011 à 16:02 +, Andy Spencer a écrit : app-office/abiword-plugins:thesaurus - Enable thesaurus support app-office/abiword:thesaurus - Enable thesaurus support can't help you if you don't know what a thesaurus is, really :( -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Please enhance your USE descriptions!
On Tue, Mar 29, 2011 at 2:24 PM, justin j...@gentoo.org wrote: Hi, the descriptions of USE flags should explain what the USE is good for. In my opinion some thing like Enables foo intergration or Enables support for foo if it isn't totally clear what foo is, sucks!! There are many, many description which do not tell me as a user without googling what I could enable or not. That doesn't make gentoo very user friendly! So please enhance you descriptions!! Thanks justin One USE flag I remember in particular bothering me was gnome-extra/gnome-games' guile USE flag. The global description says guile - Adds support for the guile Scheme interpreter but this flag is actually determines whether a number of games are installed by this package. There are lots of cases like this that need a local use flag that says what each flag actually does for the package. Matt
[gentoo-dev] Re: Please enhance your USE descriptions!
On 03/29/2011 08:00 PM, Matt Turner wrote: On Tue, Mar 29, 2011 at 2:24 PM, justinj...@gentoo.org wrote: Hi, the descriptions of USE flags should explain what the USE is good for. In my opinion some thing like Enables foo intergration or Enables support for foo if it isn't totally clear what foo is, sucks!! There are many, many description which do not tell me as a user without googling what I could enable or not. That doesn't make gentoo very user friendly! So please enhance you descriptions!! Thanks justin One USE flag I remember in particular bothering me was gnome-extra/gnome-games' guile USE flag. The global description says guile - Adds support for the guile Scheme interpreter but this flag is actually determines whether a number of games are installed by this package. The most extreme one I remember is the gtk flag of GCC: Adds support for x11-libs/gtk+ (The GIMP Toolkit) Hmm, OK. So without that flag, GCC won't be able to build gtk? Or gimp? Or any software using gtk?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 15:30, Jeremy Olexa darks...@gentoo.org wrote: Why does anyone need to *add* a package that is maintainer-needed? Regardless of how we might want to get rid of m-n packages, I do wonder about who commits them, and why. For example, while looking into the list of m-n packages, I also found dev-python/remoteobjects-, which was also entered into the tree by vapier as m-n. vapier, what's the rationale behind including these packages in the tree? And if you need them, why can't you maintain them? (I'm asking this as a member of the Python project, where we probably wouldn't mind picking up some python m-n packages.) Cheers, Dirkjan
Re: [gentoo-dev] Please enhance your USE descriptions!
On Tue, Mar 29, 2011 at 10:30 PM, Matt Turner matts...@gentoo.org wrote: One USE flag I remember in particular bothering me was gnome-extra/gnome-games' guile USE flag. The global description says guile - Adds support for the guile Scheme interpreter but this flag is actually determines whether a number of games are installed by this package. Actually, it only controls the installation of aisleriot (solitaire, freecell, etc). The USE-flag was changed from guile to aisleriot a while back, but the changes haven't made it to the tree yet because newer gnome-games are quite unusable. 2.28 (the current stable) is almost two years old. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] lastrite: net-mail/mailwrapper net-mail/mailer-config
# Eray Aslan e...@gentoo.org (29 Mar 2011) # Abandoned project. Last release in 2005. Bugs #158003, #97589, # #359411. # Removal in 90 days net-mail/mailwrapper net-mail/mailer-config
Re: [gentoo-dev] lastrite: net-mail/mailwrapper net-mail/mailer-config
On 3/29/11 9:52 PM, Eray Aslan wrote: # Eray Aslan e...@gentoo.org (29 Mar 2011) # Abandoned project. Last release in 2005. Bugs #158003, #97589, # #359411. # Removal in 90 days net-mail/mailwrapper net-mail/mailer-config That's cool. All I remember about it are file collisions. Thanks! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: postgresql.eselect
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/29/2011 05:06 AM, Ulrich Mueller wrote: On Mon, 28 Mar 2011, Aaron W Swenson wrote: This module is to replace the existing one that is shipped with app-admin/eselect-postgresql-1.0.3. It is an entire rewrite. Some remarks: - Global scope code is a no-no in eselect modules, especially if it calls external programs or accesses external files. Your module will be sourced for commands like eselect modules list and there shouldn't be any global scope code being run on such occasions. Fixed. - Don't use eval. It's almost always an indication that you're doing something wrong. Yeah, I should have used 'find' as fewer tricks are needed. Wonder why I didn't do that in the first place - For tests, please use [[ ]] rather than [ ] throughout. Done. - output and path-manipulation libraries are always loaded, so you need not (and in fact, you shouldn't) inherit them. The dev guide could be clearer on that. Removed them from the inherit line. - Don't hardcode terminal specific escape sequences (like \033[1m). Use the highlighting functions of the output library instead (which in turn use tput). Except $(highlight ...) doesn't work in plain echo. So, I just stripped it out. - Suppressing stdout of commands like do_action env update is fine, but why suppress stderr? Because 'ls' would complain that files didn't exist, such as lib*.dylib when on a Linux system. It doesn't matter. But, using 'find' avoids this mess. - Please avoid lines wider than 79 positions. Did where I could. See also eselect's README and the developer guide: http://sources.gentoo.org/cgi-bin/viewvc.cgi/eselect/trunk/README Never knew that existed. Thanks for pointing that out. http://www.gentoo.org/proj/en/eselect/dev-guide.xml That's where I got all of my information. Ulrich Thank you for the feedback. It was quite helpful. Now, I'm a bit sketchy on the handling of choosing which bitness for the executables. (psql and friends.) Sincerely, Mr. Aaron W. Swenson -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk2SSX0ACgkQCOhwUhu5AEk4xQD9E6jabiGSNYycJSU871p82H1O 0iIU1kBV2HMhfJId/NgA/0Zoq2O3Pcy9O2OcthsQb6e8ZipJZ+dpffMCaC0zOqrs =L/aO -END PGP SIGNATURE-
Re: [gentoo-dev] FYI: USE=hal masked in base/use.mask and related
On Sun, Mar 27, 2011 at 11:36:00AM +0300, Samuli Suominen wrote: USE=hal is masked in base/use.mask, but unmasked for kde-base/solid and app-cdr/k3b in base/package.use.mask pending on KDE 4.6.x stabilization. This is preparation for dropping the uncompressed usb.ids file from sys-apps/usbutils, which HAL relies on. Also, both udisks and upower now have blockers for sys-apps/hal to prevent overlapping features. -Samuli Good evening, Why didn't you use the news utility to inform users about this change and possible transition steps/migration guide? This is a rather big change that might (or may not) require a bit of effort from non-power users to migrate their systems to the new backend. A short summary of http://forums.gentoo.org/viewtopic-t-858965-start-0.html would be nice but I guess it is too late for that since another major change occurred without advertising it properly to our users. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpZc8y1TMsbr.pgp Description: PGP signature
[gentoo-dev] Re: RFC: postgresql.eselect
On Tue, 29 Mar 2011 17:05:01 -0400
Aaron W. Swenson titanof...@gentoo.org wrote:
- Suppressing stdout of commands like do_action env update is fine,
but why suppress stderr?
Because 'ls' would complain that files didn't exist, such as lib*.dylib
when on a Linux system. It doesn't matter. But, using 'find' avoids this
mess.
Never use ls to get filenames in a script. Instead of
for link_source in $(eval ls ${source_dir} 2 /dev/null) ; do
just use
for link_source in ${source_dir}/* ; do
I see you already fixed this one, but you do some funky stuff with ls -d
earlier on.
http://mywiki.wooledge.org/BashPitfalls#for_i_in_.24.28ls_.2A.mp3.29
--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] EbuildProcess logs poll-error to already removed $T (on AIX)
On 03/28/2011 08:07 PM, Perry Smith wrote: On Mar 28, 2011, at 9:49 PM, Zac Medico wrote: On 03/28/2011 07:01 PM, Perry Smith wrote: I did not 100% follow this. In particular, I didn't see how we started talking about pty's. But, since you are, I'll wade in. When the master side (the side that a daemon opens like telnetd) closes, the slave side gets the same treatment as if a modem hung up on a real tty. This is a SIGHUP *and* any further writes will return EIO (5) and further reads return 0. (All this is assuming CLOCAL is off.) I would not be surprised if the child process is receiving a SIGHUP if all the process session and controlling tty requirements have been met and the file descriptor is also selectable for POLLHUP and POLLERR. I would peek inside the Python code because perhaps it is testing for POLLERR before it is testing for POLLHUP. Or, perhaps it is not expecting the POLLERR at all (that is the 16384 value) In our case, a subprocess is connected to the slave end of the pty, and portage reads its output from the master end. With Linux (among other kernels), after the subprocess closes the slave end, we typically receive a POLLHUP event or else EIO from a read call. Apparently, Linux (among other kernels) we never receive a POLLERR event here, but with AIX we do. I want to make sure you typed what you meant to type because it wasn't what I was expecting. Does the slave close first or the master? Or, I suppose, more importantly, which side (the master or the slave) is getting the POLLERR? The slave does. This code works the same way as the script program which is used to capture the output of a terminal session that is attached to the slave end of a pty. Eventually, the subprocess that's attached to the slave end exits, and that's presumably when the master end receives the POLLERR event. I should note that I assume that the POLLERR event occurs when the slave end is closed, since the user has not reported any loss of subprocess output. If the POLLERR event occurred before that, then output from the subprocess would be lost. -- Thanks, Zac
