Re: [gentoo-dev] use.force support
Sven Wegener wrote: We just had a short discussion over in #gentoo-portage and the idea of an use.force file for profiles came up. It allows us to force some USE flags to be turned on for a profile. It's not possible to disable this flag by make.conf, the environment or package.use. But we would not be Gentoo, if we don't leave a backdoor. You can disable the flag by putting -flag in /etc/portage/profile/use.force if you really need to. Same goes for sub-profiles that need to disable this flag. Yay! I gues use.force has some other places where it is useful. Like the default-darwin profiles which use ARCH=ppc and USE=ppc-macos but the ppc-macos flag can be removed by using USE=-ppc-macos in the environment. Or selinux profiles, to force the selinux flag to be turned on. It'll be also very useful for the amd64 profiles as in 2005.0 the use flag 'multilib' is disabled but multilib-support is forced. (There are no-multilib-profiles though.) Comments? I consider use.force very useful, it'll finally make all the amd64 users stop asking themselves why the documenation says they will get multilib but the use flag is disabled, so please, go ahead implementing it. Regards, blubb -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project
Anders Hellgren wrote: BonezTheGoon: Don't know, inactive phong: Don't know, inactive pilla: Reluctant, but hasn't said he would refuse. [snip the ones who will take it or where it's not necessary] We're talking about 3 people in the worst case. I don't know how long they have been inactive, so I assume we have 3 people who don't want to take the quiz. GLEP 38 says: As moderators are pretty much exposed to the public (forums users, but also used as contact person for requests that should go to the PR department or the trustees) they need to have some knowledge about Gentoo's internal structure as well as contact to the other developers. I absolutely agree with this, and that's exactly what the staff quiz is for. The quiz has 8 questions, they're all quite easy. For those moderators who have been moderating for years, it shouldn't take longer than 15 minutes. One argument I heard was, that it's not the quiz which is too hard, but people think it's not okay to force moderators to take it to continue their work. I partly agree with this too, I know, the quiz is also (but still not only!) bureaucracy, but looking at this thread it seems to be much less bureaucracy compared to this discussion. To solve this problem, it will take 3 people to spend 15 minutes on a quiz they don't like. Or it will take many more hours to discuss it over and over again. Sorry, but this looks a bit ridiculous to me. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project
Ioannis Aslanidis wrote: Maybe just that Developer sounds prettier than Staff. The rest is exactly as you stated. Now let me ask developers this: Does it really matter you if we are called developers instead of staff? No, why should anybody bother? -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] profiles cleanup
Hi all, I've just removed a few deprecated profiles for amd64, and saw that there are still quite a lot of non-cascading profiles around. The following profiles say they have been removed by 2005.04.01: default-sparc-1.4 default-sparc-2004.0 default-sparc64-1.4 default-sparc64-2004.0 I hope this is not an April Fool's joke ;) There are also many other profiles which are probably deprecated for ages, but don't contain an information about when they will be taken out of portage. Other possible candidates for a clean-up: default-alpha-1.4 default-alpha-2004.0 default-ppc-1.4 default-ppc-2004.0 default-ppc-2004.1 default-ppc-2004.2 default-ppc64-2004.2 default-x86-2004.2 gcc33-sparc64-1.4 hardened-x86-2004.0 I didn't check them all, so I may be wrong, but some of them are deprecated for over a year now. There are also some cascading profiles which are really old and probably should be removed. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo/AMD64 Meeting Log
Hi all, Our team just had a meeting. We discussed the following topics: o Upcoming 2005.1 o Reveiwing our default use flags o Deprecation of 2004.3 o Access to our new dev boxes o QA regarding old bugs o Find alternatives for meetings o status of amd64 donations o #gentoo-amd64 cleanup Timestamps in the log are UTC+2, for those who wonder. Enjoy, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] Jul 02 20:03:51 * blubb has changed the topic to: Prerelease stages in pitr:/releases/2005.1 DO NOT DISTRUBUTE | Please test gentoo-sources-2.6.12-r2 | http://uberslacks.com/gentoo/amd64/ is down, see plasmaroo for mirror | Next Meeting: NOW Jul 02 20:04:14 LizB *yawn* Of course I could go back to bed...but. Jul 02 20:04:17 blubb Kugelfang: you start with 2005.1? Jul 02 20:04:20 Kugelfang surely Jul 02 20:04:38 Kugelfang i'm pleased to announce that the prerelease snapshot finally resulted in prerelease stages Jul 02 20:04:46 Herbs yay Jul 02 20:04:49 KingTaco Kugelfang, yo Jul 02 20:04:54 LizB oooh Jul 02 20:04:55 Kugelfang prerelease was meant by releng to test out build process Jul 02 20:04:57 Flameeyes wow Jul 02 20:05:22 Kugelfang rocket and wolf has some work to fix up catalyst, and /me had some problems with the 2005.0 seed stage Jul 02 20:05:32 Kugelfang but it worked finally Jul 02 20:05:46 Kugelfang i'd be glad if everybody could test the hell out of those stage Jul 02 20:05:47 Kugelfang s Jul 02 20:05:51 blubb Kugelfang: there won't be any stage2 for the end-user, right? Jul 02 20:05:52 eradicator nice to hear =) Jul 02 20:05:58 Kugelfang blubb: right, no stage2 Jul 02 20:06:06 blubb okay Jul 02 20:06:15 Kugelfang you'll find my latest stages always on pitr in /releases/2005.1 Jul 02 20:06:38 Kugelfang also, i will copy the installcd/packagecd isos over there once they are ready Jul 02 20:06:58 Kugelfang ah yes: GRP is done too, worked like a charm after setting X in USE Jul 02 20:07:00 eradicator what kernel is on it? Jul 02 20:07:05 Kugelfang eradicator: 2.6.12 Jul 02 20:07:29 Kugelfang i've today successfuly built stage1 of a livecd, but i still need stage2 Jul 02 20:07:38 Kugelfang which had slight problems, most of them already fixed Jul 02 20:07:46 LizB mmkay Jul 02 20:07:49 * blubb hopes there is a gentoo-em64t kernel ;) Jul 02 20:07:57 Kugelfang blubb: there will be one Jul 02 20:08:03 LizB heh Jul 02 20:08:05 Kugelfang and this time, a working one Jul 02 20:08:10 blubb heh Jul 02 20:08:10 KingTaco heheh Jul 02 20:08:18 * Kugelfang hides ashamed Jul 02 20:08:22 blubb . o O ( note: boot entry != kernel ) Jul 02 20:08:25 Flameeyes Kugelfang, the livecd are the usual glibc based? Jul 02 20:08:29 Kugelfang Flameeyes: yes Jul 02 20:08:44 Kugelfang Flameeyes: it looks like we'll be using glibc based livecds for all arches Jul 02 20:08:52 Flameeyes k :) just to be sure nobody is going to hate me if something goes wrong with libiconv :P Jul 02 20:09:07 Kugelfang beejay tried long to have a uclibc based livecd, but it didn't work like he wanted it to work Jul 02 20:09:21 Kugelfang Flameeyes: hah... embedded will kill ya :-P Jul 02 20:09:56 Flameeyes Kugelfang, i offered them the maintainership and refused :P Jul 02 20:09:58 Kugelfang like i said: I'm eager on feedback re stages and (upcoming) isos Jul 02 20:10:19 blubb i'll test the livecds next time i screw up my box ;) Jul 02 20:10:25 Kugelfang heh, deal Jul 02 20:10:32 KingTaco how many hours is that? Jul 02 20:10:36 KingTaco :p Jul 02 20:10:38 blubb :P Jul 02 20:10:51 Kugelfang it would be very helpful if we could trace all possible installations Jul 02 20:10:59 dang Kugelfang: What's the difference between the pre and the seed stages? Jul 02 20:11:00 Kugelfang a) upgrades from 2005.0/2004.3 Jul 02 20:11:06 Flameeyes i'll test a a stage after the sys-auth move is complete, i wish to restart working on openpam/linux Jul 02 20:11:07 Kugelfang b) new installation w/o network Jul 02 20:11:15 KingTaco Kugelfang, I have access to a compaq R3000 LT on which I could test Jul 02 20:11:21 Kugelfang c) new install with network in stable and in testing Jul 02 20:11:28 Kugelfang KingTaco: great Jul 02 20:11:43 Kugelfang FYI: these prerelease stages _still_ use the 2005.0 profile Jul 02 20:11:58 blubb uh, why's that? Jul 02 20:12:00 Kugelfang i will switch to 2005.1 as soon as i have positive feedback on the currentttos Jul 02 20:12:09 Kugelfang blubb: i want to know they work Jul 02 20:12:18 allanw i can test also if you guys need to, but someone will have to give me the iso Jul 02 20:12:32 dang No iso yet. Jul 02 20:13:06 eradicator Kugelfang: 2005.1 is pretty much identical to 2005.0 profile Jul 02 20:13:16 Herbs can we give AT's access to pitr? Jul 02 20:13:33 Herbs to make available the stages and release media? Jul 02 20:13:39 KingTaco Herbs, we'll talk about that later Jul 02 20:13:50 KingTaco but yes, it's possible Jul 02 20:13:50 Kugelfang blubb: there is not much change in 2005.0 - 2005.1 profile transition, so i want to reduce
Re: [gentoo-dev] New Bugzilla HOWTO
Hi, Chris White wrote: jforman EBUILD BUGS GO IN GENTOO LINUX PRODUCT STOP MARKING EVERY BUG AS A BLOCKER /jforman What about changing the description for the severity field rather than jelling at users? Honestly, if a bug prevents you from using your favourite app, wouldn't you select Blocker: This bug prevents a software application from testing and use.? Or what about Critical: The software crashes, hangs, or causes you to lose data.? Perhaps I should file a blocker bug about this ;) Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Hello
Chris Gianelloni wrote: Filtering the lists leads to a slippery slope. What happens when you start getting false positives? True, but why not filtering binary attachments? *If* you have to send an attachment to these lists, it should either be plain text or your gpg-signature. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Changelogs
Hi, Duncan wrote: and see what's up, or one can visit the website and check it out there, but for such a critical part of a Gentoo machine's infrastructure, one would certainly wish for something a bit easier than either of these. Erm, is that a joke? You want an easier way than browsing to a web page and read? Why should portage go different ways than every other software project? Expanding on the idea a bit further, what about creating a generic emerge changelog function, that fetches the tarball if necessary, then extracts only the changelog, and opens it for viewing (presumably using the $PAGER environmental variable to determine what to display it with)? Naturally, given Gentoo can't control the upstream changelog format, enforcing parseability rules as it does for its own, the entire changelog would of necessity be displayed, leaving the user to figure out the relevant cutoffs instead of doing it automatically as emerge -pl does with the portage tree changelogs, but it'd still be a rather easier way to view upstream changelogs before installation (or for that matter, after) than we have now. Portage is a package manager. package managers have to manage package versions and their dependencies. They do NOT have to be fancy changelog readers. As you already stated, it's not the developers responsibility to get you upgrade information. While I can see a great benefit in putting important information into the changelog, I really can't see why portage should provide functions to read a changelog, when nearly all packages provide the same information on their homepages. Additionally, if you really have to read the changelog before emerging the new version, the information is really important, and I'm sure it will show up in portage's changelog. Please don't make portage a news reader. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Food For Thought: Bugzilla Localization?
Hi, Chris White wrote: 2) Can people be brought on board to localize bugzilla, as well as provide translation of non-english bugs. 3) Somewhat similiar to 2, explain to users what the english fields mean, and have them fill it out in their own language, then have someone come by and translate it for the developers. While it'd be surely a nice idea to translate the field description, I don't think it's a good idea to have non-english bug reports. I'm native German speaker, and whenever I see German compilation errors I'm like WTF??. I really can't figure out what it's all about. With english error messages, it's just clear. I don't know what it's like in other languages, but at least for German, it's PITA to translate technical terms, as many of the words simply don't exist. Most people just mix up German and English, and it works quite well. Also, I think most people speak at least broken English, or they just use google translations/babelfish co. Translating bugs is just a waste of time to me. And having a localized bugzilla with a fat note Please write your bug report in English! is just ridiculous. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Luis Medinas
Mike Doty wrote: Everyone welcome our newest minion: MetalGOD. Luis joins us to help out with the printing herd and amd64 keywording. He also has his eyes on the GDP project. I'll let him introduce himself. may ekeyword be with you! welcome! -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Release files/portage snapshots auxiliary files naming scheme
Hi, Henrik Brix Andersen wrote: I suggest we unify the naming scheme to the one currently in use by our release files to avoid unnecessary confusion amongst our end-users - unless of course there is a good reason for having different naming schemes for release files and portage snapshots? Personally I don't know a good reason either for or against a change. I can't see how one would be confused with different names, so I'd suggest just leave everything as is. If you're going to make the change I won't stop you, as long as you don't ask me to do it ;P Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] We have doc USE flag, why not a man USE flag too
Jason Stubbs wrote: Personally, I think adding FEATURES to USE_EXPAND is terrible. Portage features are not ebuild features. How much do you like C code that has #ifdef's for the compiler being used? It's the same thing. what wrong with #ifdef __cplusplus__? ;) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /var/cache
Hi, Next time please open a new thread instead of hijacking an unrelated one. Dulmandakh Sukhbaatar wrote: I know it's not developers problem, but some times ago I by mistake removed some directories in /var/cache. No I can't install any portage and update it via emerge-webrsync (firewalled). What should I do? Try emerge --metadata, though i'm not sure if it really helps. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Donnie Berkholz wrote: Brian Harring wrote: I don't recall having kde/gtk crap turned on by default when I first showed up. Maybe I'm missing something; regardless, the defaults (which should be minimal from my standpoint) are anything but. I think you recall wrong, then. The default USE flags have been set so that the majority of systems will work properly without modifications, not so that they're the minimal set. I agree with that, since it's easy to configure them, but the problem is that for most users, there is no default use flag at all. I'd say most of our users run either gtk (and gnome) or qt (and kde), but not both. Either you like gnome or kde ;) So we end up having qt, gtk, gtk2, gnome, kde and arts in the default use flags, but nearly nobody wants to use that, so I think it's better to have minimal use flags than pseudo-standard ones. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Grant Goodyear wrote: Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? I'm not sure if it's really worth writing another GLEP for an april's fool... -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Simon Stelling wrote: Grant Goodyear wrote: Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? I'm not sure if it's really worth writing another GLEP for an april's fool... Gnah, forgot to include the link: http://article.gmane.org/gmane.linux.gentoo.devel/26749/match=glep+amd64 You probably want to reuse this one, if you really like the idea, I for sure don't. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Stephen P. Becker wrote: The reason is actually simple: x86 is, or at least was, the reference architecture for almost all programmers. Witih amd64 becoming so widespread, this will change. That's why I have another proposal: Let's merge x86 and amd64 keywords in about 10 years, when x86 died ;) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Martin Schlemmer wrote: I still dont see what practical advantage that would bring to x86/amd64 users or developers? Well, I guess the theory might be because then you only have one keyword and one base profile to manage - I think. Having just one keyword won't decrease our (our as in amd64 team) workload, nor will it increase our (our as in amd64 port) QA, it will just be the other way around. What really is confusing me is that mostly sparc/mips-devs want to push us in a direction we absolutely don't like, but we're affected by all effects, not them. And what is even more confusing, is that they make statements like I don't care about x86/amd64 So to be frank, I propose that either the alt-arch devs start explaining above instead of half-assed answers and senseless ranting, or shut up. From the amount of _usefull_ comments they have given, it does not look like its really an issue or priority for them besides having some fun. So I'm not the only one feeling assed, fine. I know ABI, but only in the context of multilib. We use it to decide whether something is 32bit or 64bit. As stated above, I can see how x86 will benefit from a merge, but the damage amd64 gets seems far bigger. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
Ciaran McCreesh wrote: No, there was an April Fool's joke. Which pretty good shows how ridiculous such a merge would be... -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
Danny van Dyk wrote: Paul de Vrieze schrieb: | I agree with this. It should also be a simple, backwards compatible | solution. Just don't call it maintainer, but maint or something like | that ;-) In case this should really be done, please call it 'stable'... so we get ~stable? ;) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
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. It's a bit of both. When you put a package into ~arch, it's in testing, so that says it needs further testing since there still could be a not yet discovered bug, right? -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
Ciaran McCreesh wrote: | I'm asking that you assume any support burden that you create. It | only seems fair. Stabling a package which is not in packahe.mask is only a support burden if package maintainers are abusing ~arch. I absolutely agree with you, the only point is: People are abusing ~arch in the real world, and we're not yet living in an ideal world. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [OT] Meaning of p.mask
It's not so much the case that no-one dares try pmasked pkgs. Taking a quick trip through the forum will turn up many examples of people who do. But the longstanding policy with masked pkgs is 'this is unsupported - if it breaks, don't come to us - use at your own risk'. Right now there are plenty of people using the Gnome 2.12 RC or xorg 6.8.99 or gcc 4 or the masked utopia stack, but they know better than to file bugs because it will just be closed as invalid. Personally, the only time i'll file a bug against a masked package is when i have a patch. I think you have to distinguish between packages beeing in p.mask because they really need a lot of testing and should only be tested by users that are able to fix their system themselves and packages that are in p.mask because they're horribly broken. I filed 4 bugs about gnome 2.12 without adding a single patch, 3 of them got closed a day later. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
Hi all, This has been in the todo-list for quite a while, but finally it's done. I'm curious what you think of it. Have a nice day, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] GLEP: 41 Title: Making Arch Testers official Gentoo Staff Version: $Revision: 1.1 $ Last-Modified: $Date: 2005/09/07 18:53:20 $ Author: Simon Stelling [EMAIL PROTECTED], Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 7-Sep-2005 Post-History: Abstract Arch Testers should be treated as official Gentoo staff. Motivation == Since Mike Doty (kingtaco) created an Arch Tester (AT) project in January 2005 to reduce the developer's load and the amount of open keywording bugs for the amd64 porting team, many users have volunteered to become ATs. They are doing a fair share of everyday's work to keep the amd64 and ppc trees up to date. While they spent many hours and even had to pass the staff quiz, they are currently not recognized as official members of Gentoo. Specification = ATs should basically be treated as staff. This includes the following changes to the current situation: - Get a @gentoo.org email address - Get read-only access to the gentoo-x86 repository Additionally, the mentoring period should be shortened to two weeks if an AT wants to take the end quiz to become a developer, assuming he has been AT for at least two weeks. Users which want to become developers should also run through the process of an AT. The amd64 porting team has handled situations like this for a while and only made positive experiences. Also, the idea of an arch tester as a trustful user who is able to test critical changes (such as hard masked software branches), should be expanded to every herd. These 'ATs' wouldn't be called arch testers as the 'arch' is irritating, instead, herd tester (HT) could be used. As arch testers (and herd testers) become official staff, they should be handled by DevRel. Backwards Compatibility === All current arch testers should be migrated to staff. Copyright = This document has been placed in the public domain.
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
Stephen P. Becker wrote: developer recruits. The good ATs typically go on to be developers anyway, no? This is sort of like how many companies like to hire you for an internship the summer before you graduate, then full time when you graduate if you were/are good enough. That's what the amd64 herd does for quite some time anyway, but apparently there are people who don't want to become developers with commit access, so that doesn't mean we'll loose all ATs ;) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
Donnie Berkholz wrote: Additionally, the mentoring period should be shortened to two weeks if an AT wants to take the end quiz to become a developer, assuming he has been AT for at least two weeks. Users which want to become developers should also run through the process of an AT. The amd64 porting team has handled situations like this for a while and only made positive experiences. Do you mean only users who wish to become arch devs need to be AT's? It reads as all users who want to become devs must be ATs. Err, it is 'should' as in 'is recommended', not 'have to'. It really doesn't make sense for *every* herd, and should be handled on a per-herd basis anyway. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
Stephen P. Becker wrote: business and make them an arch dev. I guess what I'm *really* asking is whether this GLEP is necessary? As of now, amd64 has 20 ATs, 6 of them became devs, 1 is inactive. The rest stayed AT. The oldest of the remaining has been AT since February, the youngest since Aug 23, so I think it definitively is. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
Ciaran McCreesh wrote: | voting previleges Again, why? They have not yet demonstrated their understanding of complex technical issues. Voting should be restricted to people who know what they're doing. Arch testers have not yet proven themselves. Does that mean that all the Gentoo people who didn't take the ebuild quiz (which doesn't proove the understanding of complex technical issues very good anyway IMHO, but that's another issue) should not be allowed to vote? | Assuming by arch dev you mean arch tester, then: | | Experience, commitment and (at least in theory) recruitment | standards. | | Commitment first: | IMNSHO, it is rude to assume that an Arch Tester is less commited to | their work than an Arch Team member. All developers should be doing | their part and should hopefully ( we don't live in an ideal world here | after all ) be commited to doing their work well. A lack of | commitment that results in shoddy work should get them removed from | any developer role, Arch Team member or otherwise. An arch tester has not committed himself to the project for the same length of time as a full developer. That's not true. The whole point is that our current ATs *don't want* to be developers but are willing to help us and are a great help to keep the tree up to date, and we think it's unfair to honor a dev who doesn't much but sending emails with a nice signature but treating the ATs as users where they do far more than said dev. Uhm... Different people have different skill levels. Some of this is down to natural ability, some of it is down to experience. Arch testers have not yet proven themselves. Full developers have (at least in theory...). Yes, in theory. Too bad reality doesn't match with theory far too often. I for example became dev after just submitting a few app-foo/bar works on amd64 bugs and moaning because it took too long to get them fixed. Of course i knew portage, but I really can't say that I have proven myself to be useful to the project when I joined it. BUT, this was before the idea of an AT existed. Today, every user who wants to become a amd64 developer, has to become AT first, to prove himself, so the problem you're speaking of was fixed, not caused by ATs. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
Homer Parker wrote: On Tue, 2005-09-13 at 04:14 +0100, Ciaran McCreesh wrote: | voting previleges Again, why? They have not yet demonstrated their understanding of complex technical issues. Voting should be restricted to people who know what they're doing. Arch testers have not yet proven themselves. I don't remember that being asked for... As the GLEP asks to make the ATs staff, it'd imply giving them voting privileges. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
Paul de Vrieze wrote: Ok, I do think that we will need a way for the maintainer to indicate that the package is stable. I'd be happy to leave stabilizing out of my hands, but I wouldn't want my packages to be stabilized before I deem it stable. That's exactly what the maint keyword is for. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
Ciaran McCreesh wrote: Well, if it's in ~arch it's a candidate to go to stable after further testing. If a package maintainer isn't prepared to have a package moved to stable, they shouldn't take it out of package.mask. The 30 days are just a rule, there are enough packages which surely need a longer testing period, even if they work flawlessly. Or would you mark gcc 4.0 stable after 30 days? I think that's what Paul wanted to say. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
Ciaran McCreesh wrote: There is nothing in this view that says consulting the package maintainer is not part of the stable decision-making process for arch teams. So do I have to ask the maintainer first everytime I want mark a package stable? Is that what you are currently doing? -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Improved ebuild information
Hi, Daniel Stiefelmaier wrote: In my opinion, the easiest way would be a wiki. Indeed. But why do you need to modify all the ebuilds? An even more simple way would be to have portage tools (eix, emerge) print an automatically generated link like http://www.gentoo-wiki.com/Ebuild:www-client/mozilla-firefox as mediawiki pages always have a discussion page attached, this could be used to get in touch with the maintainers of that package. (Only if they want that. This could be noted on the page) Wikis are very popular, but they aren't the solution to every problem in the world. If you want to contact the maintainer, write a mail, use IRC, or assign bugs to them, but why do we need another (communication) channel? It'd be great if you could animate people to concentrate useful information about a package in a certain place, but that's really not the job of an ebuild or portage. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Classes, a possible new method of spreading information
Hi, Your idea has its points, but I'm not sure if classes aren't just a work-around for lacking documentation in general. Of course, IRC is a lot more interactive than a tutorial, but reading IRC logs is really not the best method to lern something about a certain topic, so documentation would be needed anyway, except for those who are actually there. But then, why not just give them the documentation right away with a Questions/Feedback to [EMAIL PROTECTED] footer? I think this is a far more efficient way to let people educate themselves. So basically, the documentation shouldn't be the primary location to get information. Other than that, i like your idea, and surely won't stop you :) Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Classes, a possible new method of spreading information
Simon Stelling wrote: So basically, the documentation shouldn't be the primary location to get information. s/shouldn't/should I really shouldn't write emails before waking up :/ -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Handling compatible multi tools
What would we gain with such a change? You have two tools installed that are nearly equal, so why would one want to have two of them? *me scratching head* -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Handling compatible multi tools
Diego 'Flameeyes' Pettenò wrote: How many people have both vim and nano installed? Or xine and mplayer? well, i wouldn't say nano is doing the same as vi. There's a pretty big difference. Also, those people who have both installed probably don't use both, they just installed vi and didn't care to remove nano. And about xine/mplayer, they're pretty different as well. I'm surely not stopping you from implementing your idea, I just lack to see a real benefit. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: CHTEKK
Yay! Another member of the Swiss conspiracy! Welcome to Gentoo, Luca -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Getting Important Updates To Users
Hi,
Stuart Herbert wrote:
It would be great if emerge --news displayed the same news as www.g.o.
Doesn't make much sense to me. The biggest benefit from --news over other,
traditional channels would be that it's linked to the tree, meaning, if you
emerge a new kernel version which doesn't contain devfs anymore, the ebuild
would call something like enews ${FILESDIR}/blah which would then somehow make
emerge mention it. [Implementational detail: Sending it to [EMAIL PROTECTED] too
would be very nice.]
I don't see the point in reading a news item telling me that I have to do $foo
because package $bar breaks otherwise when I don't have package $bar at all.
On the other side, we already have einfo and friends, which currently are
probably the most important channels. The often get ignored because there were
no such tools like elog, but that will be fixed soon anyway, and people will
probably read the notices again, because they don't just get lost in 50k lines
of make output.
Information that doesn't belong to a specific package or a specific version
should be sent to gentoo-announce IMO, we really don't need portage to be more
than a package manager.
I started this discussion because I've experienced that the percentage
of users who read our existing news outlets isn't high enough to reach
many of them in the first place ;-)
Reading gentoo-announce should be mandatory. If a user breaks his system because
he didn't know about an important fact due to his lazyness, that's not our
problem. Of course they will still bitch, so let's introduce RESOLVED RTF_ML_.
Regards,
--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Request for changes to GLEP 41
Kurt Lieber wrote: * Drop the idea of giving the arch testers an email alias altogether I don't see what benefit this provides, to be honest. It's not much of a spiff and if someone is signing up to help with testing just for the email address, they're not here for the right reasons anyway. I agree that if somebody signs up for an email address, he's in the wrong place. This issue is not new, it's the same with beeing a dev. Becoming an AT isn't easier than becoming dev: You've got a probation period of 30 days, you've got to do the staff and ebuild quizzes. On a side note, I don't think anybody considers the worth of a @g.o address so high that he would sign up only to gain the email address. On the other side, giving the ATs a @g.o address does make sense. It might be easier for other arches, but at least the amd64 team has quite a lot of them, and it's really difficult to keep all the cryptic email addresses in mind. I have to check our AT-List about 3 times a week to see whether a bug was filed by an AT which I can trust and which I know of what his system looks like, or if it is just average Joe. So to me, an email alias would make things easier, with or without subdomain * Change @subdomain.gentoo.org to @gentoo.org. If we want to give them a spiff in recognition of their contribution to the project, give them the real thing. We do this today for any number of other non-developer groups, including GWN translators, documentation translators, etc. The original GLEP didn't foresee a subdomain, we actually wanted to give them a @g.o address, but it seemed that a lot of devs thought ATs were just a random bunch of incompetent users and as a consequence this, don't deserve a 'real' @g.o address. It made me quite sad, and I'm happy to see that I'm not the only one who thinks it would be better to not cut gentoo into different groups. However, the council asked for it, and so it was changed. And the council didn't ask for this on his own, they were just reflecting the majority of devs, so we'll have to accept that. * Create an entirely new domain I don't really like this, and it seems at least equally complicated as subdomains. If that's really the way we (as in Gentoo) want to go, I'll happily continue to look up the AT page 3 times a week. It's really not a THAT big issue. I just thought it would be nice to give the ATs a @g.o address, but it's really not essentially for me to work. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] implementation details for GLEP 41
Kurt Lieber wrote: Because, in practice, this doesn't happen. Accounts (or, in this case, email addresses) stay around until someone gets enough of a bee under their bonnet to do somethig about it. Since there's no pain or cost for the AT/HT project lead, there's no reason for them to be vigilant about tracking activity. Plus, assuming we have a large number of these testers, how are people going to know whether or not one specific arch tester is active? That's not an acceptable solution. Uhm, does that implicitly mean there is such a tracking method for devs (where dev = dev/staff/whatever)? There are devs who don't have commit permissions to any cvs repo, how is their activity tracked? In the AT case it wouldn't be so hard to check their activity. !seen on IRC and a bugzilla query printing out bugs where they made a comment should be enough, IMHO. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] implementation details for GLEP 41
Lance Albertson wrote: I see this as something that devrel would take care of since they already do this for developers. They already have the tools/access to the places for such things. Would rather not have another set of folks with that access. So do I. Hint: Homer Parker is a devrel member ;) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Decision to remove stage1/2 from installation documentation
Harald van Dijk wrote: (Note that I'm not going to argue either way whether this is a good thing; I'm merely pointing out that the docs do say we're about choice.) You still can choose between stage3 and stage3+GRP without having to do anything but following the handbook :) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] my apologies for the mess with this release of MySQL 5.0.16
Albert Hopkins wrote: Now all-of-the-sudden MySQL 5 is marked -amd64 so now I must downgrade. Is this intentional? read the changelog, it says: 24 Nov 2005; Jory A. Pratt [EMAIL PROTECTED] mysql-5.0.15.ebuild, mysql-5.0.16-r3.ebuild: version 5 does not work on clean install -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Misquoted in the GWN
Is there a good reason for sending this to -dev? You basically complain about the way the GWN authors handled the issue, so why do you tell it all the devs? It seems a bit like a lame attempt to blame them in public for their faults. Other than that, I agree with you. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] UPGRADE ANNOUNCEMENT bugs.gentoo.org
Jakub Moc wrote: :0: * ^From:[EMAIL PROTECTED] /dev/null What a poor flame. Read through the flaming guide [1] twice, and try again. [1] It once was http://dev.gentoo.org/~chriswhite/flame.html, where has it gone? -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: pkg_{pre,post}inst misusage
Duncan wrote: It just sounds like it /could/ be dangerous to me. For some reason, I don't like the idea of something that could hose a system that badly! =8^\ It won't hose your system badly, since you've got /usr/lib64 listed in /etc/ld.so.conf. I agree it wouldn't be very nice though. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
Diego 'Flameeyes' Pettenò wrote: I'm not sure if we're on the same page as far as the target audience of this change. The target audience is developers/those with strict in their features. Actually stricter, and there are way too many people to put that in without knowing what that do... or is it a default nowadays, I'm not even sure. You're mixing up 'strict' with 'stricter'. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Doug Goldstein wrote: the USE defaults are a bit INSANE... We need to get rid of some of this crap... ./default-linux/x86/2005.0/make.defaults:USE=alsa apm arts avi berkdb bitmap-fo nts crypt cups eds emboss encode fortran foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl tcpd truetype truetype-fonts type1-fonts vorbis X xml2 xmms xv zlib What about discussing this with the x86 arch team instead of -dev? IMO it's pretty much their decision what their defaults look like. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
Dominique Michel wrote: When an user or a potential user read it and want to do a networkless install, it will just use the Live CD install, and just get in trouble. It is even worse when many Linux magazines will have this CD. And you cannot argue at it is just to use catalyst or to burn a CD from a stage 3, when the doc say a bootable CD that contains everything you need to get Gentoo Linux up and running. That statement is still true. I have done 3 networkless installations for this release, without a problem. I used the installer. Using it you get your box up and running fast and convenient, so what exactly is the problem? It's not like you can't get Gentoo running without a network connection anymore. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
Roy Bamford wrote: Dropping support for x86 i686 is a debate we need to have some time I suppose, its a question of when. There is clearly only a few users, besides myself using systems that old, since there were very few forums posts about the original 2006.1 x86 media not workign on P1 and AMD k6 based systems. I'm sure I'm not the only one who is using a pentium mmx as a router, so you better think twice about it :P -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Paul de Vrieze wrote: I would go for the EAPI bump. Even then I think it would be smart to wait a short while for packages to use this as we ensure that the supporting portage version is stable. Err, EAPI was designed to assure that a supporting version is actually used, no need to wait then. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Andrew Gaffney wrote: Are you saying you like a bunch of php-only USE flags (I'm not picking on php...it was just the first that came to mind) being in the default USE in the profile? Do you also like the nofoo flags? AFAIK, previous discussions said that the per-ebuild default USE would go in the USE stacking order above make.conf and below package.use, so that USE=-* wouldn't remove the default USE flags for the particular ebuild but the user could still disable it via package.use if they *really* wanted to. Actually, USE=-* would still remove them because make.conf is above the defaults in the stacking order (if i understood correctly). Plus, don't forget that we will get package.use for the profiles with this patch, so it fixes all the problems in-ebuild defaults would solve too. I agree that base/ would probably be the better place for this. It avoids another layer that seems just redundant. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] *plop*
Good luck with all the things you will be doing in future... You will be missed. -- gentoo-dev@gentoo.org mailing list
Re: Recommended -march settings [was: Re: [gentoo-dev] CFLAGS paragraph submission for the GWN]
Wernfried Haas wrote: What about creating an official document for both -march/mtune and CFLAGS settings for different CPUs? If some other people like the idea and no one else volunteers i can go poke the different arch teams, toolchain folks and whoever else may be involved about it and compile a list based on their input. Check out these packages [1] before doing that, they will probably supply all you need. [1] http://packages.gentoo.org/search/?sstring=cpuinfo -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 and ia64 keywords
Ilya A. Volynets-Evenbakh wrote: | No worries, there are people who even wanted to merge amd64 with x86. Yeah, that's almost as daft as suggesting a single keyword to cover both sparc v8 and sparc v9, or ip22 and ip27. Err... No, IP22 and IP27 are nearly identical as far as userland goes. (and if we did everything right, they would be completely identical) Now, if you said o32, n32, and n64 [x] You just made a fool of yourself. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Developer: Matti 'mabi' Bickel
Hello all, It is my pleasure to announce the devification of Matti (mabi) Bickel to the Gentoo community. Matti has been a Gentoo/PPC arch tester for about a year and finally made the step to a full-fledged dev. As such he is going to help the PPC team with keywording requests and bugfixes. Living in Weimar and studying CS in Jena, he is going to join the German conspiracy. He is also a member of the local CCC there. Non-computer hobbies are reading (science, hitchhiker up and down, other novels, but of course also computer-related) and adrenaline sports such as table tennis. Please give him a warm welcome! -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Gentoo Commitfests
Alec Warner wrote: Haha, there are times when you need to realize that it's just joking around, versus an actual flamefest ;) This makes Gentoo look very unprofessional. It even makes us look like we're having fun. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] implicit vs explicit dependencies
Alin Nastac wrote: Up till now, I relied on implicit dependencies (dependencies of my dependencies). Apparently now (see https://bugs.gentoo.org/show_bug.cgi?id=152534) we should add every atom that an ebuild depends on to (R)DEPEND. Which is the right way? In the bug above we're talking DEPEND, for which this is true: gtk was installed with a binpkg and those don't pull in their DEPENDs because the package is already built. For RDEPEND you can savely rely on implicit dependencies, in most cases at least. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure
Mike Frysinger wrote: (how do you measure the degree of a change ?) By the number of inflammatory mails it causes within the timeframe of two weekdays. Quite obvious, isn't it? ;) -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
Chris Gianelloni wrote: Realize that the new council is trying to both become the leaders of Gentoo that so many seem to want, yet also have to balance not overstepping the bounds some people think we need. We honestly do need everyone's opinions on these things, so thank you for posing yours. I don't mind the council touching the metastructure, as long as they do it right ;) If they don't, I will surely state so and ask for a referendum. If it turns out that like 60% of the devs don't share the council's opinion I'm sure they will re-think their decision. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: license group file format
Marius Mauch wrote: Ok, as there is currently a lot of work going on for GLEP 23 (licese based visibility filtering aka ACCEPT_LICENSE) the topic of license groups came up, in particular the way how they should be (technically) defined. The simplest way is a line based format groupname license1 ... licenseN however this doesn't allow for any addition of metadata (for example descriptions to explain the purpose of a group), these (if wanted) would have to be defined in another file. The alternative would be to use a more complex file format, for example so called ini-style Uhm, what kind of metadata are we talking about here? Descriptions can just be placed in comments above the group specification line, no? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: license group file format
Uhoh, forgive me for not reading the other replies before writing a completely redundant one. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ignoring/overwriting IUSE from an eclass
Piotr Jaroszyński wrote: Just for fun(=I wouldn't use it in ebuild/eclass): Sorry, but this mailing list is not really the best place for just for fun bash foo. I suggest you take it somewhere else. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] CAMERAS as USE_EXPAND
Hi all, I would like to add CAMERAS to the list of USE_EXPANDed variables. It is currently used by media-libs/libgphoto2, which can be built with/without support for the following photo cameras: adc65 agfa-cl20 aox barbie canon casio clicksmart310 digigr8 digita dimera directory enigma13 fuji gsmart300 hp215 iclick jamcam jd11 kodak konica largan lg_gsm mars minolta mustek panasonic pccam300 pccam600 polaroid ptp2 ricoh samsung sierra sipix smal sonix sonydscf1 sonydscf55 soundvision spca50x sq905 stv0674 stv0680 sx330z template toshiba ...which is IMO enough to warrant USE_EXPAND. For any objections, suggestions for a better name, etc. please also see bug 139884: http://bugs.gentoo.org/show_bug.cgi?id=139884 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wrong dependencies to postgresql
Enrico Weigelt wrote: since jakub (as always) closes all my bugs, I'll report the issue to this list before completely giving up and never ever waste a single second on reporting bugs ... Please, never ever waste a single second on reporting bugs anymore. Your time is too worthy to be spent on such things. Thank you, and have a merry Christmas. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Through the looking glass: Reflections on Gentoo
Hi, Ivan Sakhalin wrote: Now, our memories of the past are not always as thruthful as we would like them to be, selective memory is what makes some large things small and some small things large. So let us not idealize the past as if it had no problems, but let us try to keep a perspective on how things have changed, evolved maybe, into what they are now and what they may become. Let us also not forget that a very vocal minority doesn't make a majority. Many good people, having all attained the rank of full developer, have retired, with a noticeable increase in the last trimester or so. Some have retired to avoid all the political tomfoolery that kept them from enjoying their work, some left as they found something else to fill that special place in their heart. Some, sadly, did not feel they could contribute enough as real life took its toll - may they find some time in the future. And a very selected few, regrettably, were retired against their will. Depends on your point of view. Some of these regrettable cases weren't that regrettable to me. These removals even went outside the ranks of developers - the hostile takeover of some IRC channels has caused unneeded tension between groups that should cooperate. It is a sad day when the appearance of a gentoo developer may be the first sign that your channel will now be censored and people removed that have dissenting opinions. I don't know what you're talking about here. Can you elaborate? a few people. But when people are denied an appeal and devrel unilaterally decides, ignoring policies and common sense, what is one supposed to think? Same here. Everything that is not official (for certain undefined values of official - objectivity seems to be lost on many humans) is attacked, torn apart and By the very vocal minority. Be reminded that the large majority of the devs doesn't give a damn, to be clear. insulted. A great example of that is the Sunrise Overlay, which has become quite a success, with a few of the community members becoming devs - at the same time I see with sadness that at least one dev has retired because of Sunrise. What madness there is when people leave such a great project because One. It was his own choice, so I don't think that incident is too dramatic. I ask you not to redo the errors of the past and remember the lessons learned - there is so much that needs to be done, but no single person has the strength to do them. Cooperate you must, my friends. Only when you leave the infighting and bureaucracy behind can you aspire to true greatness. You're not the first one to figure this out. It looks quite simple, and everybody will agree with your statement above, because it is not practical at all. As soon as you get into implementation of above wisdom, things get complicated. So, if you seriously want to help Gentoo, do it in a concrete manner. - Reduce the rules so that things can be done without a week of discussion for every small idea This is a very interesting idea. Do you genuinely think that less rules will result in less discussion? Quite the contrary, my friend. If there is no rule for an action, there will be a discussion whether said action was good or not. We don't need more or less rules, we need better rules. - how can the environment be improved so that people can enjoy their work and not care about silly problems? Shut up the people that cause silly problems. We've done it before, it works. So, with that being said, I hope that things change for the better. I doubt so, to be honest. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] deprecating /etc/make.profile
Hi all, As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of /etc/make.profile and the use of a PORTAGE_PROFILE variable instead. Reason for this change aside from consistency with all other portage settings is the annoyance of re-adjusting the /etc/make.profile link before and after testing a profile change in an overlay/development repo. Before the change to portage is finally made, a few things will have to be done: * Adjust handbook * Adjust the eselect plugin * (Anything I'm missing?) If you don't like this idea, please speak up. [1] http://bugs.gentoo.org/show_bug.cgi?id=148388 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Some sync control
Piotr Jaroszyński wrote: What do you think? I think it would be much nicer to have a VCS with support for atomic commits. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
I like the idea. Something really useful I could think of is *drums* the implementation of GLEP 42. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New USE_EXPAND - CAMERAS
Hi, This was discussed before, and noone was against it as it seems: http://article.gmane.org/gmane.linux.gentoo.devel/44932/match=cameras+use+expand -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Another council topic for Feb
Mike Doty wrote:
We're going to talk about arch keywording policies. IMO we should have
a standard policy if you own and use ${ARCH} then you may keyword your
packages for ${ARCH} with the exception of the sys-*/ categories.
keyword ~${ARCH} exclusively or also marking stable?
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
Ciaran McCreesh wrote: Which is all very well, but not sufficient reason to screw up a project that is developed and used by a lot of people. As if we were all gonna die without bash arrays in our config files. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Google Summer of Code 2007
Ciaran McCreesh wrote: * devmanual. Not converting it over to a new shiny XML thing or whatever, but just extending and reworking the parts that need it. Last year's SoC FAQ said that the actual work would have to be coding, not writing documentation. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New emul-libs.eclass
Hi all,
I recently worked on the app-emulation/emul-linux-x86-* packages and
used almost identical code snipplets in them, so I realized I might as
well put together an eclass and drop the duplication. The eclass would
provide a common template for the following packages:
app-emulation/emul-linux-x86-baselibs
app-emulation/emul-linux-x86-compat
app-emulation/emul-linux-x86-gtklibs
app-emulation/emul-linux-x86-medialibs
app-emulation/emul-linux-x86-qtlibs
app-emulation/emul-linux-x86-sdl
app-emulation/emul-linux-x86-soundlibs
app-emulation/emul-linux-x86-xlibs
Thanks for any feedback,
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 developer
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Original Author: Simon Stelling [EMAIL PROTECTED]
# Purpose: Providing a template for the app-emulation/emul-linux-* packages
#
ECLASS=emul-libs
EXPORT_FUNCTIONS src_unpack src_install
DESCRIPTION=Provides precompiled 32bit libraries
HOMEPAGE=http://amd64.gentoo.org/emul/content.xml;
RESTRICT=nostrip
S=${WORKDIR}
SLOT=0
IUSE=
DEPEND=
emul-libs_src_unpack() {
einfo Note: You can safely ignore the 'trailing garbage after EOF'
einfo warnings below
unpack ${A}
cd ${S}
ALLOWED=${ALLOWED:-^${S}/etc/env.d}
find ${S} ! -type d ! -name '*.so*' | egrep -v ${ALLOWED} | xargs
-d '
' rm -f || die 'failed to remove everything but *.so*'
}
emul-libs_src_install() {
for dir in etc/env.d etc/revdep-rebuild ; do
if [[ -d ${S}/${dir} ]] ; then
for f in ${S}/${dir}/* ; do
mv -f $f{,-emul}
done
fi
done
# remove void directories
find ${S} -depth -type d | xargs rmdir 2/dev/null
cp -a ${S}/* ${D}/ || die copying files failed!
}
Re: [gentoo-dev] New emul-libs.eclass
Timothy Redaelli wrote:
# remove void directories
find ${S} -depth -type d | xargs rmdir 2/dev/null
Portage should remove blank dirs or am i wrong?
Yes, but only in the unmerge phase it seems, so you it installs them,
then checks whether they are empty and removes them again, which is both
stupid and confusing.
cp -a ${S}/* ${D}/ || die copying files failed!
For future *BSD compatibility (yes i want to use the linux bsd emulation
for flash, opera, etc) it's better to use rsync -a imho
I'll use cp -pPr.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
Simon Stelling wrote: I'll use cp -pPr. Actually -dpPR, which is what -a is an alias for. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
Fabian Groffen wrote: I'll use cp -pPr. Actually -dpPR, which is what -a is an alias for. Yes, but -d is a GNU option, and BSD people are after the POSIX only options, hence the -pPR. :) Missed that, Flameeyes just told me about it, so the -d will be dropped again ;) -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
Mike Frysinger wrote: every use of find | xargs in there should be fixed to use find -print0 | xargs -0 The second one, yes, that's fixed now. The first one, no, cause egrep wouldn't like it. The xargs -d' ' ensures that \n instead of a simple space is used as delimiter. If some package really installs files with a newline character in its name, well, then that package is just not worth including in emul-packages. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
Mike Frysinger wrote: replace that with: xargs -d $'\n' aye, that looks way better. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour
Simon Stelling wrote: [snip crap] Actually, ignore me, there's a fundamental flaw in my thinking. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] multilib-strict
William Hubbs wrote: Where do I find information on how to fix the package? If you don't have a box using a multilib profile (I guess the user who filed the bug was using an AMD64 box), you won't be able to reproduce it. Just reassign the bug to [EMAIL PROTECTED], we'll fix it :) Regards, Simon -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] more up to date minimal install cd
Daniel Robbins wrote: And it should be one (web) page. http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1 -- Kind Regards, Simon Stelling Gentoo/AMD64 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
Daniel Robbins wrote: 1) Any material created by Gentoo developers, as part of an official Gentoo Project, needs to have copyright assigned to the Gentoo Foundation, whether or not it is currently included in the Portage tree. This protects all of our collective contributions against misuse, which is why it is policy. Except that in many European countries you can't even re-assign your copyright. Oops. -- Kind Regards, Simon Stelling Gentoo/AMD64 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
Ciaran McCreesh wrote: I find it amusing that no-one complaining about this has actually asked to see it. I think ferringb did, just not very successfully. -- Kind Regards, Simon Stelling Gentoo/AMD64 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
Ciaran McCreesh wrote: I'd like it spelt out please. Here we go: So why not start by imposing deadlines upon more important projects like Portage USE deps, [snip] USE deps can't be used anyway in EAPI=0 because it would break current versions of portage. So we need EAPI=1, but you can't say putting together version 2 of a spec before version 1 was writte is sane. So we need the EAPI=0 spec. Makes it pretty easy to figure out why this spec is fairly important. -- Kind Regards, Simon Stelling Gentoo/AMD64 -- gentoo-dev@gentoo.org mailing list
Re: Copyright, non-US devs and Gentoo Foundation vs Gentoo (Was: [gentoo-dev] Some council topics for March meeting)
Danny van Dyk wrote: 2) There are countries who acutally adhere to the Berne Convention (1886). This means even the deed of commiting sources with a Copyright (C) Gentoo Foundation is useless in most countries of the EU. ^ It's still Europe :P --' -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
Ciaran McCreesh wrote: It's wasting everyone's time and annoying a lot of people. This sniplet was brought to you by the almighty Flaming Guide [1]: | One thing is to frequently refer to us or our. Pretend like people | are with you on this, so the uncertain ones will flock to your side! | | Code listing 1.6: Usage of plurality | email: Stop wasting our time! [1] http://dev.gentoo.org/~chriswhite/docs/flame.html -- Kind Regards, Simon Stelling Gentoo/AMD64 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Introducing the Proctors - Draft Code of Conduct for Gentoo
Thanks for the write-up :) | Receiving one (or more) warnings. Usually, you wouldn't be banned for | a single warning, but it might happen if we feel your infraction is | severe enough. We consider banning to be pretty serious; we take each | situation on a case-by-case basis and make sure we always have a | consensus for whatever decision we reach. Who is we in this? I assume it's devrel, but I think it should be written out. -- Kind Regards, Simon Stelling Gentoo/AMD64 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Introducing the Proctors - Draft Code of Conduct for Gentoo
Richard Brown wrote:
Respectfully, you're wrong. When you're writing a
policy document we do need to dissect every word.
I disagree with that. At least in my country, laws are written in a
flexible enough way to give judges the ability to interprete the law to
a certain extend, and it works just great. I don't see why we have to
dissect every word, especially since it makes it so easy to not to see
the wood for the trees. The goal of the CoC is fairly vague ('getting
along well'), so why is there a need to specify the way ulta-explicit?
--
Kind Regards,
Simon Stelling
Gentoo/AMD64
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] About testing applications
Petteri Räty wrote: Many applications save preferences in ~/.app/. When testing applications please make sure you test with an empty directory to catch cases when an upgrade works fine but a clean install doesn't. Thanks. Even better: Fix them to use ~/.config/app instead, so they don't clutter up the home unnecessarily :) -- Kind Regards, Simon Stelling Gentoo/AMD64 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Improved user information and communication
Hi, Daniel Stiefelmaier wrote: Take the USE flag perl, for example. It has the description Adds support/bindings for the Perl language. but for mysql setting it enables the installation of some support scripts that just happen to be written in perl. Since perl is a global use flag, this is inappropriate use. You might want to file a bug :) man emerge provides information on possible options, why should there not be a way to get information on an ebuilds option??? because emerge is the tool, not the object. You wouldn't expect the openoffice documentation to cover examples for different kinds of letters, would you? The useflag xprint sounds like printing support, but doesn't tell if you need it if you use cups or the kde-printing system or... whatever. ~ $ grep xprint /usr/portage/profiles/use.desc xprint - Support for xprint, http://www.mozilla.org/projects/xprint/ what do you need more? - There are many Gentoo-related HOWTOs, not linked on a projects homepage You can easily find those through searching google - Some ebuilds give homepages like gnome.org just for some little gnome app that is not linked on gnome.org Same here, googling usually helps - There are not only howtos but other useful related pages Same here. Why do you think just because YOU don't need it, noone will? This is not a personal debate. The most important reason I see against this idea is that portage is a package manager, not a documentation center. Why should the ebuild contain links to documentation? To be honest, not even the HOMEPAGE info is needed, it's just for the user's convenience. I tend to refer to the UNIX principle: The right tool for the right job. For your problem, google (or any other search engine of course) is the right tool. No, don't give information to users! Don't have a defined way to get information to a package! It's evil! Do you think we're all sadists? Sorry, but such statements don't help your argumentation. BTW, if This is out of the domain of a package in any package management system, then why do some packages print additional information after emerging, like what files should be updated manually? For the user's convenience of course. Introducing documentation links in ebuilds however is a massive effort, and I don't think that effort is worth it. I'd rather fix a broken package than googling for documentation. I'm sure every user is able to search for HOWTOs, but not every user is able to fix a broken package himself. That question was rhetorical. Of course it's because portage can't handle everything. This is why there should be an easy, defined way to get information. This defined way is google, IMHO. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] emaint and handling of user editable files
Christian Hoenig wrote: On the other hand it would be very nice to allow comments in the world file, too, as I very often don't remember why I installed a package (a lib which for example was just a dependency for lokaly installed stuff). As I'm writing this I get the idea, that this probalby should not be part of the world file but of portage itself with a --comment TEXT parameter :-). That sounds awkward. Why introduce a new option to portage if you could just fire up your preferred text editor and create a whyiinstalledthisstuff file? Really, this is not the purpose of a package manager IMO. So, finally, how should emaint --fix deal with comments in files? (a) Only give a recommendation what / how to fix? (b) Fix if there are no comments contained, otherwise only do (a)? (c) make emaint --fix comment the lines out instead of removing them entirely. That way, you could just ignore comments and it would be a lot safer too.. I simply don't like the idea very much of having a tool removing lines from my config files. You could use ## or #@ (or whatever) to comment the lines out, which should be easy to recognize for the user. It would take a few seconds to cut the lines starting with said prefix out of the file, and the user could remove old comments in the same go. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
Zac Medico wrote: What do people think about adding userpriv and usersandox to make.globals FEATURES? I've been using these for a long time and haven't had any trouble with them. Are there any arguments against making them default? I didn't verify this personally, but a few days ago mkay came to #g-portage and asked whether FEATURES='usersandbox -sandbox' resulting in sandbox enabled is expected behaviour or not. Before we add usersandbox to the default FEATURES we should make sure that -sandbox always disables sandbox. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Outstanding decisions
Hey all, I'm just wading through a list of ~200 bugs of which some need decisions what should be done, whether it should be done at all or simply whether it is a bug or not. Bug: SRC_URI: spaces not supported http://bugs.gentoo.org/show_bug.cgi?id=102607 Is this a 'NOTABUG' case? Bug: gpg: strict incorrectly takes priority over severe http://bugs.gentoo.org/show_bug.cgi?id=68906 What's the expected behaviour? Is it NOTABUG? Bug: Method to monitor a package without installing/upgrading it http://bugs.gentoo.org/show_bug.cgi?id=47456 Same thing. Do we want this? Bug: Support for a pre-compile pkg_config http://bugs.gentoo.org/show_bug.cgi?id=99529 As Jason mentioned: Is this worth the effort? Bug: per profile package.keywords http://bugs.gentoo.org/show_bug.cgi?id=55321 Voting seems to be a bit... incomplete ;) Bug: Wording These are the packages that I would merge, in order: http://bugs.gentoo.org/show_bug.cgi?id=112439 This needs a decision too. What wording do we prefer? Either way, the bug should be closed, the fix is trivial in case we want to change it. Bug: global exception handling http://bugs.gentoo.org/show_bug.cgi?id=28535 Should tracebacks be thrown in the users' face or not? Bug: /usr/lib/portage/bin/clean_locks documentation example could make use use DISTDIR http://bugs.gentoo.org/show_bug.cgi?id=116676 Call portageq or not? Voting time ;) That should be enough for the moment. More will probably follow, considering that I only checked the first 60 bugs or so :/ It would be nice if we could make the needed decision and then close the bugs where it is NOTABUG/INVALID/LATER. I hate stale bug listings ;) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Outstanding decisions
Next bunch of bugs that need a decision: Bug: portage: emerge unmerge ... should stop in case of an error http://bugs.gentoo.org/show_bug.cgi?id=118515 Another WONTFIX/WILLFIX issue Bug: need a way to package.unmask packages in profiles http://bugs.gentoo.org/show_bug.cgi?id=118440 Is this LATER? Alec mentioned a patch, but i couldn't find it when grepping through my archives, and nothing is attached to the bug. Bug: emerge/ebuild - a bit more verbosity please http://bugs.gentoo.org/show_bug.cgi?id=67892 This obviously lacks any discussion. RFC :) Bug: Support for src_test deps required http://bugs.gentoo.org/show_bug.cgi?id=69021 WONTFIX/WILLFIX? Bug: no documentation on the elog functions http://bugs.gentoo.org/show_bug.cgi?id=116018 AFAICS it's documented in make.conf.example and man make.conf, but the user requested a howto. Is a howto really needed? IMHO it's not that complex... Bug: Split CONFIG_PROTECT into separate installing and uninstalling options (nuke untouched files) http://bugs.gentoo.org/show_bug.cgi?id=8423 The classical one with a huge CC list. Whatever decision is made, this finally needs to get (fixed and) closed. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Breakout etc-update, dispatch-conf
I'm all for it. How about 'virtual/config-manager'? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Stablizing portage 2.1
Zac Medico wrote: Well, it's been the tree for 2 days now we'll surely get bug reports as soon as people run into these hypothetical issues (though I expect very few, if any regressions). I think the globals cleanup is worth having in 2.1 because it makes the code more maintainable. Ack. If you want to move back to a more stable revision, I'd suggest 2.1_pre7 (before manifest2). I believe manifest2 introduced more potential for regressions than the globals cleanup did. I think we should really include Manifest2 in 2.1. So my personal favourite is pre10. I don't think Zac's cleanup will introduce many bugs, and if there are any, it should be pretty easy to fix them. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] feature freeze for 2.1
Zac Medico wrote: the addition of new features. From this time forward, please do not commit anything to the 2.1 branch (current trunk) unless it is a fix for functionality that already exists. Thank you in advance for your cooperation. Why don't we make 2.1 a real branch and use trunk for 2.2? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Re: Atom matching behavior
Brian Harring wrote: Response to this is that well don't have versions like that, which while valid, is ignoring the point- cpvs are exact in their version specification, there isn't anything implicit about them. This sounds to me like 'division through zero doesn't make sense, but i've still got the right to do it'. Really, if anybody is ever going to release 1.0 and 1.0.0 along each other, that person is completely on crack. You can't do 2/0, either can you have 1.0 and 1.0.0 being different versions. They should be the same. That being said, which one is higher? Tag on a (.0)* implicitly, you open up potential issues like above. Nonissue, really. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
