Re: [gentoo-dev] QA Roles v2
Stuart Herbert wrote: [...] Mark, in the discussions about the QA policy, your fallback justification always seems to be Trust us. I think this week's events have put a big dent in the credibility of that argument, if not holed it below the water line. If the QA team followed processes similar to what I've described above, I believe that this week's events wouldn't have happened. What started off as a worthy piece of QA work, which I'm sure has fixed many real problems for users, degenerated into something altogether unpleasant and unnecessary for all involved. We've all gotten a week older and a week greyer out of this. Have we fixed any real problems that stop our users installing and running Gentoo? No, we haven't. I hope we can all (and I include myself in that) learn something from this to prevent a repeat. I call for Mark's proposed policy to be rejected as it stands. Trust us sounds like a good justification to me. If the council grants the QA team the right to preempt maintainers for major QA violations, they will indeed have power and may abuse it. But if their use of this power is obviously abusive, the council can revert its decision and cut the balls from that QA team. So I'm for trusting them and see. We need more QA and they can't do their job properly the way it's working now. -- Thierry Carrez (Koon) Gentoo Linux Security Council Member -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] glep 0042 (news) final draft
Mike Frysinger wrote: On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote: Unless there are any huge flaws found, I'd like this to be voted on by the council -- looks like it'll have to wait until April's meeting to fit in with the two weeks rule. may push council meeting back to 3rd tuesday if people wish -mike Is this a resubmission? Or would it be the first time this GLEP is being presented to the council? Regards, Andrew -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 6:31:17, Mark Loeser wrote: Mike Frysinger [EMAIL PROTECTED] said: one thing i dont think we give enough emphasis to is that our tools arent perfect ... sometimes we utilize QA violations to work around portage limitations ... if you want to see some really sweet hacks, review any of the toolchain related ebuilds and the hacks ive had to add to get cross-compiling to the usuable state that it is today. a handful of them would fall under the 'severe' category i'm sure. and if we want to use the lovely php example, personally i think that given portage's current limitations, the latest dev-lang/php ebuild is probably one of the best solutions that could have been developed, thanks Stuart for all the flak you've had to take over this. also, many games ebuilds break the 'non-interactive' policy by displaying licensing and making the user hit Y because portage lacks checks where the user explicitly states what licenses they accept. This somewhat touchs on what pauldv mentioned earlier, that we will acknowledge when no better possible solution is available, and some workaround is needed. As he also suggested, we should keep a list of these in the form of open bugs so that we can get a better solution somewhere in the long-term. Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoor1=1.31r2=1.32 What's the above again? QA policy? How does user benefit from flipping a coin wrt choosing a functionality? Sigh... :/ -- 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 ;) pgp9VCpGMLVmo.pgp Description: PGP signature
Re: [gentoo-dev] glep 0042 (news) final draft
Mike Frysinger wrote: On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote: Unless there are any huge flaws found, I'd like this to be voted on by the council -- looks like it'll have to wait until April's meeting to fit in with the two weeks rule. may push council meeting back to 3rd tuesday if people wish I'd certainly like to see GLEP 42 addressed this month, if at all possible. That said, the two-weeks rule is to avoid inconveniencing the Council and unfairly springing something upon the devs without a chance to look at the details. It's certainly a good rule, but I don't think it should be considered inviolable. If there is an emergency, or the issue is sufficiently well known that the entire two weeks notice seems unnecessary, then I would think the Council could decide to make an exception. -g2boojum- signature.asc Description: OpenPGP digital signature
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 22:19:33, Stephen Bennett wrote: On Fri, 3 Mar 2006 21:47:22 +0100 Jakub Moc [EMAIL PROTECTED] wrote: Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoor1=1.31r2=1.32 What's the above again? QA policy? How does user benefit from flipping a coin wrt choosing a functionality? Sigh... :/ It gets the point across effectively. I don't see your problem. What kind of point does it get across, exactly? That flipping a coin or forcing your personal preference is a better solution than letting users decide what kind of functionality they prefer? Don't you think users do know better? What's the point of such policy? You call forcing random feature on users instead of letting them decide QA? I don't. -- 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 ;) pgpfRMpGO6qDi.pgp Description: PGP signature
Re: Re[2]: [gentoo-dev] QA Roles v2
On 3/3/06, Jakub Moc [EMAIL PROTECTED] wrote: It gets the point across effectively. I don't see your problem. What kind of point does it get across, exactly? That flipping a coin or forcing your personal preference is a better solution than letting users decide what kind of functionality they prefer? Don't you think users do know better? What's the point of such policy? You call forcing random feature on users instead of letting them decide QA? I don't. I agree. Adopting a policy like this is a low quality solution for servers. I've no opinion on how this affects desktops, but packages for servers need to be precise.A policy that says if two USE flags deliver the same benefits, but conflict, pick one is fine. But saying flip a coin ... how on earth is that quality? And how the heck is it going to work w/ USE-based defaults? This creates a situation where package (b) cannot trust that a feature is enabled in package (a), even if package (a) was built with the required USE flags. I'll go as far as saying that right now I'm embarrased that it looks like this is going to become a Gentoo policy in its current form. You're absolutely *not* creating a better user experience. You're brushing a problem under the carpet ... and making it the users' problem when they wonder why the built a package with a USE flag and the package still doesn't work as they expect. Until Portage supports resolving conflicting USE flags when the deptree is built, the practical thing to do is for ebuilds w/ conflicting USE flags to bail. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Friday 03 March 2006 15:47, Jakub Moc wrote: Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... please, get a sense of humor, kthxbye -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Sending this from the right address this time -g2boojum- Grant Goodyear wrote: Jakub Moc wrote: Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... I don't believe the text is meant to be funny. It's meant (I think) to suggest that if all else is equal, meaning that there is no obvious best choice, then just choose a flag, by whatever means, to support as the default. Even if it is not what the user might have chosen, at least the build will complete. Moreover, the results will then be deterministic. http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoor1=1.31r2=1.32 What's the above again? QA policy? How does user benefit from flipping a coin wrt choosing a functionality? Sigh... :/ It prevents emerge from crashing out in the middle of what could be a quite extensive build. Personally, I would rather rebuild one package to get desired functionality _after_ the emerge completes than have to fix the flags for that one package to be able to build everything else. -g2boojum- signature.asc Description: OpenPGP digital signature
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 22:51:39, Mike Frysinger wrote: On Friday 03 March 2006 15:47, Jakub Moc wrote: Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... please, get a sense of humor, kthxbye -mike Sorry, I don't find anything particularly humorous w/ such suggestions finding their path into documents that you are trying to enforce as a QA policy. -- jakub pgpXKbPmW8sgG.pgp Description: PGP signature
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 22:54:25, Grant Goodyear wrote: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoor1=1.31r2=1.32 What's the above again? QA policy? How does user benefit from flipping a coin wrt choosing a functionality? Sigh... :/ It prevents emerge from crashing out in the middle of what could be a quite extensive build. Personally, I would rather rebuild one package to get desired functionality _after_ the emerge completes than have to fix the flags for that one package to be able to build everything else. Erm, how exactly will you find out that you need to recompile that package after such extensive build? You'll spend a couple of hours debugging when your server app stops working? Yay! :P Oh please, stop making up artificial policies doing no good to users just to hack around lacking features in portage. -- jakub pgpHQqMRqRxGb.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 22:27:45 +0100 Jakub Moc [EMAIL PROTECTED] wrote: What kind of point does it get across, exactly? That you must choose one flag, or set of flags, to take precedence in such situations, but that how you choose is quite immaterial. If there is an obvious choice then use it, else pick one some other way. -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 23:25:13, Stephen Bennett wrote: On Fri, 3 Mar 2006 22:27:45 +0100 Jakub Moc [EMAIL PROTECTED] wrote: What kind of point does it get across, exactly? That you must choose one flag, or set of flags, to take precedence in such situations, but that how you choose is quite immaterial. If there is an obvious choice then use it, else pick one some other way. Yeah, that's a wonderful message. Let users choose, they are not idiots and such policy does more harm than good. Period. -- jakub pgp3Eck3S3o3U.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Jakub Moc wrote: Erm, how exactly will you find out that you need to recompile that package after such extensive build? You'll spend a couple of hours debugging when your server app stops working? Yay! :P I had assumed that in such a case the ebuild would output a scary-looking ewarn that notified the user of such a problem. Oh please, stop making up artificial policies doing no good to users just to hack around lacking features in portage. Was I so impolite that you felt the need to be rude in turn? If so, I certainly apologize, as it was not my intention. I don't believe that I made up this policy, although it's been around as an unofficial policy for so long that I couldn't really say one way or the other. In any event, I certainly agree that fixing portage would be preferable to policies that work around portage's warts. On the other hand, until those warts get fixed it seems useful to have a set of best practices in the meantime. I'm arguing that sudden, difficult to predict package build breakages are a bigger sin than having a package build deterministic functionality that may be unexpected by the user. You (I think) believe the opposite. Fair enough. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
Stuart Herbert wrote: I agree. Adopting a policy like this is a low quality solution for servers. I've no opinion on how this affects desktops, but packages for servers need to be precise.A policy that says if two USE flags deliver the same benefits, but conflict, pick one is fine. But saying flip a coin ... how on earth is that quality? See my previous post. And how the heck is it going to work w/ USE-based defaults? This creates a situation where package (b) cannot trust that a feature is enabled in package (a), even if package (a) was built with the required USE flags. Yep. Having a USE flag enabled turns out not to be a guarantee. That said, package builds do become deterministic, so (for example) if one needs to know if msmtp was built with openssl or gnutls it is easy enough to pull the logic from the msmtp ebuild. I'm sure that there is a more elegant solution, but I'm not convinced that having the user randomly throw USE flags at a package until some combination works is necessarily it. I could be wrong, however. *Shrug* I'll go as far as saying that right now I'm embarrased that it looks like this is going to become a Gentoo policy in its current form. With an apology for singling you out (when yours is certainly not the only, or even the most appropriate, example), that sort of emotional response is how these threads begin to degenerate. There appears to be an implicit assumption there that your view is clearly correct, and any other is embarrassingly silly. Instead, I suggest that perhaps people on both (all?) sides of the issue are rational, intelligent people who simply differ on what happens to be the greatest evil. You're absolutely *not* creating a better user experience. You're brushing a problem under the carpet ... and making it the users' problem when they wonder why the built a package with a USE flag and the package still doesn't work as they expect. I would argue that the user tends to get unexpected results in either case, it's just a matter of whether the build crashes, or the resulting package is somewhat unexpected. Given that fact, I'm arguing that having a potentially-lengthy emerge crash out is the bigger evil. Until Portage supports resolving conflicting USE flags when the deptree is built, the practical thing to do is for ebuilds w/ conflicting USE flags to bail. I, quite respectfully, disagree. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 23:31:49 +0100 Jakub Moc [EMAIL PROTECTED] wrote: Yeah, that's a wonderful message. Let users choose, they are not idiots and such policy does more harm than good. Period. You're completely missing the point here. The user has a choice, but if his set of choices doesn't make sense for whatever reason, you have to decide on some sane way to configure the package. How you come to that decision is irrelevant, hence the 'flip a coin'. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
It prevents emerge from crashing out in the middle of what could be a quite extensive build. Personally, I would rather rebuild one package to get desired functionality _after_ the emerge completes than have to fix the flags for that one package to be able to build everything else. This is why Ciaran and I opened a bug for the Portage team to get this handled up-front. Alas, I can't find the bug any more to reference it here :( You're assuming that a user can figure out how to fix the one package when they realise it's broken. Unless a user looks inside the ebuild, they're not going to understand why the USE flags they've selected has resulted in a package that doesn't actually have those features. Chances are, the user will never look. This is going to *create* more support, not reduce it. That's hardly a worthy outcome. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 23:32:36, Grant Goodyear wrote: Jakub Moc wrote: Erm, how exactly will you find out that you need to recompile that package after such extensive build? You'll spend a couple of hours debugging when your server app stops working? Yay! :P I had assumed that in such a case the ebuild would output a scary-looking ewarn that notified the user of such a problem. The whole argument here is that bailing out with conflicting use flags breaks some extensive compiles. So you suppose users will be sitting in front of their monitor and stare on the screen waiting for a scary warning? No, they won't. And even if they were, how exactly is that warning better than bailing out and asking them to change the use flags? The only thing that can happen here is that users will get unexpected results and will be debugging their broken apps once that extensive compile that must not be interrupted under any circumstances is finished. Oh please, stop making up artificial policies doing no good to users just to hack around lacking features in portage. Was I so impolite that you felt the need to be rude in turn? If so, I certainly apologize, as it was not my intention. No, sorry. That comment was aimed generally at whomever is making up such policies. I'm really getting tired of this debate. Lets drop the damned paragraph that has been added recently and lets do some more important job. This simply cannot be fixed now in a reasonable way that would improve user experience, so why don't we focus on something that is doable? I don't believe that I made up this policy, although it's been around as an unofficial policy for so long that I couldn't really say one way or the other. In any event, I certainly agree that fixing portage would be preferable to policies that work around portage's warts. On the other hand, until those warts get fixed it seems useful to have a set of best practices in the meantime. I'm arguing that sudden, difficult to predict package build breakages are a bigger sin than having a package build deterministic functionality that may be unexpected by the user. You (I think) believe the opposite. Fair enough. Well, selecting features randomly is not what I believe could be a best practice. -- jakub pgplAlVlbQEm0.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Stuart Herbert wrote: It prevents emerge from crashing out in the middle of what could be a quite extensive build. Personally, I would rather rebuild one package to get desired functionality _after_ the emerge completes than have to fix the flags for that one package to be able to build everything else. This is why Ciaran and I opened a bug for the Portage team to get this handled up-front. Alas, I can't find the bug any more to reference it here :( bug 75936 -- Kind Regards, Simon Stelling Gentoo/AMD64 Member -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Grant, On 3/3/06, Grant Goodyear [EMAIL PROTECTED] wrote: Yep. Having a USE flag enabled turns out not to be a guarantee. That said, package builds do become deterministic, so (for example) if one needs to know if msmtp was built with openssl or gnutls it is easy enough to pull the logic from the msmtp ebuild. If a build process has errors, it should stop. That's still deterministic. I'd respectfully argue that it's far more deterministic than having each single package implement separate policy for handling conflicting USE flags. Policy belongs with the user, not in Portage. It's exactly the same as the kernel pushing policy into userspace. I believe that it's bad engineering to force (using your example) packages that depend on msmtp to have to copy the logic from the msmtp ebuild to understand how to correctly depend on that package. It violates the principle of Don't Repeat Yourself. If we're going to do this, then at least we should be implementing a consistent standard across all ebuilds. F.ex, when SSL and TLS conflict, we should have a standard saying that all ebuilds will consistenly favour one over the other. That's much more deterministic than having some ebuilds prefer SSL, and others prefer TLS (for example). I'm sure that there is a more elegant solution, but I'm not convinced that having the user randomly throw USE flags at a package until some combination works is necessarily it. I could be wrong, however. *Shrug* Why would the user be randomly throwing USE flags at a package? With the PHP ebuilds and the confutils eclass, we've already proved that you can tell the user exactly why the ebuild has bailed, and what they can do to fix it. With an apology for singling you out (when yours is certainly not the only, or even the most appropriate, example), that sort of emotional response is how these threads begin to degenerate. There appears to be an implicit assumption there that your view is clearly correct, and any other is embarrassingly silly. Instead, I suggest that perhaps people on both (all?) sides of the issue are rational, intelligent people who simply differ on what happens to be the greatest evil. I accept the point, but, well, I *am* embarrassed. I guess I'm just willing to admit it when others would rather not be open and honest about how this makes them feel. I think it's fair to raise that as part of the debate. I don't think we talk enough about how we feel about what's happening to Gentoo these days. I think it's reasonable that issues like this are delt with both on an emotional intelligence level as well as an intellectual one. I would argue that the user tends to get unexpected results in either case, it's just a matter of whether the build crashes, or the resulting package is somewhat unexpected. Given that fact, I'm arguing that having a potentially-lengthy emerge crash out is the bigger evil. I can understand how that matters to first-time installs, or users running old hardware. My environment and concern are servers, where dual-Xeon or dual-Opterons are the norm. The time it takes to install a package is trivial against the time it takes to diagnose why it isn't working the way you would expect. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 23:14:41 + Stuart Herbert [EMAIL PROTECTED] wrote: | If we're going to do this, then at least we should be implementing a | consistent standard across all ebuilds. F.ex, when SSL and TLS | conflict, we should have a standard saying that all ebuilds will | consistenly favour one over the other. That's much more deterministic | than having some ebuilds prefer SSL, and others prefer TLS (for | example). And what of gtk vs qt, where for many packages one is clearly the preferred choice, but which one this is varies between packages? Do *you* know which GUI is the best option for gvim and why? Heck, it's hard enough figuring out a usable set of USE flags for PHP. If we started dieing for the three zillion or so mutually independent GUI options in gvim7 users would never actually be able to figure out how to install the thing... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Bugday reminder :-)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey everybody :-) It's time again to get some bug smashing done. We hope to see you all in #gentoo-bugs tomorrow (saturday 2006/03/04). Best Regards Bjarke Istrup Pedersen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFECJccO+Ewtpi9rLERAuytAJ93igIY6aShwxkFfzcKoO2aZIk2fQCfVAxq XmB6fRnJF9SqtQTyCe0b81k= =k7l+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gratuitous useflaggery (doc and examples)
This is undocumented and unofficial, so feel free to utterly ignore it and commit whatever the heck you want. The 'doc' and 'examples' (yay for consistency!) USE flags are intended for use where building documentation or examples would take a long time, introduce new dependencies or otherwise be an inconvenience to many users. For example, if libiamafish comes with a half dozen small example source files and a few pages of HTML, just install them. If, however, libiamafish requires, say, doxygen to generate its documentation, or comes with several megabytes of examples in a separate tarball, then you should consider a USE flag. Explanation: a USE flag for trivial stuff that isn't in /etc, doesn't slow anything down, doesn't introduce any dep bloat and generally doesn't change anything noticeable isn't a USE flag that's giving the user any meaningful choice or making things easier for arch teams. You do not get bonus points for using more USE flags. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] QA Roles v2
The whole argument here is that bailing out with conflicting use flags breaks some extensive compiles. So you suppose users will be sitting in front of their monitor and stare on the screen waiting for a scary warning? No, they won't. And even if they were, how exactly is that warning better No they won't, but elog in portage-2.1 will gladly send them a message via whatever configuration they have about the warning that the ebuild produced. -Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Friday 03 March 2006 18:14, Stuart Herbert wrote: If we're going to do this, then at least we should be implementing a consistent standard across all ebuilds. F.ex, when SSL and TLS conflict, we should have a standard saying that all ebuilds will consistenly favour one over the other. That's much more deterministic than having some ebuilds prefer SSL, and others prefer TLS (for example). bad idea ... choosing a default is a per-package issue. say we take this path and we declare that if a package supports both tls and ssl, you must utilize tls over ssl regardless. then you come to a package has really shitty tls support but it has wonderful ssl support. you're saying that defaulting to tls is a better idea than ssl ? a global decision like this just wont cut it. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Alec Warner wrote: The whole argument here is that bailing out with conflicting use flags breaks some extensive compiles. So you suppose users will be sitting in front of their monitor and stare on the screen waiting for a scary warning? No, they won't. And even if they were, how exactly is that warning better No they won't, but elog in portage-2.1 will gladly send them a message via whatever configuration they have about the warning that the ebuild produced. -Alec Warner Greetings dear Gentoo developers. I would like to give you my humble point of view on this subject as a simple gentoo user. A few days after an emerge that took 7 hours to complete I used the portlog-info script to extract the warnings from the portage log (I'm using portage 2.0.54 on that computer so no elog there). While reading these warnings I came to this one: === 2006-02-12 01:01 === php-4.4.0-r4 === = /var/log/portage/2729-php-4.4.0-r4.log (4.0K) = ... * If you have both freetds and mssql in your USE flags, parts of PHP * may not behave correctly, or may give strange warnings. You have * been warned! It's recommended that you pick ONE of them. For sybase * support, chose 'freetds'. For mssql support choose 'mssql'. * If you have additional third party PHP extensions (such as * dev-php/eaccelerator) you may need to recompile them now. ... So now, even if I have no knowledge about PHP, I know that if something is going wrong with it I will have to check these use flags. And if I was not so lazy I would have a look at them right now to be sure nothing bad will happen. I feel more comfortable with this behavior than with a long emerge that would have stopped in the middle because of potentially conflicting use flags. (sorry for my bad English and thank you all for your good work. I just love Gentoo) Fabrice Bellamy ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] glep 0042 (news) final draft
On Thu, 2 Mar 2006 00:19:47 + Ciaran McCreesh [EMAIL PROTECTED] wrote: Attached is the final draft. No substantial changes since last time, just wording cleanups and a few clarifications. You'll be able to see it here in an hour or three (check the dates!): http://www.gentoo.org/proj/en/glep/glep-0042.html Or you can try to read the attached RST source, but no moaning that it looks weird if you do. Unless there are any huge flaws found, I'd like this to be voted on by the council -- looks like it'll have to wait until April's meeting to fit in with the two weeks rule. Nothing major, just a few minor issues (I'll admit I'm late): * Portage must extend portageq to implement a command which returns whether or not the profile used for a given repository ID matches a certain base path (e.g. portageq profile_used default-linux/sparc/sparc64/2004.3 gentoo-x86). Wording here is a bit unclear, I assume it's supposed to mean wether or not the (any) used profile belongs the the given repoid and is (a subprofile of) the given profile name. Using path here is dangerous, e.g. portageq profile_used base gentoo-x86. As any substantial change results in a new news item should there be an optional Obsoletes header? Could be used to make sure people only see the most current version (without relying on rsync to wipe deleted files). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions regarding the new portage API (savior branch)
Brian Harring wrote: If y'all want to mirror it, might I suggest poking marienz for his tailorization knowledge? Afaik, he had a bzr-svn push working, or at least has investigated it. From what I've heard, tailor has absolutely no knowledge of branches. So if you use branches, might want to tread carefully with tailor. Donnie signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] [PATCH] Manifest2 reloaded
So while on my way to FOSDEM I decided to do something useful with the
time and wrote a new manifest2 implementation. This has nothing to do
with the original prototype I posted a while ago, it's been written
completely from scratch.
Basically all functionality (creation, parsing, validation) is
encapsulated in the new portage_manifest.Manifest class, including
compability code to read/write old style digests.
The changes to portage.py only change the digest*() functions to use
this new class instead of handling the task themselves (exception:
digestCheckFiles() which apparently was only used internally by other
digest* functions), they should more or less behave like with the old
code. Any new code however should use the Manifest() class directly
however.
While this patch implements the basic functionality some extra stuff
that was in the old code isn't included yet:
- gpg verification
- FEATURES=autoaddcvs
- FEATURES=cvs (probably obsolete anyway)
- emerge --digest / FEATURES=digest (may or may not work)
The first should be delayed until there is some consensus how the gpg
stuff should work in the future, the others I don't see the use for.
Also I only checked portage.py for changes, so emerge/repoman/... might
still have to be fixed.
Last but not least: I did some basic testing with this and the
important stuff seems to work, but I'm quite sure the code still has a
lot of bugs/issues, and this being a core functionality it needs a
*lot* of testing, so I'd really appreciate if you could all give it a
spin (but do not commit anything to the tree without manually checking
it first).
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
diff -ru --exclude=CVS --exclude=.svn -N pym/portage.py.org pym/portage.py
--- pym/portage.py.org 2006-03-04 02:25:20.957635000 +
+++ pym/portage.py 2006-03-04 03:12:19.545785750 +
@@ -90,6 +90,7 @@
from portage_data import ostype, lchown, userland, secpass, uid, wheelgid, \
portage_uid, portage_gid
+ from portage_manifest import Manifest
import portage_util
from portage_util import atomic_ofstream, dump_traceback, getconfig, grabdict, \
@@ -2049,181 +2050,67 @@
return 0
return 1
-
-def digestCreate(myfiles,basedir,oldDigest={}):
- Takes a list of files and the directory they are in and returns the
- dict of dict[filename][CHECKSUM_KEY] = hash
- returns None on error.
- mydigests={}
- for x in myfiles:
- print ,x
- myfile=os.path.normpath(basedir+///+x)
- if os.path.exists(myfile):
- if not os.access(myfile, os.R_OK):
-print !!! Given file does not appear to be readable. Does it exist?
-print !!! File:,myfile
-return None
- mydigests[x] = portage_checksum.perform_multiple_checksums(myfile, hashes=portage_const.MANIFEST1_HASH_FUNCTIONS)
- mysize = os.stat(myfile)[stat.ST_SIZE]
- else:
- if x in oldDigest:
-# DeepCopy because we might not have a unique reference.
-mydigests[x] = copy.deepcopy(oldDigest[x])
-mysize = copy.deepcopy(oldDigest[x][size])
- else:
-print !!! We have a source URI, but no file...
-print !!! File:,myfile
-return None
-
- if mydigests[x].has_key(size) and (mydigests[x][size] != mysize):
- raise portage_exception.DigestException, Size mismatch during checksums
- mydigests[x][size] = copy.deepcopy(mysize)
- return mydigests
-
-def digestCreateLines(filelist, mydict):
- mylines = []
- mydigests = copy.deepcopy(mydict)
- for myarchive in filelist:
- mysize = mydigests[myarchive][size]
- if len(mydigests[myarchive]) == 0:
- raise portage_exception.DigestException, No generate digest for '%(file)s' % {file:myarchive}
- for sumName in mydigests[myarchive].keys():
- if sumName not in portage_checksum.get_valid_checksum_keys():
-continue
- mysum = mydigests[myarchive][sumName]
-
- myline = sumName[:]
- myline += +mysum
- myline += +myarchive
- myline += +str(mysize)
- mylines.append(myline)
- return mylines
-
-def digestgen(myarchives,mysettings,overwrite=1,manifestonly=0):
+def digestgen(myarchives,mysettings,db=None,overwrite=1,manifestonly=0):
generates digest file if missing. Assumes all files are available. If
- overwrite=0, the digest will only be created if it doesn't already exist.
-
- # archive files
- basedir=mysettings[DISTDIR]+/
- digestfn=mysettings[FILESDIR]+/digest-+mysettings[PF]
-
- # portage files -- p(ortagefiles)basedir
- pbasedir=mysettings[O]+/
- manifestfn=pbasedir+Manifest
-
- if not manifestonly:
- if not os.path.isdir(mysettings[FILESDIR]):
- os.makedirs(mysettings[FILESDIR])
- mycvstree=cvstree.getentries(pbasedir, recursive=1)
-
- if (cvs in features) and os.path.exists(pbasedir+/CVS):
- if not cvstree.isadded(mycvstree,files):
-if autoaddcvs in features:
- print Auto-adding files/ dir to CVS...
- spawn(cd +pbasedir+; cvs
[gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
so we've found some cases where a package installs objects that either need to be ignored by some of the scanelf checks ... first off, we have kernel binary objects that a package installs (the h*modem packages do this), so they should not be subjected to the exec stack scans next up is the slmodem package ... this puppy is partly binary only and we have no access to the source code and upstream is dead ... one of the pre-built binary objects has an exec stack enabled via gcc (meaning it's a legit use of exec stack) ... so we need to skip that what this e-mail is about is naming convention ... i'm thinking that an ebuild sets up a variable with a list of relative paths to $D of files that should be skipped for various checks ... so with slmodem, we'd have like: QA_EXEC_STACK=usr/sbin/slmodemd usr/sbin/slmodem_test if, in the future, we need to add an ignore list for TEXTRELs, we'd use QA_TEXTRELS= -mike -- gentoo-portage-dev@gentoo.org mailing list
