Re: [gentoo-dev] Last rites: dev-php5/ZendOptimizer
On Thursday 03 March 2011 22:26:38 Ole Markus With wrote: # Ole Markus With olemar...@gentoo.org (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 fa...@gentoo.org 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 anta...@gentoo.org said: On Mon, Aug 30, 2010 at 1:18 PM, Diego E. Pettenò flamee...@gmail.com wrote: # Diego E. Pettenņ flamee...@gentoo.org (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
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] Re: The future of sys-apps/openrc in Gentoo
Mike Frysinger vap...@gentoo.org 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] Treecleaner Project: Maintainer-needed page
Markos Chandras hwoar...@gentoo.org 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] 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] Gentoo calendar for tracking Gentoo events
Mike Frysinger vap...@gentoo.org 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.
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/ID/public/basic https://www.google.com/calendar/ical/ID/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] Wiki(es) for Gentoo ?!
Alex Legler a...@gentoo.org said: On Fri, 20 Aug 2010 23:01:42 +0200, Thilo Bangert bang...@gentoo.org 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] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
Richard Freeman ri...@gentoo.org 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] 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] RFC: Reviving GLEP33
Ben de Groot yng...@gentoo.org said: On 7 August 2010 02:18, Brian Harring ferri...@gmail.com 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] status of releng project
Ben de Groot yng...@gentoo.org said: On 9 August 2010 14:29, Mike Frysinger vap...@gentoo.org 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] 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] Re: Add --hash-style=gnu to LDFLAGS
Markos Chandras hwoar...@gentoo.org 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/sarcasm 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 fa...@gentoo.org 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 hwoar...@gentoo.org 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 hwoar...@gentoo.org 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 do...@dev.si 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 polynomial- c...@gentoo.org 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ễnchith...@gentoo.org 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 blah 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 that's what I try to do on the packages I maintain. GNU/Linux is all about choice. Stating, during install, that a package might later install additional stuff will just provide a choice to the user, not conditioning it. Regards, - Angelo [0] There is an existing precedent for
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] Suggestion related with dropping keywords policy
Pacho Ramos pa...@gentoo.org 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] Re: RFC: changing the developer profile: FEATURES=test - FEATURES=test-fail-continue
Ryan Hill dirtye...@gentoo.org said: On Fri, 04 Jun 2010 17:11:45 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org 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] 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] The importance of test suites
Paweł Hajdan, Jr. phajdan...@gentoo.org 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 robb...@gentoo.org 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 robb...@gentoo.rog Content-Type: text/plain Posted: 2010-02-15 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-db/mysql-5.1 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 arfre...@gentoo.org said: 2010-02-06 17:54:10 Mark Loeser napisał(a): Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org 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
Ben de Groot yng...@gentoo.org 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] [rfc] layman storage location (again)
Ciaran McCreesh ciaran.mccre...@googlemail.com 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.
[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 maintainer in metadata.xml to indicate the above). kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
Mike Frysinger vap...@gentoo.org said: On Sunday 17 January 2010 15:20:46 Thilo Bangert wrote: Ben de Groot yng...@gentoo.org 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.
Re: [gentoo-dev] QA last rites for media-gfx/viewer
Jeroen Roovers j...@gentoo.org 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 to...@gentoo.org said: On 12/11/2009 10:30 PM, Hanno Böck wrote: Am Freitag 11 Dezember 2009 schrieb Christian Faulhammer: George Shapovalov (george) geo...@gentoo.org: 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.
[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 project metadata check
Joshua Saddler nightmo...@gentoo.org said: On Tue, 8 Dec 2009 10:20:36 +0100 Thilo Bangert bang...@gentoo.org 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 dev role 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 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-audicle herd empty app-admin/eselect-chuck herd empty app-admin/eselect-miniaudicle herd empty app-admin/eselect-sndpeek herd empty net-im/minbif herd empty sys-kernel/dracut herd empty x11-libs/libvdpau herd empty x11-misc/vdpauinfo herd empty virtual/perl-Filter herd empty virtual/perl-i18n-langtags herd empty virtual/perl-Package-Constants herd empty virtual/perl-parent herd empty virtual/perl-Parse-CPAN-Metaherd empty app-office/homebank herd missing dev-libs/faxpp herd missing dev-libs/librelpherd missing dev-libs/ossp-uuid herd missing dev-util/cucumber herd missing dev-util/hg-git herd missing games-rpg/sacred-gold herd missing gnome-extra/gnome-color-chooser herd missing media-gfx/engauge herd missing media-gfx/greycstorationherd missing media-plugins/gimp-greycstoration herd missing net-dialup/dgcmodem herd missing net-irc/irssi-xmpp herd missing net-libs/udns herd missing net-misc/openswan herd missing sys-apps/edac-utils herd missing Statistics == Total number of packages:13623 metadata.xml missing 0 herd missing 16 herd empty13 herd unknown 0 herd=no-herd1999 maintainer missing 8383 maintainer retired 0 maintainer is a herd1187 maintainer unknown 203 maintainer=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] irregular metdata.xml check
Ulrich Mueller u...@gentoo.org 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.
Re: [gentoo-dev] irregular metdata.xml check
Hans de Graaff gra...@gentoo.org said: On Mon, 2009-12-07 at 12:56 +0100, Thilo Bangert wrote: Welcome to this years edition of the metadata check. dev-util/cucumber herd missing Fixed, but this is really a bug in metadata.dtd, which specifies !ELEMENT pkgmetadata ( (herd|maintainer|longdescription|use| upstream)* ) That should probably be: !ELEMENT pkgmetadata ( (herd)+ (maintainer|longdescription|use| 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] 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 ri...@gentoo.org 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 vosto...@gentoo.org 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 mr_bon...@gentoo.org 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 ssuomi...@gentoo.org said: Nirbheek Chauhan wrote: On Sat, Aug 1, 2009 at 7:32 PM, Petteri Rätybetelge...@gentoo.org 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 ri...@gentoo.org 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 ri...@gentoo.org 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
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
Fabian Groffen grob...@gentoo.org 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: Training points for users interested in helping out with ebuild development
Ciaran McCreesh ciaran.mccre...@googlemail.com said: On Tue, 5 May 2009 21:19:49 +0300 Markos Chandras hwoar...@gentoo.org wrote: We surely need more developers. Otherwise we ll end up maintaining 100x500 each one. Just look at the numbers ( total packages/total 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: Training points for users interested in helping out with ebuild development (was: Re: [gentoo-dev] Retiring)
Olivier Huber oli.hu...@gmail.com said: Hi, 2009/5/4 Thomas Sachau to...@gentoo.org [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: [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: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development (was: Re: Retiring)
Nirbheek Chauhan nirbh...@gentoo.org said: On Sun, May 10, 2009 at 5:19 PM, Duncan 1i5t5.dun...@cox.net wrote: Thilo Bangert bang...@gentoo.org 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
Ben de Groot yng...@gentoo.org 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] `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 packagmanager --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] Real multilib support for Gentoo
Santiago M. Mola coldw...@gentoo.org said: On Sat, Apr 4, 2009 at 2:59 PM, Thomas Sachau to...@gentoo.org 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] Re: EAPI roadmap
Serkan Kaba ser...@gentoo.org 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 loki_...@gentoo.org said: On Sun, 22 Mar 2009 09:41:58 +0100 Matti Bickel m...@gentoo.org 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] 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, slowguy 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 ))
Donnie Berkholz dberkh...@gentoo.org 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] 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 ))
Markos Chandras hwoar...@gentoo.org 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] 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-eapi - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - 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) new extension 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 gentoofa...@gentoo.org 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 dberkh...@gentoo.org 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 auto-stable-request enabled=true/ element with the DTD setting the default as true and you could just use a auto-stable-request / 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 herdno-herd/herd, we should add an entry into herds.xml to catch it (maintainer-needed at 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/crossvcherd empty app-emulation/virtinst herd missing dev-dotnet/dbus-glib-sharp herd missing dev-dotnet/dbus-sharp herd missing dev-libs/dclog herd missing dev-util/cmtherd missing dev-util/osdt herd missing mail-filter/dovecot-antispamherd missing mail-filter/dovecot-dspam herd missing media-libs/capseo herd missing media-libs/libcaptury herd missing media-video/captury herd missing media-video/undvd herd missing net-fs/wdfs herd missing net-irc/mistbot herd missing net-misc/goog-sitemapgenherd missing net-misc/ng-utils herd missing net-misc/s3cmd herd missing sys-auth/nsvs herd missing sys-fs/encfsherd missing sys-fs/flickrfs herd missing sys-fs/fuse-python herd missing sys-fs/python-fuse herd missing sys-fs/zfs-fuse herd missing sys-kernel/kerneloops herd missing Here are the stats summarising the current state of metadata in the tree. Statistics == Total number of packages:12410 metadata.xml missing 0 herd missing 24 herd empty 1 herd unknown 0 herd=no-herd1929 maintainer missing 7287 maintainer retired 4 maintainer is a herd1285 maintainer unknown 256 maintainer=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
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. maintaineremail${HERD_EMAIL}/email/maintainer
What about herdno-herd/herd? Does that expand to
maintaineremail[EMAIL PROTECTED]/email/maintainer?
Should it be added to herds.xml?
I'd be all for the expansion. Consequently all ebuilds with metadata
herdno-herd/herd and
maintaineremail[EMAIL PROTECTED]/email/maintainer
could be reduced to just herdno-herd/herd...
Step 3 - maintainer 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 maintaineremail[EMAIL PROTECTED]/email/maintainer?
And the case with no maintainer and herdno-herd/herd?
Those would be resolved by the herdno-herd/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
herdno-herd/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 maintainer elements in category metadata we possibly create
another (very weak) group maintainership. Is there a specific reason to
allow more than herd?
Thanks.
Kind regards
Thilo
pgpxulkMsBDop.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. herdno-herd/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 herd missing 2 herd empty 0 herd unknown 0 herd=no-herd1887 maintainer missing 6611 maintainer retired 0 maintainer is a herd1300 maintainer unknown 201 maintainer=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] 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 maintainer. This is simply redundant and unless complaints are raised, all herd maintainer tags will be removed and replaced by the appropriate herd 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 herd on every single package in the tree (well ~1900 packages with herdno-herd/herd). my guess is that most of the roughly 4500 packages that currently have a herd and a maintainer which is not a herd, 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 maintainer give you that the herd 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 maintainer. This is simply redundant and unless complaints are raised, all herd maintainer tags will be removed and replaced by the appropriate herd tag instead. Work on this will start over the weekend. Statistics = Total number of packages:11701 metadata.xml missing 0 herd missing 0 herd empty 0 herd unknown 0 herd=no-herd1880 maintainer missing 6616 maintainer retired 0 maintainer is a herd1306 maintainer unknown 193 maintainer=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 herd 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 herd tag in their metadata.xml[1]. some of these have herd tags afterall - albeit empty. i will be fixing these over the next few days, adding herdno-herd/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 herd Found 4 packages with invalid herd Found 33 packages with empty herd 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 maintainer tags... kind regards Thilo pgplnh3phMhGu.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: ?xml version=1.0 encoding=UTF-8? !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd; pkgmetadata herdno-herd/herd /pkgmetadata 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] invalid herd in metadata.xml
Can you re-run this with a fully up to date tree? sure app-emulation/hercules invalid herd: herds390/herd sys-apps/cpint invalid herd: herds390/herd sys-apps/lkcdutils invalid herd: herds390/herd sys-apps/s390-oco invalid herd: herds390/herd Found 4 packages with invalid herd pgp24PUBmOafO.pgp Description: PGP signature
[gentoo-dev] invalid herd in metadata.xml
Hi everybody, the following list of packages uses a invalid herd tag in its metadata.xml. Invalid in the sense of 'could-not-be-found-in-herds.xml' Most of them appear to be simple mis-spellings or minor misunderstandings. Others may lack an entry in herds.xml (s390?). AFAICT most packages have straight forward fixes, which will be applied in about 24 hours. Beat me to it if you want or stop my insanity by speaking up. All packages with herdmaintainer-needed/herd will be moved to herdno-herd/herd. kind regards Thilo app-cdr/powerisoinvalid herd: herdapp-cdr/herd app-editors/xxe invalid herd: herdmaintainer-needed/herd app-emulation/hercules invalid herd: herds390/herd dev-libs/libffi invalid herd: herd[EMAIL PROTECTED]/herd dev-libs/liboil invalid herd: herdmedia-video/herd dev-libs/libvc invalid herd: herdmaintainer-needed/herd dev-python/python-lzo invalid herd: herdnoherd/herd dev-ruby/jabber4r invalid herd: herdRuby/herd dev-ruby/net-sftp invalid herd: herdRuby/herd dev-ruby/net-sshinvalid herd: herdRuby/herd dev-ruby/pdf-writer invalid herd: herdRuby/herd dev-util/cgvg invalid herd: herddev-util/herd media-libs/schroedinger invalid herd: herdmedia-video/herd media-tv/freevo invalid herd: herdmaintainer-needed/herd net-fs/fex invalid herd: herdnoherd/herd net-ftp/tftp-hpainvalid herd: herdbasesystem/herd net-misc/netkit-rusers invalid herd: herdmaintainer-needed/herd net-misc/netkit-rwall invalid herd: herdmaintainer-needed/herd net-misc/redir invalid herd: herdmaintainer-needed/herd net-misc/vncsnapshotinvalid herd: herdmaintainer-needed/herd net-misc/xf4vnc invalid herd: herdmaintainer-needed/herd sci-electronics/splat invalid herd: herdci-electronics/herd sys-apps/cpint invalid herd: herds390/herd sys-apps/lkcdutils invalid herd: herds390/herd sys-apps/s390-oco invalid herd: herds390/herd x11-libs/libsexyinvalid herd: herdGentopia/herd x11-libs/openmotif invalid herd: herdmaintainer-needed/herd x11-misc/gromit invalid herd: herdmaintainer-needed/herd Found 28 packages with invalid herd pgpgBSRLMoNIw.pgp Description: PGP signature
[gentoo-dev] missing metadata.xml
Hi everybody, the packages in the attached list have no metadata.xml. The following basic metadata.xml will be added to each package in about 24 hours. Speak up to stop the insanity. Thanks. kind regards Thilo ?xml version=1.0 encoding=UTF-8? !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd; pkgmetadata herdno-herd/herd maintainer email[EMAIL PROTECTED]/email /maintainer /pkgmetadata app-crypt/keylookup missing metadata.xml app-doc/doc++ missing metadata.xml app-doc/linux-kernel-in-a-nutshell missing metadata.xml app-misc/grabcartoons missing metadata.xml app-text/expander missing metadata.xml dev-libs/mm missing metadata.xml dev-libs/mpatrolmissing metadata.xml dev-util/byacc missing metadata.xml dev-util/egypt missing metadata.xml media-libs/libipod missing metadata.xml net-misc/monmotha missing metadata.xml net-misc/zssh missing metadata.xml sys-apps/einit missing metadata.xml sys-cluster/wulfstatmissing metadata.xml sys-cluster/xmlsysd missing metadata.xml sys-devel/autoconf-archive missing metadata.xml sys-fs/ddrescue missing metadata.xml www-apps/browser-config missing metadata.xml www-client/downman missing metadata.xml www-client/netrik missing metadata.xml www-client/w3mirmissing metadata.xml www-servers/plb missing metadata.xml x11-libs/ViewKlass missing metadata.xml x11-libs/dndmissing metadata.xml x11-libs/kylixlibs3-borqt missing metadata.xml x11-libs/libPropListmissing metadata.xml x11-libs/xclass missing metadata.xml Found 27 packages with missing metadata.xml pgpihy3Q9SH8o.pgp Description: PGP signature
[gentoo-dev] [RFC] missing herd tag in metadata.xml
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 herd tag in their metadata.xml[1]. Is it reasonable to simply add the herdno-herd/herd or should perhaps the policy be relaxed, such that a missing herd tag is equivalent with herdno-herd/herd? kind regards Thilo [1] Gentoo Development Guide - Package and Category metadata.xml http://devmanual.gentoo.org/ebuild-writing/misc-files/metadata/index.html pgp1MBpXu4fX8.pgp Description: PGP signature
