[gentoo-dev] Re: Last rites: dev-lang/ruby-cvs
On Fri, 13 Apr 2007 18:49:05 -0400, Doug Goldstein wrote: Hans de Graaff wrote: dev-lang/ruby-cvs builds the latest Ruby 1.9.x version from CVS. Except... upstream has moved to SVN, so this ebuild no longer works. It's now masked and will be removed in 30 days. Is there any point in waiting 30 days? Since the ebuild just doesn't work because of a VCS change, it's clear it won't work at all for anyone no matter how much hacking they do. The 30 day rule in this case should not apply. I agree that in this case it's not needed, but I think it's the courteous thing to do and AFAIK no electrons will be unduly harmed by it. Also, it makes it easier for someone in the ruby team to look at the ebuild for reference when working on the ruby-svn ebuild. Hans -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh wrote:
What, you're saying they all ship with test suites that exist but don't
work?
anything that takes more than 10m to test is broken from an user point
of view: you want the application, not having it tested.
I'd rather keep it in features since tests are _optional_, not necessary
to use the applications, just a waste of user time if they aren't
concerned (e.g.: nobody but some would care about ffmpeg failing to do
bit exact decoding of an ${fringe codec} nobody but who is developing it
uses, and surely will be angry at me not being able to get those 20%
speed improvements on h264).
I don't think it shoud be part of the spec even if you don't have test
broken on delivery.
src_test is already part of the spec, and ebuilds are supposed to
either support it or RESTRICT it. I'm just proposing that EAPI 1 be a
lot stricter about it...
Adding more build time, requirements (yes, there are some tests that
needs more ram and cpu to complete than the actual build phase) w/out
ways to opt out is just hindering our users.
lu
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] RFC - Keywording scheme
Fabian Groffen wrote: This GLEP has been laying around for some long time now in my gleps dir. I nearly forgot about it. Anyway, feedback is appreciated. Since it is a keywording scheme that is compatible with the scheme that is currently in use and fulfils all the requirements, it sounds like a no-brainer to me.. i'm sure someone will flame me for daring to say so but wtf ;) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: April Council meeting summary
Ciaran McCreesh wrote: It's not such a big deal in practise is it? Yes, it is. It's a change in workflow, and it at least doubles the amount of work for each commit. do what? if it's so tricky write a script.. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Saturday 14 April 2007 18:14:48 Luca Barbato wrote: Ciaran McCreesh wrote: What, you're saying they all ship with test suites that exist but don't work? anything that takes more than 10m to test is broken from an user point of view: you want the application, Indeed, but speaking as a user, one wants the application to build and work, that is after all the whole point of installing a package. not having it tested. That all depends. If having it tested means that it _will_ work, I'd be infavour of that. However I do appreciate that having every user's install repeating tests which have been done thousands of times before is probably un-neccessary. How abouot setting the _default_ for test flags to true for '~' builds and false for supposedly stable builds? [ all good stuff ] -- CS -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: April Council meeting summary
Ilya A. Volynets-Evenbakh wrote: I'd say Ciaran has to have write access to any such repository, as one of the main contributors. Face it, he's never going to get write access to gentoo infra. The best gentoo can give him is access via spb, who has made it clear he'll simply be pulling in whatever ciaran commits. What is the issue? -- [EMAIL PROTECTED] mailing list
[gentoo-dev] OT: was 2007.0 release
Hi, Tempted by this recent thread, wanna just voice my thoughts. Can't there be some way (GWN, Bug, some general-purpose IRC channel etc.) on which users could at least be informed that work is under way to release 2007.0, with some kind of feedback. Releng could just choose to ignore it at all, but it's a possibility to inform users that work is done (once in a week or two). It's clear nobody can work on a busy/noisy street ;) so the current ways are ok. It's also evident that people who donate there time/force to work for others can't be pushed for anything, just a way to escape creating some tension among users. Somebody might want to know (for a new install) for how long (eventually) he/she will have to wait. A true community must communicate to be a community at all. The errors/weak points we make is what makes are go forward :) So nothing wrong with any kind of problems here (don't imply there are any). Time to finish, lets hope i could make myself clear enough. NO flames intended. Rumen -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Deps (was Re: Empty DEPEND strings in virtuals)
Petteri Räty wrote: We should link this info to the devmanual. Yeah that was v. instructive. Since there's only 3 ebuilds left with the old syntax, the obvious question is: is there anything else holding up impl of the GLEP? Also, would the preferred syntax be open to usage in eg recommended deps as opposed to mandatory ones? I appreciate that it's not the same GLEP or anything. I'm also curious about impl date of ranged deps and use deps, without wanting to start a flamewar about the merits or lack thereof. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Last rites: dev-lang/ruby-cvs
On Fri, 13 Apr 2007 18:34:00 -0700, M. Edward (Ed) Borasky wrote: Yes ... upstream moved to SVN right around the first of the year. If you want, I'll file something in bugzilla to get the details for Ruby 1.9 into Portage as an enhancement. Most of my Rubyist friends go right to the source repositories anyhow, so I'm not sure it even needs to be in Portage at this point. 1.9 is scheduled for release around Christmas 2007. Feel free to have a look at it. As I mentioned some work has been done already in bug 173817. I don't think it's currenly high priority for anyone in the ruby herd. Kind regards, Hans -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: baselayout-2 and volumes (raid, lvm, crypt, etc)
Doug Goldstein wrote: http://en.wikipedia.org/wiki/Scott_Tenorman_Must_Die I say we never piss Chris off again... ever... Thank YOU! That was hilarious! But seriously.. why don't you guys switch off reply-to munging, already?! http://archives.gentoo.org/gentoo-dev/msg_120444.xml -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: OT: was 2007.0 release
Rumen Yotov wrote: Somebody might want to know (for a new install) for how long (eventually) he/she will have to wait. You do not have to wait for the gentoo release engineering team. You will get an up to date install after running emerge -uvaD system in your fresh system. If the livecd is not up-to-date enough for you you can use any liecd in the linux world. The only thing you need is chroot support. Do not wait - Go ahead and start installing Gentoo now :) best regards, Stefan -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Deps (was Re: Empty DEPEND strings in virtuals)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Long wrote: Petteri Räty wrote: We should link this info to the devmanual. Yeah that was v. instructive. Since there's only 3 ebuilds left with the old syntax, the obvious question is: is there anything else holding up impl of the GLEP? package.prefer remains unimplemented, but I'd like to implement it or something similar. Also, would the preferred syntax be open to usage in eg recommended deps as opposed to mandatory ones? I appreciate that it's not the same GLEP or anything. I guess recommended deps can be represented by the existing USE flag conditional syntax [1], can't they? I'm also curious about impl date of ranged deps and use deps, without wanting to start a flamewar about the merits or lack thereof. I'm working on a new resolver design right now and I hope to have something usable within 1 or 2 months (sooner if we're lucky). The new design should make it relatively easy to implement all of the dependencies of bugs 144480 [2] and 155723 [3]. Zac [1] http://devmanual.gentoo.org/general-concepts/dependencies/index.html#use-conditional-dependencies [2] http://bugs.gentoo.org/show_bug.cgi?id=144480 [3] http://bugs.gentoo.org/show_bug.cgi?id=155723 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGIIQv/ejvha5XGaMRAvQjAKDLZG+ko6QTK1Be64xp8W5hoElvgwCg3auv DluAGZKZiOOEeQ8Ltw/A/8c= =ygOk -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] FUD post 3,023,972 from ciaranm spills into ad-hominem. Never!
There is no company behind dotProject. Instead you are dealing with a dedicated but 100% volunteer group who give their time and energy freely and frequently above and beyond the call of duty. The development team behind, under, in front of and frequently buried by dotProject are a great bunch of people. Kind, considerate, thoughtful, experienced, hard working and capable of immensely generous acts. They can also be opinionated, dogmatic, stubborn, or whatever else they want to be. We don't care, this is a great bunch of people and all dotProject users owe them a vote of thanks and maybe a beer when they run into them in the pub :) s/dotProject/gentoo/ and grow the fu, like i asked ya to in #paludis ;) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] FUD post 3,023,972 from ciaranm spills into ad-hominem. Never!
On 14/04/07, Steve Long [EMAIL PROTECTED] wrote: ... Can I ask why you choose to enlighten the mailing list with your views on this matter? I was given to understand it was a *development* mailing list, not a talk trash about someone 'cuz they banned me from their channel mailing list. -- -Charlie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] RFC - Keywording scheme
On Sat, Apr 14, 2007 at 07:32:12AM +0100, Steve Long wrote: Fabian Groffen wrote: This GLEP has been laying around for some long time now in my gleps dir. I nearly forgot about it. Anyway, feedback is appreciated. list-admin-hat Grobian: can you please resend your message to the list? This is the second message that I've seen lost in two days, and I'm annoyed now :-(. (This message is public so I can trace it as well). /list-admin-hat -- Robin Hugh Johnson Gentoo Linux Developer Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpyFQZTEo7jy.pgp Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] RFC - Keywording scheme
On 14-04-2007 01:19:41 -0700, Robin H. Johnson wrote: On Sat, Apr 14, 2007 at 07:32:12AM +0100, Steve Long wrote: Fabian Groffen wrote: This GLEP has been laying around for some long time now in my gleps dir. I nearly forgot about it. Anyway, feedback is appreciated. list-admin-hat Grobian: can you please resend your message to the list? Because I don't have it either, luckily there is GMane: http://thread.gmane.org/gmane.linux.gentoo.devel/48017 For ease of readers, some copy paste: For people that like reading it in html or via the web: http://dev.gentoo.org/~grobian/gleps/glep-keywords.html http://dev.gentoo.org/~grobian/gleps/glep-keywords.txt -- Fabian Groffen Gentoo on a different level GLEP: XXX2 Title: Keywording scheme Version: $Revision: 1.8 $ Last-Modified: $Date: 2007/04/13 17:26:35 $ Author: Diego Pettenò [EMAIL PROTECTED], Fabian Groffen [EMAIL PROTECTED] Status: Active Type: Standards Track Content-Type: text/x-rst Created: 11-Dec-2005 Post-History: 13-Apr-2007 Abstract This GLEP is a replacement of the keywording scheme from GLEP 22 [#GLEP22]_. The current use of keywords is retained in favour of 4-tuple keywords. This GLEP defines how current keywords are to be interpreted, and how future keywords should be constructed. Motivation == Although the state of GLEP 22 [#GLEP22]_ is final, its keywording scheme was never propagated through the tree. In fact, 4-tuple keywords are not used at all. This GLEP defines a keywording scheme that is compatible with the scheme that is currently in use. Rationale = The Gentoo/Alt project deals with different Operating Systems and architectures. Recently Gentoo/FreeBSD for Sparc was introduced after support for x86 platforms. This yielded in another new keyword. For these kind of platforms, a single field keyword is not enough to properly describe the OS and architecture. While four fields in a keyword are overkill, two fields in a keyword should be enough for everyone. Backwards Compatibility === The proposed keywording scheme is fully compatible with the current situation of the portage tree, this in contrast to GLEP 22. The variables provided by GLEP 22 can't be extracted from the new keyword, but since GLEP 22-style keywords aren't in the tree at the moment, that is not a problem. The same information can be extracted from the ``CHOST`` variable, if necessary. No modifications to ebuilds will have to be made. Specification = Keywords will consist out of two parts separated by a hyphen (``-``). The left hand part of the keyword is the architecture, such as `x86`, `sparc` or `ppc`. The right hand part indicates the operating system or distribution, such as `linux`, `macos`, `solaris` or `fbsd`. If the right hand part is omitted, it implies the operating system/distribution type is GNU/Linux. In such case the hyphen is also omitted. Examples of such keywords are ``x86`` and ``sparc-fbsd``. This is fully compatible with the current keywords used in the tree. Examples of OS/distributions for the right hand side of the keyword are: :: (linux) GNU/Linux (Gentoo biased, but not fixed) fbsd FreeBSD macosApple Mac OS solaris Sun Solaris Both architecture as well as OS/distribution are lower-case ASCII (alpha) numeric character sequences. A valid keyword matches the following expression: ``[a-z0-9]+(-[a-z0-9]+)?`` Note that no limit on the length of both fields in the keyword are imposed. However, we cannot overemphasize our preference to keep keywords small and sensible. .. [#GLEP22] GLEP 22, New keyword system to incorporate various userlands/kernels/archs, Goodyear, (http://glep.gentoo.org/glep-0022.html) Copyright = This document has been placed in the public domain.
[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Luca Barbato [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 14 Apr 2007 08:14:48 +0200: Adding more build time, requirements (yes, there are some tests that needs more ram and cpu to complete than the actual build phase) w/out ways to opt out is just hindering our users. Tell me about it. We (I'm involved upstream) had a bug in pan that required ~1.3 gig of memory to compile one of the tests... IF one was using gcc-3.4.x AND = -O2. I /think/ it was eventually resolved by turning off optimization for compiling the tests (not sure as gcc-3.x is not commonly used any more and I didn't follow the bug to full resolution), but it hit several users, including some Gentoo users back before gcc-4.x went stable, which we were able to help. That said, I don't believe /anyone/ is proposing doing something so un- Gentoo-like as not giving the user ways to opt-out. From my read, FEATURES=test would simply be the default, with individual ebuilds able to opt-out via restrict, and individual users being able to opt-out by simply setting the feature off, just as the opt-in by simply setting it on, now. I like the idea in general, tho I'd like to see something like FEATURES=bigtest implemented for the biggest/longest/most-resource- intensive/extra-dependencies tests. The extra granularity would give users a no-hassle way to enable tests on most packages, without forcing the huge tests on folks that weren't prepared for them, OR forcing maintainers to turn off (restrict) tests altogether in such cases. Restrict=test could then be reserved for those that are known to be broken, regardless of the resources thrown at them. -- 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh wrote: * src_test always called except if RESTRICT=test I don't think this would fit into EAPI, to me it's an implementation detail of the package manager, or why should the ebuild care about it? It's the best way of ensuring that ebuilds have a working src_test. Arch teams need this. Any arch team that wants tests by default on their arch can just add test to FEATURES in their arch profiles; magically the users running that arch will get the tests run (with USE=test set) by default. Users who don't want tests can always turn them off in make.conf. So I struggle to grasp why this must be mandated via EAPI, since the arches who want testing could just turn it on. -Alec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
not having it tested. That all depends. If having it tested means that it _will_ work, I'd be infavour of that. Well, the problem is, that a working test suite does not guarantee a working program, as well as a failing test suite doesn't necessarily mean that the program is broken. This doesn't mean that test suites aren't useful (i tend to write lot's of unit tests when I'm programming myself), but I would say that they are targeted at developers, both up- and downstream, not at end users. Thus, considering all arguments i've seen so far, i would highly appreciate it, if various src_test functions in the tree see some love, maybe encouraged due a changed policy, but i don't think that package managers should enable test suites by default. If you want some test action, try sys-devel/autoconf with tests activated with the package manager of your choice ;-) Matthias -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 13 Apr 2007 23:01:40 -0400: they realize they have no way at all of disabling the mandatory test ... RESTRICT is an ebuild variable, not a package manager variable this is why implementing it via the profile FEATURES works ... users can still easily opt out and in case of some catastrofuck and we havent screwed ourselves into a corner by mixing policy with spec Why not keep the feature but simply default it to ON instead of OFF? That's what I had assumed all along, and in fact seems to have been what was proposed since in several places the argument was that devs would be testing it anyway, thus implying the option remains NOT to test it. As I've said a couple times now, however, adding FEATURES=bigtest would IMO be useful, then let the ebuild use that for extra resource intensive tests or the like. Default would be FEATURES=test -bigtest, thus advancing the default QA for everyone, while continuing to allow users to opt-in/out entirely if desired. As for non-maintainer archs, the maintainer would test it on his arch, and arch-teams would test it on theirs before keywording stable. Those (like myself) running ~arch on non-maintainer archs should be prepared to live with the consequences of that choice anyway, including the occasional test failure on their arch because the maintainer didn't test it there and the arch-team hasn't gotten to it yet. -- 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Alec Warner napsal(a): Any arch team that wants tests by default on their arch can just add test to FEATURES in their arch profiles; magically the users running that arch will get the tests run (with USE=test set) by default. Users who don't want tests can always turn them off in make.conf. Even such change would piss off users. Having *no* way to turn off tests, uuuhhh please retire me *before* someone implements this, I'm not going to waste my time on totally pointless bugs filed by furious users. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Jakub Moc wrote: Alec Warner napsal(a): Any arch team that wants tests by default on their arch can just add test to FEATURES in their arch profiles; magically the users running that arch will get the tests run (with USE=test set) by default. Users who don't want tests can always turn them off in make.conf. Even such change would piss off users. Having *no* way to turn off tests, uuuhhh please retire me *before* someone implements this, I'm not going to waste my time on totally pointless bugs filed by furious users. FEATURES=-test? -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Jan Kundrát napsal(a): Jakub Moc wrote: Even such change would piss off users. Having *no* way to turn off tests, uuuhhh please retire me *before* someone implements this, I'm not going to waste my time on totally pointless bugs filed by furious users. FEATURES=-test? ... wouldn't do anything, because the suggestion was that src_test() should be mandatory in EAPI=1 and would run by default unless you have RESTRICT=test set in ebuild. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] New developer: Thomas Scharl (think4urs11)
It's my pleasure to introduce to you Thomas Scharl (also known as think4urs11), our latest addition joining the forum moderators. Thomas is joining us from Nürnberg (or Nuremberg), Germany, where he's currently working for an unnamed Networking/Security company. Please welcome Thomas as a new, fellow developer among us ! Regards, Christian -- Christian Heim phreak at gentoo.org GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Matthias Langer wrote: Hmm, as an arch tester, i completely agree that packages where src_test fails are an annoyance. However, I would not suggest to activate src_test by default, as for normal users, it just introduces another source of potential defects, without that much benefits. Instead, i think that arch teams should refuse to stable packages that fail with FEATURES=test and thus encourage ebuild developers to either fix their tests, or to deactivate them explicitly. That makes a lot of sense. How about exending it a tiny bit and asking for it to be policy for all ebuilds EAPI=1 not to be allowed into stable without RESTRICT=test, or a functional test suite on the arch in question? The last bit would be automagically checked by the arch team, if the ebuild has no RESTRICT=test, during normal stabilisation (I'd hope?) since the build would fail. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Thomas Scharl (think4urs11)
On Samstag, 14. April 2007, Christian Heim wrote: It's my pleasure to introduce to you Thomas Scharl (also known as think4urs11), our latest addition joining the forum moderators. Thomas is joining us from Nürnberg (or Nuremberg), Germany, where he's currently working for an unnamed Networking/Security company. Please welcome Thomas as a new, fellow developer among us ! Welcome Thomas! Wow, new gentoo members in less than 100km distance. I'm from Erlangen :) Zzam -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] RFC - Keywording scheme
On Saturday 14 April 2007, Fabian Groffen wrote: On 14-04-2007 01:19:41 -0700, Robin H. Johnson wrote: On Sat, Apr 14, 2007 at 07:32:12AM +0100, Steve Long wrote: Fabian Groffen wrote: This GLEP has been laying around for some long time now in my gleps dir. I nearly forgot about it. Anyway, feedback is appreciated. list-admin-hat Grobian: can you please resend your message to the list? Because I don't have it either, luckily there is GMane: http://thread.gmane.org/gmane.linux.gentoo.devel/48017 ive found hooking up my NNTP client to GMane and downloading missed e-mails from there works quite well if only i could say the same for our mailing list ;( -mike pgpwyH42OLDX7.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Steve Long kirjoitti: That makes a lot of sense. How about exending it a tiny bit and asking for it to be policy for all ebuilds EAPI=1 not to be allowed into stable without RESTRICT=test, or a functional test suite on the arch in question? The last bit would be automagically checked by the arch team, if the ebuild has no RESTRICT=test, during normal stabilisation (I'd hope?) since the build would fail. And this is different from the current policy in what way? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [GLEP] RFC - Keywording scheme
On Sat, Apr 14, 2007 at 07:47:12AM -0400, Mike Frysinger wrote: Because I don't have it either, luckily there is GMane: http://thread.gmane.org/gmane.linux.gentoo.devel/48017 ive found hooking up my NNTP client to GMane and downloading missed e-mails from there works quite well if only i could say the same for our mailing list ;( Unless Gmane has some deep foo in our servers that I don't know about, it's just as likely to be missing some list messages as our developers. The missing messages aren't in mlmmj's archive either. My rough stats show that we've had problems with ~1000 messages over the last 663 days - 1.5 messages per day. The core in this is a message not going to all recipients. As as I say, I have debug stuff on now, and it's given me one core dump that's pretty much garbage, and one other interesting bit of input. Anybody that feels like inspecting C code, look at mlmmj-1.2.14/src. getaddrsfromfd.c:27 - this mmap fails, 'Could not mmap fd: Invalid argument' mlmmj-send.c -- Robin Hugh Johnson Gentoo Linux Developer Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpH9LLCzNjPd.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Thomas Scharl (think4urs11)
Hi. Christian Heim wrote: It's my pleasure to introduce to you Thomas Scharl (also known as think4urs11), our latest addition joining the forum moderators. Thomas is joining us from Nürnberg (or Nuremberg), Germany, where he's currently working for an unnamed Networking/Security company. Please welcome Thomas as a new, fellow developer among us ! Regards, Christian Congrats on getting the official Gentoo colors! That means you have no more excuse to slacking ;) -- Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo-forums / Userrel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Thomas Scharl (think4urs11)
On Sat, Apr 14, 2007 at 01:01:38PM +, Jorge Manuel B. S. Vicetto wrote: Congrats on getting the official Gentoo colors! That means you have no more excuse to slacking ;) Unless of course you become forums admin, which is the best slacker job ever. Having that said i'm going back to the pool for my 16:45 massage and some more cocktails while you guys please do all the work. :-P cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpQqpJRjYyyv.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Thomas Scharl (think4urs11)
About time! :) Wernfried Haas wrote: On Sat, Apr 14, 2007 at 01:01:38PM +, Jorge Manuel B. S. Vicetto wrote: Congrats on getting the official Gentoo colors! That means you have no more excuse to slacking ;) Unless of course you become forums admin, which is the best slacker job ever. Having that said i'm going back to the pool for my 16:45 massage and some more cocktails while you guys please do all the work. :-P cheers, Wernfried -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Sat, 14 Apr 2007 02:44:31 -0700 Alec Warner [EMAIL PROTECTED] wrote: Any arch team that wants tests by default on their arch can just add test to FEATURES in their arch profiles; magically the users running that arch will get the tests run (with USE=test set) by default. Users who don't want tests can always turn them off in make.conf. So I struggle to grasp why this must be mandated via EAPI, since the arches who want testing could just turn it on. And for at least the third time... That can't be done because there are too many EAPI 0 packages that will fail, which leads to user confusion. But bringing it in for EAPI 1 ensures a smooth gradual migration. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FUD post 3,023,972 from ciaranm spills into ad-hominem. Never!
On Sat, 14 Apr 2007 08:43:39 +0100 Steve Long [EMAIL PROTECTED] wrote: There is no company behind dotProject. What on earth are you on about? Please stop posting uninformed nonsense to the list. The noise is getting in the way of sensible discussion. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] New Developer: Tobias Heinlein (keytoaster)
It's my pleasure to introduce to you Tobias Heinlein (also known as keytoaster on IRC), our latest addition joining the docs people as follow-up lead for the german documetation. He's already been an arch tester for the amd64 herd for quite some time. Tobias is joining us from Hamm, Germany where he's currently finishing the junior high school. According to Tobias, he's skilled with writing *cough* PHP, a bit C and python. When Tobias isn't in front of his computer, he's trying to read a bit, spend some late nights out with friends, or trying to get some sleep in when he can. Please welcome Tobias as a new, fellow developer among us ! Regards, Christian -- Christian Heim phreak at gentoo.org GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Sat, 2007-04-14 at 14:58 +0300, Petteri Räty wrote: Steve Long kirjoitti: That makes a lot of sense. How about exending it a tiny bit and asking for it to be policy for all ebuilds EAPI=1 not to be allowed into stable without RESTRICT=test, or a functional test suite on the arch in question? The last bit would be automagically checked by the arch team, if the ebuild has no RESTRICT=test, during normal stabilisation (I'd hope?) since the build would fail. And this is different from the current policy in what way? Hmm, i don't want to offend anyone, i don't even want to say that it was wrong to push these to stable regarding the current situation, but what, for example, about these? bug 165085 bug 133002 bug 156572 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Ciaran McCreesh wrote: On Sat, 14 Apr 2007 02:44:31 -0700 Alec Warner [EMAIL PROTECTED] wrote: Any arch team that wants tests by default on their arch can just add test to FEATURES in their arch profiles; magically the users running that arch will get the tests run (with USE=test set) by default. Users who don't want tests can always turn them off in make.conf. So I struggle to grasp why this must be mandated via EAPI, since the arches who want testing could just turn it on. And for at least the third time... That can't be done because there are too many EAPI 0 packages that will fail, which leads to user confusion. But bringing it in for EAPI 1 ensures a smooth gradual migration. Well we could implement this differently. One could enable RESTRICT=test implicitly for EAPI=0, and drop it for EAPI=1. At least there your making the change as apart of the ebuild's API and not as some random package manager implementation detail. Everyone can turn tests on all they like; only ebuilds with EAPI=1 will get tested. The whole argument against doing it the other way is that running tests, outside of RESTRICT, has absolutly nothing to do with any kind of api; which is why I'm against it. At that point arch teams would essentially be hijacking EAPI for something it was never meant to cover. We all know how bad that can be no? -Alec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New Developer: Tobias Heinlein (keytoaster)
On Sat, 14 Apr 2007 18:14:18 +0200 Christian Heim [EMAIL PROTECTED] wrote: It's my pleasure to introduce to you Tobias Heinlein (also known as keytoaster on IRC), our latest addition joining the docs people as follow-up lead for the german documetation. He's already been an arch tester for the amd64 herd for quite some time. Tobias is joining us from Hamm, Germany where he's currently finishing the junior high school. According to Tobias, he's skilled with writing *cough* PHP, a bit C and python. When Tobias isn't in front of his computer, he's trying to read a bit, spend some late nights out with friends, or trying to get some sleep in when he can. Please welcome Tobias as a new, fellow developer among us ! Regards, Christian w00t! You better not stop doing AT work for Gentoo/AMD64... ;) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Sat, 14 Apr 2007 12:17:24 -0700 Alec Warner [EMAIL PROTECTED] wrote: The whole argument against doing it the other way is that running tests, outside of RESTRICT, has absolutly nothing to do with any kind of api; which is why I'm against it. At that point arch teams would essentially be hijacking EAPI for something it was never meant to cover. We all know how bad that can be no? Ebuild functions are an EAPI issue. They address how ebuilds are used by the package manager. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Change in mentoring requirements
p Before you can mentor anyone, you must have been with Gentoo for at least six -months or must be a project lead. +months. Previously being a project lead was enough too but with GLEP 39 anyone +can create new projects. /p /body Regards, Petteri -- Gentoo/Recruiters lead Gentoo/Java lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New Developer: Tobias Heinlein (keytoaster)
Christian Heim wrote: Tobias is joining us from Hamm, Germany where he's currently finishing the junior high school. Wow he must be really young then. But I cannot find the adequate german translation for junior high school. What is it? Welcome to the devs! -Stefan -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Change in mentoring requirements
Hi. Petteri Räty wrote: p Before you can mentor anyone, you must have been with Gentoo for at least six -months or must be a project lead. +months. Previously being a project lead was enough too but with GLEP 39 anyone +can create new projects. /p /body Regards, Petteri -- Gentoo/Recruiters lead Gentoo/Java lead Petteri, I assumed this was already the case and it makes perfect sense to me. There's one thing that you're not addressing though. We have different types of developers amongst us, so how do we count the 6 months period? Let me explain more fully. At this point, I could mentor someone into becoming a new moderator in the forums, but I don't think anyone would support me being an ebuild dev mentor - not being one myself yet. IIRC, documentation devs don't need to be ebuild devs. Does anyone propose that I could be a docs dev mentor - not being part of the team? Finally, should a 6+ month ebuild dev, recently becoming part of the docs or forums moderation team, be allowed to be a mentor for those teams? Perhaps we should require that the dev be part of Gentoo for at least six months and in the case of mentoring for the forums or the docs team, that he/she has the blessing of the team lead(s) - in case the dev isn't part of the respective team for at least X months. Do we want X to be 6 months? Anyone agrees/disagrees? -- Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo-forums / Userrel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New Developer: Tobias Heinlein (keytoaster)
Stefan Schweizer wrote: Wow he must be really young then. Yup, I'm 16, phreak was shocked as well. But I cannot find the adequate german translation for junior high school. What is it? That should be Realschule in German. ;) Welcome to the devs! -Stefan Thanks. Best regards, -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] app-misc/klive removal
On 07/04/07, Daniel Drake [EMAIL PROTECTED] wrote: klive isn't that useful and I don't have enough time to maintain it. There are several bugs kicking about. If nobody takes over, I'll package.mask it on April 14th and remove it on April 28th. I've fixed both bugs and added myself explicitly to metadata. -- -Charlie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New Developer: Tobias Heinlein (keytoaster)
On 15/04/07, Tobias Heinlein [EMAIL PROTECTED] wrote: Stefan Schweizer wrote: Yup, I'm 16, phreak was shocked as well. Welcome to the young ones :) -- -Charlie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: app-vim/doxygen-syntax
A modified version of app-vim/doxygen-syntax-1.15 is already included in vim7, no point in keeping this around. See Bug #174637. Scheduled for removal in 30 days. -- Mike Kelly signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Change in mentoring requirements
On Sat, 14 Apr 2007 22:46:10 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote: We have different types of developers amongst us, so how do we count the 6 months period? Let me explain more fully. At this point, I could mentor someone into becoming a new moderator in the forums, but I don't think anyone would support me being an ebuild dev mentor - not being one myself yet. It's long been the case that individual projects can set additional criteria for recruits joining them -- I don't see why that shouldn't also apply to people mentoring recruits to join that project. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rite media-gfx/qiv
# Samuli Suominen [EMAIL PROTECTED] (15 Apr 2007) # Using deprecated gdk functions from imlib. # Masked for removal in 30 days. See bug #166009. # Use gqview or mirage instead. media-gfx/qiv -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Saturday 14 April 2007, Matthias Langer wrote: bug 165085 i'd do some research into the glibc situation before you go pointing at it -mike pgpe73v4Qiw7K.pgp Description: PGP signature
