[gentoo-dev] LinuxWorld pictures and Dev House
Quite the crew: http://www.flickr.com/photos/novas0x2a/1079324702/. Also, http://www.flickr.com/photos/novas0x2a/1079315370/ (If anyone in the pictures wants to be tagged, let me know, or just send me a friend request and then do it yourself) Solar must be a vampire- he didn't end up in any of my pictures. Also, I'd like to extend an invitation to anyone who lives in the northern california (USA) area. We do this geek party called Super Happy Dev House every few weeks, and the next one is tomorrow, Saturday, August 11th. It's free, and there will be food and geeks. If you want more information, check out [1]. I know it's sort of last minute, but we're going from 2pm until 1am, and you can show up or leave at any time. Come by if you get a chance :) 1) http://www.superhappydevhouse.org/letter19 -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Some ideas on how to reduce territoriality
Petteri Räty <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 10 Aug 2007 21:19:13 +0300: >> (OTOH, now that portage is recompressing >> all such files based on the PORTAGE_COMPRESS setting, I suppose it's >> possible the user screwed up their PORTAGE_COMPRESS setting. Still, if >> they screw up portage variables they should /expect/ it to have >> problems.) >> >> > No. PORTAGE_COMPRESS doesn't affect what's inside upstream tarballs :) > Read /usr/lib/portage/bin/dodoc and you will see that it's actually > dodoc that calls ecompress :) Thus the point, tho I changed thoughts in mid-stream and wasn't entirely clear about it so it's understandable that you missed it. I had asked in which cases the file might be missing, true, and this doesn't fit there, correct. However, then I got thinking how else dodoc might fail. If you have a dodoc || die, and dodoc calls ecompress and that fails, then dodoc will fail as well, right? So if the user has screwed up PORTAGE_COMPRESS, that will ultimately cause the dodoc to fail, where it wouldn't have for the maintainer who had a working ecompress. I was simply saying that's one way it could fail, that the maintainer would have no control over, but that even then, it's nothing we can really worry about since on Gentoo, we ultimately leave a user to their own folly if they screw up make.conf. There's a point beyond which we simply assume they are grown up enough to handle their own misconfigurations. Donnie does have a valid point, however. There are potential corner cases with unusual USE flags. I'd still like to see a hard example, however, as /intuitively/, it's difficult for me to envision a case where that would apply to what is after all /documentation/. The case for dodoc (as opposed to say, dobin or dolib) would seem to me to be fairly straigntforward, either it's used or not, and it's hard to envision where obscure USE flags would affect it to the point of making testing impractical. I wouldn't call the "doc" USE flag "obscure" enough to qualify, but conceivably there's a package out there where dodoc is indeed called in obscure enough circumstances that testing would be difficult. (This is keeping in mind that -rX bumps wouldn't normally need to test the dodoc anyway, since it'll be using the same tarball as the original ebuild and dodoc shouldn't normally have changed. Thus, testing the dodoc conditions should normally be necessary only on tarball containing the target doc change.) -- 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] Re: Some ideas on how to reduce territoriality
On 00:25 Sat 11 Aug , Petteri Räty wrote: > It's not really about the amount of combinations but the amount of code > paths in the ebuild. Yes, you have a good point, as it applies to ebuilds. But there are still potential incompatibilities in the source itself that this cannot solve. At least for the ebuild side, perhaps we should get some sort of automated tool that can analyze all possible code paths and spit out a list. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
William L. Thomson Jr. kirjoitti: > On Fri, 2007-08-10 at 12:32 -0700, Donnie Berkholz wrote: >> On 22:09 Fri 10 Aug , Petteri Räty wrote: >>> And you think maintainers are not needed to test use flags they think >>> are uncommon? >> I think my computer isn't powerful enough to rebuild xorg-server with every >> possible combination of USE flags every time I commit to it, at 45 minutes >> per >> build. > > What about distcc? Sounds like we need to get you some more powerful > hardware to develop on or etc. Since xorg is a fairly major package. > Understandably hard to test every time, but ideally all should be. > It's not really about the amount of combinations but the amount of code paths in the ebuild. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
William L. Thomson Jr. wrote: > What about distcc? Sounds like we need to get you some more powerful > hardware to develop on or etc. Since xorg is a fairly major package. > Understandably hard to test every time, but ideally all should be. Well, last time I checked, PHP had about 90 USE flags. I guess one should grab a lot of beer for that... Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Ruby ebuild "howto" question
As soon as you define your own src_install() function in your ebuild, it will override the eclass's src_install function. Thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ruby ebuild "howto" question
On 10/08/07, Lionel Bouton <[EMAIL PROTECTED]> wrote: > I'm quite the newbie with eclasses so the only thing I can think of > right now is to *not* inherit the gems eclass, hand-copy the methods > from the gems eclass and modify them to suit my needs. > > Is there a better way? Yes, see: http://devmanual.gentoo.org/eclass-writing/index.html#export-functions Regards, -- Richard Brown -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
On Fri, 2007-08-10 at 12:32 -0700, Donnie Berkholz wrote: > On 22:09 Fri 10 Aug , Petteri Räty wrote: > > And you think maintainers are not needed to test use flags they think > > are uncommon? > > I think my computer isn't powerful enough to rebuild xorg-server with every > possible combination of USE flags every time I commit to it, at 45 minutes per > build. What about distcc? Sounds like we need to get you some more powerful hardware to develop on or etc. Since xorg is a fairly major package. Understandably hard to test every time, but ideally all should be. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
On 22:09 Fri 10 Aug , Petteri Räty wrote: > And you think maintainers are not needed to test use flags they think > are uncommon? I think my computer isn't powerful enough to rebuild xorg-server with every possible combination of USE flags every time I commit to it, at 45 minutes per build. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Ruby ebuild "howto" question
Hi, I want to package a ruby daemon (stompserver which I'm currently working on) and wonder how to add an init script to the package. I already have a gem wrapped in an ebuild (probably one of the easiest packaging you could ever dream of) but I'd like to put an init script file in the files subdir and doinitd it, which if I'm not mistaken should take place in src_install. Unfortunately src_install is defined in the gems eclass and I couldn't find any hooks in there which would allow me to define a function for installing "out of gem" files. I'm quite the newbie with eclasses so the only thing I can think of right now is to *not* inherit the gems eclass, hand-copy the methods from the gems eclass and modify them to suit my needs. Is there a better way? Lionel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
Donnie Berkholz kirjoitti: > On 12:40 Fri 10 Aug , Duncan wrote: >> Agreed. Within the limited scope of dodoc, under what legitimate >> circumstances might a file /not/ be there to "dodoc" for a user, when >> it's there for a maintainer? (OTOH, now that portage is recompressing >> all such files based on the PORTAGE_COMPRESS setting, I suppose it's >> possible the user screwed up their PORTAGE_COMPRESS setting. Still, if >> they screw up portage variables they should /expect/ it to have problems.) > > if use uncommon_use_flag && ! use another_uncommon_flag; then > dodoc foo > fi > > Thanks, > Donnie And you think maintainers are not needed to test use flags they think are uncommon? Regards, signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
On 12:40 Fri 10 Aug , Duncan wrote: > Agreed. Within the limited scope of dodoc, under what legitimate > circumstances might a file /not/ be there to "dodoc" for a user, when > it's there for a maintainer? (OTOH, now that portage is recompressing > all such files based on the PORTAGE_COMPRESS setting, I suppose it's > possible the user screwed up their PORTAGE_COMPRESS setting. Still, if > they screw up portage variables they should /expect/ it to have problems.) if use uncommon_use_flag && ! use another_uncommon_flag; then dodoc foo fi Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
Duncan kirjoitti: > Petteri Räty <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Fri, 10 Aug 2007 10:45:15 +0300: > >> Alin Năstac kirjoitti: >>> Duncan wrote: If the user sees it, it means the maintainer failed to do his job. The tarball couldn't have even been changed upstream without notice, since it'd then fail the sanity/security/signing checks. I think that's the suggestion, that it be mandatory for maintainers to deal with, and the user shouldn't ever see it. >>> You seems to forget the fact that Gentoo is a source distro and as >>> such, emerge foo can fail on users boxes while on maintainer's box >>> works like a charm. >>> >>> >> Indeed but this really doesn't have much to do with using || die with >> dodoc. > > Agreed. Within the limited scope of dodoc, under what legitimate > circumstances might a file /not/ be there to "dodoc" for a user, when > it's there for a maintainer? (OTOH, now that portage is recompressing > all such files based on the PORTAGE_COMPRESS setting, I suppose it's > possible the user screwed up their PORTAGE_COMPRESS setting. Still, if > they screw up portage variables they should /expect/ it to have problems.) > No. PORTAGE_COMPRESS doesn't affect what's inside upstream tarballs :) Read /usr/lib/portage/bin/dodoc and you will see that it's actually dodoc that calls ecompress :) Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Friendly reminder. Take care of your keywords
Hi *: This is a friendly reminder for all the people who work in the arch teams and make the keywording process. All of us know that the keyword process is hard and sometimes not very funny but it should be done with special care because is the final test between the software and the users/devs community out there. Lately we have some tools that save us to access to the bugzilla web interface to make comments or modify bugzie fields. Please, if you are going to use them, be sure of read all the comments in the stabilization bugs before because sometimes there are things to fix or important comments that can make the process to stop. We can't mark something even ~arch if there are compilation errors (reached via USE flags or not) or you found deficiencies in the use of the software until the maintainer can help us to know how to fix them or use the app properly. Arch teams are usually the last layer of QA so, please, take care of your arch, take care of your users, take care of Gentoo. Anyway, you know I love you all. P.D: please, if you don't have anything positive to say or add something of value to this thread, keep it out of the list. Thanks. -- Jose Luis Rivero <[EMAIL PROTECTED]> Gentoo/Doc Gentoo/Alpha -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Some ideas on how to reduce territoriality
Petteri Räty <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 10 Aug 2007 10:45:15 +0300: > Alin Năstac kirjoitti: >> Duncan wrote: >>> If the user sees it, it means the maintainer failed to do his job. >>> The tarball couldn't have even been changed upstream without notice, >>> since it'd then fail the sanity/security/signing checks. I think >>> that's the suggestion, that it be mandatory for maintainers to deal >>> with, and the user shouldn't ever see it. >>> >>> >> You seems to forget the fact that Gentoo is a source distro and as >> such, emerge foo can fail on users boxes while on maintainer's box >> works like a charm. >> >> > Indeed but this really doesn't have much to do with using || die with > dodoc. Agreed. Within the limited scope of dodoc, under what legitimate circumstances might a file /not/ be there to "dodoc" for a user, when it's there for a maintainer? (OTOH, now that portage is recompressing all such files based on the PORTAGE_COMPRESS setting, I suppose it's possible the user screwed up their PORTAGE_COMPRESS setting. Still, if they screw up portage variables they should /expect/ it to have problems.) -- 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] Re: Some ideas on how to reduce territoriality
Alin Năstac kirjoitti: > Duncan wrote: >> If the user sees it, it means the maintainer failed to do his job. The >> tarball couldn't have even been changed upstream without notice, since >> it'd then fail the sanity/security/signing checks. I think that's the >> suggestion, that it be mandatory for maintainers to deal with, and the >> user shouldn't ever see it. >> > > You seems to forget the fact that Gentoo is a source distro and as such, > emerge foo can fail on users boxes while on maintainer's box works like > a charm. > Indeed but this really doesn't have much to do with using || die with dodoc. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
Duncan wrote: > If the user sees it, it means the maintainer failed to do his job. The > tarball couldn't have even been changed upstream without notice, since > it'd then fail the sanity/security/signing checks. I think that's the > suggestion, that it be mandatory for maintainers to deal with, and the > user shouldn't ever see it. > You seems to forget the fact that Gentoo is a source distro and as such, emerge foo can fail on users boxes while on maintainer's box works like a charm. As a maintainer, you cannot possibly test all the USE/installed libs/CFLAGS combinations. I don't say maintainer shouldn't fix whatever problems has his package, but don't be in such a hurry to blame someone when you happen to find a bug. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
On Tue, 2007-08-07 at 10:12 +, Duncan wrote: > > Isn't the point, however, that if it's a die if the do* is on a file that > no longer exists, the maintainer will see it when they test, take care of > it, and as a result, it shouldn't ever hit the user? Yes, exactly the idea. > If the maintainer sees it, they can either investigate, if the judge it > worth it, or simply kill the do* in question. Yep > If the user sees it, it means the maintainer failed to do his job. I > think that's the suggestion, that it be mandatory for maintainers to > deal with, and the user shouldn't ever see it. Dang your better than most carpenters, hitting the nail on the head repeatedly :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
