Re: [gentoo-dev] Last rites: dev-php5/ZendOptimizer
On Thursday 03 March 2011 22:26:38 Ole Markus With wrote: > # Ole Markus With (03 Mar 2011) > # Masked 30 days for removal. > # Fetch restrictions. Does not work with >=dev-lang/php-5.3 > dev-php5/ZendOptimizer i dont run ZendOptimizer currently, but i have used it in the past to run commercial applications signed by Zend Guard. it appears for php > 5.3 the Zend Guard Loader - 5.5.0 is the replacement for ZendOptimizer. ebuild here: https://bugs.gentoo.org/show_bug.cgi?id=346043 kind regards Thilo
Re: [gentoo-dev] CUPS 1.4 and FFMpeg 0.6
Christian Faulhammer said: > Hi, > > a security stabilisation for Chromium [1] wants Cups 1.4 stable. My > test requests on Planet Gentoo and via identi.ca revealed no real > blockers, although people report that they needed to readd their > printers in order to work. Does anybody here know an obstacle to the > stabilisation? And should a news item issued for that? i've been running 1.4.x for a couple of months - no problems on the desktop. on the server though, 1.4.x regresses with regard to DNS- SD/bonjour when using avahi as a backend - which is a bit of a problem, since apple disables listening to cups broadcasts. so anybody having osx clients, will not have zero configuration of printers on those clients. https://bugs.launchpad.net/ubuntu/+source/cups/+bug/465916 in my opinion this should *not* block stablization, though. kind regards Thilo > > The same goes for FFMpeg 0.6, although it is needed for a security > stabilisation of VLC [2]. There is one open bug which still needs to > be resolved, otherwise I had no reports of problems so far. > > V-Li > > [1] https://bugs.gentoo.org/show_bug.cgi?id=335750 > [2] https://bugs.gentoo.org/show_bug.cgi?id=332361 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] QA last rites for net-misc/omnievents
Alec Warner said: > On Mon, Aug 30, 2010 at 1:18 PM, Diego E. Pettenò wrote: > > # Diego E. Pettenņ (30 Aug 2010) > > # on behalf of QA team > > # > > # Initial import in 2005 and never bumped; no users in tree; > > What does 'no users in tree' mean? No revdeps? I read this as: nothing in the tree depends on it. it is a leaf in the global deptree. kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
Mike Frysinger said: > On Tuesday, August 24, 2010 08:57:45 Thilo Bangert wrote: > > > , efficient, known-good solution > > > that does what you'd expect it to do and replace it with a new > > > thingy that doesn't provide all the features, is harder to debug > > > etc. etc.? I just don't see any *advantage* from it apart from > > > saying "OMG HAZ NEW FEATRUES" :) > > > > one feature of systemd is, that it has an active upstream. > > ... and so does openrc presumably you are referring to this: http://www.gentoo.org/proj/en/base/openrc/ ? Thats great news. Thanks. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
> Or you just let a shell handle it. Does most of the things > automatically, has a pretty low memory and startup overhead, and it > tends to be quite human-readable. > > ... why would I want to remove a > stable the biggest complaint about openrc is that its not in stable - go figure. > , efficient, known-good solution > that does what you'd expect it to do and replace it with a new thingy > that doesn't provide all the features, is harder to debug etc. etc.? I > just don't see any *advantage* from it apart from saying "OMG HAZ NEW > FEATRUES" :) one feature of systemd is, that it has an active upstream. no, i dont think it would be a good idea to switch to systemd, just yet. but like the original baselayout was breaking new ground back when it first was developed, so is systemd. it does things differently and may not have all features yet, but from the outset it appears to be vastly superior to sysv-style inits, upstart and openrc. granted, systemd is currently able to attract enthusiastic supporters. reducing these to mere fanboys, however, is ignoring the technical solution that systemd proposes. yes, openrc works great - and yes, systemd is a better solution when looking at the overall problem. given how long, so far, it has taken openrc to reach stable, it is no wonder people start lobbying for systemd today. ;-) kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Wiki(es) for Gentoo ?!
Alex Legler said: > On Fri, 20 Aug 2010 23:01:42 +0200, Thilo Bangert > > wrote: > > Dear all, > > > > can somebody summarize what the status is for one or more wikies for > > gentoo - its users and/or its developers or whatever. > > > > I can see this: > > http://www.gentoo.org/proj/en/wiki/ > > There was a meeting (logs on this list) where the goals of the project > were discussed and defined. Things like policies are still to be > discussed. uh - hhm. cant seem to find it. will look further, when i'm fully awake tomorrow. would be great to link to stuff like this from the project page, though. > > Infra has hardware ready and I have started building a set of git repos > with the mediawiki sources for it. > > The testing wiki I host needs fixing because of a PHP update. I'll try > to get to that this weekend. great - let me know. > > > I'd like to know what and where someone interested in this could > > help. Thanks. > > Get the team to meet again and do the boring work (policies!). ok > Or if you're into PHP talk to me about helping with the sources. do you have a TODO document laying around somewhere? i talk PHP from time to time. > > Alex signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events
> > > > has somebody found a way to access the gentoo calendar at google via > > anonymous caldav or a plain ics read only url? i'd like to add the > > gentoo calendar to my favorite calendaring software. > > the link from the Gentoo page shows you the Google calendar ID: > 88di0t0pl2cfau7oak48rbccfs%40group.calendar.google.com > > so use that to get a xml/ical/whatever link: > https://www.google.com/calendar/ical//public/basic > https://www.google.com/calendar/ical//public/basic.ics Thanks a lot! works like a charm. Perhaps this can even be added to the frontpage - like so: Calendar (ics) where ics is a link to the ics file. just an idea though. Again thanks. Thilo > etc... > -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events
Mike Frysinger said: > the front page of http://gentoo.org/ now links to a Google Calendar > (see side bar). this has been around for a while, but it seems it's > been more of an "underground" thing, so it's time to raise its > awareness. > > like other aspects of Gentoo, all Gentoo developers have access to it > to add their own events. anything Gentoo related may be added of > course ! meetings, events, scheduled package events, etc... > > the access step requires a bit of help though -- simply e-mail me off > list your gmail account and we can get you set up. once you have > access, you may easily pass it on to other Gentoo peeps. has somebody found a way to access the gentoo calendar at google via anonymous caldav or a plain ics read only url? i'd like to add the gentoo calendar to my favorite calendaring software. or are google non-customers limited to the web view? thanks Thilo > -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Wiki(es) for Gentoo ?!
Dear all, can somebody summarize what the status is for one or more wikies for gentoo - its users and/or its developers or whatever. I can see this: http://www.gentoo.org/proj/en/wiki/ and this: http://bugs.gentoo.org/show_bug.cgi?id=75855 I'd like to know what and where someone interested in this could help. Thanks. kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Treecleaner Project: Maintainer-needed page
> > The script is running daily at 4:15 AM (UTC) I think but it only > updates the page when needed. > Using pquery it finds all the maintainer-needed packages. Then it > compares this list to the yesterdays' one and decides if an update to > the page is necessary or not perhaps you can add a timestamp at the bottom to indicate when the list was last updated. dont know if the date on the right is updated but a timestamp would be more accurate. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Treecleaner Project: Maintainer-needed page
Markos Chandras said: > Hi > > The Treecleaners project introduced ( over a month ) and new page[1] to > track maintainer-needed packages. This page is automatically > generated. You can make use of this page to track packages that needs > your love instead of searching bugzilla or grep the entire tree. > > On behalf of the Treecleaners project awesome! this is really cool. perhaps even announce it on gentoo-dev- announce. a feature request / suggestion for improvement may be to include a link which shows bugzilla search results for the package directly (like the one you can see on the linked packages page). also, perhaps include a paragraph like the following: Gentoo developers and users are encouraged to pick up maintenance for maintainer-needed packages. Users can become maintainers for packages via the proxy-maintainer process (link to proxy-maintainer page - could not find it) anyway - great work! thanks Thilo > > [1]: > http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
> So you want me to force everyone to update the package just to respect > the LDFLAGS. yes. IIRC it has been stated on this list before, that a change which changes the resulting binary always needs to be done in a revbump. > Why, since until recently, nobody gave a crap about this > kind of QA issues? Thats a bad excuse! > > Please provide a patch for devmanual to make it more clear. Good idea. Any takers? thanks kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
Richard Freeman said: > On 08/14/2010 10:29 AM, Markos Chandras wrote: > > So do I. Fixing your package and you don't even bother to send a > > *ready to go* patch upstream seems like a bit rude to me as well. > > Perhaps, we do have a complete different point of view in this one. > > Recent example is Chí-Thanh Christopher Nguyễn who thanked me for > > fixing his package, asked me to attach the patch so *he* can send it > > upstream. I thought that was the *default* policy. Anyway. I should > > talk to each maintainer separately when I fix his package. Seems to > > me is the best approach > > My two cents. In my opinion, whether a commit is good or not depends > on whether it left Gentoo as a whole in better or worse shape than > before it was made. > > Here it sounds like we had QA problems before the commit, and no QA > problems after the commit. Maybe the maintainer has some work to do > now, but he had it to do anyway, and the maintainers have less work to > do now than they did before the patches were made. > > Now, if he had broken something due to a sloppy commit I'd be more > concerned. > > Many hands make for lighter work. The best way to have many hands is > to make individual tasks easier. 1+1+1+1+1 is going to happen faster > than 3+2, since nobody ever gets around to doing 3. > > If we give devs an ultimatum like "fix it all or don't fix anything" > guess which one they'll pick? exactly. maybe the maintainer has to do some catch up work, but thats ok. the aim is to improve the tree and not for QA to do the work of the maintainer. perhaps there is a lesson here though: if the bug isnt closed as soon as the patch has hit the tree, but its subject changed to 'push QA patch upstream', then it is clear what is left to do. > > Rich signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] status of releng project
> 1) I assume most people who are crazy enough to 'install gentoo on > thousands of machines' use some kind of image based installation > process and not a color-by-numbers install vis-a-vis the handbook? > Has anyone written a Gentoo installer that is not image based? > 1.5) There is a hidden assumption here that image based installations > would not work for everyone (likely due to a lack of the 'right' > image; too old, wrong arch, etc...) agaffney had started work on quickstart, which basically did what the handbook did in an automatic fashion. i only tried it a couple of times, but it worked rather well. its a small and neat piece of code. for anybody looking at deploying Gentoo in an automatic fashion this is a good start: http://agaffney.org/quickstart.php kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] status of releng project
Ben de Groot said: > On 9 August 2010 14:29, Mike Frysinger wrote: > > sure would be nice if someone picked up the installer again ... > > No, it wouldn't. Best leave that dead and buried. Could you explain why you think so? > > Cheers, > Ben signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Reviving GLEP33
Ben de Groot said: > On 7 August 2010 02:18, Brian Harring wrote: > > The thing you're ignoring out of this g55 idiocy is that people don't > > particularly seem to want it. There has been an extremely vocal > > subgroup of paludis/exherbo devs pushing for it while everyone else > > seems to have less than an interest in it. That's generalizing a > > bit, but is reasonably accurate. > > Exactly. This is Gentoo. Let Exherbo devs go develop their own distro > and stop trying to interfere with Gentoo. It is time the council puts > a definite stop to GLEP 55. if the council should stop anything, then rude behavior like you have shown. I am personally much in favor for GLEP55, as it solves a technical problem that keeps coming up and have no association with Exherbo at all. If you want to constructively contribute to Gentoo, i'd hope you reconsider a message like the above before sending it next time. > > > _EITHER WAY_, rather than having g33 get beat down for unrelated > > reasons by people screaming they want their pony/g55, g33 can proceed > > despite claims to the contrary, and it doesn't require g55 as > > ciaran/crew have claimed. > > I for one am a strong supporter of GLEP 33. I believe it is one of the > most promising ways to move forward. And I hope the council decides to > get behind this. I for one am a strong supporter of GLEP 55. I believe it is one of the most promising ways to move forward. And I hope the council decides to get behind this. I also support the aims of GLEP33. > > Cheers, > Ben signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
Markos Chandras said: > On Tue, Aug 10, 2010 at 06:31:52PM -0400, Mike Frysinger wrote: > > On Tue, Aug 10, 2010 at 5:53 PM, Markos Chandras wrote: > > >> It seems like few of our fellow developers don't know how to track > > >> down > > >> packages that don't respect LDFLAGS. Adding -Wl,--hash-style=gnu > > >> is a good way > > >> to do that. I would like to see this linker flag enabled by > > >> default on LDFLAGS > > >> (or at least for the dev/ profiles for now). Do you agree? > > > > > > I would really really *really* appreciated if our beloved arch > > > testers ( at least for linux amd64/x86 because they are the first > > > who stabilize a package ) make this default on their build boxes. > > > > sounds like someone needs to update/extend the arch testing > > documentation. random e-mails posted to random dev lists are quickly > > forgotten. new arch testers however should be reading the arch > > tester documnt. > > I will update the guide for amd64 HT and I will strongly advice the > rest of the arches to do that as well. Using my QA powerzzz I will be > quite strict from now on with arches making such stabilizations. i agree on this. packages on which portage complains about stuff like dohtml: bla file not found should not be marked stable. arch testers should not let stuff like this pass by. of course, neither should developers. but then again, we need better documentation of all of this. lyckily, the wiki effort has been killed off by a recent cabal kind regards Thilo > > > > It is annoying to mark a package stable when it has *clear* QA > > > problems. > > > > please dont blow this out of proportion. two points: > > - stabilizing newer versions of a package when there is no QA > > > > regression is fine. > > Fair enough, still those QA need fixing. The fact that these QA probs > are not regressions doesn't mean it is ok to ignore them > > > - ignoring LDFLAGS, while incorrect, is rarely going to lead to > > > > broken packages being emerged on end users' systems. ignoring > > CFLAGS/CXXFLAGS however is much more likely to result in problems for > > end users when working with multilib or cross builds. > > -mike > > Of course. Respecting any *FLAGS is vital and definitely ony of the > many reasons we use Gentoo. signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
Christian Faulhammer said: > Hi, > > please avoid having stabilisation requests > like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a > security bug. That way, architecture teams may not see the severity > directly and it slips, leaving users with vulnerable versions longer > than needed. Thank you. perhaps it's a good idea to tell people what you expect of them instead. i presume just removing the blocker will not satisfy you. ;-) kind regards Thilo > > V-Li signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Policy for late/slow stabilizations
Markos Chandras said: > On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote: > > On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras wrote: > > > What? I am talking about exotic arches and I didn't say to drop to > > > entire stable tree. Just to shrink it in order to keep it up to > > > date more easily > > > > But my question stands: what really is the advantage of having a > > stable tree, when you could better invest your time in keeping the > > testing tree up to date and working? Most production systems are > > running x86, right? Are stable versions of minority architecture > > installations really that much more stable than testing versions? > > Because a stable tree it is supposed to work. Testing tree on the other > hand is vulnerable to breakages from time to time. We can't always > ensure a working testing tree. We are people not machines. We tend to > brake things and this is way we have the testing branch. also the stable tree implies security support (GLSAs etc). signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
Domen Kožar said: > This should probably be updated: > > http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#flash Thanks for noticing this. Everybodies input makes Gentoo a great place to be! Now, if you want that extra chocolate chip cookie, please head over to https://bugs.gentoo.org and report the issue there. ;-) (remember to search for duplicates first). Thanks kind regards Thilo > > On Fri, 2010-06-18 at 15:58 +0200, Angelo Arrifano wrote: > > On 18-06-2010 12:16, Alec Warner wrote: > > > On Fri, Jun 18, 2010 at 2:08 AM, Lars Wendler wrote: > > >> Am Freitag 18 Juni 2010, 03:42:29 schrieb Brian Harring: > > >>> On Thu, Jun 17, 2010 at 05:14:16PM -0500, Dale wrote: > > Lars Wendler wrote: > > > Am Mittwoch 16 Juni 2010, 14:45:21 schrieb Angelo Arrifano: > > >> On 16-06-2010 14:40, Jim Ramsay wrote: > > >>> Chí-Thanh Christopher Nguyễn wrote: > > One notable section is 7.6 in which Adobe reserves the right > > to download and install additional Content Protection > > software on the user's PC. > > >>> > > >>> Not like anyone will actually *read* the license before > > >>> adding it to their accept group, but if they did this would > > >>> indeed be an important thing of which users should be aware. > > >> > > >> I defend it is our job to warn users about this kind of > > >> details. To me it sounds that a einfo at post-build phase > > >> would do the job, what do you guys think? > > > > > > Definitely yes! This is a very dangerous snippet in Adobe's > > > license which should be pretty clearly pointed at to every > > > user. > > > > Could that also include a alternative to adobe? If there is > > one. > > >>> > > >>> The place to advocate free alternatives (or upstreams that are > > >>> nonsuck) isn't in einfo messages in ebuilds, it's on folks blogs > > >>> or at best in metadata.xml... einfo should be "this is the > > >>> things to watch for in using this/setting it up" not "these guys > > >>> are evil, use one of the free alternatives!". > > > > Why? You are running a free and opensource operating system, what's > > wrong suggesting *other* free and opensource alternatives? You are > > just providing the user a choice, not to actually oblige him to > > install anything. > > > > Also, I'm pretty sure seeing nvidia-drivers suggesting the use of the > > kernel driver when using the hardened profile. > > > > >> Maybe I expressed myself a bit misinterpretative. I don't want to > > >> request an elog message telling users about alternative packages. > > >> But in my opinion an elog message pointing at the bald-faced > > >> parts of Adobe's license should be added. These parts about > > >> allowing Adobe to install further content protection software is > > >> just too dangerous in my opinion. > > > > > > I will ignore the technical portion where basically any binary on > > > your system; even binaries you compiled yourself have the ability > > > to 'install things you do not like' when run as root (and > > > sometimes when run as a normal user as well.) > > > > For all the years running Linux, I never found that case. > > > > > The real meat here is that you want Gentoo to take some kind of > > > stand on particular licensing terms. I don't think this is a good > > > precedent[0] to set for our users. It presumes we will > > > essentially read the license in its entirety and inform users of > > > the parts that we think are 'scary.'[1] The user is the person > > > who is installing and running the software. The user is the > > > person who should be reading and agreeing with any licensing terms > > > lest they find the teams unappealing. I don't find it > > > unreasonable to implement a tool as Duncan suggested because it is > > > not a judgement but a statement of fact. "The license for app/foo > > > has changed from X to Y. You should review the changes > > > accordingly by running " > > > > I'm the person who initially proposed warning users on elog. The > > initial proposal only states about: > > 1) A warning about change of licensing terms. > > 2) A warning that "additional Content Protection software" might be > > installed without users consent. > > > > In fact, portage already warns the users about bad coding practices, > > install of executables with runtime text relocations, etc.. How is > > this different? > > If me, as a user, didn't know about such detail (who reads software > > license agreements anyway?) and someday I hypothetically find a > > executable running without my permission as my user account and I'm > > able to associate it with Adobe's flash, I would be pissed off to no > > extent. And guess what? First thing I would *blame* is flash > > maintainers. I expect package maintainers to be more familiar with > > the packages they maintain than me. As consequence, I expect them to > > advice me about non-obvious details on those packages. At least >
Re: [gentoo-dev] Suggestion related with dropping keywords policy
Pacho Ramos said: > Hello > > Let my explain the problem and my suggestion to handle it better (at > least from my point of view) with an example: > > Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that > bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added. > Since libcap-ng was not keyworded in all arches but x86 and amd64, I > had to drop keywords for bluez and open > http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it. > > From my point of view, I would prefer to: > 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to > keep bluez keyworded. > 2. Open two bug reports as done with current policy: one for keywording > libcap-ng and other to check bluez works ok with it asking arch team to > unmask that USE flag if possible. > > This way to go would have the advantage of letting people running bluez > on affected arches to still get the latest bluez version instead of > still having to run a pretty old (and buggy) one. it seems to depend on turnaround time. if arch teams respond quickly, then the USE flag masking would just be an increase in workload. if they are slow to respond then that may be a good investment. given that one cant dictate the speed at which arch teams work, your proposal sounds very sensible. I am OK with both methods. kind regards Thilo > > Thanks for considering it signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
> This thread belongs to gentoo-project. perhaps its time to reduce the number of mailinglists again. IMHO it doesnt hurt to have this thread on gentoo-dev and the volume of messages and their tone here has been sufficiently normal to again allow for more subjects. just my 2 cents kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: changing the developer profile: FEATURES="test" -> FEATURES="test-fail-continue"
you make valid points regarding the overall improvement of the handling of test suites. I am not opposed to something like that being done... it still seems like there is agreement around the fact that something needs to be done about src_test. currently you cant run a system which generally enables this phase. however, the fact that different people see different problems, should not stop us of from solving any problem. so as a small incremental step, the method of RESTRICTing failing tests is acceptable despite the negative consquences you mention. thanks kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: changing the developer profile: FEATURES="test" -> FEATURES="test-fail-continue"
Ryan Hill said: > On Fri, 04 Jun 2010 17:11:45 +0200 > > "Paweł Hajdan, Jr." wrote: > > What do you think about doing the following change in > > /usr/portage/profiles/targets/developer/make.defaults: > > > > replace "test" with "test-fail-continue" to make it just less > > frustrating (we still have a lot of test failures) > > > > Hopefully that will also make more of us use the developer profile, > > and detect test failures. > > > > What do you think? > > I would say it's an improvement only because it might prevent one or > two people from completely disabling it first chance they get. :) > > IMO, test failures should be given the same status as build failures. > Packages shouldn't be commited until they're fixed or bypassed. > Following that reasoning, FEATURES="test" is the correct setting for > the dev profile. It _should_ be annoying when you hit it, that's the > point. Fix it! What's the point of even having a test suite if it > always fails? You'd be better off to RESTRICT it and save yourself > some bug reports from me and all the other users you're foisting build > errors on. > > But in the real world it seems it's just never going to happen. I've > been arguing this for years but people simply don't care. It doesn't > help that we don't have any finer control than "on" or "off". I'd > like to be able to say things like "these tests should only be run by > developers" or "some failures are normal" or "hope you have 10 hours > to run this" or "don't run these as root" or "don't run tests on arm" > etc etc. I'd like a pony while I'm at it. > > Sorry about the rant. This is one of my biggest long-standing > annoyances. > > Um, so yeah. For it! as it seems, there is disagreement about the issue among developers. Perhaps the council would like to settle this, so that we can go on with our lives. i do agree, that all packages should build successfully including the test phase. RESTRICTing the test and an open bug when this is not the case. thanks Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The importance of test suites
"Paweł Hajdan, Jr." said: > On 2/21/10 5:08 AM, Ryan Hill wrote: > > I have one simple request. When you make a non-trivial change to an > > ebuild - a patch, a version bump, anything that can effect the > > behaviour of the package - please run the test suite. > > Yeah, on my dev box I just run with FEATURES="test" all the time. Then > it's impossible to forget it. And I also catch failures in other > packages. > > Maybe it should get more exposure in the developer docs? > > > If it fails, fix it. Or restrict it. Or even make it non-fatal if > > there's no other choice. > > It's really frustrating when there is a bug reported about package > failing tests and everybody can reproduce it, yet the maintainer > doesn't at least put RESTRICT="test" in the ebuild. > > Is it acceptable for another dev to jump in and add RESTRICT="test" to > an ebuild if the maintainer does not respond to a bug report in a > timely manner? IMHO yes! of course, the bug has to be left open until the issue is fixed for real. > > The concern here may be that it's papering over the real problem, but > the good side is that it'd make running with FEATURES=test much easier. which is a good thing, since more tests will be run. RESTRICT="test" should always generate a repoman QA warning IMHO. > > By the way, for packages that fail the test suite and refuse to disable > it, I change the env locally so that FEATURES=-test (via > /etc/portage/env). how many packages do you have in there? i usually just do it manually, so i dont have easily available stats on how many packages are affected. > > Paweł Hajdan jr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] News item: MySQL 5.1 bump
"Robin H. Johnson" said: > On Mon, Feb 15, 2010 at 11:32:10PM +0200, Samuli Suominen wrote: > > On 02/15/2010 11:21 PM, Robin H. Johnson wrote: > > > This is my last blocker for getting MySQL 5.1 series into ~arch > > > status. > > > > > > > > > itle: MySQL 5.1 unmasking > > > Author: "Robin H. Johnson" > > > Content-Type: text/plain > > > Posted: 2010-02-15 > > > Revision: 1 > > > News-Item-Format: 1.0 > > > Display-If-Installed: > > > > > The 5.1 series of MySQL is going to be unmasked at the same time as > > > the release of this news item. When upgrading from an older major > > > version, you will be required to rebuild everything linked to the > > > libmysqlclient.so.15. > > You can do this by installing gentoolkit and running: FQPN: app-portage/gentoolkit thanks Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python-3.2-related changes
Arfrever Frehtes Taifersar Arahesis said: > 2010-02-06 17:54:10 Mark Loeser napisał(a): > > Arfrever Frehtes Taifersar Arahesis said: > > > 2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a): > > > > I consider filing bugs for not adjusted packages after some > > > > months (e.g in summer). > > > > > > 1123 packages (440 in dev-python category) from 108 categories > > > specify dev-lang/python or virtual/python in DEPEND or RDEPEND, so > > > actually it might be better to start filing bugs in this month. If > > > there are no objections, then I would like to file 1 bug per > > > category (except dev-python category). > > > > Make trackers and make one bug per package. Its way too hard to > > follow a huge metabug with a bunch of packages listed in it. > > Average number of non-dev-python packages handled in 1 bug would be > only 6.4, but I can create create 1 bug per package, if you still want > it. having done mass-filings with one bug per package in the past i know how tedious these are. nevertheless, 1 package per bug it must be - it makes all kinds of stuff way easier (think of retirements). good luck and thanks. Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
Mike Frysinger said: > On Sunday 17 January 2010 15:20:46 Thilo Bangert wrote: > > Ben de Groot said: > > > I think we have a bigger problem with packages that have a > > > maintainer, at least nominally, but said maintainer does not > > > actually maintain the package anymore. > > > > full ack. i was thinking that maybe we need an 'easy-fix' team, which > > can do all the easy fixes, which have been laying around for way too > > long and which aparently are "easy to fix" (ie. only waiting for > > somebody to commit)... > > when the bug wranglers re-assign to maintainer-needed, have them tag it > with SIMPLE or something no - i wasn't talking about maintainer-needed bugs. it is my impression, that many apparently maintained packages have simple bugs lingering for extended periods of time. Fx. users reporting bugs AND supplying fixes, ready to be committed. i dont want to step on anyones toes, which is why this may need to be put in place carefully - but i do think it would improve average quality of the tree. the easy stuff, that is maintainer-needed is done regularly by a number of people. of course, "easy stuff" is different for different people. the SIMPLE keyword would definitively work, though. can somebody add it to bugzilla? thanks Thilo > -mike > signature.asc Description: This is a digitally signed message part.
[gentoo-dev] how to indicate "co-maintainers welcome"?
Sebastian Pipping [snip] said: [snip] > i chose maintainer-wanted to indicate that co-maintainers and > non-maintainer-bumps are welcome. what valid means can i use to send > such a message, instead? i dont know of any. i generally assume all packages are looking for more maintainers, but that assumption may be as invalid as yours (having maintainer-wan...@gentoo.org as in metadata.xml to indicate the above). kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] layman storage location (again)
Ciaran McCreesh said: > I realise this is a lost cause, but... Repositories are databases, so > /var/db/ is your friend. > i like it. Closely followed by /var/lib/layman... wikipedia says in http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard /var/lib/ State information. Persistent data modified by programs as they run, e.g., databases, packaging system metadata, etc. /var/layman i dislike due to this sentence in the FHS: "Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication[...]" IMHO layman does not qualify. i am not religious on these things, however. kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
Ben de Groot said: > I think we have a bigger problem with packages that have a maintainer, > at least nominally, but said maintainer does not actually maintain the > package anymore. full ack. i was thinking that maybe we need an 'easy-fix' team, which can do all the easy fixes, which have been laying around for way too long and which aparently are "easy to fix" (ie. only waiting for somebody to commit)... the details would stil have to be thought through, but anything which improves the felt responsitivity for our users can only be good. Did you know: Gentoo is dying! ;-) kind regards Thilo > signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] QA last rites for media-gfx/viewer
Jeroen Roovers said: [snip] > Feel free to > CC me on bugs related to this package if you find any more pressing > issues. the standard way of indicating such an interest is to add yourself to metadata.xml. kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: use.local.desc
Thomas Sachau said: > On 12/11/2009 10:30 PM, Hanno Böck wrote: > > Am Freitag 11 Dezember 2009 schrieb Christian Faulhammer: > >> "George Shapovalov (george)" : > >>> Modified: use.local.desc > >>> Log: > >>> added local flags for new version of net-fs/coda > >> > >> Please don't add local flags to use.local.desc anymore. They are > >> now maintained in metadata.xml file. > > > > Is this a wise idea? > > Because, when I choose a new local flag, I try to stick with ones > > other packages already use (to make possible future transition to a > > new global one easier). This isn't possible any more if there's no > > central place for them. Maybe something like use.local.desc that is > > autogenerated? > > use.local.desc is autogenerated from metadata.xml of all packages in > main tree (same is also done for use.local.desc for sunrise overlay). > is the script doing this available somewhere? it could come handy for people with large overlays... thanks kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] irregular project metadata check
Joshua Saddler said: > On Tue, 8 Dec 2009 10:20:36 +0100 > > Thilo Bangert wrote: > > Hi all, > > > > similarly to the metadata.xml check, the following is a list of small > > problems related to the project metadata as found in the gentoo CVS > > repository. > > > > Documentation: Only 1 developers signed up for project! > > Only one GDP member, eh? Your script is rather unreliable. Take, for > example, our GDP page: > > http://www.gentoo.org/proj/en/gdp/index.xml > hhm, crazy. > It lists all our developers, as does: > > http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/metadoc.x > ml?view=markup > > Yet your script only seems to be looking at devrel's > roll-call/userinfo.xml file, no - the script crossreferences userinfo.xml with the projects index.xml. removing the comments between the devs makes the script work correctly for the gdp page... which leaves me a little mystified. in any case: thanks for the pointer > which is autogenerated from the LDAP > attributes each developer has. The problem with checking LDAP for > roles is that there doesn't seem to be a standard way to label > projects. For docs, you'll find the following roles: > > French Documentation Lead > Documentation > Documentation, Developer Relations, Infrastructure > ---> this one doesn't seem to be counted as Documentation, since it > lists other roles. Documentation, Czech Translation > Translator Follow-Up > . . . etc. > > There are LOTS more different references to working with documentation > or translation, some of them not even for the GDP. Normally > "Documentation" refers to the GDP, but I see some devs in there who > are not on the GDP team who list Documentation as a primary role. No > standardization there whatsoever. > > Another problem with checking LDAP attributes is that they tend to be > very out-of-date, even more so than project pages. People get their > LDAP stuff set ONCE, when they first join, then tend to forget about > them for the rest of their stay in Gentoo. Examples: all the Xfce (or > XFCE) guys who are no longer there, or anyone who's added six > different teams and package herds since their original > responsibilities. > > I wish there was a standard way of labelling existing duties, and I > wish there was an easier way to update the LDAP attributes. I think no > one cares enough to login to dev.g.o to change their stuff, as the > process is tedious. > ideally we would populate LDAP from the projects index.xml files. > You may want to point your script at all our (sub)project index pages > and check for the tag to see who does what, though that may > generate some false hits because not all of 'em will actually be > Gentoo developers, as in the case of arch testers. > this is what i intended to do. i'll report back the results once this has turned into something a little more reliable. kind regards Thilo signature.asc Description: This is a digitally signed message part.
[gentoo-dev] irregular project metadata check
Hi all, similarly to the metadata.xml check, the following is a list of small problems related to the project metadata as found in the gentoo CVS repository. research: Unknown developer: bradlyatc research: Retired devloper: blubber desktop-util: Retired devloper: pyrania fbsd: Retired devloper: uberlord desktop-wm: Retired devloper: obz Scientific Gentoo: Unknown developer: jlec vmware: Project DEAD! Zero developers signed up. RSBAC: Project DEAD! Zero developers signed up. roll-call: Project DEAD! Zero developers signed up. Catalyst: Project DEAD! Zero developers signed up. Portage Sandbox: Project DEAD! Zero developers signed up. obsd: Project DEAD! Zero developers signed up. presentation: Project DEAD! Zero developers signed up. press coverage: Project DEAD! Zero developers signed up. Gentoo Devmanual: Project DEAD! Zero developers signed up. Project "userrel" does not habe this subproject reference: /proj/en/userrel/summerofcode/index.xml desktop: Only 1 developers signed up for project! config_tools_research: Only 1 developers signed up for project! Xeasyconf-ng: Only 1 developers signed up for project! desktop-wm: Only 1 developers signed up for project! X: Only 1 developers signed up for project! rox: Only 1 developers signed up for project! metastructure: Only 1 developers signed up for project! SELinux: Only 1 developers signed up for project! Documentation: Only 1 developers signed up for project! Gentoo/x86 Arch Testers: Only 1 developers signed up for project! gentoo-alt: Only 1 developers signed up for project! nbsd: Only 1 developers signed up for project! Gentoo/Alt ATs: Only 1 developers signed up for project! planet: Only 1 developers signed up for project! adopt-a-dev: Only 1 developers signed up for project! gmn: Only 1 developers signed up for project! Kernel: Only 1 developers signed up for project! Auditing: Only 1 developers signed up for project! planet: Only 1 developers signed up for project! adopt-a-dev: Only 1 developers signed up for project! Common Lisp: Only 1 developers signed up for project! Gentoo Programming Resources: Only 1 developers signed up for project! Ada: Only 1 developers signed up for project! Kolab: Only 1 developers signed up for project! You will find the complete log at [1]. The script that generated above logfile can be found at [2]. As usual, feedback is highly appreciated. Warm regards Thilo [1] Full project-checker.log http://dev.gentoo.org/~bangert/project-checker.log [2] Project Metadata checking script. http://overlays.gentoo.org/dev/bangert/browser/scripts/project-checker.rb signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] irregular metdata.xml check
Hans de Graaff said: > On Mon, 2009-12-07 at 12:56 +0100, Thilo Bangert wrote: > > Welcome to this years edition of the metadata check. > > > > dev-util/cucumbermissing > > Fixed, but this is really a bug in metadata.dtd, which specifies > upstream)* )> > > That should probably be: > > upstream)* )> > indeed: http://bugs.gentoo.org/show_bug.cgi?id=279206 > Kind regards, > > Hans > signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] irregular metdata.xml check
Ulrich Mueller said: > >>>>> On Mon, 7 Dec 2009, Thilo Bangert wrote: > > > > Welcome to this years edition of the metadata check. > > [...] > > > > You will find the complete log at [1]. > > Hmm, eselect is not known: > | unknown maintainer: esel...@gentoo.org > > But it's in good company: > | unknown maintainer: catal...@gentoo.org > | unknown maintainer: dev-port...@gentoo.org > | unknown maintainer: genker...@gentoo.org > | unknown maintainer: g...@gentoo.org > | unknown maintainer: portage-ut...@gentoo.org > | unknown maintainer: sand...@gentoo.org > | > > As usual, feedback is highly appreciated. > > Could you make your script recognise Gentoo hosted projects as valid > maintainers? are these availabe somewhere? AFAICT we dont have them systematically available... > > Ulrich > signature.asc Description: This is a digitally signed message part.
[gentoo-dev] irregular metdata.xml check
Welcome to this years edition of the metadata check. Todays fingerpointing herd without email: secure-tunneling herd without email: middle-east app-admin/eselect-audicleempty app-admin/eselect-chuck empty app-admin/eselect-miniaudicleempty app-admin/eselect-sndpeekempty net-im/minbifempty sys-kernel/dracutempty x11-libs/libvdpauempty x11-misc/vdpauinfo empty virtual/perl-Filter empty virtual/perl-i18n-langtags empty virtual/perl-Package-Constants empty virtual/perl-parent empty virtual/perl-Parse-CPAN-Meta empty app-office/homebank missing dev-libs/faxpp missing dev-libs/librelp missing dev-libs/ossp-uuid missing dev-util/cucumbermissing dev-util/hg-git missing games-rpg/sacred-goldmissing gnome-extra/gnome-color-chooser missing media-gfx/engaugemissing media-gfx/greycstoration missing media-plugins/gimp-greycstorationmissing net-dialup/dgcmodem missing net-irc/irssi-xmpp missing net-libs/udnsmissing net-misc/openswanmissing sys-apps/edac-utils missing Statistics == Total number of packages:13623 metadata.xml missing 0 missing 16 empty13 unknown 0 =no-herd1999 missing 8383 retired 0 is a herd1187 unknown 203 =maintainer-needed 715 Proxy maintainer without gentoo association10 Unmaintained packages 731 You will find the complete log at [1]. The script that generated above logfile can be found at [2]. As usual, feedback is highly appreciated. Warm regards Thilo [1] Full metadata-check.log http://dev.gentoo.org/~bangert/metadata-check.log [2] Metadata checking script. http://overlays.gentoo.org/dev/bangert/browser/scripts/check-metadata.rb signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Individual developer signing
> BTW: About a third of the Manifests are signed [1]. if we really want to get there, maybe repoman should give a _small_ warning, starting now. i dont sign my commits and have seen how my commits removed signatures of others. i am not proud of it - but given that these are apparently never checked in any way, then no harm is done... or what? Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] QA is unimportant?
Richard Freeman said: [good stuff] i share this sentiment. lets stay an open community and encourage learning. if somebody improves a package then that is a good thing. even if it could be improved even more. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] a pragmatic approach to FEATURES [was FEATURES use or misuse?]
[snip] > I understand PMS/paludis wishing to duck the vars existance to make it > go away, but I don't think it's a tenuable approach- as you yourself > said above, in trying to do this cleanup you recognized that sometimes > there was no alternative. yes - however, there not being an alternative at the moment does not automatically mean that FEATURES is a good or the best approach. A more clean approach still needs to be proposed. [snip] > > Rather then letting the problem persist, I'd rather see folk take a > look at FEATURES/PMS and identify what needs to be pushed in to take > care of the cases where there is no alternative to 'hasq some-feature > $FEATURES' rather then us just collectively sticking our heads in the > sand. yes - exactly. so which FEATURES are absolutely required in ebuilds / eclasses for which an alternative must be developed? > thanks for your input, BTW signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Init systems portage category
Victor Ostorga said:
> Lately I have stepeed into bug 216461 "init systems in sys-apps as well
> as in sys-process and even app-admin" and was about to moving
> sys-process/minit to sys/apps-minit , but stepped into bug 190982
> "move sys-process/{minit,runit} and app-admin/jinit to sys-aps" which
> is the same and closed WONTFIX in 2009-08-09 .
>
> I don't know the history about init systems category, but obviously is
> necessary to stablish a category into which init systems should live
> happy forever (sys-init ? app-init? foobar?).
>
i would stick all inits into sys-process - its not crowded in there and
"process" fits the init concept well IMHO.
generally i thought, we wanted to move stuff out of sys-apps, as its really
not a good description of what a package is about.
sys-apps/ucspi-tcp and sys-apps/ucspi-ssl could move to net-misc or
preferably net-libs. sys-apps/ucspi-proxy to net-proxy.
thanks
kind regards
Thilo
> Regards,
>
> Víctor.
>
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] FYI: use-based deps on virtuals
FYI -- Weitergeleitete Nachricht -- Subject: monkeyd-0.9.2-r1.ebuild Date: Monday 20 April 2009 From: Michael Sterrett To: bang...@gentoo.org use-based deps are undefined behavior on virtuals. So, in monkeyd-0.9.2-r1, please fix up the virtual/httpd-php[cgi] dep. Thanks. --- /me closes bug #280173. kthxbye signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Keeping profiles/ tidy
Samuli Suominen said: > Nirbheek Chauhan wrote: > > On Sat, Aug 1, 2009 at 7:32 PM, Petteri Räty wrote: > >> Nirbheek Chauhan wrote: > >>> This seems like something that should be added to the ebuild/end > >>> quiz. > >> > >> Ebuild quiz: > >> > >> 19. What is the procedure for removing packages from the tree? > > > > Looking back, my answer to that question was insufficient, so the > > answer needs to be fixed ;) > > 19. What is the procedure for removing packages from the tree? Do you > need to do something in profiles/ after removing? If yes, what would it > be? > and where is the answer documented? http://bugs.gentoo.org/show_bug.cgi?id=164130 > -Samuli
Re: [gentoo-dev] A new glep: Ebuild format and metadata handling
> glep55: See GLEP55. To summarize: The eapi is put into the file name so > that the package manager knows the EAPI (and thus how to handle this > file format). While it simplifies the eapi discovery this comes at a > high price as there is no reliable way to find and validate all ebuilds. i must have missed the last point in the previous discussions. could someone perhaps point me to a post explaining the "high price" part? or just repeat it here thanks kind regards Thilo
Re: [gentoo-dev] Re: How not to discuss
Richard Freeman said: > Ryan Hill wrote: > > I'm tired of playing, as I'm sure you are. So please, > > let's be quiet now, and let the big people talk. > > This is a public list designed to facilitate discussion of gentoo > software development. Anybody with something constructive to say is > more than welcome to speak up - particularly gentoo staff. the thing is though, nothing constructive is being said. people are going in circles. ciaran and co are pushing glep55 for reasons which they have stated gazillion of times and nothing new is coming about. other people dislike glep55 for various reasons, but they clearly fail at proposing a (better) alternative (a competing GLEP). while both parties claim thechnical superiority of their proposal, the difference is what amounts to the colour of a shed. the arguments used to support the respective superiority reflect that. please, please DO write a competing GLEP if you dislike GLEP55. it's late, but you might just make it... it is all too common in gentoo land to be against something. i want to see more people be in favor of (not necessarily the same) something. kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
Richard Freeman said: > AllenJB wrote: > > All that's going to happen is Gentoo will have many many buggy and > > out of date packages in the MAIN TREE. Exactly where they shouldn't > > be. You claim quality won't be sacrificed, but I simply can't see > > this without any attempt to solve the manpower issues first. > > > > Isn't the purpose of this project already somewhat covered by > > Sunrise? > > I have to agree with your points. We need to have quality standards > for packages. Currently we have a couple of tiers: > > 1. Main tree - every ebuild has an official maintainer and gets prompt > security updates/etc. New features might get a little more stale, but > you aren't going to be running at risk if you only use the main tree > and routinely emerge -u world. If a package falls behind on security > it gets masked and booted. > > 2. Overlays - you're on your own and at the general mercy of the > overlay maintainer. > > 3. Sunrise (just a special case of an overlay) - somewhere in-between. > Again, you have to opt-in. > AFAIK, we have never explicitly made this distinction clear. if we had, we would have to remove stuff from portage which doesnt live up to the standards. it is also not true from a more real world perspective: there are many packages in portage that have a standard which is much lower than what is in some overlays. and there are many packages in overlays which live up to a quality standard way above portage's average. if you want to exaggerate a bit, we have roughly 500 ebuilds in portage which are maintainer-needed and have only a few users and thats why you want to keep popular packages out of the tree? its weird, how this whole thing started with wanting to accomodate our users better and then other people come around and argue against it in order to protect our users... user who want protection run stable arch! given the current state of the tree, its hypocritical to be against this proposal, IMHO. however, one could try to implement the above quality standards, possibly by splitting up the tree. this issue, as well as some others very similar to this one, have come up many times before. I suggest we do something about it... (splitting the tree or moving more stuff wholesale into portage and have a better rating system... whatever) Fedora is a much more current distribution than Gentoo - and has been for a couple of years... regards Thilo > I think that we still need to have defined levels of quality, so if we > start putting unmaintained stuff in the main tree then we absolutely > need to preserve a mechanism for users to indicate what level of > quality they desire. Users running a typical install shouldn't > inadvertently have dependencies pulled in which aren't fully controlled > for security issues. > > Could something like sunrise be integrated into the main tree? Sure. > However, there would need to be lots of rules and QA checks like > non-sunrise packages not depending on sunrise packages and the sunrise > packages are somehow clearly marked. Maybe even an ACCEPT_QUALITY = > "good-luck-with-that" setting or something like that in make.conf. We > might also need tiered levels of security in cvs. I'm not convinced > that in the end it will be any better than just having those who are > interested add an overlay to their tree. > > Maybe a better option would be a way to make overlays more seamless. > Additionally we could have rating categories for overlays like > "security responsiveness," "currency with upstream," etc. The gentoo > project would ask overlays to declare their policies as a condition of > being accessible via the seamless interface, and would drop overlays if > they don't follow their policies. It would still be easy for users to > pick non-standard overlays but it would be clear that they are > venturing off on their own if they do this (just as is the case with > layman today). > > Sure, I'd love to see an extra 1000 supported packages in portage, but > the key is "supported", not just shoveled-in. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
Fabian Groffen said:
> On 11-05-2009 11:26:46 +0200, Thilo Bangert wrote:
> > FEATURE-misuse.txt was generated by
> > $ find -name '*.ebuild' | xargs grep -nH FEATURES >
> > FEATURES-misuse.txt and sifting through the false positives.
>
> Have you checked if eclasses use it as well?
nope - thanks for the pointer ;-)
bang...@marsupilami ~/gentoo/portage/eclass $ grep FEATURES *
db.eclass: if has test $FEATURES; then
eutils.eclass: has preserve-libs ${FEATURES} && return 0
eutils.eclass: has preserve-libs ${FEATURES} && return 0
gnatbuild.eclass: has noinfo ${FEATURES} \
gnatbuild.eclass: has noman ${FEATURES} \
java-utils-2.eclass:if hasq test ${FEATURES} && ! hasq -test
${FEATURES} \
java-utils-2.eclass:eerror "You specified FEATURES=test, but
USE=test is needed"
kmod.eclass:if [ "${FEATURES/sandbox/}" != "${FEATURES}" ]
mysql.eclass: if hasq test ${FEATURES} ; then
mysql.eclass: eerror "Testing with FEATURES=-
userpriv is no longer supported by upstream. Tests MUST be run as non-
root."
mysql.eclass: # Check FEATURES="collision-protect" before removing this
myth.eclass:FEATURES="${FEATURES} nostrip"
selinux-policy-2.eclass:if has "loadpolicy" $FEATURES ; then
selinux-policy-2.eclass:einfo "\"loadpolicy\" to the
FEATURES in make.conf."
selinux-policy.eclass: if has "loadpolicy" $FEATURES ; then
selinux-policy.eclass: einfo "\"loadpolicy\" to the FEATURES in
make.conf."
toolchain-binutils.eclass: if ! has noinfo ${FEATURES} ; then
toolchain-binutils.eclass: has noinfo ${FEATURES} && rm -r
"${D}"/${DATAPATH}/info
toolchain-binutils.eclass: has noman ${FEATURES} && rm -r
"${D}"/${DATAPATH}/man
toolchain.eclass:FEATURES=${FEATURES/multilib-strict/}
toolchain.eclass: eerror "of a multilib gcc. Please set
FEATURES=-sandbox and try again."
toolchain.eclass: die "No 32bit sandbox. Retry with
FEATURES=-sandbox."
toolchain.eclass: has noinfo ${FEATURES} \
toolchain.eclass: has noman ${FEATURES} \
(the above has been filtered for obvious false positives)
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
a list cleaned for obvious false positives leaves the following 44 affected
packages.
i have treated ebuilds which mention FEATURES in an ewarn or einfo as
false positives although they probably should be fixed as well.
most of these have do one of the following (or a variant thereof)
hasq test $FEATURES
hasq distcc ${FEATURES}
hasq userpriv "${FEATURES}"
has nodoc ${FEATURES}
has noinfo ${FEATURES}
has noman ${FEATURES}
has collision-protect ${FEATURES}
hasq sandbox ${FEATURES}
has usersandbox ${FEATURES}
has "loadpolicy" $FEATURES (selinux-base-policy)
has livecvsportage ${FEATURES} (portage)
i'll start opening bugs for these:
bang...@marsupilami ~/gentoo $ cat FEATURES-misuse.txt | awk -F"/" '{print
$2"/"$3}' | sort | uniq
app-cdr/cdrdao
app-forensics/memdump
app-forensics/zzuf
app-text/dictd
dev-db/libodbc++
dev-db/mysql
dev-db/mysql-community
dev-db/postgresql
dev-db/postgresql-server
dev-db/sqlite
dev-java/commons-io
dev-java/rjava
dev-lang/fpc
dev-lang/mono
dev-libs/boost
dev-libs/klibc
dev-libs/openssl
dev-libs/poco
dev-python/logilab-common
dev-python/pyqwt
dev-scheme/bigloo
dev-util/cvs
dev-util/git
dev-util/mercurial
dev-util/monotone
gnome-base/eel
mail-mta/courier
media-sound/line6usb
media-tv/mythtv
media-video/avidemux
net-analyzer/tcpreplay
net-misc/l7-filter
sci-libs/hdf5
sec-policy/selinux-base-policy
sys-apps/dbus
sys-apps/mlocate
sys-apps/portage
sys-cluster/mpich2
sys-devel/gcc
sys-fs/evms
sys-libs/cracklib
sys-libs/db
sys-libs/glibc
sys-power/iasl
FEATURE-misuse.txt was generated by
$ find -name '*.ebuild' | xargs grep -nH FEATURES > FEATURES-misuse.txt
and sifting through the false positives.
see it here http://dev.gentoo.org/~bangert/FEATURES-misuse.txt
kind regards
Thilo
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
Ben de Groot said: > Thilo Bangert wrote: > >> Welcome to Gentoo. > > > > nice attitude... > > i am sure that'll make the problem go away :-( > > What do you expect? He's an exherbo dev, only here to criticize Gentoo > and gloat over its perceived failings. and what exactly are _you_ contributing? i was trying to point out, that somebody was rather unhelpful, and all you can come up with is being unhelpful? we can do better than that! same goes to some other people in this thread... ..now back to the topic! Thanks Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development (was: Re: Retiring)
Nirbheek Chauhan said: > On Sun, May 10, 2009 at 5:19 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > Thilo Bangert posted > > 200905101051.43926.bang...@gentoo.org, excerpted below, on Sun, 10 > > May > > > > 2009 10:51:38 +0200: > >> also, i feel voting for bugs is completely underutilized. votes make > >> it apparent to the developers which bugs bug a lot of people. the > >> incentive to fix those first is there... > > > > I know I've never use the bug vote feature, partly because I simply > > forget it's there now, and partly due to confusion from seeing the > > earlier rants against it. Such confusion makes for pretty strong > > negative conditioning. > > Also, most people I know use CCing-frequency as a measure of how many > people are facing a particular bug, and what importance level to > assign to it. Votes only cause unnecessary noise and irritation -- > worse than "me too!" comments. the number of people CC'ed to a certain bug is a good measure as well - however, i cant sort on that in bugzilla. also, i may have experienced a particular bug (and CCed to it), but its not a big deal to me. voting allows for a much more fine grained user preference in that case. a user only has 100 votes and can spend max 10 votes on a single bug - you can CC to as many bugs a you want. "me too" is an important information on a bug and between a comment, a CC and a Vote i prefer the votes... Thanks Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
> > There's a crapload of stuff in the tree doing
> > things like this and worse with FEATURES.
there is roughly 150 packages using FEATURES (including a number of false
positives). see the list below...
FEATURES variable is used in the tree
http://bugs.gentoo.org/show_bug.cgi?id=174335
>
> Welcome to Gentoo.
nice attitude...
i am sure that'll make the problem go away :-(
bang...@marsupilami ~/gentoo/portage $ find -name '*.ebuild' | xargs grep -
nH FEATURES | awk -F"/" '{print $2"/"$3}' | sort | uniq
app-editors/emacs
app-editors/emacs-cvs
app-editors/le
app-forensics/memdump
app-forensics/zzuf
app-shells/bash
app-text/dictd
dev-ada/polyorb
dev-db/libodbc++
dev-db/mysql
dev-db/mysql-community
dev-db/postgresql
dev-db/postgresql-server
dev-db/sqlite
dev-dotnet/smartirc4net
dev-haskell/alex
dev-haskell/alut
dev-haskell/arrows
dev-haskell/binary
dev-haskell/bzlib
dev-haskell/c2hs
dev-haskell/cabal
dev-haskell/cabal-install
dev-haskell/cgi
dev-haskell/cpphs
dev-haskell/editline
dev-haskell/fgl
dev-haskell/filepath
dev-haskell/frown
dev-haskell/ghc-paths
dev-haskell/glut
dev-haskell/haddock
dev-haskell/happy
dev-haskell/harp
Re: Training points for users interested in helping out with ebuild development (was: Re: [gentoo-dev] Retiring)
Olivier Huber said: > Hi, > > 2009/5/4 Thomas Sachau > > >[snip] > > For those, who can work with IRC and are interested in working with > > ebuilds, there is already an option: > > > > Join #gentoo-dev-help or even better #gentoo-sunrise and read the > > documentation from the topic. The Sunrise Overlay (with the > > #gentoo-sunrise IRC channel) is open for everyone willing to learn > > and contribute to it. Even normal users can get access, learn how to > > create ebuilds, how to improve them and how to maintain them. > > As a starting point, this is a central overlay, where ebuilds are > > maintained, that dont get a developer as maintainer because of > > missing manpower. Additionally, all contributors learn the ebuild > > development work themselves. > > I think these are really good advise but I think we could improve the > way users can help concerning maintainer-needed packages. > dirtyepic made a funny entry on his blog [1] and darkside tried also > to do something [2], but it seems to me that this alias is a black > hole. For instance, the last bugday I tried to close some bugs. Some > one them were assigned to maintainer-needed@, > so I said on #gentoo-bugs that I've updated those bugs. Sometimes, a > dev was watching and the issue was closed, but for others I have still > no comments (Ok. I'm too impatient, but I'm not really confident. But > some devs can still surprise me ;-) ) > > I fully understand that looking at this type of bug is hard and > boring. On the other hand, I know some devs who are willing to help > and check patches. Since I don't think it would be a good practise to > savagely CC' them, I propose to add a bug-with-patch alias or > something like that. many devs go through maintainer-needed bugs from time to time. i think the easy ones will get comitted fairly fast. instead of a bug-with-patch alias, i think a _easyfix_ alias could be more helpful. it could also be used by package maintainers, which dont have the time to do the _easyfix_ (rename version bump etc.) sometimes the issue appears really simple, but it reallly isnt. in that case it would be nice, if it were deduceable from the bug, why no progress is being made. also, i feel voting for bugs is completely underutilized. votes make it apparent to the developers which bugs bug a lot of people. the incentive to fix those first is there... regards Thilo > > Cheers, signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
Ciaran McCreesh said: > On Tue, 5 May 2009 21:19:49 +0300 > > Markos Chandras wrote: > > We surely need more developers. Otherwise we ll end up maintaining > > 100 > ACTIVE developers ). So first we need to attract more people. > > Evaluation and recruitment comes next > > I have a better way of improving those numbers: remove two thirds of > the packages from the main tree. to me, the above two contradictory viewpoints are the essence of the apparent and real decline in Gentoo activity. The two are just not compatible with each other and there is no clear guidance on to which of the two should be followed. in the one corner we have the 'Daniel Robbins' corner, which stands for an open and inclusive process, which favors new comers, wants fast progress regardsless of the technical limitations of that process. also, being nice is more important than being correct. one central repository is where all development should happen - this is were we came from. in the other corner is the gentoo leftover of the exherbo fork: the few people how continue to work on Gentoo but generally prefer the direction of Exherbo. technical elitism, explicitism and formal standardization are their trade. being correct is more important than good intentions. overlays or multiple repositories help achieve a hierarchy of not-good-to- supported ebuilds. we are halfway here... it would be good if we collectively could agree on some of these issues, in order to move forward. as with many of the other technical discussions which lead to nowhere, it's more important that there is a clear direction, than into which direction we are headed. maybe we need a debian project leader position - or a council, which is sensitive to the internal devide among developers and gives clear directions. if the above offends you, please take a walk before replying. it may sound inflammtory - its not meant to be. thanks Thilo
Re: [gentoo-dev] Real multilib support for Gentoo
"Santiago M. Mola" said: > On Sat, Apr 4, 2009 at 2:59 PM, Thomas Sachau wrote: > > Hi folks, > > > > > > i would like to hear about other opinions about real multilib support > > within our tree and package managers. From what i know, there are > > mainly 2 different ideas: > > The proposals are not exactly these. > > 1. Make package managers multilib-aware [1][2]. > > Package managers would be able to have a default ABI (say, x86_64) and > optional ones (x86). Everything would be built for the default ABI, > and the package manager could build things for optional ABIs on an as > needed basis. That is, if I install a 32bit binary package, the > package manager will build any 32bit libraries it needs automatically. > > Package managers will have to expose to ebuilds a mechanism to iterate > over enabled ABIs and build anything needed for each one. > > Pros: > - Any package can be made multilib aware, getting rid of the emul-* > packages. - 32bit libraries are built automatically and as needed. > - This system can be extended to support other kind of ABIs. Making it > possible to build packages for various versions of Python/GHC/etc > simultaneously. > > Cons: > - Needs to be implemented on the PM-side and needs a new EAPI. > > 2. Implement multilib on the ebuild level. > > For amd64, this would mean adding a 'lib32' USE flag to every multilib > ebuild, and use it for building 32bit libs as needed. > > Pros: > - Any package can be made multilib aware, getting rid of the emul-* > packages. - Doesn't need PM changes. > > Cons: > - Package manager won't be multilib-aware, so it won't be able to > build 32bit libraries automatically and as needed. > - Users will have to enable 'lib32' USE flag manually for every > library they needed. Enabling 'lib32' by default is not an option > since it would build tons of unneeded 32bit libraries for every user. reading the proposals so far, it sounds to me that only the one that requires pms changes would qualify as 'real multilib support'. > > > [1] http://dev.exherbo.org/~pioto/abi-ideas.html > [2] http://bugs.gentoo.org/show_bug.cgi?id=145737 > > Regards, signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
> 'guess'. Like how you have to guess what use flags are really being > used for the package in question, because it doesn't tell you? i'd like to ask the developers of package managers to standardize this. having --info be the same no matter who you like best is incredibly usefull. while we are at it, emerge --info output may or may not be made even more usefull... thanks Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: EAPI roadmap
Serkan Kaba said: > Thilo Bangert yazmış: > > i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont > > expect to have en EAPI=2 capable package manager stable within a > > reasonable timeframe. > > 2.1.6 is stable and supports EAPI2 thats pretty cool. thanks...
EAPI roadmap (was: Re: [gentoo-dev] RFC: Deprecating EAPI0)
Peter Alfredsen said: > On Sun, 22 Mar 2009 09:41:58 +0100 > > Matti Bickel wrote: > > A general question, that just popped into my head when i was reading > > this: if i touch a ebuild which has EAPI=0, should i bump it to > > EAPI=2? > > Only if you take the time to read through it and test that your revised > ebuild will have the same functionality as the old one. That's why I > wrote "when a new ebuild...". This should not be an automated thing, > but rather a part of the basic bump-adjust-test maintenance cycle. > while i agree with what you say here, it is also important to take the general EAPI roadmap into account. as we currently dont have one AFAIK, we should make efforts to agree on one soon. i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont expect to have en EAPI=2 capable package manager stable within a reasonable timeframe. as it really doesnt matter what i think, when portage-2.2 should go stable i will not bore you with that, however, given that only portage 2.2 supports EAPI=2 it is relevant for the discussion of an EAPI roadmap. in light of the current EAPI usage statistics, i would propose to deprecate EAPI 1 (and 2) much earlier than EAPI 0. regards Thilo > /loki_val
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
> > I think that summarizing "IRC" is insane. and there is no need for it either. as stated elsewhere much of what is going on on IRC is 'goofing off' - for which IRC is excellent. (heck - i should goof off more often :-) i dont mind the day-to-day work stuff going on on IRC exclusively - but when discussions about the future directions of a project and the decision making process are held on IRC exclusively, then that is not helpful in attracting new blood. for one because there is no history but also because they may not use IRC that much. > Remember we barely got > summaries of council meetings (which are at a fixed time and date) > until we got a secretary devoted explicitly to that task. > Maybe more > teams should take up the meeting model; that way non-IRC folks can > either be on IRC for meeting times only, or peruse the meeting notes > afterwards if they are interested in what happened. yeah - the kde team is leading the way here. granted - this model may not work for everybody... regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
Donnie Berkholz said: > On 19:06 Wed 11 Mar , Thilo Bangert wrote: > > > > the presumption seems to be, that as a dev one has to be > > > > available via IRC. it has long been my feeling that Gentoo as a > > > > project could realize more of its potential by better integrating > > > > people who dont do IRC. > > I think IRC helps to build a more tightly knit community and, because > of this, is very important to Gentoo. The less close we are as a > community, the more free we feel to be hostile because we don't see the > folks on the other end of the big tube as real people. It's much like a > technique that militaries use during wars to de-personalize the enemy, > except with the Internet, we start that way and have to apply effort to > grow closer. so you say, that presumption is ok? i agree 100% with what you say, but it doesnt (at least directly) address my concern. i think IRC is an excellent medium - the problems i see, though, are related to the fact that IRC requires all stakeholders to be available at the time of discussion. for a multitude of reasons this can almost never be guaranteed. also, even if we did have IRC logs, the signal to noise ratio on IRC is devastating (at least in my experience). for those reasons, i would like to see more bridge-building between the worlds. i didnt want to give examples, as i dont like pointing fingers, but here it is: relengs discussion to switch to weekly autobuilds. presumably there hast been one, but i cant find it in the list archives. not on gentoo-...@g.o and not on gentoo-rel...@g.o - where else should i look? IRC perhaps - well, where are the logs? interestingly, the announcement of the switch has a pointer to the releng project page, which does not even mention the IRC channel. from looking at the releng mailing list one gets the impression that releng in gentoo is dead. its not - i know and am greatful for the hard work everybody in releng puts in - but it makes the releng project much less accessible. to follow, or contribute. thanks for listening kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to speed up maintenance and other Gentoo work?
one thing that could perhaps speed up gentoo is specifying at what point or what steps are required before it is ok to "step on others toes". we have the QAcanfix keyword, for bugs where QA "threatens" to just fix the bug if the maintainer doesn't react timely... but it appears to be the tree could generally move faster, if there was an agreement as to when somebody is allowed to fix another maintainers stuff. if we had a formal process in place, one could always execute on that and fix the issue oneself, instead of having the cheap excuse of "well, hasnt fixed bug xxx yet, so i cant move". this process should ideally be very lean and short - as to not discourage these type of changes. kind regards Thilo
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
Markos Chandras said: > On Tuesday 10 March 2009 14:15:36 Thilo Bangert wrote: > > > Bugs aren't a good way to keep in touch with developers, that's > > > what irc is for. > > > > while i dont necessarily think, that bugzi is the best way to stay in > > contact with me, it surely is a better way than IRC - on which i am > > close to never. > > > > the presumption seems to be, that as a dev one has to be available > > via IRC. it has long been my feeling that Gentoo as a project could > > realize more of its potential by better integrating people who dont > > do IRC. > > > > kind regards > > Thilo > > To be honest , I don't agree with that. Being around on irc is quite > helpful to get direct feedback from users and fix bugs before they hit > more users. This is a good way to reduce the amount of bugs that hit > bugzilla. my complaint isn't about people using IRC. i object to the way that much of our knowledge, discussion and decision making process appear to have been moved into the temporal black hole that is IRC. realtime communication is an valuable tool, but IRC has drawbacks as well. this is alienating a lot of people who dont happen to be on IRC at the right moment/timezone or who dont have the time to be always on. it looks like many projects within Gentoo have resorted to a communication process which uses IRC exclusivly. this is unfortunate... kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
> Bugs aren't a good way to keep in touch with developers, that's what > irc is for. while i dont necessarily think, that bugzi is the best way to stay in contact with me, it surely is a better way than IRC - on which i am close to never. the presumption seems to be, that as a dev one has to be available via IRC. it has long been my feeling that Gentoo as a project could realize more of its potential by better integrating people who dont do IRC. kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] when the music's over
> Goodbye all you people > There's nothing you can say > To make me change my mind > Goodbye O babe, Dont leave me now. Dont say its the end of the road. Remember the flowers I sent. I need you, babe, To put through the shredder in front of my friends. Oh babe, Dont leave me now. How could you go? When you know how I need you, To beat to a pulp on a saturday night. Oh babe, Dont leave me now. How can you treat me this way? Running away. Oh babe, Why are you running away? -- thanks for the reminder. :-) good luck in your endeavours. regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Thanks Petteri, > > 1) Status quo > - does not allow changing inherit > - bash version in global scope > - global scope in general is quite locked down lets move on! > > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild- > - ignored by current Portage > b) ..ebuild > - current Portage does not work with this > c) .. > - ignored by current Portage 2 a) and 2 c) are fine by me. > > 3) EAPI in locked down place in the ebuild > - Allows changing global scope > - EAPI can't be changed in an existing ebuild so the PM can trust > the value in the cache > - Does not allow changing versioning rules unless version becomes a > normal metadata variable > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked > a) > b) new subdirectory like ebuilds/ > - we could drop extension all together so don't have to argue about > it any more > - more directory reads to get the list of ebuilds in a repository > c) .ebuild in current directory > - needs one year wait no thanks. > > Regards, > Petteri regards Thilo
Re: [gentoo-dev] prepalldocs is now banned
Thomas Anderson said: > Hi Everyone, > > This is a note that in the council meeting on 02/12/2009 the > function 'prepalldocs' is banned for use in ebuilds with EAPIs 0 1 > and 2. If you want some functionality from this function, please > propose a new function or clearly defined behavior for prepalldocs > for a *new* EAPI. we have a tracker bug at: http://bugs.gentoo.org/show_bug.cgi?id=259422 the following 99 packages currently still use 'prepalldocs'. some time in the near future i will start filing individual bugs for each of these. feel free to beat me to the punch. thanks kind regards Thilo app-arch/gtk-splitter app-arch/rar app-arch/xdms app-backup/amanda app-cdr/cdcover app-crypt/gnupg-pkcs11-scd app-crypt/steghide app-doc/howto-text app-doc/phrack app-emacs/ess app-misc/ca-certificates app-misc/emelfm2 app-misc/g15daemon app-misc/g15macro app-misc/g15message app-misc/g15mpd app-misc/g15stats app-office/gnucash app-text/htag app-text/robodoc app-text/sloccount app-text/ttf2pt1 dev-db/myodbc dev-db/mysql++ dev-db/unixODBC dev-embedded/sdcc dev-embedded/uisp dev-games/flatzebra dev-lang/gpc dev-libs/libg15render dev-libs/libgringotts dev-libs/libmcrypt dev-libs/pkcs11-helper dev-libs/ppl dev-python/gst-python dev-python/yolk dev-tcltk/mysqltcl dev-tex/cjk-latex dev-tex/frakturx dev-util/anjuta dev-util/geany dev-util/ltrace dev-util/pretrace games-arcade/afternoonstalker
Re: [gentoo-dev] Automatic filing of stable requests
Donnie Berkholz said: > On 05:10 Sun 14 Dec , Petteri Räty wrote: > > I added support for filing stable requests directly from my stable > > candidate RSS feed. > > For those that don't read planet Gentoo the feed can be found here: > > http://gentoo.petteriraty.eu/stable.rss > > > > Now what do people think about extending metadata.xml so that you > > could have these > > bugs filed automatically when there are no open bugs? Something like > > a > > element with the DTD setting the default as true and you could just > > use a shorthand. good idea. > > I'm all for it. It would need to take version restrictions -- for > example, I may be willing to have xorg-server 1.5.x go stable but not > 1.4.x. perhaps auto-stable should be the default (not needing the tag), only allowing things to be masked from it. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
"Robin H. Johnson" <[EMAIL PROTECTED]> said: > On Sun, Oct 19, 2008 at 12:32:44PM -0700, Alec Warner wrote: > > What if my herd email address is different from my bugzie address? > > Can I have both in herds.xml? What if my herd address *isn't* a > > bugzie account, will the world end? > > I don't know any herd where the herd email is not the same as the > bugzie email. Why would this case arise anyway? The mail aliases reside > on dev, and the duplication doesn't make sense. the gentopia guys seem to have this annoying scheme: herd email is [EMAIL PROTECTED] while bugzi account is [EMAIL PROTECTED] > > > How can we automatically detect when developers make mistakes in > > editing herds.xml? > > There is a validation CGI in Bugzie, I created it for when somebody (I > forgot who) was checking all of the metadata and herd emails > previously, which we should probably automated. for me. i have started using it today.. thanks! > > > > 1. For handling no-herd, we should add an entry into > > > herds.xml to catch it (maintainer-needed g.o). Every herd > > > listed in an ebuild MUST be in herds.xml. > > > > You and I both know this is not going to be true. Complicated > > solution; make Repoman do it. Certainly it is the 'correct' thing to > > do; however I don't expect it to get implemented or deployed quickly. > > Hacky solution: run script on osprey that tries to validate tree > > metadata against herds.xml and annoy herds who forgot to add > > themselves. > > Yes, automation is useful here. very few packages do not have a herd; no ebuilds have a wrong herd listed, but there are tons of other errors in our metadata... signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: net-mail/qmail-vmailmgr
# Thilo Bangert <[EMAIL PROTECTED]> (12 Oct 2008) # Masked for removal in 30 days (see bug #240371) # useless meta ebuild - never fully developed net-mail/qmail-vmailmgr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Ciaran McCreesh <[EMAIL PROTECTED]> said: > On Sun, 5 Oct 2008 03:44:20 -0700 > > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > > Either we need special cases to declare that it no longer has a > > homepage, or we need to allow the empty HOMEPAGE. > > HOMEPAGE="( )" HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/"; signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
"Robin H. Johnson" <[EMAIL PROTECTED]> said: > Hi folks, > > I'm doing some research on our usages of the $Header$ keyword in our > main CVS repo. > > The primary use-case that has been publicly stated before was for users > to be able to identify to developers what version of a given ebuild > they were using. > > Q: How much have you utilized the primary use case? > > Q: Are there any other use-cases you have and actively use? > > For evaluating existing uses of the primary case, I took a glance at > Bugzilla. There are 624 bugs total that contain a $Header$ with an > existing Gentoo path. At least 143 of those are for new packages or > version bumps (they copied existing ebuilds). it appears we have decided to keep the $Header$ keyword in ebuilds for now. however, what about removing it from the ChangeLog? kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Request for feedback on GNU Patch change
"C. Bergström" <[EMAIL PROTECTED]> said: > Fabian Groffen wrote: > > On 17-09-2008 10:41:07 +0200, "C. Bergström" wrote: > >>> By the way, I'm against this stuff. I rather see a PATH solution > >>> involved. Portage already has a DEFAULT_PATH, and if someone > >>> refuses to install patch, one could always use a special directory > >>> with symlinks to the g-versions, e.g. patch -> /usr/sfw/bin/gpatch > >>> such that Portage/eclass/ebuilds don't have to bother about this at > >>> all. > >> > >> patch is installed and I would agree with you, but in certain > >> circumstances using the GNU tools are broken. > > > > Then if that is the case, Portage/eclass/ebuild relies on that > > brokenness. I'm not saying you should have the same PATH as Portage. > > GNU tools always behaved as expected on Linux. The brokeness is > platform specific in my case. please, also make sure this gets fixed. thanks for your work kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Shall we create a ballot for PROPERTIES value definition proposals?
Zac Medico <[EMAIL PROTECTED]> said: > Hello everyone, > > Given the vast number of possible choices to consider when defining > new PROPERTIES values [1], perhaps we should create a ballot and > hold a vote on definitions that people have submitted. I suppose > that voters would be able to vote yes or no on each proposed > property definition and they would also be able to write in one or > more alternative names for the definition. I don't know what the > best method(s) to carry out a vote like this would be. Does anybody > have any suggestions? have the council sign of whatever compromise looks like it made it way through. the current process seems to work very well, me thinks. thanks for your effort, BTW. best regards Thilo > > Thanks, > Zac > > [1] > http://archives.gentoo.org/gentoo-dev/msg_e145fc04e907de72e30d88285afb1 >34c.xml signature.asc Description: This is a digitally signed message part.
OT: Precedence: bulk (was: Re: [gentoo-dev] Please don't use auto-responders on the lists.)
"Robin H. Johnson" <[EMAIL PROTECTED]> said: > Please do NOT use out-of-office, vacation or any other auto-responders > on the lists. It's bad list etiquette. decent vacation mail software ignores mail marked with a 'Precedence: bulk' header, as mailing list mail usually is (including mails sent by gentoo lists)... I wish somebody would finally write up a RFC for this. best regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] packages up for grabs
> > > net-misc/ntp > > This is rather basic, isn't it ? It keeps your clock accurate. > Is there any alternative ? net-misc/openntpd - by the OpenBSD folks... http://openntpd.org/ http://en.wikipedia.org/wiki/OpenNTPD regards Thilo signature.asc Description: This is a digitally signed message part.
OT: offensive (Re: [gentoo-dev] explicit -r0 in ebuild filename)
> Please think things through before asking to have pkgcore's bugs > 'fixed' via specification next time... maybe my english language skills or social interaction qualities are failing me, but i find the above sentence highly offensive. am i too thin skinned for gentoo-dev? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Help offered - Portage tree
> end up copying the ebuild from the tree into our overlay and fix. great! where is it? does it have a webvc or trac interface? thanks Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] One request for the next SoC: non already-devs students
> But I > sincerely think the main goal of Summer of Code is to allow new people > to enter the scene of Free Software, to understand how Free Software > projects work and so on. it's not just what you "sincerely think"! I most certainly think, you have a valid point. from http://code.google.com/soc/2008/faqs.html#0.1_goals: Google Summer of Code has several goals: - Get more open source code created and released for the benefit of all; - Inspire young developers to begin participating in open source development; - Help open source projects identify and bring in new developers and committers; - Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer (think "flip bits, not burgers"); - Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette). -- kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo Foundation Elections - Last Call for voting
"Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]> said: > Hi. > > As we've stated before and is listed on the election page[1], the > voting period lasts from 00:00.00 UTC February 14th (Thursday) to > 23:59.59 UTC February 28th (Thursday). Thus, there's little less than > 48 hours to cast your vote. > At the moment 24% of the eligible voters have submitted their > ballots[1]. > Vote now if you want to have an influence in the election. it's not just that. after the trouble of the last months, it would be great if the next trustees could feel confident about their mandate. it would also be a clear signal to our users, that we (the devs and former devs) feel these issues are important as well. if you dont care about the foundation, you can still vote 'dont care', by putting all candidates on the same line. by not voting at all you boycot the democratic nature of the foundation. it would be intersting to hear from all those who choose not to vote, why they did so - in order to address whatever concerns they may have in the future. likewise it may be interesting to hear from those who already voted. now, everybody vote! ;) here are the step-by-step instructions on how to vote (from the website): Eligible current Gentoo devs should login to dev.gentoo.org and run the following commands, in the order specified. - votify --new trustees2008 - This creates a new ballot in your homedir. - Edit the .ballot-trustees2008 file and rank the candidates. - Once you're sure, run votify --verify trustees2008 to check the validity of the ballot. - If that goes through fine, the next and final step is to submit your vote using votify --submit trustees2008 - In case you're stuck, detailed help can be accessed by using votify --help or feel free to drop by #gentoo-elections on IRC. If you think you are eligible to vote, but cannot, please contact one of the officials. - Grab a beer, have fun, sit back and enjoy the show..till we announce the results ;) The remaining Foundation members (ex-devs), should email their ballot to the 3 election officials, signing the mail with their gpg key. > > * [1] - http://www.gentoo.org/proj/en/elections/foundation-200802.xml > > For the election officials, > > -- > Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org > Gentoo- forums / Userrel / SPARC / KDE signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] irregular metdata.xml check - 3rd edition
"Robin H. Johnson" <[EMAIL PROTECTED]> said: > On Tue, Feb 12, 2008 at 10:01:16PM +0100, Thilo Bangert wrote: > > Noteworthy errors > > === > > herd without email: comm-fax > > Proxy maintainer without gentoo association 15 > > Two specific feature requests: > 1. Check that every email address has a bugzilla account. i'll look into it. a hashed list of gentoo.org bugzilla accounts would definitivly help! just the query is a good start though - i suppose (lets try that first). the script runs a couple of minutes anyway - if that doubles, triples or quadruples its not a problem... > 2. Check that metadata with a proxy maint also has a non-retired Gentoo > person listed. 'Proxy maintainer without gentoo association' means 'there is neither a herd nor a gentoo maintainer listed'. you want to require a maintainer? a lot more ebuilds will fail this check... one may actually want to restrict that even further, and require both a herd and a maintainer, as to define a pool of backup people in case the gentoo maintainer retires. thanks! kind regards Thilo signature.asc Description: This is a digitally signed message part.
[gentoo-dev] irregular metdata.xml check - 3rd edition
Welcome to the third edition of the irregular metadata.xml check. Noteworthy errors === herd without email: comm-fax herd without email: dev-tools herd without email: haskell herd without email: common-lisp herd without email: secure-tunneling herd without email: ia64-kernel herd without email: middle-east herd without email: arm herd without email: s390 herd without email: sh net-misc/netcomics-cvs retired maintainer net-wireless/gnome-bluetoothretired maintainer sys-devel/distcc-config retired maintainer x11-plugins/gkrellm-countdown retired maintainer dev-util/crossvc empty app-emulation/virtinst missing dev-dotnet/dbus-glib-sharp missing dev-dotnet/dbus-sharpmissing dev-libs/dclog missing dev-util/cmt missing dev-util/osdtmissing mail-filter/dovecot-antispam missing mail-filter/dovecot-dspammissing media-libs/capseomissing media-libs/libcapturymissing media-video/captury missing media-video/undvdmissing net-fs/wdfs missing net-irc/mistbot missing net-misc/goog-sitemapgen missing net-misc/ng-utilsmissing net-misc/s3cmd missing sys-auth/nsvsmissing sys-fs/encfs missing sys-fs/flickrfs missing sys-fs/fuse-python missing sys-fs/python-fuse missing sys-fs/zfs-fuse missing sys-kernel/kerneloopsmissing Here are the stats summarising the current state of metadata in the tree. Statistics == Total number of packages:12410 metadata.xml missing 0 missing 24 empty 1 unknown 0 =no-herd1929 missing 7287 retired 4 is a herd1285 unknown 256 =maintainer-needed 556 Proxy maintainer without gentoo association 15 Unmaintained packages 717 You will find the complete log at [1]. The script that generated above logfile can be found at [2]. As always, feedback is higly appreciated. Warm regards Thilo [1] Full metadata-check.log http://dev.gentoo.org/~bangert/metadata-check.log [2] Metadata checking script. http://overlays.gentoo.org/dev/bangert/browser/scripts/check-metadata.rb signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The return of the old fart: Mark Loeser (halcy0n)
hip hip hurray for the old fart(s) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New USE flags documentation
Jeroen Roovers <[EMAIL PROTECTED]> said: > On Sat, 24 Nov 2007 15:10:58 +0100 > > Thilo Bangert <[EMAIL PROTECTED]> wrote: > > the idea is really great > > > > [...] > > > > now this needs to be [...] made mandatory for all ebuilds. > > Uh, what? > > Why? If the idea is that great, then why does it need to be mandatory? This is one more way the maintainer can document the functionality of the ebuild. IMHO this documentation is so usefull that every ebuild should provide it. see the recent blogpost by nichoj http://technicalpickles.com/posts/pidgin-idle-time which supports this reasoning. regards Thilo > > > Kind regards, > JeR signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] packages.gentoo.org lives!
> On the subject of Squid, it would be extremely useful if it could > ignore some headers and respect others in figuring out if the page is > already in the cache, without stripping the headers from the request > (it is doable with Apache's mod_cache), so that two requests with only > a slightly different User-Agent between them hit the same cache entry, > while different Accept* headers are respected, adn don't hit the same > cache entry? have you looked at www-servers/varnish - appears to be the new kid on the block for this kind of stuff (http acceleration that is)... the stuff you mention seems to be pretty trivial to setup in varnish. (including rewrites of old style URLs - if i am not mistaken). kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ranged licenses
Ciaran McCreesh <[EMAIL PROTECTED]> said: > On Wed, 28 Nov 2007 20:06:46 +0100 > > Christian Faulhammer <[EMAIL PROTECTED]> wrote: > > > One thing that would need to be decided: > > > > > > LICENSE="GPL-2" > > > > > > Would that require an = prefix? To simplify things, we could say > > > that *only* the postfix [] form counts for licenses... > > > > To have backwards compatability...yes. > > Backwards compatibility isn't necessary over an EAPI bump. The question > is whether it's sufficiently useful that having inconsistent parsing > rules for dep specs and license specs is acceptable. perhaps its really a matter of how often this would be used. for a span of three license versions, i'd prefer unranged notation as it's more easily read (opfer's argument). /usr/portage/licenses seems to carry but a handfull of licenses with more than three version numbers. ranged version numbers OTOH are used much more often... there is also the legal argument. it's better to state explicitly which versions apply and not have to cleanup the mess, when somebody decides to release GPL-2.5. kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New USE flags documentation
> While planet is a good medium to share ideas and get contributors, > seems to me like we need a more official way to discuss this kind of > 'global' ideas before make them real. Or at least drop a note on > -dev-announce explaining the new feature and telling devs and users > this is now officially supported. yoswink, thanks for bringing the discussion to gentoo-dev - i was not aware of such an effort. > Is the feature ready to be used? Is there any kind of documentation > (aside of DTD)? It will replace use.desc? the idea is really great IMHO and the implementation is pretty straight forward. thanks to flameeyes and cardoe for putting their heads together. now this needs to be extended and made mandatory for all ebuilds. in order to reduce the workload the global useflags should only be documented once - while still allowing ebuilds to extend (or even override?) the global description. great stuff all around. happy hacking Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] stripping out the DO NOT REPLY from bugzie emails
Andrew Gaffney <[EMAIL PROTECTED]> said: > It seems that not everybody loves the new "DO NOT REPLY TO THIS EMAIL" > header at the top of every bugzie email as much as robbat2 does. 1. if everybody hates it (full ack btw), why not remove it globally? 2. why doesn't bugzi receive mail (anymore?)? kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] "Trivial" commit reviews
i am all for the 'trivial' review. as i am not on the commit list, however, i can't tell whether this acutally helps. do people fix the stuff that is pointed out to them? also, perhaps the more common ones should additionally be converted to repoman tests, if that is feasable. kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] iuse defaults example
Mike Frysinger <[EMAIL PROTECTED]> said: > On Tuesday 10 July 2007, William Hubbs wrote: > > On Mon, Jul 09, 2007 at 11:26:19PM +0100, Ciaran McCreesh wrote: > > > As for IUSE defaults... There were objections against that feature > > > on the grounds that it's unnecessary and increased maintenance. Do > > > they really offer any benefit over package.use? > > > > Would iuse defaults not be appropriate when a certain use flag is > > recommended as the default for most users for a package?? > > other examples that make sense and are a pain with package.use: > - local USE flags (suddenly not so local huh) > - local USE flags and changing names > - defaults based on version (feature sucked <= 1.x and then rocked >= > 2.x) - developing new ebuilds for personal use > - developing new ebuilds for merging into tree (btw: need to update - we could finally kick all the no* USE flags. USE flags are use flags - they determine what should be used. not what should not be used... /usr/portage/profiles $ grep :no use.local.desc | wc -l 87 Thilo pgpCq4ecWgN3q.pgp Description: PGP signature
OT: gentoo-kindergarten (was: Re: [gentoo-dev] [RFC]: gentoo-politics ML)
I want a gentoo-kindergarten list, where useless discussions like this (sub)thread can be directed to. kids, grow up! pgpJFDJFTgIVf.pgp Description: PGP signature
[gentoo-dev] irregular metdata.xml check
Hi all, welcome to the second issue of the irregular metadata.xml check. Did you know that only 16% of all packages in the tree do not belong to any herd (ie. no-herd). Nevertheless, as no-herd is not a nice place to be, perhaps your herd can adopt a package or two. If you get really lucky you even get a dev with the deal - for free! Herds with no email === As robbat2 points out, in order to allow for automatic bug assignment all herds need to have an email address. The following herds do not have an email address specified in herds.xml. herd without email: comm-fax herd without email: dev-tools herd without email: haskell herd without email: common-lisp herd without email: secure-tunneling herd without email: ia64-kernel herd without email: middle-east herd without email: arm herd without email: lang-misc herd without email: s390 herd without email: sh Statistics == Total number of packages:11684 metadata.xml missing 0 missing 2 empty 0 unknown 0 =no-herd1887 missing 6611 retired 0 is a herd1300 unknown 201 =maintainer-needed 438 Proxy maintainer without gentoo association13 Unmaintained packages 602 As always, the full metadata-check.log is available from [1]. The script used to generate the log can be found at [2]. Feedback welcome. Kind regards Thilo [1] Full metadata-check.log http://dev.gentoo.org/~bangert/metadata-check.log [2] Metadata checking script. http://overlays.gentoo.org/dev/bangert/browser/scripts/check-metadata.rb pgp3vzg6mRCqm.pgp Description: PGP signature
Re: [gentoo-dev] [v2] Planning for automatic assignment of bugs
> Step 2 - Metadata.xml contains only a herd
> --
> 1. Take the herd element, and look up the herd in herds.xml to convert
>to an email address. This email address must be a valid bugzilla
>account.
> 2. This email is treated as an implicit maintainer element after this
>point. "${HERD_EMAIL}"
>
What about no-herd? Does that expand to
[EMAIL PROTECTED]?
Should it be added to herds.xml?
I'd be all for the expansion. Consequently all ebuilds with metadata
no-herd and
[EMAIL PROTECTED]
could be reduced to just no-herd...
> Step 3 - element
> -
> 1. Add the maintainer element to an ordered list, in the order they are
>present in the file.
> 2. If an element appears more than once, the later element overrides
> the earlier element. (This provides a route when the herd is assigned,
> but does not wish to receive email for a specific package). 3. If a
> maintainer element contains the 'ignoreauto=1' attribute AND a
> non-empty role element (describing why this maintainer should not be
> contacted), delete it from the list.
What about [EMAIL PROTECTED]?
And the case with no maintainer and no-herd?
Those would be resolved by the no-herd expansion proposed
above.
>
> Notes/Changes from before:
>
> - The herd element is always used.
> - The 'contact' attribute is now called 'ignoreauto'.
nice!
> - The 'ignoreauto' is the logical opposite of the original 'contact'
> attribute.
> - The 'ignoreauto' attribute defaults to false.
> - Any usage of the 'ignoreauto' attribute requires the role element to
> be present.
> - Herds that do not wish to be contacted for specific bugs should add a
> maintainer element stating that (and use 'ignoreauto' on the
> element).
IMHO at least one herd should always be (at least) CC'ed (unless
no-herd is the only herd) - in order to guarantee that a
group is being notified about the problem.
Or put differently: if an ebuild is part of a herd, but the herd doesn't
want to know about it, why is ebuild part of the herd in the first place?
> - Category level metadata.xml is now used for fallback if
> this is a bug about a new package in an existing category.
> - Category level metadata.xml may contain herd and maintainer elements.
By allowing elements in category metadata we possibly create
another (very weak) group maintainership. Is there a specific reason to
allow more than ?
Thanks.
Kind regards
Thilo
pgpxulkMsBDop.pgp
Description: PGP signature
Re: [gentoo-dev] irregular metdata.xml check
"Robin H. Johnson" <[EMAIL PROTECTED]> said: > On Wed, May 23, 2007 at 07:49:43PM +0200, Thilo Bangert wrote: > > Also, many ebuilds put the herds email address as an additional > > . This is simply redundant and unless complaints are > > raised, all herd tags will be removed and replaced by > > the appropriate tag instead. Work on this will start over the > > weekend. > > No. > > See the thread about automatic assignment for more about this. > More importantly, once the automatic stuff goes into play, the > existence of the herd tag will only matter on metadata that does not > have any other maintainer. sorry - to have missed this earlier. from your proposal: >Case 2 - Metadata contains a single maintainer >-- > The herd field is not used. so, you want to ignore the herd tag, as soon as there is a single maintainer tag? why? we have on every single package in the tree (well ~1900 packages with no-herd). my guess is that most of the roughly 4500 packages that currently have a and a which is not a , will need to adjust their metadata to reflect the situation where the maintainer should get the bug asssigned and the herd gets CC'd... IMHO the herd should always get an email on bugs with packages belonging to the herd... if this is not the case, what is the purpose of the herd? or asked differently: what can the herd in give you that the can't? other than that i (still) agree with the overall proposal. lets just make sure to codify the policy which has been agreed upon... regards Thilo pgp9fOV1ObYKO.pgp Description: PGP signature
[gentoo-dev] irregular metdata.xml check
Hi all, welcome to the IMC - irregular metdata.xml check, issue 1. As can be seen from the statistcis below, the herd tags have been fixed. Thanks to those who have helped with the cleanup. Whats next? == The current policy in the devmanual demands a maintainer tag - nevertheless half the tree is without it. The policy should perhaps be changed to reflect the reality. Also, many ebuilds put the herds email address as an additional . This is simply redundant and unless complaints are raised, all herd tags will be removed and replaced by the appropriate tag instead. Work on this will start over the weekend. Statistics = Total number of packages:11701 metadata.xml missing 0 missing 0 empty 0 unknown 0 =no-herd1880 missing 6616 retired 0 is a herd1306 unknown 193 =maintainer-needed 438 Proxy maintainer without gentoo association11 Unmaintained packages 596 The full metadata-check.log is available from: http://dev.gentoo.org/~bangert/metadata-check.log The script used to generate the log can be found here: http://overlays.gentoo.org/dev/bangert/browser/scripts/check-metadata.rb Feedback welcome. Kind regards Thilo pgp1OFUyQs7Ty.pgp Description: PGP signature
Re: [gentoo-dev] Packages with same name was -> Conversion of Emacs virtual packages
> > It isn't different. That's the problem. If you have two packages > > with the same name, you have the same problem. > > On that note I would hope the vim/vi peeps would rename. > app-vim/ant and app-vim/sudo > IMHO app-vim/ant should really be app-vim/vim-ant or something other > than just ant. or app-vim/sudo-syntax and app-vim/ant-syntax as there already are a number of ebuilds following that scheme... regards Thilo pgps9kzRfHjIU.pgp Description: PGP signature
Re: [gentoo-dev] DWS for 2007-05-07 - 2007-05-13
Markus Ullmann <[EMAIL PROTECTED]> said: [usefull DWS snipped] you rock! pgpFgJgMmryKA.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] missing tag in metadata.xml
Hi again, Thilo Bangert <[EMAIL PROTECTED]> said: > The metadata cleanup continues... > > A list of 427 packages found at > > http://dev.gentoo.org/~bangert/herd-metadata-check.log > > do not have the required tag in their metadata.xml[1]. some of these have tags afterall - albeit empty. i will be fixing these over the next few days, adding no-herd. a current run has yielded the following statistics: Found 0 packages with retired maintainer Found 1517 packages with unknown maintainer Found 11 packages with invalid proxy maintainer Found 395 packages with missing Found 4 packages with invalid Found 33 packages with empty Found 606 unmaintained packages Found 0 packages with missing metadata.xml 11665 Packges checked, 2566 errors detected see the full log at http://dev.gentoo.org/~bangert/metadata-check.log the large number of unknow maintainers are largely due to herd email addresses listed in tags... kind regards Thilo pgplnh3phMhGu.pgp Description: PGP signature
Re: [gentoo-dev] invalid in metadata.xml
> Can you re-run this with a fully up to date tree? sure app-emulation/hercules invalid herd: s390 sys-apps/cpint invalid herd: s390 sys-apps/lkcdutils invalid herd: s390 sys-apps/s390-oco invalid herd: s390 Found 4 packages with invalid pgp24PUBmOafO.pgp Description: PGP signature
Re: [gentoo-dev] missing metadata.xml
> the packages in the attached list have no metadata.xml. all fixed. however with the following metadata.xml: http://www.gentoo.org/dtd/metadata.dtd";> no-herd as no maintainer implies maintainer-needed and this is being done in lots of other ebuilds as well. kind regards Thilo pgpttgHImjKSF.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] missing tag in metadata.xml
> you should look at > the archives to see what people decided. from reading the archives and the response so far as well as the current documentation on the subject i conclude that the issue is still not clear and people make up their own stuff as they go along. the following may be a formalisation of current (best) practices: - maintainers fall into three categories. herds, gentoo developers and non-gentoo proxy maintainers. - a herd is defined in herds.xml. exception: no-herd. no-herd is limited to the situation where no suitable herd can be found. - a gentoo developer is defined in dev-rel/roll-call/userinfo.xml. - every ebuild has a herd. - a package can belong to more than one herd. - a package can be maintened by no or more parties. - a package with herd different from 'no-herd' is said to be maintained by the members of that herd. - all maintainers different from herds state their maintainership using the tag. the tag requires the tag. - a package with herd 'no-herd' and no additional maintainers is said to be unmaintained. - a of [EMAIL PROTECTED] indicates no maintainership and is only allowed as the sole maintainer. meaning a single tag and a single no-herd tag. infact it is semantically equivalent to a single no-herd tag and no additional maintainers. - a package that is proxy maintained needs an additional gentoo association in form of a maintaining herd or gentoo developer. [EMAIL PROTECTED] may be such an association, but only if the original one disappeared. optionally one may want to include, although personally i prefer to state it explicitly: - a missing or empty tag is equivalent to no-herd open questions: - what does it mean when the package is maintained by a herd and an additional maintainer? how does one determine the order in which to contact multiple maintainers? - are there situations in which we specify a other than no-herd but don't want its members to act as maintainers? ... what are your current best practices regarding metadata? regards Thilo pgpA6IXbqq6cC.pgp Description: PGP signature
