[gentoo-dev] Re: Packages needing manitainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Volkov wrote: > В Вск, 08/03/2009 в 22:54 +0100, Rémi Cardona пишет: >> Le 08/03/2009 21:38, Tomáš Chvátal a écrit : >>> net-misc/mDNSResponder >> How about dropping this one in favor of avahi? Or am I missing something >> obvious? > > Are they completely interchangeable? Last time (well, the only time) I > built samba 3.3.0 it linked against dns_sd and it have no provisions to > be built against avahi as I see... > net-dns/avahi[mdnsresponder-compat] provides /usr/lib*/libdns_sd.* as a wrapper around its own libraries, so it should Just Work(tm). Also, looking at the version of samba I have installed on my system, it doesn't appear to be linked against libdns_sd.so at all. I'm not sure if it was simply removed from a later version, or what, as I do have avahi installed on this machine. - -- ABCD -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm3FM4ACgkQOypDUo0oQOo6HwCfRk+s6yl6cm0ajApUUiN3fcWC 1ZMAoJ7gz4ZWiQtEyp0AxgPaWiRFg4qi =D/UT -END PGP SIGNATURE-
Re: [gentoo-dev] bzr.eclass: The next level (this time with patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann schrieb: > As one can easily see: While the fetch time for co and lw-co are more or > less equal, the export time is not. As one can say, that each package is > at least exported as often as updated (if not more often), this makes > the lw co operation more or less a no-no. (Waiting one minute to get a > snapshot of a medium-sized project? ... ehm - NO) One note - just saw the following for the bzr-1.13_rc1 release notes: "Lightweight Checkouts and Stacked Branches should both be much faster over remote connections. Building the working tree now batches up requests into approx 5MB requests, rather than a separate request for each file. (John Arbash Meinel)" So perhaps it is improved for this new release. Have to retest soon. (I also wonder, why the hell the export of the lw-co takes so long ... it more or less just needs to copy the files... I cannot see the need to fetch each file again from the remote repo. Perhaps this is worth a bzr-bug.) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm3C9MACgkQ4UOg/zhYFuDAuwCePrNj2rQ4au99QziYZl7qpe9a PFYAn2ZuRqp3vpNLUwcASN6wk8NaqL/s =Li4s -END PGP SIGNATURE-
Re: [gentoo-dev] bzr.eclass: The next level (this time with patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have some doubts about the usage of "co --lightweight" instead of the plain "co". The only reason I can see is the reduced disk-space needed. Because concerning time, the lightweight checkouts take (way) longer... Just some bash-time tests done with the portage bzr-repo (lp:portage -- 6470 revisions). I used bzr-1.12: method fetch export == = == branch: ~47s / ~2s stacked branch: ~68s / ~49s checkout: ~46s / ~2s lightweight co: ~50s / ~51s As one can easily see: While the fetch time for co and lw-co are more or less equal, the export time is not. As one can say, that each package is at least exported as often as updated (if not more often), this makes the lw co operation more or less a no-no. (Waiting one minute to get a snapshot of a medium-sized project? ... ehm - NO) But for completeness: size with co: 24MB - with lw-co: 3,1MB So I'd vote for switching back to using normal checkouts (or branches - they don't really differ in bzr for that matter). Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm3CeIACgkQ4UOg/zhYFuAmmQCeL/BqnCClR5CBapvAvO3Og0Tu MBEAoINCwaNfnAYkFyxmaB2kR5BeHMsj =37WD -END PGP SIGNATURE-
Re: [gentoo-dev] Packages needing manitainer
В Вск, 08/03/2009 в 22:54 +0100, Rémi Cardona пишет: > Le 08/03/2009 21:38, Tomáš Chvátal a écrit : > > net-misc/mDNSResponder > > How about dropping this one in favor of avahi? Or am I missing something > obvious? Are they completely interchangeable? Last time (well, the only time) I built samba 3.3.0 it linked against dns_sd and it have no provisions to be built against avahi as I see... -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
AllenJB wrote: Markos Chandras wrote: On Tuesday 10 March 2009 14:15:36 Thilo Bangert wrote: Bugs aren't a good way to keep in touch with developers, that's what irc is for. while i dont necessarily think, that bugzi is the best way to stay in contact with me, it surely is a better way than IRC - on which i am close to never. the presumption seems to be, that as a dev one has to be available via IRC. it has long been my feeling that Gentoo as a project could realize more of its potential by better integrating people who dont do IRC. kind regards Thilo To be honest , I don't agree with that. Being around on irc is quite helpful to get direct feedback from users and fix bugs before they hit more users. This is a good way to reduce the amount of bugs that hit bugzilla. While IRC is undoubtedly a useful communication medium, it is pretty much a "here and now" thing. I believe that Gentoo would benefit quite a lot if teams started using more permanent forms of communication such as blogs, wikis or websites. Not only would this allow the current set of developers within a team to know what one another are up to and what needs to be done, but it would also allow those who are not so intimately involved (both other devs, contributors and users) to keep up to date and contribute as well as leaving something for future developers to be able to look back on and see what options / improvements / etc were considered / done in the past. I recently wrote a blog post that went somewhat along these lines: http://allenjb.me.uk/blog/why-only-think-about-projects-for-gsoc As someone who's very interested in getting involved in Gentoo Development, I often find it hard to gather information on what projects / people are up to, what's currently going on and what the plans for the future are. AllenJB Just wanted to quickly add mailing lists to the explicitly mentioned venues for improved communication. As a quick example, I'm interested in the PR / Newsletter side of Gentoo, but I find it very hard to keep up-to-date. I recently learned that there's a new blog-like version of the newsletter in development but I've heard nothing else about it and searching hasn't turned up anything. While I am on the gmn irc channel, I don't have time to read through all the backlogs for relvent information. I am also on the gentoo-pr mailing list (among many others, as well as checking on the lists via gmane) and it's basically completely silent. I'm currently waiting to catch one of two devs who might be able to give me more information on IRC. To all eyes looking from the outside in, unless they happen across the one forum thread I did, the newsletter is dead and nothing is being done about it, which gives a poor view of the state of affairs within Gentoo Development. To take the bus analogy to this, if these 2 developers are hit by a bus, then who knows what's currently going on with the newsletter and where all the resources are? I have said it before and I will say it again, yes the newsletter may be a current weak point for Gentoo, but it's a very obvious one because it's the one that's visible to everyone in the community. I still think my points are valid for any area of Gentoo development tho. AllenJB
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
Markos Chandras wrote: On Tuesday 10 March 2009 14:15:36 Thilo Bangert wrote: Bugs aren't a good way to keep in touch with developers, that's what irc is for. while i dont necessarily think, that bugzi is the best way to stay in contact with me, it surely is a better way than IRC - on which i am close to never. the presumption seems to be, that as a dev one has to be available via IRC. it has long been my feeling that Gentoo as a project could realize more of its potential by better integrating people who dont do IRC. kind regards Thilo To be honest , I don't agree with that. Being around on irc is quite helpful to get direct feedback from users and fix bugs before they hit more users. This is a good way to reduce the amount of bugs that hit bugzilla. While IRC is undoubtedly a useful communication medium, it is pretty much a "here and now" thing. I believe that Gentoo would benefit quite a lot if teams started using more permanent forms of communication such as blogs, wikis or websites. Not only would this allow the current set of developers within a team to know what one another are up to and what needs to be done, but it would also allow those who are not so intimately involved (both other devs, contributors and users) to keep up to date and contribute as well as leaving something for future developers to be able to look back on and see what options / improvements / etc were considered / done in the past. I recently wrote a blog post that went somewhat along these lines: http://allenjb.me.uk/blog/why-only-think-about-projects-for-gsoc As someone who's very interested in getting involved in Gentoo Development, I often find it hard to gather information on what projects / people are up to, what's currently going on and what the plans for the future are. AllenJB
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
2009/3/10 Markos Chandras : > Gentoo as a project could realize > more of its potential by better integrating people who dont do IRC. Yes. Let's integrate them by introducing IRC to them.
Re: [gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives
On Tue, Mar 10, 2009 at 4:58 PM, Christian Faulhammer wrote: > > Having the EAPI stored outside the ebuild's scope is generally a bad > idea, because someone has to tell you that the ebuild you just > downloaded from Bugzilla is EAPI x. And the package manager will be > totally confused when assuming an EAPI that is wrong. So the EAPI > should be stored inside (best solution regarding giving ebuilds away) > or in the file name (best compromise regarding the whole situation. > Most ebuilds in Bugzilla have a proper name. I suggest you to download them with pybugz: $ bugz attachment that will download it with the proper name. Regards, -- Santiago M. Mola Jabber ID: cooldw...@gmail.com
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
On Tuesday 10 March 2009 14:15:36 Thilo Bangert wrote: > > Bugs aren't a good way to keep in touch with developers, that's what > > irc is for. > > while i dont necessarily think, that bugzi is the best way to stay in > contact with me, it surely is a better way than IRC - on which i am close > to never. > > the presumption seems to be, that as a dev one has to be available via > IRC. it has long been my feeling that Gentoo as a project could realize > more of its potential by better integrating people who dont do IRC. > > kind regards > Thilo To be honest , I don't agree with that. Being around on irc is quite helpful to get direct feedback from users and fix bugs before they hit more users. This is a good way to reduce the amount of bugs that hit bugzilla. -- Markos Chandras (hwoarang) Gentoo Linux Developer Qt/KDE/Sound/Sunrise signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Mon, Mar 9, 2009 at 3:26 PM, Ciaran McCreesh < ciaran.mccre...@googlemail.com> wrote: > On Sun, 08 Mar 2009 08:49:16 +0100 > Tiziano Müller wrote: > > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ > > Here're some more easy ones. > > First up, un-optionaling some optional things. No impact for developers: > > * PROPERTIES must be cached properly (it's optional in current EAPIs) +1 from me > > > * DEFINED_PHASES must be supported (ditto) +1 from me > > > Next, some probably easy but long standing features: > > * src_test run unless RESTRICTed or explicitly disabled by the user (bug > 184812) I'd love to but please look at the most recent comment I've made on the bug > > > * have econf run ./configure with --disable-dependency-tracking and > --enable-fast-install (bug 211529) +1 from me. Did we ever test autoconf 2.13 based stuff? > > > * Limit values in $USE to ones in $IUSE (bug 176467). The existing > behaviour's majorly annoying; time for the package manager to start > enforcing things strictly. definitely +1 from me. I've been trying to put kernel_linux and such in my ebuilds already to improve this. > > > Some things we should probably sort out: > > * The list of extensions for unpack probably needs a couple of new > things. We also need a way for the actual program being used for the unpack to be added to DEPEND. > > > * Provide ebuilds a way to differentiate between updates and removals > (bug 205557), since the way devmanual says to do it got broken by a > non-EAPIed change. This one's slightly trickier than initially > apparent, because a solution's needed for the weird cases. One > example is if you have foo-1:1 and foo-2:2 installed, and you're > installing foo-2:1. In this case, it's both a reinstall and an > upgrade. One possibility is a REPLACING_VERSIONS variable that > contains a list of all versions being replaced, along with a > REPLACED_BY_VERSION variable for the pre/postrm part. +1 from me > > > Not sure if these can go in in time for Portage or not: > > * Utility commands, even the ones that aren't functions, should die. To > get a non-die version, prefix the command with nonfatal (e.g. > 'nonfatal dodoc README', which just returns non-zero on failure > rather than splatting). +1 from me > > > * Calling unpack on an unrecognised extension should be fatal, unless > --if-compressed is specified. The default src_unpack needs to use > this. +1 from me > > > * pkg_info should work on things that aren't installed, as well as > things that are. We'd need to properly educate people about this because I'm pretty sure a bunch of pkg_info()'s require the actual package to be installed currently. > > > -- > Ciaran McCreesh >
[gentoo-dev] Maintainence of /usr/portage/skel.* and some updates for skel.ebuild
I would like to know, if there is some policy about editing skel.* files or who owns/maintains them. Additionally, i suggest some changes to skel.ebuild: -fix the comment for inherit (afaik $(getlibdir) is provided by multilib eclass) -comment out the inherit line -comment out DEPEND and RDEPEND -remove the || die from econf -comment out the complete src_compile Since it seems like people change it at will and those are minor changes, i will do them in a few days, if noone has a good reason against them. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Developer Retirements
Doug Goldstein wrote: > > Granted the people I've recently talked to about this or the people I > remember bringing this issue up in the past had this happen to them > before we had this firm policy in place so really you're addressing a > lot of the issues. > > But the whole act of making them go through all the hoops as a brand new > developer is somewhat put off-ish to people wanting to come back. I > honestly can't think of one developer that's come back and hasn't been > up in arms about being made to go through all the hoops of a new developer. The quizzes haven't changed that radically in the last couple of year. Personally I wouldn't want people who have been inactive for ages to just start committing as their information is more quite likely outdated. Doesn't the fact that they complain about having to do work to answer the quizzes prove this? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Monday March 09 Ciaran McCreesh wrote: > > * src_test run unless RESTRICTed or explicitly disabled by the user > (bug 184812) Yes, and I would go even further: keep src_test for unit tests and some kind of pkg_posttest for either a routine to test the package once installed or an elog test recipe, a bit like the emacs testing plans. It could be useful for arch testers, guis, and revdep tests. It would force packagers to define an omitted src_test when upstream actually had one. As mentioned by Christian, src_test is desirable in sci packages to get consistent results, but sci packages depend on lots of others, so you can't limit tests to some categories. And yes, you can't revdep test everything, but you can reduce bug load. It seems to be controversial, so unfortunately does not look like a good candidate for a flash EAPI upgrade. But really, don't dismiss it just because your pet package doesn't pass tests or it takes too long. One solution for packages taking too long to compile is not dismissing tests but a good binary package system. -- Sébastien signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Developer Retirements
2009/3/10 Doug Goldstein : > So really an effective solution might be for the recruiters/retirement staff > to change a user's shell with a script that spits out a message that says > something to the effect of: > > "You have been inactive for a while. Please contact recruiters to re-enable > your account. This was done as a security measure." > > Obviously a little friendlier would be better but everyone gets the gist. > That'll prevent them from logging into infra boxes and from being able to do > a commit. > First of all there's been a lot of returning devs from whom I heard no word of complaint about the procedure. Bonsaikitten is one of them if this argument really requires an example. Now, if someone can't, has no time or is unwilling to redo his quiz... what makes you think this person will make a good developer later on? What will ensure quality of his contributions? After months or (in most cases) years of not being a developer it's very likely the person is out of touch with most current things in Gentoo and a conversation with a recruiter may be really good learning experience. I heard multiple times from recruiters that this is procedure is necessary for returning developers. If you ask them, I'm sure they will confirm those devs often need such refreshing and also are appreciating the time put into it from the recruiting team. Finally, what you are proposing (which I read as infra suspending their access automatically instead of me or other undertaker contacting the person first) far harsher and putting off than pretty soft (and many say too soft) procedures we have now. I personally would prefer to talk to such a person before suspending them anything happens. Please also remember that if we suspend access automatically and it's suspended for some time, it will require jumping through hoops upon returning just like one has to jump through them when being recruited back. I don't think QA will allow us to just give access back without prior checking if the person is current with everything a developer should know. And if they did allow that, I wouldn't consider this a good thing. Kind regards, Lukasz Damentko
Re: [gentoo-dev] Re: Developer Retirements
On Tue, Mar 10, 2009 at 8:35 AM, Duncan <1i5t5.dun...@cox.net> wrote: > "Pierre-Yves Rofes" posted > a4345526fd26a2a6f5dd3cccb4e9767d.squir...@mail.rofes.fr, excerpted below, > on Tue, 10 Mar 2009 11:21:55 +0100: > > >> We don't want some still active authorization and key > >> from two years ago getting stolen and used to try to slip a bad commit > >> under the radar [...] > > > > With some devs reviewing gentoo-commits@, I highly doubt that this > > commit could go unnoticed more than a few hours. > > That's a relatively new and very good change, and may indeed change the > thinking on this one, some. But why even risk that when (as rane just > posted) there's all deliberate effort to contact on the way out and a > fast return, for someone who hasn't put an away up, has ignored the > contact efforts or after being contacted said yes, retire me, and who > hasn't had any commits in months already, with no indication that's going > to change. > > Can you imagine the PR on even a few hours' breach, when it turns out > they'd been inactive for years, but their login was still active? Would > you want it to be /your/ machines affected? > > Yes, it can happen with even active devs, but the risk is considered > worth it there. But devs that have been inactive for months or years, > and who have ignored contacts or even asked to be retired after the > contact? IMO that's needless risk, (almost) entirely down-side (with > "almost" in there only as a CYA on an otherwise absolute "entirely"), > especially when reuptake is (as posted) so fast. > > -- > 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 > > > So really an effective solution might be for the recruiters/retirement staff to change a user's shell with a script that spits out a message that says something to the effect of: "You have been inactive for a while. Please contact recruiters to re-enable your account. This was done as a security measure." Obviously a little friendlier would be better but everyone gets the gist. That'll prevent them from logging into infra boxes and from being able to do a commit.
Re: [gentoo-dev] Developer Retirements
On Mon, Mar 9, 2009 at 10:18 PM, Lukasz Damentko wrote: > Okay, let me explain in detail. > > Undertakers contact devs who didn't touch CVS for at least two months, > are considered inactive in the bugzilla and have no current .away set. > > After the initial contact, something like 3/4 of e-mailed people > respond very quickly and explain why they are gone (usually family and > work trouble, weddings, army service, health issues, moving out/in and > so on, so called real life) and in such cases we do not retire them > but let them resolve whatever trouble they are in and return to the > project afterwards. > > There are dozens of devs in the project who had such a conversation > with me or other undertakers and all can confirm retirement was > abandoned right away after they gave valid reasons for their absence > and the only consequence was poking about missing .away and asking > when they are planning to get back to work. > > Those people wouldn't even be contacted if their .aways stated why > they are gone and for how long. Therefore a REMINDER: Please do set > your .away. Thanks. > > The rest are usually people who already gave up on the project, just > for various reasons didn't say bye yet. They often have no commits for > many months despite undertakers poking them a bunch of times. Half a > year period without even touching CVS and bugs isn't that uncommon for > them. I can give you specific examples if you really want some. I'd > prefer to avoid pointing fingers at people though. > > Those folks either say goodbye to everyone after being contacted by us > or do not respond at all, in which case, if we get no response to our > two e-mails and an open retirement bug from them after more than a > month, we consider them missing in action and go on with their > retirement. If they appear suddenly at any point of this procedure and > say they want to stay, we either abandon retirement completely or only > send them to recruiters to redo their quizzes if their absence was > extremely long. > > I don't think how we can proceed differently in above kinds of > situations. Do you suggest we stopped e-mailing people who seem gone > from the project (how would we find out those who are really gone > then?), stopped retiring people who mail -dev/-core and say goodbye or > stopped retiring people who aren't responding to their mail and bugs > named "Retire: Person's Name" for months? > > There's only one controversial group of inactive devs: > > There are some people who would prefer to stay in the project although > they can't really give a good reason what for. Usually they claim they > belong to a number of projects although they don't put any regular > work into any of them and leads of this projects often haven't even > heard there's such a person on board. They sometimes were members of > this projects years ago, sometimes wanted to be members and sometimes > only imagine they are members of them. I can give specific examples if > you insist. > > Those we try to encourage to find a new job within Gentoo and often > they do. I can name one who yesterday did start his new Gentoo work > after years of slacking. :-) > > They are the smallest group of those we contact and process, I could > maybe name 5 or 6 of those currently in Gentoo and that's it. There's > no pending retirement of such a person currently. > > Really. Situation you name, when someone wanted to stay in Gentoo > despite not doing any actual work and got retired happened once or > maybe twice during the last year out of about a hundred retirements we > have processed. And all were extreme cases of close to zero activity > over many years with no promise of it ever increasing. We consider > those very carefully, they are always consulted with devrel lead. This > kind of decision isn't made lightly I can assure you. > > Finally, if someone really wants to be a dev but got retired, he can > return to Gentoo within couple of weeks by reopening his retirement > bug, submitting quizzes to recruiters and waiting to get useradded. > Recruiters process returning devs extremely fast so returning to > Gentoo if someone really wants to isn't a problem at all. And there's > absolutely no way anyone from undertakers could stop someone from > being recruited again. > > So summarising, the situation you're complaining about is extremely > marginal. You are invited to subscribe to retirement@ alias and read > its logs on bugzilla and see for yourself how rare occurrence it is. > > I hope I explained everything completely. I'm happy to take questions > if you have any, and of course am open to suggestions. > > Kind regards, > > Lukasz Damentko > > Granted the people I've recently talked to about this or the people I remember bringing this issue up in the past had this happen to them before we had this firm policy in place so really you're addressing a lot of the issues. But the whole act of making them go through all the hoops as a brand new developer is s
Re: [gentoo-dev] Developer Retirements
On Mon, Mar 9, 2009 at 1:55 PM, Jeremy Olexa wrote: > On Mon, Mar 9, 2009 at 1:44 PM, Doug Goldstein wrote: > > I'm wondering what exactly is the harm in letting developers idle for a > > while? While they might not be actively committing they are still > > knowledgeable people that are just as capable as everyone else to push in > a > > fix for small packages. There's lots of bugs in bugzilla with items that > > just need someone active to commit them. There's even a lot of these > items > > are filed by retired Gentoo developers who could have easily pushed this > fix > > for all users. The fact that someone only does one commit a year does not > > marginalize their contribution. While it may be small it is improving the > > overall quality of the distro. I'm constantly seeing developers getting > > upset over getting pushed out. > > The problem comes when $idle_dev has XX bugs assigned to them and they > don't get resolved and no one else knows that there are issues. Then > users get the attitude that they shouldn't even file bugs because no > one fixes them and they just sit there. > > So, I agree with you as long as $idle_dev doesn't pretend to maintain > packages and the team that they belong to doesn't consist of people of > the same activity level. (rendering the team useless too). > > 2 cents, > -Jeremy > > So let's re-assign the bugs to m-needed and not nuke the person.
Re: [gentoo-dev] Re: Developer Retirements
On Tuesday 10 of March 2009 16:29:56 Alec Warner wrote: > > With some devs reviewing gentoo-commits@, I highly doubt that this commit > > could go unnoticed more than a few hours. > really? cause I bet I could slip something in; now I'm motivated to try ;p I somewhat share the view that's rather easy to slip some parts in stream of commits. Would it be possible to introduce some kind of *commit*/*ebuild* *reviewing* *system*? So that every change to tree would need to be somewhat approved by anyone else - just to provide extra pair of eyes to catch early some silly, obvious, unnecessary or very tricky parts of code. It could be quite cheap to introduce and yet not-demotivating step to increase overall quality. I bet it's a practice already by some developers but it would be nice if it could be introduced as a rule for everyone (possibly requiring some GLEP). Personally I don't find it at all humiliating if someone is capable of QA my code - I actually very appreciate it, and I guess most developers do. Should I start separate thread? -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3
On Tue, 10 Mar 2009 17:11:56 +0100 Christian Faulhammer wrote: > Ciaran McCreesh : > > Then this is a legitimate problem that someone needs to know about > > and fix. So having src_test turned on globally is a *good* thing. > > > [...] > > > > Again, finding this is good. > [...] > > > > And if you're on an especially slow platform, as a user you can turn > > tests off. > > Ciaran, your initial argument was that stable users won't see those > failures as architecture teams will spot them during stabilisation. Unless there is a genuine problem, yes. > This is wrong, above cases will turn up after a successful > stabilisation with full QA. And they indicate a genuine problem, so you want them to show up. > Nobody ever said, that spotting those is bad, so for me this > discussion has ended. Enabling by default for everyone (not all > users are experts, like it or not) is a bad idea as it causes many > false positives and has drawbacks for just-users. So? The occasional false positive, which can quickly be fixed, is a lot better than missing things that will break a user's system. We should be failing safely, not defaulting to dangerous behaviour. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Ideas for a (fast) EAPI=3
Hi, Ciaran McCreesh : > Then this is a legitimate problem that someone needs to know about and > fix. So having src_test turned on globally is a *good* thing. > [...] > > Again, finding this is good. [...] > > And if you're on an especially slow platform, as a user you can turn > tests off. Ciaran, your initial argument was that stable users won't see those failures as architecture teams will spot them during stabilisation. This is wrong, above cases will turn up after a successful stabilisation with full QA. Nobody ever said, that spotting those is bad, so for me this discussion has ended. Enabling by default for everyone (not all users are experts, like it or not) is a bad idea as it causes many false positives and has drawbacks for just-users. For me following your turns and twists through a discussion is not worth my time. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3
On Tue, 10 Mar 2009 17:00:05 +0100 Christian Faulhammer wrote: > > Well, the alternative is to drop src_test all together. If a test > > failure is meaningless, having the test is meaningless. > > No, some software like in sci-* has test suites that a user wants to > run probably before productively using that software. But the user > should opt for and not against it. You're saying that users want to have something installed that they aren't going to use productively? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Ideas for a (fast) EAPI=3
Hi, Ciaran McCreesh : > On Mon, 9 Mar 2009 20:58:40 -0700 > Alec Warner wrote: > > You can't test everything. I think for a small project like exherbo > > where everyone basically sees eye to eye on a number of ideas this > > works great. Everyone agrees testing is super and they will fix > > broken tests or RESTRICT them. But Gentoo is bigger, and people > > have varying opinions, and on this topic the opinions are rather > > strong; so I kindly ask that you drop it. There are plenty of > > other far more useful features on your list that are worth your > > time and will actually slide through rather quickly ;) > > Well, the alternative is to drop src_test all together. If a test > failure is meaningless, having the test is meaningless. No, some software like in sci-* has test suites that a user wants to run probably before productively using that software. But the user should opt for and not against it. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives
Hi, Duncan <1i5t5.dun...@cox.net>: > > Potentially the developer could just manually put the EAPI in the > > manifest (or use a tool to do this). Obviously this is an extra > > step when adding ebuilds to the tree, but that would completely > > address the issues with sourcing builds. > > That's an interesting idea. A "manual" method for putting the EAPI > in the manifest, thus bypassing the chicken/egg issue of needing to > need the EAPI to source the ebuild... to get the EAPI. Having the EAPI stored outside the ebuild's scope is generally a bad idea, because someone has to tell you that the ebuild you just downloaded from Bugzilla is EAPI x. And the package manager will be totally confused when assuming an EAPI that is wrong. So the EAPI should be stored inside (best solution regarding giving ebuilds away) or in the file name (best compromise regarding the whole situation. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller wrote:
> With eapis 1 and 2 we introduced nice features but also a couple of
> new problems. One of them are the use dependencies when the package
> you depend on doesn't have the use flag anymore (see [1] for an
> example).
Here's another one to consider:
If S= is wrong (which it often is, for packages with icky tarballs),
src_configure and src_compile won't error out. These days this isn't a
huge deal, because your custom src_install will probably fail. But if
we're introducing a default src_install, it will instead see no
Makefile and just do nothing, resulting in an empty package being
installed.
Currently, at the start of src_configure, the package manager does a cd
to ${S} if ${S} exists, and to ${WORKDIR} otherwise. I'd like to
propose that ${S} not existing should instead be an error if either of
the following conditions are met:
* ${A} is non-empty
* Any of src_unpack, src_configure, src_compile or src_install is a
defined phase.
Ebuilds where this would trigger a false positive would have to specify
S=${WORKDIR}.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Developer Retirements
On Tue, Mar 10, 2009 at 3:21 AM, Pierre-Yves Rofes wrote: > On Tue, March 10, 2009 7:07 am, Duncan wrote: >> Gordon Malm posted >> 200903091617.48682.gen...@gentoo.org, excerpted below, on Mon, 09 Mar >> 2009 16:17:48 -0700: >> >>> There is an important security aspect to retiring folks - commit >>> abilities. Perhaps in the case a dev wants to contribute but cannot in >>> the near future their commit privs can just be revoked until such time >>> they ask for them to be turned back on? I guess that would be an >>> 'extended devaway' ? >> > > [...] > >> We don't want some still active authorization and key >> from two years ago getting stolen and used to try to slip a bad commit >> under the radar [...] > > With some devs reviewing gentoo-commits@, I highly doubt that this commit > could go unnoticed more than a few hours. really? cause I bet I could slip something in; now I'm motivated to try ;p > > -- > Pierre-Yves Rofes > Gentoo Linux Security Team > > > > >
[gentoo-dev] Re: Developer Retirements
"Pierre-Yves Rofes" posted a4345526fd26a2a6f5dd3cccb4e9767d.squir...@mail.rofes.fr, excerpted below, on Tue, 10 Mar 2009 11:21:55 +0100: >> We don't want some still active authorization and key >> from two years ago getting stolen and used to try to slip a bad commit >> under the radar [...] > > With some devs reviewing gentoo-commits@, I highly doubt that this > commit could go unnoticed more than a few hours. That's a relatively new and very good change, and may indeed change the thinking on this one, some. But why even risk that when (as rane just posted) there's all deliberate effort to contact on the way out and a fast return, for someone who hasn't put an away up, has ignored the contact efforts or after being contacted said yes, retire me, and who hasn't had any commits in months already, with no indication that's going to change. Can you imagine the PR on even a few hours' breach, when it turns out they'd been inactive for years, but their login was still active? Would you want it to be /your/ machines affected? Yes, it can happen with even active devs, but the risk is considered worth it there. But devs that have been inactive for months or years, and who have ignored contacts or even asked to be retired after the contact? IMO that's needless risk, (almost) entirely down-side (with "almost" in there only as a CYA on an otherwise absolute "entirely"), especially when reuptake is (as posted) so fast. -- 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
Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3
On Mon, 9 Mar 2009 20:58:40 -0700 Alec Warner wrote: > You can't test everything. I think for a small project like exherbo > where everyone basically sees eye to eye on a number of ideas this > works great. Everyone agrees testing is super and they will fix > broken tests or RESTRICT them. But Gentoo is bigger, and people have > varying opinions, and on this topic the opinions are rather strong; so > I kindly ask that you drop it. There are plenty of other far more > useful features on your list that are worth your time and will > actually slide through rather quickly ;) Well, the alternative is to drop src_test all together. If a test failure is meaningless, having the test is meaningless. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Tue, 10 Mar 2009 10:08:06 +0100 Michael Haubenwallner wrote: > Whats wrong with 'set -e' and doing '|| true' behind? Waaay too many false positives. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3
On Tue, 10 Mar 2009 00:25:49 +0100 Christian Faulhammer wrote: > > Uh, you *are* testing things that use a library before you stable > > that library, right? > > When I was an architecture developer I tried to. But when > stabilising a minor version of curl (for example), testing all > reverse dependencies is no option. But this broke tests for Bazaar > for example in stable. Then this is a legitimate problem that someone needs to know about and fix. So having src_test turned on globally is a *good* thing. > Badly written Autoconf systems which will break in src_test() with a > different version of intltool, which is not a direct dependency. Again, finding this is good. > That pitfall hit me several times in the last years. The more, x86 > e.g. ranges from embedded Geode platforms to dual core desktop > systems and running the sqlite test suite on the first is no fun. As > a user I would not accept two hours of build time. Test-driven > development is great, but not so widely used as one could wish it to > be. And if you're on an especially slow platform, as a user you can turn tests off. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
On 10-03-2009 13:15:36 +0100, Thilo Bangert wrote: > > Bugs aren't a good way to keep in touch with developers, that's what > > irc is for. > > while i dont necessarily think, that bugzi is the best way to stay in > contact with me, it surely is a better way than IRC - on which i am close > to never. > > the presumption seems to be, that as a dev one has to be available via > IRC. it has long been my feeling that Gentoo as a project could realize > more of its potential by better integrating people who dont do IRC. +1 -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
> Bugs aren't a good way to keep in touch with developers, that's what > irc is for. while i dont necessarily think, that bugzi is the best way to stay in contact with me, it surely is a better way than IRC - on which i am close to never. the presumption seems to be, that as a dev one has to be available via IRC. it has long been my feeling that Gentoo as a project could realize more of its potential by better integrating people who dont do IRC. kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Developer Retirements
On Tue, March 10, 2009 7:07 am, Duncan wrote: > Gordon Malm posted > 200903091617.48682.gen...@gentoo.org, excerpted below, on Mon, 09 Mar > 2009 16:17:48 -0700: > >> There is an important security aspect to retiring folks - commit >> abilities. Perhaps in the case a dev wants to contribute but cannot in >> the near future their commit privs can just be revoked until such time >> they ask for them to be turned back on? I guess that would be an >> 'extended devaway' ? > [...] > We don't want some still active authorization and key > from two years ago getting stolen and used to try to slip a bad commit > under the radar [...] With some devs reviewing gentoo-commits@, I highly doubt that this commit could go unnoticed more than a few hours. -- Pierre-Yves Rofes Gentoo Linux Security Team
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Mon, 2009-03-09 at 15:39 -0700, Donnie Berkholz wrote: > > * Utility commands, even the ones that aren't functions, should die. To > > get a non-die version, prefix the command with nonfatal (e.g. > > 'nonfatal dodoc README', which just returns non-zero on failure > > rather than splatting). > > Sounds useful to have less '|| die' all over the place. Whats wrong with 'set -e' and doing '|| true' behind? IMO this would feel more shell-ish. /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Hi, Reminder (for myself): As long as we want/have to support PMs lacking EAPI detection in '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI to an '*.ebuild' must be hackish. So we can try to find the least ugly hack, or we need to change the extension. So just another idea, based on the "eapi() function" one: As inherit() is the only(?) global function provided by old PMs, the first non-commentary/non-blank line in '*.ebuild' could read: inherit eapi Compliant PMs identify 'eapi' as a special eclass name (with or without sourcing the ebuild), to know that "this ebuild specifies an EAPI". For non-compliant PMs, we need to provide an 'eapi.eclass', which just spits some 'your PM lacks EAPI support' message and causes the PM to mask this ebuild 'by corruption' or the like. Or - what are old PM's messages when an eclass is missing? Eventually, this line also could finally specify the EAPI and read: inherit eapi 4 Because non-compliant PM's already quit because of (missing or dying) eapi.eclass, there is no need to have a '4.eclass'. /haubi/ -- Michael Haubenwallner Gentoo on a different level
