Re: [gentoo-dev] Repository stacking and complementary overlays
Le lundi 02 mars 2009 à 23:59 +, Ciaran McCreesh a écrit : On Tue, 03 Mar 2009 00:55:38 +0100 Gilles Dartiguelongue e...@gentoo.org wrote: We didn't implement anything but let's just talk about what we wanted to see. We simply wanted overlay users to keep testing gnome 2.24 components that were masked or using masked packages in base/package.mask so we just made sure those packages had the proper keyword visibility. So if you could mask 'testing'ish things that're in the overlay (already possible), well there was nothing masked in the overlay really, for 2.24, because the overlay is for testing stuff already. Let me try to rephrase and see if I can make it clearer. Although we moved some packages to the tree, some packages didn't ended up moving because they needed more testing or huge regression fixing patches but they were masked by gentoo-x86 masks because of their dependencies. Hence the mask reverting in overlay. and provide an easy, consistent way for users who choose to to unmask and keyword a particular group of packages, would that solve the problem? wrt to previous point, it would probably help a great deal even though I'm not sure it would completely solve this case. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Git eclass update
Tomáš Chvátal a écrit : Hi, I am currently messing with git.eclass and i would like to see some other sets of eyes on it. I am throwing in full new eclass [1] and its diff [2]. I will be really happy for comments and even more for diffs :D Oh and by the way, the diff looks nice to me. Maybe we could put it temporarily in the X11 overlay, it'd get a lot of testing in there. Donnie, what do you say? Would running emerge --regen be too much inconvenience ? Cheers Rémi
Re: [gentoo-dev] Git eclass update
Tomáš Chvátal a écrit : Hi, I am currently messing with git.eclass and i would like to see some other sets of eyes on it. I am throwing in full new eclass [1] and its diff [2]. I will be really happy for comments and even more for diffs :D Does/Can it fix bug #247187 ? Or is it something that needs to be fixed in each Xorg ebuild or in the x-modular eclass? Cheers :) Rémi https://bugs.gentoo.org/show_bug.cgi?id=247187
Re: [gentoo-dev] Git eclass update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomáš Chvátal wrote: I am throwing in full new eclass [1] and its diff [2]. Errr, maybe it's my eyes, but it looks as though the new eclass isn't the same as the existing eclass with the diff applied (for instance, git_src_prepare doesn't get called in the diff, but does in the new eclass). Also, base_src_prepare doesn't get exported if EAPI != 2, so I'm not sure what happens when it gets called from git_src_prepare (which can be called when EAPI = 0|1). Has anyone actually tried this on a non-EAPI2 ebuild? Lastly (and this happened in the old eclass, but I figured since it was getting an update now would be a good time to fix it), because checking out uses --depth 1, it's possible for a checkout to fail (specifically if EGIT_BRANCH/EGIT_TREE is set on first checkout) since the required commitish may not exist in the shallow copy. The error messages thrown out are along the lines of not a tar file, but I believe the ebuild continues, until it doesn't find the unpacked source. The possible fixes would be to: a) ask git to clone at a specific commitish (although I can see how to do that in git clone --help) b) see if there's a specific commit set, and then clone the whole tree c) see if there's a specific commit set, and if so trap the error message and offer a useful warning like remove the repo and set EGIT_FETCH_CMD='git clone --bare' Unfortunately a) and b) don't solve the problem of a specific commit being set by a user after the initial clone's taken place (in which case, if it's not in the clone there'll never be a way to get it from that checked out copy). Perhaps on an error during an update could clear out the git repository from distfiles/git-src and try again without a --depth? Clones made without a --depth entry that then fail would be an actual fail... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmuZk4ACgkQu7rWomwgFXoZ9wCbBh2BH7ERu+Ck/0W0IkLxHPU4 GW4An1DMBJ2rK+Hkb92U571QegW+VDhQ =aB2B -END PGP SIGNATURE-
[gentoo-dev] Re: How to speed up maintenance and other Gentoo work?
On Wed, Mar 04, 2009 at 04:01:36AM +0200, Mart Raudsepp wrote: I'm collecting ideas from the wider development and contributing community on how to help maintainers and contributors get work done quicker, or rephrased - how to get more done in the limited time we have. Give a git access to the developpers beside the current CVS ? -- Nicolas Sebrecht
Re: [gentoo-dev] Git eclass update
Dne středa 04 Březen 2009 11:22:54 Rémi Cardona napsal(a): Tomáš Chvátal a écrit : Hi, I am currently messing with git.eclass and i would like to see some other sets of eyes on it. I am throwing in full new eclass [1] and its diff [2]. I will be really happy for comments and even more for diffs :D Does/Can it fix bug #247187 ? Or is it something that needs to be fixed in each Xorg ebuild or in the x-modular eclass? Cheers :) Rémi https://bugs.gentoo.org/show_bug.cgi?id=247187 As i said on irc. It can be done by simple array PN-HOMEPAGE. :P But of course somebody have to write that array down :D Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Git eclass update
Dne středa 04 Březen 2009 11:29:44 Rémi Cardona napsal(a): Tomáš Chvátal a écrit : Hi, I am currently messing with git.eclass and i would like to see some other sets of eyes on it. I am throwing in full new eclass [1] and its diff [2]. I will be really happy for comments and even more for diffs :D Oh and by the way, the diff looks nice to me. Maybe we could put it temporarily in the X11 overlay, it'd get a lot of testing in there. Donnie, what do you say? Would running emerge --regen be too much inconvenience ? Cheers Rémi It might be good idea to add it to the x11 overlay, but i would need access there cause it would be really inconvinient to bug you around for every change i would like to do :] Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Git eclass update
Dne úterý 03 Březen 2009 20:47:28 Tomáš Chvátal napsal(a): [2] http://dev.gentoo.org/~scarabeus/git.eclass.diff As for now the diff is really obsolete so use direct link and make diff yourself (sorry but i preffer fast including patches :]) Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
Bugzilla is a tool for developers to track progress, not for third-party distributions to track progress. You've forked the tree. That's fine. The license allows that. But it doesn't obligate us to adapt our tools to fit your purpose. I've done lots of version bump bugs over the years. my reasons for doing so may have changed. But the general process has not. Does it matter if I've forked? doesn't the package still need an update? Your behavior on bug 260582 was clearly unacceptable. You seem to think that we owe you something. Please re-examine your premises. Donnie already told you he was working on it. Our job is not to support your distribution. It is to make the best distro for ourselves. In the case of xorg-server, that means getting something into the tree that works. A masked ebuild will in this case be more bother than it's worth because the mask would have to encompass a bunch of other packages. Which leads me on to the next paragraph... this and all the cases given are examples, and perhaps my behavior was unacceptable. But I think the response to my bug was too. No gentoo doesn't owe me or regen2, a thing. It might, however, owe users something. I agree on committing ebuilds that work, that doesn't mean I don't have the right to open a bug and watch for progress reports. In many cases that's true, but on average, the QA of the tree is much better than overlays. I couldn't say... I suppose I agree yes on most overlays, but a few are supposed to be more 'exceptional'. the biggest problem is the bugs that result between ebuilds in the tree and those of overlays. like one I filed on virtual/perl-Mime-Base64. or like how inkscape won't build against 5.10, except with patches already in bugzilla, but both cases seemed to be one of 'perl 5.10 isn't in the tree so we won't fix' I think they should put it in before 5.10 is in the tree. put that's just me. We Need Git. It would really ease the workflow of accepting user contributions if users could just set up their own overlay and sent me an email asking to merge their changesets. git's great. but I've actually found 'merging' changesets to be a bad idea from people. It can lead to some really sloppy commits, and merging is a less stringent review than cherry-picking patches. You could have made thousands of commits already, fixing a substantial amount of the problems you've raised. thousands seem like a high number. I think I've been pushing an average one 1 patch per day since january to the tree (my tree). *laughing* I'm still the #1 contributor of git patches to funtoo. This isn't a quick fix. You'll have to work with people and that can sometimes be frustrating. I already have to 'work' with these people, the difference would be what? how much respect I get? in gentoo land having @gentoo.org seems to mean something... if you don't have that, you seem to auto-magically get less respect, than you would if you did have it. But you'll get to be part of the development process and you'll get to work with the things you care about. you mean I'll be part of 'a' development process and work on some of the things I care about. Obviously stepping on other developers toes seems to be a taboo. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
On Wed, Mar 4, 2009 at 8:59 AM, Thomas Anderson gentoofa...@gentoo.org wrote: eh, that's the problem with ~arch. ~amd64 keywords aren't added for every new version; keywords are carried over from the previous version. Having to test each new version of a package before it receiving a keyword puts far too much stress on the arch teams I'm not talking about testing before... I was talking about removing it after. I understand that not everything can always be tested before. But when it's found to be broken, there shouldn't have been an argument about the kewords removal in lieu of a proper fix. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Caleb Cushing wrote: I'd like to start with, I'm not trying to stir up trouble but since questions were asked i'll answer them. If you think neither should exist why do you have an opinion about this at all? I merged the java-overlay into regen2 a couple of weeks ago. as of right now I've no plans to support java-experimental. I'm fine with overlays so long as working ebuilds spend no more than a few weeks in them. I have my own development branch and half the stuff that's in there that isn't in the main tree doesn't work. Things like perl 5.10 have been rotting in an overlay for a year. Funtoo ( under my direction ) and Regen2 have had it ~arch for over a month now. We found one bug post release thus far. I filed a bug on xorg-server 1.6.0 not being in tree. It was resolved fixed (in overlay) (which another bug clearly states it has amd64 build issues). since when has (in overlay) been an acceptable solution to a missing package? I said it before, the reason I like gentoo* distro's is I don't have to find the repository to get the latest package, that's just a pain, in ubuntu, in opensuse, in fedora... etc. But no more... officially supported huge overlays have ruined this. The single tree model is not the only one, nor necessarily the best one. I understand your concern, but as ciaranm argued in another thread, the issues many people seem to have with overlays are caused by the current level of support by Portage. What we need is better support for multiple repositories, not to drop them. As it has been discussed before, multiple repositories could even foster the development in Gentoo, instead of halting it down - as quite a few people seem to be affraid of. If we can have some repositories focusing in certain areas or relaxing access rules to a few repos, some devs might get more focused and some packages might find new maintainers and or their way into mainline Gentoo. One issue that has been raised is about having testing ebuilds in overlays instead of the tree. In a few cases, we have ebuilds in overlays, not because of the lack of QA of the ebuilds, but because of the experimental nature of the packages or because of the difficulty in making packages comply to Gentoo rules. One example of a package that was never in the tree, but instead on an overlay was XGL. It was never considered to be stable enough to get into the tree. KDE-4 work started in overlays and was kept there until 4.0 because it was more flexible to work in the overlay than it would have been to do it in the tree. By the way, KDE-4 is a good example of how work in overlays can help the tree - what we had for 4.0 and have now in the tree was mostly done by people that weren't Gentoo devs. Work in these overlays has lead to an injection of many new devs. ... users don't know how to hack. the very definition of user says that, imo. There are developers, admins, and users. admins don't want overlays, they are supposed to be unstable. users can't hack, so what do they care. the problem is, an overlay has become a repo, I'm not sure that it was originally intended for that. Fortunately, Gentoo users are not like some other distributions users. I've seen many Gentoo users working in ebuilds and quite a few working with devs to improve the Gentoo tree. Most admins don't like unstable packages. Unfortunately quite a few of them have to support new (testing) packages whether they like them or not. ... Further, overlays are good places to put ebuilds for software that is more experimental than what's expected for ~arch. That includes live ebuilds. In the end, overlays have a (far) lower level of guaranteed quality than the main tree, for their ebuilds because ~arch is supposed to work? take open bug on wine-1.1.16 it doesn't build on amd64 and yet it's ~amd64. how about that nam ebuild that has invalid bash that I mentioned? that's some quality work there. The point is the tree is no better or worse than the overlays in many cases. If anything, I've been hearing lately complaints about the testing branch having become the new stable branch, not that it's terribly broken. ... I've probably already offended a large share of people on this list, now lets see if I can offend a few more by soliciting. I think you'll find a reasonable tolerance level in this ml about technical issues and development models. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmvJroACgkQcAWygvVEyAJtEwCfYNY1EuJ4/ZEKOGBtKDX7VtOm mtYAniAof1AWL5GMVtpbpZ1g6LCKf7GS =i3Gl -END PGP SIGNATURE-
Re: [gentoo-dev] QA Overlay Layout support.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wulf C. Krueger wrote: On Monday, 02. March 2009 10:29:59 Jorge Manuel B. S. Vicetto wrote: Also, having separate overlays would allow one to do experimental stuff with eclasses in the experimental overlay without affecting users of the base overlay. Until we get versioned eclasses, I don't see how one can do that with a single overlay. You've used it yourself before in GenKDEsvn. :-) We have a private git repository for development. Any commit in its master branch gets auto-pushed by a simple hook to the public repository which is the overlay. That's one way to do it and as you say, we've used it before successfully. An alternative could be to use different branches in the same repo. We've used it before in the KDE git overlay, but it can get tricky. In some cases though, one might want to make the experimental work available to some users (with a big fat warning). The above alternatives don't allow this or make it complex. One of the reasons we had to split the work in the 2 overlays was to move the live ebuilds to the experimental overlay so that casual users wouldn't be affected by them. Any other branches in the private overlay stay just there. They're not publicly visible by default but they *can* be published for guinea pigs who feel like suffering. Once the the experimental stuff is safe enough for the public overlay, merge that branch to master and - swoosh! Best regards, Wulf - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmvMGEACgkQcAWygvVEyAL0FACfemf/O3oCw4A1ZTIgOEMOFk8l WNIAn21IHSdV5R4dLJZY0/yXwirI3sQi =Pm+a -END PGP SIGNATURE-
Re: [gentoo-dev] Repository stacking and complementary overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jorge Manuel B. S. Vicetto wrote: This seems desirable and reasonable. As I replied to this subject earlier regarding KDE, let me complement that information. In the case of the KDE team, we keep work on a release all in the same place, so we don't need to unmask some KDE packages in tree for those using the overlay. However, we some times have deps on packages from other teams and or in other overlays, so I hope the repo deps would help here (not to unmask those packages, if they're masked, but to add a dep on a particular repo and allowing the PM explain to the user that he/she needs to unmask a particular version in the tree / overlay). The problem with repo deps is that they're too restrictive since they assume that only a specific repo can satisfy the dep. Suppose that you migrate some of the packages from the overlay to the main tree? Now you've got installed packages that are trying to pull in deps from the wrong repo. Or suppose that somebody else has an overlay with a compatible package? I think a better way to reference another repo is with the layout.conf approach suggested in the QA Overlay Layout support thread [1]. For example, if packages from the java-experimental repo depend on some ebuilds or eclasses from the java-overlay repo, it's specified via a masters entry in layout.conf. If any of those ebuilds/eclasses happen to migrate to the main tree then the migration is seamless. [1] http://archives.gentoo.org/gentoo-dev/msg_33c61550b4ed2b7b25dd5a4110e1ec81.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmvMcIACgkQ/ejvha5XGaNmkwCePw/XjWCqZtIXq5yXQ4gpHALL fXUAoMqkmJ30Go2SJaqS2lzs+8axyLwn =ju66 -END PGP SIGNATURE-
Re: [gentoo-dev] Repository stacking and complementary overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: Jorge Manuel B. S. Vicetto wrote: This seems desirable and reasonable. As I replied to this subject earlier regarding KDE, let me complement that information. In the case of the KDE team, we keep work on a release all in the same place, so we don't need to unmask some KDE packages in tree for those using the overlay. However, we some times have deps on packages from other teams and or in other overlays, so I hope the repo deps would help here (not to unmask those packages, if they're masked, but to add a dep on a particular repo and allowing the PM explain to the user that he/she needs to unmask a particular version in the tree / overlay). The problem with repo deps is that they're too restrictive since they assume that only a specific repo can satisfy the dep. Suppose that you migrate some of the packages from the overlay to the main tree? Now you've got installed packages that are trying to pull in deps from the wrong repo. Or suppose that somebody else has an overlay with a compatible package? I agree repo deps might be restrictive, but in some cases we might really want to be restrictive. For instance, I might want to have a dep on a package in the GNOME official overlay - I might not want to get the version in some other overlay listed in layman. When the package moves to the tree or if work moves to another overlay, then sure, it will mean more work. But sometimes that might be preferred. I think a better way to reference another repo is with the layout.conf approach suggested in the QA Overlay Layout support thread [1]. For example, if packages from the java-experimental repo depend on some ebuilds or eclasses from the java-overlay repo, it's specified via a masters entry in layout.conf. If any of those ebuilds/eclasses happen to migrate to the main tree then the migration is seamless. I like this proposal as well. I think repo deps and master layouts are complementary and not alternatives. Getting back to KDE (sorry for being so self-centered), we would make the kde-experimental overlay have kde-testing as the master overlay. So we could do some work in eclasses in kde-testing without needing to copy them to kde-experimental. [1] http://archives.gentoo.org/gentoo-dev/msg_33c61550b4ed2b7b25dd5a4110e1ec81.xml - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmvNhUACgkQcAWygvVEyAJTDwCfeFwqVMtUY4r+BR5mX6kyGhuk tTAAoJG0kQksJnVM6Fd/WwPHxJmBJZoi =eSaw -END PGP SIGNATURE-
