Re: [gentoo-dev] EAPI 2 must die
On Thu, Jun 6, 2019 at 8:07 AM Andreas K. Huettel wrote: > Hi all, > > for the package maintainers among you, here's the list of remaining EAPI=2 > packages. Please help getting the number down to zero soon!!! > > Cheers, > Andreas > > media-fonts/culmus-0.120-r4 > > Done.
Re: [gentoo-dev] EAPI 2 must die
On 6/6/19 1:06 AM, Andreas K. Huettel wrote: > Hi all, > > for the package maintainers among you, here's the list of remaining EAPI=2 > packages. Please help getting the number down to zero soon!!! > > ... > net-analyzer/nagtrap-0.1.3 Last release in 2008, no maintainer, dead homepage, dead SourceForge page; can likely be put to rest.
[gentoo-dev] EAPI 2 must die
Hi all, for the package maintainers among you, here's the list of remaining EAPI=2 packages. Please help getting the number down to zero soon!!! Cheers, Andreas app-emulation/ganeti-instance-debootstrap-0.11 app-misc/dnetc-2.9108.517 app-misc/dnetc-2.9110.519b dev-dotnet/flickrnet-bin-2.2-r1 dev-java/glassfish-jms-api-1.1.2.2.04 dev-java/jlayer-1.0.1 dev-java/resin-servlet-api-3.1.12 dev-libs/bglibs-1.106-r1 dev-lisp/clisp-2.48-r1 dev-lua/toluapp-1.0.93 dev-tex/culmus-latex-0.7 dev-tex/dvipost-1.1-r2 media-fonts/culmus-0.120-r4 net-analyzer/nagtrap-0.1.3 net-libs/cvm-0.76 net-misc/adjtimex-1.29-r1 net-misc/asterisk-extra-sounds-1.4.11 net-misc/asterisk-moh-opsound-2.03 net-misc/cfengine-2.2.10-r4 net-misc/tokyotyrant-1.1.41-r1 sci-libs/openfoam-bin-1.6 sys-apps/cobalt-panel-utils-1.0.2 sys-apps/powerpc-utils-1.1.3.18-r2 sys-boot/netboot-0.10.2 sys-process/fuser-bsd-1142334561 www-apache/mod_tidy-0.5.5-r1 Already masked for removal: app-accessibility/festival-2.1-r1 dev-java/glassfish-connector-api-1.1.2.2.04 dev-util/antlrworks-1.2.3 dev-util/pmd-4.2.5 net-mail/qmail-qfilter-2.1-r1 net-misc/mindterm-3.4 -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice)
[gentoo-dev] EAPI=2 must die!!!
Hey all, there are only 92 ebuilds with EAPI=2 left in the tree. Let's make sure this number goes down faaast! Cheers, Andreas app-accessibility/festival-2.1-r1 app-emulation/ganeti-htools-0.3.1 app-emulation/ganeti-instance-debootstrap-0.11 app-misc/bottlerocket-0.04c-r1 app-misc/dnetc-2.9108.517 app-misc/dnetc-2.9110.519b app-text/bibutils-4.12 app-text/refbase-0.9.5 dev-dotnet/flickrnet-bin-2.2-r1 dev-embedded/tavrasm-1.22-r1 dev-java/dbus-java-2.7-r1 dev-java/echo2-2.1.1 dev-java/glassfish-connector-api-1.1.2.2.04 dev-java/glassfish-jms-api-1.1.2.2.04 dev-java/idm-console-framework-1.1.7 dev-java/jgroups-2.9.0 dev-java/jicmp-1.0.2 dev-java/jinklevel-0.1 dev-java/jlayer-1.0.1 dev-java/jline-1.0 dev-java/jvyamlb-0.2.5 dev-java/libmso-0.1 dev-java/libreadline-java-0.8.0-r3 dev-java/matrix-toolkits-java-0.9.12 dev-java/nailgun-0.7.1-r1 dev-java/proguard-4.5 dev-java/resin-servlet-api-3.1.12 dev-java/sat4j-core-2.2.0 dev-java/sat4j-core-2.3.1-r1 dev-java/sat4j-pseudo-2.2.0 dev-java/sat4j-pseudo-2.3.1 dev-java/tijmp-0.8 dev-java/xjavac-20110814 dev-java/zemberek-2.1.1 dev-lang/confluence-0.10.6 dev-lang/mozart-stdlib-1.4.0-r1 dev-libs/bglibs-1.106-r1 dev-lisp/clisp-2.48-r1 dev-lua/toluapp-1.0.93 dev-ml/ocaml-autoconf-1.1 dev-scheme/guile-cairo-1.4.0 dev-tex/culmus-latex-0.7 dev-tex/curve-1.16 dev-tex/dvi2gr-0.4 dev-tex/dvipost-1.1-r2 dev-tex/revtex-4.1_p2-r1 dev-util/antlrworks-1.2.3 dev-util/btyacc-3.0-r2 dev-util/ftnchek-3.3.1-r1 dev-util/pmd-4.2.5 dev-vcs/easygit-1.6.5.5 mail-filter/libmilter-1.0.2 media-fonts/culmus-0.120-r4 media-gfx/flam3- media-gfx/openclipart-0.20 media-gfx/pixie-2.2.6-r1 media-gfx/xloadimage-4.1-r11 media-sound/id3ed-1.10.4 media-sound/mt-daapd-0.2.4.2 media-sound/peercast-0.1218-r2 media-sound/vkeybd-0.1.18d net-analyzer/barnyard-0.2.0-r3 net-analyzer/barnyard2-1.9 net-analyzer/nagtrap-0.1.3 net-libs/cvm-0.76 net-libs/cvm-0.96 net-mail/mailfront-1.16 net-mail/qmail-autoresponder-0.97-r1 net-mail/qmail-autoresponder-0.97-r2 net-mail/qmail-qfilter-2.1-r1 net-misc/adjtimex-1.29-r1 net-misc/asterisk-extra-sounds-1.4.11 net-misc/asterisk-moh-opsound-2.03 net-misc/cfengine-2.2.10-r4 net-misc/mindterm-3.4 net-misc/secpanel-0.6.1-r1 net-misc/smbc-1.2.2-r2 net-misc/tokyotyrant-1.1.41-r1 sci-electronics/gnucap-0.35.20091207 sci-libs/openfoam-bin-1.6 sys-apps/cobalt-panel-utils-1.0.2 sys-apps/makedev-3.23.1 sys-apps/powerpc-utils-1.1.3.18-r2 sys-block/scsiadd-1.97 sys-boot/netboot-0.10.2 sys-process/fuser-bsd-1142334561 sys-process/supervise-scripts-4.0 www-apache/mod_tidy-0.5.5-r1 www-misc/visitors-0.7-r1 x11-terms/root-tail-1.2-r3 x11-themes/fluxbox-styles-fluxmod-20050128-r1 x11-wm/vtwm-5.4.7-r1 -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tuesday 09 December 2008 12:13:40 pm Petteri Räty wrote: Robert R. Russell wrote: My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. The current policy states that ebuilds should only be bumped if the installed files change. Changing EAPI from 1 to 2 has no effect outside the vdb so the current policy means developers should use option 3. There was a bug in stable Portage when EAPI 2 went in the tree that made Portage stack trace but that's a problem with Portage not with the policy in general. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Why should we prefer making it a little bit easier for stable users over making ~arch users needlessly recompile stuff? Regards, Petteri My answer is a simple example from my own system. My current system uses a motherboard that is around 6 months old and is only correctly supported by the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I am using the latest ~arch xorg-x11. The internal video card isn't even recognized by the xf86-video-intel drivers except the ~arch versions. Even some of the packages I use for school work such as kile have bugfixes and other improvements between the versions in stable and ~arch that are important to getting work done. The ability to selectively upgrade only the specific packages needed to get a working system is a major strength for Gentoo. Why should I have to run more packages from ~arch than I absolutely need to? We all know that upgrading more software than absolutely necessary will result in bad things happening to a computer. The easiest solution to the problem with ~arch having the only working versions of some packages is to get more of those packages stabilized. But, we all know that the manpower required simply doesn't exist.
Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell wrote: My answer is a simple example from my own system. My current system uses a motherboard that is around 6 months old and is only correctly supported by the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I am using the latest ~arch xorg-x11. The internal video card isn't even recognized by the xf86-video-intel drivers except the ~arch versions. Even some of the packages I use for school work such as kile have bugfixes and other improvements between the versions in stable and ~arch that are important to getting work done. The ability to selectively upgrade only the specific packages needed to get a working system is a major strength for Gentoo. With all of these problems, it sounds like in your case, our stable tree isn't living up to our hopes. *This* is the problem you should be bringing to our attention, instead of complications with portage and EAPI. I looked up your email address on bugzilla, hoping to find at least 5 bug reports, one for each of the problems you describe above. I could only find one (and even that one doesn't really make clear the fact that the current stable has problems which is affecting your schoolwork). Please could you fix that? Thanks! Daniel
Re: [gentoo-dev] EAPI 2 policy for portage tree
why offlist? Robert R. Russell wrote: Stabilization reports for ~xorg-x11 and the ~xf86-video-intel drivers aren't likely to go any where given the number of issues people are asking about on the forums But the important thing is that you notify the maintainers that you're in trouble. That may encourage them to focus more on the remaining blockers. But at the very minimum it makes them aware, and it serves as documentation for others who may hit the same problem. and the time taken to fix even simple bugs like this one https://bugs.gentoo.org/show_bug.cgi?id=227895 You can't judge the whole of Gentoo on your experience with one bug. It is also not an excuse for not filing the bugs, even if they take a while to get fixed. A user reporting the problem is just as significant as a developer fixing it. A more accurate guide to what the devs want on a filed bug report or a reply to a bug report( patches to the ebuilds, patches to the software, and the like) would help me out in giving the devs what they need or want. Suggestions appreciated. My advice would be, if something is broken, then file a bug (after doing some sanity checking to attempt to confirm it's not your fault, and nobody else has filed it). As far as the kile stabilization report, what priority do stabilization reports need? Do I need to give exact details on what doesn't work in the old version compared to the new version, which is unlikely because I can't even remember the problem that forced an upgrade? I wouldn't bother with the priority field. But information on the benefits and importance of stabling is important. Give developers motivation to fix the bug, by describing what problems the stabilisation solves. The end of school will also help with the bug filling rate going up in the next week or so. Great! Daniel
Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell [EMAIL PROTECTED] writes: 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Another reason for preferring option 3 for bug fix (but not for 'cosmetic' changes or ones which prevent some users from installing the package) is that (~arch) users will already have the pre-bug fixed version installed and portage will not install the bug fix unless either the version is bumped or USE flags have changed and the --newuse emerge option is used.
Re: [gentoo-dev] EAPI 2 policy for portage tree
Jean-Marc Hengen wrote: tree and my policies (more precisely: I can't keep current stable portage and cmake-2.6.2). My solution to the problem, was to copy the ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. The drawback of this workaround is, I could miss important fixes, like security fixes. [snip] the cmake-2.6.2 ebuild. This has the advantage, that people with a setup like mine can continue to use, what they already use and work on the cmake ebuild can continue in the new revision. If the new revision fixes a security issue, one can mask the old version, with a message with bug telling this. Just FYI, there's no difference -- when you've chosen to use the ~arch version, you *have* to follow any updates to it as soon as possible if you want to be reasonably sure you aren't affected by a security bug, as our security team doesn't issue GLSAs for ~arch packages. Sticking with a version that works for you doesn't mean you're somehow protected form security bugs. So to put this into perspective with cmake -- if there was a security bug in current version (which you'd keep as you don't want to upgrade Portage) and the fix for this bug would be using EAPI=2 (which is not an unrealistic situation), you'd be affected. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell wrote: My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. The current policy states that ebuilds should only be bumped if the installed files change. Changing EAPI from 1 to 2 has no effect outside the vdb so the current policy means developers should use option 3. There was a bug in stable Portage when EAPI 2 went in the tree that made Portage stack trace but that's a problem with Portage not with the policy in general. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Why should we prefer making it a little bit easier for stable users over making ~arch users needlessly recompile stuff? Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] EAPI 2 policy for portage tree
Hi, I like to write about an observation about gentoo, I made the past weeks, which does frustrate me personally a little bit, mainly because it makes administration a bit harder for me. It could be considered as an issue or as yet another case of When you play with unstable packages, you're on your own.. It's about EAPI 2 and maybe it isn't worth changing anything with portage 2.1.6 on the way, but I guess, with future EAPI's such a situation could be repeated, so maybe there's interest in discussing it. If I'm to late and missed the discussion, I apologize for the spam. This mail is about EAPI usage in the portage tree. Let me describe it, with what happened today: I'm running a mostly stable system (91 of 1255 installed packages are unstable), but I test here and there some packages. On of the packages, which I installed and is currently masked unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy with it so far. Today, while updating, portage wanted to downgrade cmake to the stable release, due to all cmake 2.6.x version masked by EAPI 2. The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a bug). My rule of thumb is to only use unstable on none system packages after checking, what can go wrong with the unstable package and if I can afford the worst case. Generally I consider portage to be a no-go as unstable package. So I'm in the situation, where I used cmake-2.6.2 on a daily basis and like to continue, but I can't with the current state of tree and my policies (more precisely: I can't keep current stable portage and cmake-2.6.2). My solution to the problem, was to copy the ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. The drawback of this workaround is, I could miss important fixes, like security fixes. This isn't the first issue I had with EAPI 2, but they were until now always upgrades to new version or new packages, so I abandoned and stayed with the current version or didn't install the package at all and wait for stable portage with EAPI 2 support. Up till now I could always do without those packages, but if I needed one necessarily, I guess, I would have backported the ebuild to a older EAPI, rather than upgrading portage. What I don't want to say, is that EAPI 2 should be blocked, rather the contrary, I look forward to EAPI 2, but from my perspective, in the particular case of cmake described above, I rather had added a new revision (cmake-2.6.2-r1) with EAPI 2 and the fix and wouldn't touch the cmake-2.6.2 ebuild. This has the advantage, that people with a setup like mine can continue to use, what they already use and work on the cmake ebuild can continue in the new revision. If the new revision fixes a security issue, one can mask the old version, with a message with bug telling this. So persons like me know, that they have to decide, what to do. Certainly one can have a different approach (like the one, that the maintainer of cmake took), which I do accept and what I descriped would be my solution. So this is about, if the current policy for using EAPI 2 in the tree is really good or it should be improved, when introducing future EAPI's, where portage supporting that EAPI is still unstable. My proposal would be, to only use new EAPI with a new version or revision and also let the last non new EAPI version for unstable packages in the tree. This would allow users of that unstable package with stable portage to not downgrade or maintain their local version or forced to upgrade portage. This would be a start. I guess, I'm not the only one, having such a setup and it prevent user's like me testing unstable packages. I need my PC on a daily basis, I can't afford, having it to reinstall, only because I played with unstable software. That's why I'm strict, when it comes to system packages or important packages to me (and I have to congratulate the gentoo devs for their work, my system just works like a charm and I'm very happy with gentoo, only hardware failures could make me headaches). So what I expect, is to find out, if setups like mine can or should be somehow supported. I'm fine, when the outcome is, that I won't be supported, then I know and should rethink my strategy to manage my gentoo boxes. With kind regards, Jean-Marc Hengen, a happy gentoo user
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 01:00 +0100, Jean-Marc Hengen wrote: So this is about, if the current policy for using EAPI 2 in the tree is really good or it should be improved, when introducing future EAPI's, where portage supporting that EAPI is still unstable. My proposal would be, to only use new EAPI with a new version or revision and also let the last non new EAPI version for unstable packages in the tree. This would allow users of that unstable package with stable portage to not downgrade or maintain their local version or forced to upgrade portage. This would be a start. I guess, I'm not the only one, having such a setup and it prevent user's like me testing unstable packages. I need my PC on a daily basis, I can't afford, having it to reinstall, only because I played with unstable software. That's why I'm strict, when it comes to system packages or important packages to me (and I have to congratulate the gentoo devs for their work, my system just works like a charm and I'm very happy with gentoo, only hardware failures could make me headaches). So what I expect, is to find out, if setups like mine can or should be somehow supported. I'm fine, when the outcome is, that I won't be supported, then I know and should rethink my strategy to manage my gentoo boxes. As a arch developer and mostly stable user, I also find this very frustrating. I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Mon, 08 Dec 2008 19:09:50 -0500 Olivier Crête [EMAIL PROTECTED] wrote: I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. The can be tested properly phase is when it's in ~arch... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:11 +, Ciaran McCreesh wrote: On Mon, 08 Dec 2008 19:09:50 -0500 Olivier Crête [EMAIL PROTECTED] wrote: I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. The can be tested properly phase is when it's in ~arch... That also means that to pull a significant number of ebuilds it forces mostly everyone to test it.. and that part is annoying.. The testing should be two phased, the first for regression (against existing ebuilds), and once thats stable, then we can test with new ebuilds... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:29 +, Ciaran McCreesh wrote: On Mon, 08 Dec 2008 19:25:44 -0500 Olivier Crête [EMAIL PROTECTED] wrote: The testing should be two phased, the first for regression (against existing ebuilds), and once thats stable, then we can test with new ebuilds... Uh, regression testing's handled by the package manager's extensive set of unit tests, which can cover this with targetted accuracy with much more reliability than making sure random ebuilds still work. We all know that portage doesn't have an extensive testing suite... And that test suites can't cover all the cases that the whole tree does... What you're suggesting here is making everyone wait four more months for no increase in safety. I'm not suggesting waiting any longer, just not pushing ebuilds into the tree until we have a stable enough version of portage that handles them (and if we do, then lets mark it as stable..). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Mon, 08 Dec 2008 19:25:44 -0500
Olivier Crête [EMAIL PROTECTED] wrote:
The can be tested properly phase is when it's in ~arch...
That also means that to pull a significant number of ebuilds it forces
mostly everyone to test it.. and that part is annoying..
If you don't like it, don't run ~arch.
I have to agree with Ciaran on this one.
Furthermore, it's unrealist and to an extent unfair to impose
limitations on ~arch ebuilds because of arch users. Gentoo should
support arch users, but that doesn't mean making sure ~arch ebuilds
work for arch users. When a arch user opts to use an ~arch ebuild,
he/she does so at his own risk.
About replacing EAPI-{0,1} ebuilds with EAPI-2 ebuilds, I can agree
with the proposal, although one can pick earlier versions/revisions from
http://sources.gentoo.org/viewcvs.py/gentoo-x86/
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkk9zYcACgkQcAWygvVEyAKEmQCfblj0GaZSITsF6/L0PvZVBLyA
1QsAoIote0hbzetNbcrPvWUpTuIOPITW
=XnAf
-END PGP SIGNATURE-
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Monday 08 December 2008 06:00:10 pm Jean-Marc Hengen wrote: snip This mail is about EAPI usage in the portage tree. Let me describe it, with what happened today: I'm running a mostly stable system (91 of 1255 installed packages are unstable), but I test here and there some packages. On of the packages, which I installed and is currently masked unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy with it so far. Today, while updating, portage wanted to downgrade cmake to the stable release, due to all cmake 2.6.x version masked by EAPI 2. The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a bug). My rule of thumb is to only use unstable on none system packages snip With kind regards, Jean-Marc Hengen, a happy gentoo user The problem is not that an EAPI 2 supporting portage is unstable or that he is using a ~arch version of one particular package, but the during a bugfix the maintainer moved the ebuild to EAPI 2 without a version bump forcing Jean-Marc to downgrade to the stable version. The question on policy is, can a maintainer upgrade an ebuild to the latest EAPI while doing some other bugfixing without a version bump? My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg).
Re: [gentoo-dev] EAPI 2 is brokened :(
On Fri, 2008-10-10 at 00:55 +0100, Ciaran McCreesh wrote: On Thu, 9 Oct 2008 16:38:56 -0700 Brian Harring [EMAIL PROTECTED] wrote: Of that 308, number of ebuilds that either inherit java-utils (which adds src_prepare), define their own src_prepare, or even *match* default via grepping in the ebuild is 20. Of those, and those in overlays, and those that are going to be committed over the next few weeks, how many use src_prepare to apply security related patches? A round zero. Security patches are going stable soon after entering portage tree, and EAPI=2 ebuilds can not go stable yet, as there is no package manager supporting EAPI=2 that is going to be stable in the next week or two (so maintainers make sure they don't use EAPI=2 for security fix revisions). And if the bug is there and properly filed to the appropriate bugzilla, they wouldn't go stable before that bug is fixed (which I read are already fixed). I can not understand why this is dragged on. It was a bug, it is fixed. The sky is not falling and EAPI-2 is not broken - there was a bug in the implementation that is fixed. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 is brokened :(
On Thu, Oct 9, 2008 at 3:34 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Thu, 9 Oct 2008 15:22:19 -0700 Brian Harring [EMAIL PROTECTED] wrote: So where exactly is this sky is falling issue you're worried about? Bugs happen. It means anyone using EAPI 2 now is going to encounter severe breakages with Pkgcore. Simply put, all your Pkgcore users are going to get screwed over very messily as soon as they try to use any EAPI 2 things. Is this not something we should be caring about? I think everyone appreciates the forewarning (even if not everyone appreciates the manner in which it was delivered). I think we do care and we are fixing it. I believe the developers of said packages have a different idea of the risks involved than you and I don't expect everyone to agree on specific software development or release processes. Frankly you're overreacting on this- and that is assuming you *are* overreacting instead of just going for a bit of a public smear via bugs. Bah. If you want me to lecture you on how you're being blatantly irresponsible and incompetent then I will do, although by the way you rush on the defensive and start trying to cover your ass by throwing accusations at me it looks like you already know it. But what I care about is getting the mess fixed in the most painless way possible. This is a real issue and developers need to know the implications. If you want to call people names do it on your own lists. Either way, my vote is fix the bugs, leave EAPI2 as is, and in the future kindly file bugs properly (preferably w/out the noise, but I'll take usable bug reports in almost any form). If you want bug reports via trac instead of IRC, get your trac to respond faster. -- Ciaran McCreesh
Re: [gentoo-dev] EAPI 2 is brokened :(
On Fri, 10 Oct 2008 09:32:44 +0300 Mart Raudsepp [EMAIL PROTECTED] wrote: Of those, and those in overlays, and those that are going to be committed over the next few weeks, how many use src_prepare to apply security related patches? A round zero. Security patches are going stable soon after entering portage tree, and EAPI=2 ebuilds can not go stable yet, as there is no package manager supporting EAPI=2 that is going to be stable in the next week or two (so maintainers make sure they don't use EAPI=2 for security fix revisions). Oh really? So you're absolutely certain there aren't and won't soon be any EAPI 2 bumps of non-EAPI 2 versions that include security patches? And you're absolutely certain that there aren't, say, any packages that sed a broken chmod in a makefile in src_prepare? I can not understand why this is dragged on. It was a bug, it is fixed. The sky is not falling and EAPI-2 is not broken - there was a bug in the implementation that is fixed. The point of EAPI is to avoid these kinds of problems. The process is failing and the fallout needs to be handled. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] EAPI 2 is brokened :(
Unfortunately Portage and Pkgcore have broken EAPI 2 implementations. So far as I can see: Portage: * doesn't implement the 'default' function correctly for src_prepare. Pkgcore: * doesn't implement src_prepare * doesn't have a working default * default_src_configure and default_src_prepare are the only default_s that work Unfortunately, neither appears to have comprehensive unit tests covering all new EAPI 2 functionality, so these got through into package managers that made it into the tree. This is a bit of a mess. Possible solutions are: * Ignore it, and tell anyone using broken package managers to upgrade, and deal with the resulting mess. * Create a new EAPI 3 which is identical to EAPI 2. Make really really sure Portage and Pkgcore implement it correctly before they go into the tree. Deprecate EAPI 2, and convert everything using it to EAPI 3. * Avoid using any broken feature, and retroactively remove the definitions from EAPI 2. Unfortunately, this probably isn't viable because of the src_prepare thing in Pkgcore (were it merely an unusable 'default' we could get away with this). None of these are very nice. Better options would be encouraged... We have to do *something*, though, because this is hitting users already (see bug 240684 for one). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 2 is brokened :(
Ciaran McCreesh wrote: Unfortunately Portage and Pkgcore have broken EAPI 2 implementations. snip Ciaran, I would think at this point you know this since you've seen this brought up hundreds of times on this list. The mailing list is not an appropriate place to file bug reports. The proper place would be in http://bugs.gentoo.org for Portage and http://www.pkgcore.org for pkgcore.
Re: [gentoo-dev] EAPI 2 is brokened :(
On Thu, 09 Oct 2008 17:47:36 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Unfortunately Portage and Pkgcore have broken EAPI 2 implementations. snip Ciaran, I would think at this point you know this since you've seen this brought up hundreds of times on this list. The mailing list is not an appropriate place to file bug reports. The proper place would be in http://bugs.gentoo.org for Portage and http://www.pkgcore.org for pkgcore. Uh... The bugs have already been reported. This is supposed to be a discussion about how to handle the fallout -- what do you feel you gain by leaping to erroneous conclusions and making accusations? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 2 is brokened :(
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: Unfortunately Portage and Pkgcore have broken EAPI 2 implementations. So far as I can see: Portage: * doesn't implement the 'default' function correctly for src_prepare. This is fixed and released in sys-apps/portage-2.2_rc12. None of these are very nice. Better options would be encouraged... We have to do *something*, though, because this is hitting users already (see bug 240684 for one). Like I said in the council thread, I think you may be overreacting. No version of sys-apps/portage that supports EAPI 2 has been marked stable yet so the fact that some unstable versions were a little buggy is not a big problem since unstable users tend to upgrade relatively frequently and sys-apps/portage is promoted to the from of the merge list anyway. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjug2IACgkQ/ejvha5XGaOhFgCg6OhVpG5ZZjS00Z9GsU79JZUF aD8Aniy1cTFm3oXrQQ128cQJCfgS2Az/ =eTvZ -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI 2 is brokened :(
On Thu, Oct 09, 2008 at 10:53:13PM +0100, Ciaran McCreesh wrote: On Thu, 09 Oct 2008 17:47:36 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Unfortunately Portage and Pkgcore have broken EAPI 2 implementations. snip Ciaran, I would think at this point you know this since you've seen this brought up hundreds of times on this list. The mailing list is not an appropriate place to file bug reports. The proper place would be in http://bugs.gentoo.org for Portage and http://www.pkgcore.org for pkgcore. Uh... The bugs have already been reported. This is supposed to be a discussion about how to handle the fallout -- what do you feel you Interestingly enough, I don't see a bug filed in either of those ticket systems. I see an irc msg that's vague on details from you proceeding this email by an hour or so though. Pkgcore EAPI2 support was released ~2 days ago; portage EAPI2 support was released 09/26, ~12 days ago. So... not exactly a huge window. In addition, all *3* versions supporting EAPI2 are all unstable; meaning fairly rapid upgrade cycle by consumers of unstable, and not exactly likely to have versions lingering long term in peoples vdb. So where exactly is this sky is falling issue you're worried about? Bugs happen. I'd expect zac will fix whatever issue there is and knock out a release w/in next day or so. I know pkgcore will be fixed/released w/in next 12 (post work primarily). Frankly you're overreacting on this- and that is assuming you *are* overreacting instead of just going for a bit of a public smear via bugs. Either way, my vote is fix the bugs, leave EAPI2 as is, and in the future kindly file bugs properly (preferably w/out the noise, but I'll take usable bug reports in almost any form). I'd assume zac's opinion will be the same, although he obviously speaks for himself. ~brian pgpZsPPHHp2MF.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 2 is brokened :(
On Thu, 9 Oct 2008 15:22:19 -0700 Brian Harring [EMAIL PROTECTED] wrote: So where exactly is this sky is falling issue you're worried about? Bugs happen. It means anyone using EAPI 2 now is going to encounter severe breakages with Pkgcore. Simply put, all your Pkgcore users are going to get screwed over very messily as soon as they try to use any EAPI 2 things. Is this not something we should be caring about? Frankly you're overreacting on this- and that is assuming you *are* overreacting instead of just going for a bit of a public smear via bugs. Bah. If you want me to lecture you on how you're being blatantly irresponsible and incompetent then I will do, although by the way you rush on the defensive and start trying to cover your ass by throwing accusations at me it looks like you already know it. But what I care about is getting the mess fixed in the most painless way possible. This is a real issue and developers need to know the implications. Either way, my vote is fix the bugs, leave EAPI2 as is, and in the future kindly file bugs properly (preferably w/out the noise, but I'll take usable bug reports in almost any form). If you want bug reports via trac instead of IRC, get your trac to respond faster. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 2 is brokened :(
On Thu, Oct 09, 2008 at 11:34:59PM +0100, Ciaran McCreesh wrote: On Thu, 9 Oct 2008 15:22:19 -0700 Brian Harring [EMAIL PROTECTED] wrote: So where exactly is this sky is falling issue you're worried about? Bugs happen. It means anyone using EAPI 2 now is going to encounter severe breakages with Pkgcore. Simply put, all your Pkgcore users are going to get screwed over very messily as soon as they try to use any EAPI 2 things. Is this not something we should be caring about? You're massively overreacting, either due to ignorance or due to trying to stir things up. Tree currently has 308 ebuilds out of 25500 that are EAPI=2. ~1.1% of the tree. Of that 308, number of ebuilds that either inherit java-utils (which adds src_prepare), define their own src_prepare, or even *match* default via grepping in the ebuild is 20. I reiterate. 20 out of 308 EAPI2 consumers, meaning that pkgcore misbehaved on .078% of the tree (all unstable ebuilds in addition, and haven't even counted how many are masked), and it did this for a window of a few days. There is a difference between not caring about breakage, and gauging the affect of the breakage and dealing with it appropriately (triaging). Regardless, it's worth noting that 0.4.7.11 was cut, and commited to the tree (thank you zac) already fixing the issues you so kindly pointed out. So those 25 ebuilds pkgcore broke, are now addressed. Frankly I'd be amazed if anyone even spotted it yet (both portage and pkgcore) due to the minimal slice. Frankly you're overreacting on this- and that is assuming you *are* overreacting instead of just going for a bit of a public smear via bugs. Bah. If you want me to lecture you on how you're being blatantly irresponsible and incompetent then I will do, although by the way you rush on the defensive and start trying to cover your ass by throwing accusations at me it looks like you already know it. But what I care about is getting the mess fixed in the most painless way possible. s/painless/painful to targets/. And to be clear, just like the last time you reported bugs in pkgcore via ml, yes, there were bugs in EAPI2. No ass covering. Also, if you want to bitch at me and call me incompetent do it via your blog. No one this ml cares to watch us trade blows, let alone deal with personal BS that bleeds into your posts. This is a real issue and developers need to know the implications. Either way, my vote is fix the bugs, leave EAPI2 as is, and in the future kindly file bugs properly (preferably w/out the noise, but I'll take usable bug reports in almost any form). If you want bug reports via trac instead of IRC, get your trac to respond faster. Actually trac is responsive. Now if you work your way into the trac-bzr bits (source browsing), yeah, it's slower then I'd like (patches welcome of course). Regardless, bugs.gentoo.org exists; if it's EAPI related, I'd expect folks wouldn't mind if a pkgcore bug or two wound up there (it's not like it's a feature request for pkgcore after all). Frankly, the sky is not falling. A max of 20 freaking ebuilds misbehaving for pkgcore (20 for portage also) doesn't warrant mangling EAPI2 let alone going to the ml to stir up shit. In the future, kindly just file bugs. If upon investigation it is an issue, sure escalate it. Essentially focus on getting it straightened out instead of going for drama. ~brian pgpcds9KNzHPR.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 2 is brokened :(
On Thu, 9 Oct 2008 16:38:56 -0700 Brian Harring [EMAIL PROTECTED] wrote: Of that 308, number of ebuilds that either inherit java-utils (which adds src_prepare), define their own src_prepare, or even *match* default via grepping in the ebuild is 20. Of those, and those in overlays, and those that are going to be committed over the next few weeks, how many use src_prepare to apply security related patches? Also, if you want to bitch at me and call me incompetent do it via your blog. No one this ml cares to watch us trade blows, let alone deal with personal BS that bleeds into your posts. I'm not the one going around levelling personal attacks at everyone. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] EAPI-2 and src_configure in eclasses
How should exporting of src_configure in eclasses be handled? Should it be conditional, depending on the EAPI? Or is it O.K. to export src_configure unconditionally, since it doesn't harm for EAPI2? A concrete example is elisp.eclass which should export an empty elisp_src_configure function for EAPI=2. Ulrich
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 15:36:30 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: How should exporting of src_configure in eclasses be handled? Should it be conditional, depending on the EAPI? Or is it O.K. to export src_configure unconditionally, since it doesn't harm for EAPI2? Export it if and only if EAPI is 2. Note that this means EAPI really really has to be set as the first thing in the ebuild (*cough* or in the file extension). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 15:07:27 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sun, 5 Oct 2008 15:36:30 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: How should exporting of src_configure in eclasses be handled? Should it be conditional, depending on the EAPI? Or is it O.K. to export src_configure unconditionally, since it doesn't harm for EAPI2? Export it if and only if EAPI is 2. Note that this means EAPI really really has to be set as the first thing in the ebuild (*cough* or in the file extension). By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells has my eapi foo support but that sort of bites its tail that way. An eapi.eclass with such functions and lists of eapi features maintained there could help though. An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi would help too. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 16:15:46 +0200 Alexis Ballier [EMAIL PROTECTED] wrote: An eapi.eclass with such functions and lists of eapi features maintained there could help though. The problem is, 'features' change between EAPIs. For example, all three EAPIs have src_compile, but it does different things for all three. One can't assume that a feature working for current EAPIs will carry on working for future EAPIs, and even if it does there can be other interactions that break. An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi would help too. An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place checking for eclass screwups... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 15:24:20 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sun, 5 Oct 2008 16:15:46 +0200 Alexis Ballier [EMAIL PROTECTED] wrote: An eapi.eclass with such functions and lists of eapi features maintained there could help though. The problem is, 'features' change between EAPIs. For example, all three EAPIs have src_compile, but it does different things for all three. One can't assume that a feature working for current EAPIs will carry on working for future EAPIs, and even if it does there can be other interactions that break. Indeed; different names could be given to different implementations of the same thing, but that might completely kill the point of abstracting it. Maybe eclasses should die on unknown eapi; the fact is I really hate the current way it's done when switching an ebuild to EAPI-2 which uses an eclass that exports src_compile; most eclasses don't special case eapi-2 yet and we end up running econf twice at best. I fear that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll support src_configure too) An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi would help too. An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place checking for eclass screwups... yes; that's just a matter of choice though, but for eclasses it's probably not luxury. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 17:07:40 +0200 Alexis Ballier [EMAIL PROTECTED] wrote: Maybe eclasses should die on unknown eapi; the fact is I really hate the current way it's done when switching an ebuild to EAPI-2 which uses an eclass that exports src_compile; most eclasses don't special case eapi-2 yet and we end up running econf twice at best. I fear that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll support src_configure too) There's currently no mechanism for an ebuild or eclass to 'die' in global scope. It's something that could be available for future EAPIs without too much difficulty, though... We discussed this for Exherbo, and decided upon something like this: * Add a new metadata key called BROKENNESS. * Any ID with non-empty BROKENNESS is treated as being hard masked and not unmaskable by the user, in the same way than an unknown EAPI is. * Add a function which can only be called in global scope that adds an item to BROKENNESS. This does *not* prevent further sourcing. This one hopefully shouldn't be too hard to implement (Zac?). If people are running into excessive difficulties with eclasses, it might be worth doing an EAPI 3 quickly with just this addition... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008, Alexis Ballier wrote: Ciaran McCreesh [EMAIL PROTECTED] wrote: Export it if and only if EAPI is 2. By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells has my eapi foo support but that sort of bites its tail that way. Hm, what about: [ $(type -t src_configure) == function ] EXPORT_FUNCTIONS src_configure Or is this too fragile or trying to be too clever? Ulrich
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 17:38:11 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells has my eapi foo support but that sort of bites its tail that way. Hm, what about: [ $(type -t src_configure) == function ] EXPORT_FUNCTIONS src_configure Or is this too fragile or trying to be too clever? It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sun, 5 Oct 2008 17:07:40 +0200 Alexis Ballier [EMAIL PROTECTED] wrote: Maybe eclasses should die on unknown eapi; the fact is I really hate the current way it's done when switching an ebuild to EAPI-2 which uses an eclass that exports src_compile; most eclasses don't special case eapi-2 yet and we end up running econf twice at best. I fear that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll support src_configure too) There's currently no mechanism for an ebuild or eclass to 'die' in global scope. They can call 'die' in global scope. Perhaps it's not the nicest thing to do, but it can be done. It's something that could be available for future EAPIs without too much difficulty, though... We discussed this for Exherbo, and decided upon something like this: * Add a new metadata key called BROKENNESS. * Any ID with non-empty BROKENNESS is treated as being hard masked and not unmaskable by the user, in the same way than an unknown EAPI is. * Add a function which can only be called in global scope that adds an item to BROKENNESS. This does *not* prevent further sourcing. This one hopefully shouldn't be too hard to implement (Zac?). If people are running into excessive difficulties with eclasses, it might be worth doing an EAPI 3 quickly with just this addition... Considering that they can already call 'die' in global scope I don't see it as being that urgent. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjo9SsACgkQ/ejvha5XGaOUUQCfRSaJYF3xqWfaLVfE1M5lT0Fk NDcAnikfPOu/6nnBZIXuKbUXptNIPyOP =Lpc7 -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 05 Oct 2008 10:11:08 -0700 Zac Medico [EMAIL PROTECTED] wrote: They can call 'die' in global scope. Perhaps it's not the nicest thing to do, but it can be done. Last time I tried it, Portage behaved rather horribly with global scope dies. Is this still the case? Considering that they can already call 'die' in global scope I don't see it as being that urgent. If we're considering global scope die to be a usable solution, we need to start defining its behaviour and providing a way of tracking it in metadata. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sun, 05 Oct 2008 10:11:08 -0700 Zac Medico [EMAIL PROTECTED] wrote: They can call 'die' in global scope. Perhaps it's not the nicest thing to do, but it can be done. Last time I tried it, Portage behaved rather horribly with global scope dies. Is this still the case? In terms of dependency resolution, the current behavior is to report that the package is masked by corruption. Considering that they can already call 'die' in global scope I don't see it as being that urgent. If we're considering global scope die to be a usable solution, we need to start defining its behaviour and providing a way of tracking it in metadata. Sure, we can add some bells and whistles. But like I said before, I don't see it as being especially urgent. If an eclass uses 'die' as an assertion, it's not something that should be triggered under normal circumstances. It serves mostly a feedback mechanism which quickly informs the developer when they've made a mistake that needs to be corrected immediately. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjpIo0ACgkQ/ejvha5XGaOtrwCg4Q58XViLtI9/YNMz2hj6VX1k y2QAoIHGMLelGKmIyYDYmZNmg61z0LUj =iwn8 -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI-2
Ciaran McCreesh kirjoitti: On Sun, 14 Sep 2008 15:28:09 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: On 21:55 Sun 14 Sep , Ciaran McCreesh wrote: On Sun, 14 Sep 2008 23:51:11 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Hopefully someone formats it to a real GLEP before that. git clone git://git.overlays.gentoo.org/proj/pms.git git diff origin/master..origin/eapi-2 Ciaran, could you merge eapi-differences-summary into eapi-2 to address Petteri's concern about specifying EAPI differences in one place? Or just merge both of them into master. Alright, eapi-2 has the fancy table and eapi-differences-summary is gone. Yeah this will do. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI-2
Jan Kundrát wrote: Michael Hammer wrote: But for me it's still questionable why we don't have a gentoo project for this important task? You mean something like http://www.gentoo.org/proj/en/qa/pms.xml ? Cheers, -jkt This page is incomplete and needs some more details added to it. The Gentoo Council took this up at the last meeting on Sept 11th. and plan to some details posted to gentoo-dev in the coming weeks. However, I've been spearheading this a bit and I'm getting married this weekend and then I have my honeymoon so, except things to be almost at a stand still from me until October.
Re: [gentoo-dev] EAPI-2
On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote: ~ * The meaning of the !atom blocker syntax now implies that ~ temporary simultaneous installation of conflicting packages is ~ allowed [3]. ~ * A new !!atom blocker syntax is now supported, for use in special ~ cases in which temporary simultaneous installation of conflicting ~ packages should not be allowed. I didn't really look into the issues, intended to be resolved with this, but I'm somewhat suspecious that this is merely a hack around inaccurate dependency listing in ebuilds on the one side and Portage's dependency resolver issues on the other. What I do strongly oppose is changing the meaning of the '!' symbol, as blockers, which should remain real blockers will not be adjusted by us, when changing an ebuild to EAPI 2++ in every case, since we're humans after all. So, if you implement this, keep '!' as is and find another symbol for these soft blockers. ~ * A new src_prepare phase function is called after src_unpack. ~ * The old src_compile phase function is split into separate ~ src_configure and src_compile fuctions. All I do see is more complexity, but no real benefit. Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Lohrke wrote: On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote: ~ * The meaning of the !atom blocker syntax now implies that ~ temporary simultaneous installation of conflicting packages is ~ allowed [3]. ~ * A new !!atom blocker syntax is now supported, for use in special ~ cases in which temporary simultaneous installation of conflicting ~ packages should not be allowed. I didn't really look into the issues, intended to be resolved with this, but I'm somewhat suspecious that this is merely a hack around inaccurate dependency listing in ebuilds on the one side and Portage's dependency resolver issues on the other. Well, I'm open to alternative suggestions. Please see the previous email in which I've attempted to explain the reasoning for the given approach [1]. It seems to me that this approach is well suited for solving cases in which temporary simultaneous installation of blocking packages is needed. What I do strongly oppose is changing the meaning of the '!' symbol, as blockers, which should remain real blockers will not be adjusted by us, when changing an ebuild to EAPI 2++ in every case, since we're humans after all. So, if you implement this, keep '!' as is and find another symbol for these soft blockers. Again, please see my previous email on this subject [1]. The reason that I think we should change the meaning of the '!' symbol is that the majority of existing EAPI 0 or 1 blockers appear to fit the new meaning already. So, we'll only have to use the new !!atom syntax for special cases in which temporary simultaneous installation of blocking packages must be explicitly forbidden. ~ * A new src_prepare phase function is called after src_unpack. ~ * The old src_compile phase function is split into separate ~ src_configure and src_compile fuctions. All I do see is more complexity, but no real benefit. My impression is that most people tend to see these as useful extensions despite the slight increases in complexity. Carsten [1] http://archives.gentoo.org/gentoo-dev/msg_2551bea5c002093d5bacc26723208d93.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjNR5sACgkQ/ejvha5XGaPR0gCgkiG7H4HZ4ASh/SyLboFGTCix 50EAmwU6WWU3gx5GV+EU1NqRmY+s4fDb =rbQz -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI-2
On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote: Tobias Scherbaum wrote: Luca Barbato wrote: I don't see any problems with it. +1 Tobias +1 Since this latest version hasn't generated any noticeable disagreement, could the Council please formally vote on it at the next meeting?
Re: [gentoo-dev] EAPI-2
David Leverton kirjoitti: On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote: Tobias Scherbaum wrote: Luca Barbato wrote: I don't see any problems with it. +1 Tobias +1 Since this latest version hasn't generated any noticeable disagreement, could the Council please formally vote on it at the next meeting? Hopefully someone formats it to a real GLEP before that. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI-2
On Sun, 14 Sep 2008 23:51:11 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Hopefully someone formats it to a real GLEP before that. git clone git://git.overlays.gentoo.org/proj/pms.git git diff origin/master..origin/eapi-2 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
On Sonntag, 14. September 2008, Zac Medico wrote: Well, I'm open to alternative suggestions. Please see the previous email in which I've attempted to explain the reasoning for the given approach [1]. It seems to me that this approach is well suited for solving cases in which temporary simultaneous installation of blocking packages is needed. Thanks for pointing me to it, Zac. I do not pretend to be able to pull the white bunny out of the black hat, presenting you the perfect alternative, especially since you've thought about it a lot more than me. I just feel uncomfortable, having ebuilds overwrite each others files. According to the referenced data, it'll work around a number of issues. The time will show, If real hard blocker issues remain a problem, I guess. Again, please see my previous email on this subject [1]. The reason that I think we should change the meaning of the '!' symbol is that the majority of existing EAPI 0 or 1 blockers appear to fit the new meaning already. So, we'll only have to use the new !!atom syntax for special cases in which temporary simultaneous installation of blocking packages must be explicitly forbidden. Just the majority or pretty much all and the others are easily to find out and moved to EAPI 2, so the point I raised ceases to exist!? I want to share another thought regarding this proposed addtion: !! has the double meaning a) unmerge the following ebuilds later and b) overwriting files of the following ebuilds while merging changes makes them owned by the freshly merged ebuild so we have one symbol denoting two different commands, which could find use independently. Moreso, if we add more of these symbols to express something different, our syntax may look almost like Lisp in the end: use? ( ! ( X ( Y ( || ( ( foo bar ) baz ) ) ) ) ) ) Looks ugly, doesnt it? How about using two symbols for !! and having the possibility to aggreagate them, e.g. use? ( !XY||: ( ( foo bar ) baz ) ) instead?! Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI-2
On 21:55 Sun 14 Sep , Ciaran McCreesh wrote: On Sun, 14 Sep 2008 23:51:11 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Hopefully someone formats it to a real GLEP before that. git clone git://git.overlays.gentoo.org/proj/pms.git git diff origin/master..origin/eapi-2 Ciaran, could you merge eapi-differences-summary into eapi-2 to address Petteri's concern about specifying EAPI differences in one place? Or just merge both of them into master. It would also be extremely useful to have some way to discriminate the status of each EAPI (perhaps in the same appendix): approved, draft, or in progress. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgp2dusNrPP73.pgp Description: PGP signature
Re: [gentoo-dev] EAPI-2
Hi folks! I am not involved in creating the EAPI 2 draft but I am interested in the discussion and would like to track the technical evolution but this seams nearly impossible as you're not able to agree on a public draft document. * Ciaran McCreesh [EMAIL PROTECTED] [080911 20:02]: On Mon, 08 Sep 2008 23:34:28 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote: Given the earlier discussion about EAPI-2 in http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? I've prepared patches for PMS for this lot. They can be found on the branch 'eapi-2' at git://git.overlays.gentoo.org/proj/pms.git . Can we use these as the definitive definition? So my request to the council is not a technical decision on the content itself but at least a decision about which document is the official draft. So here are my suggestions: (which are an enhancement over the GLEP process) - An official (by the council accepted) VCS repo (a la git) for the document (EAPI draft or even the PMS spec?) - An interface (mailing address) where everyone interested can submit a patch for this document and a herd which is responsible for maintaining and merging the patches if accepted. (- we need a procedure especially for the accept of patches. Voting, council decision, herd decision) - A project page where the patches are published (and evtl. can be voted) and the HEAD is public readable - The technical discussion can then be made in mailing list but then every dev has a possibility to follow the technical issues in a concentrated way and we have a place where we can cite and ref to. - To make this work any other document or source for drafts has to be declined and not discussed (this seams hard but is IMHO the only way to make things work) So long and thx for all the fish, mueli p.S.: If I missed something and something I mentioned already exists then please correct me or forget my request but please be also so kind and publish in a documentation (perhaps somewhere at [1]) where to find informations on the EAPI process. [1] ... http://www.gentoo.org/doc/en/list.xml -- Michael Hammer|[EMAIL PROTECTED] | Graz, AT Geno's Developer (Kerberos) | http://www.michael-hammer.at LocalWords: Kerberos pgphDTBmqsuAe.pgp Description: PGP signature
Re: [gentoo-dev] EAPI-2
On Fri, 12 Sep 2008 08:28:52 +0200 Michael Hammer [EMAIL PROTECTED] wrote: - An official (by the council accepted) VCS repo (a la git) for the document (EAPI draft or even the PMS spec?) Uh, already exists. - An interface (mailing address) where everyone interested can submit a patch for this document and a herd which is responsible for maintaining and merging the patches if accepted. (- we need a procedure especially for the accept of patches. Voting, council decision, herd decision) Already exists. - A project page where the patches are published (and evtl. can be voted) and the HEAD is public readable Already exists. - The technical discussion can then be made in mailing list but then every dev has a possibility to follow the technical issues in a concentrated way and we have a place where we can cite and ref to. Already happens. p.S.: If I missed something and something I mentioned already exists then please correct me or forget my request but please be also so kind and publish in a documentation (perhaps somewhere at [1]) where to find informations on the EAPI process. How much research did you do before sending your email? Did you read EAPI and PMS for people who haven't been paying attention? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 9 Sep 2008 22:14:57 -0400 Jim Ramsay [EMAIL PROTECTED] wrote: I was personally expecting to see some sort of section called EAPI-1 that contains something like: EAPI-1 consists of EAPI-0 with the following features added... Have a look at the eapi-differences-summary branch on git://git.overlays.gentoo.org/proj/pms.git . Is that roughly what you're after? From what I could make out of the raw latex code, yes! Unrelated topic: What packages are actually required to 'make pms.pdf' so I can actually read it? I get: ! LaTeX Error: File `appendix.sty' not found. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
On Fri, 12 Sep 2008 14:14:51 -0400 Jim Ramsay [EMAIL PROTECTED] wrote: Unrelated topic: What packages are actually required to 'make pms.pdf' so I can actually read it? I get: Have a look at the dependencies for app-doc/pms. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
On Mon, 08 Sep 2008 23:34:28 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote: So we're talking about adding the following to EAPI-2: Are we treating PROPERTIES as purely optional and having no defined values for EAPI 2 then? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Mon, 08 Sep 2008 23:34:28 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote: So we're talking about adding the following to EAPI-2: Are we treating PROPERTIES as purely optional and having no defined values for EAPI 2 then? You are correct. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjJQ8EACgkQ/ejvha5XGaPIegCeIx6YqAgAU8rtCyL5ZRKgTcJ0 49oAn3vVIszYOlAuMAdUUlqgHhWJMSdk =0/4+ -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI-2
Luca Barbato wrote: Jorge Manuel B. S. Vicetto wrote: Hi again. Quoting Zac earlier in #gentoo-portage: 21:46 zmedico jmbsvicetto: I think we essentially have a spec already that people can agree on. just take my draft and subtract the eapi* functions and the gitweb unpack extension. I don't see any problems with it. +1 Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] EAPI-2
On Mon, 08 Sep 2008 23:34:28 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote: Given the earlier discussion about EAPI-2 in http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? I've prepared patches for PMS for this lot. They can be found on the branch 'eapi-2' at git://git.overlays.gentoo.org/proj/pms.git . Can we use these as the definitive definition? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
On Tue, 9 Sep 2008 22:14:57 -0400 Jim Ramsay [EMAIL PROTECTED] wrote: I was personally expecting to see some sort of section called EAPI-1 that contains something like: EAPI-1 consists of EAPI-0 with the following features added... Have a look at the eapi-differences-summary branch on git://git.overlays.gentoo.org/proj/pms.git . Is that roughly what you're after? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
Tobias Scherbaum wrote: Luca Barbato wrote: Jorge Manuel B. S. Vicetto wrote: Hi again. Quoting Zac earlier in #gentoo-portage: 21:46 zmedico jmbsvicetto: I think we essentially have a spec already that people can agree on. just take my draft and subtract the eapi* functions and the gitweb unpack extension. I don't see any problems with it. +1 Tobias +1
Re: [gentoo-dev] EAPI-2
On Tue, 9 Sep 2008 22:14:57 -0400 Jim Ramsay [EMAIL PROTECTED] wrote: What about the PMS EAPI 1 documentation do you consider 'not proper'? I was personally expecting to see some sort of section called EAPI-1 that contains something like: EAPI-1 consists of EAPI-0 with the following features added... Then an explanation of each change and the appropriate syntax. I did see how EAPI-1 is integrated throughout the document, which is valuable in a different way - but it's harder to answer the question What exactly does EAPI-1 add to EAPI-0? The way it is now is valuable to package manage people, since they need to know things like my parser must be able to do foo, bar and baz, not my parser must be able to do foo and then hidden away later the parser must also do bar and baz for EAPI 1. Perhaps I'll try sending you a patch with something like that, if I have time, and if it would be appreciated. We've discussed having a purely informative appendix with a summary of changes between EAPIs, and references to all the relevant sections. But no-one's ever wanted it enough to submit a patch... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
Ciaran McCreesh kirjoitti: On Tue, 09 Sep 2008 16:31:08 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Jorge Manuel B. S. Vicetto kirjoitti: and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? I won't approve it for use in the tree before it's written as a GLEP in order to avoid the fiasco with EAPI 1 (it's still not documented properly). I can however approve the list of items. What about the PMS EAPI 1 documentation do you consider 'not proper'? I am talking as in it's not documented anywhere readily available in *.gentoo.org. Everything in current PMS git is probably documented. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: Ciaran McCreesh kirjoitti: On Tue, 09 Sep 2008 16:31:08 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Jorge Manuel B. S. Vicetto kirjoitti: and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? I won't approve it for use in the tree before it's written as a GLEP in order to avoid the fiasco with EAPI 1 (it's still not documented properly). I can however approve the list of items. What about the PMS EAPI 1 documentation do you consider 'not proper'? I am talking as in it's not documented anywhere readily available in *.gentoo.org. Everything in current PMS git is probably documented. Regards, Petteri Are you saying that the docs in my dev space don't count? http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-1 - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjIIZ0ACgkQ/ejvha5XGaO+lQCdER+OYtthh1jwq4dECeRZyU1M gb8An3LjpxhUKj+9URGLCgmzfBsJXHpU =Y36b -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: Zac Medico kirjoitti: Petteri Räty wrote: Are you saying that the docs in my dev space don't count? http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-1 They don't have any official status as far as I know. Fair enough. Anyway, they are available for consideration. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjITKgACgkQ/ejvha5XGaO2KACdEq+y6Aoxk4AwVdWsrAHY9nK4 GWEAniiLjimhiOF2BZCXo8UVpBpCQcik =0VoB -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI-2
On Tue, 09 Sep 2008 16:31:08 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Jorge Manuel B. S. Vicetto kirjoitti: and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? I won't approve it for use in the tree before it's written as a GLEP in order to avoid the fiasco with EAPI 1 (it's still not documented properly). I can however approve the list of items. What about the PMS EAPI 1 documentation do you consider 'not proper'? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
Jorge Manuel B. S. Vicetto kirjoitti: and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? I won't approve it for use in the tree before it's written as a GLEP in order to avoid the fiasco with EAPI 1 (it's still not documented properly). I can however approve the list of items. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI-2 do* functions die
В Пнд, 08/09/2008 в 23:34 +, Jorge Manuel B. S. Vicetto пишет:
So we're talking about adding the following to EAPI-2:
While it's not too late. Can we make dobin, doman and other do*
functions finally die in EAPI=2? I've reviewed discussions on -dev
[1],[2] and bug 138792 [3] and seems that the only possible stopper is
that implementing them as functions makes impossible to use them with
xargs. Maybe for such rather rare case we should create new functions
(xdo{bin,*} or whatever name is better)?
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/40437
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/56443
[3] bugs.gentoo.org/138792
--
Peter.
Re: [gentoo-dev] EAPI-2 do* functions die
On Tue, 09 Sep 2008 20:45:52 +0400
Peter Volkov [EMAIL PROTECTED] wrote:
В Пнд, 08/09/2008 в 23:34 +, Jorge Manuel B. S. Vicetto пишет:
So we're talking about adding the following to EAPI-2:
While it's not too late. Can we make dobin, doman and other do*
functions finally die in EAPI=2? I've reviewed discussions on -dev
[1],[2] and bug 138792 [3] and seems that the only possible stopper is
that implementing them as functions makes impossible to use them with
xargs. Maybe for such rather rare case we should create new functions
(xdo{bin,*} or whatever name is better)?
I'd suggest holding off on that one. There're at least three different
ways of implementing it, all with different implications, and it needs
proper discussion.
* Using traps looks nice on the surface, but in practice they're
sufficiently weird on things like conditionals that they're probably not
a useful solution.
* Banning xargs and doing them as functions is a possibility, but far
from ideal, especially since it's just working around a Portage
limitation.
* Making Portage support subprocess dies is the nice solution, but this
probably isn't an EAPI 2 timeframe feature.
In addition, having nonfatal versions of commands is also useful in
practice. Exheres has a 'nonfatal' command, so you can do 'nonfatal
dodoc foo bar baz'. This also needs discussing before deciding upon a
spec.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] EAPI-2
Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 09 Sep 2008 16:31:08 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Jorge Manuel B. S. Vicetto kirjoitti: and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? I won't approve it for use in the tree before it's written as a GLEP in order to avoid the fiasco with EAPI 1 (it's still not documented properly). I can however approve the list of items. What about the PMS EAPI 1 documentation do you consider 'not proper'? I was personally expecting to see some sort of section called EAPI-1 that contains something like: EAPI-1 consists of EAPI-0 with the following features added... Then an explanation of each change and the appropriate syntax. I did see how EAPI-1 is integrated throughout the document, which is valuable in a different way - but it's harder to answer the question What exactly does EAPI-1 add to EAPI-0? Perhaps I'll try sending you a patch with something like that, if I have time, and if it would be appreciated. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
[gentoo-dev] EAPI-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again. Quoting Zac earlier in #gentoo-portage: 21:46 zmedico jmbsvicetto: I think we essentially have a spec already that people can agree on. just take my draft and subtract the eapi* functions and the gitweb unpack extension. So we're talking about adding the following to EAPI-2: ~ * The 'doman' helper function recognizes language codes in man page ~ source files, and uses them to generate an appropriate ~ installation path. ~ * The meaning of the !atom blocker syntax now implies that ~ temporary simultaneous installation of conflicting packages is ~ allowed [3]. ~ * A new !!atom blocker syntax is now supported, for use in special ~ cases in which temporary simultaneous installation of conflicting ~ packages should not be allowed. ~ * Dependency atoms can be constrained to match specific USE flag ~ states, including USE conditional expressions embedded within ~ the atoms themselves. ~ * SRC_URI supports a syntax extension which allows customization ~ of output file names by using a - operator. ~ * A new src_prepare phase function is called after src_unpack. ~ * The old src_compile phase function is split into separate ~ src_configure and src_compile fuctions. ~ * Default phase function implementations for the current EAPI are ~ accessible via a function having a name that begins with default_ ~ and ends with the respective phase function name. ~ * The default phase function implementation for the currently ~ executing phase is accessible as a function named 'default'. Given the earlier discussion about EAPI-2 in http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjFtoQACgkQcAWygvVEyALQigCePXcGlT5m6JGB2OlB5swY6f4F /yIAnRte3mm5PULg73j5KDrnKHSFB5h6 =lW1u -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI-2
Jorge Manuel B. S. Vicetto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again. Quoting Zac earlier in #gentoo-portage: 21:46 zmedico jmbsvicetto: I think we essentially have a spec already that people can agree on. just take my draft and subtract the eapi* functions and the gitweb unpack extension. So we're talking about adding the following to EAPI-2: ~ * The 'doman' helper function recognizes language codes in man page ~ source files, and uses them to generate an appropriate ~ installation path. ~ * The meaning of the !atom blocker syntax now implies that ~ temporary simultaneous installation of conflicting packages is ~ allowed [3]. ~ * A new !!atom blocker syntax is now supported, for use in special ~ cases in which temporary simultaneous installation of conflicting ~ packages should not be allowed. ~ * Dependency atoms can be constrained to match specific USE flag ~ states, including USE conditional expressions embedded within ~ the atoms themselves. ~ * SRC_URI supports a syntax extension which allows customization ~ of output file names by using a - operator. ~ * A new src_prepare phase function is called after src_unpack. ~ * The old src_compile phase function is split into separate ~ src_configure and src_compile fuctions. ~ * Default phase function implementations for the current EAPI are ~ accessible via a function having a name that begins with default_ ~ and ends with the respective phase function name. ~ * The default phase function implementation for the currently ~ executing phase is accessible as a function named 'default'. Given the earlier discussion about EAPI-2 in http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjFtoQACgkQcAWygvVEyALQigCePXcGlT5m6JGB2OlB5swY6f4F /yIAnRte3mm5PULg73j5KDrnKHSFB5h6 =lW1u -END PGP SIGNATURE- That removes the only two sections that appeared to have any chatter on them. Anyone involved in PMS or other package managers have any input on this? No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.19/1660 - Release Date: 9/8/2008 6:39 PM
Re: [gentoo-dev] EAPI-2 - Let's get it started
В Срд, 11/06/2008 в 07:53 +0200, Luca Barbato пишет: Getting the build time from 30minutes to an hour or more? Actually I don't understand this concern. If you bother about time tests take don't build package from sources - use binary packages. If you build program by yourself - run testsuite to be sure it was built correctly in your environment... -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 07:53:21 +0200 Luca Barbato [EMAIL PROTECTED] wrote: A whole bunch of science packages have upstreams that say If you're building from source, run 'make check' and if it fails don't carry on. Their rationale behind that is that their code is severely broken, using experimental features from their language of choice or, simply, that they are paranoid and couldn't think better ways to annoy people? Their rationale being that compilers and users screw up, and that detecting a failure before deployment is important for people who care about what programs do. Simple example... Take people who use Roy's broken patches from bug 192403. If you build a program that uses C++ exception handling using such a compiler, it'll compile just fine and then do very weird things at runtime. Test suites catch this, and spare a lot of everyone's time. For that matter, I'm strongly inclined to say that for Paludis too... Getting the build time from 30minutes to an hour or more? And saving your ass when you're using a broken compiler that generates broken code that would force you to reinstall a working compiler by hand when the package manager gets h0rked. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 07:58:44 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Oh, so Gentoo has decided that basic QA is another 'poor programming practice' now? Having a good testsuite is part of the QA, having it not failing is part of the QA, running it for supposedly tested code (thus having those test passed already) every time isn't. You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Tue, 10 Jun 2008 17:11:23 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote: On Tue, Jun 10, 2008 at 17:39, Doug Goldstein [EMAIL PROTECTED] wrote: At this point, we should really only discuss features that all 3 package managers have implemented. I'm not sure that's a good idea, only two have implemented EAPI 1 so far. 3 have. If you're aware of a pkgcore issue, then kindly file a bug rather then going for mocking on -dev. Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. http://www.pkgcore.org/trac/pkgcore/newticket lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:01:30 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Wed, 11 Jun 2008 07:49:44 +0200 Alexis Ballier [EMAIL PROTECTED] wrote: I thought tests were already supposed to pass whatever the EAPI is and devs were supposed to run them... Supposedly. But in practice this isn't true, because far too many developers just don't care. and having it forced in the eapi won't change this. Sure it will. They won't be able to install their package without either passing src_test or restricting it. Developers *do* try to install things before committing, right? Enforcing src_test in a you must explicitly say so if your package's test suites are expected to fail way on an EAPI bump is a clean way of recovering from this. You are assuming that every package has a test (false), nobody will have src_test dummified. Not at all. If upstream has no test suite, or developers choose to RESTRICT off test, it just means there's less QA being done for that package. But more importantly, it still means that people *know* that a failing src_test is to be investigated. Currently they instead have to guess whether it's a lazy developer issue or a genuine bug being shown. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:02:48 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. http://www.pkgcore.org/trac/pkgcore/newticket http://www.pkgcore.org/trac/pkgcore/ticket/197 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Wed, 11 Jun 2008 07:53:21 +0200 Luca Barbato [EMAIL PROTECTED] wrote: A whole bunch of science packages have upstreams that say If you're building from source, run 'make check' and if it fails don't carry on. Their rationale behind that is that their code is severely broken, using experimental features from their language of choice or, simply, that they are paranoid and couldn't think better ways to annoy people? Their rationale being that compilers and users screw up, and that detecting a failure before deployment is important for people who care about what programs do. Simple example... Take people who use Roy's broken patches from bug 192403. If you build a program that uses C++ exception handling using such a compiler, it'll compile just fine and then do very weird things at runtime. Test suites catch this, and spare a lot of everyone's time. You are supposed to test proposed patches for opened bugs before deploying them in any way. Your example, that btw is a quite low try to smear Roy, proves nothing. And saving your ass when you're using a broken compiler that generates broken code that would force you to reinstall a working compiler by hand when the package manager gets h0rked. You (upstream) are supposed to test and early users are supposed to check their bleeding edge stuff is working if they care enough. People using released programs that are in stable shouldn't have to do that. If your code doesn't survive a gcc release usually it's the code being wrong most of the times. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:50:47 +0200 Luca Barbato [EMAIL PROTECTED] wrote: And saving your ass when you're using a broken compiler that generates broken code that would force you to reinstall a working compiler by hand when the package manager gets h0rked. You (upstream) are supposed to test and early users are supposed to check their bleeding edge stuff is working if they care enough. People using released programs that are in stable shouldn't have to do that. If everyone running stable used the same base system, tool chain and configuration you would be right. But every Gentoo system is different, so there's no common target to test on. And it's fairly well established that lots stable Gentoo users have broken toolchains... If your code doesn't survive a gcc release usually it's the code being wrong most of the times. If you have bad code, yes. If you have good code, instead it's usually gcc's fault. Things like gcc bug 31899 are common enough to be a nuisance. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:55:16 +0200 Luca Barbato [EMAIL PROTECTED] wrote: But more importantly, it still means that people *know* that a failing src_test is to be investigated. Currently they instead have to guess whether it's a lazy developer issue or a genuine bug being shown. Not really. Ok, if EAPI 2 turns on src_test except where explicitly overridden by the ebuild, explain how EAPI 2 src_test failures are meaningless in the same way that EAPI 0/1 src_test failures are. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:57:35 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. if your code sucks isn't our fault. - gcc upstream And those all too common cases where the code is correct and gcc gets it wrong? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: Sure it will. They won't be able to install their package without either passing src_test or restricting it. Developers *do* try to install things before committing, right? No, they also write the ebuilds using cat /dev/urandom through a perl regexp. But more importantly, it still means that people *know* that a failing src_test is to be investigated. Currently they instead have to guess whether it's a lazy developer issue or a genuine bug being shown. Not really. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Wed, 11 Jun 2008 08:57:35 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. if your code sucks isn't our fault. - gcc upstream And those all too common cases where the code is correct and gcc gets it wrong? Get fixed. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 09:14:03 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Wed, 11 Jun 2008 08:57:35 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. if your code sucks isn't our fault. - gcc upstream And those all too common cases where the code is correct and gcc gets it wrong? Get fixed. And all those people running gcc versions that haven't had the fix applied yet? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: Ok, if EAPI 2 turns on src_test except where explicitly overridden by the ebuild, explain how EAPI 2 src_test failures are meaningless in the same way that EAPI 0/1 src_test failures are. Test failures aren't meaningless right now. Applications with good test suites got them used by the people that cares already. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 09:18:07 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Ok, if EAPI 2 turns on src_test except where explicitly overridden by the ebuild, explain how EAPI 2 src_test failures are meaningless in the same way that EAPI 0/1 src_test failures are. Test failures aren't meaningless right now. Applications with good test suites got them used by the people that cares already. The point you've been missing this whole time: If, as a user or an arch person, I get a src_test failure right now, I don't know whether this means eek! Something's gone wrong, and I really need to fix this or oh, whoever maintains this package doesn't care. But with EAPI 2, I'll be able to know that a src_test failure really does mean something's wrong. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, Jun 11, 2008 at 08:18, Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Ok, if EAPI 2 turns on src_test except where explicitly overridden by the ebuild, explain how EAPI 2 src_test failures are meaningless in the same way that EAPI 0/1 src_test failures are. Test failures aren't meaningless right now. Applications with good test suites got them used by the people that cares already. If you care about tests now, how do you know if foo.ebuild failed its src_test because there's a problem or if src_test failed because no one else has ever run it with test in FEATURES? Also, I think you seem to be suggesting that gentoo is so well tested that once something's marked stable, there's no point in testing it. -- Richard Brown -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On 00:11 Wed 11 Jun , Bo Ørsted Andresen wrote: I would like the portage devs to comment upon which of the following features they think could easily be implemented before portage 2.2 goes stable. These ones meet the criteria of I know people are working around them because they don't exist yet, and it's annoying and extra work: - Use dependencies, it's not clear to me whether we all agree entirely upon the syntax yet though (bugs #2272 and #174406) - Custom output names in SRC_URI, also called arrows (bug #177863) - Limit values in $USE (bug #176467) - GLEP 42 - news items - maint_*, it's not clear to me if this has been fleshed out in sufficient detail yet (bug #185567) - default_*, allows an ebuild to redefine phases to add more functionality and then call default_$phase. Currently the default phases are lost when redefining the phases. - default for src_install (bug #33544) - Ranged dependencies (bug #4315) Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, Jun 11, 2008 at 7:53 AM, Luca Barbato [EMAIL PROTECTED] wrote: A whole bunch of science packages have upstreams that say If you're building from source, run 'make check' and if it fails don't carry on. Their rationale behind that is that their code is severely broken, using experimental features from their language of choice or, simply, that they are paranoid and couldn't think better ways to annoy people? It's not as simple as that. A package may fail tests because compiler bugs, build environment misconfiguration, problems in a library which is being used, a setup problem or, of course, a bug in the package which shows up in rare cases and haven't been spoted by upstream yet. When the package can be critical for the system, upgrading to a buggy version will eat people's dogs. I feel a bit safer when I run the test phase for my package manager, and I wouldn't install it if it's failing any test. I don't think that's too paranoid. Also let's put a real example: gmplib. From www.gmplib.org on the front page: IMPORTANT INFORMATION FOR ALL GMP USERS: GMP is very often miscompiled! We are seeing ever increasing problems with miscompilations of the GMP code. It has now come to the point where a compiler should be assumed to miscompile GMP. Please never use your newly compiled libgmp.a or libgmp.so without first running make check. If it doesn't complete without errors, don't trust the library. Please try another compiler release, or change optimization flags until it works. If you have the skill to isolate the problem, please report it to us if it is a GMP bug; else to the compiler vendor. (The compilers that cause problems are HP's unbundled compilers and GCC, in particular Apple's GCC releases.) Upstream clearly states that a gmp build which tests have failed shouldn't be used. I bet they deny support for users who fail to follow that indication ;-) Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Wed, 11 Jun 2008 08:02:48 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. http://www.pkgcore.org/trac/pkgcore/newticket http://www.pkgcore.org/trac/pkgcore/ticket/197 Uh - what is the goal on this list - to make Gentoo a better distribution or to point out that the package manager that I maintain is better than the package manager that you maintain? Gentoo is served by having lots of package managers that all work well. If somebody knows of a bug and intentionally doesn't report it, they're being rather selfish. That's like posting ha, ha - I found a zero-day exploit in apache and if you were as elite as me you'd have found it in your testing! There is an old adage - if you're not part of the solution you're part of the problem. And if you don't want to be part of the solution, then why are you wasting your time here? I'm a big fan of PMS/paludis/etc in general, but why waste your time contributing these things to Gentoo if you don't want Gentoo to succeed? If you do want Gentoo to succeed, then why not give others a helping hand when it costs you virtually nothing to do so? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 06:55:45 -0400 Richard Freeman [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Wed, 11 Jun 2008 08:02:48 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. http://www.pkgcore.org/trac/pkgcore/newticket http://www.pkgcore.org/trac/pkgcore/ticket/197 Uh - what is the goal on this list - to make Gentoo a better distribution or to point out that the package manager that I maintain is better than the package manager that you maintain? The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. And if you don't want to be part of the solution, then why are you wasting your time here? I'm a big fan of PMS/paludis/etc in general, but why waste your time contributing these things to Gentoo if you don't want Gentoo to succeed? If you do want Gentoo to succeed, then why not give others a helping hand when it costs you virtually nothing to do so? Give a man a bug report and he fixes one bug. Persuade a man to write basic unit tests and he fixes a whole load of bugs and catches a whole load more in the future before shipping them out. And then you give him bug reports for what that doesn't catch. The problem is, the pkgcore people are being blatantly irresponsible by sticking a package manager that claims to support EAPI 1 in the tree without actually supporting EAPI 1. In particular, it means we'll have to decide whether to avoid using some EAPI 1 features just to avoid breaking people using older pkgcore versions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, Jun 11, 2008 at 08:23:59AM +0100, Richard Brown wrote: Also, I think you seem to be suggesting that gentoo is so well tested that once something's marked stable, there's no point in testing it. A very good point. Just last week the *stable* perl cairo bindings were broken by a x11-libs/cairo bump. We caught this however and noticed that the new perl cairo bindings worked. Those were then stabilized at the same time and users now have a working cairo. What would have happened if that hadn't happened? Any package that depended on dev-perl/Cairo would've been broken. The lesson to learn is that once something is stable doesn't mean it's always stable. If a user finds out that way and files a bug, chances are greater that he'll get a dev-perl/Cairo that works with the new cairo version soon, rather than a dev-perl/Cairo version that breaks immediately. What would you rather have? pgpbdD6ZaLPYT.pgp Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Santiago M. Mola wrote: It's not as simple as that. A package may fail tests because compiler bugs, build environment misconfiguration, problems in a library which is being used, a setup problem or, of course, a bug in the package which shows up in rare cases and haven't been spotted by upstream yet. May happen indeed. When the package can be critical for the system, upgrading to a buggy version will eat people's dogs. I feel a bit safer when I run the test phase for my package manager, and I wouldn't install it if it's failing any test. I don't think that's too paranoid. The main point is that it could be overly bothersome, if you depend on certain applications you won't just use the standard testsuite but also run your batch of compliance checks, but that isn't common. Upstream clearly states that a gmp build which tests have failed shouldn't be used. I bet they deny support for users who fail to follow that indication ;-) gmp isn't a key component if you aren't using math/sci applications using it. You may point openssl as something you may want to have a round of checks before is too late, same for openssh. Still there are people perfectly happy w/out those since they do not use those packages that for me and possibly many other are vital. I won't be happy to have gcc have its batch of tests run, just to see later it fails on ffmpeg because the tests do not catch those conditions, I have better way to break gcc than those you have in the regression test =/ Changing the default features would just at best have people that do not care switch to -test, people that care already about that won't be affected and just create an annoyance. Putting it in an eapi makes not much sense as well since you may change the defaults as you wish since they aren't causing incompatibilities. To sum up: - having the test feature on by default isn't good for anybody but paranoids and lazy developers, paranoids have that already on, lazy developers will switch it off for them and let people do the automated test for them. - having that mandated by the eapi doesn't have sense since it doesn't change anything by itself. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? Talking away problems, now that is a way to handle QA. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? No, it's just unsubstantiated rumors. As such they are irrelevant until some kind of proof is shown. Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? It is too generic and doesn't even describe the class of bug. By the same rationale portage and paludis have multiple bugs ... Talking away problems, now that is a way to handle QA. So, could anyone just actually mention what the problem is, or is the hivemind not able to express such a simple thing? Just think of the thousands of emails, being read by hundreds of readers, that have cost so much time ... in that time you could have written a patch and a bugreport. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 14:49:19 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. EAPI 1 is entirely specified in terms of a diff against EAPI 0. Checking every part that's changed before releasing an EAPI 1 package manager is the least any responsible person would do. That they would release a version without doing such basic tests shows you just how much they care about Gentoo... Assuming that Ciaranm isn't just lying knowingly it's just plainly rude, otherwise it is pure malice. What, asking the pkgcore people to test their code before releasing a version that claims to support EAPI 1 but actually doesn't, forcing people to avoid using some of EAPI 1 to avoid breaking pkgcore, is malice? The whole EAPI lets us do upgrades cleanly process is broken when people release a package manager that claims to support a certain EAPI but doesn't. If pkgcore had any actual users we'd have to consider banning EAPI 1 in the tree and releasing EAPI 2 as being identical to EAPI 1 just to work around this. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Patrick Lauer schrieb: Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? No, it's just unsubstantiated rumors. As such they are irrelevant until some kind of proof is shown. It might be, but it might also be a bug. Of course the maintainers can choose if they go after it. BTW: The Paludis maintainers did have a look at the security hole you pointed out, even though everyone knows, that you spread lies about Paludis... Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? It is too generic and doesn't even describe the class of bug. By the same rationale portage and paludis have multiple bugs ... It is indeed generic, but then you should test every part of EAPI. The main point was, that test are missing and the fact, that there is might be a bug, that they didn't catch yet is a follow up. Of course, filing a bug report for a single issue might get that issue fixed, but what caused this issue to be still there (missing tests) will still be there. Talking away problems, now that is a way to handle QA. So, could anyone just actually mention what the problem is, or is the hivemind not able to express such a simple thing? Just think of the thousands of emails, being read by hundreds of readers, that have cost so much time ... in that time you could have written a patch and a bugreport. Again, one patch and one bug report wouldn't wipe out the problem in the long term view. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: EAPI 1 is entirely specified in terms of a diff against EAPI 0. That doesn't have a complete definition by itself. Checking every part that's changed before releasing an EAPI 1 package manager is the least any responsible person would do. That they would release a version without doing such basic tests shows you just how much they care about Gentoo... Again smearing without substance. Assuming that Ciaranm isn't just lying knowingly it's just plainly rude, otherwise it is pure malice. What, asking the pkgcore people to test their code before releasing a version that claims to support EAPI 1 but actually doesn't, forcing people to avoid using some of EAPI 1 to avoid breaking pkgcore, is malice? Saying that w/out giving any substance? Sure! The whole EAPI lets us do upgrades cleanly process is broken when people release a package manager that claims to support a certain EAPI but doesn't. If pkgcore had any actual users we'd have to consider banning EAPI 1 in the tree and releasing EAPI 2 as being identical to EAPI 1 just to work around this. Apparently those users do not see the problem, you do, help those blind people. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Luca Barbato schrieb: Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? He doesn't point any issue in particular. And that wasn't the point. He pointed out, that there is an issue, that hasn't been caught because of missing tests. Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. It really doesn't matter how it is specified. You have an implementation of it and should make sure, that this implementation works. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, Jun 11, 2008 at 02:00:19PM +0100, Ciaran McCreesh wrote: On Wed, 11 Jun 2008 14:49:19 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. EAPI 1 is entirely specified in terms of a diff against EAPI 0. Checking every part that's changed before releasing an EAPI 1 package manager is the least any responsible person would do. That they would release a version without doing such basic tests shows you just how much they care about Gentoo... Assuming that Ciaranm isn't just lying knowingly it's just plainly rude, otherwise it is pure malice. What, asking the pkgcore people to test their code before releasing a version that claims to support EAPI 1 but actually doesn't, forcing people to avoid using some of EAPI 1 to avoid breaking pkgcore, is malice? The whole EAPI lets us do upgrades cleanly process is broken when people release a package manager that claims to support a certain EAPI but doesn't. If pkgcore had any actual users we'd have to consider banning EAPI 1 in the tree and releasing EAPI 2 as being identical to EAPI 1 just to work around this. Ya know ciaran, I've just got to point out that you spend quite a large amount of time talking about pkgcore. Literaly- you talk about it more then I do. I could point out how paludis (or portage) has picked up the misc functionality pkgcore (then known as saviour, or ebd) established 4 years back, but hey, I'm not petty like you. Generators aren't at all like the basic repository concept, no sir. But you know that, of course, and of course you've got nothing to worry about from pkgcore, no sir. Alternatively, I'll take your tack- eapi1 actually isn't supported by paludis. Ask me what bug, please, trust me I'll make it entertaining for the gentoo-dev readers. ~harring pgpUGXDUUerqT.pgp Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? He doesn't point any issue in particular. Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. Assuming that Ciaranm isn't just lying knowingly it's just plainly rude, otherwise it is pure malice. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
