Re: [gentoo-dev] combining x86 and amd64
On Friday 02 September 2005 06:28, Lance Albertson wrote: Grant Goodyear wrote: Christian Parpart wrote: [Thu Sep 01 2005, 05:45:43PM CDT] This just leads me to assume you're not really a coder (wrt native programming languages like C/C++), are you? *Grin* This sort of condescending attitude is rarely wise when it comes to dealing with Gentoo devs. Not only does it tend to annoy people (yes, I'm a tad annoyed by the presumption), but since you're still relatively new here the odds are that people know the person you're being condescending to better than they know you, and thus it just makes you look bad if you're wrong. Feel free to ask people what I do for a living, and whether they suspect that I know the difference between a 64-bit pointer and a 32-bit int. Ha! Yeah ... kids these days... just don't respect their elders like they should ;-). I have seen more and more 'newish' devs speaking their minds like this without even knowing/asking the person. I guess respect and tactfulness isn't being taught anymore... And yes, Grant definitely knows the difference :-) Maybe I do not understand the diffference between I assume and I know, and I know I meant the first, however, in that case, Grant, I do not know why you're requesting this combine when you know about these issues already. Don't get me wrong, I am (though, I was) just curious, and really surprised how the hell ppl (telling to be coders) can even think about such merges. It might - of course - *somehow* still be possible, but I just do not believe in, as I posted earlier (by example). And just like kintaco said, there're not only ppl outside that do know why those archs are different, there're also ppl outside that even make use of such things on *their* main arch (x86) and do not care (or did) about 64bit compats, in fact, most do not know that this piece of could would lead into semantic errors on such archs anyway. As said, don't get me wrong, I'm neither new (depends on definition!) nor am I missing respect. I was just sharing some by-example snippets why this is a bad idea, and I was just assuming (not know) why I said what I said. Regards, Christian Parpart. pgp0pZlV2YJFY.pgp Description: PGP signature
[gentoo-dev] Test message. Please ignore.
sorry, this is just test, please ignore. -- Sergey Kuleshov[EMAIL PROTECTED] Home Page: http://svyatogor.gnns.net Jabber: [EMAIL PROTECTED] ICQ: 158439855 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] 2005.1 profile gives devfs as virtual
Having gone over to Udev, I went to unmerge Devfs got a big red warning. It appears that the 2005.1 profile gives Devfs as a virtual: is this an oversight or is there a reason behind it ? I would have assumed that Udev would now be the required device manager. /usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals : virtual/dev-manager sys-fs/devfsd -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2005.1 profile gives devfs as virtual
Philip Webb wrote: Having gone over to Udev, I went to unmerge Devfs got a big red warning. It appears that the 2005.1 profile gives Devfs as a virtual: is this an oversight or is there a reason behind it ? I would have assumed that Udev would now be the required device manager. /usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals : virtual/dev-manager sys-fs/devfsd That is because udev doesn't work with a 2.4 kernel. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2005.1 profile gives devfs as virtual
Philip Webb schrieb: /usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals : You are using the 2.4 subprofile of 2005.1. -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 signature.asc Description: OpenPGP digital signature
[gentoo-dev] tentative x86 arch team glep
Dear all, Here's a GLEP that I'm thinking about right now. It's not yet official, since I'd like to get some feedback beforehand (which helps to ensure that I'm not abusing my GLEP-editor powers). If you have additional arguments either pro or con, please send them my way so that I may incorporate them. Best, g2boojum -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 GLEP: 40 Title: Standardizing arch keywording across all archs. Version: $Revision: 1.8 $ Last-Modified: $Date: 2005/01/09 16:12:40 $ Author: Grant Goodyear [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 3-Sep-2005 Post-History: 6-Sep-2005 Credits === This GLEP originated from a rather contentious discussion_ on gentoo-dev about combining the x86 and amd64 keywords. This GLEP attempts to get at the heart of that discontent. The proposed stable-keyword guidelines have been lifted verbatim from `The Doc`_. .. _discussion: http://tinyurl.com/bp859 .. _The Doc: http://dev.gentoo.org/~plasmaroo/devmanual Abstract It is time for x86 to no longer be an exception to the standard keywording guidelines. Thus, an x86 arch team should be responsible for moving packages from ~x86 to x86. Motivation == The original, informal x86 keywording policy, where almost any x86 dev (which were the vast majority of devs) who used a package could mark it stable, arose from a time when there were relatively few Gentoo devs. Adding packages to the tree was the principal concern, as opposed to maintaining existing packages. QA considerations have since modified that policy slightly, and now it is the package maintainers who should mark an x86 package stable. Of course, that policy presumes that package maintainers are generally x86 devs, which is slowly becoming less and less true. This policy for x86 is quite different from how every other arch marks packages stable. For the non-x86 archs, each arch has a specific arch team which is responsible for moving packages from ``~arch`` to ``arch``. This approach has worked quite well for the non-x86 archs, and this GLEP asserts that the same approach would benefit x86 as well. Specification = Stabling guidelines for all archs - For a package to move to stable, the following guidelines must be met: * The package has spent a reasonable amount of time in ``~arch`` first. Thirty days is the usual figure, although this is clearly only a guideline. For critical packages, a much longer duration is expected. For small packages which have only minor changes between versions, a shorter period is sometimes appropriate. * The package must not have any non-``arch`` dependencies. * The package must not have any severe outstanding bugs or issues. * The package must be widely tested. * If the package is a library, it should be known not to break any package which depends upon it. * The relevant ``arch`` team must agree to it. x86 arch team - A robust x86 arch team needs to be created. The [EMAIL PROTECTED] alias already exists, and it merely needs to be used. This team, with the aid of potential non-dev ``arch testers``, has the responsibility of stabling all x86 packages. Current x86 devs who wish to mark their own packages stable must therefore either be members of or make individual arrangements with the x86 arch team. Rationale = There will be a considerable one-time cost involved in establishing a robust x86 arch team. Certainly consistency between the various archs would be a virtue, but is it worth the cost involved? Here are the arguments for enduring the pain involved: * Over time, x86 is likely to become a minority arch as 64-bit systems become the norm. The implicit assumptions that underly the current system (that most devs, users, and package maintainers use x86) will become increasingly less valid. * Markedly improved QA for x86. Assuming that the author's own is behavior is representative, most x86 devs run ``~x86`` systems. Thus, the assumption that devs are good ``x86`` testers is not really valid. One obvious consequence is that packages tend to languish in ``~x86`` for a very long time, since x86 devs running ``~x86`` have little cause to notice that a package has not been marked stable. The much larger effect, though, is that it is rare for ``x86`` packages to be stabled in the context of a full ``x86`` tree, so the big picture of a stable *system*, not just a stable package, is lost. This approach of stabling in the context of a full stable ``arch`` tree, it has been argued_, is the fundamental reason why the non-x86 archs have notably better QA than does the x86 arch. .. _argued: http://thread.gmane.org/gmane.linux.gentoo.devel/30369 Implementation == Creation of a robust
[gentoo-dev] Mail server problems (missing inbox)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since the 2nd, I have discovered that my ISP has messed up my primary inbox, so I have received almost no mail, including anything to an @gentoo.org address. I have now forwarded (I believe) @gentoo mail to what appears to be a good address for me. However, I have received no @gentoo mail since sometime on September 1. So if anyone thinks I have received such mail after the 1st, I haven't. Presumably my ISP will fix things after the Holiday. Sorry for any inconvenience, Regards, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (sparc, devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDGwqSQa6M3+I///cRAl3rAJ9ZwEBvoXxhrNImvhK0doaA9yshpQCgxYZ0 /4uoYmLqLHxv5cPOBbkykqQ= =spPE -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Sun, 4 Sep 2005 11:08:58 +0200 Christian Parpart [EMAIL PROTECTED] wrote: | Maybe I do not understand the diffference between I assume and I | know, and I know I meant the first, however, in that case, Grant, | I do not know why you're requesting this combine when you know about | these issues already. Probably because he understands both the 32/64 issues and the portage side of things far better than you do. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpvz73g1sVLp.pgp Description: PGP signature
Re: [gentoo-dev] 2005.1 profile gives devfs as virtual
050904 Sebastian Bergmann wrote: Philip Webb schrieb: /usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals : You are using the 2.4 subprofile of 2005.1. The 2.4 subdir is the place I found Devfs mentioned, but I don't seem to be using that subdir. I actually have /etc/make.profile - /usr/portage/profiles/default-linux/x86/2005.1 So when I enter 'emerge -Cp devfsd', why do I get : !!! Trying to unmerge package(s) in system profile. 'sys-fs/devfsd' !!! This could be damaging to your system -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Packages for mixed PHP4/PHP5 environment added to Portage
Hi, The PHP Herd is pleased to announce that it has added new packages to Portage which will allow Gentoo to provide stable PHP4 and PHP5 packages on the same box at the same time. These packages have come from the successful PHP Overlay [1]. At the heart of these packages is the new dev-lang/php package (which will replace the existing dev-php/php, dev-php/php-cgi, and dev-php/mod_php packages), and the new dev-php4 and dev-php5 categories which allow us to provide, and support, PHP extensions and frameworks that are specific to each version of PHP. These changes also leave us well-placed for the next major release of PHP (possibly called PHP-6), which upstream are currently brewing. We hope to move these packages to ~arch (on architectures that the PHP Herd supports) on Thursday 8th September, as part of our migration plans [2]. If you find any problems with the packages, please file bugs in Bugzilla as normal. We are aiming to remove the old dev-php/php-4* et al packages on 8th January 2006; support for non-security issues will cease two months earlier on 8th October 2005. The older dev-php/php-5* et al packages have been removed today; anyone still using these packages should move across to the new dev-lang/php package. Support for other architectures will follow as and when other arch teams can resource it; you can follow the progress in [3], and provide feedback to help the arch teams assess the stability of these packages. The PHP Overlay will continue to be the place where the PHP Herd does most of its development and testing. You'll find more packages in the Overlay than in Portage, and new versions of packages will be tested in the Overlay first. [1] http://stu.gnqs.org/diary/gentoo.php [2] http://svn.gnqs.org/projects/gentoo-php-overlay/ [3] http://bugs.gentoo.org/102649 Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] eselect modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Huddleston skrev: I've recently updated opengl-update to use the eselect framework. I think the team has done a great job as it was extremely easy to port the bash script to an eselect module. However, when I placed it in the portage tree, it sparked a little bit of a policy discussion between myself and the core eselect devs on how to best include modules in the tree, so I'd like to let other devs chime in as well. Firstly if you don't know what eselect is, check out: http://www.gentoo.org/proj/en/eselect/index.xml The eselect developers want to keep all eselect modules in their svn repository and distributed through a single package (app-admin/eselect). Their main reasons for this are better QA and less overhead for releases and merging. I have a problem with this policy because: 1) Stability of the modules should not be tied to stability of the core package. Basically, I'd like to determine when my modules get pushed into stable without considering how it'll effect the eselect modules of other developers. Similarly, I don't want bugs in another module holding up my module from going into stable. 2) Not all users will want all modules. The goal of the eselect project is to provide a framework to replace java-config, motif-config, gcc-config, binutils-config, opengl-update, etc, but not all users will need all modules. 3) Some modules require extra files (opengl-update installs header files, gcc-config installs a wrapper, etc), and the app-admin/eselect package is not the correct place to provide these files. Also, what should the correct way to introduce these modules into portage? Should we keep them in the packages they're replacing (x11-base/opengl-update)? Should we place them in a new package in the same category as the script they're replacing (x11-base/eselect-opengl)? Should we place them in app-admin/eselect-module name or perhaps app-eselect/module name? Note that for backwards compatibility in all cases, x11-base/opengl-update will RDEPEND on this eselect module and install a backwards-compatible frontend to the eselect module until all packages in portage have been updated to use the eselect module instead. Any plans on moving webapp-config as an eselect module? :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDGzt+O+Ewtpi9rLERAiZgAKDAzrI29bEbUoVKdji4r9vaZOFFcwCdGbfo rXlfU7yQb6qvpuMj2BR806Y= =d86l -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2005.1 profile gives devfs as virtual
Philip Webb wrote: 050904 Sebastian Bergmann wrote: Philip Webb schrieb: /usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals : You are using the 2.4 subprofile of 2005.1. The 2.4 subdir is the place I found Devfs mentioned, but I don't seem to be using that subdir. I actually have /etc/make.profile - /usr/portage/profiles/default-linux/x86/2005.1 So when I enter 'emerge -Cp devfsd', why do I get : !!! Trying to unmerge package(s) in system profile. 'sys-fs/devfsd' !!! This could be damaging to your system Most likely, the reason you're seeing this is because the 'system' target contains 'virtual/dev-manager' (defined in /usr/portage/profiles/base/). devfsd satisfies this dependency (as well as udev). Portage apparently isn't smart enough to notice that there's another package installed that satisfies this dependency. You can safely unmerge devfsd if you have udev installed and working. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2005.1 profile gives devfs as virtual
On Sunday 04 September 2005 15:11, Philip Webb wrote: Having gone over to Udev, I went to unmerge Devfs got a big red warning. It appears that the 2005.1 profile gives Devfs as a virtual: is this an oversight or is there a reason behind it ? I would have assumed that Udev would now be the required device manager. You installed using an earlier profile, obviously, when devfs was the default for virtual/dev-manager (otherwise you wouldn't have it installed). Because the profile depends on a virtual any attempt to remove a package providing that virtual will throw up the warning. Exactly the same symptom you're seeing with editors on -user. -- Mike Williams -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 4 Sep 2005 09:37:11 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | There will be a considerable one-time cost involved in establishing a | robust x86 arch team. Justify this please. If there is a cost associated, the details of this cost should be provided. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpnO5dNgSqBd.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sunday 04 September 2005 10:37 am, Grant Goodyear wrote: This policy for x86 is quite different from how every other arch marks packages stable. For the non-x86 archs, each arch has a specific arch team which is responsible for moving packages from ``~arch`` to ``arch``. This approach has worked quite well for the non-x86 archs, and this GLEP asserts that the same approach would benefit x86 as well. this isnt quite true ... non-x86 archs usually take their queues for when packages should be moved to stable from the maintainer of the package in other words, arch teams generally defer to maintainers (and rightly so) as to when newer versions should go stable -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2005.1 profile gives devfs as virtual
On Sunday 04 September 2005 01:36 pm, Philip Webb wrote: 050904 Sebastian Bergmann wrote: Philip Webb schrieb: /usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals : You are using the 2.4 subprofile of 2005.1. So when I enter 'emerge -Cp devfsd', why do I get : !!! Trying to unmerge package(s) in system profile. 'sys-fs/devfsd' !!! This could be damaging to your system known portage bug -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2005.1 profile gives devfs as virtual
050904 Andrew Gaffney wrote: Philip Webb wrote: I actually have /etc/make.profile - /usr/portage/profiles/default-linux/x86/2005.1 So when I enter 'emerge -Cp devfsd', why do I get : !!! Trying to unmerge package(s) in system profile. 'sys-fs/devfsd' !!! This could be damaging to your system Most likely, you're seeing this because the 'system' target contains 'virtual/dev-manager' (defined in /usr/portage/profiles/base/). devfsd satisfies this dependency (as well as udev). Portage apparently isn't smart enough to notice that there's another package installed that satisfies this dependency. You can safely unmerge devfsd if you have udev installed and working. Yes, someone provided a very clear explanation to my parallel query yes, Devfsd's ebuild does have a similar 'PROVIDE' line to Joe's. As you say, Portage lacks intelligence here: it needs to be educated to check for other packages or in the meantime make a less forthright warning. Thanx for your explanation, which is what I really wanted. -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
Hi Grant, On Sun, 2005-09-04 at 09:37 -0500, Grant Goodyear wrote: Dear all, Here's a GLEP that I'm thinking about right now. It's not yet official, since I'd like to get some feedback beforehand (which helps to ensure that I'm not abusing my GLEP-editor powers). If you have additional arguments either pro or con, please send them my way so that I may incorporate them. Best, g2boojum For better or for worse, x86 is the maintainer arch for a large amount of our packages. With the new x86 arch team being the only team allowed to stabilise packages on the x86 arch, the concept of the maintainer arch will finally be removed from the tree. This leaves a problem - how can package maintainers and arch maintainers work together to ensure that arch teams only stabilise packages that the package maintainers consider appropriate? I can't claim credit for the following idea, but I can say that it's one we've been using in the PHP Overlay in recent weeks, and it has made my job easier as the PHP maintainer for the ppc arch. Introduce a new arch keyword maint, to turn the concept of the maintainer arch from an intangible into something real. Package maintainers can then mark packages ~maint or maint as required, and leave the real arch keywords for the arch teams to handle. This approach ensures that arch maintainers have the metadata they need to know which packages the package maintainers consider appropriate for stabilising, and which ones they don't. Any guesswork is removed. I'd like to see this proposal in the final GLEP. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 04 Sep 2005 20:48:52 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | Introduce a new arch keyword maint, to turn the concept of the | maintainer arch from an intangible into something real. Package | maintainers can then mark packages ~maint or maint as required, | and leave the real arch keywords for the arch teams to handle. This | approach ensures that arch maintainers have the metadata they need to | know which packages the package maintainers consider appropriate for | stabilising, and which ones they don't. Any guesswork is removed. Workable for a certain category of packages so long as it's advisory only. Arch teams need to be allowed to override maintainers where appropriate, and in some places (eg toolchain, kernel) the concept of maintainer arch is utterly irrelevant. And maint as a name? Yick. maintainer or owner maybe. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpBodFouSyIH.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 2005-09-04 at 14:16 -0500, Grant Goodyear wrote: * Having bodies on [EMAIL PROTECTED] is just the starting point. The more difficult part will be convincing people that it is in their best interests to do things this way. Similarly, what do we do with devs who refuse? All of those issues still remain to be worked out. Depends on how many refuse I guess ;-) There doesn't seem to be much sign of any opposition to the concept so far. We have an elected council now; if the council approves the plan, and devs refuse to follow it, the devs should resign or be ejected. Otherwise, what's the point? :) I'd be more worried about the impact on users. From a user's point of view, x86 is a fast-moving arch, where you can normally find an up to date package, and where most of the major packages are actively and well maintained by the package maintainers. The introduction of the x86 arch team will, at some point, turn the x86 arch team into a bottleneck (just like all the other arch teams already are), and the experience for our users will change. Our challenge as a project is make sure that the benefits of the x86 team outweigh the negatives in the right places, so that we don't lose our users in the process. If the introduction of an x86 arch team results in a lot of pain for our users, it's going to hurt us as a project, and reduce our standing in the wider community. Your GLEP currently doesn't cover this risk, or provide a robust plan for mitigating it :( Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 2005-09-04 at 21:05 +0100, Ciaran McCreesh wrote: Workable for a certain category of packages so long as it's advisory only. Workable for the vast majority of packages in the tree I expect. Arch teams need to be allowed to override maintainers where appropriate, Why not talk to the package maintainers instead, and convince them that you need a different version marking maint instead? Why override (which, tbh, smacks of we arch teams know best, life would be better without package maintainers) when you could work with people instead? You're *not* in competition with package maintainers. We're all supposed to be working towards the same thing :) I've no personal problem with arch teams sometimes needing to do their own thing, provided it's confined to a specific class of package. Outside of the core packages required to boot maintain a platform, when is there ever a need for arch maintainers to decide that they know better than package maintainers? If this isn't confined - if arch maintainers are allowed to override package maintainers wherever they want to - then arch teams need to take on the support burden. Fair's fair - if it's the arch team creating the support, it's only fair that they support users in these cases. It's completely unfair - and unrealistic - to expect a package maintainer to support a package he/she thinks isn't fit to be stable on an arch that he/she probably doesn't use anyway. In such a conflict of egos, the real losers remain our users. And maint as a name? Yick. maintainer or owner maybe. It's just a word. Provided the concept is agreed on, the word isn't the most important thing in the world. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages for mixed PHP4/PHP5 environment added to Portage
On Sun, 04 Sep 2005 18:47:30 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: We hope to move these packages to ~arch (on architectures that the PHP Herd supports) on Thursday 8th September, as part of our migration plans [2]. If you find any problems with the packages, please file bugs in Bugzilla as normal. I've filed notes in the tracker bug you put in the Gentoo Bugzilla but other than your initial response, I haven't gotten any feedback on them. Cheers, -- Jason Wever Gentoo/Sparc Team Co-Lead pgpjcekTCVegI.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
Stuart Herbert wrote: The introduction of the x86 arch team will, at some point, turn the x86 arch team into a bottleneck (just like all the other arch teams already are) A possible way to alleviate this is proactivity on the maintainer's part. Our current rule for going testing-stable is 30 days. If we could alert the arch teams x number of days in advance they could test it before the end of the period minimizing delays. Since all arch teams would need this alert a relevant script could be created/modified. I realize this doesn't help if the arch teams are just plain too busy. Hopefully the 'fast arch' losing its speed will show people that we need more help in testing and bring more people on board. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
Vapier wrote: [Sun Sep 04 2005, 01:00:41PM CDT] this isnt quite true ... non-x86 archs usually take their queues for when packages should be moved to stable from the maintainer of the package Perfectly reasonable. in other words, arch teams generally defer to maintainers (and rightly so) as to when newer versions should go stable I agree that the arch teams shouldn't be marking packages stable in advance of when the the maintainer thinks it's ready. At the same time, it's the respective arch teams, as owners of their entire stable tree, who (in my opinion) should have the final okay on a package going stable, since they're the ones with experience of the entire stable tree. Does that make a bit more sense? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgplQgW8w9jqF.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 4 Sep 2005 15:53:07 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | I'm still thinking about the concept of a maint option. This | question I can answer, however. It's not unheard of for a package | with a lot of dependencies to be marked stable when one of the | dependencies has not yet been so marked. In that sort of | tree-breaking case, the arch teams actually do know better, since | they maintain ``arch`` systems (or chroots) for testing. Anyone doing that needs to have their commit access revoked. repoman has checked for this properly for about eighteen months now. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpo279fLb75j.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 2005-09-04 at 14:40 -0600, Joshua Baergen wrote: A possible way to alleviate this is proactivity on the maintainer's part. Our current rule for going testing-stable is 30 days. If we could alert the arch teams x number of days in advance they could test it before the end of the period minimizing delays. Since all arch teams would need this alert a relevant script could be created/modified. That's where having some devs/ATs running stable, and others running testing really helps.. That and chroots for core packages going from package.masked to testing. It's worked well for amd64 that way. -- Homer Parker Gentoo/AMD64 Arch Tester Strategic Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
On Sunday 04 September 2005 22:53, Grant Goodyear wrote: I tend to think that's fair. At least in my view, the goal is not to minimize the importance of package maintainers, but simply to separate package maintainance from tree maintainance. That's right. I think this is good, as a maintainer. What we actually lack now is a way to suggest a candidate stable. For example, maintaining libtorrent, I found a point where libtorrent/rtorrent worked fine on am64 and ppc, but crashed in some situation on x86, because of a conjunction of -fomit-frame-pointer and exception handling. I refrained from editing the ebuild stable on amd64... so I just added the filter-flag on another version and considered that as possible x86 stable at that point. the ~x86 ebuilds were working, without tinkering with them, but not stable enough for the stable tree anyway. Giving an advice on what to marking stable is probably useful. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpIh5tD7AHcF.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 4 Sep 2005 15:43:11 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: I agree that the arch teams shouldn't be marking packages stable in advance of when the the maintainer thinks it's ready. At the same time, it's the respective arch teams, as owners of their entire stable tree, who (in my opinion) should have the final okay on a package going stable, since they're the ones with experience of the entire stable tree. Does that make a bit more sense? For the most part, this makes sense, However we do have times where a particular arch team may need to stabilize a package sooner in the case where earlier versions are broken. This is not entirely uncommon to see packages that used to compile with stable keywords no longer compile after a period of time. Cheers, -- Jason Wever Gentoo/Sparc Team Co-Lead pgp7aZ5u0rxVe.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
Hi Grant, On Sun, 2005-09-04 at 15:53 -0500, Grant Goodyear wrote: I'm still thinking about the concept of a maint option. This question I can answer, however. It's not unheard of for a package with a lot of dependencies to be marked stable when one of the dependencies has not yet been so marked. In that sort of tree-breaking case, the arch teams actually do know better, since they maintain ``arch`` systems (or chroots) for testing. Yes, but if package maintainers aren't allowed to mark packages as stable on anything but the maintainer arch (unless they are also a member of an arch team), this problem shouldn't happen. At the moment, the only way for a package maintainer to mark a package stable is to mark it stable on a real arch. Creating the maintainer arch solves this very problem. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 2005-09-04 at 21:57 +0100, Ciaran McCreesh wrote: Yeah, foser's on holiday. Good time to push the GLEP through. How typical of you to try and drag this discussion down into something personal :( If you keep feeling the need to do this, do everyone a favour and keep your mouth shut instead. It detracts from otherwise insightful and useful comments. The only reason certain arch teams are considered a bottleneck is because they do real testing. As opposed to x86 or ppc, where packages which won't even unpack get marked stable... You can't help yourself, can you? You have to have a pop at someone :( I didn't mean considered, I meant are. It wasn't a criticism, it's just a statement of fact. It's impossible for an arch team to keep pace with the rate of change in the tree and do adequate testing too. No arch team is currently big enough. Arch teams are always going to lag behind what package maintainers do. It's a simple numbers game. There are only two arch teams with 20 or more members (amd64 and ppc), as of 22:30 BST today. They have to deal with the output of approx 155 herds, plus countless changes that don't go through herds in the first place. The numbers speak for themselves. Arch teams are bottlenecks. Until the numbers change, that won't change. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tentative x86 arch team glep
On Sunday 04 September 2005 23:35, Jason Wever wrote: For the most part, this makes sense, However we do have times where a particular arch team may need to stabilize a package sooner in the case where earlier versions are broken. Why this remembers me xine-lib on sparc? :)) -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpM7zKsqP9eT.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 2005-09-04 at 21:59 +0100, Ciaran McCreesh wrote: If it isn't fit to be marked stable, it shouldn't be out of package.mask. ~arch means candidate for going stable after more testing, not might work. Agreed, but we both know that it's just not how many devs work atm. Perhaps that is a problem that also needs to be solved? There's also the issue that many users are happy running ~arch packages, but are reluctant to test masked packages (making it difficult to get enough feedback to move the package to ~arch anyway). This is a bit of a chicken and egg situation - one that the maintainer arch may provide a new solution to. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 2005-09-04 at 15:45 -0600, Jason Wever wrote: This is the current policy, though it gets violated quite often. Maybe the answer is to have separate trees for arches and general packages then? That would be one solution. (Although not one that I'd personally prefer. I'd rather the package maintainers learned to work within the rules instead.) Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages for mixed PHP4/PHP5 environment added to Portage
On Sun, 2005-09-04 at 14:31 -0600, Jason Wever wrote: I've filed notes in the tracker bug you put in the Gentoo Bugzilla but other than your initial response, I haven't gotten any feedback on them. Sorry, I hadn't realised you were waiting for a response from us. That's now sorted. I appreciate the usefulness of logging answers in bugzilla, but popping into #gentoo-apache to talk to us is always an option too. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 04 Sep 2005 22:54:02 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: Maybe the answer is to have separate trees for arches and general packages then? That would be one solution. (Although not one that I'd personally prefer. I'd rather the package maintainers learned to work within the rules instead.) I agree, I'd rather keep things as they are (and supposed to be) rather than do weird things like have arch specific trees. However, package maintainers (particularly in the scripting herds) need to be disabused of the notion of making assumptions about my language is portable so I can mark this stable. While the script itself may be portable, there may be core elements of said scripting language that don't work quite right and aren't noticed until some particular script package triggers it. This includes shells as well as regular programming languages. Cheers, -- Jason Wever Gentoo/Sparc Team Co-Lead pgpNWIIeP2Vm3.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sun, 04 Sep 2005 22:43:20 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | On Sun, 2005-09-04 at 21:57 +0100, Ciaran McCreesh wrote: | Yeah, foser's on holiday. Good time to push the GLEP through. | | How typical of you to try and drag this discussion down into something | personal :( If you keep feeling the need to do this, do everyone a | favour and keep your mouth shut instead. It detracts from otherwise | insightful and useful comments. What, weren't you around for all the previous attempts at this proposal? | The only reason certain arch teams are considered a bottleneck is | because they do real testing. As opposed to x86 or ppc, where | packages which won't even unpack get marked stable... | | You can't help yourself, can you? You have to have a pop at | someone :( It's the truth, it's a problem and it needs fixing. | It's impossible for an arch team to keep pace with the rate of change | in the tree and do adequate testing too. No arch team is currently | big enough. Arch teams are always going to lag behind what package | maintainers do. It's a simple numbers game. | | There are only two arch teams with 20 or more members (amd64 and ppc), | as of 22:30 BST today. They have to deal with the output of approx | 155 herds, plus countless changes that don't go through herds in the | first place. The numbers speak for themselves. Arch teams are | bottlenecks. Until the numbers change, that won't change. You want numbers? A total of 31 ebuilds seems outdated on sparc A total of 72 ebuilds seems outdated on x86 A total of 3634 packages are keyworded on sparc A total of 7793 packages are keyworded on x86 Real numbers. Not guesswork based upon misconceptions. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgppSH29THZ3S.pgp Description: PGP signature
[gentoo-dev] i8k with torsmo
I'm addding functionality to torsmo by adding support for i8k, The dell laptop utils. I am using existing source code from the i8kutils package to extend this functionality. Now my question is, Since I am using source code from i8kutils and adding it to torsmo, which would be the most appropriate method to pass this info on to torsmo? add a patch to bugs.g.o? pass it directly to torsmo? or something else. I'm still writing it, so nothing pressing yet. Lares -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: i8k with torsmo
Nevermind, torsmo is superseeded by conky. On Mon, 2006-09-04 at 16:51 -0600, Lares Moreau wrote: I'm addding functionality to torsmo by adding support for i8k, The dell laptop utils. I am using existing source code from the i8kutils package to extend this functionality. Now my question is, Since I am using source code from i8kutils and adding it to torsmo, which would be the most appropriate method to pass this info on to torsmo? add a patch to bugs.g.o? pass it directly to torsmo? or something else. I'm still writing it, so nothing pressing yet. Lares -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
On Mon, 5 Sep 2005 1:12:54 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | 3) All packages need to be assigned an x86 arch team member |responsible. Why? | 6) I notice the amd64 team requre their arch testers to |take the ebuild quiz; I think this is a bit harsh, as |arch testers are regular users without commit access to |CVS etc. A simpler quiz targetted at ensuring the arch |testers know what is expected of them would lower the |bar and should encourage more users to join in. Using |the ebuild quiz means you get people who quickly become |devs in their own right... The ebuild quiz isn't particularly difficult... If the proposed write an ebuild for equizapp question goes through then maybe they could be exempt from that until they need cvs access, but the main ebuild quiz just tests basic understanding. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpbJsNZkYDz7.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Mon, 2005-09-05 at 01:12 +0200, Kevin F. Quinn wrote: 6) I notice the amd64 team requre their arch testers to take the ebuild quiz; I think this is a bit harsh, as arch testers are regular users without commit access to CVS etc. A simpler quiz targetted at ensuring the arch testers know what is expected of them would lower the bar and should encourage more users to join in. Using the ebuild quiz means you get people who quickly become devs in their own right... Just until we get finished with the AT quiz, which is working out to be more QA/troubleshooting oriented. The ebuid.quiz was handy, and is a good way to check if the prospect has at least read the docs enough to get the questions answered. It also helps ensure they really want it, rather then having a high turnover rate. The ppc ATs took the test as well, which I reviewed, and gave pointers where there was a problem. JoseJX seems to have liked the help he's gotten so far from them. As for making dev.. hehe.. Yeah, it's a start, and there for awhile we had like 2 ATs because they'd all made dev ;) It does give you a pool of dev prospects as well, which works out nicely. Several of the amd64 ATs submit patches with their bug reports which helps the devs out as well. We now have several ATs that have no interest in making dev, content with helping out as an AT. Got a little longer then I wanted, but wanted to give a decent explanation of our experiences so far. -- Homer Parker Gentoo/AMD64 Arch Tester Strategic Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
On Sunday 04 September 2005 03:59 pm, Ciaran McCreesh wrote: On Sun, 04 Sep 2005 21:26:37 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | Arch teams need to be allowed to override maintainers where | appropriate, | | Why not talk to the package maintainers instead, and convince them | that you need a different version marking maint instead? Why | override (which, tbh, smacks of we arch teams know best, life would | be better without package maintainers) when you could work with | people instead? You're *not* in competition with package | maintainers. We're all supposed to be working towards the same | thing :) Sure, we do that anyway. However, sometimes package maintainers are outright wrong. agreed talk/communcation is fine, if the maintainer is only trying to flex muscles and does not have a good reason, the arch team ought to be able to do what is best for gentoo and not be shot down by a (hm) stubborn(?) maintainer, if the maintaner could do that, the arch team would be quite limited in its effectiveness | I've no personal problem with arch teams sometimes needing to do their | own thing, provided it's confined to a specific class of package. | Outside of the core packages required to boot maintain a platform, | when is there ever a need for arch maintainers to decide that they | know better than package maintainers? Pretty regularly. A significant number of package maintainers have a very shoddy attitude towards QA, and a significant number of upstreams have no clue what portability is. | If this isn't confined - if arch maintainers are allowed to override | package maintainers wherever they want to - then arch teams need to | take on the support burden. Fair's fair - if it's the arch team | creating the support, it's only fair that they support users in these | cases. It's completely unfair - and unrealistic - to expect a | package maintainer to support a package he/she thinks isn't fit to be | stable on an arch that he/she probably doesn't use anyway. In such a | conflict of egos, the real losers remain our users. If it isn't fit to be marked stable, it shouldn't be out of package.mask. ~arch means candidate for going stable after more testing, not might work. pgp9ahKI3ctaR.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sunday 04 September 2005 04:52 pm, Stuart Herbert wrote: On Sun, 2005-09-04 at 21:59 +0100, Ciaran McCreesh wrote: If it isn't fit to be marked stable, it shouldn't be out of package.mask. ~arch means candidate for going stable after more testing, not might work. Agreed, but we both know that it's just not how many devs work atm. Perhaps that is a problem that also needs to be solved? There's also the issue that many users are happy running ~arch packages, but are reluctant to test masked packages (making it difficult to get enough feedback to move the package to ~arch anyway). This is a bit of a chicken and egg situation - one that the maintainer arch may provide a new solution to. sounds like you suggest to trick ~arch users into testing unripe ebuilds/bumps/versions by sending it into ~arch to get the testing done while someone in a chroot would be much better equipped for doing the testing with? Best regards, Stu pgpFrUo735khK.pgp Description: PGP signature
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 11795 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 208 minutes.
--
gentoo-dev@gentoo.org mailing list
