[gentoo-dev] Re: Re: Summary for 15 March 2007 special council meeting on CoC
Robin H. Johnson wrote: There isn't one yet, but proctors@ or reporting on BugZilla will probably work fine as soon as kingtaco and kloeri actually get the initial proctors together. In all seriousness I propose [EMAIL PROTECTED] - I am not trying to start a bidding war here for names, so please don't flame me. The reason I propose is that anybody who uses gentoo knows what it means. Further, it's easy to remember; Who was that asshole from gentoo- mail the .*! It's not like the rest of the GNU community don't know about our situation and it shows we're taking it seriously, but not that seriously. Nor is it much of a problem with anglophonic parents nowadays. Only Gentoo developers may be nominated Thus your corner-case of a moderator that does nothing else wanting to become a council member is not valid, because the moderator is not a developer, if he were, he would be doing other things as well. As a user I would dearly love to see the forum mods in there. I guess you know that by now ;) See the 20060914 council meeting where we discussed conflicts of interest and reached the conclusion that we should act professionally (and impartially) if possible, and abstain from a matter if that was not possible (example in the meeting was kloeri being the lead of devrel). ++ -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Gentoo's problems
Mauricio Lima Pilla wrote: We are always ready to listen to feedback and constructive criticism, but your constant trolling against the forums can't be classified as such. IMO ciaran has definitely been trolling this list and it's doing my head in. Is there anyone else who feels the same, strongly enough to risk his ire? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Re: Gentoo's problems
There's a difference between UI improvements like FEATURES=candy and UI improvements like ability to do dependency-based uninstalls (merely one example). UI improvements that improve user experience substantially are fine. Minor UI improvements are good too, but not when they're being touted as significant achievements. Oh ffs, why don't you stop all this negativity, and post some algorithms for once? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Summary for 15 March 2007 special council meeting on CoC
Robin H. Johnson [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 15 Mar 2007 22:07:45 -0700: I think you missed one thing. From the council page: Only Gentoo developers may be nominated Thus your corner-case of a moderator that does nothing else wanting to become a council member is not valid, because the moderator is not a developer, if he were, he would be doing other things as well. It's possible I read the conclusions incorrectly, but I thought that global forum moderators were made full Gentoo staff, and that, save for the practical distinction of tree dev vs. not, the terms Gentoo dev and Gentoo staff were interchangeable. That's at least part of what I referred to with the mention of possible restriction I wasn't aware of, as I wasn't positive about staff status, but if it's correct, then at least in theory global mods could indeed run for council. If it's not correct, that they are staff and /not/ devs, therefore /not/ eligible for council, then I've misunderstood. Apologies for the noise. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Summary for 15 March 2007 special council meeting on CoC
On Fri, Mar 16, 2007 at 09:28:10AM +, Duncan wrote: I think you missed one thing. From the council page: Only Gentoo developers may be nominated Thus your corner-case of a moderator that does nothing else wanting to become a council member is not valid, because the moderator is not a developer, if he were, he would be doing other things as well. It's possible I read the conclusions incorrectly, but I thought that global forum moderators were made full Gentoo staff, and that, save for the practical distinction of tree dev vs. not, the terms Gentoo dev and Gentoo staff were interchangeable. That's at least part of what I referred to with the mention of possible restriction I wasn't aware of, as I wasn't positive about staff status, but if it's correct, then at least in theory global mods could indeed run for council. If it's not correct, that they are staff and /not/ devs, therefore /not/ eligible for council, then I've misunderstood. Apologies for the noise. Somebody else more intimately familiar with the meta-structure documents would be better suited to answer this one than me - reading those instead of the council page, I cannot tell one way or another if they are or are not able to run for the council (but it could also be that it's 02h40 and I'm really tired and still stuck on work stuff). -- Robin Hugh Johnson Gentoo Linux Developer Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpg4oXFkfa6Y.pgp Description: PGP signature
[gentoo-dev] Re: Gentoo's problems
Steve Long [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 16 Mar 2007 08:41:50 +: Mauricio Lima Pilla wrote: We are always ready to listen to feedback and constructive criticism, but your constant trolling against the forums can't be classified as such. IMO ciaran has definitely been trolling this list and it's doing my head in. Is there anyone else who feels the same, strongly enough to risk his ire? That may or may not be, but I don't believe the list is the place to debate it. If you believe anyone (in the generic, let's not name names here) is trolling, mail the proctors (or in the mean time, kloeri or kingtaco, who are setting up the initial proctor list, see the Summary for 15 March 2007 special council meeting on CoC thread). Here isn't the appropriate place to discuss it. I of course have an opinion and am tempted to post it, but shall restrain, because as I said, it's inappropriate here. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Gentoo's problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Long wrote: Mauricio Lima Pilla wrote: We are always ready to listen to feedback and constructive criticism, but your constant trolling against the forums can't be classified as such. IMO ciaran has definitely been trolling this list and it's doing my head in. Is there anyone else who feels the same, strongly enough to risk his ire? Steve Long, please stop your trolling. Steve Long wrote: Ciaran McCreesh wrote: There's a difference between UI improvements like FEATURES=candy and UI improvements like ability to do dependency-based uninstalls (merely one example). UI improvements that improve user experience substantially are fine. Minor UI improvements are good too, but not when they're being touted as significant achievements. Oh ffs, why don't you stop all this negativity, and post some algorithms for once? Ciaran is working on a replacement, so this comment makes no sense. Please stop your incessant trolling. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+me8p/VmCx0OL2wRAh8wAJ9b56ol4Tv1YUaY49zVgOahYJcH6wCgj0aI OzUGR3E07+zb4oADHlub1PE= =sUkH -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo's problems
Jakob Buchgraber wrote: Why don't you join the portage team and try to persuade the current portage devs and help to implement the killer features? The main problem with such projects is that you cannot do some stuff in an easy way, that's the reason you have from scratch rewrite of 2.0 codebases many times. You take the wisdom from the design errors you had the first time and move to a better design. So instead of saying that portage is missing features and developing your own pm you could be even more productive and help improving portage. Not really. Why don't ya do that? Because he knew that it would take less rewriting from scratch. now, having paludis and pkgcore around makes even portage improving since you can compare different ideas and have more inputs on how things could be done. lu - I like independent implementation, xine and mplayer won't be that good w/out each other. -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo's problems
Jason Stubbs wrote: That's not entirely true. The main trouble with refactoring portage code is that there is no defined public API and so even the littlest changes are likely to break things in gentoolkit and several of the portage gui front end packages. What about branching, doing the dirty stuff and let others fix their code? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Gentoo's problems
On 16/03/07, Steve Long [EMAIL PROTECTED] wrote: Mauricio Lima Pilla wrote: We are always ready to listen to feedback and constructive criticism, but your constant trolling against the forums can't be classified as such. IMO ciaran has definitely been trolling this list and it's doing my head in. Is there anyone else who feels the same, strongly enough to risk his ire? -- gentoo-dev@gentoo.org mailing list From what I've seen of the recent blather I can say I'm sorry Daniel Robbins is the one who took off. Jeff -- Q: What will happen in the Aftermath? A: Impossible to tell, since we're still in the Beforemath. http://latedeveloper.org.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Gentoo's problems
On Fri, 16 Mar 2007 08:41:50 + Steve Long [EMAIL PROTECTED] wrote: IMO ciaran has definitely been trolling this list and it's doing my head in. Is there anyone else who feels the same, strongly enough to risk his ire? If you think Ciaran is trolling, just ignore him. Be part of the solution, not the part of the problem. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Summary for 15 March 2007 special council meeting on CoC
I'd just like to say good job and thanks, to all involved in the CoC. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo's problems
On Friday 16 March 2007 18:58, Luca Barbato wrote: Jason Stubbs wrote: That's not entirely true. The main trouble with refactoring portage code is that there is no defined public API and so even the littlest changes are likely to break things in gentoolkit and several of the portage gui front end packages. What about branching, doing the dirty stuff and let others fix their code? I've worked on a branch in the past as has Brian and a lot of the code that went into 2.1.0 was done in a seperate branch. However, a lot of bugs that got fixed in the release branch never got fixed in the development branches and so switching wasn't really viable. For 2.1.0, a lot of the work that was done ended up being completely redone in the release branch. In hindsight, if the team had have worked together as a team on a dev branch and only critical bug fixes went into the release branch while the dev branch was being readied it would have worked. Proper coordination would be needed but I guess it still could... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Emacs Project Overlay
Hi all, Yesterday the Emacs Project Overlay has been created on overlays.gentoo.org and is accessible through Layman $(layman -a emacs). What's new? * An eselect module for Emacs to control the version of Emacs you use ** changes the target of /usr/bin/emacs which up to now simply took the most current one ** setting symlinks to the correct man pages ** setting the correct INFOPATH to let info find the correct nodes ** brings desktop file including icon to avoid file collisions * updated ebuilds for all versions of Emacs (Emacs 18 and 21, plus CVS Emacs 22 and 23). In detail they bring (for CVS versions only): ** work together with the eselect module (all versions actually) ** new/removed USE flags and changed the behaviour of some: added sound: disables/enables sound support modified alsa: really kills ALSA detection if not enabled, if enabled also activates sound on its own removed nls: Emacs brings its own gettext.h removed gnome: was only needed for the icon of the desktop file, which is included in the eselect ebuild now * Emacs 23 has all the new cool ebuild features Emacs 22 already had (see ChangeLog in tree) * revamped DEPEND and RDEPEND, all package atoms should be in the correct place now * updated version of elisp.eclass and elisp-common.eclass (mainly documentation to the functions along with examples) * updated version of app-emacs/ebuild-mode (Emacs support for .eclass, .ebuild and .eselect files, mostly some added keywords) We need testing, as Emacs is widely used and such big changes can't be brought to the main tree over-night: Functionality in general: Do all Emacs versions from 18 to 23 work fine? File collisions: Which versions of Emacs overwrite a file owned by another? FEATURES=collision-protect is the magic word. eselect functionality: Is switching working as expected? If you feel like trying all that, ceck the overlay out and file bugs or write an email to the Emacs team. Special thanks go out to Ulrich Müller as he gave a lot of feedback and inspiration. URL:http://www.faulhammer.org/index.php?option=com_contenttask=viewid=165 (URL to my Planet post, which has same contents) V-Li signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Gentoo's problems
On Fri, 16 Mar 2007 08:44:02 + Steve Long [EMAIL PROTECTED] wrote: There's a difference between UI improvements like FEATURES=candy and UI improvements like ability to do dependency-based uninstalls (merely one example). UI improvements that improve user experience substantially are fine. Minor UI improvements are good too, but not when they're being touted as significant achievements. Oh ffs, why don't you stop all this negativity, and post some algorithms for once? http://paludis.pioto.org/ Look, a completely reimplemented alternative to Portage complete with huge numbers of substantial improvements! -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo's problems
darren kirby wrote: Exactly. LSBs insistence on using RPM as the One True Package Manager seems incredibly daft to me. It was RPM-hell that steered me towards Gentoo all those years ago in the first place. I cannot put into words how much I loathe RPM. Seems to me if Gentoo wholesale adopted the LSB then it would be little more than another Redhat/SuSe clone no? And nobody here wants that, do they? Portage (or the tree as Ciaran puts it) is _still_ the chief reason I use Gentoo, and I rather think it will always be... just another Gentoo luser, -d You too huh? I left Mandrake because the upgrades were a mess to say the least. They were also slow to come out. I hope Gentoo will get all this mess straightened out because I have no clue what I would have to move too. Dale :-) :-) :-) -- www.myspace.com/-remove-me-dalek1967
Re: [gentoo-dev] gentoo-dev vs lkml?
On Thu, 2007-03-15 at 20:17 -0400, Daniel Drake wrote: Now look at the LKML. It's often hard to find general discussion behind the truckloads of patches and river of technical review emails. A large proportion of the content is not understandable unless you have a good knowledge of C, operating systems, and the technical area in question. This isn't a place that users hang out, users dont really read it either, and you need to be a decent developer to get involved in the first place. This is honestly one of the things I think is a problem with this list, in particular. I hope to start trying to steer the conversation away from this list and keep things on a more technical level. If things start to go off-topic, you might likely get a response from me asking you to either get back on-topic or to take it elsewhere. Looking back over the flames we've seen recently, there's usually very little technical discussion, if any. Instead it is heated argument over things like beliefs (technical or otherwise) and politics, neither of which really belong on a development list. I think if this list got back to its core of being a *development* list, that many of the flames would die down to an acceptable level. Thank you for your insight, Daniel! -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Gentoo's problems
On Fri, 2007-03-16 at 00:50 +, Steve Long wrote: Jakob Buchgraber wrote: So I just think something has to be changed e.g. making paludis an official gentoo project and mentioning it in the docs, but keep portage as the default pm. If portage can't get improved, then people have to get informed that there is a better alternative, because I know a lot of Gentoo users having never heard about paludis and I also didn't know that it even exists until a month ago. You (and others) should also be made aware of pkgcore then as it might turn out from these discussions that ciaran's future contributions will not be allowed in gentoo (unless i'm missing something.) In which case, I have no You're missing something. Notice that the Council did *not* agree to banning contributions from people, only possibly removing them from the discussion mediums due to their behavior. We are trying to fix people's behaviors, not remove them as possible contributors. For one, it would be very hard to accomplish and would require, in my opinion, too much work for the perceived benefit we would gain. http://www.pkgcore.org/ if you want to see the other other package manager, written by one of the (core?) portage devs. Apparently it's where a ex-portage devs (just to clarify) -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gentoo-dev vs lkml?
On Fri, 2007-03-16 at 13:33 +0900, Jason Stubbs wrote: Also part of the maturity point. Perhaps we all just need to grow up? ;) I do think we have a significantly lower average age than the Linux Kernel developer group. This probably plays a significant role in how things go on around here. This is an important point that I hadn't considered. It kind of resembles the affect of bad press coverage you mentioned earlier. I'm not sure that there's much that can be done about it though - at least not in the short term. I think some gentle prodding by non-proctors (I know I'll be doing this) for people to keep on-topic might help. I'm sure it won't prevent every flame from starting, but it might help some, and at this point, we need all the help that we can get. Perhaps a code of conduct should be created that discusses how one should behave rather than how one should not. Taking cues from member of LKML that show maturity as well as other communities that do well, it could cover what is expected in the situations where we are failing and extended as needed. We actually have revised the code to read differently. You should check it out at http://www.gentoo.org/proj/en/council/coc.xml to see how it has changed. Also, we are planning on reviewing it again prior to the next meeting. I suggest that people take suggestions/comments on the current incarnation on the gentoo-council mailing list, where it belongs. What do you think? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Summary for 15 March 2007 special council meeting on CoC
On Fri, 2007-03-16 at 04:35 +, Duncan wrote: * If you perceive a breach of the Code of Conduct guidelines, let the proctors know. How? The council's email address is given for appeals, but no general proctor address is listed. (At least none that I saw, even after searching, so if it's there, it needs to be made rather more prominent.) [EMAIL PROTECTED] a reasonable alias? Mentioning it right after the above quoted sentence should work, I think. We had no such alias made, but I'm requesting it to be done. I'll update the document accordingly once we have the alias. I also plan on making it known that users/developers should be able to also contact any of the local moderation/operation staff for the medium they're on, meaning they can contact any op in #gentoo or any moderator in the forums. There's no need to necessarily go directly to the proctors for everything. their council term, if elected). Was that really intended? Perhaps it Yes, it was intended. Nobody on the Council should be a proctor. I think you missed that only the *initial* group of proctors includes all global moderators. By the next council meeting, we plan on having a much reduced list of proctors to serve in a more permanent role. This will *include* moderators from the forums, but not all of them. If someone runs for Council and is elected, they would give up their position as proctor (but not as a moderator/operator). Since the next Council elections aren't before the next Council meeting, this should work out just fine. ;] Basically, the chain goes like this: local moderators/operators - proctors - Council -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Summary for 15 March 2007 special council meeting on CoC
On Fri, 2007-03-16 at 09:28 +, Duncan wrote: If it's not correct, that they are staff and /not/ devs, therefore /not/ eligible for council, then I've misunderstood. Apologies for the noise. Staff are devs and are eligible for the Council just as much as Infra are staff and eligible for the Council. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] Summer of Code 2007
Hiya all, It is that time of the year again, and we have yet once more been accepted as a mentoring organisation for SoC. Interested mentors (current Gentoo developers) should fill in the mentor application (link sent to -core). Interested mentors, co-mentors, people with project ideas and prospective students are encouraged to sign up to the [EMAIL PROTECTED] ML as well as joining the #gentoo-soc IRC channel on irc.freenode.net TTFN, Christel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dont use `which` in ebuilds
* Ned Ludd [EMAIL PROTECTED] [07/03/12 16:36 -0700]: app-cdr/cdrkit/cdrkit-1.0.ebuild:26: app-cdr/cdrkit/cdrkit-1.1.2.ebuild:28: Those are fixed. Regards, Lars -- Lars Weiler [EMAIL PROTECTED] +49-171-1963258 Instant Messaging : [EMAIL PROTECTED] Gentoo Linux PowerPC : Strategical Lead and Release Engineer Gentoo Infrastructure : CVS Administrator pgpY8iwgWLjer.pgp Description: PGP signature
Re: [gentoo-dev] A User's View of the Code of Conduct
On Wed, 2007-03-14 at 13:45 -0700, M. Edward (Ed) Borasky wrote: Larry Lines wrote: I learned Linux by installing and hacking and suffering over Gentoo. Exactly one year after installing Gentoo, I was in Hong Kong building and programming for a Linux cluster. There is no other distribution that compresses the learning curve like that. I still can't figure out what is supposed to be easier about running Redhat or Fedora. Sure installation is easier but then you don't know where anything is and you can't tweak anything easily. And that's precisely because a whole generation of RHCEs knows *exactly* where everything is on a Red Hat or Fedora system, and Gentoo puts everything somewhere else. :) If I were an RHCE, I'd have just as much trouble customizing and tweaking a Gentoo (or Debian) box as you would on a Fedora system. I know ... I've flunked the dang RHCE exam *twice* for that very reason! :) It's about repetition, muscle memory, rote learning, etc. -- not about Red Hat being better than Gentoo or the other way around. -- Well I guess it would be more accurate to say I don't want to learn a new distribution. But maybe I should since Gentoo is a dying distro! ;) I still say that just the install process for Gentoo is a huge learning tool for Linux. You have to know a lot more than the average Redhat user just to get through the install, and Gentoo's install is heavily documented so if you just follow the instructions without knowing Linux, it's possible to learn quite a bit very fast. The network analysts at one of my jobs actually make the new people install Gentoo on a box just for the experience. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: gentoo-dev vs lkml?
Also part of the maturity point. Perhaps we all just need to grow up? ;) Very likely, but how? I think my own opinion was best expressed by John Galsworthy (or Soames Forsyte of the Forsyte Saga): One of these days they’d try and bring in Prohibition, he shouldn’t wonder; but that cock wouldn’t fight in England — too extravagant! Treating people like children wasn’t the way to make them grow up; as if they weren’t childish enough as it was. I think that the mere existence of the CoC would slow down, to say the least, growing up. Prohibition laws are in the spirit of time, though, so when facing the dilemma of being decent vs. following the rules, the majority prefers the latter nowadays. Love, H -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
On Mon, 2007-03-12 at 19:15 -0400, Mike Frysinger wrote: On Monday 12 March 2007, Mike Frysinger wrote: instead, since we require bash for our ebuilds, use the builtin `type -p` err i botched that ;) `type -p` is almost a complete drop in replacement for which ... it does not work on bash builtins however, so people should use `type -P` to force the PATH search in other words, `type -p echo` would return while `type -P echo` would return /bin/echo -mike Here are the remaining offenders for sync 1174037821 that match '$(which ' or '`which ' in eclasses and ebuilds. eclass/mysql.eclass:529: eclass/mysql.eclass:530: app-dicts/stardict/stardict-2.4.8.ebuild:42: sci-mathematics/octave/octave-2.1.57-r1.ebuild:34: sci-mathematics/octave/octave-2.1.69.ebuild:36: www-apps/lxr/lxr-0.3.1.ebuild:37: app-cdr/cdrkit/cdrkit-1.0.ebuild:26: app-cdr/cdrkit/cdrkit-1.0_pre5.ebuild:30: app-cdr/cdrkit/cdrkit-1.1.0.ebuild:28: app-cdr/cdrkit/cdrkit-1.1.1.ebuild:28: app-cdr/cdrkit/cdrkit-1.1.2.ebuild:28: app-dicts/verbiste/verbiste-0.1.16.ebuild:28: app-text/pdftk/pdftk-1.12.ebuild:20: dev-db/hsqldb/hsqldb-1.7.3.1-r1.ebuild:48: dev-util/kdesvn/kdesvn-0.11.1.ebuild:34: dev-util/kdesvn/kdesvn-0.11.1.ebuild:35: media-libs/pdflib/pdflib-5.0.4_p1-r1.ebuild:39: media-libs/pdflib/pdflib-6.0.3-r1.ebuild:48: media-libs/pdflib/pdflib-6.0.3.ebuild:38: sys-process/fcron/fcron-2.0.2.ebuild:28: sys-process/fcron/fcron-2.9.5.1.ebuild:31: sys-process/fcron/fcron-2.9.7.ebuild:26: sys-process/fcron/fcron-3.0.0.ebuild:33: sys-process/fcron/fcron-3.0.1-r1.ebuild:33: sys-process/fcron/fcron-3.0.1.ebuild:33: -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
Ned Ludd wrote: Here are the remaining offenders for sync 1174037821 that match '$(which ' or '`which ' in eclasses and ebuilds. dev-db/hsqldb/hsqldb-1.7.3.1-r1.ebuild:48: This one just echos which to a script so it's safe I think. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC Package name additions
After reviewing http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules I still seem to be having to finagle version names for some packages. At the moment it would be nice if we also had the following suffixes available _dev Apache upstream, specifically Tomcat/mod_jk tends to do developer snapshots that they then host out of developer space. People do fetch bins and source from there for testing. It's kinda pre-release, so I have been using _pre where I would use _dev, but _pre does not make much sense. _build Other packages seem to do constant builds (weekly) of the same version. For example Glassfish (Sun's FOSS J2EE stuff). It's sources are v2-b39. So would be nice to be able to do like glassfish-servlet-api-2_build39 _snapshot This one is kinda universal in it's name/implication. Would be for any sort of upstream snapshot release, that might not be versioned as such. Short of the name snapshot being some where. The above would then follow the rest of the normal schema, where in they could still be suffixed by a number, or not. Hierarchy would be the following snapshot - dev - build - alpha - beta Or at least that's my thoughts on it. Time for others thoughts, much less those that will make it so. Not expecting it to get done or be available any time soon. Would be suffice if they were just accepted and planned for inclusion at some point. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dont use `which` in ebuilds
Am Freitag, 16. März 2007 23:16 schrieb Ned Ludd: On Mon, 2007-03-12 at 19:15 -0400, Mike Frysinger wrote: On Monday 12 March 2007, Mike Frysinger wrote: Here are the remaining offenders for sync 1174037821 that match '$(which ' or '`which ' in eclasses and ebuilds. sci-mathematics/octave/octave-2.1.57-r1.ebuild:34: sci-mathematics/octave/octave-2.1.69.ebuild:36: ^^ fixed. Must have slipped through in my first round. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
Ned Ludd wrote: Here are the remaining offenders for sync 1174037821 that match '$(which ' or '`which ' in eclasses and ebuilds. eclass/mysql.eclass:529: eclass/mysql.eclass:530: media-libs/pdflib/pdflib-5.0.4_p1-r1.ebuild:39: media-libs/pdflib/pdflib-6.0.3-r1.ebuild:48: media-libs/pdflib/pdflib-6.0.3.ebuild:38: Fixed, thanks for the report! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Removing of package games-rpg/planeshift
On Wednesday 14 March 2007, Christian Bricart wrote: Tupone Alfredo schrieb: games-rpg has been masked on 18 jul 2006 and there is a pending bug #167547 Broken dependancies in games-rpg/planeshift-0.3.011 Removing is planned for this end of week: 17 Mar 2007. 0.3.011 is wy t old and not compatible with current server versions. BUT see: http://bugs.gentoo.org/show_bug.cgi?id=155790#c7 maybe it only needs some love after all... it doesnt need some love, it needs a real maintainer ... the current one no longer enjoys maintaining it and i see no reason to force him into such punishment -mike pgpw6BP7nurSh.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
There's absolutely no reason to absorb every single version naming scheme on earth. Gentoo's does work nicely and more than we have would only be irritating to the user. Simply use _predatecode or whatever fits, but extending our naming scheme is unneeded and pointless. Carsten pgpcLcObgCmuK.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
On Sat, 2007-03-17 at 00:11 +0100, Carsten Lohrke wrote: There's absolutely no reason to absorb every single version naming scheme on earth. Gentoo's does work nicely and more than we have would only be irritating to the user. Simply use _predatecode or whatever fits, but extending our naming scheme is unneeded and pointless. Well that's the problem. When I use say _pre instead of _dev it gives off the wrong impression to users judging package by it's name. Since it's not a pre-release. A user may go upstream looking for some sort of pre-release. Which they won't find. The whole point is to make it clearer to the user the relation of the sources to upstream. Instead of making them fit into our naming schema, which do not apply to all. Now granted at least on the Java front we have discussed coming up with documents. We have a start of one, How to be a good upstream http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream Which we do need to make a section regarding package naming, tagging sources and etc. With examples and so on. Also keep in mind the _dev one I believe stems from Apache's own release policies. Which they have a considerable amount of packages, so it's not something that would only fit a small subset. IE Tomcat, mod_jk, etc. The whole idea is better clarification to the end user via package name. Instead of package being tagged as _pre or etc, and sources being tagged with -dev and/or coming from a developers space. Not main project release page or etc. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
On Sat, 17 Mar 2007 00:11:43 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: There's absolutely no reason to absorb every single version naming scheme on earth. Gentoo's does work nicely and more than we have would only be irritating to the user. Simply use _predatecode or whatever fits, but extending our naming scheme is unneeded and pointless. And of course there is the issue of how older Portage releases will react to ebuild names that they don't understand. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does milestone releases. These are pretty stable and usable since milestone 7 of netbeans 6.0 with many new features that make sense to use the milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc. though I was assured by mkt guy from Sun it is not yet alpha quality. It would be fair to the upstream and to users to not use _alpha because it is not alpha but there's no appropriate choice available. - -- Miroslav Šulc (fordfrog) Gentoo/Java Team William L. Thomson Jr. napsal(a): After reviewing http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules I still seem to be having to finagle version names for some packages. At the moment it would be nice if we also had the following suffixes available _dev Apache upstream, specifically Tomcat/mod_jk tends to do developer snapshots that they then host out of developer space. People do fetch bins and source from there for testing. It's kinda pre-release, so I have been using _pre where I would use _dev, but _pre does not make much sense. _build Other packages seem to do constant builds (weekly) of the same version. For example Glassfish (Sun's FOSS J2EE stuff). It's sources are v2-b39. So would be nice to be able to do like glassfish-servlet-api-2_build39 _snapshot This one is kinda universal in it's name/implication. Would be for any sort of upstream snapshot release, that might not be versioned as such. Short of the name snapshot being some where. The above would then follow the rest of the normal schema, where in they could still be suffixed by a number, or not. Hierarchy would be the following snapshot - dev - build - alpha - beta Or at least that's my thoughts on it. Time for others thoughts, much less those that will make it so. Not expecting it to get done or be available any time soon. Would be suffice if they were just accepted and planned for inclusion at some point. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+yssRSzWCmqu+0YRAoQAAJ9XHz0wZL3pdkSzSyxnVRnLsrw4FwCfVMDO vuDOHvpko+t1nhu1cvx0RfY= =ZYFd -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Fri, 2007-03-16 at 23:46 +, Stephen Bennett wrote: On Sat, 17 Mar 2007 00:11:43 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: There's absolutely no reason to absorb every single version naming scheme on earth. Gentoo's does work nicely and more than we have would only be irritating to the user. Simply use _predatecode or whatever fits, but extending our naming scheme is unneeded and pointless. And of course there is the issue of how older Portage releases will react to ebuild names that they don't understand. Understandable for sure. Thus not really putting any sort of time frame on implementation. Maybe EAPI=1 or beyond. Up to others that would implement it. Just was tossing it out there, providing some feedback. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
On Fri, 16 Mar 2007 20:00:51 -0400 William L. Thomson Jr. [EMAIL PROTECTED] wrote: Understandable for sure. Thus not really putting any sort of time frame on implementation. Maybe EAPI=1 or beyond. Up to others that would implement it. Just was tossing it out there, providing some feedback. EAPI doesn't help, at least not in its current form. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
William L. Thomson Jr. said the following: Well that's the problem. When I use say _pre instead of _dev it gives off the wrong impression to users judging package by it's name. Since it's not a pre-release. A user may go upstream looking for some sort of pre-release. Which they won't find. The whole point is to make it clearer to the user the relation of the sources to upstream. Instead of making them fit into our naming schema, which do not apply to all. snip The whole idea is better clarification to the end user via package name. Instead of package being tagged as _pre or etc, and sources being tagged with -dev and/or coming from a developers space. Not main project release page or etc. Hi guys, As one of the aforementioned users, I think the goal of helping us get a better idea of the reliability a given package is excellent. I was looking at the GLEP list the other day, and one of them that I liked in particular was GLEP 46. (Allow upstream tags in metadata). I think it could have some bearing on this goal. Although the GLEP doesn't list upstream-version as one of its proposed metadata tags, I think it could fit in nicely. I have no clue what the status of that GLEP is, but maybe the authors would? Personally, I think it sounds like a good flexible way of adding information to an ebuild without needing to redo the naming scheme, or the upgrade path. Here, you could use one of the existing ways of naming the package, but in the metadata give the information a user would want to evaluate the package's reliability (plus more!) :) -nkm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Friday 16 March 2007, William L. Thomson Jr. wrote: Well that's the problem. When I use say _pre instead of _dev it gives off the wrong impression to users judging package by it's name. Since it's not a pre-release. A user may go upstream looking for some sort of pre-release. Which they won't find. isnt it though ? how is a development release different from a pre release ? -mike pgpeE8TY4c1A7.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote: Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does milestone releases. These are pretty stable and usable since milestone 7 of netbeans 6.0 with many new features that make sense to use the milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc. though I was assured by mkt guy from Sun it is not yet alpha quality. It would be fair to the upstream and to users to not use _alpha because it is not alpha but there's no appropriate choice available. i would use _p# over _alpha# -mike pgpCf7QYn7X2T.pgp Description: PGP signature
Re: [gentoo-dev] Re: Distrowatch
On Wednesday 14 March 2007, Caleb Cushing wrote: Perhaps they're more interested in generating ad revenue from whipped-up scandals... or maybe they have a point. distrowatch hpd ranking show's us down from a few years ago we were those rankings are less significant/accurate than slashdot polls ;) -mike pgpZnsXGFA6wU.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
On Fri, 16 Mar 2007 18:25:17 -0400 William L. Thomson Jr. [EMAIL PROTECTED] wrote: Hierarchy would be the following snapshot - dev - build - alpha - beta And that's where the problems start. As you said yourself _snapshot is something universal so it doesn't really fit anywhere in the chain. Similar for _build, it usually runs parallel to normal versioning (a release also has a build number). Don't know about _dev, never seen a package where that would be useful myself. And as has been said, there are compability issues. At best older portage versions would ignore ebuilds using these new suffixes resulting in confused users, worst case stuff starts breaking. If you want to pursue this you should get some numbers of how many packages could actually make use of these new features, it simply isn't worth thinking about it for just a handful of packages. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Fri, 2007-03-16 at 21:23 -0400, Mike Frysinger wrote: On Friday 16 March 2007, William L. Thomson Jr. wrote: Well that's the problem. When I use say _pre instead of _dev it gives off the wrong impression to users judging package by it's name. Since it's not a pre-release. A user may go upstream looking for some sort of pre-release. Which they won't find. isnt it though ? how is a development release different from a pre release ? I take it as a pre-release is more of an official release. Where in it would be easily found on a projects download page or else where. What I would consider a _dev release is something coming out of a developers space on the project. Not really announced say beyond the developers mailing list. In that same regard alpha's and beta's usually can be found on project download pages. Same I would assume for any pre-releases. Given conceptually a development release is pre release. But not really advertised as such by upstream. Either way it would not really fit into our hierarchy. Most times the dev release will precede an alpha or beta, sometimes does skip and is before an official release. This might help a bit http://marc.info/?l=tomcat-devm=117251925901310w=2 In that example a _dev is more of a snapshot, which could also be considered as pre-release :) Good old interpretation of words. P.S. OTT With regard to above link and following development that closely. Between revisions of mod_jk, not only was there a security vulnerability. But in compatible changes effect certain file extensions .jsf, that a user reported. Which they only mentioned during stabilization of a given version (literally in stabilization bug). So in a sense a version with a problem got stabilized. But was an upstream bug, effecting a small subset. So did not really merit keeping the package from going stable for others. But bug was not filed with upstream either till 30+ days after release due to our stabilization policies and etc. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
On Sat, 2007-03-17 at 03:11 +0100, Marius Mauch wrote: On Fri, 16 Mar 2007 18:25:17 -0400 William L. Thomson Jr. [EMAIL PROTECTED] wrote: Hierarchy would be the following snapshot - dev - build - alpha - beta And that's where the problems start. As you said yourself _snapshot is something universal so it doesn't really fit anywhere in the chain. Yes, order wise snapshots might be quite confusing. Not sure if a well defined definition would clear that up. Similar for _build, it usually runs parallel to normal versioning (a release also has a build number). That's more something specific to say glassfish where builds are weekly https://glassfish.dev.java.net/public/downloadsindex.html#Promoted_binary_builds With major ones being milestones, similar to Netbeans. https://glassfish.dev.java.net/public/downloadsindex.html#Milestone_binary_builds Glassfish alone is likely to comprise of a guestimated ~20 or so packages. It's Sun's formerly closed source J2EE stack for the most part. Very possible could be more, formerly know as WSDP http://java.sun.com/webservices/jwsdp/index.jsp At best older portage versions would ignore ebuilds using these new suffixes resulting in confused users, worst case stuff starts breaking. If you want to pursue this you should get some numbers of how many packages could actually make use of these new features, it simply isn't worth thinking about it for just a handful of packages. After others comments, this is definitely something for the future. If and a time comes that it's feasible to introduce such changes safely. I do agree before acceptable or implementation the amount of packages that can benefit from it would surely help justify it or not. Now I doubt it's feasible for me alone to figure out if it can benefit all 4k+ packages :) So hopefully others can chime in briefly on if they can benefit or not. Maybe email me directly to I can start a tally. Only if you have packages that can benefit, no need otherwise. With that said, what percentage or ruff # of packages do you all think would need to benefit to justify it? That way if it's hard to find say 50 and min is like 500+, then no reason to look into it any further. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
William L. Thomson Jr. wrote: On Sat, 2007-03-17 at 03:11 +0100, Marius Mauch wrote: On Fri, 16 Mar 2007 18:25:17 -0400 William L. Thomson Jr. [EMAIL PROTECTED] wrote: Hierarchy would be the following snapshot - dev - build - alpha - beta And that's where the problems start. As you said yourself _snapshot is something universal so it doesn't really fit anywhere in the chain. Yes, order wise snapshots might be quite confusing. Not sure if a well defined definition would clear that up. Similar for _build, it usually runs parallel to normal versioning (a release also has a build number). That's more something specific to say glassfish where builds are weekly https://glassfish.dev.java.net/public/downloadsindex.html#Promoted_binary_builds With major ones being milestones, similar to Netbeans. https://glassfish.dev.java.net/public/downloadsindex.html#Milestone_binary_builds Glassfish alone is likely to comprise of a guestimated ~20 or so packages. It's Sun's formerly closed source J2EE stack for the most part. Very possible could be more, formerly know as WSDP http://java.sun.com/webservices/jwsdp/index.jsp At best older portage versions would ignore ebuilds using these new suffixes resulting in confused users, worst case stuff starts breaking. If you want to pursue this you should get some numbers of how many packages could actually make use of these new features, it simply isn't worth thinking about it for just a handful of packages. Bleh; you have to break it at one point anyhow; you added the cvs suffix, no? :) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Summary for 15 March 2007 special council meeting on CoC
Chris Gianelloni [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 16 Mar 2007 09:23:31 -0400: On Fri, 2007-03-16 at 04:35 +, Duncan wrote: * If you perceive a breach of the Code of Conduct guidelines, let the proctors know. How? [N]o general proctor address is listed. We had no such alias made, but I'm requesting it to be done. I'll update the document accordingly once we have the alias. I also plan on making it known that users/developers should be able to also contact any of the local moderation/operation staff for the medium they're on, meaning they can contact any op in #gentoo or any moderator in the forums. There's no need to necessarily go directly to the proctors for everything. Cool. =8^) their council term, if elected). Was that really intended? Perhaps it Yes, it was intended. Nobody on the Council should be a proctor. I think you missed that only the *initial* group of proctors includes all global moderators. By the next council meeting, we plan on having a much reduced list of proctors to serve in a more permanent role. OK. Makes sense now. I saw the /initial/ but wasn't sure where it was going from there. The further explanation makes sense. Thanks. =8^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Summary for 15 March 2007 special council meeting on CoC
Chris Gianelloni [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 16 Mar 2007 09:30:41 -0400: On Fri, 2007-03-16 at 09:28 +, Duncan wrote: If it's not correct, that they are staff and /not/ devs, therefore /not/ eligible for council, then I've misunderstood. Apologies for the noise. Staff are devs and are eligible for the Council just as much as Infra are staff and eligible for the Council. Thanks. That was my understanding as well, but it's good to have a solid statement on it. (The reason I brought it up you addressed elsewhere.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
