Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Thu, 02 Mar 2006 00:54:25 + Duncan Coutts [EMAIL PROTECTED] wrote: On Thu, 2006-03-02 at 00:41 +, Roy Marples wrote: For the non technically minded folks whats the difference between -fno-stack-protector and -fno-stack-protector-all? [...] It was explained to me like this: -fno-stack-protector makes gcc use a heuristic to decide whether or not change a function to use stack-smashing protection. -fno-stack-protector-all makes gcc just do it for every function. not quite (note the 'no-'!): In gcc-3: -fstack-protector switches on stack protection for functions that gcc decides heuristically to be most vulnerable according to their parameters and local data. -fstack-protector-all switches on stack protection for (almost) all functions -fno-stack-protector switches off -fstack-protector -fno-stack-protector-all switches off -fstack-protector-all Of note is that: ... -fstack-protector -fstack-protector-all -fno-stack-protector results in no ssp at all ... -fstack-protector -fstack-protector-all -fno-stack-protector-all results in heuristic ssp switched on For gcc-4.1, the semantics have changed as RedHat Did Their Own Thing and broke backwards compatibility: 1) -fno-stack-protector-all does not exist 2) stack protection is viewed as a three-state setting configured by the last occurring switch from the set -fno-stack-protector - no stack protection -fstack-protector - heuristic stack protection -fstack-protector-all - stack protection on all functions (imo they should have done something like -fstack-protect[N] for N=0,1,2 which would have been clearer, but I got ignored when I suggested it) Since 'last option wins' in the RedHat version, '-fstack-protector-all -fstack-protector' gives heuristic ssp, whereas on gcc-3 it gives full ssp. Upshot - managing ssp has become a bit of a pita :/ (gcc-4 is currently masked in the hardened profile, primarily because gcc-4.0 has no ssp, but going forward also until we decide what to do with the hardened specs on gcc-4.1). there is also: -fno-stack-protector-to-all which if supplied makes -fno-stack-protector get promoted to -fno-stack-protector-all. Apparently -fno-stack-protector-to-all is on by default in all current gcc profiles so that means that at the moment if you specify -fno-stack-protector you really get -fno-stack-protector-all. there is no '-fno-stack-protector-to-all' as such. the gcc specs we change (in gcc-3) currently switch -fstack-protector-all on if -fstack-protector is set (either on the command line or automatically in the case of the hardened compiler). This occurs also with the vanilla compiler - which is a bug although very few people (if any) come across it as the only supported way to use the stack protector at the moment is by using the hardened compiler. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Hi Mark, This draft seems to be effectively the same as the last one. On 3/2/06, Mark Loeser [EMAIL PROTECTED] wrote: * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action. Same as original version. * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. Same as original version. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. Same as original version. * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. Same as original version. * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. Same as original version. * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation. Same as original version. * If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to devrel. Same as original version. * The QA team will maintain a list of current QA Standards with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered. The QA team will also do their best to ensure all developer tools are in line with the current QA standards. The bit about explanations as to why they are prblems, and how to fix the problem is new, as is the statement to ensure that all developer tools are in line with the current QA standards, but otherwise this is also the same. I'm sorry, but personally I don't see how this draft is substantially different from the one posted originally. It looks like you've decided not to address the points I raised about your original draft: * There's nothing in this policy about end users. If this QA team is not *focused* on delivering benefit to end users, then (as has happened this week) it becomes a self-serving team, focused instead on what can only be described as a destructive path. No-one benefits from that, no-one at all. * The QA team is asking for more than it needs to perform its role. The UNIX principle is that of least privilege. Donnie's already pointed out that FreeBSD is able to conduct effective QA without the extra power that the QA team is continuing to ask for. * There is no proposal for a process to formulate, and gain wide approval for new QA standards. This week, there's been an example of the QA team documenting a QA standard *after* a bug was raised about a QA violation ... and then that document being used as if that particular QA standard had always been in the document. Mistakes will always be made by all developers, and good QA is essential to Gentoo's future. We need a good QA team for Gentoo. Not having a QA team is, in my eyes, not an option at all. But, as this week has shown, QA members are also developers (and human), and are just as capable of making mistakes as anyone else. We need a quality assurance team that conducts all its activities in a quality manner. I'm not just talking about personal behaviour, or of any one individual. The way *everything* is done must be in a quality manner. That should mean a high quality process for creating QA standards, having them approved, and making sure developers know what changes are coming and when. That should mean high quality automated tools that cope with the real world, not some ivory tower that has no real pay-off for users. It should mean an interpretation and application of QA standards that is focused on how it improves matters for real users - and not a tick in a box QA approach. It should mean a team of educators, not a team out to bully with the mandate to do so. In twelve years of being a professional software engineer, I've never seen a successful QA team that didn't match that description above. 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
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 03:53, Mark Loeser wrote: Here is my updated version after some feedback from people: * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action. * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation. * If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to devrel. * The QA team will maintain a list of current QA Standards with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered. The QA team will also do their best to ensure all developer tools are in line with the current QA standards. I'd like to add the following two points: * Just because breaking policy breaks a QA tool, but is guaranteed to never break itself (formatting policy, like space vs. tab etc.) does not increase the severity of the breakage. * Before any enforcement is possible, QA must establish a well supported (debated on dev-) exception policy. While it were nice if exceptions are not needed, reality is that they can not be avoided. Therefore there must be an exception policy. An exception does not mean there is no violation (so appeal is pointless). An exception means that the violation is needed because it offers important features for the user, and the benefits outweigh the costs. At the same time that an exception is allowed, steps should be undertaken to get a structural solution to the problem. QA is responsible for ensuring that the maintainer(s) of the package in question keep on doing so. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgprXCemTv9v5.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On Wed, 2006-03-01 at 19:28 -0500, Mike Frysinger wrote: On Wednesday 01 March 2006 04:17, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. so, GLEP44 is up right ? any last questions ? /me looks at solar Far as I'm concerned at this point we are just formalizing it. I have no remaining questions or recommendations. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Thu, 2006-03-02 at 09:01 +, Stuart Herbert wrote: [snip] * There's nothing in this policy about end users. If this QA team is not *focused* on delivering benefit to end users, then (as has happened this week) it becomes a self-serving team, focused instead on what can only be described as a destructive path. No-one benefits from that, no-one at all. * The QA team is asking for more than it needs to perform its role. The UNIX principle is that of least privilege. Donnie's already pointed out that FreeBSD is able to conduct effective QA without the extra power that the QA team is continuing to ask for. So I see two scenarios for that: - A QA team with a purely advisory function, helping with communication. pro: no big policy changes etc. con: teethless QA may get ignored - A QA team with limited executive power, fixing bugs as they are found pro: fast turnaround times on bugs con: resistance from developers The second approach needs to be carefully implemented, people need to have trust in the QA team to empower them. * There is no proposal for a process to formulate, and gain wide approval for new QA standards. This week, there's been an example of the QA team documenting a QA standard *after* a bug was raised about a QA violation ... and then that document being used as if that particular QA standard had always been in the document. Communications issue. This thread should help fix the policies for that I hope. Mistakes will always be made by all developers, and good QA is essential to Gentoo's future. We need a good QA team for Gentoo. Not having a QA team is, in my eyes, not an option at all. Fully agreed. But, as this week has shown, QA members are also developers (and human), and are just as capable of making mistakes as anyone else. Obviously :-) We need a quality assurance team that conducts all its activities in a quality manner. I'm not just talking about personal behaviour, or of any one individual. The way *everything* is done must be in a quality manner. That should mean a high quality process for creating QA standards, having them approved, and making sure developers know what changes are coming and when. That should mean high quality automated tools that cope with the real world, not some ivory tower that has no real pay-off for users. It should mean an interpretation and application of QA standards that is focused on how it improves matters for real users - and not a tick in a box QA approach. It should mean a team of educators, not a team out to bully with the mandate to do so. That sounds like a mission statement and should be part of QA policy In twelve years of being a professional software engineer, I've never seen a successful QA team that didn't match that description above. 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. I'd like to see it extended with the ideas shown in this thread. Also the QA team should consider ways of getting higher acceptance - I suggest that a general vote should be done, that's about as democratic as we can get and noone can weasel put after that (although I'm open for other processes to give the QA team support) Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] QA Roles v2
Paul de Vrieze [EMAIL PROTECTED] said: * Just because breaking policy breaks a QA tool, but is guaranteed to never break itself (formatting policy, like space vs. tab etc.) does not increase the severity of the breakage. I had hoped something like this would have just been understood to not be too severe, since it doesn't really break anything but coding standards. * Before any enforcement is possible, QA must establish a well supported (debated on dev-) exception policy. While it were nice if exceptions are not needed, reality is that they can not be avoided. Therefore there must be an exception policy. I'm not sure what you mean here. You mean for each instance? In general? In general can be difficult since it leaves a lot of things up for interpretation. For each instance, 99% of the time an acceptable interim solution should be able to be achieved between the QA team and the maintainer. In situations where we can't figure out how to best address the situation, opening the discussion up to -dev may help, but in the end it should come down to an agreement between the maintainer and the team. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpa7xQtkRfX0.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 14:09, Mark Loeser wrote: Paul de Vrieze [EMAIL PROTECTED] said: * Just because breaking policy breaks a QA tool, but is guaranteed to never break itself (formatting policy, like space vs. tab etc.) does not increase the severity of the breakage. I had hoped something like this would have just been understood to not be too severe, since it doesn't really break anything but coding standards. * Before any enforcement is possible, QA must establish a well supported (debated on dev-) exception policy. While it were nice if exceptions are not needed, reality is that they can not be avoided. Therefore there must be an exception policy. I'm not sure what you mean here. You mean for each instance? In general? In general can be difficult since it leaves a lot of things up for interpretation. For each instance, 99% of the time an acceptable interim solution should be able to be achieved between the QA team and the maintainer. In situations where we can't figure out how to best address the situation, opening the discussion up to -dev may help, but in the end it should come down to an agreement between the maintainer and the team. The policy should be general. It could be something like Developer and QA discuss the exception and the solution to be used. If they do not agree the council . In any case when an exception is made, appropriate bugs are created, including a bug to request a feature that makes the exception unneeded. When the requested feature is available and stable, the exception becomes invalid and the feature must be used instead. My idea is that QA can not enforce controversial things before such a policy exists. Otherwise exceptions stay only a theoretical possibility, and arguments continue. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp5PvPaEwYUz.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thu, 2 Mar 2006 11:35:12 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | * Just because breaking policy breaks a QA tool, but is guaranteed to | never break itself (formatting policy, like space vs. tab etc.) | does not increase the severity of the breakage. I'd argue against this one. See, it's possible to deliberately circumvent some of repoman's checks by doing weird whitespace and syntax trickery. There's also no way to fix repoman short of writing a fully functional bash parsing tool -- which is complicated enough that even bash doesn't have one that works in some releases... -- 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] Re: [gentoo-core] Resignation
Duncan wrote: Seeing this news makes me very sad, as ferringb was a name I had associated with trust and integrity of opinion and developer skills. It's certainly a loss for Gentoo, and as Gentoo is now a part of me, a loss I'll feel personally, as well, but unfortunately, those times do come. As with Donnie and the others, only user to dev, I wish you well. May our paths meet again! Wow, Duncan is so sad he only wrote one paragraph! Seriously man, you will be missed. Colin -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Lance Albertson [EMAIL PROTECTED] said: Ciaran McCreesh wrote: I'd argue against this one. See, it's possible to deliberately circumvent some of repoman's checks by doing weird whitespace and syntax trickery. There's also no way to fix repoman short of writing a fully functional bash parsing tool -- which is complicated enough that even bash doesn't have one that works in some releases... QA shouldn't have to depend on the tools you use. The final say should be the human interaction. If doing weird white spaces breaks the tool, but really isn't a QA issue outside of neatness, it shouldn't be waving red flags. Yes, its probably something that should be fixed, but it shouldn't be a critical one just because the tool is broken and can't handle the weirdness. I agree. Coding standards, while they may qualify as violations, are not as severe, but are definitely things we would like to see fixed. They are there to make readability across ebuilds easier since everything will be formatted the same way for a developer to see. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgplmu4fjgdQn.pgp Description: PGP signature
Re: [gentoo-dev] Resignation
Brian, you'll be missed... can you at least pop by once and i while? always enjoyed humping you... /me 's list off biatchus is reducing... good luck in the future mate, may you conquer your fears and reach your dreams... don't forget Ne humanus crede -- Defer no time, delays have dangerous ends Ne humanus crede Jochen Maes Gentoo Linux Gentoo Belgium http://sejo.be http://gentoo.be http://gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | QA shouldn't have to depend on the tools you use. Sure. However, the tree is far too large to check manually for many things. If we were to do the Sekrit Tool's IUSE check manually, for example, we'd still be in app-something, and would have missed many of the screwups. | The final say should | be the human interaction. If doing weird white spaces breaks the tool, | but really isn't a QA issue outside of neatness, it shouldn't be | waving red flags. The problem is, without fixing the syntax weirdness it's not possible to tell whether red flags should be being waved for something else. | Yes, its probably something that should be fixed, | but it shouldn't be a critical one just because the tool is broken | and can't handle the weirdness. That's the thing... Doing static analysis on bash code is ludicrously difficult. If you don't believe me, try writing a tool that will figure out all ebuilds that have a redundant src_compile. It's a heck of a lot easier to do if you assume that developers will use sane syntax. Where developers don't use sane syntax, the only way to deal with it is to check it by hand. We don't have enough developers to do that. -- 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
Ciaran McCreesh wrote: On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | QA shouldn't have to depend on the tools you use. Sure. However, the tree is far too large to check manually for many things. If we were to do the Sekrit Tool's IUSE check manually, for example, we'd still be in app-something, and would have missed many of the screwups. Then fix the tool. I find it somehow ironic that a member of the QA team is trying to force a 'work-around' just to avoid fixing the source of the problem. -- Kind Regards, Simon Stelling Gentoo/AMD64 Member -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Thu, 02 Mar 2006 19:09:28 +0100 Simon Stelling [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson | [EMAIL PROTECTED] wrote: | | QA shouldn't have to depend on the tools you use. | | Sure. However, the tree is far too large to check manually for many | things. If we were to do the Sekrit Tool's IUSE check manually, for | example, we'd still be in app-something, and would have missed many | of the screwups. | | Then fix the tool. I find it somehow ironic that a member of the QA | team is trying to force a 'work-around' just to avoid fixing the | source of the problem. How? Writing a full bash parser is extremely difficult and would be a complete waste of time. It's far saner to assume sane syntax, and just bail out when crazy stuff is encountered. Sane syntax is not a work around -- it's a basic thing that should be expected from any source file that has to be worked on by more than one person, or even one person over a long period of time. Syntax is already, at least to a certain extent, mandated by policy. The question at hand is whether violations of this policy should be effectively ignored, or whether they should be treated as potentially severe simply because they mask other problems. -- 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
Ciaran McCreesh [EMAIL PROTECTED] said: It's a heck of a lot easier to do if you assume that developers will use sane syntax. Where developers don't use sane syntax, the only way to deal with it is to check it by hand. We don't have enough developers to do that. I don't see where anyone is saying that we shouldn't fix things to adhere to coding standards. We are just saying it is not a, OMG you broke it! problem. It is about appropriate responses to the problems we encounter. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpLZFPLlfZyj.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Ciaran McCreesh wrote: On Thu, 02 Mar 2006 19:09:28 +0100 Simon Stelling [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson | [EMAIL PROTECTED] wrote: | | QA shouldn't have to depend on the tools you use. | | Sure. However, the tree is far too large to check manually for many | things. If we were to do the Sekrit Tool's IUSE check manually, for | example, we'd still be in app-something, and would have missed many | of the screwups. | | Then fix the tool. I find it somehow ironic that a member of the QA | team is trying to force a 'work-around' just to avoid fixing the | source of the problem. How? Writing a full bash parser is extremely difficult and would be a complete waste of time. It's far saner to assume sane syntax, and just bail out when crazy stuff is encountered. Sane syntax is not a work around -- it's a basic thing that should be expected from any source file that has to be worked on by more than one person, or even one person over a long period of time. It should be a basic thing to expect the QA tool knows how to bail out correctly and resume looking for more important critical issues. QA should not revolve around the tools you use. Technical difficulties in the QA tool dealing with weird syntax's should not provoke a red flag on a particular package. Yes, those weirdness issues should be fixed, but the tool should not hinder the overall outcome of the QA process. So what if it takes too much time to fix it, then just have it ignore that package (and mark it to be viewed later by hand) and move on to the next package. -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
On Thu, 02 Mar 2006 13:15:48 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | It should be a basic thing to expect the QA tool knows how to bail out | correctly and resume looking for more important critical issues. Sure. But what if more important critical issues are being masked by weird syntax? | QA should not revolve around the tools you use. There are not enough people to check the entire tree by hand. Even if there were, manual checks are extremely tricky to do properly. Humans are extremely bad at picking out errors like transposed letters or a missed captial in a package name. The tools are extremely important. Without them most QA mistakes will go unnoticed until they cause breakage. | Technical difficulties in the QA tool dealing with weird syntax's | should not provoke a red flag on a particular package. Not flagging a weird package can lead to breakage being missed. | So what if it takes too much time to fix it, then just have it ignore | that package (and mark it to be viewed later by hand) and move on to | the next package. Doable, but not reliably, only for so long as it's a very small number of affected packages. Here's why manual checks don't scale. Some of the following *DEPEND specifications are broken. Some are not. Without using a tool, pick out which ones are broken. Then say how long it took you to do it. For comparison, at least one QA tool can do these in well under a hundredth of a second. RDEPEND=|| ( ( x11-libs/libXext x11-libs/libX11 x11-libs/libXau x11-libs/libXdmcp x11-libs/libXkbui ) virtual/x11 ) DEPEND=~app-editors/vim-core-7.0_alpha20060228 || ( x11-libs/libXext virtual/x11 ) !aqua? ( gtk? ( =x11-libs/gtk+-2.6 virtual/xft gnome? ( =gnome-base/libgnomeui-2.6* ) ) !gtk? ( motif? ( x11-libs/openmotif ) !motif? ( nextaw? ( x11-libs/neXtaw ) !nextaw? ( || ( x11-libs/libXaw virtual/x11 ) ) ) ) ) !bootstrap? ( sys-devel/patch ) cscope? ( dev-util/cscope ) gpm? ( =sys-libs/gpm-1.19.3 ) perl? ( dev-lang/perl ) python? ( dev-lang/python ) acl? ( sys-apps/acl ) ruby? ( virtual/ruby ) mzscheme? ( dev-lisp/mzscheme ) netbeans? ( dev-util/netbeans ) =sys-apps/sed-4 sys-devel/autoconf dev-util/ctags =sys-libs/ncurses-5.2-r2 RDEPEND= ( !gnome-base/gnome-core =dev-libs/glib-2.8.6 =x11-libs/gtk+-2.8.11 =dev-libs/atk-1.10.3 =x11-libs/pango-1.10.3 =dev-libs/libxml2-2.6.23 =dev-libs/libxslt-1.1.15 =media-libs/audiofile-0.2.6-r1 =media-sound/esound-0.2.36 =x11-libs/libxklavier-2 =media-libs/libart_lgpl-2.3.17 =dev-libs/libIDL-0.8.6 =gnome-base/orbit-2.12.5 =x11-libs/libwnck-2.12.3 =x11-wm/metacity-2.12.3 =gnome-base/gnome-keyring-0.4.6 =gnome-extra/gnome-keyring-manager-2.12 =gnome-base/gnome-vfs-2.12.2 =gnome-base/gnome-mime-data-2.4.2 =gnome-base/gconf-2.12.1 =net-libs/libsoup-2.2.7 =gnome-base/libbonobo-2.10.1 =gnome-base/libbonoboui-2.10.1 =gnome-base/libgnome-2.12.0.1 =gnome-base/libgnomeui-2.12 =gnome-base/libgnomecanvas-2.12 =gnome-base/libglade-2.5.1 =gnome-extra/bug-buddy-2.12.1 =gnome-base/control-center-2.12.3 =gnome-base/eel-2.12.2 =gnome-base/nautilus-2.12.2 =media-libs/gstreamer-0.8* =media-libs/gst-plugins-0.8* =gnome-extra/gnome-media-2.12 =media-sound/sound-juicer-2.12.3 =media-video/totem-1.2.1 =media-gfx/eog-2.12.3 =www-client/epiphany-1.8.4.1 =app-arch/file-roller-2.12.3 =gnome-extra/gcalctool-5.6.31 =gnome-extra/gconf-editor-2.12.1 =gnome-base/gdm-2.8.0.7 =x11-libs/gtksourceview-1.4.2 =app-editors/gedit-2.12.1 =app-text/evince-0.4.0 =gnome-base/gnome-desktop-2.12.3 =gnome-base/gnome-session-2.12.0 =gnome-base/gnome-applets-2.12.3 =gnome-base/gnome-panel-2.12.3 =gnome-base/gnome-menus-2.12.0 =x11-themes/gnome-icon-theme-2.12.1 =x11-themes/gnome-themes-2.12.3 =x11-themes/gtk-engines-2.6.7 =x11-themes/gnome-backgrounds-2.12.3.1 =x11-libs/vte-0.11.17 =x11-terms/gnome-terminal-2.12.0 =gnome-extra/gucharmap-1.4.4 =gnome-base/libgnomeprint-2.12.1 =gnome-base/libgnomeprintui-2.12.1 =gnome-extra/gnome-utils-2.12.2 =gnome-extra/gnome-games-2.12.3 =gnome-base/librsvg-2.12.7 =gnome-extra/gnome-system-monitor-2.12.2 =gnome-base/libgtop-2.12.2 =x11-libs/startup-notification-0.8 =gnome-extra/gnome2-user-docs-2.8.1 =gnome-extra/yelp-2.12.2 =gnome-extra/zenity-2.12.1 =net-analyzer/gnome-netstatus-2.12.0 =net-analyzer/gnome-nettool-1.4.1 cdr? ( =gnome-extra/nautilus-cd-burner-2.12.3 ) dvdr? ( =gnome-extra/nautilus-cd-burner-2.12.3 ) hal? ( =gnome-base/gnome-volume-manager-1.5.4 ) =gnome-extra/gtkhtml-3.8.2 =mail-client/evolution-2.4.2.1 =gnome-extra/evolution-data-server-1.4.2.1 =gnome-extra/evolution-webcal-2.4.1 =net-misc/vino-2.12.0 =app-admin/gnome-system-tools-1.4.1 =app-admin/system-tools-backends-1.4.2 accessibility? ( =gnome-extra/libgail-gnome-1.1.3 =gnome-base/gail-1.8.8 =gnome-extra/at-spi-1.6.6 =app-accessibility/dasher-3.2.18 =app-accessibility/gnome-mag-0.12.3 =app-accessibility/gnome-speech-0.3.9 =app-accessibility/gok-1.0.5 =app-accessibility/gnopernicus-0.11.8 ) ) -- Ciaran McCreesh : Gentoo Developer (Wearer of the
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 17:45, Ciaran McCreesh wrote: On Thu, 2 Mar 2006 11:35:12 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | * Just because breaking policy breaks a QA tool, but is guaranteed to | never break itself (formatting policy, like space vs. tab etc.) | does not increase the severity of the breakage. I'd argue against this one. See, it's possible to deliberately circumvent some of repoman's checks by doing weird whitespace and syntax trickery. There's also no way to fix repoman short of writing a fully functional bash parsing tool -- which is complicated enough that even bash doesn't have one that works in some releases... I'm also convinced that deliberate circumvention is easy to detect. QA should be able to fix these issues on itself anyway. If people deliberately subvert QA in these kinds of way, In my opinion, they are in need of a serious talk with devrel. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpHUMOGgR5Vl.pgp Description: PGP signature
Re: [gentoo-dev] What's on with ejabberd and relatives?
Am Sonntag, den 26.02.2006, 21:25 -0800 schrieb Donnie Berkholz: [...] You might want to talk to the maintainer and herd, not all of us. Or even file a bug for updates -- some people are very busy and just don't notice there's a new version. Tried to talk to the maintainer, no answer for days. What would you suggest to do now? Greets, Lars -- Kriterium des Wahren ist nicht seine unmittelbare Kommunizierbarkeit an jedermann -- Theodor Wiesengrund Adorno, aus: »Negative Dialektik« name: Lars H. Strojny web: http://strojny.net street: Engelsstraße 23blog: http://usrportage.de city: D-51103 Köln mail/jabber: [EMAIL PROTECTED] f-print: 1FD5 D8EE D996 8E3E 1417 328A 240F 17EB 0263 AC07 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] QA Roles v2
On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | I'm also convinced that deliberate circumvention is easy to detect. In that case, please provide a list of cases where !arch? flags are being used to circumvent repoman warnings, where the correct solution would be to use use.mask. My reasonably educated guess is that this is the most common kind of deliberate circumvention to avoid a repoman error. Unfortunately, detecting foo? ( !arch? ( somepackage ) ) gets a whole load of false positives. I already tried that one without success... -- 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
On Thursday 02 March 2006 19:28, Mark Loeser wrote: Ciaran McCreesh [EMAIL PROTECTED] said: It's a heck of a lot easier to do if you assume that developers will use sane syntax. Where developers don't use sane syntax, the only way to deal with it is to check it by hand. We don't have enough developers to do that. I don't see where anyone is saying that we shouldn't fix things to adhere to coding standards. We are just saying it is not a, OMG you broke it! problem. It is about appropriate responses to the problems we encounter. That is my point exactly. I do encourage QA though to make available a list of those syntax issues that break their tools. Take it for a positive spin, developers will then be prepared to accomodate QA. We all want quality. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgptQ7HUvX6fU.pgp Description: PGP signature
Re: [gentoo-dev] What's on with ejabberd and relatives?
On Thu, 2006-02-03 at 21:14 +0100, Lars Strojny wrote: Am Sonntag, den 26.02.2006, 21:25 -0800 schrieb Donnie Berkholz: [...] You might want to talk to the maintainer and herd, not all of us. Or even file a bug for updates -- some people are very busy and just don't notice there's a new version. Tried to talk to the maintainer, no answer for days. What would you suggest to do now? Then you ask the herd.. But it seems humpback is still responsive, look at his reply to bug #101708 -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On 02-03-2006 20:19:19 +, Ciaran McCreesh wrote: On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | I'm also convinced that deliberate circumvention is easy to detect. In that case, please provide a list of cases where !arch? flags are being used to circumvent repoman warnings, where the correct solution Circumvent? Can you elaborate on that? repoman does have a problem with this, while portage does not. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 21:19, Ciaran McCreesh wrote: On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | I'm also convinced that deliberate circumvention is easy to detect. In that case, please provide a list of cases where !arch? flags are being used to circumvent repoman warnings, where the correct solution would be to use use.mask. My reasonably educated guess is that this is the most common kind of deliberate circumvention to avoid a repoman error. Then explain people that doing this is not the way. I would suspect that people think that this is the actual solution. It's also not really like people would do this to hide the fact that they have hidden a global rm -rf somewhere around.And is it really a quality issue? In all cases? There must be cases where the problem is package + arch + useflag specific, and this solution solves it. What I mean with deliberate, is circumventing when knowing it is wrong. If people know it's wrong, and still do it, they are clearly malvolent. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpDiTiKMvNES.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thu, 2 Mar 2006 21:29:30 +0100 Grobian [EMAIL PROTECTED] wrote: | On 02-03-2006 20:19:19 +, Ciaran McCreesh wrote: | On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED] | wrote: | | I'm also convinced that deliberate circumvention is easy to | | detect. | | In that case, please provide a list of cases where !arch? flags are | being used to circumvent repoman warnings, where the correct | solution | | Circumvent? Can you elaborate on that? repoman does have a problem | with this, while portage does not. Okay. This is a rather hypothetical example, since alsa is masked on relevant profiles, but it's a nice, easy to understand case that's on a worryingly common theme. Say you create a new package, which we'll call mysoundthing. You add mysoundthing 1.1 to the tree, and it picks up a ~sparc keyword. Along comes mysoundthing 1.2, complete with optional ALSA support. You add in a dep of alsa? ( whatever the alsa libraries are these days ), and try to commit it. Repoman complains that the alsa libraries are unkeyworded on sparc. Now, you've heard that dropping keywords is bad. But you have a clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets past repoman just fine. Along comes 2006 (or late 2005), and some sparc profiles get working ALSA support. So, the ALSA libraries are keyworded / profile masked as appropriate. Along comes joeuser, who installs mysoundthing. He wants ALSA support, so he turns on the alsa USE flag. Sure enough, emerge -pv indicates that ALSA will be enabled. However... Because of the nasty !arch? hack, he won't get alsa support until the arch team goes through and fixes this ebuild (and probably several others too...). The correct solution is to get the alsa USE flag use.masked on various profiles (as, in the alsa case, it is). However, there are a whooole load of ebuilds in the tree that don't do this properly. Scary sidenote: a similar hack has lead to some forums users suggesting that the way to avoid getting mozilla as part of gnome was to use USE=mips. This issue has been a major pain in the ass for some of the arch teams, and it will very likely be another major pain in the ass in the future, again and again. -- 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
On Thu, 2 Mar 2006 21:38:33 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | Then explain people that doing this is not the way. Have done, repeatedly, as have many others. | And is it really a qualityissue? In all cases? There must be cases | where the problem is package + arch + useflag specific, and this | solution solves it. This is most definitely a quality issue in cases where it is misused. See my reply to Grobian for why it's a huge problem. And yes, there are legit cases of using !arch? inside DEPEND, which is what makes it even harder to detect deliberate repoman circumvention. -- 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
Stuart Herbert [EMAIL PROTECTED] said: Hi Mark, This draft seems to be effectively the same as the last one. I'm sorry, but personally I don't see how this draft is substantially different from the one posted originally. It looks like you've decided not to address the points I raised about your original draft: I never said it was different. I said I added some things based on feedback I got. As I said in the last thread, I disagree with many of the things you have come up with. You are free to try and convince me otherwise. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpsVcWsbNh6w.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 21:51, Ciaran McCreesh wrote: On Thu, 2 Mar 2006 21:38:33 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | Then explain people that doing this is not the way. Have done, repeatedly, as have many others. | And is it really a qualityissue? In all cases? There must be cases | where the problem is package + arch + useflag specific, and this | solution solves it. This is most definitely a quality issue in cases where it is misused. See my reply to Grobian for why it's a huge problem. And yes, there are legit cases of using !arch? inside DEPEND, which is what makes it even harder to detect deliberate repoman circumvention. I've read your explanation in the other reply. I agree with you that it is indeed an issue. Paul ps. The explanation was clear to me. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpyjB4SoEQ9o.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thu, 2006-03-02 at 20:49 +, Ciaran McCreesh wrote: Now, you've heard that dropping keywords is bad. But you have a clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets past repoman just fine. STOP As any arch can tell you, that's never stopped me - *IF* you do it correctly, ie comment out the existing keywords, add the keywords that the package can support, and file a bug against the arch's that you had to drop explaining the need for re-keywording because of a new dep that they don't yet support. AFAIK that's the correct way to do it - and I believe that pretty strongly since at this point there isn't a single arch that wouldn't have filed a grievance against me otherwise. Sure, those bugs may stay open for months and months and months because ia64 doesn't have the resources to devote (which is understood), but at that point you have 2 references for users, the ebuild with the commented out line, the ChangeLog, and the bug. Is this not how its supposed to be done? Because if it is, maybe those insistant on the !arch method should be pointed to that and leave it up to the arch's to make the decision of whether to keyword or disable specific support. Devs acting on behalf of a herd shouldn't be making these kind of arch decisions, but instead leaving it up to devs acting with their arch hats on. Maybe the two meet under the same roof sometimes, but more times than not they don't. Yep, that's a lot more work and effort and pain - but afaik it follows good qa methods. And despite the length of this message, I haven't spoken on one side of the fence or the other I think...sweet :) ~mcummings signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] QA Roles v2
On Thu, 02 Mar 2006 16:19:58 -0500 Michael Cummings [EMAIL PROTECTED] wrote: | On Thu, 2006-03-02 at 20:49 +, Ciaran McCreesh wrote: | Now, you've heard that dropping keywords is bad. But you have a | clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). | This gets past repoman just fine. | | STOP As any arch can tell you, that's never stopped me - *IF* you do | it correctly, ie comment out the existing keywords, add the keywords | that the package can support, and file a bug against the arch's that | you had to drop explaining the need for re-keywording because of a | new dep that they don't yet support. AFAIK that's the correct way to | do it Yup. I probably should've mentioned that as part of the explanation... The correct way to proceed, in the general case, is to contact the arch team and ask them to use.mask or keyword deps as appropriate. Keywords can be dropped if and only if a bug is filed. -- 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] What's on with ejabberd and relatives?
Lars Strojny wrote: Am Sonntag, den 26.02.2006, 21:25 -0800 schrieb Donnie Berkholz: [...] You might want to talk to the maintainer and herd, not all of us. Or even file a bug for updates -- some people are very busy and just don't notice there's a new version. Tried to talk to the maintainer, no answer for days. What would you suggest to do now? Greets, Lars Just because I don't answer does not mean I dont read. Work is in progress at the proper places (bugzilla is the place, private e-mail or this list is not). -- Gustavo Felisberto (HumpBack) Web: http://dev.gentoo.org/~humpback Blog: http://blog.felisberto.net/ It's most certainly GNU/Linux, not Linux. Read more at http://www.gnu.org/gnu/why-gnu-linux.html . - signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 16:19, Michael Cummings wrote: On Thu, 2006-03-02 at 20:49 +, Ciaran McCreesh wrote: Now, you've heard that dropping keywords is bad. But you have a clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets past repoman just fine. STOP As any arch can tell you, that's never stopped me yes, but you do not represent every single dev :) we still have occurrences in the tree where people wrongly utilize the aforementioned syntax ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 04:01, Stuart Herbert wrote: * There is no proposal for a process to formulate, and gain wide approval for new QA standards. This week, there's been an example of the QA team documenting a QA standard *after* a bug was raised about a QA violation ... and then that document being used as if that particular QA standard had always been in the document. i chatted on irc with a few peeps about this and here's what has been rolling around in my noggin ... we're going to have two documents of sorts ... the balls-to-the-wall happy-to-be-hardcore nothing-more-official-than-this devrel document ... and then we're going to have the stop-cant-stop-my-feet QA guidelines which is quite dynamic and meant to outline what the QA team is looking for at any particular point in time to get into the QA guidelines, you go through the QA team ... to get into the devrel document, you go through the devrel doc maintainers. to increase visibility here, i think that all significant changes to policy that are Incorporated into the devrel handbook should have a notice sent to the gentoo dev mailing list first. thus if people strongly object, we can resolve those differences without having people upset when something they disagree with and have never heard of is thrown in their FACE. as for the QA document, there is a QA list where notifications/changes can be sent. then over time we can move relevant pieces of the QA document into the devrel document. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Wednesday 01 March 2006 21:53, Mark Loeser wrote: Here is my updated version after some feedback from people: * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. 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. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
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. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpZANo2PW7H2.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions regarding the new portage API (savior branch)
On Wed, Mar 01, 2006 at 08:15:19PM -0800, Brian wrote: On Wed, 2006-01-03 at 17:39 -0800, Brian Harring wrote: emerge bzr bzr get http://gentooexperimental.org/~ferringb/bzr/saviour cd saviour bzr pull ...roughly. ;) a little too rough :) [EMAIL PROTECTED] ~ $ bzr get http://gentooexperimental.org/~ferringb/bzr/saviour bzr: ERROR: Not a branch: http://gentooexperimental.org/~ferringb/bzr/saviour [EMAIL PROTECTED] ~ $ Try again :) ~harring pgpJVERABoPLh.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions regarding the new portage API (savior branch)
Hi, Brian wrote on Thursday the 2nd of March 2006: [EMAIL PROTECTED] ~ $ bzr get http://gentooexperimental.org/~ferringb/bzr/saviour bzr: ERROR: urllib2.HTTPError: HTTP Error 403: Forbidden at /usr/lib/python2.4/urllib2.py line 480 in http_error_default [EMAIL PROTECTED] ~ $ After getting 156 items in saviour/.bzr/revision-store (219 items in weaves) I'm getting exactly the same error after a few minutes and 285 of 384 packages. Bye, Michael -- Michael Schilling eMail : [EMAIL PROTECTED] URL : http://glcu.sf.net/ IRC : Zerwas on #sfg(IRCnet) and #gentoo.de(freenode) Change my name I remain the same. - Moloko -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions regarding the new portage API (savior branch)
On Thu, Mar 02, 2006 at 06:54:45PM +0100, Michael Schilling wrote: Hi, Brian wrote on Thursday the 2nd of March 2006: [EMAIL PROTECTED] ~ $ bzr get http://gentooexperimental.org/~ferringb/bzr/saviour bzr: ERROR: urllib2.HTTPError: HTTP Error 403: Forbidden at /usr/lib/python2.4/urllib2.py line 480 in http_error_default [EMAIL PROTECTED] ~ $ After getting 156 items in saviour/.bzr/revision-store (219 items in weaves) I'm getting exactly the same error after a few minutes and 285 of 384 packages. See... I always have a helluva time transitioning the repository since I keep forgetting simple things like upload the repo, not an export or reset perms due to umask... Either way, bzr repo should be fine, and a tarball is up there (might be quickest grabbing that and just doing a pull afterwards) ~harring pgpmkLn1TQrvP.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions regarding the new portage API (savior branch)
Brian Harring wrote: I switched over to bzr about 2 months back; svn doesn't allow for offline committing, nor does gentoo's vcs allow for anon*... bzr natively allows for those capabilities, so that's what I'm using. :) http://gentooexperimental.org/~ferringb/bzr/saviour Is where I'll be updating the code for at least the near future. Oh c'mon, be trendy and use git. bzr is so last year. Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Questions regarding the new portage API (savior branch)
Marius Mauch wrote: Does that mean we should drop the SVN branch? Marius I've already removed it from the documentation and added links to Brian's current work on ge.org. As far as the actual repo, I think keeping it around a bit longer might be beneficial, but who knows. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Questions regarding the new portage API (savior branch)
On Thu, Mar 02, 2006 at 10:44:58PM +0200, Marius Mauch wrote: Brian Harring wrote: On 2/28/06, *Michael Schilling* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: - Is one of these svn-web-repository up to date? * http://sources.gentoo.org/viewcvs.py/portage/main/branches/savior/ * http://mzz.mine.nu/bzr/savior-svn/portage/ http://mzz.mine.nu/bzr/savior-svn/portage/ I switched over to bzr about 2 months back; svn doesn't allow for offline committing, nor does gentoo's vcs allow for anon*... bzr natively allows for those capabilities, so that's what I'm using. :) http://gentooexperimental.org/~ferringb/bzr/saviour Is where I'll be updating the code for at least the near future. Does that mean we should drop the SVN branch? Realistically... I have no intention of going back to SVN, haven't for a while. Can't even access the darn thing now a days anyways, thus the branch has fallen further in usefulness to me :) 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. ~harring pgpp4WaacDO2M.pgp Description: PGP signature
