Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Am Samstag, den 22.08.2009, 01:54 +0100 schrieb AllenJB: From what I've seen here, at least part of the problem here stems from the fact that this feature won't be considered until EAPI-4, and that means it might be a long way off yet. This, in my mind, raises the question of whether the current PMS/EAPI process is too slow in certain circumstances and could it be modified to speed things up when deemed necessary? Could there be room for fast track EAPI's to be considered on some occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the package.* as directory in profiles feature included? If this is a matter of what the council has decided, would a simple solution be to have a motion for amendment / fast-track of EAPI2.1 (or alternative solution) brought up and voted on by the council? As you can see currently, most time is needed to implemente the features in portage. It therefore doesn't make sense to make the EAPI process even faster. On the other hand, I think it would make sense to have a separate group developing new EAPIs instead of the council. Cheers, Tiziano -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Tiziano Müller wrote: As you can see currently, most time is needed to implemente the features in portage. It therefore doesn't make sense to make the EAPI process even faster. On the other hand, I think it would make sense to have a separate group developing new EAPIs instead of the council. Cheers, Tiziano I agree with what's being said here. The previous council ran into a huge road block with EAPI and GLEP's. I think that EAPI's should be moved to the Portage herd, and GLEPs assigned as necessary until final approval or dissent is given by the council. This would hopefully reduce contention with GLEP's as has happened in the past, and put EAPI's closer to the devs who will implement them. Andrew D Kirch Funtoo.org
[gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
On 08/22/2009 06:40 AM, Jeremy Olexa wrote: Nikos Chantziaras wrote: On 08/22/2009 05:59 AM, Nikos Chantziaras wrote: On 08/22/2009 05:39 AM, Sebastian Pipping wrote: Sebastian Pipping wrote: Commits are done automatically, triggering and pushing is manual at the moment. By now a cron-based setup is running syncing the pure-funtoo overlay (and therefore also its atom and rss feeds) every 24 hours. There seems to be a bit of (minimal) duplication between pure-funtoo and sunrise. Uhm, I just discovered that there are conflicts with portage too. That is not good. After I added pure-funtoo, it messed up my emerge -u world (stuff like wanting to upgrade to sys-apps/baselayout-2.1.5). pure-funtoo should not offer packages available in portage (sunrise is the lesser evil). Huh? This is true of all overlays. Not the ones I'm using. If my overlay had baselayout-5.0 in it, you would be upgrading to that version if you had my overlay... By nature of overlays themselves, you should know what you are doing and how to handle it (ie. mask =sys-apps/baselayout-2.0.1) I use overlays for packages I can't get through portage. If they conflict, I don't use them. Masking is no solution. If I mask =sys-apps/baselayout-2.0.1, I mask it for good, not only in the specific overlay it comes from. If portage updates to it, I'll never get it. This is quite a major pain in the ass and the reason I stay far away from overlays that offer conflicting packages.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On 8/22/09, Andrew D Kirch trel...@trelane.net wrote: Right, this is called punishing innovation. It's a hobby of bureaucrats everywhere. It could also be said to be punishing excellence. If it wasn't a sort of a bug (some omission in the original PMS?), then I suppose this could also be described as The Three 'E's: embrace (a supposed standard), extend (possibly in an incompatible, hard to replicate ways), and extinguish (well, harder to do with FLOSS, but you can probably see where I got these 'e's ;) ). I think that also Microsoft calls that 'innovation'. :D Let's just leave this to the Council. These semantic-pedantic is not, is too-discussions with Mr. McCreesh never seem to end as both sides keep to the logic that if you don't quickly reply to comments which are wrong, then your silence means that the other one was right. There should be some kind of eternal loop detection for these threads ... :P -- Arttu V.
Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
Sebastian Pipping schrieb: Nikos Chantziaras wrote: There seems to be a bit of (minimal) duplication between pure-funtoo and sunrise: app-office/thinking-rock-bin dev-tex/mimetex x11-drivers/xf86-video-nouveau And since sunrise is the most popular overlay, it might be a good idea to also omit packages found in sunrise. Sunrise ebuilds are subtracted already. The reason app-office/thinking-rock-bin ends up in pure-funtoo is that newer version of existing ebuilds are also taking into account: Sunrise: 2.0_pre2-r2 Funtoo: 2.0.1 That's why app-office/thinking-rock-bin-2.0.1 is in pure-funtoo. Sebastian I suggest that you (or the person, who added those ebuilds to funtoo) join the Sunrise project and update the ebuild in the sunrise overlay instead of adding it to another tree. ;-) -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] New media-libs/jpeg-7 and how to deal with it.
media-libs/jpeg-7 installs .so.7.0.0 so this causes some headacke for
binary applications:
media-libs/jpeg-compat-6b will install libjpeg.so.62{,.0.0} for use with
binary applications, let me know if there is a trouble with the package.
This means you have change deps to || ( media-libs/jpeg-compat
=media-libs/jpeg-7 ) for example. Feel free to use suitable alternative
syntaxes.
Otherwise it just means a long @preserved-rebuild emerge.
jpegint.h isn't installed anymore (private header), if this is causing
trouble for you let me know about that too...
Thanks, Samuli
Re: [gentoo-dev] New media-libs/jpeg-7 and how to deal with it.
Samuli Suominen wrote: This means you have change deps to || ( media-libs/jpeg-compat =media-libs/jpeg-7 ) for example. Feel free to use suitable alternative syntaxes. Typo. Correct: || ( media-libs/jpeg-compat media-libs/jpeg-7 )
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Am Samstag, den 22.08.2009, 02:23 -0400 schrieb Andrew D Kirch: Tiziano Müller wrote: As you can see currently, most time is needed to implemente the features in portage. It therefore doesn't make sense to make the EAPI process even faster. On the other hand, I think it would make sense to have a separate group developing new EAPIs instead of the council. Cheers, Tiziano I agree with what's being said here. The previous council ran into a huge road block with EAPI and GLEP's. I think that EAPI's should be moved to the Portage herd, Portage just happens to be one of the package managers to implement the specs afterwards. Since you agree with me about implementation taking too long a pretty easy conclusion is that the portage team is already understaffed so moving even more responsibility/work there makes the whole process even slower. (Besides the fact of not including other package manager devs in the process, but guessing from your earlier comments you don't care about that.) and GLEPs assigned as necessary until final approval or dissent is given by the council. And you moaned about bureaucracy earlier today? Interesting. -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] New media-libs/jpeg-7 and how to deal with it.
On Sat, 22 Aug 2009 16:01:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: media-libs/jpeg-7 installs .so.7.0.0 so this causes some headacke for binary applications: Doesn't this mean you should slot it? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New media-libs/jpeg-7 and how to deal with it.
Ciaran McCreesh wrote: On Sat, 22 Aug 2009 16:01:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: media-libs/jpeg-7 installs .so.7.0.0 so this causes some headacke for binary applications: Doesn't this mean you should slot it? No. I only want the .so.62 for binary apps, thus the ebuild won't install anything but the shared libs.
Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nikos Chantziaras wrote: On 08/22/2009 06:40 AM, Jeremy Olexa wrote: Nikos Chantziaras wrote: Huh? This is true of all overlays. Not the ones I'm using. Have you ever used the X11, GNOME or KDE teams overlays? Most of the overlays around exist so that people can work on important updates to existing packages or to test new ideas / features. In that respect, sunrise is a special overlay as it follows the rule that it must not contain any package in the tree. IOW, overlays having just new packages, not present in the tree or other overlays, are the exception, not the norm. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqP8k0ACgkQcAWygvVEyAKZnACgn3cRXNvfDsyGtswbYZCWEKjf VfgAn0Tbhej3uRw/wjtF5vc0XjvieLqZ =81nF -END PGP SIGNATURE-
Re: [gentoo-dev] New media-libs/jpeg-7 and how to deal with it.
Samuli Suominen wrote: Ciaran McCreesh wrote: On Sat, 22 Aug 2009 16:01:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: media-libs/jpeg-7 installs .so.7.0.0 so this causes some headacke for binary applications: Doesn't this mean you should slot it? No. I only want the .so.62 for binary apps, thus the ebuild won't install anything but the shared libs You wrote a header was now private so it will probably make a lot of ebuilds incompatible with 7.0. Maybe slotting could be useful even for them. Mounir
Re: [gentoo-dev] New media-libs/jpeg-7 and how to deal with it.
Mounir Lamouri wrote: No. I only want the .so.62 for binary apps, thus the ebuild won't install anything but the shared libs You wrote a header was now private so it will probably make a lot of ebuilds incompatible with 7.0. Maybe slotting could be useful even for them. No. The include was always private but we patched 6b to install it for a ancient bug involving media-gfx/feh.
[gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
On 08/22/2009 04:27 PM, Jorge Manuel B. S. Vicetto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nikos Chantziaras wrote: On 08/22/2009 06:40 AM, Jeremy Olexa wrote: Nikos Chantziaras wrote: Huh? This is true of all overlays. Not the ones I'm using. Have you ever used the X11, GNOME or KDE teams overlays? Nope. I had to remove them again due to the problem I mentioned. Most of the overlays around exist so that people can work on important updates to existing packages or to test new ideas / features. In that respect, sunrise is a special overlay as it follows the rule that it must not contain any package in the tree. IOW, overlays having just new packages, not present in the tree or other overlays, are the exception, not the norm. They are pretty much the only ones I use though (at this time, interactive-fiction, oss-overlay and sunrise.) The others are a pain to keep due to portage not being able to use only packages from overlays that don't exist in portage. Of course that's my personal opinion. I don't use developer/experimental overlays, I only use those who provide some extra packages I want. And I was under the impression that pure-funtoo falls under this category: providing packages that don't exist in portage.
Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
Nikos Chantziaras wrote: Of course that's my personal opinion. I don't use developer/experimental overlays, I only use those who provide some extra packages I want. And I was under the impression that pure-funtoo falls under this category: providing packages that don't exist in portage. By the nature of Funtoo being a entirely different distribution, that is a wrong assumption. It is unreasonable to expect the pure-funtoo overlay owner to mask everything that is an upgrade but not in portage yet. I would recommend that you remove the pure-funtoo overlay, because your expectations don't match reality. -Jeremy
[gentoo-dev] New 10.0 LiveDVD release enhancements
Fernando V Orocu (likewhoa) has been working on getting the 10.0 LiveDVD images in shape for the Gentoo 10th year anniversary release. We need some assistance in terms of LiveDVD testers, user suggestions for new packages software testers since there will be over 100+ new packages on this release dvd. We are looking for constructive feedback and ideas from both the developer community and user community. We want this 10th year anniversary release DVD to reflect our accomplishments over the year and your feedback is highly appreciated. Below are a few of the goals for the the LiveDVD release. 1. Supply both 32/64bit stable kernels 2. Enable HybridISO for the images 3. KDE/GNOME Desktop Environment 4. Speak-Up Functionality 5. your suggestions here Some links.. http://bugs.gentoo.org/281827 http://weboperative.com/gentoo/downloads/livecds svn co svn://anonsvn.gentoo.org/releng/trunk/releases/10.0 -Samuli
Re: [gentoo-dev] New 10.0 LiveDVD release enhancements
Samuli Suominen wrote: Fernando V Orocu (likewhoa) has been working on getting the 10.0 LiveDVD images in shape for the Gentoo 10th year anniversary release. We need some assistance in terms of LiveDVD testers, user suggestions for new packages software testers since there will be over 100+ new packages on this release dvd. We are looking for constructive feedback and ideas from both the developer community and user community. We want this 10th year anniversary release DVD to reflect our accomplishments over the year and your feedback is highly appreciated. Below are a few of the goals for the the LiveDVD release. 1. Supply both 32/64bit stable kernels 2. Enable HybridISO for the images 3. KDE/GNOME Desktop Environment 4. Speak-Up Functionality 5. your suggestions here Recently, Gentoo LiveCDs/DVDs moved to XFCE. I don't have a strong opinion on if XFCE is included or not, but I will assist if anything is needed on that front. -Jeremy
Re: [gentoo-dev] New 10.0 LiveDVD release enhancements
Maybe some Gentoo/GNOME Gentoo/KDE Gentoo/otherDEorWM wallpapers/logos/icons? I have some Gentoo/KDE wallpapers and logos that could be used. Or do we prefer strictly Gentoo anniversary artwork? On Sat, Aug 22, 2009 at 5:46 PM, Samuli Suominen ssuomi...@gentoo.orgwrote: Fernando V Orocu (likewhoa) has been working on getting the 10.0 LiveDVD images in shape for the Gentoo 10th year anniversary release. We need some assistance in terms of LiveDVD testers, user suggestions for new packages software testers since there will be over 100+ new packages on this release dvd. We are looking for constructive feedback and ideas from both the developer community and user community. We want this 10th year anniversary release DVD to reflect our accomplishments over the year and your feedback is highly appreciated. Below are a few of the goals for the the LiveDVD release. 1. Supply both 32/64bit stable kernels 2. Enable HybridISO for the images 3. KDE/GNOME Desktop Environment 4. Speak-Up Functionality 5. your suggestions here Some links.. http://bugs.gentoo.org/281827 http://weboperative.com/gentoo/downloads/livecds svn co svn://anonsvn.gentoo.org/releng/trunk/releases/10.0 -Samuli
Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
Sebastian Pipping wrote: Nikos Chantziaras wrote: Uhm, I just discovered that there are conflicts with portage too. That is not good. After I added pure-funtoo, it messed up my emerge -u world (stuff like wanting to upgrade to sys-apps/baselayout-2.1.5). Hopefully fixed http://git.goodpoint.de/?p=pure-funtoo.git;a=commitdiff;h=341663321f0cf876390fff5967105e403ed3fcbc See, the problem with this is when Gentoo itself gets a baselayout-2.1.x, then it is masked for them if they have the pure-funtoo overlay. IOW, people will complain one way, and then they will complain the other way. IMO, it is busy work for the overlay owner and should be left to the user to know what they are doing because all overlays are experimental. 2 cents, -Jeremy
[gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
On 08/22/2009 05:56 PM, Jeremy Olexa wrote: Sebastian Pipping wrote: Nikos Chantziaras wrote: Uhm, I just discovered that there are conflicts with portage too. That is not good. After I added pure-funtoo, it messed up my emerge -u world (stuff like wanting to upgrade to sys-apps/baselayout-2.1.5). Hopefully fixed http://git.goodpoint.de/?p=pure-funtoo.git;a=commitdiff;h=341663321f0cf876390fff5967105e403ed3fcbc See, the problem with this is when Gentoo itself gets a baselayout-2.1.x, then it is masked for them if they have the pure-funtoo overlay. IOW, people will complain one way, and then they will complain the other way. IMO, it is busy work for the overlay owner and should be left to the user to know what they are doing because all overlays are experimental. That is not true generally though. Most of them are of experimental nature, but some try to provide good, working and stable packages for stuff that can't make it into portage (no dev willing to adopt it, unpopular software, policy reasons, etc.) Just because something isn't in portage doesn't mean it's always experimental.
Re: [gentoo-dev] Re: New 10.0 LiveDVD release enhancements
On Sat, 2009-08-22 at 18:16 +0300, Nikos Chantziaras wrote: On 08/22/2009 05:46 PM, Samuli Suominen wrote: [...] Below are a few of the goals for the the LiveDVD release. 1. Supply both 32/64bit stable kernels 2. Enable HybridISO for the images 3. KDE/GNOME Desktop Environment 4. Speak-Up Functionality 5.your suggestions here Something that looks good in sites bringing the news. Gentoo is usually greeted with another release that looks like the previous one, this project is moving nowhere. So at least something to trick* them into saying something positive for a change would be nice. * trick them because if they see there's no installer, the bashing and negative rating will skyrocket again :P We really don't want another installer and I highly believe users won't really care if there is one or not. GLI was not a very good experience for many. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New 10.0 LiveDVD release enhancements
On Sat, 2009-08-22 at 17:54 +0300, Theo Chatzimichos wrote: Maybe some Gentoo/GNOME Gentoo/KDE Gentoo/otherDEorWM wallpapers/logos/icons? I have some Gentoo/KDE wallpapers and logos that could be used. Or do we prefer strictly Gentoo anniversary artwork? Please link to your artwork, I like to see if any of it can be of good use and if you're a designer a 10 year anniversary theme would be ideal. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
Nikos Chantziaras wrote: I use overlays for packages I can't get through portage. If they conflict, I don't use them. Why do you apply such a general rule? For instance I have been using dev-util/diffuse from the zugaina overlay until a newer version went into the gentoo tree. Portage tells you which overlays the packages you're about to install come from. I agree though, that masking is not a perfect solution here, or not even a solution if you want. Support for overlay-specific atoms could be a solution I think. In case you have the time helping us bring that to Gentoo that would be cool, I actually want support for that, too. Sebastian
Re: [gentoo-dev] New 10.0 LiveDVD release enhancements
On Sat, Aug 22, 2009 at 8:16 PM, Samuli Suominenssuomi...@gentoo.org wrote: We are looking for constructive feedback and ideas from both the developer community and user community. We want this 10th year anniversary release DVD to reflect our accomplishments over the year and your feedback is highly appreciated. Here's the thing: artwork needs to be put at the *top* of that list. The artwork is the one thing that is *immediately* visible to users, and goes a very long way in setting up a positive look and feel for the distro. If required, I would suggest that we set a bounty using foundation money for artwork (bootsplash+gnome+kde). -- ~Nirbheek Chauhan GNOME Team, Gentoo
Re: [gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Nikos Chantziaras wrote: (so that smoltGui can actually be used at all since it doesn't take a --server parameter.) Good catch. Just opened a new task for it here: http://soc.gentooexperimental.org/issues/show/67 Before submission you can view all the data you submit. Near the bottom should be a long list of package details, right above the privacy metrics table. No, I don't get anything like that. I see. More on that further down. I get a *lot* of errors at the beginning; a *big* stream of: ERROR:dbus.proxies:Introspect error on :1.0:/org/freedesktop /Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type=method_call, sender=:1.27 (uid=0 pid=17288 comm=/usr/bin/python) interface=org.freedesktop.DBus.Introspectable member=Introspect error name=(unset) requested_reply=0 destination=:1.0 (uid=0 pid=1668 comm=/usr/sbin/hald)) [...several hundreds more snipped...] Sorry to hear. I haven't touched Smolt dbus code though and I cannot do anything about it at the moment. And at the end: Smolt has collected four types of information: General Default run level: 3 Language: en_US.UTF-8 OS: Gentoo Base System release 2.0.1 ... Devices [...snipped...] File system-related [...snipped...] Distribution-specific No data, yet That No data, yet indicates you're not running the correct version of the Smolt client. Either that's a plain 1.3.x release or the master branch from my repo, not the gentoo one. Have you installed app-admin/gentoo-smolt- through portage? It has a blocker on !app-admin/smolt inside and EGIT_BRANCH=gentoo in the first line. Have you installed it off the overlay through sudo ebuild foo merge or so? Sebastian
Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
Nikos Chantziaras wrote: And I was under the impression that pure-funtoo falls under this category: providing packages that don't exist in portage. If you want to you can adjust funtoo-ripper to do just that on your local machine. All you have to do is adjust the EbuildTree._minus function: http://git.goodpoint.de/?p=funtoo-ripper.git;a=blob;f=funtoo-ripper Let me know if you have trouble with setting it up or if you have patches for me. Sebastian
Re: [gentoo-dev] New 10.0 LiveDVD release enhancements
Samuli Suominen wrote: 2. Enable HybridISO for the images What's this? Explain! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New 10.0 LiveDVD release enhancements
On Sat, 2009-08-22 at 09:52 -0700, Josh Saddler wrote: Samuli Suominen wrote: 2. Enable HybridISO for the images What's this? Explain! Starting in version 3.72, ISOLINUX supports a hybrid mode which can be booted from either CD-ROM or from a device which BIOS considers a hard disk or ZIP disk, e.g. a USB key or similar. In other words no more burning cd/dvds if you don't want. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 01:54:22 +0100 AllenJB gentoo-li...@allenjb.me.uk wrote: Could there be room for fast track EAPI's to be considered on some occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the package.* as directory in profiles feature included? It's a possibility, since it's zero cost for Portage and an easy one to word into the specification. Another possibly nicer option would be to add the feature into EAPI 3. However, if we're considering this, we'd have to be absolutely totally clear that this isn't a call to open up EAPI 3 for yet more changes. Zac said three months ago that Portage EAPI 3 support would be done in a month, so it can't be far off ready. We also need to consider whether people even want it done exactly the way Portage does it now. Some developers have expressed a preference for a package.mask.d of some kind instead. So yes, it's something that could be done, if the Council is interested and if it's not going to be used as an excuse to try to shove a whole load of other things through at the same time. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Last rites for dev-ruby/ruby-amazon
# Hans de Graaff gra...@gentoo.org (22 Aug 2009) # ruby-amazon uses the obsolete v3 protocol which has been shut # down by Amazon on 2008-03-31, and upstream indicates that they # will not continue development on it. dev-ruby/ruby-amazon Given that it no longer works I'll remove it in 30 days. Kind regards, Hans signature.asc Description: This is a digitally signed message part
RE: [gentoo-dev] New 10.0 LiveDVD release enhancements
-Original Message- From: Samuli Suominen [mailto:ssuomi...@gentoo.org] Sent: August 22, 2009 10:47 AM To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] New 10.0 LiveDVD release enhancements Fernando V Orocu (likewhoa) has been working on getting the 10.0 LiveDVD images in shape for the Gentoo 10th year anniversary release. We need some assistance in terms of LiveDVD testers, user suggestions for new packages software testers since there will be over 100+ new packages on this release dvd. We are looking for constructive feedback and ideas from both the developer community and user community. We want this 10th year anniversary release DVD to reflect our accomplishments over the year and your feedback is highly appreciated. Below are a few of the goals for the the LiveDVD release. 1. Supply both 32/64bit stable kernels 2. Enable HybridISO for the images 3. KDE/GNOME Desktop Environment 4. Speak-Up Functionality 5. your suggestions here Some links.. http://bugs.gentoo.org/281827 http://weboperative.com/gentoo/downloads/livecds svn co svn://anonsvn.gentoo.org/releng/trunk/releases/10.0 -Samuli How would a non-developer go about participating in the test?
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-22 21:39:47 Ciaran McCreesh napisał(a): On Sat, 22 Aug 2009 01:54:22 +0100 AllenJB gentoo-li...@allenjb.me.uk wrote: Could there be room for fast track EAPI's to be considered on some occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the package.* as directory in profiles feature included? It's a possibility, since it's zero cost for Portage and an easy one to word into the specification. Another possibly nicer option would be to add the feature into EAPI 3. However, if we're considering this, we'd have to be absolutely totally clear that this isn't a call to open up EAPI 3 for yet more changes. EAPI=3 can be opened also for other changes trivial to implement (e.g. allowing bash-4.0 features). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 22:22:54 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Another possibly nicer option would be to add the feature into EAPI 3. However, if we're considering this, we'd have to be absolutely totally clear that this isn't a call to open up EAPI 3 for yet more changes. EAPI=3 can be opened also for other changes trivial to implement (e.g. allowing bash-4.0 features). That isn't a trivial implementation feature unless GLEP 55 is passed, since it breaks sourcing for metadata for users of older Portage versions. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 01:32:33 -0400 Andrew D Kirch trel...@trelane.net wrote: Ryan Hill wrote: On Fri, 21 Aug 2009 17:29:12 -0700 Chip Parker infowo...@gmail.com wrote: If you were building a house, and the blueprints had been signed off on calling for 1 meter high doors, but the builder had built in 2 meter high doors, would you then go back to the builder and require him to do something that makes those doors unusable for the vast majority of people entering the house? Package managers can implement whatever extra bells and whistles they like, but they still have to follow the spec. Your metaphor is flawed in that you're talking about a single house here. If it doesn't match the plan you do an as-built and file a deviation with the registrar. The situation here is more like if you build a hundred houses to code, and then one above code, and then change code to match the one house and bulldoze the rest for not meeting minimal requirements. You're punishing anyone who implements a package manager to spec if you keep changing the spec in incompatible ways. Right, this is called punishing innovation. It's a hobby of bureaucrats everywhere. It could also be said to be punishing excellence. We've had a lot of political systems which try to implement a design which weeds out both the mediocre, and the excellent, leaving us with the average all have been failures. The reason why they fail is that it is the above average who do the heaviest lifting. No, you're still missing the point. Innovation is good. Rewarding innovation is good, which is why we change the spec in backwards-compatible ways to incorporate the best ideas every so often, through new EAPIs. What is bad is when one particular package manager innovates and we retroactively change the spec to match what it does, leaving all the PM's that operate according to what the spec previously said to do up the river. For the record, I use portage. I have always used portage. I just don't see the point of having a specification on how to write a PM that works with Gentoo if we keep changing that spec on whim. -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] package.mask or package.mask.d
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Aug 22, 2009 at 08:39:47PM +0100, Ciaran McCreesh wrote: We also need to consider whether people even want it done exactly the way Portage does it now. Some developers have expressed a preference for a package.mask.d of some kind instead. I saw that, and I'm not sure why they suggested changing the directory from package.mask to package.mask.d, since all you would need to do is rename the file package.mask to something like package.mask/oldmasks and the masks in it would be preserved until you put them in different files in the package.mask directory and removed them from oldmasks, ultimately deleting oldmasks. - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqQWqYACgkQblQW9DDEZTiKxQCfejjxnM/8EmhXglK6bpnzCxIG emcAn3CFgDOJ27wkNWo46DZh2p/N5J74 =v+g+ -END PGP SIGNATURE-
[gentoo-dev] Last rites for dev-ruby/cgi_multipart_eof_fix
# Hans de Graaff gra...@gentoo.org (22 Aug 2009) # cgi_multipart_eof_fix is used to fix ruby versions up to 1.8.5. # We no longer ship these versions, and all versions in the tree # are unaffected, so this will be removed in 30 days. dev-ruby/cgi_multipart_eof_fix signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 14:47:44 -0700 Chip Parker infowo...@gmail.com wrote: * When loading profiles '/etc/make.profile' for repository 'gentoo': /etc/make.profile is user configuration, and beyond the scope of PMS. Additionally, I plan to show very soon that PMS is incorrect in its requirement that profiles/parent includes only relative paths. It is impossible to include absolute paths in repository parent files, since there is no guaranteed filesystem location for repositories. This is now the third time I've had to tell you that user configuration is not part of PMS. You're contributing substantially to the amount of noise on the subject, wasting the time of everyone who has to read your posts and respond to them. Kindly stop. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Fri, Aug 21, 2009 at 5:34 PM, Ciaran McCreeshciaran.mccre...@googlemail.com wrote: On Fri, 21 Aug 2009 17:29:12 -0700 Chip Parker infowo...@gmail.com wrote: If this feature, which HAD been documented (in bugzilla and commitlogs) prior to the first RFC for PMS As I've already explained to you on bugzilla, this is untrue. You're confusing user configuration with the tree. PMS has nothing to say about user configuration, and nothing is being done to take away the feature you're concerned about. -- Ciaran McCreesh This assertion is not only incorrect but asinine. build paludis # paludis -q apache palu...@1250977472: [WARNING e.ebuild.configuration.no_names_cache] The names_cache key is not set in '/etc/paludis/repositories/gentoo.conf'. You should read the Paludis documentation and select an appropriate value. Unhandled exception: * In program paludis -q apache: * When performing query action from command line: * When handling query 'apache': * When parsing user package dep spec 'apache': * When parsing generic package dep spec 'apache': * When disambiguating package name 'apache': * When finding all versions in some arbitrary order from packages matching */apache with filter all matches filtered through all matches: * When finding category names containing package 'apache': * When loading names for virtuals repository: * When loading virtual packages for repository 'gentoo' * When loading profiles '/etc/make.profile' for repository 'gentoo': * When using directory '/etc/make.profile': * When adding profile directory '/etc/make.profile: * When handling parent file for profile directory '/etc/make.profile: * When adding profile directory '/etc/managed-portage/common/pre/make.profile: * When loading specised use file '/etc/managed-portage/common/pre/make.profile/package.use: * In file '/etc/managed-portage/common/pre/make.profile/package.use': Error reading file: 'Error reading from fd 3: Is a directory' (paludis::SafeIFStreamError) (paludis::ConfigFileError) Additionally, I plan to show very soon that PMS is incorrect in its requirement that profiles/parent includes only relative paths. This shows that both the PMS spec and your pet package manager are incapable of supporting behavior that was considered correct by portage prior to your initial RFC.
[gentoo-dev] Last rites for dev-ruby/devel-logger
# Hans de Graaff gra...@gentoo.org (22 Aug 2009) # devel-logger is now bundled with ruby 1.8. The standalone version # is only suited for ruby 1.6, which has gone from our tree a long # time ago. devel-logger will follow in 30 days. dev-ruby/devel-logger signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New media-libs/jpeg-7 and how to deal with it.
On Saturday 22 August 2009 10:19:00 Samuli Suominen wrote: Mounir Lamouri wrote: No. I only want the .so.62 for binary apps, thus the ebuild won't install anything but the shared libs You wrote a header was now private so it will probably make a lot of ebuilds incompatible with 7.0. Maybe slotting could be useful even for them. No. The include was always private but we patched 6b to install it for a ancient bug involving media-gfx/feh. sounds correct to me. ABI change only - no SLOT. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, Aug 22, 2009 at 2:52 PM, Ciaran McCreeshciaran.mccre...@googlemail.com wrote: On Sat, 22 Aug 2009 14:47:44 -0700 Chip Parker infowo...@gmail.com wrote: * When loading profiles '/etc/make.profile' for repository 'gentoo': /etc/make.profile is user configuration, and beyond the scope of PMS. Additionally, I plan to show very soon that PMS is incorrect in its requirement that profiles/parent includes only relative paths. It is impossible to include absolute paths in repository parent files, since there is no guaranteed filesystem location for repositories. This is now the third time I've had to tell you that user configuration is not part of PMS. You're contributing substantially to the amount of noise on the subject, wasting the time of everyone who has to read your posts and respond to them. Kindly stop. -- Ciaran McCreesh Since you have a habit of ignoring relevant bits of technical opposition to some of your more insane schemes, I'll cite *again* the relevant portion. '/etc/managed-portage/common/pre/make.profile/package.use: * In file '/etc/managed-portage/common/pre/make.profile/package.use': Error reading file: 'Error reading from fd 3: Is a directory' (paludis::SafeIFStreamError) (paludis::ConfigFileError) This is the exact same error that I get either when using the portage compatibility OR paludis with my profile defined in the only configuration file type where it is allowed to go (on my system /etc/paludis/repositories/gentoo-portage.conf), as per the paludis documentation. (http://paludis.pioto.org/configuration/repositories/e.html) build managed-portage # paludis -q apache palu...@1250986148: [WARNING portage_environment.dodgy] Use of Portage configuration files will lead to sub-optimal performance and loss of functionality. Full support for Portage configuration formats is not guaranteed; issues should be reported via trac. Unhandled exception: snip repeat of previous email output * In file '/etc/managed-portage/common/pre/make.profile/package.use': Error reading file: 'Error reading from fd 3: Is a directory' (paludis::SafeIFStreamError) (paludis::ConfigFileError) So, Ciaran, if your personal reference implementation of PMS fails miserably when using this methodology, your argument that I won't be or am not affected by your attempt at changing portage is invalid. If you'd like to test for yourself, I'll be more than happy to tar up both my /etc/paludis and /etc/managed-portage for you. If you can show me a DOCUMENTED configuration option for including a profiles/ directory for use with paludis that is outside of defining it in a repositories/*.conf file, and it's tested working, I'll gladly be quiet and go away. Otherwise, I will continue to loudly object to you attempting to break my systems.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sunday 23 August 2009 01:26:24 Chip Parker wrote: So, Ciaran, if your personal reference implementation of PMS fails miserably when using this methodology, your argument that I won't be or am not affected by your attempt at changing portage is invalid. If you'd like to test for yourself, I'll be more than happy to tar up both my /etc/paludis and /etc/managed-portage for you. You're still talking about /etc, which is still unaffected by PMS. If Paludis doesn't support a feature in /etc that you want to use, then feel free to file a bug. If Portage supports that feature in /etc, there's no reason why it needs to stop doing so, regardless of what it does or doesn't accept in the tree.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 17:26:24 -0700 Chip Parker infowo...@gmail.com wrote: Since you have a habit of ignoring relevant bits of technical opposition to some of your more insane schemes, I'll cite *again* the relevant portion. I showed you the relevant portion. /etc/make.profile means it is user configuration, which in turn means PMS has absolutely nothing to say about it. Anything done under /etc/make.profile is entirely up to the package manager and is not covered by the specification. So for the fourth time, no-one has asked for anything that will break what you're doing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, Aug 22, 2009 at 5:32 PM, David Levertonlevert...@googlemail.com wrote: On Sunday 23 August 2009 01:26:24 Chip Parker wrote: So, Ciaran, if your personal reference implementation of PMS fails miserably when using this methodology, your argument that I won't be or am not affected by your attempt at changing portage is invalid. If you'd like to test for yourself, I'll be more than happy to tar up both my /etc/paludis and /etc/managed-portage for you. You're still talking about /etc, which is still unaffected by PMS. If Paludis doesn't support a feature in /etc that you want to use, then feel free to file a bug. If Portage supports that feature in /etc, there's no reason why it needs to stop doing so, regardless of what it does or doesn't accept in the tree. They're the same thing. It doesn't matter if the profiles directory is in located in /tmp or in /usr/local/portage, the behavior of paludis *still* doesn't support the feature that these profiles depend on and portage still *HAS* since before PMS was submitted to this list as an RFC in August of 2006. The argument here is that PMS should be changed to reflect what has been being used in the wild since before it came into existence, especially considering the removal of the particular feature that this trick depends on would break user expected behavior. On Sat, Aug 22, 2009 at 5:34 PM, Ciaran McCreeshciaran.mccre...@googlemail.com wrote: On Sat, 22 Aug 2009 17:26:24 -0700 Chip Parker infowo...@gmail.com wrote: Since you have a habit of ignoring relevant bits of technical opposition to some of your more insane schemes, I'll cite *again* the relevant portion. I showed you the relevant portion. /etc/make.profile means it is user configuration, which in turn means PMS has absolutely nothing to say about it. Anything done under /etc/make.profile is entirely up to the package manager and is not covered by the specification. So for the fourth time, no-one has asked for anything that will break what you're doing. You claim that PMS doesn't matter outside of a repository, and yet it most certainly does, because as I said to David, it doesn't matter /where/ the profiles are actually located: /etc/, /tmp/, /usr/local/portage/, or /usr/portage/ the behavior *should* be both consistent and not unnecessarily restricted by a specification controlled by a person who is on the outside of the Gentoo organization. If you'd prefer, I can merge my /etc/managed-portage stuff with my internal overlay and then bitch loudly about you attempting to remove features that existed prior to your involvement in Gentoo's package managers. Additionally, there isn't a way to define in paludis where the profiles actually exist outside of the repository configuration files, which means that in your mind, they're one and the same. What you proposed in the bug you filed would specifically break how I do things, without replacing it with an equal or better solution. Your inability or unwillingness to comprehend that simple fact is really not my concern. When the most prolific committer to PMS also happens to the most prolific committer and is listed as owning the repository for a competing package manager, it looks suspiciously like conflict of interest.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 18:10:36 -0700 Chip Parker infowo...@gmail.com wrote: What you proposed in the bug you filed would specifically break how I do things, without replacing it with an equal or better solution. No it wouldn't. It would have no effect whatsoever on how you do things. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sunday 23 August 2009 02:10:36 Chip Parker wrote: They're the same thing. It doesn't matter if the profiles directory is in located in /tmp or in /usr/local/portage, the behavior of paludis *still* doesn't support the feature that these profiles depend on and portage still *HAS* since before PMS was submitted to this list as an RFC in August of 2006. The behaviour of Paludis doesn't matter as far as your own /etc goes, because you (presumably) don't use Paludis. You're free to use whatever's supported by your own favourite package manager. Additionally, there isn't a way to define in paludis where the profiles actually exist outside of the repository configuration files, which means that in your mind, they're one and the same. You can read minds now? The actual reason why the profile is configured in the repository configuration file is that the profile used by a particular repository's packages is a parameter to that repository. Not that that's relevant to what you do in your own /etc, as I said above.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-23 02:34:08 Ciaran McCreesh napisał(a):
On Sat, 22 Aug 2009 17:26:24 -0700
Chip Parker infowo...@gmail.com wrote:
Since you have a habit of ignoring relevant bits of technical
opposition to some of your more insane schemes, I'll cite *again* the
relevant portion.
I showed you the relevant portion. /etc/make.profile means it is user
configuration, which in turn means PMS has absolutely nothing to say
about it. Anything done under /etc/make.profile is entirely up to the
package manager and is not covered by the specification.
/etc/make.profile is by default a symlink to appropriate profile directory
in ${PORTDIR}/profiles. Documentation of /etc/make.profile concerns also
all profile directories.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and nonfatal die
2009-08-22 01:43:54 Ciaran McCreesh napisał(a): On Sat, 22 Aug 2009 01:39:41 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: There was a clarification of the wording after it became clear that there was room to misinterpret the intent of the original wording, and it went through the usual Council-mandated process for such a change. This sentence contradicts your first sentence. No, it doesn't. it went through the usual Council-mandated process for such a change clearly contradicts There was no change. There was a change in wording to better convey the original intent. There was no change in behaviour. There was a change in behavior of 'nonfatal eclass_function_which_sometimes_calls_die'. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
