Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On Wed, 7 Dec 2016, Jorge Manuel B. S. Vicetto wrote: I'm asking recuiters directly, but unless someone changed the rules and I was distracted, irc is not mandatory. I've got confirmation that nothing has changed, so irc is not mandatory. I hope this clears any misunderstandings and puts an end to any speculation. Best regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On Wed, 7 Dec 2016, Duncan wrote: james posted on Tue, 06 Dec 2016 22:10:16 -0500 as excerpted: Really, for someone like me, it is just best to avoid irc. FWIW, some 12 years ago now, in 2004, I started using gentoo, with the intent of contributing and potentially eventually becoming a dev. Somewhere along the line but rather early in the process, I read that IRC was absolutely required at least for the final interview, and given that I too strongly prefer email (or for group communications better yet newsgroups, with gmane being that bridge for most mailing lists), I decided my contributions, such as they are, can be better made either elsewhere, or to gentoo, but without becoming a dev. Much later, likely after some recruiters project changes, someone from recruiters clarified that IRC on the final interview isn't actually /required/, there might be ways around it in individual cases. Apparently it does need to be real-time synchronous for some reason, but he suggested that a (VoIP?) phone call or the like could be arranged as an alternative. In theory I could do that. Now it seems to be IRC hard-required again. I'm asking recuiters directly, but unless someone changed the rules and I was distracted, irc is not mandatory. More important than an irc review session though, we have several developers that rarely, if ever, do irc, so it's certainly possible to be a Gentoo Developer and not maintain a regular irc presence. To be clear, irc is a good a way to be part of the team and to quickly talk to others, so we should encourage its use. But encouraging something is not the same as making it mandatory. About not really wanting contribution and making up "barriers", the "barriers" we've put are in our view required to make sure people have a real interest in being in this community and know enough to be able to maintain packages (for those applying for ::gentoo access). Best regards, Jorge Manuel B. S. Vicetto Gentoo Developer PS - Let's please move all this discussion to the project ml as this clearly doesn't belong in the gentoo-dev ml.
Re: [gentoo-dev] Tinderboxing efforts in Gentoo
On Sat, 3 Dec 2016, Michał Górny wrote: On Sat, 3 Dec 2016 13:13:36 + Markos Chandras <hwoar...@gentoo.org> wrote: On 12/03/2016 10:41 AM, Michał Górny wrote: On Sat, 3 Dec 2016 10:35:32 +0100 Patrice Clement <monsie...@gentoo.org> wrote: Friday 02 Dec 2016 14:10:27, Michał Górny wrote : Hi, everyone. I've heard multiple times about various tinderbox projects being started by individuals in Gentoo. In fact, so many different projects that I've forgotten who was working on most of them. I know that Toralf is doing tinderboxing for most of the stuff. What other projects do we have there? What is their status? Is there anything we could try to integrate with pull requests to get a better testing? -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> Continuous integration is all the rage these days and tinderboxing is the obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor doing tinderboxing out of his own will. In reality, we should have a team of devs looking after our own tinderboxes instead of relying on the community. I'm wondering if we could start a donation campain for this project and ask people if they've got spare machines laying around. I know a lot of folks are reading this mailing list so maybe asking on gentoo-dev first for a start would be appropriate. Hardware is not the problem. Lack of software is. Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do instead of reinventing the wheel? [1] http://open.qa/ [2] https://openqa.opensuse.org/ [3] https://openqa.fedoraproject.org/ Do you by any chance happen to know how it maps to our needs? At a first glance it seems quite tangential. Last time I looked at it, a few years ago at FOSDEM, one issue to me, at least for testing release builds, was that it relied on fingerprint of images and time delays. To me it would make more sense to get a "console" and grep the output for relevant strings. I don't know if / how it evolved, so this might no longer be true. Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] Tinderboxing efforts in Gentoo
On Sat, 3 Dec 2016, Rich Freeman wrote: On Sat, Dec 3, 2016 at 9:47 AM, William L. Thomson Jr. <wlt...@o-sinc.com> wrote: On Saturday, December 3, 2016 9:33:00 AM EST Michael Orlitzky wrote: On 12/03/2016 09:25 AM, William L. Thomson Jr. wrote: This is generally considered infeasible: I would not think such, just need a wrapper to run around each package that would get its USE flags and re-emerge it a few times. If a package has 10 USE flags, and if each can be set on/off with no constraints, then that gives you 2^10 different ways to emerge it. May make the requirements of the host system larger or take more time. I am sure processing power could handle that load. Would be nice if someone like Google would sponsor such efforts. They have enough hardware and cloud services to make such feasible. Have you given thought to how long it would take the largest supercomputer in the world to rebuild libreoffice once for each of the 2^28 USE flag combinations it has (not including USE_EXPAND)? It is certainly possible, but I doubt that you're going to get it dedicated to Gentoo for a few weeks whenever one of its deps changes. This is not a reason to give up on tinderboxing. This is just a reason to be realistic about just what it will do. I recall some discussion about tinderboxing suggesting that more important than testing all possible use flag combinations, would be to test: * all use flags disabled (some packages fail miserabily if you don't enable at least one use flag) * all use flags enabled (good to detect conflicts) * default use flags (rely on IUSE defaults - even better if you test it on different profiles to see the impact) * a set of use flags defined by maintainer (mysql ebuilds have a set of USE flags for maintainers to test them) Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] Looking for a generic solution to non-USE-conditional circular deps
On Tue, 14 Apr 2015, Michał Górny wrote: Dnia 2015-04-11, o godz. 16:50:53 Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org napisał(a): On Sat, 11 Apr 2015, Andreas K. Huettel wrote: snip Now if only anyone would remember what these were intended for? Both build and bootstrap are reserved for stage building. The former is used on stage1 and iirc, the latter is used by scripts/bootstrap.sh in the portage tree called during stage2. Maybe we're just trying to re-invent the wheel... No, they are needed for stage building and for that *only*, so please find another solution so you don't end up killing stage building and forcing releng to fix it again. It would be nice if releng would be able to namespace their private flags properly instead of cluttering the global flag namespace with stuff you aren't allowed to touch and reserving the two useful flag names here. As you can see in the commit history, both bootstrap and build were already part of the first use.desc file[1] committed to gentoo-x86, on Fri Apr 12 05:17:16 2002 UTC. So those use flags largely predate the RelEng team and I doubt at that time anyone thought about namespaces. [1] - https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/use.desc?revision=1.1view=markup In fact, I don't even understand why the flags aren't hard-masked if you're not supposed to set them. Of course, that would require some minimal effort of setting stage building stuff to unmask the flag... And all of that needed to be implemented in catalyst and no one did it. It's easy to complain now ignoring the history of the tree, catalyst and release building in Gentoo. Regards, Jorge Manuel B. S. Vicetto Gento Developer, RelEng team lead
Re: [gentoo-dev] Looking for a generic solution to non-USE-conditional circular deps
On Sat, 11 Apr 2015, Andreas K. Huettel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Samstag, 11. April 2015, 16:19:23 schrieb Ciaran McCreesh: build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1] bootstrap - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used during original system bootstrapping [make stage2] However, since both are marked for 'internal use only', I don't think it's a good idea to use them here. So I guess we need a new flag. Does anyone have suggestions how to name it? Incidentally, if those were all migrated to USE_EXPAND_HIDDEN, the dire warnings wouldn't need to be so visible... Now if only anyone would remember what these were intended for? Both build and bootstrap are reserved for stage building. The former is used on stage1 and iirc, the latter is used by scripts/bootstrap.sh in the portage tree called during stage2. Maybe we're just trying to re-invent the wheel... No, they are needed for stage building and for that *only*, so please find another solution so you don't end up killing stage building and forcing releng to fix it again. - -- Andreas K. Huettel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVKTGkAAoJEB9VdM6hupKVONgP/jyWR+iF7rGOFFJxaEwXcaH9 ax/wuipfGehq57iBwLsDagOXqy3IMX5XXLN3he4Bh8YSf+cXgoGY2biojVF8rn3h /Wl0unf4nkbxcPMWN5Upw/v9ZL/ecDPOZjG0btcGfcKtplyguqwxWRQsjflrSi70 D/wrPagHfmUE48eIi2uHErP/vJ6/Dx1vQrnJTFth+ek2zG1Q7MngEq5UpFY4fl8L PaW052QHi3mHR8Be2i0u/9V3ywzETEw7s16fgLafGP0FYtBWR1DqepBUk788BAAD s2HBRbDrZXHj8WwKvJGXimhBNbDk6Cx6W0Rjs2mKhovr/7AdsWHBHcehPCW4SYUU edwz/f18jCaOt80LjMd+7h3EUddN3QlazbpNPTsmr/Jc4DtyNK3hfwpaF6fNAhvN +CApdVgQaTuTmbiB0Dr7TwDt6tlFz4e03pQOgwnvsJimChtQ9QYcLZG6kuFtC84c fvgj63hOqSubPPwB4O8ra89d92TXtxF+JsbQ1AHBoJp9uKOzj43RQ1AsVOg8TCSA 5pk22LUHJWia6pQhAkKfMRlorJQyDNhJFCvsW9cqhCDTQSqA1QyIsEF8hAwO1owb DDArktv/opBQQtx8hXixGevuNkxIldDAqe9424HQsFxoFrOPopmwpv13Y9eCO1tA HYClKo52mtvmeGjC2y4L =eRun -END PGP SIGNATURE-
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
On Sun, 12 Apr 2015, Andrew Savchenko wrote: On Thu, 9 Apr 2015 00:23:29 +0200 Michał Górny wrote: Hello, developers. We have added a new mail alias travis-ci@g.o and set up travis-ci [1] to send notifications on status change there. Please seriously consider adding yourself to the alias, and contributing to the quality of Gentoo. snip While I must admit that travis is a quite convenient tool (thought it has its limitations), I'd like to raise related software freedom concern. Travis itself is a closed, proprietary and non-trivial-to-replace solution. If travis will become essential for Gentoo development, it may undermine development freedom and Gentoo social contract, which states: Gentoo will never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative (OSI). I've seen no one suggest the use of travis is or will be mandatory. What Michał has done is setup the environment to help identify tree breakage. I want to thank him for working on a tool to improve the quality of Gentoo. If travis will change their terms of service in future and our workflow/infra will depends on these checks, whole development process may be hampered. Our infra has no dependency over travis. The only thing we've done infra side about this is to create the alias travis-ci and an ml[1] (gentoo-automated-testing) where we plan to send the output of several automated tools so that interested parties can check the status and fix any issues. [1] - https://archives.gentoo.org/gentoo-automated-testing/ So developers should think twice before depending their workflow on this solution. I'm refusing to sign up to the list which in my opinion indirectly violates Gentoo social contract. I fail to see how by adding yourself to the alias, joining the ml or checking the archives, you are breaking in any way the Social Contract - but every developer is free to choose whether to use this tool or not. If some other free tool (preferably deployed on Gentoo infrastructure) will be used for this task, I'll sign-up right away. If you care about this topic, you should talk to the QA team and developers that have showed an interest in automated testing. Just the other day Magnus sent an email to this ml about a project his working on. Best regards, Andrew Savchenko Regards, Jorge Manuel B. S. Vicetto
Re: [gentoo-dev] Things one could be upset about
On Sun, 18 Jan 2015, Patrick Lauer wrote: On Saturday 17 January 2015 14:00:34 William Hubbs wrote: On Sat, Jan 17, 2015 at 01:44:21PM +0100, Dirkjan Ochtman wrote: On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer patr...@gentoo.org wrote: * Stage3 archives are too fat See https://bugs.gentoo.org/show_bug.cgi?id=531632 We're now shipping three python versions and glib for extra fun! Fix: Motivate releng to stop being silly Why the heck do we ship both 3.3 and 3.4? I forget the exact situation with 2.x and 3.x, but I don't think setting PYTHON_TARGETS to 2.7-only is a great option if that remains the default after installation (although it would be fine for just the initial stages). I'm going to be very blunt. I am sick of the finger being pointed only at releng for this. The issue is package dependencies. If even one package in the tree has a dumb dependency on python, e.g. dev-lang/python, it will pull in all stable versionf of python. Only if you absolutely insist that releng can never deviate from tree. What RelEng has insisted in is building what we have in the tree - which, curiously enough, is a good way to test the tree. Anyway, I've started working on a portdir config for the default stages, not because of this, but because of the caps issue (bug 531788). Which is a silly idea, see bindist useflag, which is locally enabled for stage building and then removed. Oh wait, it's not removed because we can't deviate while deviating. So users regularly find ssl 'broken' ... Building stages with USE=bindist isn't a question of being silly but of making sure we don't give anyone a reason to sue Gentoo. We don't want to force USE=bindist in the released stages, but that means we add one more workaround to catalyst code or we provide a way to specify which use flags we want to use for building the stage and which we want to be kept in make.conf. It took me about 2h of fiddling around to find a few spots where stage3 has useless bloat: - pkgconfig pulling in 30MB of glib - python installing tests (that's 3x 25MB now ...) internal-glib is not something that should be used in the stages. - having more than one python installed (which is not really absolutely necessary, and could easily be reduced to one) If your system has 3 python versions installed because the tree deps make portage install 3 versions, you should expect that to happen in your stages. Since I'll have to work with portdir to address the caps issue above, I'll also take care of this, but if you want to blame someone about this, releng doesn't maintain the tree. Also, by adding this to the releng repo, that means we're going to have more work as we'll have to track new python versions. Out of 700MB on-disk I could prune about 150MB - about 20%, without affecting functionality It's not about pointing a finger, it's about fixing issues when they are easy to fix and not hiding behind a fake complexity argument. (I would fix things, if I had access and/or certainty that patches provided would be integrated ...) I don't recall ever having seen a patch from you to catalyst, so before you suggest we don't want to accept your patches, you may want to send one ;-) Have fun, Patrick Have fun, Jorge
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, 10 Oct 2014, Rich Freeman wrote: On Fri, Oct 10, 2014 at 5:31 PM, W. Trevor King wk...@tremily.us wrote: On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote: In a similar vein, would releng be open to moving stage1/2/3 package sets to virtual packages or package sets? Presently they are inside catalyst, and I think this would clean things up a lot. They're already in the Portage tree (the profile's packages.build for stage1, scripts/bootstrap.sh for stage2, and the profile's packages for stage3) [1]. Obviously this entails work on somebody's part, but would it still make sense to make the stage build process more generic along the lines Robin suggested? That is, instead of having 3 specific places we use to generate a stage1/2/3, we instead just define a stage as a virtual of some kind that optionally depends on another stage (not necessarily using the standard DEPEND mechanism) and then pulls in a list of packages. The root stage would not depend on another stage, and therefore would be built from the host system. All of the above suggestions would require changes to catalyst. In any case, given the way we build a stage1 and bootstrap stage2, that isn't possible. For stage1 and stage2 the *order* we build packages is relevant. We rely on portage following that list in sequence. Furthermore, because of the implicit dependencies and issues with circular dependencies, it would likely be impossible for portage to resolve the list of packages to build for stage1 and stage2 from a virtual. The build system would just iteratively start at the bottom and output a tarball or whatever as each level is completed, then use that as the basis for bootstrapping the next. That's how catalyst already works. To address one point in your last sentence in the above quote: The root stage would not depend on another stage, and therefore would be built from the host system. You almost always don't want to build with the state of a live system, but of a clean seed - that's why releng tells catalyst to use a stage3 as the seed for the stage1. Such a design would also eliminate the need to have the same list of packages define the contents of @system and a stage3. It could also support any number of stages, with any names we wish. No, not really. You're over-thinking this. To be able to split the system set and the stages releng provides, all we need is to fix the bug that was already mentioned before and have releng provide stages built from a stage3 (while removing some packages from the system set) and a list of packages that we want to provide (the ones dropped from system and a select few others). I would also still have stage builds use a profile of some kind - that could be useful from a standpoint of setting USE flags and so on. However, if it made sense to build earlier stages with different flags they could still be specified as USE dependencies (maybe due to circular deps you have to build a package with different set of USE flags before you can build the desired USE flags in a later stage). We build stages using a profile. One of the variables set on stage specs is profile to list the profile to be used in the stage. -- Rich Regards, Jorge Manuel B. S. Vicetto Gentoo Developer PS - As I've warned before, I'm not following closely the dev ml. So you got this reply now, because I just happened to look at the emails in this ml. If you want me to comment further, your best option is to poke me about it.
Re: [gentoo-dev] Add bc back to the stage3
On Mon, 29 Sep 2014, Rich Freeman wrote: On Mon, Sep 29, 2014 at 7:53 AM, Anthony G. Basile bluen...@gentoo.org wrote: Although, I must say, Jorge's is being little premature here, and I doubt the Council will act rashly. So, while I was trying to be balanced in my reply, I'll admit it may have still been a bit too emotionally motivated. I think this was really the bit that I was reacting to. In general I do agree that it is best to let individual teams make the call before escalating to council. I just don't like attitudes along the lines of I'll do what I think is best, and if you don't like it you can do it instead. It is true that we're all volunteers, and we all need to be mindful of that. However, if all Gentoo is to somebody is a place to host their sole-committer git repo, you could probably do better. In this case I reacted more emotionally that I should have. Using your expression above, please consider it as releng is doing what it thinks is best. As the team lead, I was also expressing that to see something as ordinary as deciding if bc should be in stage3 sent to the council to decide, those pushing for that (and that critic wasn't directed to the council members but those pushing this to council), shouldn't be surprised if releng members get upset and decide to spend their time elsewhere. I don't really think that was how Jorge felt, and I think we're all just venting, and my response probably wasn't more helpful than what I replied to, so apologies to all for the line noise. Yes, I was venting. I got a bit upset to see something as simple and ordinary still being discussed (I believe the last time I read about it had been 2 weeks before). To me, this isn't the first time that someone decides to discuss in the dev ml about releng work, without even bothering to let releng know about it. I know that our policies state that technical issues should be raised in the dev ml, although they also support doing the discussion in specialized mls, but they also mention that one should make an effort to contact those involved in the matter. For what its worth, this still isn't on the agenda (I'll probably send out the call later today). I also think that if anybody is feeling really frustrated over the content of stage3/@system and so on, they're probably best off directing that frustration towards getting something like mix-ins supported. :) Gentoo is about choice, but we can only offer the choices that our tools support. -- Rich Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] Add bc back to the stage3
On Sat, 27 Sep 2014, Tom Wijsman wrote: On Sat, 27 Sep 2014 13:22:45 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 27 Sep 2014 12:47:14 +0200 Luca Barbato lu_z...@gentoo.org wrote: Because I'd expect a stage3 to be posix compliant I agree. It's time to replace nano with Vim. Vim is not fully POSIX compliant; you may find it claim mostly in its documentation, but that's where it stays at and thus doesn't suffice... While we're at it, we must make everyone use a POSIX IDE with a ribbon! Jokes aside, this sub discussion is pointless; if we want results, a moderated mailing list as suggested in a reply won't cut it! It seems like everyone needs to chill a bit. Ciaran wasn't trolling, he was making a point. I'm sure everyone around here understood his point. There were no attacks and no foul language, so can we move forward? What is really needed here is a vote by the Council on whether to add bc back to the stage3. If the people do insist, another vote regarding adding or changing an editor to stage3 could be done as well. No, there isn't a need for a Council vote here. This is something up to Releng (in respect to what is in the stages) and to everyone in respect to what is part of the system set. Further, to me, this is a case where if anyone tries to side-step Releng and go over it with a Council decision, than the council members should be ready to start doing Releng work. I've stopped following this mailing list regularly quite sometime ago. To see this thread is still going on and no one bothered to cc releng, to me shows a lack of respect for the people actually doing releases around here, as well as a real lack of interest in getting this done as you can discuss this all you want, but in the end, it's releng that works on this. Regards, Jorge Manuel B. S. Vicetto Gentoo Developer (Releng Lead)
Re: [gentoo-dev] Add bc back to the stage3
On Wed, 17 Sep 2014, Luca Barbato wrote: The bc utility is part of the posix tools and it might be used to build linux among the other stuff. Luca, bc is not in the system set and is a dependency of the kernel or any other package that needs it, so why do we need to include a package that takes ~20 seconds to build? lu Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] Catalyst news item - v2
On Thu, 30 Jan 2014, Jorge Manuel B. S. Vicetto wrote: On Thu, 30 Jan 2014, Jorge Manuel B. S. Vicetto wrote: Here's v2 of the news item. I tried to address the concern with showing this news item to anyone with catalyst and not only running catalyst-. If anyone insists, I don't mind restricting the news item to , in which case I'll drop the note about this only affecting . I've committed this news item to the gentoo-news repository. Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] Catalyst news item
On Thu, 30 Jan 2014, Peter Stuge wrote: Jorge Manuel B. S. Vicetto wrote: +After many years of stalled development I'm quite allergic to statements like this. Remember that you may not really be representing everyone when you express your own opinion - even if it is shared by many. many years of stalled development can only be true if there was no development whatsoever for many years - which I don't really think fits catalyst at all. I think the statements discards the efforts that have gone into catalyst during the last many years - however small! I understand your comment and in principle agree with it. However, in this case, as I was one of those closest to the catalyst development in the mentioned period, I believe I'm entitled to use such words about myself ;) In any case, I'll present v2 in a bit to address the comments thus far. //Peter
Re: [gentoo-dev] Catalyst news item - v2
On Thu, 30 Jan 2014, Jorge Manuel B. S. Vicetto wrote: Here's v2 of the news item. I tried to address the concern with showing this news item to anyone with catalyst and not only running catalyst-. If anyone insists, I don't mind restricting the news item to , in which case I'll drop the note about this only affecting . Hi. I would like to commit the following news item in the next few days. diff --git a/2014/2014-01-31-catalyst-head-changes/2014-01-31-catalyst-head-changes.en.txt b/2014/2014-01-31-catalyst-head-changes/2014-01-31-catalyst-head-changes.en.txt new file mode 100644 index 000..7c5736e --- /dev/null +++ b/2014/2014-01-31-catalyst-head-changes/2014-01-31-catalyst-head-changes.en.txt @@ -0,0 +1,22 @@ +Title: Catalyst head changes +Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org +Content-Type: text/plain +Posted: 2014-01-31 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: dev-util/catalyst + +After many years of stalled development, the catalyst repository is +going to have major changes introduced to master in the next few days. +The work done in the rewrite branch[1] by Brian Dolbec, is finally +going to be merged into master through the pending branch[2]. +Anyone using catalyst to produce stages is advised to use the latest +release (currently 2.0.16). If you need to track the stable branch, +please use the catalyst 2.0. ebuild that tracks the 2.X branch. +Anyone wanting to help with catalyst development and testing is +encouraged to use the version and report issues to the catalyst +team, pending the understanding that master may be broken during the +next few months. + + [1] - http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=shortlog;h=refs/heads/rewrite-on-master + [2] - http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=shortlog;h=refs/heads/pending diff --git a/2014/2014-01-31-catalyst-head-changes/2014-01-31-catalyst-head-changes.en.txt b/2014/2014-01-31-catalyst-head-changes/2014-01-31-catalyst-head-changes.en.txt new file mode 100644 index 000..0ea8a28 --- /dev/null +++ b/2014/2014-01-31-catalyst-head-changes/2014-01-31-catalyst-head-changes.en.txt @@ -0,0 +1,28 @@ +Title: Catalyst head changes +Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org +Content-Type: text/plain +Posted: 2014-01-31 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: dev-util/catalyst + +After a long period on life support, the catalyst repository is +going to have major changes introduced to master in the next few days. +The work done in the rewrite branch[1] by Brian Dolbec, is finally +going to be merged into master through the pending branch[2]. +Anyone using catalyst to produce stages is advised to use the latest +release (currently 2.0.16). If you need to track the stable branch, +please use the catalyst 2.0. ebuild that tracks the 2.X branch. +Anyone wanting to help with catalyst development and testing is +encouraged to use the version and report issues to the catalyst +team, pending the understanding that master may be broken during the +next few months. Please report any issues to our bugzilla[3]. You +can always find us in the #gentoo-releng irc channel of freenode. +To be clear, these changes will only affect catalyst- and the +master branch of the repository. If you're not using either, this +doesn't affect you. + + [1] - http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=shortlog;h=refs/heads/rewrite-on-master + [2] - http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=shortlog;h=refs/heads/pending + [3] - https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Hosted%20Projects +Component: Catalyst Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
[gentoo-dev] Catalyst news item
Hi. I would like to commit the following news item in the next few days. diff --git a/2014/2014-01-31-catalyst-head-changes/2014-01-31-catalyst-head-changes.en.txt b/2014/2014-01-31-catalyst-head-changes/2014-01-31-catalyst-head-changes.en.txt new file mode 100644 index 000..7c5736e --- /dev/null +++ b/2014/2014-01-31-catalyst-head-changes/2014-01-31-catalyst-head-changes.en.txt @@ -0,0 +1,22 @@ +Title: Catalyst head changes +Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org +Content-Type: text/plain +Posted: 2014-01-31 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: dev-util/catalyst + +After many years of stalled development, the catalyst repository is +going to have major changes introduced to master in the next few days. +The work done in the rewrite branch[1] by Brian Dolbec, is finally +going to be merged into master through the pending branch[2]. +Anyone using catalyst to produce stages is advised to use the latest +release (currently 2.0.16). If you need to track the stable branch, +please use the catalyst 2.0. ebuild that tracks the 2.X branch. +Anyone wanting to help with catalyst development and testing is +encouraged to use the version and report issues to the catalyst +team, pending the understanding that master may be broken during the +next few months. + + [1] - http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=shortlog;h=refs/heads/rewrite-on-master + [2] - http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=shortlog;h=refs/heads/pending Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] Catalyst news item
On Wed, 29 Jan 2014, W. Trevor King wrote: On Thu, Jan 30, 2014 at 02:14:53AM -0100, Jorge Manuel B. S. Vicetto wrote: +After many years of stalled development, the catalyst repository is +going to have major changes introduced to master in the next few days. ?the next few days? sounds a little optimistic to me ;). ?next few months?, which you use later, seems more accurate here too. In the next few days, master is going to be open again for work. It doesn't mean we're going to get immediate commits or that it will break the next day. In the next few months, no one should expect master to work / build all the time. +report issues to the catalyst team, This reads ?catalyst@? to me, which is fine if that's what you indend. However, you may want to suggest gentoo-catalyst@ instead, if you want a wider net of possible responders. I didn't use an email as I didn't mean to imply that the reports should be done by email. I expect we will prefer using bugzilla or poking us in #gentoo-releng, at least for quick status inquiries / updates. Cheers, Trevor Regards, Jorge.
Re: [gentoo-dev] Catalyst news item
On Wed, 29 Jan 2014, Matt Turner wrote: On Wed, Jan 29, 2014 at 7:14 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: +Display-If-Installed: dev-util/catalyst Display-If-Installed: =dev-util/catalyst- Matt, my plan was to show this to anyone using catalyst. I believe this news item is relevant and interesting for anyone using catalyst, but if others disagree, I can restrict it to only those using catalyst-. Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, 14 Dec 2013, William Hubbs wrote: On Sat, Dec 14, 2013 at 05:56:33AM +, Jorge Manuel B. S. Vicetto wrote: On Tue, 10 Dec 2013, William Hubbs wrote: My issue with what we are currently doing is not whether we have a default network provider in the stages or not, but it is just that the netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any reason. William, the push for the use flag was to ensure that users would keep the existing networking functionaility and more importantly their network configuration. Without it, portage would happily clean /etc/conf.d/net - something not desirable by most. Hi Jorge, Portage will not clean /etc/conf.d/net, and this is not related to the use flag. That is handled by the block starting at line 212 in openrc-0.12.4.ebuild. I had to modify the file so portage wouldn't remove it. Ah, that's good to know. I mentioned /etc/conf.d/net as you know I lost it on a production box when the new openrc with netifrc was initially released. It's good to know that was fixed on a different way. The push for the use flag was because people didn't think it was enough for me to put out a news item telling them that they should emerge netifrc if they wanted to continue using it once this version of OpenRC was installed. OK, I see what you mean. To be clear, I'm not ready to have a stage3 without netifrc. If / when we update catalyst so that the new stage3 is the sum of @system and additional packages, we can move netifrc to that list. William Jorge
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Tue, 10 Dec 2013, William Hubbs wrote: My issue with what we are currently doing is not whether we have a default network provider in the stages or not, but it is just that the netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any reason. William, the push for the use flag was to ensure that users would keep the existing networking functionaility and more importantly their network configuration. Without it, portage would happily clean /etc/conf.d/net - something not desirable by most.
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, 7 Dec 2013, Rich Freeman wrote: On Sat, Dec 7, 2013 at 12:52 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: snip Honestly, I'm not really sure why anyone would want to make stage3 less functional than it already is but honestly net isn't something I'm ready to give up just yet. It isn't about making the stage3 less functional, but about giving the user a choice. We don't stick a kernel in stage3, despite the fact that everybody needs one. We don't stick an MTA in the stage3 despite the fact that one of those is pretty hard to live without. Now that Gentoo apparently offers a wide selection of network managers, perhaps it makes sense to have the user pick which one they want to use. IMHO the purpose of @system and the stage3 is to solve the circular dependency problem inherent in bootstrapping. It really shouldn't contain anything beyond this. By all means have an @useful-utils set or some kind of profile that auto-installs a list of packages like openssh, vim, and so on. However, these are not required to bootstrap a system and I'm not sure why we should be forcing them into the @system set as a result. I disagree with you about this - stage3 and @system are not the same. The purpose of a stage3 is to provide the minimum sane environment to do an install. We provide some packages because of convenience. So even though someone might not want to connect remotely, there's no valid reason to drop openssh from a stage3. Just like we'll keep providing nano and less in the stages - they may not be needed, but it makes sense to provide them. Another option would be to have things installed in the stage3 that are not part of the @system set, so that they would be depcleaned at a later date. I'm not a big fan of that, however, mainly because it could be a curve-ball for somebody to deal with after they think they've gotten everything working. I think users will have a better understanding of how their system is set up if they put things there than if things start out there but get yanked out from under them. There's an open bug about this - https://bugs.gentoo.org/show_bug.cgi?id=393445 Some of the previous comments are based with this bug in mind.
Re: [gentoo-dev] Re: New install isos needed
On Mon, 25 Mar 2013, Tobias Klausmann wrote: Hi! On Mon, 25 Mar 2013, Markos Chandras wrote: On 25 March 2013 09:30, Tobias Klausmann klaus...@gentoo.org wrote: I'll say it again: if we don't make install media anymore and tell people to use SRCD instead, we will lose installation support for at least alpha, ppc/64, hppa and ia64. As for sparc, mips and arm, there _might_ be alternatives, but I'm not aware of them. We can suggest SRCD as an alternative just for the amd64/x86 isos WFM. Note that I _agree_ that all the install image building is eating time and is a source for errors. While I've personally recommended users to use SRCD and use it myself for a few things, I won't stop working on the amd64 / x86 releases. Also, from a QA standpoint, having automated builds is very important as it allows us to catch many problems with the tree or specific packages. Thing is, if we only build them for fringe archs, we might run into the oh well, it's just for those few dozen users, it doesn't matter if it's slightly broken effect. Even though the images were broken for the mainstream, it took quite a while (and a longish thread) for them to be fixed/taken care of. Imagine if they'd only been broken for ppc64 and alpha. As I said, I won't stop working on the amd64 / x86 releases. While my arch team (alpha) is very lucky to have armin76 taking good care of the images, not all of them have somebody like him (who seems to have 36h-days and never sleeping). And if we drop support for the ISO on amd64/x86, fewer people will probably care about it, putting more strain on the already thinly-spread arch teams to fix stuff and track upstream package changes. Recommending SRCD as an alternative sounds fine by me, especially for the sheer volume of possible hardware combinations in amd64-land. But we should still think of our own ISOs as something supported on all arches we want to offer. Regards, Tobias Regards, Jorge
Re: [gentoo-dev] New install isos needed
On Sat, 23 Mar 2013, Pacho Ramos wrote: Today I tried to boot latest install ISO (from January) and hit this bug: https://bugs.gentoo.org/show_bug.cgi?id=455924 This breaks a lot of hardware requiring firmwares (like some wireless drivers) Could a new ISO set be released? I'm working on it. The bug itself was fixed on catalyst some weeks ago (I still need to do a release with it, but our official box is using catalyst- and has the fix). The 2 main issues with the stages and isos for the past 6 months have been developer time (I'm the one doing that work and haven't had as much free time) and the hardware hosting the official build box. The new buildbox has had a few hardware issues that have caused it to reboot while running the catalyst jobs. We also had a few issues with the tree that caused some build failures and the main reason why everyone is so interested in the new stages / isos, the recent major blocks affecting the tree, also caused issues for catalyst. In the meantime, anyone interested in new stages / isos, are free and welcome to test the ones built on my own server (using the official specs)[1]. About the complaints regarding the packages in the minmal cds, releng's position is that it should include the bare minimum to install Gentoo. That's why we're now creating admin-cds, that use a hardened kernel / toolchain and include a few useful tools (still no X, though)[2]. [1] - http://www.jmbsvicetto.name/releases/auto/ [2] - https://bugs.gentoo.org/show_bug.cgi?id=352152 Thanks Regards, Jorge Manuel B. S. Vicetto PS - I still haven't fixed my Gentoo email setup, so I wasn't following this thread until someone hinted about it.
Re: [gentoo-dev] News item 2: updates to catalyst
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This news item was committed. On 06-09-2012 03:55, Jorge Manuel B. S. Vicetto wrote: Hi. Following the July 24th thread about changing the default location of make.conf and make.profile in the new stages, I propose to commit 2 news items in 2 or 3 days. The first one (previous email) was directed to all users and informs about the change and what to do. The second one (this one) is directed to catalyst users. This news item should be presented to all users running a version of catalyst prior to 2.0.11. Does anyone have any comments about this news item? Title: Catalyst updates Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org Content-Type: text/plain Posted: 2012-09-08 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-util/catalyst-2.0.11 Starting with catalyst 2.0.10.1, make.conf and make.profile will be moved from /etc to /etc/portage. This is a change in the installation defaults and may impact anyone using custom / automated methods to do Gentoo installations. If you use catalyst, be sure to check if you need to update your installation method(s). The 2.0.11 version finally provides support for using xz snapshots. Catalyst nows prefers xz over bz2 snapshots. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQTPhUAAoJEC8ZTXQF1qEP21cP/2XO+2p461BwaVMMLmbYez84 KFfUvQqEyvNUy/rc+qjdrZUom8JI32GfDrOr+/AVNEOAa53Xspa8oIDhtfM7hiP1 Z/xX8aS7wnfNjeoS7CjQLvFEUgqF6GfVkDn87JHAiwGHPJ59pyGKnARRxW9p0KYh 8cWP7iZ0HAQYd1MvUzPOVp78Cxk+emVTSW8Wzj1s+MEuYhGK361lC2fkCBj9oMEy C09gp8zgxY236+UBUHo/JgiMFkBenLLM2OAAJgaKzTJjjRLTidDijHnOz4P9Quqv iL0nt6ZobCCTmsErnNEo4xp3s19middh4DsODclXtnAOUJuXv4FlblM8HJkIeEkc ufzSVKNkDHBAoxJi0rM6km2dCxwa0S0a2vb8gwTCmwlx2EZfg1Qmn96leBJ+Zt+V 1QJ5zuW/MxQSZyyOUdNSfN1rpOOhTWntS5qyGGbWkIB6RghtsEPjV673M8Ec6sz+ tLwCmCVoFnoKeF5t/284CFH4LiU9wU8GM/RBlpoko/wkxeYk+qohb9hVtyx/aAgI Q/zcAQQM8fqbKS59hSa0k4qjdcm8RncGFpJaM1GgSw+tNV4wXU7r1JxSMmNipI6i LblSfMjKph0T8VsqQPeNba6gASRy1rjR0ks5tG6puUyxpKANJYjv3/IJkNX07TR4 sh4y8bwjxGY8be22+1eu =EZvU -END PGP SIGNATURE-
Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This news item was committed. On 06-09-2012 03:52, Jorge Manuel B. S. Vicetto wrote: Hi. Following the July 24th thread about changing the default location of make.conf and make.profile in the new stages, I propose to commit 2 news items in 2 or 3 days. The first one (this one) is directed to all users and informs about the change and what to do. The second one (next email) will be directed to catalyst users. This news item should be presented to as many users as possible. Following Fabian's request in the previous thread, I'm trying to restrict it to default/linux profiles only. I don't know if it's possible to filter with default/linux/*, if there are other alternatives or if we will have to list *all* relevant profiles (the latter case is not appealing). Does anyone have any comments about this news item? Title: make.conf and make.profile move to /etc/portage Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org Content-Type: text/plain Posted: 2012-09-08 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/portage Display-If-Profile: default/linux/* Starting next week, new stages will have make.conf and make.profile moved from /etc to /etc/portage. This is a change in the installation defaults, that will only affect new installs so it doesn't affect current systems. Current users don't need to do anything. But if you want to follow the gfepreferred location, you may want to take the chance to move the files in your system(s) to the new location. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQTPhrAAoJEC8ZTXQF1qEP+0wQAKuVRvE1ZnaDLIKYasxexsGL RI2NhvBayW+N8Al1cwtpKO1sMKu2bbC1mflyB5uTFekExUZ+nQ6+ILywJzyh7VQ4 B+NglgInSkssJ5quEqE8C6sgoMTEw7OhLcTcc2BOP5TOP73PxhtqbeorBSae9gN+ ubsqpRcTpV7EHKJAd1lyEOEHuSYu4gjed1FNTWINPLkvhTSOpgZmRXhtYV0nrSbb reDA0V5FIBG+2Q0LmVGqyHnXLGbM/Eq8ZKrYS+mts/gNOe4tb9VJsx0byRBN4RXS +q3PGvV+liMnw/tlrvAny118zgxluzjsVW5MRVODmmm4DQVR073b2CGUkwSu01Lb G3ImRrjsD0O6nX2/Lzs50VFN5OSh6k2l9yd3UIKmLzDkqclAPvqckafnRlpDgSZV qcZbbvGEFbS3I1wMaBbdcTT8K1S94f+KW+E1d+ROKU/vhUvUJ3ZCY0MypKqtHnrC 5xLszZ6Xwf4t0UmaS4HlDtklhzYQTvPp3k4pKMLjW6Q9wcG4aCSE8/PCrXjPc0oW qsaMS/rIen6GzIy/os2whZwyytpRWPlAbvbPo9mSUeqq9n2JyowQF35fp6Xy5Clp A+9cVxWnDTOjv7BLMGxZx2HX1xdcyFCnfEKYD23XfJG5LhHQ1YaQfRPoL+DdCScO 0ctTiZYTz8pokhoIrBu0 =I8II -END PGP SIGNATURE-
Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the second draft for this news item. On 06-09-2012 03:52, Jorge Manuel B. S. Vicetto wrote: Hi. Following the July 24th thread about changing the default location of make.conf and make.profile in the new stages, I propose to commit 2 news items in 2 or 3 days. The first one (this one) is directed to all users and informs about the change and what to do. The second one (next email) will be directed to catalyst users. This news item should be presented to as many users as possible. Following Fabian's request in the previous thread, I'm trying to restrict it to default/linux profiles only. I don't know if it's possible to filter with default/linux/*, if there are other alternatives or if we will have to list *all* relevant profiles (the latter case is not appealing). Does anyone have any comments about this news item? Title: make.conf and make.profile move Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org Content-Type: text/plain Posted: 2012-09-08 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/portage Display-If-Keyword: alpha Display-If-Keyword: amd64 Display-If-Keyword: arm Display-If-Keyword: hppa Display-If-Keyword: ia64 Display-If-Keyword: m68k Display-If-Keyword: mips Display-If-Keyword: ppc Display-If-Keyword: ppc64 Display-If-Keyword: s390 Display-If-Keyword: sh Display-If-Keyword: sparc Display-If-Keyword: x86 Starting next week, new stages will have make.conf and make.profile moved from /etc to /etc/portage. This is a change in the installation defaults, that will only affect new installs so it doesn't affect current systems. Current users don't need to do anything. But if you want to follow the preferred location, you may want to take the chance to move the files in your system(s) to the new location. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQS4jTAAoJEC8ZTXQF1qEP9rkP/iaaHIZ43sBXim1Eb8lW4u/U E4Us9pzrdCqTiPdHZWzGpdsaUgJdFEVcF/6S+TMByJV5WZM17vcy0wI/9Fm92UKH /stZvOlECnCkCoASxSSzyjyfHOwio1G5A6oLWtfhTS8Mbbf28bny71iCgQN+MjDO 2asva5e04tEbe2yd/cQZfObf6npCmSb+tg94N8+dAu42uwtjZ1Zp1TcUZ0mP/PY9 2vs8joOOxvpnv5Azf8oz4p/g5dxWXVbGjZeJV7sBZKGbu2wpmeQsjYX3suE8r5gz d3ZMRFkGwYEmVWVXp4qNS36sik6h8++PsWPS+RJy/6W7IfWh21DHXVYrmEvPAxOU gSqJXPKwHu9a5DsVNf2fbgnDhOirx7gSgQBl2SwPZdpQ6Ts60h/Epn6oeDs8AXF0 B4MXQJUZV8AzXR7GQXnYDAIO+5FMyAPXJdxQ9MpoCP/ENrd+RBETiLDc6C7zfino DDxB2tUtA5pFx4scpJaOE2ZAD3vVSBG7cravSTHgD3xEnyf9elblAIzaE3ADYzgL 5UkR4kEcnzGuSOYUR0uZqrp7Xyz+Pb661bFbindzCpmqEaoOUQfkdBum+SD7eG8y h7XDzVBK0aNqsZ3STTfRn7OtJ5en7tUQJbznm69+DXz24WVk/r2zNr7NyWoNu/+J 0RKE6fzAHjTC6laxHJf5 =o5GT -END PGP SIGNATURE-
[gentoo-dev] News item 1: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. Following the July 24th thread about changing the default location of make.conf and make.profile in the new stages, I propose to commit 2 news items in 2 or 3 days. The first one (this one) is directed to all users and informs about the change and what to do. The second one (next email) will be directed to catalyst users. This news item should be presented to as many users as possible. Following Fabian's request in the previous thread, I'm trying to restrict it to default/linux profiles only. I don't know if it's possible to filter with default/linux/*, if there are other alternatives or if we will have to list *all* relevant profiles (the latter case is not appealing). Does anyone have any comments about this news item? Title: make.conf and make.profile move to /etc/portage Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org Content-Type: text/plain Posted: 2012-09-08 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/portage Display-If-Profile: default/linux/* Starting next week, new stages will have make.conf and make.profile moved from /etc to /etc/portage. This is a change in the installation defaults, that will only affect new installs so it doesn't affect current systems. Current users don't need to do anything. But if you want to follow the gfepreferred location, you may want to take the chance to move the files in your system(s) to the new location. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQSB4ZAAoJEC8ZTXQF1qEPBNUP/iuZlVtdKm0pJnV2w43e2djm U5eepkslMTITH66OuxWOGDaI5Qam7L4RVVC6nRs7WZi09ea9u8QD8/dF1S5gzTfK F7hmcR5ynxm1gqePEZT3Ooj8fE+BRiZGVrYtaxMC6+gtUiqnsl68IS5aJZ/lfnWI B9vPv5a9dx/4dPv9FUl2rbo8/+a/O+aiNqNOiZJ+nmdEvdZjBZy8nXzkeHQTZkX4 7pxFFFDGi/e2FzKiZZfNeeY6LKm1c1kYQs92KP3h+kne4zfpbYxFub9QIlWSH3oe GS6kPCdeg+waNVugsjBNKEw5Z5QjyURwFB9oVDyWpa5kNzKYCNEK4swDNs8vO+W9 4TOVYrmTweyRaZPceCG2GG9PHcRxnmO2pMalFdvbRCAi4BlEH1cbbG/89r6zAU62 0rhykkuIbpjMx9kwOvC0FSdlzbQxmEWmWfcwETlWUZgdKDbjt1wzlRL4zbGoy+Aa dseBj6s6aHrpQab5WPa+79dIZ2yiO+PJED1IzseFGjpjUn6hOmMMS7A3KRclX3yk 5Ugl+x+FNYB9+czf6rIi/2f9gwy2tIGJT343XJkkeVzHyjTmWn7OvZVfPzzhyhqW pjIPA+ZaApfRs6lV70fCWaSb9slzunUwG7kTYw8lxnA5WKkiNWAxbQbvSkCMWk9P uSvllBQwzbiKtAi3eBWl =m+Ij -END PGP SIGNATURE-
[gentoo-dev] News item 2: updates to catalyst
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. Following the July 24th thread about changing the default location of make.conf and make.profile in the new stages, I propose to commit 2 news items in 2 or 3 days. The first one (previous email) was directed to all users and informs about the change and what to do. The second one (this one) is directed to catalyst users. This news item should be presented to all users running a version of catalyst prior to 2.0.11. Does anyone have any comments about this news item? Title: Catalyst updates Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org Content-Type: text/plain Posted: 2012-09-08 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-util/catalyst-2.0.11 Starting with catalyst 2.0.10.1, make.conf and make.profile will be moved from /etc to /etc/portage. This is a change in the installation defaults and may impact anyone using custom / automated methods to do Gentoo installations. If you use catalyst, be sure to check if you need to update your installation method(s). The 2.0.11 version finally provides support for using xz snapshots. Catalyst nows prefers xz over bz2 snapshots. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQSB69AAoJEC8ZTXQF1qEPLFUP/02UmDmifCQbWnG+iOPzXTev pmM108wVpgG5c1Vf2q//Ik20X3WyX+iPIdPWCMs+u6ReebCuQE4hpq0jCwg21QrV VqXA2Qh6Y/p3D4mpspNHbqU73LjzFbJQdbvFqp/1bkmgXxzpSyurkGn+ZOSzh3XG EtxxIENsJpo/4PlsECETzx/KazwDC70s+627KG712tmpV5zWG8s56d9sUpB4ivDz qNzI12cojXldUiVZcNVj+FVLvQEingTyJYQmM24WGxcGAtsY78VRg02zV8/1QUgJ oAdieTf0HJNkUCRO6TY25IsUWQ3xtavt/O35QAmgwIOcConDbPsCKS2qOImLGC+q Ha23HVkrXZ6XveYm7gdlLU0IWsn/CkIwoVEP0XDJHiU1mg5U/+nQkVzYnOYtwyvr vsAODOkF6verECG7OW1BlY2h042fibgQOf7kqinEKcm3ZAkCIocWMZEgUyEdyw4L 1xzAYrTmVRLGy45D+e/24nQWiEi8WIK8cVIaLFS59wIc75C3Fjr6xND1JB29eB6x 3a0WGUm8m5l9UbYkRjAYhUxWI/BUi4j0yP+MUmuaenhvx4mYywhmqL7s0VTDXD7L q4RC46F2qHVpYagKgFiQ1LyOl1Kvak9bNVmlE1qiWdcQtM2uMkuDrfCUCwVqCL13 HYvpnt5D+K1nsY1t1Zm3 =O9jf -END PGP SIGNATURE-
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31-08-2012 20:46, Ciaran McCreesh wrote: snip Also, we're getting rather a lot of *DEPEND variables here... If we're making people make major changes to their deps, which for HDEPEND we definitely would be, then the it's expensive since people would have to redo their deps argument against a combined DEPENDENCIES variable goes out of the window, so we should rethink that too. I have to agree with Ciaran, instead of multiplying DEPEND variables, it's probably time we move to a single DEPENDENCIES variable. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQRpeVAAoJEC8ZTXQF1qEP/UgQALd+7oqAODQA5bXdyqV+Qix+ mDN66c/6UO4VS2dyhfCEyA3osJzFS4u6mIuR7uFpXoKXGGs+MYdl7EG9C0k48zUu YLCDD56oyk6wACxBk7EHWVql1rvFoFemMUw5YUVq71w3FU9hrpBi/DXKsoAlCRyw 4B2p6t8p6efll3vzbcz7M0LZseiox4GBTFCrtxR5zwgvx3b0gKvgU1Pv+AT3SBQK J3IOxb09GSLCJKo56+iDHGuS5RwBBmdWP9l3+AdbjR2LoQ05f8o8a7/geg1Qqg/Z gVVSo4WDN2kIDJOvCBuXuo95a0KKFt/zUgfwjsqe02fRu2mDiWAju4L6vk2WE316 4yfMULI6HrVUk3ra+O4ZW7eoOuRvPVDpr4vyCVetFe4bx+zmlo/CmzOg/2teMyoc rlMvOigR/4D+wxX7mbw/0fwZ5tVUbZ2pkdEhKetlpDe+xbWY0LhaczKdizwF7BrT d+BeazPGWBP/muY0s3VDu3KV/3TRS0tME8GRsDevA9nCfA2plU0ZmmZnTB69tLc+ /dgdexHhc3IuA5eMObwOfSK6r9Jozlrv09TDvb6kHXm+0kqhV/W/aaS1qT4Bjlxd psMjf9lSJHLcXuhtOz9OW4qmhp4BGCA8Rgeoq25Yw8E2eH0abvDbHR5U7u1hEpnQ j6rJ0fZ27tfbMecd5i8b =Zv/I -END PGP SIGNATURE-
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25-07-2012 13:29, Michael Mol wrote: On Wed, Jul 25, 2012 at 9:25 AM, Aaron W. Swenson titanof...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/24/2012 04:19 PM, Michael Mol wrote: Another user opinion...it would be a significant improvement to the stage images and live discs to include the latest copy of the handbook, so that a network connection isn't required to access it. But that's probably a subject for a different thread. And I think that's at least three topics, now, this thread has touched on. The handbook has always been included. There may be a discrepancy between the online version and the version included with the disc, but that's because the online version is always current where the stages can be a week or so behind. I've never spotted it. Good to know. :) AFAIK, the install-cd never provided the handbook. It used to be manually added to the live-cd. About adding it to the minimal-cd, we don't want to add manual steps to the automated weekly builds for an installation process that already requires network access - the GRP CD stopped being built a long time ago. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEAJVAAoJEC8ZTXQF1qEPGZUP+wdUw8I52RPhI/jIw0wcC8xB 7a0xAkeUB6RZNTgeZTs8YeImHmTMGJzpFyFJ1lQx6JXw51TmdXDiiEOm02BOqmwV fVgVwUJ52CjBoDkU+S9Jc9/dH611uolBm3nkcPdhW4FY6gaLJBonqBkRQX1G4L9a wzGICTihHl/fEj4MwwJB98GdnGuuEGHsjwWDGmz4Os1hT1Dk3oaky9lA3nRxxP0+ Dj9lY4idlLMCfhA3IohBxOfV7weUHD4m0CjExQ0ITWkJ6EYRgtQM30sxmAOcpuz+ VeoiRMoylMr3QIh7rl1heyAvyZ+pzMOtZbbDLgpwRKGbEDDSDA/o7L8ls36ildKD AileB4PsmPONCFLOi4jxWfMMRzxKDBkyGAuAoz5Sz+2Ws1E7QVvsj0GrpBp0uddd 8G401zX/Obz9728YVkGEaQhflx7SZMAgVhDm9QdS40ngg2gQvTgDZmwvPPtRopNy Idr14GnTa81hPrplFQ32HpsD4UlWpfClV0kcsbQPxJ/kTgRgw6asX9v3qiZ0JJ8M Y4ws7+CrD1NEApaWfupzJvehIGJLKVDHypcrwrJYu8mLeeqvi8IhAh4T2SeJZVoj r2ass0DeFCyXQfmumH8UAW5jrs3O2679Kamk0hqOB17XuMyGs+ycMqhWs2IKBzjO eAZVtBESNWmvinbchFKw =pqnW -END PGP SIGNATURE-
Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24-07-2012 00:07, Jorge Manuel B. S. Vicetto wrote: Hi. I propose to commit this news item in 2 or 3 days. Does anyone have any comments about it? The idea is to show this news item on all Gentoo systems. Is that even possible / desirable? I've talked with both the PR and Docs team before about this change. I'll try to help the docs team updating the handbook. Taking into account the input in this thread, I've updated the proposed news item. Title: Changes on new stages Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org Content-Type: text/plain Posted: 2012-07-27 Revision: 1 News-Item-Format: 1.0 Starting with catalyst 2.0.10, make.conf and make.profile will be moved from /etc to /etc/portage. This is a change in the installation defaults and since Portage will prefer make.conf under /etc/portage over /etc, this is an heads-up for anyone doing new installs. If you have a custom or automated method to install Gentoo, be sure to check if its affected by this change. Releng build boxes will be updated to this catalyst version during the next few days. So I expect stages built after July 30th to have make.conf and make.profile on /etc/portage. Current users don't need to do anything. But if you want to follow the preferred location, you may want to take the chance to move the files in your system(s) to the new location. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQDn7hAAoJEC8ZTXQF1qEPg9oQANUKtzsAXZggYYKZ9aEAthWa Eeftr/qdyjycHl7/Ov5ztgkuJhBcDvvpofcY1ynuxbkXxxmEUemrsbzSM1mgQ58A olieDncD83mo2p8HFZ4peN9H/OsyoeZaumj6gVm5ZjHdj7FO1bWvpeTNmfoARhV8 AxjTarZTJp9Gp7PTKyeLFQVS5j/RAv3S3/RgnrAVzBV43eFlx0CZTqpY2S9Lg9DO LnrIMoaT7gNb39x0xUnIpdkCOJqp8Oqif/DlE9uga6A+l95VEIoCWShA48fRGlAm 5VqMVrhLhw9YbNDPewOA0/+eYcu5IFal9+AwYO6gtqJsWG11cR5RT8zdoJ4JkwLZ Sh1v0B/9op6kNHuTvQBKcHUjCZ4p6cEHPuPJpJAiDYK5NS7CXsXmL/vUFlNqlNPl m4I9ktJySTDtqyOlpx27a74tYsfXjRiUxnm7DZAXnV77MxppKik5Y73prVVtt6zZ qenNwjo4uDUB7UV/wu9IYv/1KR8UYGTEi6Zr5JC7cAJVZtrZULZLuN4tVLTfDDXI DrPx+byA+Rmq0rVA1NJpZqnUlUfjgSMLaiVtVYEjGpQAYnPK5gwimBqeKQ7A3FWx wkfhXkZt4lNU770lsciym17qPpQdCVi42PNz5Pt094z9oyy/TwT9X7oQ+1EBc+0+ W8zzrDtrn1dHODWsRerh =+95k -END PGP SIGNATURE-
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24-07-2012 08:48, Sven Vermeulen wrote: On Tue, Jul 24, 2012 at 12:07:59AM +, Jorge Manuel B. S. Vicetto wrote: I've talked with both the PR and Docs team before about this change. I'll try to help the docs team updating the handbook. Speaking of which, will this also start the use of the SHA512 WHIRLPOOL checksums? We've had a bug open for it for a while (bug #386475) but the digests still don't show this. If it is simultaneously, we'll need to fix that as well. I had forgotten to update the catalyst config files in poseidon (amd64 / x86 build box). I've done that now. Can current users also already use the /etc/portage location? If so, I can already update the docs now (since I'll need to describe both of the locations for a while anyhow). Yes, current installs can use the new location. Wkr, Sven Vermeulen - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQDn8xAAoJEC8ZTXQF1qEP1GIQAIqq2HjGSRufWeze9DaP5LO4 oehrABeBYJxeAaFlnJ7N4yrgQTuqhimwTt0fSV5ZzdkQobSam6q4VypPxXlmw/L4 O3SN1iWaidpAeIC9Ff2M0of1mlET2WE7BJeCnBn2Lq3ihNTjb6ctt88qp2/RBZcG WKx58w+MwDGX3gXvwr+Tsk9yiQqsELjGWZv0q4ECbBfhoAhWThps3B+K3/VYsoYa bN/v+hYJLVQgTWJhHUQDhlTBWM5GkEo1ZVq9cVXb5pkkfuFwzC+BRYfxGQ7HXG5o Ypwu2XQUqECh4riI49dGloN7tjScPJDKOwQZCxkWLPKmfS2IDgmz9PVESYqd+R+Y FA0KFne/L2c46TXBY/nhPN0Pbz4GJXbCeOcGVQmcOohQRkRlLeOL9Pco4/yXWWQS StQvDqAQRotAra58MRcfgMnkf9ttgbUWlYHt+QttE+Csf/RdIT3LqbziA6OoEikz DrQZCsyU8Frc1SE3fYKmjkjlHfSg1Pm7lPX0irV9D3r0RZuOMkeyK4T7ZxJPkRPA shE4GHQpwwhAHspnlMWM+f39C5MtdisbUezR2VmgWuz1LAZpLGZJmWux/s0RPebR AZSTWaiYhsocJAPkgNodbSKP9FPQR6Kz7aSAF5s30WyT3Ezs19Rk9a5fCUKYetyK yw5jlj0yQfZw9yWjrotS =FTY+ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24-07-2012 06:54, Fabian Groffen wrote: On 23-07-2012 22:10:08 -0400, Rich Freeman wrote: On Mon, Jul 23, 2012 at 9:58 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: This is just a heads-up for Gentoo users that got used to find make.conf and make.profile under /etc in stages, that these files will stop being there and will instead be under /etc/portage. So we are changing the defaults. I'd spell that out then - just say that no action is required for existing installations, but be aware of the new location on new installs, or feel free to move them if you want. I still don't see why you'd bother all existing users with that info. Just blog, or (better) write a nice email to -announce, and update the install docs. The point of bugging all users was to minimize the risk of a user not being aware of the change. If the general consensus is that this should not be sent as news item (GLEP42), I'll drop itl Also, can you exclude all Prefix profiles for this news item if you insist on pushing it out? I don't know the specific methods to filter news items, so if you or others can help with that, I'd appreciate. If anyone has particular suggestions about who should see this news item, including the filter of how to achieve that, please let me know. Fabian - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQDn/7AAoJEC8ZTXQF1qEP0isP/3vY3d4IyGbBBiopV8LJ1fGq KzgzTJAa02lEEumSK5eCnybm84uPhUGcUA/sUrpLKCcJqA3JraXnUNGYjjQnFyXf 1bDKWmn6OLcz/1ziQ+0Je4EsfoHbMoSyMr7YUA5o7j2Sj7ZPB4crCqybEKSDsdyi y+g+xDtJqIgS46Xjs9G9T4dYwrN5oXfr6TNFLzBsh3ZJ5tn9M3AKU48ojwQJgRU5 x8vlfbxOEpK2k2HhAPdGgQdy3V7tVUuqVDcLfDCtvwMG18dffF/35i2XpeHETe5g qmctkp8dhIIIS/717t1m+g5lRdxVjDWADFtIAqlWXzES0phnk21nrGpNqJYbKu+2 pdaeDYyG4qQ18t5bLvFzqGCl93DXl6PQOUiM7GrbausmY8yKjfabW3pRtC5nt1RV C75guLowBfF7kUmDQz8cwIBSL93g212bVBIXyq2KLqw2zaT75815O4GNCmGLD0g9 YkSU0hTLe5Y4veJ5XDDzHRaHMdZ71/+VdShcC55rdnKw3N+A6zd/g9wLbtmi79pE yjFM8ZaZz4P8GxPMoQBWEMGwBj7TNw9p7led82PGbxmAmUnDDDsXLNEqoepvJEzb SIUd+g6rxS0KpcgL3ocaDnGmNorOT53OPi5Uho86ulkp8khVrOgcA60fagRPzn+6 2J9uD6CwFTv0O5QsVAfO =8cWY -END PGP SIGNATURE-
Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24-07-2012 09:29, Maxim Kammerer wrote: On Tue, Jul 24, 2012 at 3:07 AM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: I propose to commit this news item in 2 or 3 days. Does anyone have any comments about it? Several comments: 1. Maybe note that /etc/portage/make.conf takes precedence over /etc/make.conf? 2. New make.conf location (although supported) is not mentioned in portage(5) man page for currently stable sys-apps/portage (2.1.10.65). 3. This news item is really useful, since the change has a potential to break automated builds. 4. Are the other files / links in /etc also moving? # ls -ld /etc/make.* -rw-r--r-- 1 root root 3554 Jul 24 09:20 /etc/make.conf -rw-r--r-- 1 root root 421 Jul 3 22:03 /etc/make.conf.catalyst lrwxrwxrwx 1 root root 42 Jul 12 18:15 /etc/make.profile - ../usr/portage/profiles/hardened/linux/x86 This is what we're moving with catalyst to /etc/portage lrwxrwxrwx 1 root root 40 Jul 20 00:26 /etc/make.globals - ../usr/share/portage/config/make.globals This symlink is installed by Portage, so it's outside catalyst control. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQDoGxAAoJEC8ZTXQF1qEPE84QAIxuDcNdJdEU2f5d8LRzn8c7 kL5GAyh7+MgnldOWZZEIi3SWdbo6gsBZASJmU7BVoe/bcKqACQt00J2LPeEsgYa4 jmQGy61wH1kqA+P5peJrRNdSv9ULcH615UNj1ggzL5nRNahgGDMdl8O0zhg7NA+K soZurXrAgkgOYR0WOJ+6Ps8oU1y6KozmXGr71wsFpIAeLVE8t67A+AUxagAXCw1s wDvif/w7x5EA2a4GeJs2iPBNehwMLgFRfxtO5GlN7YucHWINrf9xZcNvFJyceUcQ cuiBcVj4fgo9ckaVOUrFqL/V4QzkgyE/v2c2qaBaz0+qSYllk8fctdkTBWx5LfwO pLGDtOXWOATnOXIwtiyWLEQ4fhC9AaBnZyuJvDAu7RYOP2e/qhNSkOiHKVU078Dn xpGe9WhATfLj53Q1ybVK0EYwZ33AugN0KQ3XMA7WN9PFjpoZaPHLZYAA78oRytej ZVrCQQ2d6u3V4cpM199swL4YwHiuOMQAIN/N3RpzRmJFvJ51JLN47tXJt7g/++7u DAgitWoLHzK0tknZVlxKFCenVIzY95P9tmmWx65CkBmeWanNephJLY/5fk2NwDsm 0zQa7fF+kSDFSGjv0pqYt9djbd2RAsYlCqnPfepovFuWHcmJHXJMa1yzLuCWHdok SJh4uA+4JLSiTmzNyPxT =EF2+ -END PGP SIGNATURE-
[gentoo-dev] news item: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I propose to commit this news item in 2 or 3 days. Does anyone have any comments about it? The idea is to show this news item on all Gentoo systems. Is that even possible / desirable? I've talked with both the PR and Docs team before about this change. I'll try to help the docs team updating the handbook. Title: Changes on new stages Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org Content-Type: text/plain Posted: 2012-07-27 Revision: 1 News-Item-Format: 1.0 Starting with catalyst 2.0.10, make.conf and make.profile will be moved from /etc to /etc/postfix. Releng build boxes will be updated to this catalyst version during the next few days. So I expect stages built after July 30th to have make.conf and make.profile on /etc/portage. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQDedfAAoJEC8ZTXQF1qEP0xwQAJaX1KgYTVDpyfO+A1loKuz2 nY/lTPHs5w9vONaBm04dxt8zsuW84dhhOOxwWvOwWzV4DXpsPmiQpX/3QuNY86Nz B7npuvemDNh+tOvMhuzZeXKZhlAoFDG/onIJegcQnwLfk1urSfGnUQqXNdInkvlP nWMebJTb7dI9R06W+hQPKvviW+EeuUfuA3DmfPKv9j1G2iUJCcXyi2aDWN5RNZlJ AnoSI8xllIWeqh8G5ushwVLqtlA9kmBx0HV7EotCk+A/z0ITrtT1AEZvMrGgt9Kf jSzVTMVVR9/nYn3/NvreahGak+ztKCa/eRuARm5bTjXBR8IohNL/mhsydH9YSxjY h/RMb7ESXyGfSwfCgAosb9EaM6TO3HPHfX7KmKJTnrgyA9vn3jckgNcCyTPyJome OqZenKYo+6StnDbRq7Vmmo/woZ4SAALIhtxEbs/kP0Hdi8X4HYQc9OxBssDANHdR L85ILLzBMhcFfPsxIxM3R3GGae7MsfnS/cymOluHu8J+KqsLTgYXnPJoJ8RDk4Em 4D5kIXFVbld92begBA8VecmjE+s7sNCgmRSCZzyovikP9vevrmVvgsFsW6evUDJu KOqmGrF4JNFU0l/nr/qs5wz1YDA/vAurcvNELxDd1whWtB0I7fdzbuchIYkxtAuN lMn8FElQKkT68B+5HZeE =dx+o -END PGP SIGNATURE-
Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24-07-2012 00:19, Diego Elio Pettenò wrote: Il 23/07/2012 17:07, Jorge Manuel B. S. Vicetto ha scritto: from /etc to /etc/postfix. Are you really sure? I don't think Portage looks for it there ... ;) Thanks Diego for catching the typo. It's obviously /etc/portage and not /etc/postfix. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQDeqrAAoJEC8ZTXQF1qEPq8oQAJ14P7XIvQtk04sNYpufT8H/ C9iPyo7iduDT/z8Uj8OlFu/4GPsUs+bjege4coOY0XOU1L6lolAR/1IsfanmufNc LrkmqR6nmVbNhs/WsNnaJ1mXY6ietfkk1FWGZcLq9KJsIPwFz3hAnbghu0Kupefs SpiFrwwVmHH2RV5KXJ+IL8Y6m9v6vI7C4qjkiuYsomq+i89FOvhwowTqxLqfR9WH Sp8cM3hV67lTjCjT2lPqlbSp3vkVWdWP58C+Tn/VRSQjNBYJ8Gf1PmySzhDJruom WO/SDfWNo1+1QTbrImkrpFMwDGK3PQSlyMAPUXrlbTPXB5uHs8JATb+2OESgOBIN 1ZI8ykiCLnD790ULmEkLKvhxqMrw7PmHwjQQIUp+bLcHYjIugk6sk5z9pGji516g jQH0cvRKe53R7hnj4GgD0DRK3hqUBOr5AmIbaDKLSfaEuH/mJVJBKzejMIv7bHzY s/rXWvWrZQhke2qciljL6u7OzeRK6z316zWud4doNgbpUbocpgFLGyqCZPCOazPf 6LiFJd2VM9hqSkzJbVY3nQlNuXnIPexhhuNOCTXwM71TpTSIeKsnIVthvm8dljm5 h9MJEwgqGhzfyzCOsvCtrTTfbLAax4kA1DR0DrtId6bWh8b3VGDwkzREVo5rKaxc c3n/ygY3YlfhlYSwJUXg =0dTE -END PGP SIGNATURE-
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24-07-2012 01:33, Rich Freeman wrote: On Mon, Jul 23, 2012 at 8:07 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: I propose to commit this news item in 2 or 3 days. Does anyone have any comments about it? What action if any do you want Gentoo users to take. If I read that news item the first question I'd have is where SHOULD I keep those files? Should I leave them alone? Should I move them? Will anything bad happen either way? If the answer is that we're changing the defaults but plan to support the old way for a very long time, then spell that out. Otherwise you'll get a million people asking about it. This is just a heads-up for Gentoo users that got used to find make.conf and make.profile under /etc in stages, that these files will stop being there and will instead be under /etc/portage. So we are changing the defaults. About supporting the old way, that is beyond Releng and up to Portage and maintainers of portage tools. I was told at least Portage has no plan to drop support for /etc in the foreseeable future. Rich - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQDgFYAAoJEC8ZTXQF1qEPzdwP/16ArdOg1k+2vX1xAbwDSnMs Bjw7XIn9EsPmk1hT5FKZTUrwgeihXudMtHHCMKXexH4Ena9F9hu5NNblV2Aklv4u zPQVc6GOvf3oWUgzPGDC/2AFb701aIKzNHLPaiWVIX0f8USly4rho+yulg0WYjRG pHXH9c2szLsRgGOVcgxLmwMeqAFl2D2iywp7ASLPBPjMCqJDaGJXhHgUr1EvaoET sLwtyfeW0pvSiPZkyHs2+dBPvRnup2fsv1VZwvpBFNeopItCg76rTEhxDouH8zN/ xZz37mw4+6et2+9L0u1R8oQsDmEyw7XPQ8Q1JuibHsim0K/bdhxoINVJXLAE425T aaJNUx5jL3taY12fS1mcIjfIpFZwqTf8CUUjkIY+OOEYNltjlXCK6JyWbj0a7wEN BCneLC21aKWvdR15HuyK7CP//8qhPkAtpt9QwbT+qNryI1hX80IMXnl3Ey6hIG88 aD14U/AyzK8OCZBpKpYt8RKMVHyOTrpqxfHTPJhF2rkn6lH1aT781k0a70Njc/uK 0wRXrb5jwXPCehCXF4LVdNfPqB5AmAg+JkRbBkwHRu96U2ioncCd1w+h5NTlnNLL NvVoDiXKO+5ouH8qrSzf5Y28CVZa8r94VpoQOgND3N7DM5GOin/ok3S2k1PhbELd k6dHPEF4bJcCsUg+PblX =Bjnh -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-07-2012 21:09, Michał Górny wrote: On Wed, 18 Jul 2012 23:03:14 +0200 Peter Stuge pe...@stuge.se wrote: William Hubbs wrote: let's move all of the discussion of this to the bug if possible so that it is all in one place. That's fine and probably good. Note that you were the one inviting email discussion about the change. I guess you wanted rather to focus on the question if breaking compatibility was cool or not. Anything web is *way* too inconvenient for me to participate without strong interest. That may be a good thing. Anyway I've mentally abandoned init script including openrc long ago. :) systemd is the future, and truly a leap ahead for systems world wide. No, it's not. But it's a step ahead. It's obvious that to its supporters systemd is fantastic. It's also obvious that to everyone else it's probably far from that. Let's please try to leave systemd off this ml for some days - I for one am getting tired of all the systemd related emails in this ml. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQB2O/AAoJEC8ZTXQF1qEPfPsP/R5+BIZVP7qKQn5MSsmCspnC vDPSf3CWP1OjQ6D1yeaDKWoPCSBqYg308DIgFWscR0URruC/Jd+Vdkl8B1ZztTWv YjuJp9tiIsrhb+gAg84tbxy5YE5I+xFwAH6pfhVb5xWX9DOwNMK2KW8C41L2GArP jPK6xtxbTWdRlElpymaskhEftVVXeNe7V48QERG26d3YXpz7D1cmSpjIeJdp7evS rkpleFRQHSAVVfr95KIol3gi/8LSY5M5HqnuxHqJ4NwnOna2WccFY68dK71qi4Gs ah38h7LxWwTLsaoD83Dbmu+nOzNwA07CDA7Sf2GIhHmHbd6PoJQ4D1bGUzppry9r NvbJKmIJdut55IHNpA9QPGTWfKO116o/1caQeiIWW0j9bmPj7YaWASBLJGNkO22e OgJT6WedFj5jWYAH4hANZLZov8s/KvtKXvyiA1Sq6fkFZi7LBhcEf7OpcaQgSBHu NK/MiruF1kRELrbbp5yuh/KKwZDnZQY1gNW/PZuUAfe+/DGA7ZVzmFh8UquIalNR fuLbGqViiyd06czxlnVHvscgZZ4K1dXMT0mFF6ZpmiSEboIeoKu/H3IdiZhTCyPJ zp5w6B2MXlNkPLQQjfkPyuRkSRpbCkFxlQIN2TDWbdfJQwIVDkZ47EGyXHCN6sc6 +/IW3MuPUHS4pEoqKnJp =pGgy -END PGP SIGNATURE-
[gentoo-dev] Lastrite: compiz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My apologies for sending this twice to the gentoo-dev ml, but I forgot to CC gentoo-dev-announce. # Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org (22 Jan 2012) # Mask compiz for last-rites unless someone steps up # to maintain it. Removal in 30 days. dev-python/compizconfig-python x11-apps/ccsm x11-apps/fusion-icon x11-apps/simple-ccsm x11-libs/compiz-bcop x11-libs/compizconfig-backend-gconf x11-libs/compizconfig-backend-kconfig4 x11-libs/libcompizconfig x11-plugins/compiz-plugins-extra x11-plugins/compiz-plugins-main x11-plugins/compiz-plugins-unsupported x11-themes/emerald-themes x11-wm/compiz x11-wm/compiz-fusion x11-wm/emerald I no longer have the time nor will to work on the desktop-effects packages. In reality they've been unmaintained for quite sometime now. Unless someone steps up, there won't be any alternative to finally remove compiz from the tree. - - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPHSwrAAoJEC8ZTXQF1qEPu7sP/RpXjcPRVmH5vCIs/sdt7Op/ EC9RQ7c616q0jHhLI+Aj86OZqfZG45NtVfprW2kmQO0mtxf/YGq9+W5k4JGhkGn9 sVZkijuETq83VFzm/kHzGFGkGcshX/p5sO+Fd1LMJHfZSuRfds+5JMwx61P7y98A kn/BJwWRc1MbqLxOzte8NdwLpEtmLVom+mjOfA841nLWIfiAe5Fs8mNevOtTr1j1 GU8VX82vWT1Zy1fYT9Vd3KBQRW4yXrKZ9oNhZdwvpbzuBQ4w+TUsfezdLPix624W viyA0L5QdAiOktWL+XsUdcLZHnTG9Huzfl2zuWq8UbtP8K0YpZ2AWWV879peAs2g 4AFJthQ6ZkJr5PrRrX19eZhnPhlrVB8jGo50ZF1L5JGGGZLNFmDfxZWO2d4ZIjS9 sBFDjhUtQSX27nvq/AFhrha3XU4tdfoZGvHQD6GRb9EYjT6OJDhuN5zg09XQG0eX 69AE9shlWG1hD4JVkZbJKljMQJYC/UwToZUZ5Jh/BMD0r8AcX6Aq09FCuaJKqW6y gQUzX+NBSyQn7a7g9qIPzDive+CrES6s5m2nuY6r/3yuhoIGCLiUh+ZAQfq4R1Qd pDcMkRCoUOJUYzx9zR9eiV4wNOqqGb+iWIE0qh+4fWYB4IIrKc48VXlnMviZcaJr FMDp9WHC2BV2kwtUzbUi =2uGL -END PGP SIGNATURE-
[gentoo-dev] Lastrite: compiz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org (22 Jan 2012) # Mask compiz for last-rites unless someone steps up # to maintain it. Removal in 30 days. dev-python/compizconfig-python x11-apps/ccsm x11-apps/fusion-icon x11-apps/simple-ccsm x11-libs/compiz-bcop x11-libs/compizconfig-backend-gconf x11-libs/compizconfig-backend-kconfig4 x11-libs/libcompizconfig x11-plugins/compiz-plugins-extra x11-plugins/compiz-plugins-main x11-plugins/compiz-plugins-unsupported x11-themes/emerald-themes x11-wm/compiz x11-wm/compiz-fusion x11-wm/emerald I no longer have the time nor will to work on the desktop-effects packages. In reality they've been unmaintained for quite sometime now. Unless someone steps up, there won't be any alternative to finally remove compiz from the tree. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPHJyTAAoJEC8ZTXQF1qEPVZcP/R537EetPfQ6OwB3muPGus7i Dqm942vAS1jeK3g0UDbJDhI3lladdb3jR0MLfkD+TuLi8X6bx+ss+3xqgsjeZ6M7 5Mf/QDWxyqKCQumacTI9yXWa/FwMrJuhxjOFCusjYbxDLr6Ct4t+8lUl9RP+HBoG DKh3Z3DJvIw6VZIWZUEmCEghvYMn7wzUt3DoMGmP/BjfxvCfirkV6xMwJHfxQGzc UtQVNecgnODn3liJo/XrpGikAlNqP+tCyJCjTuE5dcV+EbNmQJhjkvphXPtfAgbn WvHZNLepbv5EGPJrWRwoeh2lpCWh5JhisxaQxH7LNSf+ID8r33Pb6j3r/J9EBj7m c11P8twv4255nl07mkF6kiNlwY6JLTF9LgX0hxPOJ+02Pw2w3ECyVeXTx0qMK5+1 Tsg7uU9JD63YmDubgv0LMyR+nYyWx+e3lBTjwNGXQZeRzOdXkSrEg5Vbj9paPfyJ ApZ9k0EzjkJ72G79aWhSKH3lLGMiX6yyEk7RRNXZwV2axa6X+L2fmXX4EMuhPCYB 2epepXUunE6B/NDoXfViU86tcNn4A7dcHgV5Qzjn7v5/6wYSwdb6pc9heydGxErC oiB1treO6n1UqWSbeQppDY4mI8wQY2cSgostClhkQw0F9a6A9lT3PfygI/20aYV7 uz+/8J53rPiap9t7mOty =PbRw -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/ghostscript-gpl: metadata.xml ChangeLog ghostscript-gpl-9.04-r4.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-11-2011 09:25, Samuli Suominen wrote: I wonder what that has to do with Fixed slotting for media-libs/tiff? Do we have a guideline or policy on using 2 spaces vs. tabs in .xml files and gentoo-x86? Just asking because I prefer 2 spaces over tabs. Sometime ago when I did a few updates to metadata.xml related to retirements, I've asked around and there was no policy on whether to use 2 spaces or tabs. Back then the GDP preferred one over the other, but that only applied to GDP documents. On 12-11-2011 11:01, justin wrote: On 11/12/11 12:56 PM, justin wrote: I wonder what that has to do with Fixed slotting for media-libs/tiff? I missread your question. This has nothing to do with slotting, but I don't think this needs an extra entry in the Changelog. Or am I wrong here? Changing style on a package or supporting files is imho something that should be left for package maintainers. If some maintainers / herds agree with the change, one should probably add a note in the commit mentioning that. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOvo3zAAoJEC8ZTXQF1qEPa5UQAJ758RZlZGw7baix3oA19kw7 Cr9nRXFFlnXAq+8yws5kNi01N8Azhug+MH7lwTJyqnJADYHl8gti15iegW5iZW0r qxpwHE5XWjCKdST65kM1F3aDtaqvRQK/gd2mmQ9dgAzLWzwiy1tfI9aYxSUq7ufR KUbEuDoyATmddoAONMQIEgokTLWewESJ+3a8q1i87Yd+O2iii/JXo0GgcnWIsROU lwiEmK0G1iCIqzELik1ceeQ8BJanpPXuX06/fSAVmWNUKkKqATFiV1Q1qrNrIR1o akkpDTKNUPFXlVUl5IjohxpJ58ybIaBsklK7v8ceFF4I8mJgwjQLmjaruFB/yHuy t6g4FaS1BiIyQ6aiHxm62LVG8UTOKtxqHjke6JobRskIm/hsaG09R2G7d4Nzs3gU uycyBbu0QkmuC7emsZZw+cb89E3/TMQavMO/QWaCHpiBXEH0II/uXsl7LR8ZpdiB FXLxZNcN9mRPX7n1Q0FKNqwJH4cm4gZRto4PwbeTQ1Ls9aX26r5eBMlFBSzcI5f1 zKaS3GqXTvErSGKsDQxWB7RihH1fNbXEUm/GvXKG4dVRzYPT+VKTZBDW26gnBaWR C8zwXuuy3aOdUl1KKy4cDZRHVySojZarDXnxiiwtpImPq46nCZq8TCtxX1GgZxs4 Vx6I0sGNFJwVDK8jTZa6 =Y/gm -END PGP SIGNATURE-
Re: [gentoo-dev] desktop-effects herd future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06-11-2011 16:37, Samuli Suominen wrote: With bug 365121 we don't really have a working compiz in Portage anymore for quite a while. Anyone willing to work on bug 363321 or shall I just lastrite the package? Is anyone interested in joining the desktop-effects herd? If not, I guess it's time I drop all the packages that herd maintained and drop the overlay as well. I've moved to other stuff and haven't got the urge to work on desktop-effects packages, in particular compiz, in a long time. All the other members have stopped working on the packages too. - Samuli - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOt0EZAAoJEC8ZTXQF1qEPTgAP/3hfjWAdm3ammjI2/LxfQkpL FFdmdhe5Solfe58LhCAeHxPYTrDIMD4kwWgD6z5I624D/KOTSVyNGZ891g7q42Bu 8DKpqfTrHZcefsZlqhFxlkxISkxyaDt+fqqjQWnBZHAJ8Wf6P3DmY2cN2Rik2b1m KtiQvwd2n8bZoJkYV4YTE/iiO2PVREliAuo4oeVoC/fuzPonblzWgVCkYhVRDOZK ny0V8AID/T5PXW7cJuruozKj6RB0d63wjKjsfpS7rN5gyiVJ3igpkhpY0jUX7yk+ 5c+hpBcJDCyxOj1625viR4ygLc2AiyYpHjO2SePrpsBopPaXMupciRb5SnHK4kdC WY7/Qu4nE41qcBXgKYgoDCK8ywL+U38Hhhlf+ETOt1HYniEvJEQposi7GCrJBph2 OsmMPFYR/Ux7TMAWz7FMBw9xYL0m9UHqqEhZWjkN/QUMWVh1/bDRazmfyRy6KHXG y3H/pDxDejDyYiN9tB3hdlWl/Yeq9+6SFJ5N+1FR3mGDMrJ3+ApYdH1j84XiLOg5 FaDQIDSnQNhpOvVcApEydYnAMEixN1o7vFgWEHg7SSZCQPalr0iXmCTgCiZT2tAa MRO0nvbVc9i58OX0fbK8iZMt7R/YA0dfr2/OIpda+bkxPV6elw3aYQTo0V5ahX1o +FwMCNnhT+rDbdr0pypf =HZTI -END PGP SIGNATURE-
Re: [gentoo-dev] git-2: a bunch of patches to review
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22-09-2011 08:11, Michał Górny wrote:
On Thu, 22 Sep 2011 09:01:17 +0200 Ulrich Mueller u...@gentoo.org
wrote:
Attaching fixed version of the last two patches, and a
complete eclass for convenience.
Just a general comment: Is it really necessary to change all [[
-n ${foo} ]] and [[ -z ${foo} ]] conditionals to the more
obscure [[ ${foo} ]] and [[ ! ${foo} ]]?
The shortest possible form is not always the one that's best
readable.
The style change was approved by Donnie already.
You mean that Donnie agreed with the style change. It's not up to any
individual developer to approve such a change for the entire tree.
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOexTUAAoJEC8ZTXQF1qEPMZ0QALNSTSCLwCKP9hd2BSt7HtP3
BzsJHr9Q+9+DpdwG9eRjbE0AnW1EbhpFmctPAnEszwC7I0NxID8vAsMw4HQS2MA8
wv2HKY14HYhSV9KBhHISn0i3tg8+LPwCpZJUYca4LWM+1o6brW/+MYEyzRBjWnMN
ljVEfK+to94+UvsPZyjvd0jRp3MuGVoATyXEDwHo1pNFC89Fq03J2YSvP6lPYE1V
J/Etw9PM5jJLWE7qQ8BlxHvf4FCWXZbAoOJ1kAFKLUp0v9AJeHssU84ZxZWDU/Rc
NjAiscFDXfhldL/DYlXFtZe24nF2V9aJ8DNFk+639f+L45oky5WNupiyRLMyn9ut
WAJAoPIoyQRccph5eAW2frrk7hUKhjsfS3uCDCB9otncQYpAFLK4X8USzRMEQlNV
QBBODOwccb/9BbwK6WGTywJiamB36dR9YGtdD6h+gULytRP9+WCK2HYGhQOAxumE
y+nVo4o5JAvHJ5W2IpCO611rbpyx/KXLGMu7my2OY06xrSsf1tU1DMEN+T3YtZ0s
s7TQRvbobKYmi4RsbQ/3J6ept5KldLLuhi4B/l/Nst2Di9bMCQ0bCHKcObeKsir+
LOb7zdVMwVAvCK1DvnPgFKMyR5LCfcHvdy1tD6UxwYlNUcm6SNMytb1QET/B0k4n
6Yyi7UQgCXfYWP5KL7TX
=4YOg
-END PGP SIGNATURE-
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-09-2011 09:33, Ciaran McCreesh wrote: On Sun, 18 Sep 2011 14:54:56 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: I don't see any features in EAPI 3 and 4 that are useful for the profiles. However, a bump to EAPI 2 (or at least 1) would be *extremely* beneficial, and cause much less chaos. Speaking with my GNOME hat, it will be *extremely* useful for slot-masking GNOME packages. If that route is taken, I'd recommend 1 rather than 2, for the simple reason that if 2 is introduced to profiles, we need to have a very careful discussion about the meanings of use dependencies in profile files. For example, people might think they can start masking cat/pkg[flag]. Is this a replacement for package.use.mask or does it mean something else? I have a sneaking suspicion that if there's not a policy saying no use deps in profiles then people will start trying to use them for all kinds of horrible hacks that would be better being fixed properly. What other meanings could it have? What would be the problem with moving the package use flag masks from package.use.mask to package.mask? As we're talking about updating profiles EAPI, what do we need to get to be able to mask use flags for the stable tree, but not the testing tree? Also, should we get back to the discussion of decoupling keywords from ebuilds and move them to profiles? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOdf4yAAoJEC8ZTXQF1qEPmxsQAKX/rqRhF9cnekdaVZK9oPSA wd9GxDoof2zkUgf0UM+HH0ACzZ7cIznodK32gY+J0waBAucmq/Dn3xbrY2wrpJS7 130HqbKB+jyX+7SaT1DYdwdDJ4hAvdgAG0Vhnq6xF2lsvFPYsuq6irMzK8lXdeID qEUMQ8+7RtrotilVyeIuiSUUp+I8Z6vdhKbqmAYf91/UP5BOFvtleF6vVimtj4HA q+i6ELpExrIvH1zWgIJ9k0oyL+LNWCnOiajT4dy7qdy73wVy+8LLA2+nntLIbhdv X4HSm9wHvhKsdB1OCub0rh+WFH4gBb6CoZtqSWHuzLEEXzClXsym0XxjqBu8slaj F8+e04jTF1zO9GchDlOvAWJroOP9hsKlSJg+bbvnk4Dat72OPKA1zJf/R9XurNkn 4MWPgY7TCYbpIB2hSPHsmQ7rnxz8sj+pgDZqY8MNpqLl7XGITSMhp7Krq0yS2MOP mkI5ZvhVkx9eqvM2MRe0KCKsC7r1U/2DSgkS+YlRmUvD2ts08miY5Ce2bVS4OWP3 5Wr5mVBJTlMMrN0NUX0LVtt3yuDV6voVeyxEI3iCMRAfYde34ddpFJ3e5x8q7bAA aldoJ8383J6RWhx7dBhnLgQ/zQm94E4g9o9sJW5sYwcfZ4qOh+SQbnuI7HVxEj2e vuvrabJqE2RsjHfJcW+y =axJ6 -END PGP SIGNATURE-
Re: [gentoo-dev] udev and /usr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-09-2011 12:59, Nirbheek Chauhan wrote: On Sun, Sep 18, 2011 at 6:19 PM, Michał Górny mgo...@gentoo.org wrote: No, there isn't anything traumatic. The only thing systemd folks are doing is nicely asking devs to include systemd unit files whenever necessary or use the eclass whenever upstream supplies those files. In other words, some devs just found themselves a scapegoat. ++ I'm astonished by the large amount of misinformation that is being spread around about systemd. If this originated on the gentoo-user mailing list, I'm disappointed that Gentoo users wouldn't do some basic research. I kind of expect this kind of trigger-happy FUD from websites like omgubuntu, but surely Gentoo folk are more mature. You mean that no Linux users, in particular anyone not running or not wanting to run GNOME and Fedora, shouldn't be worried about the way some people in the GNOME and Fedora community seem intent to impose their ways to everyone else? Worse, in the process seeming to want to convince everyone they found the panacea and that the old unix ways that have been around for 40+ years are all obsolete and that we should give in to the collective? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOdf+2AAoJEC8ZTXQF1qEPyKEQANmT0GVzK0aHSCPiX8d08ZY0 dSFiiXHUyXPemT1k0ilKk87uFkejhV3KFD3HUv9QwMJ/7NTOKIZibYG3i2+lPWhS +1eTjprsuke08YaPbo4HQMyGwPgwyMDNJ4wz30NDDmu3UgyFHsMNyF24vaVv6rri 7EgVUIbhJIWUl57sQ9nDT8njxh3I1RUykP8rxlob5iF2aLPVojKd/FoyP5daBXne kZfWdz5/L7qxslIaUnSjLfZ2Oeu9PRN7UOMWWTlZfq77r2z4yDlYv0SEN5o8+oEw uVLtTD+nZvN67WYNh7GrXn5ix/cGWieHkV6q23HrmNPA6wCUCqNgLNNkiKWlrHpc E/IO5vu4YYEqCmedYS7mnbJEQjlOsrDjyTDaHJ0YGLoLs2+zr9RME8PADRu/mM5I 4LUX4G8b5PAagZmNr32061YCHCgh6qAcUPcFJCaoBAOITLVH8tf1STaH6vJ7p56e eeaT+fipDLKrdYX/xfYlxe/RvU+Sz0dsnNEf863p8s7QNCFmZV8DHUh5Q0g5tHUb m/xib5WhCF68o73t05PEAYcIoDapmMscLNQ0l/xIPT+OQiVOOUH2FfYFbZ5sAUHK HVKF46jyZdkIHWGQFW4GfopHDMZDmKWL4jUgfERnmV8JeOZtvK8h61k+35HiLrSu MhbFeB3VJnnl8HHHXWcx =2sUg -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoostats, SoC 2011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29-08-2011 21:23, Donnie Berkholz wrote: On 03:18 Fri 26 Aug , Jorge Manuel B. S. Vicetto wrote: I've picked this message as I want to address one point in this thread that was focused on this sub-thread. I disagree with the idea that adding an application to the Gentoo tree that collects data from users and sends it to a central (or distributed) system is the same as adding any other application to the tree. Having the ability to add ebuilds to the tree is part of what you gain by getting gentoo-x86 access. Issues with significant users privacy concerns and substantial changes like adding packages to the tree that collect data from users and compile it, Like, oh, any package with a built-in bug reporting system? How many of those are part of the system set or get installed automatically on one's system without any intervention? Furthermore, how many of them are or will be programmed to send data automatically, without prior action of the user and possibly without trace? The point I was addressing is the suggestion that the above should be possible and the idea that any single developer is entitled to do so. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOXEKXAAoJEC8ZTXQF1qEP1ggP+gLBY9IiNjOaIxdQoJ1B/i2f KEmvyTddr4Grxjo8ZME7mefIHi/8ethrWKBuCgf//XshpCQ2r+xKtEgluQf4fX+w MAk9OePybbJJvIeATuoxb/nVYaihMZ7uuOtH5dqbDzhWMMsV0xkmTqgztrQM2v4X jE4yT2hPYV4Ir9OUljzJ5LTBkcdgwDKIjxSn/lUjvCWhNGKr081h6437fOuIQDYE kf+/nDU/UDngk7yKTH4Bgbd7pBNUe8Fu8HJ+7y8iwG0Y4mPW8VCFRHsBFTVNf2/p haX68uC/jPAsWEPO3/YO5rs8JDHNXqL+8zXRPjZn/E0cUkT13+Fa79vKXI6wTPK4 fwF+WZdmAmP/zW5Gs7w82wbML0S0KhQzfVmLu+ne3NBxGhrtnpEzFq6BQgzCtlNu p8vQjtCEVSpeHkTMt0St9/3qPMXhVc1DCRllD2OrEbFil1keHLutDHzIFLVxUZuE 9Fv+esWuTI7yzJjErbvT2OGzbpZMvPuho90QthIbSap/fIf6vK/DOgN+2FcJy0/7 PDtIq8fRL2NF/CQOxjwfGwkpyUK3ZWk7QCBh65MA4PiZHG1eZf5enlvg+WuqYHcC e14tvNVl0FeiW3lwCNy3/IOugSPpIatrbtHCImu0eaJ6oZqLP+OX6HZjpixJg2TP JEnebRBgj6z6VdT774gg =vmrl -END PGP SIGNATURE-
Re: [gentoo-dev] License for Google Chrome
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26-08-2011 22:06, Mike Gilbert wrote: I have been maintaining an ebuild for Google Chrome in an overlay. It basically extracts a deb file to /opt. This serves as an easy alternative for people who do not have the patience to compile Chromium. Now that I have developer access, I would like to move this to the tree. Before doing so, I need some advice on how to deal with the EULA[1]. I think clause 2.2 (B) allows me to avoid a fetch restriction. I think clause 5.3 prohibits mirroring. Do I need to worry about anything else here? [1] http://www.google.com/chrome/intl/en/eula_text.html Mike, when you have doubts about a license and mail the gentoo-dev ml, also cc the licenses alias. I'm curious, but does Google release a pre-compiled binary that you can use as chrome-bin? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOWExdAAoJEC8ZTXQF1qEPhggP/imjIP9mWTkev452mwtjYPfH NRTwHuiXmCkzX/uwmsS+kRBFMv62FUTUYMTdi0KS/j+UYyLzrdygH7aUE+rGZjbM ucEAxh3Q69/KCd/syRhTDjK/997D+7385jPJdgCNPewbWfNw3JYlHyoItp3s8vTU JO3hxFI2salhAxn+kjoJSxWUXAPsROFdKRayzhTATLIbzgyh5x1ylEYPS8EQ3q+P +tBdtN0Qt3vicfJOQL/ZtaQgOuCqv/CEUofm+HPkS2OlIE/41uE1bkN3Gk4qi6wO //dLw7S/lheJubjs6RwbqAtOkoSV6M4bK1q6ggFWZpCetfy3hK1ilAPwP2aKyVkc zL+Xphs/SkgVWcyGygW+x+AiaMwqZ2MdZxUoUyqZ3X4aQSyRWgnDc4ESCRE5PKwN gqnlaBRJIhU8XT59tPjrO82kcjtr8ZQDHk+VkUHdMrwubce5iD45zgkpCFHCK7dO Tma+Je3QNJl1sO/sBL8NnRokXn5IiEXy/MKIU80VPGnH5VOcUMsMIK1kni12AVs9 Lwb3ReYyqnNtWncOrMirjzyW4KtEgFduwvjex6ESvjWMZ8AetFUjWe9GLCxVGEt7 71qnnckxOritbZDOh3C0VmY0ac8i12JKmaxEYgb9oBT4xoAZrk0GbdFYoC7xt91z hm0pLv01fSkG4altk2IN =2ayy -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoostats, SoC 2011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25-08-2011 14:35, Alec Warner wrote: On Thu, Aug 25, 2011 at 5:20 AM, Rich Freeman ri...@gentoo.org wrote: snip The big issue with opt-out is privacy law - especially in Europe (that's leaving aside just being up-front with users). We'd end up having to have EULAs or such and perhaps a number of other legal controls, and I don't think that is a direction that we want to go in. I'm just not seeing the upside - better to just figure out good ways to use data that is easy and safe to obtain first. Earlier somebody suggested that this decision wasn't really in the domain of the Council/Trustees. I'm not sure I agree here - any kind of opt-out data collection is something that has potential legal ramifications as well as huge reputation concerns for the distro (the software is distributed from Foundation-owned hardware utilizing a Foundation-owned domain name and the data goes back to Foundation-owned hardware - I'm sure any lawyer could make a case for this). Just because there isn't a policy written down somewhere doesn't mean that we can't use common sense. Devs certainly don't need to run everything past the Council, but if you want to do something high-profile post it on -dev, and if there is an uproar look for an official second opinion before doing it. We did post to -dev, hence this thread. The point is that we don't need any 'official opinion' to do anything; and I don't want to set that precedent. If you have specific concerns about actions we plan to take (which by the way, we are not planning an opt-out solution. If we plan to do an opt-out solution, we will again have a thread on -dev) then let us know. If you have specific legal concerns about the application, data retention, encryption, logs, backups, onerous european privacy laws, and other such questions you should raise those concerns now. I've picked this message as I want to address one point in this thread that was focused on this sub-thread. I disagree with the idea that adding an application to the Gentoo tree that collects data from users and sends it to a central (or distributed) system is the same as adding any other application to the tree. Having the ability to add ebuilds to the tree is part of what you gain by getting gentoo-x86 access. Issues with significant users privacy concerns and substantial changes like adding packages to the tree that collect data from users and compile it, should not be at the discretion of individual developers but be subject of global policies that should take into account the legal ramifications (trustees) and reflect the developers desire and goals (council). - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOVxCXAAoJEC8ZTXQF1qEP7KAQAJBwDHp4aS+5l8gahHUrsWYI 0gUpO+qtsFODsKToQa4ZZ9jTZhFvN0iscyApXvgO8FBOnPzFCMiq+LblI/j/cnFK OwVYJ4/tvcc1C1fE1lQecd1kNVlnVLCEvR8NbeKA184ty4kS7cJy2FqAiWbzGGno /zNsQI+iDUg6ZCamCz29EZ5FJgfUzXzG+Ipbh61T0c/Ukugq5xHA8c5zTzoRre2u /fSRMM9qPakmgaHJoV8t+8B0ejJccW/+MquKIyFdDnUDvQH5U/RnXl3D5oe7+0vb Eak3VB5iUrkZifqhpOQMEeAtuNColigPy4oPr6BsQz7t0uiC2M0MHei4cigbN8kn yp4U+RZE4PhJ/+b/U/jnaiidGu8IF+Kdl3DPgCR130N4vbpO8u7KjyphdoL7QZx5 hnc3A5ZxQxraQolKtFnl8Be8P5NvuKdiP192wYmACuCw3W95XVNDtUhc63n++fqo 0K9WTEudO+JZN7JYZFSU6OJo5hvujHcQvvIO2sG30Q56x7EfvCRFCzMUsRC8mU0L uSKW+YFHVp1+yCJ9BbnTWp9afPUVQ56/1YtCxLDsqEi0lI7otm0TpuJFIC/fDJ1F Hf9Kqaap9kZzc1WBKuMY0Rvvf8CKf/9bd9QTxT5Fz/tpiNGkU9MTMFPHghDFUP8h 773YR/NFapQVLHyqemla =G4Y6 -END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-08-2011 08:50, Diego Elio Pettenò wrote: Hello everybody, I have already said this before, but it looks like nobody cared. We have a problem for what concerns Gentoo-generated distfiles. This includes custom snapshots, custom packages, patches, patchsets, and so on so forth. While it was infra that (back when I joined at least) asked not to use dev.gentoo.org for hosting said fails and rather prefer to use mirror://gentoo/, they already stated that it's not a problem to do so until we have a proper system in place (system that has been considered and worked on for quite a bit already and yet is not available). Unfortunately, as long as the mirror://gentoo/ option is still maintained, we'll end up with situations like today's gnuconfig that couldn't be fetched, causing all ~arch users to see the same failure, because the distfile wasn't uploaded to the staging area. Of course the same could happen with a stable SRC_URI, but then it would fail after hitting that, rather than going through half the gentoo mirrors trying to find a file that is not there. So, anybody has reasons beside laziness, or concern for infra's disk usage (that argument is allowed to come only from infra members!), to not go this route? Diego, I understand the concern, but instead of banning the use of mirror://gentoo, why not make it mandatory to have a dev.gentoo.org link in SRC_URI when there's a mirror://gentoo link? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOTP2OAAoJEC8ZTXQF1qEPWnoP/jpHJAonBiWm7p6xp1AjuAaE t2vkFYFpxQRJ0IOYSaXh1Qrynhzc7ky5sT3G6/sLZPARfbCKinjWEXqGJMyvEsHU tkk4cRdTeoi1iCa8tDtMVgXCEVofhwYJZQvbm+rVRzwuGgks4kNxsVOlAcmPZ3iU tj9mfgFqKmhuNbFHe/fcPTkEFmCfyMFQdbt0btdk9PKOZK4MK39lEd6kifkNFRKp Xtzud3uttud+5bOJIQ4er2OthNQhQGEA2SUnS8M5TL0qZyQDfHNrxZGMwbCu/qqz vsldI6H6d0mCpuBDJ0WeFTcwwgSRCrM2+WiHsseJCUQODcSNkAikSvtaSNyx1LZg PDQt05m4cX4bQ1I2obwJUvvss7LrDUH9P0JRE+4SHQsPAPwUMNMl3wfPg+PTXXF+ EI1QVEySaMsbJE3czQ7x8stt7Ogzh54eswwKn7Z40yjByX95gH+Oy75ouZmNV5AX FEnnvpOCyOorc+K1ye+q26rwYHOndtuI/geGRHaF4HDpY+DKyzkq5Pj4v+m7/njP V1QzYbMu+CYeBlnpnvpQ690Kxayn9e2+5n6DDzoJw1SjBMfJcZ9RnqXJvi0+6uJ3 fuH/FR9iczxambDEgafACKLGXfaNUuIfDeeXK3Xf1qXp2JYfDNmR68HWN8a0hjBm SDk6u/zlsSpq6oYuUgAg =96T7 -END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-08-2011 08:50, Diego Elio Pettenò wrote: Diego, I understand the concern, but instead of banning the use of mirror://gentoo, why not make it mandatory to have a dev.gentoo.org link in SRC_URI when there's a mirror://gentoo link? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOTP1+AAoJEC8ZTXQF1qEP/EQQAKMv5JQsj6dH9ry2+Pukf6oh PqXJkcJJBe2b3vIHRdaj50qiXvpZDYSsRX4U5juCG9nwlYSx0UyZkBVZl9IQHmpB 8XRXZAsjtku100mejuOm8RffINXWvy1pefvN1Qdofnu1US/l8SXSZCQf9VikRvLI HEcrCAHETSjm4ZbuChc9o2ZH2qbkeRZCctZvmVSOWcTRMdkBoNAwYTDnCYzly36m OfMLWCwpNBhIT3z4mK7BEMYx8kGAr7xM5tzBnBXaLu3XJ6Q2iX/yFsrdxJLoaxnx OxMk3DxG/8zdD41u1UPh2oSDaYIfDl1JAGv2etvNPmatCv3RqL4vKRp8J1buZmJw /IK8C7mzj0HU7sOaIkIAZDP0fi/9QG0RPYSh6bi2mVF+mQ3lOWLdXdzDtT9X7aUW zvBgVUvmNLgn52jvGK0fzaqtfQ9rL+RYuM46ziTPg2eJOK7adrlAHcyE7RVIl4ks z07qV4EqzFWmDXriRo8C556XUkCUO16X0QQFKmm6TrM58PEqjP1mviCxMKj6RTYI 4pkNKyFnIDI7z2i6NaCVwi+V3OvB1BthiMMVt0TgM8zjV/99sZw7LVpX3WIaiFdR yUz/f8OPTPmZfQNtXz2MGmoX6CNSOIUyH6uo6GPIY/dtsh/jLiOlOOUQB9FWpsq9 5UFiY6VYzkDd1wkMA1hb =KKq4 -END PGP SIGNATURE-
Re: [gentoo-dev] /usr vs. initramfs redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10-08-2011 21:56, Robin H. Johnson wrote: On Wed, Aug 10, 2011 at 03:57:30PM -0500, William Hubbs wrote: Sorry, I should have been more clear here. Mounting /var doesn't fill up the root partition, but if you don't want to use the initramfs, this means that /var must also exist on the root partition, which can create more of a concern for filling the root partition than putting /usr on the root partition creates. That's a problem for the users, not the initramfs. The initramfs supports /usr, /var and anything else as noted. Having /var on / is a perfectly valid choice for certain situations. The problem of filling up / is PEBKAC primarily, and can happen equally for / (think /root), /usr on /, /var on /. True, but it's also far more likely to happen when you have /usr and /var on / than otherwise. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOQxMdAAoJEC8ZTXQF1qEPBKoQAI5FBt/rDaFSWA5ln6tmDNOt HhLq54dirdaXWSdHUp6C+vmSNcAC/QPmPlB8RA/bwXQ2aRlO0m4Jc6XPS3NTdT0H TEgqBQ+3NtZ3mRyTHv+E2YtDanemZIQ5rrpl0QuvMfeODUOM3zNdTosV6/37tmo+ 9clXHGzauPqWKpUvXxHc9Ic7OSA9ROXy1vq8wvTzvQWsg2sz7ML6pU7yAE5niC78 FlFgZyG2aZ0S+oBt88aSEkDEwU6aDlgQbLwxT5rN61QtE8wvV5hx5h7k74iJwkaJ 89vUbcgtmdMNFVYcXpIprlqkYWKr68uBxqsdSy2z+uX6d6E90G8mQs8qF9cHryFY YuA9WSXn4rtElsTkdrdA9yEqEwGXSeiD9oohn8wHwcVYNKWYKVPiRzeCxyAVOSVy dUqCRh5ZvTVuyD7wvVY1rVihCRLdSSOTYkUknOWexPs/PqvWmwDlhsEH79vVZeL2 pxnO5umvLKn17FL/jOimS2djua1b83elX99nqjdfZLTqT/DCeZ699YOD2Hc1Dd0O AtYmDzbJSNnjKoFVU8SGX4NspsGdilBFKCa5Gj6MUXqHgjHcMK23HpBcl76jIgeX tqK+ooJYsd0p/hwCV3gJqaUQvtvU3r05qfU7Qjzg3PAif0Heu4wrjKG056UkUIFb t1HYMphiA6ITXnSLVl7o =EcGc -END PGP SIGNATURE-
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04-08-2011 07:55, Samuli Suominen wrote: On 08/04/2011 05:30 AM, Michał Górny wrote: On Sat, 30 Jul 2011 10:27:27 +0300 snip So, let's sum up a little. The most common argument against separate /usr requiring a proper initramfs is 'it works now, thus it's great'. That is practically understandable that people don't like to switch things upside down like that, especially when machines are not locally reachable. What's the exact differences between an initramfs and an early bootup setup in rootfs? As I see it: - initramfs is a small fs which is used for a short while on boot, to setup the system necessarily for the early bootup sequence, - while initial rootfs is a rather large piece of fs which is supposed to contain random stuff necessary for the early bootup to be able to proceed and mount the necessary remaining stuff before the actual bootup begins. And we're mostly stuck with it for the whole runtime. As I see it, I see no reason to keep forcing things like complete glibc, ncurses and the whole other lot of libraries for the early bootup if all needed is some kind of minimal 'mount' program (for instance). In the ol' days I tried building a NFS-shared system and the main problem was that some of early run tools relied heavily on the local system libs and files before they were replaced by NFS mounts. And I had to keep them in sync manually which is not the most comfortable thing. I don't see how trying to fit the best set of libs and files into rootfs can solve it. You either want for the system to be clean or weirdly split to support various possible configurations. And decide which are not 'weird enough' not to support. And really, most of the things about separate /usr are hacks which were introduced because the system was incapable of a proper rootfs. Read-only /usr should be read-only rootfs with writable mounts on top of it. NFS-mounted /usr should be the whole system part network-mounted (which would be easier if everything went into /usr rather than being split). It seems what we need is an migration plan. Sending out a Portage News item, and correcting documentation as first step. Then giving people enough time to migrate. This would give us plenty of time to work on the details for moving the files over from / to /usr. Again, not all of us are willing to migrate away from a separate /usr partition, least of all when that is being imposed by some people trying to shove their pet projects to others and when we don't agree with or acknowledge the arguments. It seems non-problematic for new installs, as stages could ship the symlinks and files get installed to /usr through them, even before the packages are changed. The symlinks will have to be part of baselayout as files get into stages through packages and not through catalyst. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOOn/LAAoJEC8ZTXQF1qEPOQsP+we6tifTVnCXqr46ajXa2Xft NqXhJfxmONGbbhfDYPhoNiGK5ovojpoDncKEE0t158X35QfLRjqFqrudbPDUNzrh /zEJmQYacZckyMT866PE2iJBovEA5ZBnXB8y6RBHJLH3ky5/dO8R92jHSnNihi1y u639+dpRHP6cRQIk9i2sEHaph+bZo6e3X+GCT6FL63m4sNDSBfJGo4wtMewp/aDD HS2Ya41WAt+SYA131QLcVwLhyDz7sRdQm1iR7W06iScMxgE/mKHF9S25NKMYf+H+ Qtd+PF1SLcxC1lKztPsmNTr1lpDLlAoO5OQzpOnXoPmCWvuzBVyrHfSPo+cxQOFM 6VA0mjdNODS4gbEL5Fu8Q/Asf3/byJ7gBOfLNuHkMksMfLSy/O0KXjx3fnmpj1a0 yXlt+iuer7z5rwuz7ZfXNCmw0DWzuMOUimz1jz0pUwTzXDD9zZJXKHOt/RR4oQb8 NLldmh8YBcl17r6l60H49GWyL8YiIhQetBZuNi9+Pm72o3vVsKmCnyXHP1Cf0CsQ ziVy4+Lub2qSSQfndrTHnJ6rDIDFSLT4iZYRDJmlf6Mhrk7abogze/s0Vgfkfrfl yJVNVPG3Evk4d1qIFROSmQhhu44EOkufhijYvytpCHeNLvWUupeaMZOchX6QUXp4 4FhE/udxLI1zpQtTHLbJ =DhRY -END PGP SIGNATURE-
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01-08-2011 08:31, Eray Aslan wrote: On 2011-08-01 10:23 AM, Samuli Suominen wrote: that's my impression now too since nobody has managed to provide useful case for separate /usr, or they have been very vague I will switch if I have to but saying / and /usr on the same filesystem is the better technical solution just annoys me. I understand if going against upstream and keeping them seperate is not worth the hassle and noone steps up to do it. But then we should say so. Please don't kid yourself (or others). I agree with Eray. Furthermore, please stop trying to reverse the game. It's those that want to break existing policies and conventions that have to justify why they want to do that, not those that want to keep using what has worked for years. You may not need or like it, but I want to be able to use partition schemes like the following without needing to use an initramfs: /dev/md4/boot /dev/md2/ /dev/sda1 swap /dev/sdb1 swap /dev/vg/home/home /dev/vg/usr /usr /dev/vg/portage /usr/portage /dev/vg/distfiles /usr/portage/distfiles /dev/vg/var /var /dev/vg/vtmp/var/tmp /dev/vg/www /var/www /dev/vg/repos /home/repositories /dev/vg/release /home/release Also, desktop users that don't split the /usr path might not like the stress that /usr/portage will add to the / partition - not to talk about the size and inode constraints. With the above design, I have on a system the following disk space use: FilesystemSize Used Avail Use% Mounted on rootfs9,4G 262M 8,7G 3% / I'm growing tired of how complex and over-designed desktop technologies that hide stuff from the users keep trying to break the unix way and convince us they're awesome. No, I don't need or want *kit, groups exist for something. No, applications that do magic stuff with dbus and xml (and I like xml) on the users back and hide how X work aren't a good thing(tm). Finally, Gentoo's init system is and will likely be for a long time openrc, so stop trying to push crazy or experimental init systems - most with a seemingly poor design and unable to do what an init system needs to do (start and stop services). - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJONm+6AAoJEC8ZTXQF1qEP10wP/ifqJFPJxbpbhJfMc2+UpvAj Danv5I4hRhOhixfz5ni63Kw++kFmxJ2o0oSxmPOMUuIZgdakDAQFAMPhGnTZc6l6 /cqrraZjM215fcJLq3mzq2KfC+c6l45gLv87sagmwuTLLSDnFbXllY2vNo2KgQ/u Brf1IxqBMQeesC21gVNyewnLpWe/hPLqoigIYepBQt4Fg3GxhRYQuVcKC/oE9mO2 Z/0pOJW42fE5i5+VZRPUb7q9WC2bAlVQymRDc+Lt/b6f6VUIFa+SVgcCAkE2HoPo Xue+jiMNCDAvWuqmGeRGySDmAp3VtqobHjaaVkLXDJOG14u0HmP3qXK9oLtSA3Fz FUaL8yNjfjlZ94ntRZax2WCFat66tX03pF4QC/EQfnVx+8dgMUH3sop/s8Ay1pLX Q05sXhoEIyNMOfo04IJt6aQqgLqKHuxL9dTu+q1dN7pnQ5CGZ027W6XCe8251UIe 6wmyVwaQPQKSZ0N7j0LkqujFmCjPoFRCAN9QRPMM9g4rYTuVsjm49BjgFFFegQ+y qTM3lvriQR34a1x1khnnb44g+1611q92CuTjcr6B9Ho1IY6Osqk68y3hA2WTZ0+p S6+cKiBlnA1Q6+2lqcVP89Fb5WP44LHc5xmAvyzfx5LJsQ3XvINgrrx9kGbvgge7 wIY+OXxnZD8oW0MpiYO2 =ybUS -END PGP SIGNATURE-
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30-07-2011 22:17, William Hubbs wrote: On Sat, Jul 30, 2011 at 10:27:27AM +0300, Samuli Suominen wrote: Since running separate /usr without mounting it from initramfs on top of / before init is and has been broken with udev for a long time now[1][2][3] [1] http://bugs.gentoo.org/show_bug.cgi?id=364235 [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr [3] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Can we warn users about not doing the separate /usr mistake in the handbook? There are actually two options for us according to upstream. One is the one you are talking about -- mounting /usr from an initramfs before / is mounted. The other is to mount local file systems, if setups are simple enough, before we start udev. I could set this one up easily enough just by moving localmount to the boot runlevel. Can we discuss both options? If there's any option that allows the use of a separate /usr partition without an initramfs, then let's explore it. I don't feel like having to use an initramfs just because I want a small / without /usr on it. As others have said, having /usr as a separate partition worked for years until some people started trying to shove bloat on everyone's systems and then they want us to believe that having /usr as a separate partition is stupid. William - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJONKjzAAoJEC8ZTXQF1qEPLjEP/i8oGv6aP3RH1SokVG5llfuq j0pckRZOTcqcHl4CM7ZfvYvixLR8XZK1ZSRk3DnysxUQCrI6fNvYr1/8EqJUIB9j wM5XRshkyOwh8VpwdTdd/y0XhcE1MaAqwXOXOO2FrnuH6cd6RR0YFbeVVbL62kni PdTV+DNY2Wbo1fn8xAY0lRANMqghNXPGBK4/5kYuwCBME1xaV/cRkbDrtUnznWbq dsCshhm5m2ertOHuRZzDQfpUOlS0J5RiE8zvAqyasC1stT3TcegcnTL/M8zxOoF8 jxcPJCIsVx/WfKrDXT9qgSOo9/E2X182dLN/6br2prV/Yvjb0nMcC1orsueHDnVo WHvYCEZ7ZlLIMw6boiWycqzRcxSrz24XQLufyWwcYUpWdxHmToNPW6dOQvM+ZcNz QAOs3fAR7NinGHMRkl9AehCbK1PiKBBmiZU/KXcCffBabWsUuwWEwhxz0BNGvLgZ 62NgPM1HbF3+azq+mqre2tp2mu3s4cVUiu12Zf5SBXTJP98FCIX9Q+vpypoQGhjv R1JtlozfOunPYnLaEBT0pz/Rev9HrdxIpslKcQug6N3u/1Z0+COUSEatr9xJDSOb fXD6c+Cm4zFcJx1hiZ2+qyidhcX57uC+2Y6GIVGhHKOBwJSFna0DGsQw8iMbNk8Y OQ2x6i+JYAqyUKZdJLP3 =bxvJ -END PGP SIGNATURE-
Re: [gentoo-dev] About some developers in devaway status that maybe are no longer active at all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09-07-2011 14:43, Markos Chandras wrote: On 09/07/2011 03:20 ¼¼, Jorge Manuel B. S. Vicetto wrote: The retirement process evolves with time and with our experience. Markos linked to the last documented process, but after that we've been trying to take care of metadata.xml asap. So as soon as a bug is assigned to infra, we're free to drop people from metadata.xml and reassign bugs. - From that point onwards, if a retirement is stopped, it's the developer's responsibility to add himself back to any packages and to get back to bugs. The processing of herds and teams should still be left to the final step. Good point Jorge. I agree that we should process bugs and metadata.xml when we assign bugs to infra. Do you want me to update the docs? Please do it. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOGadwAAoJEC8ZTXQF1qEP6boP/0fwBsSH4SW8Vr5tZNMAV81M RbQ/7UGVwlUfwIu21+SfBTXs7E9n+oLIDltcIglIgLrgFF12yIW0ueZvkgrfcbKV jg/WT3Jq9njXGc11FN7NUnmbzbLKxzf219LTk2Jqq9dQ4ucgg7k3so8gYrnSbDpx OlLcl6Qu4cpH/jH6hmAa2sYOzwA9b9bzPOZlDITizqHgg0ZfED8XopWxGMw8Aptu Dh+mbDIdtpi+FzxTlUa/mDxELRjbdwxfUnFlM+LuJ2Cv6Mrqat9h4bMSeCWq4zN/ UAOlisLdNUJCUcoWmiP4mDPjEFyMx/CLyilFz2IxRnRw0BbWJZm0sFKWKajX8I2P yZgOJR0UTdgLU+X9JwUeH7/HbpaToONJtCF452dikVCJPcM/+X1/Yb5BF+kS5FO1 5WGE9//h1Rq8S/YYcyeC2BYM8PDJbTdRA6epB4HS0btlVqrAKvcQBpPF9TynFFoQ boCLH4zBZhcD5w+ZcXBDbBxrX15g7nbg36lNy2uWjjWRdD7g3Qs/OSno3VCThqtt RWW+Ktd1/MDv92lsUKlQe3v4qZWT22mmwQidh5duj1751NtWfWshXM7fvYCVBO7C JI5nDGV55tnGblzPTyW1kRrK6uMyw2f0ZnzVbRHmTEsbDZ21XDIzJHi955MvGw9Y +q88zt5PZVslCVNyU0NR =wxC1 -END PGP SIGNATURE-
Re: [gentoo-dev] About some developers in devaway status that maybe are no longer active at all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09-07-2011 14:40, Pacho Ramos wrote: El sáb, 09-07-2011 a las 12:20 +, Jorge Manuel B. S. Vicetto escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08-07-2011 17:00, Pacho Ramos wrote: El vie, 08-07-2011 a las 19:45 +0300, Markos Chandras escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 snip Good point but there is a problem. If we process the metadata.xml, project pages and bugs before the infrastructure people process his account, and the said developer decides to return, then we need to process all the previous files again and restore them to the previous state. This is why we do not touch them until the developer is fully retired by the infrastructure. This is the only way to ensure that he is really gone. The only thing you ( as an individual developer ) can do, is to report bugs, wait for some time, and if the slacking developer does not touch them, go ahead and fix them. We cannot force people to use the devaway system or to provide accurate information about their status :-/ - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 At what step is the retirement process irreversible then? For example, looking at https://bugs.gentoo.org/show_bug.cgi?id=266794#c13 I would start dropping him from metadata.xml as it's already clear the retirement has started :-/ Maybe we could add a step that makes the retirement irreversible (with a concrete date) after retirement team comments in bug report announcing the process has started. The retirement process evolves with time and with our experience. Markos linked to the last documented process, but after that we've been trying to take care of metadata.xml asap. So as soon as a bug is assigned to infra, we're free to drop people from metadata.xml and reassign bugs. - From that point onwards, if a retirement is stopped, it's the developer's responsibility to add himself back to any packages and to get back to bugs. The processing of herds and teams should still be left to the final step. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng OK, thanks for the explanation. I have searched in bugzilla for bugs with infra-retire in whiteboard and have found, for example: https://bugs.gentoo.org/show_bug.cgi?id=28480 I have seen he still have some bugs assigned to him and he is still present on metadata.xml. From your last comment, looks like we could start to reassign them and drop him from metadata.xml just now. Could I do that or should I be a member of retirement team? Anyone can help with that, so if you feel like doing it, please go ahead. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOGaeXAAoJEC8ZTXQF1qEP1x8P/1X2edKcJsXaWQx9f2TmkO8F 7FegJr6QpjipMJg6KQoKYO4rRPNuPCToGYJFQCvy/P5MYhX2LQUT4O/exUmk4j4j Rkpkj5NdoUVxj71Zq7foX3d6PE37XR6NACao1gkkNZSxoRHKhfDoCj8pyKpdNemK xOEoXhLTmZJnRJCkRu2/ZgEBp0dOp4TKMlSo8QnZSokUjoFb1/PF25JupYGNs+Wi 71tTW0ykiOFMPav2eMUZY4p7R9X/flHY1/7h8C4barkx4p/CV/aAg9sgksFGc+kT MHkgt7z3vjScKayLAbitwDNHsj7jeD0JVSkyki9cp0/9B0fjryD3goXrewk79e6e 3guhq1wTMrUpY8BmuHqQ0UUUKLKXp9bMdGcRKlTr8CQqlaPFtWqrpGpy1dlJ5cZw HbraScaQpQTQdklFYlql8WSBga+uGv6TrsruqeSEBETPm/CMNbTl94KljcJyH2rg aVAmlJhy0zTvweBI8iy8sshgmwhZxO8mJ1Jjo81Uomq5NoQNIvZXLpg18ubTGK9C QX3FpslfKCxsnhy7WVsw83g9L9aAj6ygkVd0kDZzd5bahBs3fqwvnQshcwHUOY4W /1mnwZfxfMb7LTTSTBpz9R4Ch4guMEb//9pLo6HtDGxJqElDvhDv5ypFlH6C/uZB YpVRPOxRX5n8FsP8Mf5P =nV04 -END PGP SIGNATURE-
Re: [gentoo-dev] About some developers in devaway status that maybe are no longer active at all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08-07-2011 17:00, Pacho Ramos wrote: El vie, 08-07-2011 a las 19:45 +0300, Markos Chandras escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 snip Good point but there is a problem. If we process the metadata.xml, project pages and bugs before the infrastructure people process his account, and the said developer decides to return, then we need to process all the previous files again and restore them to the previous state. This is why we do not touch them until the developer is fully retired by the infrastructure. This is the only way to ensure that he is really gone. The only thing you ( as an individual developer ) can do, is to report bugs, wait for some time, and if the slacking developer does not touch them, go ahead and fix them. We cannot force people to use the devaway system or to provide accurate information about their status :-/ - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 At what step is the retirement process irreversible then? For example, looking at https://bugs.gentoo.org/show_bug.cgi?id=266794#c13 I would start dropping him from metadata.xml as it's already clear the retirement has started :-/ Maybe we could add a step that makes the retirement irreversible (with a concrete date) after retirement team comments in bug report announcing the process has started. The retirement process evolves with time and with our experience. Markos linked to the last documented process, but after that we've been trying to take care of metadata.xml asap. So as soon as a bug is assigned to infra, we're free to drop people from metadata.xml and reassign bugs. - From that point onwards, if a retirement is stopped, it's the developer's responsibility to add himself back to any packages and to get back to bugs. The processing of herds and teams should still be left to the final step. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOGEeOAAoJEC8ZTXQF1qEP3PUP/0ts4zMqcC0nR1hhvwXv2qjF jifRUTSZzc9B2S9w1H+OgVx2Gw8wwy/gvu5HDewDUV4BPnpPS+5/hLWXE0zqhPEJ YoqT+6+uouOSLTa9kQj56Zt7eViBvfS8QIWeHi9Ajz7sfiZOZ2ykkJlZ0K/orcYI hrc62ppC3L0mrlGnfJf7dFPGAbKyuDl18MqzSm972wn7kM3vGM7RMvJURFt8ji18 +Kd1C9FOTZ/HiPFQOaL5ro5BKJHo7FWwWHz99NnorGRDFJZiwMcOlzgMJwo6qfnH 5fl0qxdSVx1BcZ0r0vUZAPcvDBI6GZlXwNwYfKRAnBTKM6P2c1BC28zpTwop01cU b7h/Ao/XRUHAC0rvYoONoGEvmTWrNMBE6OTPozsQQjat48ptHs2Z1Xd4Lp4TXell c3359wTsslktBWmFCwH6TK4FCjLXqOJucEXwrfZNADY8TJp04EeU9kRrwNhNPIJi WTeHG4l+5vtI1NtInU6eKpjBkECnuOCjauAnAoGDgqgV178vOSdAJCqstKPqu2tq W0JXJCBmayzEFi5G+pyiauJcv6nXA2GXrsL0x0fxbGOcY+n1Z6lC5k8wFQ4zMVuv cKOXqH3X2dOcpAVp+uGTOVljymQwjkoVhuLv+a4jD0n56+RNc5kMhjiz3KXvZP/G IhlVGU/MGO2ITp8ntJSI =jPcP -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01-07-2011 19:33, Patrick Lauer wrote: On 07/01/11 21:25, Sebastian Pipping wrote: [SNIP] If we use EAPI 4 in that ebuild we cannot make it stable anytime soon, correct? As far as I'm aware we have a stable portage with EAPI 4 in the tree for a few weeks now, so you can actively use it everywhere. This prompted me to search the council meeting logs about EAPI 4 use for stable packages. Contrary to my recollection, this topic fell off the council radar a few months ago. In any case, as decided in the February[1] meeting, EAPI 4 was approved for tree use. The first portage version with EAPI-4 support[2] was marked stable over 3 months ago[3]. I did a quick grep in the tree and count over 500 ebuilds with EAPI 4 and amd64 or x86 keywords, so we already have quite a few EAPI=4 stable packages in the tree. [1] - http://www.gentoo.org/proj/en/council/meeting-logs/20110201-summary.txt [2] - https://bugs.gentoo.org/358009 [3] - http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/portage/portage-2.1.9.42.ebuild?view=log - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJODnYtAAoJEC8ZTXQF1qEPub8P/1hYj/8jyw6eligk+pUV3P8W /yUK/71w3Em151IlVF4nkCRLhCM0FW+TpqVcmau/EKja5wzL/X+vaIaGKwjqfh39 Z3O0cjCs8hV/SZ/AscHkdiLG4TmL8M0zeHmTc7xKw1FW7QuLe6nOuZoBOSlYVwqX M+g/dm/snxQcfsxn0YNNn2g/GYrk8whUg6YBmqdqSlElh5xJS1Zvi+BokAPQqgu8 mK4DMs2yxEb6aOXsvCYDiwLgPfxZVCbAkXoqqEOQtHjoA76lDUt3LByP11fCTZXo ysUqDlXbL98ToX/jPRNNDLjdFKKKnaTcYjdEM1mzyou1i/tvQWJaTuvPrZzPohCy ph21dEJKEq70ECSCBUr26HQ9bOSyEDcyV415SENFt1Rp8lXhK4dIwPDXsMrHkC1F DzBa/8sGwFjtlLqj+x2pOzROx8lBrSRZE7vVwW4fabpoqM1VSqtqQSsQLufqpzz5 MpEtvf8kr9d6G2rHUzEDN0PuOj5ouwEi0AyG0IutAgIRx7UO4SmGrY0tbfImdgvd O9ynGdbrGd9zlRBsbrdtGHlNmAzF8C9+ZgxzMUduHKFfNNYdPeAmV6lO8EjZDKF6 PLyUVKx0dh1RUsYwtJRV/RSWzRjtuqeoLDjMR5lxchB+MaF4qw1FGYTiU/Sg6Szw gUmWGfpa/FQzM6uThtmp =TiQL -END PGP SIGNATURE-
Re: [gentoo-dev] removing of autotools from system set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29-06-2011 06:53, Mike Frysinger wrote: now that we have autotools.eclass to ease regenerating of autotools in ebuilds and people have generally adopted this tree-wide, i'd like to look at dropping autoconf, automake, and libtool from the system set. i'll wait for the current stage-breaking issue to get sorted out (/dev nodes in stage3) before making the commit, but i want to get this out there asap because i love making Jorge work for it. Yay, more work for me :-P I've started a new local build to test this. i dont think we'll need to add them to packages.build for stage1 as all the deps should be correct. any other issues people can think of ? -mike - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOCxaLAAoJEC8ZTXQF1qEPSsAQAJterew5pclN83Hw86FRyBW+ 72fd9eDYVJ6wBtj0BwW+FIWkQJrb59Hhs9gkHjiCAjmc/sPnU2vaUkZlI380d+/x Yg7bLIBmWpkaqxdEDFHHFAjdtpLxyTnExmE9N2cvu5ZgxlZjFSRo2QjzufOPwtn+ 3+A/haOZqr3Y6wu6dEftkArLjqzgT/l/WO+pQX5chQ8OCJ521rI1HRFA0fuR1vm9 nsSxrACI6KPB57NtxsG36IX1FdFuRWYxCNcs2N7WHS5Dx3ZQLTpJq9ZYPRtKn2XS Sdrre6bkKH+WTLzaJq2xy6kWC/q/prUbUC63c3oiHIwsSOATETVMMjS74IHGPTR9 EGO4q3//cDNxr4LL3KZMac8NzIKSRW4BrcsrpD77s88QjJCSGpJ4Cybfu7S8ujve L4CSwoGMxMI7vwh5c5tHdb5bj4zHBg9Mffsn4KObMQnKiw0kuQI6OUh2OYSZJ/sj Z9Byx/8QWCuB5Fz9E8y/dPMK48tfM3OTVVcHBvZMsnvJvBcHjSf21j7/9cpP17yY BM9LKBOdLUqXBkENXDIix4FRM+zjaEIV38yqJOgiEtQONJ/zq4S6O6fsYblkhS84 42aIjIHalj9c3EqejyTWEj2hxZI1dOCXNu/pHj6Eb48G5L9pTMwYxhxuXqxtDfu4 qwYyu+19mmYDxD0rIA5v =wDME -END PGP SIGNATURE-
Re: [gentoo-dev] The Python problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28-06-2011 07:19, Dirkjan Ochtman wrote: On Tue, Jun 28, 2011 at 08:54, Joshua Saddler nightmo...@gentoo.org wrote: This would be nice, but unfortunately the python maintainer forced 3.x on everyone, despite the fact that nothing uses it and no one really wanted it made the default. So now it's shipped with all the stage tarballs, in addition to 2.7. You've got it whether you want it or not. This is one of the things that needs to be rescinded, along with the python eclass changes. Get everyone down to just one version of python installed. It's just slotting like everything else. (There's an open bug for the stages.) Yes, but with slotting you allow different packages to pull in different slots of python. Furthermore, when you slot a package and mark more than one slot stable, you're saying that all the stable slots work and don't break the tree. About the stages bug (330361), as was discussed to exhaustion on the bug, mls, IRC and many other locations, python3 isn't added to the stages by the will or work of releng. Cheers, Dirkjan - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOCb93AAoJEC8ZTXQF1qEPurcQAKj3i7pL22kd2EpmG2+tDdcg us3xE2dQofp6hVkiSkz6LVQuyCEH9QV/jujSkwYJLVPDsGGyXzBIkUGA9iLc2iDQ nJx2r2QqZe11CxOuyd15AomVsLDazDGq8mxkxIBzJl9l9xS5HINqL+D79HxiOsdE oraOL/cr4tbjDLWgraLZMXM/QPUkhqXkQurgn1uF4U4TAkvjZessJwe2Csi6raUW xhJ42HAF+Q+VpFuTlBJfJevNsXnyHR4y6qM4xFF5X6sIyPodz3CORfHBMAXrU/pX MCsMSPRJQRIAc26tEf+V4WJuUsp+yaydejPnEiyZSnDBDmgeS7zgEhQRLAPf+//Y sMEMqchTAkwS4gxyAyl6AoR3+DFlGZdcTmn2S+AbtQNH318Lt3yamGbwRUMpjUHX p8YXxsjL6iigyIUaJt594W1Bc2gS6ktkQGUqERLvM0dYUSoQcZJCeWq7y+qO/3vF uukqOnljgSEvucijeHUM3623ImgpoCw3tzw7UGz74PunqqqL37op7FxX55exyYWw TjzDqFEPlnaNQNvD3E3dZdU+/KnUlmn9Jtbxv/o04unVfEFspGP9DeuZYUOolWAG 86LFsL9PeSGLhqgxWbFjMR4lmznilnlaaB+4MmEtMV3K3FGdsI/68dhGRNe+oEC7 8JTT1DDZpunk0coni/f3 =aUwd -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26-06-2011 12:23, Kent Fredric wrote: On 26 June 2011 23:40, Rich Freeman ri...@gentoo.org wrote: I think we should avoid changing the fundamental design of portage, such as removing categories or allowing tags to be used as dependencies/etc. At least, not right now. If we set up namespaces for tags that might allow for such a thing in the future. At this time I vehemently oppose the idea of using tags for dependencies. If there was even a good reason to do this, I would probably want to see the system working really well first. The main driver behind tags seems to be searchability, and I think that is something we could easily improve. +1 I don't think we should hold that up over an initiative to completely re-architect Gentoo... +1 I agree with the above. I've done my best to stay out of this discussion until now, but I see people going so far out of the box, that I fear if we were to do this we would end up breaking the box. - From past discussions about tags, I'd also like to recall a few ideas that have been completely ignored on this discussion: * tags should only be important for searching or classifying packages * tags should exist beyond portage / mostly use an on-line system * tags should be usable and maintainable by users * users should have a way to contribute directly to tags That's why in the past the discussion pointed to using an online system that users could contribute directly without having to wait on developers answering their requests, why it was seen as a manual system and why it didn't affect the package managers or tree. Being able to combine tags on metadata.xml for the tree and overlays with an on-line tagging system and have the tools use that data when searching seems an interesting option. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOBy3dAAoJEC8ZTXQF1qEPrJkP/2HhRwwj4GuhRyz7bXi3g9/U osmGEKj1f7dcLLCGNiS9AQ6aiCcOREXtq2uWkiMJHhILqfhm1bTLI/2OF7Vcmslh ImE5KzDlBfITb2Q6KxBppDfCwgYzclVKqMtyaeLq84O1PSmUn1tEaWaHzXlkVHI8 Uiae5rYSq/ikfbt1wQXXwQ3LBcgGbjfr8AWGvXTdnB9drGoNCezEfQaizuTuN6ib 1DmVj9MiHiQ+9+ixSCzJGJ7XryfEX1qEdWkn+rGqmN9CXXBQjjXOvHTVhIHbixQA 6+LWrVL/qjrzCUZ6Nsapgb5SbK+BQZoHD01oLs2Em7gum2+K7Z+gIiKVN5rUncaQ ExcIyOdnyZb8dyXYR/purSTEuTJv2vM6z6/EbV3XF4NsKfY8DQRq5x1h8+6ihMzE G/UT5Hqg8px0hbaWe4fHGNUzPaX8meu791Kw+GJd27Z2BJaZjP8VK5NSk0S3Y7XM SE0PNMdgLPBfcTK2Qw5WisH0DPwzfFWUoulCfvHGcZ/dfYC3SuideCfouHgkE8rT K7Y45c0h0A9QhEDSjRG3NFQzNU8tFfYvM8uy0GZr81SVMA1qFLvlVWR51kyGs/of a92wNdW0HqyN6nXTRLGcj8lFnv23Cqy0yi7Ya59Vkh1O0PMhIzl4GyghfnuszwYe sXzbYFYbsOMfY1tI/XCZ =OJ8M -END PGP SIGNATURE-
Re: [gentoo-dev] SHA256 and indention in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25-06-2011 14:23, Nirbheek Chauhan wrote: On Sat, Jun 25, 2011 at 6:16 PM, justin j...@gentoo.org wrote: Another question, do we have a rule, how the metadata.xml has to be indented? Tabs or n spaces? There's no rule, but we should follow the same rule as ebuilds — indentation should be with a tab that's displayed as 4 spaces in editors (no expansion of tabs to spaces). Talking from my own experience when doing retirement stuff, there seems to be two large currents on metadata.xml in the tree, using tabs and 2 spaces for indentation. I personally prefer tabs, but I also like using EAPI=version, sorting everything alphabetically and even use the following depend blocks: *DEPEND= !X-2.0 !Y A B ... Z a? ( X ) b? ( Y ) c? ( J K ) As expected, I'm sure many of the others disagree / dislike at least part of my preferences. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOBkXrAAoJEC8ZTXQF1qEPjUgQANBsE0uhZPR0Yqlmh6G4bCpo F+IvN0PbMcU35tjy87jQ47Y4dCg9mCQftPe1uPt4rtmc1Sww/ztqPdlsXJdi4nRQ pnVPnJdds39hYzmc5rOjVtsyZOKLH92J7ytVom9AiuO7DqxJvs/A6q/sj46E0KBI MSUHvSNMH+aq6xGVyQ2lTRAUXUT83bkl3BOrxdPLApgZvteF+fDKHUIviLoQA+wO VV31Jsav+IIa3KNmxmiF6IoWZFeCLyVlwMJDHp0r23Q28n6qDOoKbWjpwQBwGPXQ 5a/nLKHRTVStzy94gqqCSlNyZso4KjrC5JAeadHiAPisRGloJUWB12UYN/Tm/4CA KfA4Myvk3Aclr6BGnUQ+DeX+r0hKElHwR60XqkebTt04dcDS1GylV1IpJjpHt8dZ j2Btz6HdZKzDTRabCyaaOk2UaXAYtN4KjkaWepKHauR73XEtLxs8YY1gc+0T3i4Q pbjQJfGCP166b/1hS9Evr5/oAcxlDlSRHL0773BowrX/CGpKTDv5bv+9Gm3skiOV Zd89MomsoV++QUTcXe1i7m6XAYyHkhf9doJl62t5LlflQYE+UIb69HnhdpdHQdfw km55lo24X4lvxV+nDz26v+fi9mHqlJ4TNxZaQ+6PnvrI4K862biRz+VlsSWcE5ay 1nb/tuwZ0VlfQvUh5TES =wuC1 -END PGP SIGNATURE-
Re: [gentoo-dev] systemd project created.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22-06-2011 08:02, Michał Górny wrote: On Tue, 21 Jun 2011 13:48:44 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: Is there any particular reason to create this project as a top-level project? I don't see why this shouldn't be a base sub-project, like openrc. By the way, base/index.xml doesn't mention openrc sub-project. Is that a feature or a bug? In my opinion, a bug. Someone needs to update the base/index.xml page. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOAdS/AAoJEC8ZTXQF1qEPTGsQAK850lJ+WS2CMGBKZCkGNF1E bxOMLV8FbpavOu3CpITvpEQfnoPzJi3/k32btwHOr+Ixmbp7qmVJRsRgkg5fBw6e TuQ1vqnnrmC5QjF1H0k87H3bma6Zn/LjkXpamKfIDla2C1z5nhjeHTa0PXcohXB1 1B3KOekVA4Bxy+zXsFrn5oBaeBGs7ZFhljFNkYRJTYu8Dx+AxO4ZWNQGMS4fBTES 5nERS1mR43HXExWR22p3jdf2CrZPzvr0/Em/AjDuc0pl1JSgVar9hs43t72ir0Ci Xri45vYYfV4LZIeMnPuhIQlKhOSnPWlDBhXNd2Bph5liT2CLF/ad3bgCjKSjqh8q LX6DpcDrT5L0pcAYbDdaCvtsFPDIeWTkQUJZSiTS3PtWiI0XsIO9jqx+txzrfWL3 XwjOu37TVZENG4rab4tKsTI+ntfjxxnOOJJNHSwdO6iBP3YDdjsLba5iYzP6ORbf Q59spzlZof6CZBCOLBBFWTPwCkXUuWl6j8W0TTUZrB+o3lKXP5pde48XbQQTXjmy i2ZLsCLg0+E2oAdEYZy9VO90kFnxOElW39dkMujgyjJ45FR2scE8J7/zPMT0WRkr Bm+h8lHQsih56A6GpTU1KAmOdRyLGRwsnfPUMXZuW7F+rXxvzbq1D/oqv3jUByvf Fc31Gw06kr7ocbnI+b5x =GRVH -END PGP SIGNATURE-
Re: [gentoo-dev] systemd project created.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. On 21-06-2011 09:43, Michał Górny wrote: Hello, I'd like to announce that I've created an initial project page for Gentoo systemd project [1]. The main purpose of that project page would be keeping docs for systemd users in Gentoo. Hopefully, we will include some soon. If anyone is interested in helping out, we'd be grateful. We won't be probably maintaining many packages, thus I'm not adding a herd. We can be reached through systemd@g.o alias though. [1] http://www.gentoo.org/proj/en/systemd/ Is there any particular reason to create this project as a top-level project? I don't see why this shouldn't be a base sub-project, like openrc. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOAKE8AAoJEC8ZTXQF1qEPfAkQAKuy0gUlQ/FX6UvcAU2Oky+c VfnauAj+UaQJtiV+BDtblxEDerPg363W5F/kgCJOFPeX8gY1eFRHb1lnGSFAqvrP 1iDngdzeBFOS5lIUI/15/QBi8o3SgMz9TEaNlplns7FoIJKVENQTCMh857YnWPGL wsGxb67lba5PoDSrt7uiJeV2yttpgJpFBT3WIU6NLfreYbxJkbA0o37VabUvLf1s x5idk1wmYOv2I9qTmwCr0mjBODPWLhD353fyzuYpRFV9FjPha7kp9+k7K+6FFliU AKX1iHWBI8nuSF4VlrCITNcVut1erYpMIej+n5yGcMjb1SO/TDdTzRo8XYitgQM7 96xNQHye5GurLrb+FWgH/Y8HLDAL59yvqf4exF7WToa4pvDmZKttq8+EZY+0Mqc7 zaZ6tmMlnE5vIPPMdXrwNfqR1qlK8dBv8Sj4HZoxL8rjwfKU52QjbVdm2y7aZxtY gcXpwd/29Oork8/DPOI+fP3zt+wt1rE69r0YbFLC0tmwIfqp7eOZWXcOgLOrldw6 6H3ztgEcSiQbmLax0U5uOwCPctj5gv9NjTTwsarLAi/6/ryN7qzGC11zJBxXHKf5 56vk0VLvk7Qp9kVB7YymLsmTnaozkFLWf+fG/2OXHpQhYqQLHle6WmpOgQk6OxOu X12ODeKoDPj5GALi8eKQ =lZoY -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-06-2011 20:48, Mike Frysinger wrote: On Saturday, June 11, 2011 16:24:00 Ciaran McCreesh wrote: On Sat, 11 Jun 2011 15:58:43 -0400 Mike Frysinger wrote: So, effectively the QA team lead can appoint the people who elect him. I'm not at all implying that Diego would abuse his position, but still I think that this is not a sane situation. it does seem trivial to remove people who disagree with you and thus cement an echo chamber Are you talking in a hypothetical future situation, or has this already happened? If so, can you point to an example of where Diego's been removing people for disagreeing with him, rather than for disagreeing with the Council? how is disagreeing with a Council decision valid grounds either ? punting people because they disagree with any group isn't really valid. -mike It was not about disagreeing with Council but actively going against an approved policy when the team is responsible for enforcing policies in the tree. This is why in my proposal for the review of GLEP 48 I added a point stating that acting against established policies would constitute ground to be removed from the team. The point about the QA lead having to approve anyone wanting to join the team should be evaluated with the background that the council will surely pay attention to who the QA lead accepts or refuses in the team and that if he acts in an inappropriate manner he may be subject to a devrel bug. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN9piSAAoJEC8ZTXQF1qEPI8MP/3reALc0xY6JXhOQ1mIDiDjh tugb3K7DYxWn4o3g78CBc1EDjZG+WTnoNTvhBC3KnFvdR2jCyuTyoxTgrdiyMCBt Z92klv9fWYwn5IgjRXD3PthG//uen+fpWS5BAvL9PjjeqiR5WOGlfavqbutsAvmy 7zCerkrNgBIzUyvgDBTRMcnftNMwbXu/fOtkVp9m203KjZuvzge606OKBcjiKYbG uZ+Vw2pMfvJ0MycoRdI3a411/RuouISpRlWKoQR6QpFtgago9qf4Gx4MqY1qXaV9 2iY/fBAau1AmVy3IAqFDG1IvBM1QDr9C3wuGqX2nlLQF8V+3BazIputV3sqYhxwd scxJSzJlH+SMnO5+IkyR2Y7WaW9byIQb/pV/weIxfGqEoXmx7kfVSyal55rwLTYF Yd7n0Y8RtHZswYCIxYpZ/kTAlJDl+lpMIJ3lsu9CIIrrc6SgWrQZL4XVEM/CkdVl Oi5VH/6XQrYaVYF53lHPow7LWeRMf/eT/1ZRy164Gsp3x/G1t4GfKYS8egiMSqAy 6TF0Le/tJqBreanwvihVJRas3D27I74//0asIQeu9jgxRnAvaWOvMx5uCFTMfr5k E1rt5Bl7i5qRLs//hA9MPEGa9Tywx5muf9SQ3BH2D8jNlHcOWdDUntylcU1ZTeOA D9Ahs1NzxyQbOzxvTQG9 =QNSu -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-06-2011 09:23, Markos Chandras wrote: On 06/11/2011 03:36 AM, Diego Elio Pettenò wrote: snip Il giorno sab, 11/06/2011 alle 01.48 +0100, Markos Chandras ha scritto: Maybe I scream in private, but what you three (keeping Tomáa out of this) are doing is crying in public because you're no longer allowed to poop in the sandbox you should keep clean. Do note that it was even your words: I am sorry but having elections every few months is not a solution. First we need to clean up the team, then become team, then have elections. Which is exactly what I'm going to do: I'm going to make sure that the team is on the same page: policies has to be followed, or they need to be changed. Which doesn't look like either of them (nor you I guess) want to do. I'm pretty sure I didn't ask much to the team beside actually following what the council decided. Finally, I'd like to point out that neither my character nor my actions have changed the slightest since the mail that Peper quoted yet I was elected as team leader; it looks like though people wanted me to scream at anyone else beside them too easy that way. And the only two people in the team who bothered to cast a vote (Luca and Christian), seems not to have an issue with me keeping this way. So, this might hurt your feelings, but I'm not really sorry to see you leave. As I said before I had been disappointed when people I had a high esteem of decided that rules shouldn't apply to them. Calm down please. I don't scream in public. I tried to start quiet a lot of discussions in private before I make my decision. You are right. Retire is not a good work for the 4 people that left. Maybe gone is more appropriate. But, seeing your tone, it is very hard for me to even start a discussion cause everything leads to personal attacks, irony and Mediterranean temper that we both have. I lost all of my motivation and energy with Samuli's case. IMHO, kicking them out wont improve anything. They both agreed to follow the establish policy after all. QA team requires *active* (do note the word) people, not just people with high respect to rules. You have to admit, that now, you and Dane are the only ones who are really *active*. Can you two really handle the QA load by yourself? Diego, leadership means that you have to motivate and inspire people. People need to follow you not because they afraid of you but because they admire and respect you. You never really tried to talk to us and get some insights. Everytime we received a mail from you it was because someone has screwed up something and you were mad at him. Please, just stop and think for a second that you *may* be wrong at some points. I see Diego's actions as cleaning up the QA team. Some members of the QA team have left it because they got tired of how some people in the QA team would not respect some rules and do everything to prevent QA team from being able to enforce them. Unfortunately, Tomas is not the first member to leave because of this. If the actions of Diego make Tomas and the others want to get back to QA, I'll consider this whole issue a success. Markos, the worst thing that I, looking from the outside, noticed about QA was how some members were too quick at using the QA hammer to impose their ideas to others, but always found ways not to follow some established policies and not to get them applied to themselves. As a council member, I am very happy to see Diego trying to fix QA, doing his best to enforce policies and caring about the tree not being broken. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN82rLAAoJEC8ZTXQF1qEPoXQP/22xC9pQmuO47Tavg+mpOiMe Z59O7GGNb47sJb9am8+MHh4r1tP1W/KvMNsb8WzDC+OsqMjfKmyOOjOfyg5xK+VY US722Xj08L3js93qVJs/fI4jsa0GsBZBpdDoJrAZmRco3i42W6mP5KneOyMD5h98 uWnUFP8f7e7qy69usio05gIqn25SCDa5QT3BIL/OB8j9VPLPzdw66Ps41Dvp+u9q JRUXv99oV5WsOauducSz7n2K71RP8bh5mUIMBI01WfUk9AWpzFLlMy4SMQMKatNY Xsm1eJsn4yM9tKzWjTVn8D5rsjnb7zAYLoMPj2Mi5hkSrG7MOZ3X2rFx1PTFwBdi ikkqe8SrK/+otbl9BZG2nw2Oypw9JwlnLf6XGyAeykpz66IOfwZzY1aUIc94LMrb LsJTuDqpEMAaN32Sykt/VQicZBnUTDoWfF70GH1lFFXYC99/YBiqnQuR09w4y0iw U7QZIf1YDqmijDxbnwJeIQN9vKrMm6HZrbeN0YFmEi+MRmp0BQUEDje3vtl+ogud H2iDzLcw3bGkCNJWaRUY8Yl3cS9YuWqA1R5p70gG3QvRmGfM9H9kNLvqD9w5Dn5y HRQg+U6e7cpDA9vcOQTIRZ2ntPEuBoir907sP/dp41XGrffqjsVmzBjBFSKQB5KV 82g/eiuhMfjAVwksTCSP =Pgv4 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-06-2011 16:58, Jeroen Roovers wrote: On Sat, 11 Jun 2011 18:13:14 +0200 Diego Elio Pettenò flamee...@gmail.com wrote: Il giorno sab, 11/06/2011 alle 17.33 +0200, Jeroen Roovers ha scritto: Reading all this, I kept wondering how you think your self-appointed position as team lead (look how I'm stretching the definition there) is still tenable. Good luck there. I'd suggest you to know facts before slandering your fellow developers. You mean slandering is morally unobjectionable? Never mind. I'm *not* a self-appointed lead, I've been voted in. Why doesn't GLEP 48 mention this process? Seeing how QA is becoming this monster that regularly upsets the majority of the volunteers on this project, and is at the same time grabbing power left and right, it is important to have this set in stone. Jeroen, please re-read GLEP48 as I updated it at the end of the council meeting to reflect the changes already approved on March (txt version, I still need to update the html). The GLEP states that the team lead shall be elected annually by the team members. jer - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN87Q1AAoJEC8ZTXQF1qEPHUMP/iOvojC5OELqh2qRD5ZevnWH 4GxKOPPlc9CyQksjGXUFKvFSZR8K+9joA5ZCsSbWu0Z/u9IrbP0ZgmUoxu9f29H+ DjoBBFtcLPPZS+aW2StnH96Lm6bmU2j/VR9EmRXlS3cuMu+RafogSNluLetaQgdg yXesJfMkXcyGU2msmk/eyW9JzyV0c6lbS0RiVqpMAItEqWlQod4q/1G8kWtYCYnT 3Y6seaxsV34Giw4jKg4wqAZ2bg2LSmQDT7k8MpAZnDn4MTO+WmpJChvuHLjKLWzK THnth5PPsaNU2mvbgTrskb2nE1zvhMm7MFXyryX+w9Bh5ZWwJb8YMvO4xFE6YNpW 0ZMir0JubZjaUoMQiLykbTeIo1Nwaw+HXlFsd0vnZSkXfc0452YXWjLEuHJN+fAD WdIuDjox0vJojQbB0nUikHUL/rCd/K1qBlDo7XzAsJp8WlZrbwW34O+nVDPDePm5 ej++8a1msa3atlFWUbCnBL5ufQpDCSz/FO4Z0r9Qhb6BZNZSXtFfOdp/v+bbgTX1 UXtfHJ05olMNe2WrSWOLxar8b5MYLxT46ekOcyUsLmcPVSEr64Qw7rQDb+vERzXu gMedvSyJnjSXFeDE8PMejEt83mOV0SttjcNxYe5BxpM7WJ0me5TL6z7uzhZoWJUa 5m+nypN+cNUlOqusVQPB =VJXX -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-06-2011 15:34, Ciaran McCreesh wrote: On Wed, 01 Jun 2011 18:27:04 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Wouldn't it be better to just trust devs to use common sense in what gets into ChangeLogs, and actually be grateful about if they take the time to sensor the crap out from it, and scrap the whole topic? This whole thing came about because a select few developers repeatedly refused to use common sense, even after having been told to do so on numerous occasions. Unfortunately, common sense for some developers is running round the room whilst waving their wangs at everyone. I had meant to send a reply to this message yesterday, saying I agree with Ciaran on this. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN53JUAAoJEC8ZTXQF1qEPr7MQALJKKNmx6McM93T9c5IepKGJ k/AGcpbz6V1JRxzLToZigl6ChoRCfp1jIIE0kb8sr9l4R5BpYaIkHyO/o5+uDq/F cg49IJc9A/syfacD8dcf+5ueLHQXJcZjgreok5gKGjjnrdayntc6ZHFgH569BtuG 8feC+iSa/5AQ9XBQ7JjTNlgblHCyXC9h6YTHOkYCENJT8zMhH0urTZqkrv3oNNVl RuqsATeyop5aodht2XSlPoNnvJyZOjTo+ZTBfH+pe9q3Cx2XIR8MkPglqBoRucDn RvPwTjBZLhDX4WyznDjZAZjk4SRU32TvSdxRH0TAnoTmEl/bBeUPB09fWuw6Go6j cIbp4zAURYBE4QfxjKHG7J5Zzkk9A9YDX/2eDAHPepSnJKr0cpSU7O/lH/SMLpqo 4Cgdo9b83ElyK36madmXYB92S0tMycwWhjJaK8LNODKToLaPvjy3D3dI0iUIKBvn Sj8WRG/zP4wNwoN25EPSPfArBoVsXnPrl8kIJNpdX3lHzBz7CHdDzFd95dzC4opH sEVqNEIpyAHfgaXioVOmLgeJyuK9Hr9M5kH5QQpZCuKM7z4AkiVJaRJW8LdpgEMp 8P2CBTKyL8KrFDFw73SRsdt7rCAM28Ukt+HZLbsIOvwGkiRZB9JLy+TzGvvwpJTf MwnHIigHpPdjbuknKO97 =x5eY -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-06-2011 19:50, Nirbheek Chauhan wrote: On Wed, Jun 1, 2011 at 9:54 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: So we come back to the problem being *CVS* not ChangeLog rules. Well of course we can just tell everyone go look it up on sources.gentoo.org. However, this is a different discussion. sources.gentoo.org is a much worse (and slower) solution than cvs log. The main advantage of a ChangeLog (and of git) is that it allows you to check the history locally, without needing access to the network. All this is such a massive waste of time. Can't we just expend this energy on the move to git? [snip] We're not talking about future plans here but about the current situation. And about how to deal with it. The current situation is: (a) Not dire. (b) Not urgent. (c) has irked enough developers and users that people pushed council to update the policy about the use of ChangeLogs. And if we decide, hey, let's move to git instead of having this discussion, the current situation is also: (c) A waste of everyone's time. So no, future plans are not independent of the current situation, and a move to git *is* a way to deal with the current situation. In effect, we kill (at least) two birds with one stone and prevent a lot of argument and bad blood. To be clear I support the goal to move our tree to git. However, I'd like to point out that simply moving to git will leave us in the same state. Assuming everyone agrees that git is far more useful than cvs to check for changes in the tree, a simple but important issue remains: the plan is to move the development tree to git, but to keep the rsync mirrors for users. So the move to git doesn't fix the issue for users or developers using an rsync tree. One solution that has been proposed before and that was raised again in this thread is to generate ChangeLogs directly from scm commit messages. That is already a solution with cvs, so moving to git won't help here. The same objections that have been raised about doing it for cvs, not being able to use different messages for the commit message and in ChangeLog (something I understand but admit have hardly used before), are also valid if we move to git. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5stWAAoJEC8ZTXQF1qEPIPMQAJOBJxGkWJZ3saNdQvAjbR7l KQdLHbO3IdUTBixqSqnmBXop4d6XFBd6lZyjiLu29x9xBn68wE4gm7rlpulITs6R Yqh4ASyLkUF88qezmqdkBaIy/TUGpGS7ZQWMu7ViarhPtLpcyrVWIh8U0T7oJZBh offLYHiQK9dDajLro83aIGLfRlLEYTB9MhjHegv8sDTUCr+ti23OuKjO0CoI7LFx yYdnzkA1YQWA1MGj6iEAVHzcy+RsaGK1QfVn26qAyly3Mg4mPkbKjtIHUEleIV0X TiWPQfNOvPbbNNyuaJ2cBZoGSTLtTstwUKMccYspQawCpDz0h2yNxNLtVS5ws5AO HBvfuWROKtWQ90hSiHb5dy13KXhRYR0CZzGPPLMs316YzdsFtKRL5AG3ywzLT2Bu Dj/wiUoRIRhoPuBTRskCxmXBd04nE/MtDZM/MRn0OZE9zHeYvZYIqCtWVXaGejtZ uID3LxOdGvJn07+TeH7/i8ap4zchRvwZaW6H9LBFr5bIHzKEFPUAfL3NqquGj66d HOHsh/RdPG25gKAZy5/zJ92lsRbFyZlxZFNYoTBTSFg89z7YldPMMxPPpNMWro+n ZzhyourKYprtt2+ZI05gPB/f24KMBhZY8kALoORSeNpUxBwTQ/aanpbKKqjFcfuv j0asDqRgkHAvpF3aTmaI =cSzK -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-06-2011 22:59, Rich Freeman wrote: snip I think the problem is that we're getting a bit legalistic here. I have no idea why we even needed the policy change. IMHO what should happen is: 1. Dev does something significant and doesn't update a Changelog. 2. QA or another dev calls them on it. Tells them not to do it again. 3. Dev does it again. 4. QA or another dev escalates to devrel. Devrel deals with the issue, resulting in either a dev who takes the rules more seriously or one less dev. What it almost sounds like to me is that step 4 is breaking down. Perhaps somebody is arguing well, it isn't clear in the rules so you can't do anything to me. To that my only answer is sure we can! Rich, besides a disagreement on how to deal with policy issues (as you can read in my proposal to update GLEP48), the issue here is *exactly* that whenever developers or QA warned *repeatedly* the people that don't update ChangeLogs (a very restrict minority of developers), they've always tried to find loopholes in the policy and argued others had no support for their request. About step 4 breaking down, the DevRel process would face the same hurdle as the above, but then there's another important point that people really need to think about: Do we really want to take all technical issues to DevRel and in the limit fire people only for that? I'm not saying that technical issues aren't relevant for DevRel or that people can't get fired because of them, but in my experience the role of DevRel is more to evaluate the ability and willingness of developers to work in the team than to fire someone because they failed to apply a policy here or there - to be clear, I'm talking here about mistakes and ignorance, not about defiance and disregard for others and policy - which in my view constitute the sort of behaviour patterns that DevRel is meant to evaluate, help fixing and, when everything else fails, to remove. When it comes to money and taxes we need to have pretty clear rules for legal reasons, but when it comes down to expecting devs to be mature and team players, I don't think that we really need 14 appeals and a team of lawyers to eliminate every loophole in our policies. If a misunderstanding is genuine then everybody should get past it quickly and maybe we update the policy to be more clear. When policies are flaunted despite explanation, and the authority of devrel or QA or whatever and ultimately the council (on appeal) is questioned, then we're not playing like a team. It is amazing what intelligent people can fail to understand when getting something they want depends on it. The sad fact is that increasingly it seems our developer base, or a significant part of it, is losing all common sense. Just my two cents... That, and in the big scheme of things this is a bit of a tempest in a teapot but I do share concerns that QA is an attitude and small problems today just lead to big ones tomorrow. Rich - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5s33AAoJEC8ZTXQF1qEPFEcP/2tLhDBXR24AF/GunN5BHKQy +fganpXgO1OqZcFX6tEG7h+j6fjbSFwTPaNG9CiSyrz/NsYseuL7wzkxXZawfUax ftiaFuOuKvLd56AizO0y0YNfrvIVxp2rTPas17yg+Noqgm3Hd5voh2J9FkN3x8X9 PPd8yA8f4DXA4ptdihGS694edtDtT2WwMVGbPuGl6I3U0tlLYlPyGoQDRaAhvQoB LnOzqrYxFxDxcEUWyae25dp3DI1rhqWw8cUc1We6lOZENOtGxiLuxToIorVB8lAs b3SB326WI5XJRyHWgWtcPkF9OrQvpsDXgO9YEqBbsXn3w6vsj2rD8IeswMGNt66R h4cmHEwXEyZ9iQPEPwJKi/UI6MZHTM5ezYJDAbBxBuLt5dPuR7RQBspHkyjSSFe8 /RPLDYy0UYnh0uUw1Rq7DCB5rhLf9acnGhT247q+5PNMcfdN3aBYPIK2ruqTQGKD SfNefj0tKJCXd/TsQUSn7GP7SLjiBNh7Ym+qy8Q5TFQs49vhYprbqRn6RdsMpPe6 eeHNiNzSw9Cfi6n/ZidHlvOXUM7g2yVOLzJ9ChzZRhftxABMWMJCzYvQfjE6Eqey +pVX372nI2G9e9UErS8/Zfxxxw/+vOE7DLLYKe9HSXeM3XdNwEzotdcN+Xxth3f/ R5tVPjMUL3TACOcqA/zr =vsto -END PGP SIGNATURE-
[gentoo-dev] Council 2011 / 2012 election
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear community, as promised during the last council meeting, I've checked the logs and emails for this council's election[1][2][3][4]. The nominations for this council started at June 5th, 2010 and the members took office on July 4th, 2010. As such, the election for the 2011/2012 council should take place next month (in around 2 weeks). Roy and Robin have already volunteered for being election official and the infra contact for the upcoming election. So at this point we need 2 other election officials to run the election. If you are a Gentoo developer and do not plan to run for the election, please consider helping to run it. Expect an email from the election officials with more details about the election in a few days. [1] - http://www.gentoo.org/proj/en/council/#doc_chap5 [2] - http://archives.gentoo.org/gentoo-dev-announce/msg_bb83f25da678841fbe62cbefc18bc6fa.xml [3] - http://archives.gentoo.org/gentoo-dev-announce/msg_99a0200839932a93304dc202bbbac8a0.xml [4] - http://archives.gentoo.org/gentoo-dev-announce/msg_a9fd36a3292204abdddac5b0f6a4926b.xml - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN2IirAAoJEC8ZTXQF1qEPyEIP/jVoO0vbljx1QozdfH2OVHiZ HTA5TEs5ptSm+aCgo9Ie7Yd6EiDfWxZh+yeTH8Edw8R3NAzU2hIdnKCXJW/KS+A2 ZZsiREtRngGUl8yAqk8g6tTSreU3fnYbEZjqoHBGB4NEo1+/qKYZpNlSDX4KHkZv A3cftE9JqUPgHj5X6a3aB5GNjPo7/5dBPECc3ThbeiXWBj0sPTgTMN5D2Q/2lf2X 3hVmG3+cHbmjnpBQugifxaES/h3toR9Wt38Nnn2huEwvrHt43py3ff4jSnMhWDPb OKZjEYHPAvxWIFC0q59iYaGR4m+Gk6atHVE0o8pc427fa5zZ6s55x8kG0d5n1wpR GRcKlicIklswSntiIfqCEJdkrFqYYahOEyH5i3+kkHPn2tLbDymIcChfnJEhX40I rrgDGHq1YHJ2ab1sDeQtypQe640zs1/dCBim9DsFIEUqHhnbnqjmlrKqNLTxCNK6 Y9HRPEqel8e1nWI/NySROvLLR69t3aLEEkC56fn+Aor5xoxFD/r70ol+jEOYziyr d5Wt9rM7lsl6rT+KMrj4Q7yrDOmExF2dBI0Bzo27xwNTmph/l+0aqBidavOiczQN 8OwP0Fwi3gIvZ4ipr6wlvASSSVRpIpA8dd5a7Ls7sRz8lXqVzlsCjcDZ9klhkQt9 WfanW/MCbgr6D/SkeM5M =r7FU -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-05-2011 00:20, Samuli Suominen wrote: On 05/17/2011 03:15 AM, Samuli Suominen wrote: Let's start with generalized example so everyone gets the idea... Reference: man 8 pklocalauthority /etc/polkit-1/localauthority/10-vendor.d/example-udisks.pkla [Local users] Identity=unix-group:plugdev Action=org.freedesktop.udisks.* ResultAny=yes ResultInactive=yes ResultActive=yes The above file would grant permission with or without active local ConsoleKit session to users in plugdev group to everything udisks handles. Notice that getting active ConsoleKit session you are now required to use PAM, or Display Manager like GDM with internal ConsoleKit support. Note that the PAM method requires you to have CONFIG_AUDITSYSCALL=y support enabled in kernel to get valid sessionid string and not all minor archs support this kernel option. We could have similar .pkla files also for other stuff like bluetooth, networkmanager, shutdown/reboot, suspend and hibernate (upower), and the list continues. The benefits are somewhat clear, things would work out of box for remote users beloging to right group, PAM-less users, as well as minor arches. The downside of this is that most users would propably end up using this as workaround for inactive ConsoleKit sessions that should really be local, but the user is just failing to configure his system in proper state to gain it (launching the X wrong way, wrong kernel opts, ...) And if we want this, should we stick to generalized plugdev group? Or perhaps group wheel for shutdown/reboot. Group storage for udisks. Group power for upower (hibernate, suspend). Group bluetooth for bluez. Group network for networkmanager?(Just throwing ideas...) So... any comments before I just pick what I think is best and commit the .pkla files (or not). I'm really 50-50 on this... Would like to get this decided before p.masking HAL. As others have already mentioned, I'd like to have the option to live without the *kit mess. One of the nice features about Linux, and Gentoo in particular, is being able to understand what's going on under the hood and the *kit movement seems to be about magic and not bothering users and not about being simple and clear. Futhermore I would like the baselayout package to create the groups decided here, be it wheel (already there), plugdev, or more fine grained storage/power ones. I think the distribution policy (be it the general consensus on this thread) on this should be reflected in there. And it's the most convinient place, then packages don't have to worry about creating them... just follow About baselayout default users, we should split this topic to another thread as the releng team also needs something along these lines to get new stages with bl2 / openrc to build[1]. [1] - https://bugs.gentoo.org/show_bug.cgi?id=53269 - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN0m8GAAoJEC8ZTXQF1qEPpJsP/iMIo0RSFAEerpPH+6Mi+5QP zrw26lCyX6palAFxFfthueF7hT9ARsLdJSx8p9ERMS7BBrmjKk8bnq20vm7kNcEC mcohegWYr5cxe51YofMjPwRTbhpSZRJYrjYeUGYz6xZ9X85LlON6UA6331KTcklb v1qewoalKn4lCKykBmd2xAj1ok4VshX4MgxtZJsMJY+eqWITUou6RYJfGOPYn/Hh qvNLDoxdlyszJeD6aCi5xLK2tLTVEfVKO718jBz4EKOOk2jatwDi8ojRCUYHS+Mp pBBdfvOivqgA1N1c9MOHf7z2vllVao5h/PckYJEwnff828SE6E9Ox/DdBbETBkfV jDCwKmec65kSJ4bVcCtr0d2QZcUNq57GX1mrCoaPHKRSETiEW1TCf4Fw2to0kbbo t9x5Je+sAs4yAHMnD5u1mnQqkNjXkJ5MS9GFPyoTYQ1rux5zsSRNWSs50/ihKjL4 QtHafz/xYUIoCM4bQ2jIuf+ZOxVJ0SLPwaeYQGWZQOteLDhtqBI7UpWAPQNUoRYv AxbgokNVwIcvhkjfi4iljKPPjD5jy5vlAUIPx1uanTIOE1ZdYsYg8fO0OxOhAz5H DS9b3xrXGednbBSuvsqygbnJKQQpD3r5ca4nXFz/1YjDOCq7OM0BjjzMRkaU0jk5 eGf9UkN3EHKkIm316Ges =UGFI -END PGP SIGNATURE-
Re: [gentoo-dev] More bugzilla restrictions should be applied to normal users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13-05-2011 10:10, Markos Chandras wrote: On Thu, May 12, 2011 at 11:57:26PM +, Jorge Manuel B. S. Vicetto wrote: ... This topic has been raised a few times in the past and as far as I can recall there never was a consensus about it. In any case, as pointed out before, some developers want users to be able to CC them on bugs, at least on some bugs, informed users can have a good idea about the importance and or severity of a bug and in general being more open can provide a more inviting environment for users to look at and or contribute to Gentoo. First of all, I said Ccing Arches. Of course they should be allowed to CC anyone, but ccing arches creates too much noise for us and quite a lot of them do not understand the purpose of arch alias. I failed to notice you were talking about arches, sorry about that. Finally, whenever a user abuses bugzilla, you can poke bugzilla admins, userrel and a few others to look at and take care of it. Some of us can go as far as locking users accounts - feel free to poke me if that need ever arises. Regards, How is this solution more elegant than the one I proposed? :) All I'm saying is that we already have tools to deal with users that abuse bugzilla and we've used them before when needed. Regards, On 13-05-2011 00:39, Francisco Blas Izquierdo Riera (klondike) wrote: El 13/05/11 01:57, Jorge Manuel B. S. Vicetto escribió: Finally, whenever a user abuses bugzilla, you can poke bugzilla admins, userrel and a few others to look at and take care of it. Some of us can go as far as locking users accounts - feel free to poke me if that need ever arises. I'd just like to add that usually a simple warning when users don't do things properly suffices, I recall receiving one from Tommy[D] regarding the use of CCing and after that I didn't do evil deeds with it again. klondike Francisco, thank you for mentioning this. When talking about users abusing bugzilla I was talking about users that repeatedly have a bad behaviour and that ignore warnings and or requests from developers. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNzR0QAAoJEC8ZTXQF1qEPD0gP/1UXW8nKwZZJbXDo5GNwwWqT g3WDnTZzoot/1tN/u2ar4fm8mCEFiEY+J3X9jmBeIN/IhOcPduNX4gIenyPWylIp +179STN5xoRcdQjSCRBWTz5WamnCGMkCX1QqIKDTUQ/N4weA+BOGCBqo3ZLbsYJ6 Ek/QdhgbheL8o90RUSwalsngCgNk30/53sjVHu48F88N3NbJtdmhvj0pxM16Ds6Q 6Wyl7m7Y+72W+XIsAytmDHP7f9UaBR4WO8vDvXHHceHkJ8ovHxofm6l1UQ6DsqUh oPKLTk2D9tD3fZPf0oVYyZWgFdbdx/glz8VRDqzQylhWhyDB/VuetTCEf0IEl61f BiBQ7Z4wka5TsmBNDIla3xJosZQOfwVvry4javxSRvCbYZntdpEeSsKDTSb4tjt0 5dI/evC3sool0oUAuxxOE+sX4a8fpl5qAvIIjXFZhOCDrPaWBQe50VxNMNGOTmu2 8sSgz6GmoFFMcizPGxP6PKEzFh4rDmT724ZUZ1tj0vARcyQcpq0jLnBIQFWhq/vh 7aFArhK+xBA6EIrSm3UUkcBGP+rUVmDo1vs6vl4FeZDY2/epvQGPHR+NLZVliHTE M9jrwnJuGSFPVjtriYVmTExkRTH/dDYZd5adkOASSvptpH6/5z056r6g4eBpoqmv Ttutf3QCSGFXseHLFZLq =3hVB -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: *_iface variables in openrc network scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi William. On 12-05-2011 14:34, William Hubbs wrote: Hi Jorge, On Thu, May 12, 2011 at 02:01:19AM +, Jorge Manuel B. S. Vicetto wrote: On 12-05-2011 01:45, William Hubbs wrote: In my opinion, the best way to fix this, and the best way forward, would be to stop doing this. My plan is something like this: For the next openrc release, put in a warning that config_* is deprecated and advise the use of ifconfig_* or ipconfig_* depending on which interface handler is being used. Then, at some point in the future, remove support for config_*. Does anyone have any thoughts? William, isn't that the whole point of the modules variable in the config file? One of the first things I do when configuring a new system is to edit /etc/conf.d/net and I start by adding modules=iproute2 to it. I'm not sure I follow. would you rather keep the config_* variable? I think we should try to keep them. If so, how do you feel about requiring the syntax of the variable to match the tool you are using? That would mean that the following snippets would not work: modules=iproute2 config_iface=x.x.x.x netmask y.y.y.y broadcast z.z.z.z # the above is using ifconfig syntax with the iproute2 module modules=ifconfig config_iface=x.x.x.x/y broadcast z.z.z.z # This is using iproute2 syntax with the ifconfig module. That's exactly what I meant. By choosing the module one would get tied to its syntax. That should make it simpler to parse the data. I would also suggest making the declaration of modules mandatory or for you to pick a default tool to be used when someone doesn't declare modules. I prefer iproute2 syntax, but I suspect most people would prefer ifconfig. As long as I have an option to use iproute2, I don't have a problem :) William - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNzHICAAoJEC8ZTXQF1qEP6qUQAMeBWdnItCG2IyQDcUfeDVh0 F6rbngiYPu/AETXvyBfcx0d0rmaszqrqQLWGoNEZVJlPIbHTGD3kTrBVYatTAsIb ooDAcDa3G7yjc/NLu3FRXmJv7Ed+qNFOm9/jDCRH+bOS69rD23BoR0KiRhriFGg8 OwsNxyrFyvRFmoZH1CBfbOcXMlEUBP401iiaeGs+2zuSwFZErRWVIvUQcgaf8evI 6zYk4Lxyh/OHVHhBiumDrJ3izhZklBAVQnYvxvId+kbhvxKPLgI3sZjDZx/L1Qd5 oA7UaLJu+7qFfesj4UXH+VLj0uxIWl398Ka9ZU9h6H08MNde8l6N3rn2D+wkoMax h5mSsWQiRKRqdUIS3vGddLJyd29LNhrixY7FRKnSnSJMgDpxcb25CYU66zJXga3I dO4Fta9e4qdFtZwfsiTxuFAd4XVWrZ2+HkgIthULCXfk92bSgHxU2sdzkBlVju2U 1prywa79wK/hm5Y7miAaRbVkJ2iI/DI/46rphnny/JLDsbcD+M37xbG2Ypw6/Jt7 jmpuHs+Vu2PyFaAA84q/pBPQFJBckReyB0+8l+RDV15zPy4gPdc1nqj4HDhFAj27 SFBKjpYbGJ7VFW0vjZGO5k8E4z3Ecn/X2QlBtlPFrk3Nxk2EG6yTC7H0Q5/i+Pam 3DNpqx0iGmLIWixmjHyJ =gDFf -END PGP SIGNATURE-
Re: [gentoo-dev] More bugzilla restrictions should be applied to normal users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Markos. On 12-05-2011 20:19, Markos Chandras wrote: Hi, Quite a lot of users tend to change bugzilla fields without even understand why they are doing it. Would it be possible to restrict users from touching the following fields? - Importance - Severity - CCing arches on their own (!) - Blocks - Keywords - ... How do you feel about that? Does bugzilla allow such restrictions? I think we should trust our users. Some might feel tempted to test all the buttons, but I'm sure the majority will just try to fill a bug report the best way they know how. This topic has been raised a few times in the past and as far as I can recall there never was a consensus about it. In any case, as pointed out before, some developers want users to be able to CC them on bugs, at least on some bugs, informed users can have a good idea about the importance and or severity of a bug and in general being more open can provide a more inviting environment for users to look at and or contribute to Gentoo. Finally, whenever a user abuses bugzilla, you can poke bugzilla admins, userrel and a few others to look at and take care of it. Some of us can go as far as locking users accounts - feel free to poke me if that need ever arises. Regards, - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNzHPmAAoJEC8ZTXQF1qEPWRwP/iDSLgm9K5htBo3Pw/p4l4De vjSepG+8JXbv7T/cI4b1f9WxHPiu4hFslrdPlj/knZw7jqlb5McMWYzB8/SnoRMc CKKEryXS2EO4QapBeNMd6RD1P6+qh+rrhyRxHQw4rR0ewIt0yE63jkUIPILIfRzc +iNCabIs0q4Wm2mKJR3CyRiEw5la22iJW3z3Y+QIIpe93RqvzRJta9/MGrZc2LjT /rlmqHoKw7ntoB343F0yy7VqqSdmPPZGsxmOMmGihqTcfq/7a0j6QJlzJnKy2x3w A8gLuuqeZ7T7I4zztOWb3ZJ+lPNqa2eB+nId1cmYYVLkxHMPGtMqfSy74Tvdr0/0 8v9FcRPxF+fJmuDW1+0RtvrIk6J14047KxTyeU0qLvJxqrwL/0cPTZO3MUZ++MdZ Kt6YROATwt17dCNy5Uw0MVgraYzLrrjfSwLExvU6R94FI24A4Wuop506AOHUyp4S uZh8ukh/lG1dCBic7f4Nd4qpMcVtanZPHtK9YaNzfnfx1xfphiR9/Z6LKumnsLIm aMjQFXXoJ+sHimaiBnxr6JA2cqiAzbjODVZIqVsIoNMBKeMyJcwUrsJcnYOE2p/i 2E4mPqtvYj5SH5lG5ISe74d0Am23xBe/slL0ugRjfN06RL74MYDXmxcQwMQp+VC0 36/PbzTyYj4SUaqm+tmt =Xt5T -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: *_iface variables in openrc network scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-2011 01:45, William Hubbs wrote: All, we received a regression for openrc which prompted me to post this to the list to see what everyone thinks. The bug is http://bugs.gentoo.org/366905. Currently, we use one variable, config_$(INTERFACE), to configure the interfaces,. In the bsd world there are no issues, because there is only one configuration tool, ifconfig. However, in the linux world, there are two, ifconfig and iproute2, which have completely different command line syntax. Currently, we try to keep the syntax of config_* constant, which means that the scripts attempt to convert ifconfig syntax to iproute2, and the other way around. In my opinion, the best way to fix this, and the best way forward, would be to stop doing this. My plan is something like this: For the next openrc release, put in a warning that config_* is deprecated and advise the use of ifconfig_* or ipconfig_* depending on which interface handler is being used. Then, at some point in the future, remove support for config_*. Does anyone have any thoughts? William, isn't that the whole point of the modules variable in the config file? One of the first things I do when configuring a new system is to edit /etc/conf.d/net and I start by adding modules=iproute2 to it. Thanks, William - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNyz9vAAoJEC8ZTXQF1qEPeu8P/39X4MPzqwNe0wb7yBBxTOhz bSCoWroD+NyU6WHWq/WumZBKugXhjQpxHr1QcXtckUJonVcwZz7bxuv6YzMqReOY 00bhYF4Ok2xpFrLlwNR5c+lRxNyOI4S8noglkGnNgnnEyCIP76fENdzMNu9viHhf 23bOUFBaNe0Bm8R7NLpntQcM4Ihk4aC7l60ffRC3/L0pRetPJeDjpTOKuooxsFKP Bms4ZgATtUziAkjcZ4z/u3hIbgvNwcQSlXS2OHfPCPpvxGKx9jpDkbnW4WL582h5 /SH4RF1pCFFyTwQ4LFZatftD/r/aOqO1CXlbroEDgNL79dE93Cjf1US3fiIDXHTu 5VNi/HabY9Mz13+HxUIvUxBGx7q3CUY2wpPpK0U5A+voxTlLF7W2rp/+QZZfwQXG TJVFOIwn/Egr4SUlD6ayS+tVFARIygjJhQCCiX1aTdWZ1k13wqg72DcGHnxQhdjd s83UI8FAaRh7CWX6/hfo+FxZ0oE+3V4kNN3Mjm1qB1bqCO+p98BwMGR+DQHRSOGU ue6pGQ5EKnrTqJ68aBkbDL3h56pOf5SKoIw71bCv0lXbDVTif3+IRveyUlEVy7Dp 7mmYLE49paCQkY0SDYhpi22TzBE/RGg9lNz8Zt3WG8tS1Lwg7I0Q1zKuVIdSEbsH tSfJWWzH8NE9731oTi35 =v/dl -END PGP SIGNATURE-
[gentoo-dev] Automatic testing on Gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. Another issue that was raised in the discussion with the arch teams, even though it predates the arch teams resources thread as we've talked about it on FOSDEM 2011 and even before, is getting more automatic testing done on Gentoo. I'm bcc'ing a few teams on this thread as it involves them and hopefully might interest them as well. Both Release Engineering and QA teams would like to have more automatic testing to find breakages and to help track when things break and more importantly *why* they break. To avoid misunderstandings, we already have testing and even automated testing being done on Gentoo. The first line of testing is done by developers using repoman and or the PM's QA tools. We also have individual developers and the QA team hopefully checking commits and everyone testing their packages. Furtermore, the current weekly automatic stage building has helped identify some issues with the tree. The tinderbox work done by Patrick and Diego, as well as others, has also helped finding broken packages and or identifying packages affected by major changes before they hit the tree. The use of repoman, pcheck and or paludis quality assurance tools in the past and present to generate reports about tree issues, like Michael's (mr_bones) emails have also helped identifying and addressing issues. Recently, we've got a new site to check the results of some tests http://qa-reports.gentoo.org/ with the possibility to add more scripts to provide / run even more tests. So, why more testing? For starters, more *automatic* testing. Then more testing as reports from testing can help greatly in identifying when things break and why they break. As someone that looks over the automatic stage building for amd64 and x86, and that has to talk to teams / developers when things break, having more, more in depth and regular automatic testing would help my (releng) job. The work for the live-dvd would also be easier if the builds were automated and the job wasn't restarted every N months. Furthermore, creating a framework for developers to be able to schedule testing for proposed changes, in particular for substantial changes, might (should?) help improve the user's experience. I hope you agree with more testing by now, but what testing? It's good to test something, but what do we want to test and how do we want to test? I think we should try to have at least the following categories of tests: * Portage (overlays?) QA tests tests with the existing QA tools to check the consistency of dependencies and the quality of ebuilds / eclasses. * (on demand?) package (stable / unstable) revdep rebuild (tinderbox) framework to schedule testing of proposed changes and check their impact * Weekly (?) stable / unstable stage / ISO arch builds the automatic stage building, including new specs for the testing tree as we currently only test the stable tree. * (schedule?) specific tailored stage4 builds testing of specific tailored real world images (web server, intranet server, generic desktop, GNOME desktop, KDE desktop, etc). * Bi-Weekly (?) stable / unstable AMD64/X86 LiveDVD builds automatic creation of the live-DVD to test a very broad set of packages * automated testing of built stage / CD / LiveDVD (KVM guest?) (CLI / GUI / log parsing ?) framework to test the built stages / install media and ensure it works as expected I don't have a framework for conducting some of these tests, including the stage/iso validation, but some of them can use the existing tools like the stage building and the tree QA tests. Do you have any suggestions about the automatic testing? Do you know of other tests or tools that we can and should use to improve QA on Gentoo? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNyZx3AAoJEC8ZTXQF1qEPqoIQAKxIUHJItLX2HCgqbjmOMOTu P7Losyu6bAi9ndtyRGYwlmEHSRBgbrkHyllx2GCMj6vR20HBYWUiUaFn3QIghLLq 2d1Z75zzL6FN9IQvAM8BgQWEj7+Fe24MdOhx8knQmXzZn4jffzxeI/Clw/YzfxWd 7uVNWh2x48+/susjLhrkpmbQfcvuSuwK/qzhMsfJcbL5G0rHweoXtOI6L2fvLd/8 VxwtNPRm0lemB2DSifN5zmDiWe7Z1Tb+qnb7XZrj4KgJB154dbnpIirqW6eilYz7 zDVzGtjRm5MdRHzNxcHZ0M1XqR0N9BcwBBsqyh2Qhr6y8W8BX7gnqC/OuT+2LPOi HzvZ4sbGq2uq6/Fqjnyv9yWtqVNDjlJI2WjuZSsmZJaPVr/zSUptPfJEO/Qdla98 6aC7zdZucQAG8ai6KccttsaVv2N9Q5YAmZygBsiMjBZqNMfb8vsxN8VtDattd16Y ICnYBIyAxkazI94dp0dAuX429c+9+jTYZVMmGSbMQ8I/jFayEkpvim9wmCtIG+nx aySk+CKUpBFxF+nAttO0NEnM5oNtoNNx8k4VtMLRVyUG/LDK7z4p1OGocGZ1uELq +0aNNrY3qmDK4Yq0ID5bhp/gppn7PGrJBvm7zrqXUk7lVqs3NJHFSz4NLNIp41le o0qGl3+8Mhbns1mljpmx =sWpj -END PGP SIGNATURE-
Re: [gentoo-dev] New mysql eclasses review
Hi.
On 18-04-2011 23:02, Ulrich Mueller wrote:
On Mon, 18 Apr 2011, Jorge Manuel B S Vicetto wrote:
The mysql team now uses 3 eclasses: mysql-v2.eclass[2] (base
eclass), mysql-autotools.eclass[3] (for autotools based releases)
and mysql-cmake.eclass[4] (for cmake based releases). The first 2
eclasses are complete, pending any updates from the review. The
mysql-cmake eclass is still under development, but can also benefit
from a review.
I didn't go through all of it, but here are a few things that I've
noticed in mysql-v2.eclass:
Thank you Ulrich for the review.
I'm attaching the diff to this email, but the commitdiff can also be
seen in the overlay -
http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=commitdiff;h=7cd4cedb1dcade2a63018fc82a2622606c524126
# @ECLASS: mysql.eclass
Shouldn't this match the filename of the eclass? (Same for
mysql-autotools.eclass.)
Fixed.
# @DESCRIPTION:
# The mysql.eclass provides almost all the code to build the mysql ebuilds
# including the src_unpack, src_prepare, src_configure, src_compile,
# scr_install, pkg_preinst, pkg_postinst, pkg_config and pkg_postrm
# phase hooks.
Name of the eclass should be updated.
Fixed.
MYSQL_EXPF=src_unpack src_compile src_install
case ${EAPI:-0} in
2|3|4) MYSQL_EXPF+= src_prepare src_configure ;;
*) die Unsupported EAPI: ${EAPI} ;;
esac
EXPORT_FUNCTIONS ${MYSQL_EXPF}
You don't need a global variable here:
,
| EXPORT_FUNCTIONS src_unpack src_compile src_install
| case ${EAPI:-0} in
| 2|3|4) EXPORT_FUNCTIONS src_prepare src_configure ;;
| *) die Unsupported EAPI: ${EAPI} ;;
| esac
`
or even:
,
| case ${EAPI:-0} in
| 2|3|4) ;;
| *) die Unsupported EAPI: ${EAPI} ;;
| esac
| EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile
src_install
`
I was following base.eclass example, but switched to the last
alternative you presented.
# @ECLASS-VARIABLE: XTRADB_VER
# @DESCRIPTION:
# Version of the XTRADB storage engine
XTRADB_VER=${XTRADB_VER}
Is this assignment needed, or could you use @DEFAULT_UNSET instead?
(Assuming it's for the eclass manpage.) Same for other variables.
Did you mean using : ${XTRADB_VER:=}? Done.
# Having different flavours at the same time is not a good idea
for i in mysql mysql-community mysql-cluster mariadb ; do
[[ ${i} == ${PN} ]] ||
Quotes are not necessary here.
Fixed.
pbxt_patch_available \
PBXT_P=pbxt-${PBXT_VERSION} \
PBXT_SRC_URI=http://www.primebase.org/download/${PBXT_P}.tar.gz
mirror://sourceforge/pbxt/${PBXT_P}.tar.gz \
SRC_URI=${SRC_URI} pbxt? ( ${PBXT_SRC_URI} ) \
# PBXT_NEWSTYLE means pbxt is in storage/ and gets enabled as other plugins
# vs. built outside the dir
pbxt_available \
IUSE=${IUSE} pbxt \
mysql_version_is_at_least 5.1.40 \
PBXT_NEWSTYLE=1
xtradb_patch_available \
XTRADB_P=percona-xtradb-${XTRADB_VER} \
XTRADB_SRC_URI_COMMON=${PERCONA_VER}/source/${XTRADB_P}.tar.gz \
XTRADB_SRC_B1=http://www.percona.com/; \
XTRADB_SRC_B2=${XTRADB_SRC_B1}/percona-builds/ \
XTRADB_SRC_URI1=${XTRADB_SRC_B2}/Percona-Server/Percona-Server-${XTRADB_SRC_URI_COMMON}
\
XTRADB_SRC_URI2=${XTRADB_SRC_B2}/xtradb/${XTRADB_SRC_URI_COMMON} \
XTRADB_SRC_URI3=${XTRADB_SRC_B1}/${PN}/xtradb/${XTRADB_SRC_URI_COMMON} \
SRC_URI=${SRC_URI} xtradb? ( ${XTRADB_SRC_URI1} ${XTRADB_SRC_URI2}
${XTRADB_SRC_URI3} ) \
IUSE=${IUSE} xtradb
Probably a matter of taste, but I'd use if blocks instead of the
multiple here.
I switched to if blocks here.
mv --strip-trailing-slashes -T
${old_MY_DATADIR_s} ${MY_DATADIR_s} \
Both options --strip-trailing-slashes and -T are GNUisms and may not
exist on other userlands (like BSD).
I'll let Robin take a look at this one.
Ulrich
--
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
diff --git a/dev-db/mysql/Manifest b/dev-db/mysql/Manifest
index a76baf5..99f845f 100644
--- a/dev-db/mysql/Manifest
+++ b/dev-db/mysql/Manifest
@@ -11,6 +11,7 @@ DIST mysql-5.1.52.tar.gz 23841760 RMD160
5809c7a5932a014fe412ddc5b9f15632c7367c2
DIST mysql-5.1.53.tar.gz 23871815 RMD160
e8fd69450dda85cf3f41269e6e3fca05caccc76d SHA1
24064a4c0f8b88b30acb6ddb03f32e897ef061f3 SHA256
d68c0db580bb514bb1759d4c69dc71ceb0e3573ac88a1025111bdd8f89e234a4
DIST mysql-5.1.56.tar.gz 24795624 RMD160
c2ff6eb06d0797d4b56630b783d4ad2d1add1422 SHA1
8665c76ab4ab36e8d2379ddf6d678c89b95d9321 SHA256
930e731c8f9318aa3f5e2e6985f6776aaaec81cd32df310e79e73d87177f6613
DIST mysql-5.5.10.tar.gz 23877968 RMD160
7f190513e38bbbcac21291e226de87b3b95a1ba4 SHA1
7e0b426d7a9ef0eaa6e2b2ea3e5fef1e1a078c5d SHA256
f4a0dae6d2626705ccede5126f2a3d45700195cb2568537c8b18bf1b604315a5
+DIST mysql-5.5.11.tar.gz 23664849 RMD160
e220a2b105d43de0544b097ffae954e2d0829da6 SHA1
f6a9ccf00fe723e7f18027cfd64527d1e71c8322 SHA256
Re: [gentoo-dev] Bugzilla 4 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07-03-2011 08:51, Robin H. Johnson wrote: On Sun, Mar 06, 2011 at 11:55:31PM +0100, Christian Ruppert wrote: our Bugzilla (bugs.gentoo.org) will be unavailable for the next hours. We're going to migrate our old Bugzilla to Bugzilla-4. We expect our update to finish within the next hours. All completed now. If you run into any problems, please file a new bug under the Bugzilla product. Thank you both for all the work in the upgrade and for all the maintenance work you've been doing for years on our Bugzilla. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNdMHeAAoJEC8ZTXQF1qEPzMwP/Rgc/F0ffJ8N5nKcW6DmcAO6 Xk8mPs7aMZ+YKdUmt0Ti67QMkGXn7UYDGqcEysKJzPY8G9aPboGZ/rrZIKU8kUtN ddD++GO/yrqIBmMZaohXd28SSCTi7Ea+fmZSreL9Kq3Z9JSMIRNvCXKxlDVb82ll wV44OPdrmRkTJ561fARuWxUs0NY7KnSUuBQ2Xr2dqjYQ3FsxtBK9RwDag1wFf24W rJwoIHa9a/jRyp4eYlAErWdcQKDrdtfJWTX2gNjjp67JDO/PJBBvb2qXzGebjgra iKpTfVKqXRt5TGWvL+UkKKi220St0C83wBXhmOSRbpaLBEq6+dvLPJT0nGEeaO1s 2dY6I1CFdW+oK8fEg+V1+4djWJ7CwRfg9uH2q9lgxZXXBw6uq4vsLjWwMr+O20hE zwXNhHhq77VsJGENM3o+NFeiGvw4+j+1metvzsQgNQTq2gcnEeSiXxxwXWD7P2d5 QfjTlJg5Y6u6f3YnNYYNckgizeFmm5SkgKElET0wBD2ILChPMshhyB+aPnMlkzTm DJKcwr/9C1g9pEHjoUC8uOrIGTDny/uP/IOgBlbvBFwkH9u258spI/nkHliyF0y1 xVtXveYp4k/8GCuUyGscj5oeVqTdft65x47oDRYzWw93vb1Aacenkei2RciN9ueo nxpA5Kc0okEJVptcq1uT =vJNK -END PGP SIGNATURE-
Re: [gentoo-dev] Adding app-arch/xz-utils to the system set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again. On 31-01-2011 22:33, Jorge Manuel B. S. Vicetto wrote: Hello. Given the increased use of lzma compressed files, including on portage snapshots, I'd like to add app-arch/xz-utils to the system set. We already have a few bugs about requiring xz-utils such as 347557[1] and 305127[2]. [1] - https://bugs.gentoo.org/show_bug.cgi?id=347557 [2] - https://bugs.gentoo.org/show_bug.cgi?id=305127 Can anyone think of any reason not to do it? Following Jeremy's reply earlier today[1], I've just went through and added xz-utils to the system set. [1] - http://thread.gmane.org/gmane.linux.gentoo.devel/69661 I did so because Portage snapshots are already being offered as lzma archives and releng might start building stages as lzma archives too. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNbkU5AAoJEC8ZTXQF1qEPNDUP/jRqCLoGcDC/zZnQBNLGGXKm 47FhtzfjsWcggSYBqMYZ//tMBpjnflWGIiHP+xQ0GLl/VCkjpgs2KBU1KQWmUGbg 8OYeP0lj7a9/sW+JEBD0aXoEa4vEMKBIZjpvfnsttbFW294D/qQAc+GSBVB8FN8H YTfSUrEQR8gDOC4sxFx4Ad1/sC30MLJ/YKDF9G1syCKXyTBwoeL1s98FPXlIki6u tsP8eMybkl4OoA4XsRIxg9ckC4UULhatF46MEVQ6kveob1vcoaZqir6q8VR/Y7SQ fLp7Lo4rAt1Spg7/kzMpSLlE4GwEIR5FL29Hy/5CrIe8hmLZB9m8jvxJX0lrHebE Js4IoUblJ8GBDoxBKKVFB4ilN7uN5hm5GmsQ8HmgZYRL8EouVt+uXCb3lQVngDWy UqlnamBowtng0VrYvcEQRsVcXch4rD5aiYgP/s5Rvd2qPKorKU4vNlgfYgdOrVNF THCL35on2vWW0XZVDFxujQojmzqcpXb+ha7xdu9kkULJzHJgn119cuTEaJx3XPzp yYmTJFOuYmBDu5sGY5/qsjo/FPgM20nfgiWb7S+4azLppflprj8prJ75D/uV6Ig7 qzduthyS4u7ylNQ32Pt0jWlSHXjRk96WdD6yNIbp01DVne3q3klpSn3VscP06T/e QAauc5SBuZgvs2//ECrA =xYSK -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Policy for conflicting USE flags
On Thu, 10 Feb 2011, Ryan Hill wrote: On Wed, 9 Feb 2011 13:04:11 +0100 Ulrich Mueller u...@gentoo.org wrote: Maybe we also need a guideline that whenever possible, ebuilds should accept the default USE flags from our profiles as a valid combination? Or, in the exceptional case when that isn't possible, a package.use entry should be added to profiles. Yes, we need to be careful when using REQUIRED_USE with global USE flags, especially the defaults. If a new user has to spend half an hour trying to figure out the magic combination of USE flags that will allow them to run `emerge @world` on their fresh install they're going to get frustrated and leave. I imagine it would break stage building as well (?) The stage building process is affected by ebuilds that die for conflicting and or missing use flags. Fortunately, stage building only builds packages in the system set and not the world set. So if you have a package in the system set, before you make it die in the above scenario, be sure to check with releng the impact and try to provide an exception for USE=build. --- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
Re: [gentoo-dev] Gentoo Installer (text-based)
On Thu, 10 Feb 2011, Donnie Berkholz wrote: On 21:18 Wed 09 Feb , Fabian Groffen wrote: This is a post-FOSDEM call for people with interest for a Gentoo text-based installer. If you are a developer, or Gentoo user, and feel like spending some time on (possibly) creating a text-based installer for Gentoo in cooperation with others, please contact me (off-list). Like http://agaffney.org/quickstart.php ? We mentioned quickstart on FOSDEM and getting boxes installed up to stage4 so they have all the software one wants to get them into production. Fabian, is your thread about this or about something else? Regards, Jorge Manuel B. S. Vicetto
[gentoo-dev] Adding app-arch/xz-utils to the system set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. Given the increased use of lzma compressed files, including on portage snapshots, I'd like to add app-arch/xz-utils to the system set. We already have a few bugs about requiring xz-utils such as 347557[1] and 305127[2]. [1] - https://bugs.gentoo.org/show_bug.cgi?id=347557 [2] - https://bugs.gentoo.org/show_bug.cgi?id=305127 Can anyone think of any reason not to do it? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNR0bhAAoJEC8ZTXQF1qEPrfgQAIzHlpfT5KFalUHMqepG6M0W HFCKjP2GGxF5FgztAQreiOX5C7BdPhIvqXssOnKZ3tUYu7CRTv0yLp9Q1+zQEOZa bdvDzPkL67Ht63fgRszczfLRwEXFDr6uB9PFqMMTcwt8T7sU/qrAYVsIoILPY6Nn FtRIZpOOvvrA0hsUgUD/Pr+yNP2EFEZTkj7dXOHs3dd65wlGW5rLP9+f1jPEhuOH EV5mAvoVefhyOLOq/H9khH/MPdTtq8aB7XflDvCI7uFOym2HV+EfZl3lo1C3zYBe rtZnh6yKKkHEsoTEYdZG83wdBwGWJRl4SC0Fzyw8dhJV6Uhz3Up+oiNiaGm7KjY/ fDdHdOt2adTIpVU8kw++pNDpkQ64WDThFQ8Fi/f0D4rY4E/+ET3B8QQMh5Q1FRna QfHhL8CbjeV1NKn2ltD06i0g4wISrlC2f51Zhq9WqnT6SS+PzNcMbg+fGjKHNQJ9 bZ7DMvhc0QCHJm728KcQPFHaZnigvvdE0y+LGrDNJbr/qbObi69xQSh0lX1RErjH K9qH3tLk9bdZJDFA37r36EhHKHzgO3U4MyQnFvkzRLQ77+GwmXbmX4GIq37LLNWG 2CBIL+y4JhlZUn9DGjO/MdjPaEsePLh/dkpU/4VFlJttB/scrQaAeXTDA+aIcHLy aILDjemfuclyFIC9lkoO =G3wn -END PGP SIGNATURE-
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22-01-2011 03:20, Donnie Berkholz wrote: On 04:38 Sat 22 Jan , Theo Chatzimichos wrote: Assuming we're going to move the git.overlays.gentoo.org repos there as well in the near future, this is the structure i am proposing: source - portage-main.git - portage-history.git ... overlay - project (instead of proj) - sunrise.git - kde.git - ... - personal (merge dev/ user/) - aballier.git - alexxy.git - ... I don't see any particular reason to distinguish between the main tree and overlays in this structure. Just do something common for both, like tree/ or ebuilds/ or packages/. In the same vein, there's no good reason I can think of to discriminate between overlays that are project vs personal, since either can be supported or unsupported. I think a distinction between tree and project overlays can be useful in case we ever consider splitting the main tree. In that case, our new tree would be composed of all the split repos under tree and users would have an easy way to distinguish between the tree and project overlays. We could even provide the ability for users to have just some of the split repos and thus not require the complete tree. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNOvOLAAoJEC8ZTXQF1qEP924P/2dbxlK8m3y0k4/ArQojeJH7 9HY3NzMImIuIW44kcdGhEj6+bJDEPGTz1Pb1zGrNMSxNYgrxrXYkEKEWldNYszm7 TNqQvm+Pl9D39ckjjDzV+zMfKZQn9UtM3MCTOw4ozWZynSLGajkpZK6Cp4BIiOjF JiPi+Q8zSw/Xc8umLxK4ZfWy4n4WhLDbJgxO8ws+s27iSlQemJhqlOmCw1nMAcyB FPlf1cyMa0MxUStqHWzJ0MBtYOfkxoSNvnXAoVl47DGPbOagdSSWkbbmx5p6vn2C HpJ/xNfJkDoPa6DPrbBdQtmiay3A72fkokwLSFKMvNhMjDMeMhR30IPxDkrRf/ls faIK7FKeJbh/sWr0XgBVR5rsASSQkor647DbjT04/v+g9HN/bB9IxmYY9hVC66aw +j0gph07zTuXUAHDcqqSnMxlr3MGril+mAVXf+ne2N6emrP88K2plnSGc5LmUfyy i+eEfb5UBTxfBfmyollKArVS9djzKveKLiVgIn1ga6kyj7JGYiDZnJTOfHJ1sfdc R8dti5qyqQUruzmjkEeGQEMBpawIh/ZYY3LDfh7MaDkLjLScdVUHgZDipn+QjIUx lliDjRK5sa1S4WWojK0t/gd3ikW/YrXQRHpLo9EOtMzkRfR9FSbFv+ew8ud5RlyN eIQrF7smR0LCOMF1/mzj =ytaq -END PGP SIGNATURE-
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22-01-2011 11:32, Theo Chatzimichos wrote: On Saturday 22 January 2011 10:55:19 Robin H. Johnson wrote: 1. We EXPLICITLY need a location for private repositories. didn't know that, so i guess the private dir should be: private - infra - (infrapriv1).git - (infrapriv2).git - foundation - (foundpriv1).git - (foundpriv2).git - pr - - Some of the developer+user repos are NOT overlays, but Gentoo-specific code/applications. These DON'T belong here, they should go to project/ Why not provide a tree for overlays and another for application repositories? - On one hand, I would like user repositories to have a separate namespace, so that other users realize a given repo is NOT from a developer. - On the other side, what do we do when a user with a repo becomes a developer (and when they retire?) Well, the distinction for unofficial/official overlays happen mostly in layman -L, I don't think users pay attention to our git repo list. Furthermore, I got at least three requests from developers to move their repo from user/ to dev/ (same problem when devs retired). This distinction doesn't make any sense. Instead of relying on the name space for such a distinction, I propose we use a label for that. Preferably we should have an automatic system to produce the label and have it present on any online repo browsers (gitweb?) and on project management apps (redmine?) so that users have no doubt when looking at projects.gentoo.org / overlays.gentoo.org about the type of a repo. The label to distinguish between developers and non-developers repos could take advantage of the ldap info. We could also use labels for the status of a project like we're already doing on layman. With the above in mind and some of the suggestions in the other emails, what about the following structure: tree - core-portage-tree.git - core-portage-historical-tree.git (possibly some day) - gnome.git - kde.git - sci.git - x11.git (split profiles, keywords(?)) - profiles.git overlay - project (do we want to support non-gentoo projects?) . gnome.git . kde.git . sci.git . sunrise.git . external project a* . ... - individual (we need to decide whether we want to host and the legal costs of hosting non-gentoo individual's or project's repos) . aballier.git . alexxy.git . user a* . ... project - pages (project web pages, but not applications code source like forums, blogs or PMS) . main-site.git (split from the current gentoo repo) . gentoo-project.git (should we split the current gentoo repo?) . devmanual.git - repositories . project (tied to projects) ^ gentoo-forums.git ^ gentoo-blogs.git ^ gitolite-gentoo ^ gstats.git ^ packages.git ^ planet.git ^ portage.git ^ pms.git ^ releng.git . individual (work of one or more individuals not tied to any projects) ^ portage-utils.git (not tied to any project afaik) ^ layman.git ^ rbot-gentoo (is it tied to any project?) ^ cool new toy for Gentoo done by devs A and B ^ soc (include individual soc projects here) (would it make sense to organize by year?) ' soc project 1 ' soc project 2 private - foundation . legal . finances . ... - infra . infra 1 . infra 2 . ... - pr . pr 1 . pr 2 . ... This design includes 4 top-level labels: tree, overlay, project and private: * the tree sub-tree should be used for the Portage tree, it's history and any future trees we choose to have. * the overlay sub-tree should be used to host repositories to be used as overlays. * the project sub-tree should be used to host the web pages and sites and all the repositories for applications / tools. * the private sub-tree should be used for private repositories that cannot be exposed to the public. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNOv+zAAoJEC8ZTXQF1qEPp9EP/AvFRbVsYQHcik4PMMFdwHPO 3vCXl2M0JENah/HBIM7cMigt1KWmk8jPJ4QOdARnFb2rVy9nDbycIzKYhHotg/aO Bh7euJdLj1jxI3DKz1kZCj++DXQyZ0clzBde/c+sYWfw/1bGruRuZoAqr5Tbtkd4 4h6YV2bCHgeJUjUpC/7+K6M1/UNW7MwhdJC9cViLXyZ+O04fGSNZ5g/V7CCQtrE4 oMDodPgmfjwdmp9AqsA6ejVswkhuMbL8KyHS3kEBQXABugQpGnwVnY48KI2oi0yv 4oqa6cv+A6F9hoSrfHk9dytMdegAHtuFmq/70nnLBwVvljrdyGackAJj51oAtLgW 6tZDOGp6ZsjzsruSS3Keh4V2wFRz7Uejjkhkn/QuYMO86QyX3QA0eN9dce/HuOEv zpbgZf3qvVvZ/zFnJw48sYNogfeb+CSQqs1pqRCjLwhShg1TcrBYYldiRvhxKNXl SNBBUQDKSiorLGLnM6T23QEH/hEoVVjH6Z6D/09F0MODpwdv0H+iMJkUIGg1iv7G WladznFgBg/gHjLB15Aq0Ux7eGwd6uoJ1Mm3zt0KbuO14udYgAbW6JvLw2JF7DSV Y5njptBYPTUHx7Oj15LtzrN6RUQMnN/fLM8/VoBVrSb5dnXIdYWwCerL3JzkFsiH
Re: [gentoo-dev] Deprecate EAPIs 1 and 2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31-12-2010 10:02, Ulrich Mueller wrote: Hi, after approval of EAPI 4, there are now 5 different EAPIs available, and it's hard to remember what features are offered by which EAPI. So maybe it's about time that we deprecate EAPIs 0 and 1 for new ebuilds. As a first step, a warning could be added to repoman that would be triggered whenever a new ebuild with an EAPI less than 2 is committed. I agree that having too many EAPI versions around can only lead to confusion. Furthermore, it can require extra work from developers to ensure compatibility for ebuilds and more importantly eclasses. Instead of deprecating EAPIs 0 and 1, I'd suggest we deprecate EAPIs 1 and 2, though. As others have recalled, we'll have to maintain EAPI 0 around indefinitely, and EAPI 3 includes all the features in EAPIs 1 and 2. This way we can leave the system set packages alone. At a later time, the warning could be changed to an error. When most of the tree has been updated to EAPI 2 or newer, we could also think about actively converting the remaining ebuilds. (Currently this doesn't look feasible though, as about half of the tree is still at EAPI=0. [1]) Sounds a good idea (for EAPIs 1 and 2). Opinions? Ulrich [1] http://blogs.gentoo.org/alexxy/2010/11/06/some-interesting-stats-about-gentoo-portage-tree/ One way we could drop EAPI 0 would be if we do a major review of tree and repo formats to improve upgrade paths, which would however likely require breaking backwards compatibility at such point. I believe such a change would only be acceptable, if we would pack enough features and safety measures that it would ensure another break would not need to be done for a long time. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNIJeVAAoJEC8ZTXQF1qEPnpIQAM73/W5vvIz9DJjHKiSPp8OX Z4ezg0lBiT5ZpeN4caY5jdhh0lRWE8raEDBKiCjJhm/lnkdqs3hpYx5ogHJxhGrM 2HkzF1wfDFt5/l0PnqhCyGlS6o/v/zN4w0d3TQKsl1hq5bz5fge2SCe37bZXSC/h Did6ijW17wsu+OQOP4ihI7CibLy0G9khi+zDQBoKsC8UVwfzO013aRuVORySP+d+ fgyR4wMOgduVqlsIKqLBVMTRzPWCUDvmyGd2eVJ8zhl5i/n1Hnq8Pw3QTwSmK15s wfUUQH7N7uuWgC8w2i2JEy717yzjB5CRZX54MIFgIk2zFxPZe6mBsMeafL9oPNeR 3J2qJvlULM7BOxjkdXakE+089TM3R3d32ul9qcBmnlWbpbxHwzH/h7dAoCRb1kwW DVG9MS1FGRar7EnKLVKhDh554cG47vS15b6q0fOSbxKNyjKa28XJVR7GQNtjk85Z ACJdG5J9yCidgWWyiCcdF6uDAKGOl6FqJDngGLVrXsSWyL6nuUA68hEAMfuC5Y3D EIWsexsRqVT2tksZ8a/LlhpCH74ksbibrH5sLw/0P0qrhQvK3K0whfIXF+kjSVy9 qnixHkSYTWUDkYB8cWrBemroD6bLQvm8pzOurOrSKeLY8ax28H2Dqkz914W6H4Ae 3DYA5ct0nnFQV4FOvUzA =nBkm -END PGP SIGNATURE-
Re: [gentoo-dev] ebuild for python-dev package - need some help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22-12-2010 09:42, Dirkjan Ochtman wrote: On Wed, Dec 22, 2010 at 11:40, justin j...@gentoo.org wrote: we have a seperate list for helping on development of ebuild, gentoo-devhelp. Please send questions like this to this list. That's good advice. You may also want to ask for help in #gentoo-python on IRC, or file a bug about this (if there isn't one already). You can also ask for help about general ebuild writing in #gentoo-dev-help on IRC. If in doubt, you can check a partial list of our IRC channels at the IRC page[1]. [1] - http://www.gentoo.org/main/en/irc.xml Cheers, Dirkjan - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNEdlNAAoJEC8ZTXQF1qEP55wQAM9YLCqH/7Do0iuDDYlas9Tu MzNUY1vc4XWZtfETq5uYejCPImCuWcXUyxeRECVow9E4N3MgkzFlSEnSABxijFM3 iVIWd92K+B2dpI00fBJYik9hFAiLXI+H2eb26ALZz5WgVXWtrV2F9VGTQs2NQNpj ZVM//qKVRJFAfjPM5mreSSnJNxWX2pY3dpf41gJAmWvg7i/SzbB+6phJabAmqg4K BbnJaAK/IFM2Rsed+IK1HI01qfKBG7GBofuYodE4v/QHBZvcLP4wrZRmQtnQ+0TC JpRzUuAEXnW6795mfNUOPWT40op0vMusLRxHQBKHPkXan0yZgv7dtiXznheoIERp T/vmr97bQQn6AtCZZX6Y+M78Ma3A1k2UQauHIE1KELq58h+Ck7a2pYRsdoUX6aj1 2lVumMxWKrqDLoN6PpzDstJIR+hkwZ82ojJ28c/xijV5mDvhvsNjH00l4WSEjdFI ee6uE7+VLWq0sx5L/jrbufVBCTpNX98bctMUciSbGX7+AfqQLFM4nFk3XQngCOG8 fhuHMIwU5SwdU8smtSSy+TkEXhFkRjZK00KT1LvRd5ftBm2jfNMgf/Aa1+JzKAH8 YtfaNHGD4QzbunFSthC+/YicpeKWlw177dE2T01IqorKiQzaFrwS/neCNIcpx91x vh9G9Eda3AqHz9T0ZMvy =1KO0 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: What are || ( ) dependencies?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-12-2010 18:35, Ryan Hill wrote: On Fri, 17 Dec 2010 15:25:04 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? I already thought that was the case, so +1 from me. I've been treating it that way for a long time. The KDE team used this feature at least one or two times, that I can recall, to reflect the change on preferred deps. I think one case was the move from monolithic to split Qt deps. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNDWLiAAoJEC8ZTXQF1qEPA8oP/3mGSBO3ojtBTn4mjQeqJFh3 z3bBQSx25QulgpZtn9oM5oYb6uxFY3Wh188THW548Bb+E6kKAYm6SlE7RxyoP0sz XNie8KcrMPCUfvbu1DaHdFzhnGh5Jrr9kYieQI8PRFxYLR1ucLAdLm07dX1MJ5VW Y0eFB0qRw9JP9JTLyFLNqj3j5x5Z97KE3CdLbenVfm8DcMHUgwKL5IChEFPZolcr nXWRDhh9JYNXIeb+13YW8b29XuJei1nJs8Gk1rsK1uKu//0y+mkwr/bzbDA+gpqs RcYwKc8HlZrNuLALXRUoIwx99Rhe3/JSuCfcHgXctTPCxPbZzaHYsjMIkp8EK392 R6yhENmUVTfzIrHkYGR4aoUcDjB/r7yxXN04W1A/r32e5QGy3fV5r80Ak7cFPhRv Xteg3BYtWhsVDzJucYgtyeFkCWXwz5ywOKpK6awVrp10ymmGD2FpYpLafCU/8rZM 8X9EdGII9OjPRDw1RUzao1WMoYwVbe5vmUOVp7N+F7mrwHB2VoXqKpkUAOrfrApZ QB6iHs+WM0q4WM+Bh9mGpsLyL/Xo+/Q996DdJ14m41RHYu4wEthzh4A2W3mqXjLH LwEdq1TCpz9+SVJ3TZNMf+SBl0aG3dyQW21IQyMGxX/zaiizuYOJ6rVhkYX0O9w3 BjGd7Gmv5LXEDScNfbaQ =PVWL -END PGP SIGNATURE-
Re: [gentoo-dev] Participation at FOSDEM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Zeerak. On 09-12-2010 23:04, Zeerak Mustafa Waseem wrote: Hey guys, Just wondering if Gentoo will be represented at FOSDEM this year? We will have several developers at FOSDEM, including 4 council members and the Foundation President. Betelgeuse has submitted a talk proposal to the distro miniconf and I'm still planning to submit a proposal as well. I don't know if anyone else is planning to submit / submitted talk proposals to the distro miniconf, the main tracks, the lightning talks or to one of the other rooms. The organizations that were assigned stands should be announced next week (14 December), but afaik no one submitted a request for Gentoo. We're also planning to have our usual dinner on Saturday. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNAYCZAAoJEC8ZTXQF1qEPQNQQANqKVud3bo399gzzxLluGDmm Gwxnwq5FVFmtcRcGiVgsTREhmfXZNp2n5x1plZLnP8CUSZHgP1ZdjLn59TjfiIsK 3wmdVjY/vb17jbnLJX/q7EHgw193ONJebKFMEMu3YJzs3hD10yYwEZRvCBMdRJy8 zXiROtgQ7v+CUaYXEyq/AVmKMIJgDncvvqtHh2QiYxReEj8EBuEnTfCPLHVeNL4J Dg7vW1sOYkgT01TxKGIJISB26M5VALUtkRu5ViplCZWxby3wuR/sRUE0iSbbzlaW MY2iK7QgDj8gYnbhqMYpJ3EnYfgdhpqP+9GeFvAajocIhWZ5ZiPtpoTGsK+QBSdR eI/8KQyB8F8Ff87P1YEJztI9Jfyu6j8/yUBzxiBdgGEqrUtZpP8wL+nK18kailFM m2Bp/SgrNvagKIS9+f49Dxf0GjPp+4lbZnbpyVP6g8Q+OU1sUGW2ARiePAOJ6LTa 2pZ/mrv3gdE8tR/WPnBNe/ABKoNxYAu24gOMM0Ay/Uc4e1ctrXfgNwicjtFsm86b QyEDLxx7jrMc2b4nl5lTB9bL0t7LrZvYY9E1KKQzUhP5nzlGMaYURGykhYRoppgS OeyJQxAwWJkh9hXIt7VXx9r3+ZcPjgUdX4ueI5ZFFFRgm/BBMG+Ln9oCstemICoP 7AsJ+JMSmN1iIW2eKowi =mGKi -END PGP SIGNATURE-
Re: [gentoo-dev] Stable Python stage repair thread
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
On 03-12-2010 23:34, Sebastian Pipping wrote:
Hello!
In the mean time I have sent the attached patch to people involved with
building Gentoo stages. Before further taking action on/with that patch
I am waiting for their response.
I've been talking with Sebastian to see if we can get a fix that works
for releng, so we can get stages building working again.
I am now posting it here in order to let you know about this change in
status and to give potentially interested parties a chance to join with
review.
I've sent Sebastian the following patch that I've tested locally and
that allowed me to build stages again.
diff -u -b -B -r1.10 python-2.6.5-r3.ebuild
- --- python-2.6.5-r3.ebuild 1 Dec 2010 19:53:20 - 1.10
+++ python-2.6.5-r3.ebuild 4 Dec 2010 01:44:13 -
@@ -299,6 +299,7 @@
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
+ eselect python update --if-unset
}
pkg_preinst() {
Index: python-3.1.2-r4.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/dev-lang/python/python-3.1.2-r4.ebuild,v
retrieving revision 1.11
diff -u -b -B -r1.11 python-3.1.2-r4.ebuild
- --- python-3.1.2-r4.ebuild 1 Dec 2010 19:53:20 - 1.11
+++ python-3.1.2-r4.ebuild 4 Dec 2010 01:44:13 -
@@ -297,6 +297,7 @@
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
+ eselect python update --if-unset
}
pkg_preinst() {
This patch gives us back the python symlink and sets python-2.6 as the
default python interpreter.
Best,
Sebastian
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJM+Z2kAAoJEC8ZTXQF1qEPIgwP/0hbKtUma2XbnJzB0uawdXwe
QQTrrnaLq82ErQYTBDyG63Pb1kscTbeH8LwqeSsDpIRkCcXwFEeC+Imr738e3uZh
e9ihYvFGCdD97z0YvkAkYuqVqGGP5im3KBHSnNSMk6ZwXJtD03vgeVwRA5Dnx7jg
KgMWj5WEdevAaH9VP59dpTRjSvhyMKHPEPjrcJjZ01RFu/QNSqvvVpVXB80oJCLn
A4nneBjBJhIWEFYR2plriw56I2XsTg++M6LkSaVKDUOBbBkIVaDARAvlBzwcaVXp
uIndguJjaXOp1Nl/GACsuvsc2Dd0GOkCbeDv2NAynzYBiOT6ldwq64NMa87JrNVa
BcMQilvsovw3qsupR2rmR3Ylss1Q26lAN5lbqyMsfbLTVO4DZTcy4Fr/ktieMojt
SngC/TBIOUwUApWrCYUNFHqqMM0jpWVtqa0RPaAj6FkNjYoWOTgfYxKmwJPz1Dj0
jY5zR0lwHaaSCkoi6KbA1XWo1/db5o7wbGomb7B5bRY4HbXUI8cXU/zBaZElkR2y
Jf0j30NvWtTM6Eh8V7T15hFku900BjmmMjvmrNMwrajA5U3DsLRVW/spLNx12yeL
xyErfH32WuiW/hmLCgnmGrGmcYnQeN6fBO0ENCM0kDWCYW5b4qmkoqug0v3G1ReV
ZgE5fXFR/eS67bhUir/2
=jEfM
-END PGP SIGNATURE-
Re: [gentoo-dev] Disabling auto-bumping of active Python version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-12-2010 19:13, Alec Warner wrote: On Tue, Nov 30, 2010 at 8:02 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: On 29-11-2010 10:34, Sebastian Pipping wrote: On 11/29/10 09:35, Arfrever Frehtes Taifersar Arahesis wrote: There will probably be no active version of Python set. You had two weeks to come up with this. Please find my on IRC to team up on an agreed fix. As Arfrever noted, this is likely the cause of the broken automated weekly stages for this past week. By not having a python symlink / wrapper, stages generation failed on stage2 run. I'd like to take this chance to recall this is the 2nd time on the last few months where stage generation was broken by python changes. Also, we've been unable to create hardened stages for over 8 weeks because of a sandbox issue. The weekly stages generation depends on the quality and stability of the stable tree. Therefore, the RelEng team kindly asks all maintainers to pay attention to the stable ebuilds in the system set and to please fix any failures asap as they may / can prevent stage generation. Be sure to think carefully about changes that can impact the stage generation, in particular when they involve python. Two issues: proj/en/releng is old as hell and doesn't even mention stage generation. Yeah, as everywhere else in Gentoo we could use more man power in RelEng. How does a developer know when the stage generation is broken? Is there a dashboard? At work we have a guy who is basically a build cop and checks our build dashboard once a day or so and if it is broken he goes and finds the guy who broke it and punches him in the face until he fixes it. I imagine we do not have staff for this (and no one has invented punching over the internet.) Lately I've become that guy for the amd64 and x86 builds. I've been going after maintainers to get the issues that are breaking stages fixed. I haven't tried punching anyone yet, though ;-) I am curious how often stage builds fail (how long can they be broken until we actually care?) They've been failing a bit in the past 6 months or so. We have some issues that affect all arches and others that affect specific arches. The worst and longest issue in the recent past was the mess with python-3.1 that lead to catalyst to die when python3 was becoming the main interpreter in stage1. We lost stages for a few months before we acted on that one. The previous issue that still affected this weeks stages build was the issue with sandbox that prevented any stages from being built for the past 2 months. This last issue with python was first reported for the ppc builds on 20101128. I only found out yesterday when I was poked by Raúl (armin76) as I missed all Gentoo emails for the previous 10 days. For random issues I generally start worrying on the 2nd email. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM9uYXAAoJEC8ZTXQF1qEPJkcP/jMau8sJ5UObjIGrGHeXODgB k76hNPm5j64jjqiQnqByevukIYQ0VfZhEbCcvRRdlMRzVfDoukmDx26372bZVO8d VkkS5JUmWxVR392W9flZqJw85DlrOB4p7HlxfjamgcsCxzrKVkKAqVDQcQkDGQOB qCOeDfLlijWOuc1bLMDUsQo1dYCr1XSKvsuY37lC6oQf5oCHr5a1+4xdhto1EbGr ASq3O9aKu/J+YLGI7rZtet5Lm8kAS803j6DLz0t15/I8obHzx+CeIzFLyr9Bly72 yL9DqU3aQ7xGFEI/GvCcS0vEOiile1VAT/YDLJAE3e24fs6r7Bf6PD1bUXoTiuAR tOGEJNwpj0Pa5lQoEs7Xe/xaY7W3YkoHe5QmyA8MNa2VyDpoMEm9HJkNH8IumyIn to68EOc4lHLHCYnm3CFa3C83jP6l3oq04VRlrs/D+geDP2rdTCCXvU8eg8O+c1NV buca8gK7iuA1sqHZWmInKSKp679Suw82rh7AxPJgXPc/YOzinhtBcMad3XmGmU4g XdoAXm5VWmO7/fj7ssCK9lzAWGn9ZaDKqGSl3rgpDkSTn7p7/Pih3OCcdcwoI/Gp uoJ/QD0eI8KAn6OTMN6UWr/i6P/Ys58m7dStKODsyboLejjtZMANbu1KiUKuumix AYLQ86te5Evz78MaFxeb =Yo6Y -END PGP SIGNATURE-
Re: [gentoo-dev] Disabling auto-bumping of active Python version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29-11-2010 10:34, Sebastian Pipping wrote: On 11/29/10 09:35, Arfrever Frehtes Taifersar Arahesis wrote: There will probably be no active version of Python set. You had two weeks to come up with this. Please find my on IRC to team up on an agreed fix. As Arfrever noted, this is likely the cause of the broken automated weekly stages for this past week. By not having a python symlink / wrapper, stages generation failed on stage2 run. I'd like to take this chance to recall this is the 2nd time on the last few months where stage generation was broken by python changes. Also, we've been unable to create hardened stages for over 8 weeks because of a sandbox issue. The weekly stages generation depends on the quality and stability of the stable tree. Therefore, the RelEng team kindly asks all maintainers to pay attention to the stable ebuilds in the system set and to please fix any failures asap as they may / can prevent stage generation. Be sure to think carefully about changes that can impact the stage generation, in particular when they involve python. Sebastian - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM9cjoAAoJEC8ZTXQF1qEPdC0QAK0HLSse/T3XUL9+vjp3VHro xXED/VsiXLlJtwlEsfWLf5kkMhejEXTO5gbLWZmqaJynOCFBk55eqQz04YXZQqWv XmtEnXzaf+394chTaWV3hPIzuVayZzJRtVJhEj1imbgLIa3Qyx7XJjpC4NwH2MVo 1Odef7Eh8vhpE2bD48BxJfp9KGIf+MQf0TPex/4TACirYzJ60J4aGZ627gbzyaym 3o9DoLD1DRRrURO66buLyV2eXvnMrNrO3UYKPP1M93uW1hq4RXZRGJ4oGePbBfwQ JuoGNc227lixeaivlLA83AOQbfYM3OW8zuM1l2kVMNSvzeVyh/wEx9U9ptvLhhLR nd0FJNt8RsIH8Yzi5NUfv4JMJoAQK5km2kNVFH1bE8vVp+RwyTVFPnuCtdNL1uLJ rVl+ptrF/Aiey5u/gVXpYSZGjU/lYtp73EebZhO+Bn1mymGMNVr2/UU9HWgCowmN so0AIcKa5NkT5L4Y3kI+bSokcrm/5bLbjZQ5MayWsRuEwJkWyt1vxfW2B2DaQbjQ +hRezNy/GwnfLM21yEYn46h5RnArdtV3vT6J6vksG+4aepa6WNAFnw47ABJW63z0 jAL8n/qjrsi2PJlUdrbZ230iqIFV1RmPtP5Z7M9gAM4VAtb8dNPWxB2ooEYOqg6u 8yAYnSVjKv/dTK7nPhSk =gX34 -END PGP SIGNATURE-
Re: [gentoo-dev] Disabling auto-bumping of active Python version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-12-2010 03:02, Jorge Manuel B. S. Vicetto wrote: On 29-11-2010 10:34, Sebastian Pipping wrote: As Arfrever noted, this is likely the cause of the broken automated weekly stages for this past week. By not having a python symlink / wrapper, stages generation failed on stage2 run. I just tested the stages creation locally and as expected this must be the source of the failure has there's no python symlink when building stage2: atlan...@atl4core /home/release $ ls -la buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/py* - -rwxr-xr-x 1 root root78 Dez 1 02:57 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/pydoc2.6 - -rwxr-xr-x 1 root root78 Dez 1 02:59 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/pydoc3.1 - -rwxr-xr-x 1 root root 6104 Dez 1 02:58 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python2.6 - -rwxr-xr-x 1 root root 10272 Dez 1 03:00 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python3.1 - -rwxr-xr-x 1 root root 1200 Dez 1 02:57 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python-config-2.6 - -rwxr-xr-x 1 root root 1177 Dez 1 02:59 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python-config-3.1 - -rwxr-xr-x 1 root root 10328 Dez 1 02:52 buildroot/amd64-dev/tmp/default/stage2-amd64-20101201/usr/bin/python-wrapper As such the RelEng team would appreciate a quick fix of the broken python stable ebuilds. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM9c1rAAoJEC8ZTXQF1qEPlygP/2wib7n4YOXvXRfBCrYoKuDi VTHLPpXHIhOxqWvAqIczyHfJhsIwAzeVm5wehmj+NDUSs7HXeO4Why4H6X9FY530 0KQqAsnjBQJU4xqfE8kofcRt8TUY7jmToObmEnGDM8raqouvpHjUlpp/2CC/eNCz xOVuJ66+DJC3LIjmCcMQIAhbrhZZ63s/3J9O3D7XHJtLGdWBmNvAfRELTdxNM+Zw UZRntctOWaPnyB6aSTvfK3SvC8cgPyBwvQFGWioZozWn9W+0J97/aux+aJRSCKJy f+BzqVCGfeEq8j4yUzyQUzkXRV7fbIXMHhbGq6wUuMgMvZo/tAa64x77nebPBtCm ZH49HAnKRRzy8O72AE3BVKVT3hCAxEBU/len309Dc2Cbwznb17WYm18Ihl5ShACG /UZ+TkYwyctuh/ICmtFE0DsUIgcXHsMaCllpLF1iNxIEX6yOaxWvPoE1Pv4cnyIv BWGHHL4sHsybyRNkiGYbeQQarYaXKS78N6wOeBhjXMi+T7QqanrJ76897l7LsRr2 3+RaPA0KHCvexixI7EuEUjfrIcYNFpZJoLLGci8ZxtjDe9MRRpnY1J6540B1sTi9 1Amb8ZwrXib4ngId7oZPN//E9umbB1FFOixGRNGfn9E2Ovmc9D+BFm5/+xCxr2/0 B6bpK4SXkB5tedu+D4a6 =uqe1 -END PGP SIGNATURE-
Re: [gentoo-dev] News item: Dropping Java support on ia64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-11-2010 18:41, Paweł Hajdan, Jr. wrote: On 11/14/10 8:36 PM, Petteri Räty wrote: The IA64 arch team does not have the resources to maintain Java support so we agreed that support will be dropped unless more man power becomes available. Could you also add the info to http://www.gentoo.org/proj/en/devrel/staffing-needs/ ? That page is generated automatically from info on project pages[1]. For more info about ProjectXML writing, check the guide[2]. [1] - http://www.gentoo.org/proj/en/metastructure/projectxml.xml#doc_chap3 [2] - http://www.gentoo.org/proj/en/metastructure/projectxml.xml - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM4chmAAoJEC8ZTXQF1qEPXkkP/3zNt7JzsdbM2Fu4MEWKHhpo 1K/DgS9zpyDS8N2CyjetqEd7mZgUOPkV8uZJLVjo8JM6SCtFhDKpiPjHQmPw1nUg GwlbR4MsS5G3yr3bW+lUIc/pxE0yX34mslPBaGZOWVn4kr3jiyoZgp4UwWjLEXUD Urn/Cm0CQ7DauOzfgjoqMZBnKATiQZM9WOL22ETMLyYBysDT1NkZy1ZE2/vhp4iI 1BUNRqc+eq0DRZ8aAkaTSqcFaRwOD5eSLz30V0wwfYjK3GMTkDXtKv1YOgf2x7Z7 M0/YvmOK0kIWXqFpVE0kF/3L3wgwhLchf7OE2zr7eJffdcSLsb1/RfWqiW1wI7rU 4J/A6kMq1C2QICc8UwvLwVNs500Jy3+DI7L9XzH8IRZ1SivigS1DUYefRK+ttCEH ninqh4UjHGlynT4qoBdfEza2VKSnq87aUER8TsX3SkNaa6lufRKBIfeOjLuCn3ql uMpLYZ9tere+NgXhGLUDjJ3HDgUGE/1dzIDtQHpOLY1GkNF7k8vNSZMWQB9C75J4 elFrEYEqxPVuqTyWU4zn1ClFaaHLLHPTwKBtLtckB51TesnsPLl1F4lj8fFS5j9u sAjSyndnfXefcxqhWg+E4Dk8SNX2/TD2pt/Tlv6j7zRBgponKBdphkUKtaaMh2OA 54cjJizdynp48mTLmQtZ =kPh/ -END PGP SIGNATURE-
Re: [gentoo-dev] Please move your packages to virtual/jpeg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08-11-2010 11:17, Dirkjan Ochtman wrote: On Sun, Nov 7, 2010 at 20:51, Jory A. Pratt anar...@gentoo.org wrote: As some of you are aware libjpeg-turbo is in the tree, with v8 support. We will not keyword for any archs until we officially add the 1.1 release that is not avaliable as of yet. If we all use virtual/jpeg we can ensure that the user has the right to determine what version of jpeg they wish to use. Here's a list of packages that depend on media-libs/jpeg, to make it easier to scan for your packages and see if there's anything you should do. Thanks for compiling the list. kde-base/gwenview kde-base/krdc kde-base/libkdcraw kde-base/libkexiv2 kde-base/okular Done. Cheers, Dirkjan - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM2CHvAAoJEC8ZTXQF1qEP8ZsP/RDxyIIWqNxvNyJP7t0wfl8g bAMXQHvuwnM3puaRcpHnNE2kdfkraXMDKvhZFk13T61qU3ID9iPdOw6Zu78Wc8v2 ajAvdGkNqWNNDRZ0wwB6EWT5c241wMDRoNfoRkBbGgvEABlxk2eQgs+1AT+xdyCc cr9BJUWj+gS3iKCBQ9jlJZlJDpHMjXdHXRrx2+5+YsnwRsjerfiAibFMzNoj1pPR f/gkt2HIgcSVFBjgLONyjrmScAuSdpEWiZaencmCX/NQn9cBM3hp9IU7RaK9Qz6a CU/EootFfeZrohxSO9bo7KunrtOP+mgtpyYjekhCT5RilUDlruljNiYrcLaGcHY0 eXcQVe0C1vd1yOU0dXn1tUIy9FbTMTcLUrj/K8VSKeaGkb5zedsetNLtVWV4xTlZ JFHsX719VH0SK+39D4nQfLDQfExz/z/gC5z5N5MypgVsYcZ9ABZWYR8qIfbU1hmu GUmYuorxqSmEhuUE0act613RSVnZE65Cqr+AT5c/PLIjDK6nZojoTs3yJcc10p51 0hfGw113COSKRJ1j9KUIwPvFQbccKpk71Viy4Z6HcYqMe8jozaNHi+XtpUOWOJVQ bqL9PsFclGd++BnRkNJTrxfAa/LQ6oQPUoXGLog7gRhRR0mZjyonFg1yLnoZJUG0 arIswFOAyebj8zx7qo9F =H2Cr -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrite app-pda/*synce*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04-11-2010 18:34, Samuli Suominen wrote: On 11/04/2010 09:13 PM, Olivier Galibert wrote: On Thu, Nov 04, 2010 at 09:03:13PM +0200, Samuli Suominen wrote: # Samuli Suominen ssuomi...@gentoo.org (04 Nov 2010) # Over 20 open bugs, http://tinyurl.com/2wurbtz # Bugs assigned to a proxy maintainer without CVS access # Every package outdated, bug 340007 # Removal in 30 days The bug 340007 you're citing shows that people are working on adding the next version but are not done yet. What's the point of this masking/removal besides fucking up the installation of people who use the software? OG. Watch your language. Nobody with commit access is working on it, the bug has only comments from users (and a retired developer in CC list). Samuli, there was a very recent thread in this ml about these packages and the conclusion was that they fall to the pda herd. The proxy-user also asked for help and showed interest in working to become a developer. As such, did you contact the pda herd about these packages? Did peper drop the herd from these packages? Waiting more than 1 day to kill these wouldn't hurt us. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM0w4aAAoJEC8ZTXQF1qEPTh0P/1IZK4Gdu7WqJxlL7vSgf2to rSBAljrLDP7Ye6YkDKLVSRooWZDGfI0dkxvjIHEZhuvnekpolLjcct56tKzkPw47 buEyKIfFFyROBL6++brvE1aseSd+FGryqivd424+eYVkxw6tr+2yYWUEnZdFF+pX TBBTn3YxsvIy4KmRErdIoWebjP19Q9QIhJy0FUFBkOTJKKCGXrfptT1NogPHTZ1X XMUU8nBODuYKezw80FHmZ4yURbWMgXMnhz5lQbxgvYH8JMHYpoAbqRF7L4sKtScV I6AnH96dmtKqShGLTvVYunzMhPl+CFjboAHzQw9/A2duRbsIHyxcQKvHTx+NstHp yIwujpLblpXlykjIxwfTztuN2Fc+WfNuHJVdHgypMnj038KenG6jYWRlNs+pzx0T Cws41czGJd0nYbJ9vyN4iC5/ZIQZEccWswcLWFPsZUE2ldoDeNbn89gEA/eZPk1+ qMPxaGoZfc2GZkvj6SSN5GYm0Kc2wxfOs+XZuaNzp0Q0Q406/U7yACXsPeUN7+E9 X3gMkV1RS+/QvnuIhv+qmDrXQSseZIbnSHcd+hUq3G5rKHMc2NCU8mVvS+LuFTot jdqPKjBmdZOU7eRTaMMqLvtXmsJP1dvWLgTWhLNv2c1atH2mK4qQmlQKFJZtw12+ KRmlcpf14+48ryaZg4JP =G9wH -END PGP SIGNATURE-
Re: [gentoo-dev] Changes in server profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02-11-2010 19:30, Markos Chandras wrote: - - ewarn This profile has not been tested thoroughly and is not considered to be - - ewarn a supported server profile at this time. For a supported server - - ewarn profile, please check the Hardened project (http://hardened.gentoo.org). As was stated a few times in this thread, simply dropping this ewarn without adding a warning somewhere that anyone looking for a production server profile should be looking at hardened, doesn't seem prudent to me. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM0J13AAoJEC8ZTXQF1qEPrEAP/3GNLyH67SLszchOL1wjvctE xEZ+yCDrTexXmc1A4YzqYKjVicTXgDdmIPThwD274YTGCfOqCzgOalcTqfHEu6X3 W3044m/YOHi1BeNpNXnLqdyleVFKtDs8YvsZkawUFIgyjMOQ0sKzetyORkk4QE4N 5kr6c4eGN36uIpe2P7viufgvgxAaJwP4k2xsVmVKOpMzGkGLmq8WNeeGTZZ4Jw9O LPD70gI+QBtgYYzqFMB5XMxA2ia4kYJibCrrzC9sqnRpfEStXXXSAWcjUn8aslOw +h4ITENwAqY/exRDLpTHXWpU5SzLz+UU9Y1BG8hKUtKEl++iVjFMn6GePRWjJHA8 mCmkRJ0ku4RscI73qhKjQQdxPEttfvvyfnaS5JdznJMJ/0MyvWV1MMV+j9eKprQq rAnRAZPbe1slh8Egnj2Cd4lik2L9ek3hAyLu0LEvW47IEJyi8LF5Z7ar9hN+ZJw5 IwV22/PYc5g/2Ukl+InHWXjtGrNWx7k3KD5D1O7pwkVnGo5ZRvj0AIgM3u7LWLBb llIFzf1boE6gFen2WgW+GvKngFtX4c8TqBvMLEBs17S3kESSEIzeqCBCuYqAVMEX vXO/En3NwlyiZ4bhfOOSgo3eQvclJKM6yCK6gDb8rfZFUptyIicQF1AkyFQw7mjN Y0UY+STLK4I0oW7bK3Sq =a9yz -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Gentoo's plan to remove .la files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31-10-2010 15:31, Denis Dupeyron wrote: On Sat, Oct 30, 2010 at 10:25 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: As decided in the last council's meeting, following the recent discussions about .la files removal, I'm sending an email to this list with a proposal for a plan to address this issue. 1- Why is a proposal sent to gentoo-dev-announce? Shouldn't that rather be worked out before being announced? Or is there some context that the ordinary user or developer is missing? I sent this purposely to gentoo-dev-announce as this is an important subject and I wanted to give interested parties a chance to be aware of the discussion and to be able to provide input. 2- Sending to both gentoo-dev and gentoo-council makes sure that this splits into twice as many threads as it would have. Good luck with merging them after that. I CC'ed the council alias so all of the council members would get the original email starting the discussion about this proposal. Denis. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMzee3AAoJEC8ZTXQF1qEPHHYP/1rg93mdCLcHdbrmktZ73v+u gQcQxu6hffBLmdstQxO+XkU3hdKt+nwxBIoSGje9yfkwxxxu2zrlkrMBIgv9yKlu sjYUvmgHVBbpZS/qwiFqEXhUhWbkm49X67Ei6Iy5jSWHRhHOiJ56+TfTgIAbRlEv RCWAcF+KpfGnDwR/L+vDnZPxXURmTVqzh5sDm25vCpsUVUYS+5y7tQxia4Z4Lz9P gVzLdvJQSiDZOxLIA7CUGzAHIYbHZjQ4bEBjNECSXjKZSH15fbK+0TxJ7/aBYZph ZLVzawGIjoozdgoN8zfZP0BdL12TRTyFEAxuGDJAEwq+238QNt+f5a22VNLTqStl 1opWaJHJdye8z+PHyaGB1I7FaF+nw1VqFevw7w4MWBx2s0RYA9UNubLPMIg82fY4 i9tIvKl6DyjBd/w/0ApAreL42ZDifGDPdneX1yM77qLtavy4DUbxsGpPUZc9x8rx p7dMlzakDj78YPmvhPCTCq2ZzJPEEgeF+TbhOsnWDRj3OxDiQIA0GrFHqxk7X8nk cOhmFoJMi/uOVCqHxSWfxFF8wQYh0znN8kyD8Xe/6wxEGiZIGDeKkEl4X4zHJg1P m8ZvJzA/j7UKDbXtr3fGj1crdfC1xLxLU/Lz7v/0rqSg11SNgsAfSAdlq5PcQ09D Em7TYvtIUjkb4nq2N5Rm =dwIq -END PGP SIGNATURE-
[gentoo-dev] Gentoo's plan to remove .la files: eutils function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
As outlined in the global email about this issue, this email is to start
a thread about the eutils function. Please reply to this thread if you
have any comments about this point.
1. Add a function to eutils to deal with the removal of the .la files.
delete_libtool_archives() { find ${@:$D} -name '*.la' -delete }
That function was suggested by Diego, but Arfrever has argued that we
should replace : with - as '${@:$D} expands to a subarray containing
elements starting with element with index $D (where element 0 is $0)'.
The point in having this function in eutils is to ensure we use a
consistent way to address the .la files. This will also make it much
easier to adapt or review this function if needed.
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMzPB6AAoJEC8ZTXQF1qEPYDoP/jUmq4pu7xK3rWd8TiK372Sn
uZ/pRiwUgZsOOTV8nvVwA5KjliHPqC0nMCxrZWrWEW6v9+trwPWQFCjQ99AGhgM3
EaOZnFEdTR7w7ybOfSYllGUR/iaquvwg9jUx+QZx4g5Qu6WF8ZkHyHGCYtRJqfQY
+uJyIXbY+FyIW79ss3L7MYaKgdLk8es4AbvAViH9USf6H8oqJeeHoIi60ebdrNcj
Z4vGB5r3pj38lOQVC6c1XxV9xqMsKCCIqx+ftr7gZBrb+82ddCSmRy81gqCm2oo/
9AVBTksbgtFsXJt3GMVzwFtN6rqGrY6iMRYniAr2zb2JdBjQNVzlXDg73tKc0HuX
rLmcK/W4mqGsrOM+Teo/EfPUGeVGrm7xe4bT1wxP4/7/vqRZKOZJuH7zsyAzbFGX
3V4PWArdFxXmTTG8S3++T4BQQcSQ883zbDpLLNoQo7Y860VIORTSWfZIJuyCaLqY
PBsbf1pvCcBB/fw+68SK5cBnDPPhTD6Qpllq4x+2L58FS3GCY8GfHG9JQo7jBd1q
qlcKx2L8aD+/zmHD7RgzIEUYLFPdwXCyM55sRyQcclrxPO8SNxmDMu2LFB0UhEbh
FFBrSMlzmXt9l5WrbIUrzmALLgj0YdhYbbPNdrFXoyb2gfgqeQtNHHu8RyljPen/
/qgNo/sOuioLkrzAFNM+
=bYty
-END PGP SIGNATURE-
[gentoo-dev] Gentoo's plan to remove .la files: QA document
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. As outlined in the global email about this issue, this email is to start a thread about the QA document. Please reply to this thread if you have any comments about this point. 3. Add a page to the QA project space (unless they're not interested) about la files and how to deal with them I think we can ask Diego to use large parts of his blog posts and charts about .la files[1], [2], [3], [4] as a source for the document. We can also add some basic info from the autobook[5], [6]. The goal would be to have a document similar to our own --as-needed guide [7] and to other distributions[8], [9]. Anyone wishes to volunteer for this task? QA would such a document be welcomed in your project space? [1] - http://blog.flameeyes.eu/2008/04/14/whatabout-those-la-files [2] - http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later [3] - http://blog.flameeyes.eu/2009/07/06/identifying-pointless-la-files-for-plugins [4] - http://blog.flameeyes.eu/2009/09/28/removing-la-files-for-dum-w-uncertain-people [5] - http://sources.redhat.com/autobook/autobook/autobook_11.html#SEC11 [6] - http://sources.redhat.com/autobook/autobook/autobook_68.html#SEC68 [7] - http://www.gentoo.org/proj/en/qa/asneeded.xml [8] - http://wiki.mandriva.com/en/Libtool_archives#shared_build [9] - http://wiki.mandriva.com/en/Overlinking - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMzPFhAAoJEC8ZTXQF1qEPw84P/i8tpOguja80XDIpB68ewgcU O2lRYlvVA8LRPbcl2pBXnefHH4BtO2h1AHhjlOBO3upu/RGdP7IFR0Q5T8DLKr3O UZLoK4oGxYct053Ehp1WP2zhtQaRcDUcBzyyPEr7YdVl9oTud1dHplcojx/jas3r H3aXhBkMVE1s2PUXUfrLMz5WqAlSpDxkk+LVpWe6cvMjsZ2BqclYNXGKcKjldx0l GzzJO+nSyeFQ/Udn4dEO60ORhX6/2G9cGnBCWWDVAuTuht1+i6M8LxtJwVYlOg+c JQ1P9PFq6zLgNGOE122Bgzox+7wMPwsh+ja54mg6XK2YjeQ1jOGTLAitwwqL9BOk isCS0VTkzBhvJcOqzatVMGt/iDBa8zXOItl1nX3PQPnw07SsxqGGsZJWj8+gf0o0 heY9tbFnSMvMwVd7gKSpq80NVZ4mSlfZXKWkUWgatg3OLXF+A7sJhAxA16K9TU9x BaNADGfizC33z4JRLUNrtcocNoVFQWr6/OGybAkAn2JKGHEOuvhmupQET0b0qf18 qsG6unuv7DX93uCNkKxL+9qhghO8E3I1BWlecTXhdPJiD0cisxgYnoFrZ/F9aHbl FlYytKUH3bCiLuKy1RmkAG+YRjH4vYyIe9tTM+brBvU/NAJpbN4b36oUmOmj8Kdv JmT/C5sBOes+5QEV3X49 =czVz -END PGP SIGNATURE-
