Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 06-08-2011 16:36:00 +0100, Markos Chandras wrote: I like your proposal but please clarify the following two questions 1) Each package requires a new repository. Who is responsible to create that? Should developers be responsible to do that or they should ping infra? I would prefer all ebuild devs to be able to create new packages (repos), like they can right now. 2) Assuming the repository for a new package was created. Who is responsible to include this in the rsync generation file? The dev in question that wants it to be added to the rsync tree. I think your approach requires centralised administration to ensure minimal incidents in the infrastructure mechanisms. Absolutely. Typically the rsync generation file is in its own repo, and requires as much centralisation as the current CVS tree, or the proposed git variant of that tree. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 07-08-2011 00:07:41 +0530, Nirbheek Chauhan wrote: On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen grob...@gentoo.org wrote: In short, the repo-per-package model means that each package (my-cat/package) is a separate repository in some VCS. Instead of having a huge tree that will only grow forever (gx86), packages are just in their own repository. I had mixed feelings while reading your email. The idea is certainly very intriguing, but there's a few things that make it a no-go for me: 1. One of the big things I've been looking forward to with git is the ability to do atomic commits across the tree. Addition of GNOME releases, pkgmove changes across the tree, changing ebuild/eclass behaviour, etc. without inconsistency or praying that my connection doesn't get dropped in the middle of a hundred interrelated commits. Without this feature, I think some arch teams and GNOME/KDE teams will become sad. I see this being possible by making a single commit to the rsync tree generation script. I also consider alternatives possible, as touched upon by James Cloos in this thread where large projects like GNOME and KDE have a single repository for all/most of their ebuilds, and perhaps even eclasses. Repo-per-package may be too finegrained for projects like these, and being flexible here is not going to be any problem AFAICT. 2. The ability to do feature commits across the whole tree instead of hundreds of tiny commits everywhere. This combined with the ChangeLog generation will save a lot of time and space. This will especially benefit arch teams, but I've felt the need for this numerous times myself. Example: we moved to using .xz tarballs for GNOME, and that touched a lot of ebuilds, and it was extremely time-consuming to repeat echangelog repoman commit per-package. Consensus is that echangelog is eventually going to disappear, IIRC, and repoman commit probably can be done on the entire tree/repo, with the help of sub-repos, or when you have a repo for full GNOME. Whether you script a loop, or make a single call to repoman, you always have to pay for running repoman, since it's your QA tool, that you're not supposed to skip/bypass. 3. Adding packages from overlays via `cherry-pick` or `git am` will become extremely tedious. If thin manifests are implemented, a series of patches + a simple merge hook will be all you need to move KDE/GNOME releases from the overlay to the tree. Without a single tree, you need to go back to the current way of doing things. With my proposal you wouldn't do this. You would simply add a line in the rsync tree script for including that package. Most probably the package would already live on g.g.o or something Gentooish, so it wouldn't move at all, it would just be included. In case you would have a repo with multiple packages, you would just tell the script to now also include the directory where your package lives. 4. We'll need to write extra tools to keep the user's cat/pkg list up-to-date; adding and removing repositories as needed, etc. This is added complexity for which we'll need volunteers (we've been facing a manpower shortage already...) I don't understand this. Users don't see anything of this change. Developers could use subtrees, forests, or just only what they care about. 5. The total size of the tree will increase a *lot* since all these repositories will no longer share data. The current gentoo-x86 tree stored in git without history takes only ~25MB because ebuilds are extremely redundant. The space requirements will balloon once we need to store 15,000 repositories. And arch teams will have to store *all* of them, often on devices with very low space. I'm not too concerned about disk space. Cloning a repo as-needed should be fairly fast, and even arch teams won't need all 15,000 repositories. It's easy to throw away repos for packages no longer necessary too. For the limited disk-space arches, the specialised rsync trees do come in handy though. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 06-08-2011 16:17:32 -0400, James Cloos wrote: Your idea is a step in the right direction, but the ideal config would have a top level portage.git with sub-modules for each category, as well as for eclass, licenses, profiles and scripts. Each category.git should have sub-modules for each package therein. I believe the size of a repo (how much it contains) should depend on what it is. Some packages (like e.g. Mutt) live very well on their own, I understand larger projects like GNOME and KDE prefer to have many sub-components in one repo. I don't necessarily think there should be a clear hierarchy, although subtrees may require that. Within the profiles.git it *might* be reasonable for each directory in arch/ also to be a sub-modules. Or not. That should be dicussed. And the bureaucracy should be minimal. Adding, changing or removing a submodule from its parent repo should only require a call for consensus among the devs, and not be pushed through a small set of devs on some given team. Currently, all devs can add and remove (with notice) packages, so I don't see why that would require a consensus with this model, suddenly. It may also be useful for the process which generates metadata/ to push out to a repo, too, just before syncing out to the rsync mirrors. I don't understand what you mean by this. Can you elaborate? Having each package in its own repo is a great idea. But a simple recursive git pull to update the whole thing is highly desireable. Git submodules fit the bill perfectly. I assumed something like this possible to be able to get all easily or something. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 06-08-2011 22:42:33 +0200, Krzysztof Pawlik wrote: To be honest I don't like that idea. I don't see any benefits from doing so: - tree generation is dynamic - actually I think this is a disadvantage, it has a nice potential to eat a lot of resources on master rsync server, also having different flavours of the tree only brings in added complexity To be honest, I don't see any problem there. The rsync master server is a modern machine. Generating multiple trees, hardly takes more since all repos in use are shared, of course. With the prefix rsync tree generation [1] in mind, I think the extra cost timewise aren't too bad either. So: - having it all in single repository means that I need to care only about one thing, not around 14956 of them subtrees would help you here - git was designed to be efficient with large repositories, use this ability I'm not claiming git is inefficient. I think our current model is not very flexible. An alternatives like the one I proposed solves certain problems that currently exist within Gentoo. [1] http://stats.prefix.freens.org/timing-rsync0.png -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 06-08-2011 20:55:05 +, Robin H. Johnson wrote: On Sat, Aug 06, 2011 at 04:13:52PM +0200, Fabian Groffen wrote: In this email, I step away from the current model that Gentoo uses for the gentoo-x86 repository. Instead, I consider a repo-per-package model, as in use by e.g. Fedora [1] and Debian [2]. Everything you have mentioned here was previously covered in the discussions about Git conversion models. Please consult the history of this list, as well as the -scm list. Additionally, a large discussion about the pros and cons of all 3 models (package per repo, category per repo, single repo) was had at the GSoC mentor summit last year, and a number of the core Git developers were involved in the discussion. I see now my previous search wasn't complete. Please correct me if I'm wrong, but I have the impression the previous discussions looked at repo-per-package just from a storage point of view, not from a functional point of view. The git overhead for repo-per-package is admittedly quite undesirable. Problems: - atomic/well-ordered commits that span packages, eclasses and profiles/ directories. (Esp. committing to eclasses and then packages afterwards). This can be done with a single commit to the rsync tree script, and it doesn't necessarily need git repos. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On Sun, 7 Aug 2011 11:12:47 +0200 Fabian Groffen grob...@gentoo.org wrote: Problems: - atomic/well-ordered commits that span packages, eclasses and profiles/ directories. (Esp. committing to eclasses and then packages afterwards). This can be done with a single commit to the rsync tree script, and it doesn't necessarily need git repos. And have you considered the function PoV on this? With clean git repo: few commits, git push With your split-tree: a lot of commits to random packages, potentially using random VCS-es, a lot of pushes, hacking some magical rsync stuff and finally guessing what went wrong this time -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 07-08-2011 11:21:51 +0200, Michał Górny wrote: Fabian Groffen grob...@gentoo.org wrote: This can be done with a single commit to the rsync tree script, and it doesn't necessarily need git repos. And have you considered the function PoV on this? With clean git repo: few commits, git push With your split-tree: a lot of commits to random packages, potentially using random VCS-es, a lot of pushes, hacking some magical rsync stuff and finally guessing what went wrong this time Ideally, only one VCS would be in use. For the current situation there is both CVS and git, though. With some experience from the Prefix rsync tree generation (CVS + SVN), I can tell the magic is quite absent, and I've seen no guessing what went wrong this time. I have considered it. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] contribution to colorgcc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/07/2011 01:48 AM, Dmitry Goncharov wrote: Greetings, Is anybody maintaining dev-util/colorgcc? I'd like to contribute certain improvements for gcc and also support for the sun, ibm, hp and intel compilers. I pushed the current version to https://github.com/dgoncharov/colorgcc. You can pull from there or i can submit a set of patches. regards, Dmitry The best way to submit such improvements is using https://bugs.gentoo.org - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOPlzrAAoJEPqDWhW0r/LCY+kP/3eD3Fp0sbPwGTrR/I49LxJE rjIJm+i7tUdbh8WRrkuOOGPd1zp8iaXZfZXy9bnU2UovoQ7tyU/Itaut/jx5c1qZ c+v0p6jJ6yZwXZhKKoRG8wH5QMspRVMZddiq/a18VfI5931VLPg4EdKxQ2oiR2SK KH4WM1O/Zkdfi4/ZOWAftKeIv+vKNJXHIQWCHO+oAca6vSsGgOGcvElLgkp9+D9G 4Vnlt5NDOcnlNJP8NZvyUIfL+zsgK0ETcX/mNCk78FdARsJKdiU9DCfrHfhovYTC PW9aBAMOt+5z4r0Rbpz6hXfiRtNopXdWw9Kw/iOt+kXlpI16gW/4sZXvTJ0/n1ei uNnIqGky98th+H4YzBVf1jpoDd20GUsuMM7DLVRPYXtKMT7hbZV6A0o6OCfQFkse m1tTBupYS14rOvmWzYRWN3jRkMdJegvAUNRFRQht1tTtBb0vOoe/4ToWFiLRN7SY 574ljDgPsfQtGNG6AwayyXVbRfykTOdPjJgmPthIZvxuszQCSoJj8edlCL5bmyiB 9ZIdNF+z9J+CYVqomSuEkaRPod7nySPbQkys3SM1gktILDipJEknGoIi2kyORrj4 42q2e+91zjlMP+5vyPMSchzVRxWHBN7M2HGWrHt3xX3l8z1ymyxcRF/sq8heN7Z2 Kj0kwPCicNTE3xYo64BM =dpIW -END PGP SIGNATURE-
Re: [gentoo-dev] contribution to colorgcc
On Sat, 6 Aug 2011 20:48:09 -0400 Dmitry Goncharov dgoncha...@users.sf.net wrote: Is anybody maintaining dev-util/colorgcc? I'd like to contribute certain improvements for gcc and also support for the sun, ibm, hp and intel compilers. I pushed the current version to https://github.com/dgoncharov/colorgcc. You can pull from there or i can submit a set of patches. I suggest you start with pinging upstream. The homepage [1] indicates the project is on github too [2], so I guess you can go with a pull request if you forked it. [1]:http://schlueters.de/colorgcc.html [2]:https://github.com/johannes/colorgcc -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] contribution to colorgcc
On Sun, 2011-08-07 at 11:45 +0200, Michał Górny wrote: On Sat, 6 Aug 2011 20:48:09 -0400 Dmitry Goncharov dgoncha...@users.sf.net wrote: Is anybody maintaining dev-util/colorgcc? I'd like to contribute certain improvements for gcc and also support for the sun, ibm, hp and intel compilers. I pushed the current version to https://github.com/dgoncharov/colorgcc. You can pull from there or i can submit a set of patches. I suggest you start with pinging upstream. The homepage [1] indicates the project is on github too [2], so I guess you can go with a pull request if you forked it. Also, please use github's fork feature, so you don't lose the entire history. And, like Michał said, you really should take your changes upstream, they seem pretty active (last commit in June). They also quite often accept pull requests if you look at the history. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On Sun, Aug 7, 2011 at 5:12 AM, Fabian Groffen grob...@gentoo.org wrote: On 06-08-2011 20:55:05 +, Robin H. Johnson wrote: Problems: - atomic/well-ordered commits that span packages, eclasses and profiles/ directories. (Esp. committing to eclasses and then packages afterwards). This can be done with a single commit to the rsync tree script, and it doesn't necessarily need git repos. What exactly are you thinking about here. How about this use case: I have a list of 150 packages/versions. I want to make all of them go from ~x86 to x86 at the same time. If they're all in one git repo, then I can use a script or whatever to go through every one at leisure and rekeyword them. Then I can do a repoman scan on the entire repository for an hour or two if I want. When I'm happy I can commit everything atomically. How do you envision doing this by just making a single commit to the rsync tree script if the files are in multiple repos? Right now that rsync tree is pulling in all those files already - in the ~x86 version. Do you propose cloning all the repos, fixing the arch flag in the new repos, and then re-pointing the rsync tree atomically? That would work, but any commits to the 150 packages by others in the meantime would get lost, and it seems a bit painful to do it this way. I can see how you could atomically add or remove 150 packages entirely, but not how you can tweak individual versions of packages without a fair bit of pain. Admittedly, you could have some clever solution in mind that I'm just not grokking. The other thing that was tossed out is having multiple repos, but putting things like kde/gnome in their own bigger repos. I'm not sure this is going to work, since it only works for those particular situations. A package can only be in one repo, so you can't have one repo for kde, and another repo for everything that uses qt, and another for everything that uses pulseaudio, or whatever. Atomic changes to many packages could be required for any number of unforseen reasons. I can see the elegance of allowing the portage tree to be a collage of packages from different sources, but I'm not convinced we really need this. Users can already accomplish this on their end with overlays. It seems like we're just making the portage tree an overlay of its own. I'm not sure what it really buys us. Just using git in the first place already simplifies distributed development. If you took this idea to an extreme you might not have the rsync server assemble the tree at all, but just push out the official list as a recommended list of overlays, and let the users put their own trees together (with the ability to override parts of it). Rich
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 07-08-2011 07:05:03 -0400, Rich Freeman wrote: What exactly are you thinking about here. How about this use case: I have a list of 150 packages/versions. I want to make all of them go from ~x86 to x86 at the same time. If they're all in one git repo, then I can use a script or whatever to go through every one at leisure and rekeyword them. Then I can do a repoman scan on the entire repository for an hour or two if I want. When I'm happy I can commit everything atomically. How do you envision doing this by just making a single commit to the rsync tree script if the files are in multiple repos? Right now that rsync tree is pulling in all those files already - in the ~x86 version. Do you propose cloning all the repos, fixing the arch flag in the new repos, and then re-pointing the rsync tree atomically? That would work, but any commits to the 150 packages by others in the meantime would get lost, and it seems a bit painful to do it this way. I can see how you could atomically add or remove 150 packages entirely, but not how you can tweak individual versions of packages without a fair bit of pain. Admittedly, you could have some clever solution in mind that I'm just not grokking. Not sure. You could branch I guess. It takes more work, undoubtedly. The other thing that was tossed out is having multiple repos, but putting things like kde/gnome in their own bigger repos. I'm not sure this is going to work, since it only works for those particular situations. A package can only be in one repo, so you can't have one repo for kde, and another repo for everything that uses qt, and another for everything that uses pulseaudio, or whatever. Atomic changes to many packages could be required for any number of unforseen reasons. This indeed makes it difficult. I can see the elegance of allowing the portage tree to be a collage of packages from different sources, but I'm not convinced we really need this. Users can already accomplish this on their end with overlays. It seems like we're just making the portage tree an overlay of its own. I'm not sure what it really buys us. Just using git in the first place already simplifies distributed development. If you took this idea to an extreme you might not have the rsync server assemble the tree at all, but just push out the official list as a recommended list of overlays, and let the users put their own trees together (with the ability to override parts of it). I don't feel users should be playing with these things in general. I see the tree assembling thing more as a technical way to deal with some given legacy and limitations. Admittedly, it isn't perfect, and many people seem to intend doing things with a git-based tree that cannot be done with now CVS, and an assembled tree wouldn't really support it out of the box either. -- Fabian Groffen Gentoo on a different level
[gentoo-dev] [RFC] subprofiles for ARM architecture
Hi, The other day Markus(maekke) found an issue i encountered two years ago. An app supports only a subarchitecture of the ARM architecture. For those that don't know the ARM architecture, its an architecture which is mostly used on embedded and/or mobile devices(cell phones, mostly), also there's now some stuff called smartbooks(Efika MX smartbook, Asus Transformer, etc...) and smarttops(Efika MX smarttop). The problem is that during the history of the ARM architecture(according to the wikipedia, the architecture was introduced back in 1981) there has been some subarchitectures(the most available are armv4, armv4t, armv5t, armv6j and armv7-a) which include new functions that is not available on the previous subarchitecture. Something like SSE, SSE2, SSE3, etc... but in arm is called SIMD, NEON, etc... Apart from that, there are some apps that only work in one subarchitecture because it uses some capabilities only available on that subarchitecture and newer. Which is the case of valgrind. It only works with armv7-a. Also there's www-client/chromium, which later versions only work on =armv6j. With subprofiles we could keyword such packages, mask them globally on arm and unmask it on the subprofile of the subarchitecture that supports it. We build stage3s for the armv4t, armv5te, armv6j, armv7a subarchitectures, and we'll make them use the profiles. Thanks
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
On Sat, Aug 6, 2011 at 18:55, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: python.eclass from python overlay supports EAPI=4. Sounds good to me. Why isn't it yet in the main portage tree? Because Arfrever isn't a developer anymore, none of the other developers are very familiar with the eclass code, and we'd really like to limit any additional complexity introduced now (because we'd like to start removing complexity from it soonish). So I've been reviewing the patches carefully before committing them, and that takes time. I was on holiday for the past two weeks, but I will try to continue tomorrow. Cheers, Dirkjan
[gentoo-dev] Re: contribution to colorgcc
On Sun, Aug 07, 2011 at 02:50:06PM +0400, Peter Volkov wrote:
Hi, Dmitry!
В Вск, 07/08/2011 в 00:44 -0400, Dmitry Goncharov пишет:
Is anybody maintaining dev-util/colorgcc?
I'd like to contribute certain improvements for gcc and also support for the
sun, ibm, hp and intel compilers.
I pushed the current version to https://github.com/dgoncharov/colorgcc.
You can pull from there or i can submit a set of patches.
Cool! Could you ask upstream to pull your changes? Since upstream is
also on github it should be not hard [1]. After that, please, open bug
report on bugs.gentoo.org [2].
[1] https://github.com/johannes/colorgcc
[2] https://bugs.gentoo.org
The latest ebuild in the portage tree does not pull from [1].
$grep SRC /usr/portage/dev-util/colorgcc/colorgcc-1.3.2-r5.ebuild
SRC_URI=mirror://gentoo/${P}.tar.gz
Once gentoo switches to pull from [1] i'd be glad to submit there.
The current situation makes me submit to gentoo.
regards, Dmitry
[gentoo-dev] Re: contribution to colorgcc
On Sun, Aug 07, 2011 at 02:50:06PM +0400, Peter Volkov wrote: Hi, Dmitry! В Вск, 07/08/2011 в 00:44 -0400, Dmitry Goncharov пишет: Is anybody maintaining dev-util/colorgcc? I'd like to contribute certain improvements for gcc and also support for the sun, ibm, hp and intel compilers. I pushed the current version to https://github.com/dgoncharov/colorgcc. You can pull from there or i can submit a set of patches. Cool! Could you ask upstream to pull your changes? Since upstream is also on github it should be not hard [1]. After that, please, open bug report on bugs.gentoo.org [2]. [1] https://github.com/johannes/colorgcc [2] https://bugs.gentoo.org I invited Johannes to participate in this discussion. regards, Dmitry
[gentoo-dev] Re: RFC: virtual/x11-lock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/06/2011 08:34 PM, Markos Chandras wrote: - gpg control packet Hi, Because of this bug[1] I would like to introduce a new virtual for all the X*lock packages. This will contain the following packages 1) alock 2) slock 3) xlockmore This will be maintained by the desktop-misc herd ( and maybe X11 if you want to ) Unless there are any objections, I will create such a virtual and send it for review [1] https://bugs.gentoo.org/show_bug.cgi?id=347729 Please review the attached ebuild - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOPwTAAAoJEPqDWhW0r/LCCIQP/1pNHY22DfJSFrZbTVAxO7xA diNJut5jbbFMVTML5mCzlfdQV9kYrTalryWcGY94v9wu1l6w7+QgS3GfGGkCG0u5 BTnNfjTUgrxR/InvLEQsdVm/xP0coWKrBPq3uqXjvJiJBjsXwCE862ODrQ4ca5RE 9mAjkutr6iGKRFcClSzcNo8hDp9jIDQAqLaMWfbgT9T/ObkhwOoEhqQ/uAFbJ1LC m1OA7QJ4urdUcn5pJCHaNdsm+JUZRIGJQYZLcrOetTxCN0nfBAfEW74mJCOGsbt6 s6maijyFrO0KoQrorxV/00b6++WJHjbT6xMIHd/wgU4HvMWqJrM6j1DbdJmJUiM1 EoWeBoT5v2WgwHbiy73VbkKbo5vXjVGT8DqmelAHmaWTVrIIYdpH/XcbFOjB1ErA sHCDNT8HbwwuU8gGTtivvNLvDwZzr8Qi6/RVeY7O86j3b9TFIOEVDw5Tg+zvW+c1 v5gqO7DbjlAY2ZOSTQO8hXjSvz4n8JcT54JUlpEUiC15N2lpQWN+7S5FOL5PXzG5 65gWPFgEgRTraQEC+K9hfzbuCLBBCTEuxA2bg5V0YQAxScQ7B9FapXGJgCVKtKdg rnjY0Ej1cqfSDKzbs3Fj2XzK0NVVCauKR1gcGEkgon+GqljIw8Q0tpKC7TrK3NNJ qGOT+9TLldIjZmJ0t6Bk =owoX -END PGP SIGNATURE- # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ EAPI=4 DESCRIPTION=A virtual package to choose between different X-locking applications HOMEPAGE= SRC_URI= LICENSE= SLOT=0 KEYWORDS=~alpha ~amd64 ~hppa ~ppc ~ppc64 ~sparc ~x86 IUSE= RDEPEND=|| ( x11-misc/alock x11-misc/i3lock x11-misc/slock x11-misc/xlockmore x11-misc/xscreensaver x11-misc/xtrlock )
Re: [gentoo-dev] Re: RFC: virtual/x11-lock
On 08/08/2011 12:33 AM, Markos Chandras wrote: On 08/06/2011 08:34 PM, Markos Chandras wrote: - gpg control packet Hi, Because of this bug[1] I would like to introduce a new virtual for all the X*lock packages. This will contain the following packages 1) alock 2) slock 3) xlockmore This will be maintained by the desktop-misc herd ( and maybe X11 if you want to ) Unless there are any objections, I will create such a virtual and send it for review [1] https://bugs.gentoo.org/show_bug.cgi?id=347729 Please review the attached ebuild The virtual is useless without some wrapper script to execute any of the installed locks, since they have no other uniform command or syntax Perhaps even eselect module with the wrapper? But then why is this virtual, instead of just || ( ) list in the package that will install the wrapper? Seems like an overkill in anycase
Re: [gentoo-dev] Re: RFC: virtual/x11-lock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/07/2011 10:38 PM, Samuli Suominen wrote: On 08/08/2011 12:33 AM, Markos Chandras wrote: On 08/06/2011 08:34 PM, Markos Chandras wrote: - gpg control packet Hi, Because of this bug[1] I would like to introduce a new virtual for all the X*lock packages. This will contain the following packages 1) alock 2) slock 3) xlockmore This will be maintained by the desktop-misc herd ( and maybe X11 if you want to ) Unless there are any objections, I will create such a virtual and send it for review [1] https://bugs.gentoo.org/show_bug.cgi?id=347729 Please review the attached ebuild The virtual is useless without some wrapper script to execute any of the installed locks, since they have no other uniform command or syntax Perhaps even eselect module with the wrapper? But then why is this virtual, instead of just || ( ) list in the package that will install the wrapper? Seems like an overkill in anycase I think you are right. Now that I think about this again it seems to me that a virtual may not be the solution to the bug referred in the first e-mail. It would be easier to just append all the optional dependencies - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOPwsGAAoJEPqDWhW0r/LCvDUP/iwZtv5O4+Kb9K112uErFo2H cKv9XmP1YonedV/ClPdsD5ylDHxiqQtmm9p5IVvRvoNXTeyipyHDVNKn/U36+RaQ m3A8X89tENE0dPqNzJ+Oy2W0u/n6YLzrpHNbdCaT41VOLTSvFEByw1tZQ/1FSwyJ +E2DfuLAKBb7vKhl6mLbBKnXUF2d2JWHUffc3S3qcc0CwPq25lztXGuzaV+kAorO RixPvEKWW+NPueRl8wA/hKk0IwUx7ZFjVg+lNVD8WKzWPyLq7bt61/678j7s1w4J l15XLaaogZFPYM1oLc6DQ91G6QCCzEPB5gPa37WXVNNGAeS089CxOsI0sq0jdhiz 6L+G6hzzSTZ73PAslugtITFjxrV5ENbiJVpt+WpNKCep8WspxecyT+XpaDJ/nDqO sPqKwSnQy2cECb1N5l7oC691oq9fuwgpuAlMn7BAc8/HO4qRykcEEMjLw/edOTsI 0MN3f6MosTaWpO4Cy+lcgBpgc3g7wm8gfL8vr58qlv+6cRip/ehvSRdjqKfIdCQs KM+hg8HgET3XddpWA2/B4f9NT+dW8N3IqttdkebD6a2eMsUjlY3UOBo9EHvXpC3B dR3rNcYHcwZ+w+fWm8Us+IUn8mFJwrGQxZ1/xMzI1EOJOcAt32IqUAVsRxzXQEPp W8HLYxLpQQecLe47rkWu =LEl9 -END PGP SIGNATURE-
[gentoo-dev] new virtual/yacc
now that yacc is no longer part of system, and we have multiple providers of yacc, we need a virtual. so unless there are any complaints, i'll be adding virtual/yacc which has || ( sys-devel/bison dev-util/yacc ). once that settles, i'll probably relocate bison to dev-util. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2011-08-07 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2011-08-07 23h59 UTC. Removals: app-crypt/steghide 2011-08-01 18:53:13 hwoarang app-arch/upm2011-08-01 18:55:15 hwoarang app-emulation/gdb-armulator 2011-08-01 18:56:55 hwoarang app-emulation/pearpc2011-08-01 18:58:17 hwoarang net-libs/clinkcc2011-08-01 19:01:53 hwoarang sys-apps/pcmcia-cs 2011-08-01 19:03:43 hwoarang sys-apps/pcmcia-cs-cis 2011-08-01 19:05:20 hwoarang sys-apps/pcmcia-cs-modules 2011-08-01 19:06:01 hwoarang sys-apps/pcmcia-cs-pnptools 2011-08-01 19:06:45 hwoarang x11-libs/Xaw3d 2011-08-02 05:38:35 mattst88 games-strategy/wormux 2011-08-04 17:23:34 mr_bones_ media-libs/libwpg 2011-08-04 17:40:15 scarabeus Additions: dev-perl/AnyEvent-I32011-08-01 06:16:16 xarthisius x11-libs/libXaw3d 2011-08-02 05:34:21 mattst88 media-sound/minitunes 2011-08-02 14:39:46 hwoarang dev-python/envisage 2011-08-03 23:47:33 bicatali dev-python/pyface 2011-08-03 23:48:32 bicatali dev-python/traitsui 2011-08-03 23:49:29 bicatali dev-python/etsproxy 2011-08-04 00:25:58 bicatali app-text/libwpg 2011-08-04 16:25:30 scarabeus sys-libs/ldb2011-08-04 18:33:24 maksbotan dev-haskell/tar 2011-08-04 20:04:47 slyfox sci-astronomy/ds9-bin 2011-08-05 20:26:51 bicatali media-libs/libbluray-xine 2011-08-05 21:27:38 radhermit dev-python/pyds92011-08-05 21:55:30 bicatali dev-python/libnatpmp2011-08-07 02:51:55 blueness sec-policy/selinux-pan 2011-08-07 11:10:33 blueness media-libs/libmetalink 2011-08-07 17:35:40 hwoarang net-misc/mulk 2011-08-07 17:38:25 hwoarang -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: app-crypt/steghide,removed,hwoarang,2011-08-01 18:53:13 app-arch/upm,removed,hwoarang,2011-08-01 18:55:15 app-emulation/gdb-armulator,removed,hwoarang,2011-08-01 18:56:55 app-emulation/pearpc,removed,hwoarang,2011-08-01 18:58:17 net-libs/clinkcc,removed,hwoarang,2011-08-01 19:01:53 sys-apps/pcmcia-cs,removed,hwoarang,2011-08-01 19:03:43 sys-apps/pcmcia-cs-cis,removed,hwoarang,2011-08-01 19:05:20 sys-apps/pcmcia-cs-modules,removed,hwoarang,2011-08-01 19:06:01 sys-apps/pcmcia-cs-pnptools,removed,hwoarang,2011-08-01 19:06:45 x11-libs/Xaw3d,removed,mattst88,2011-08-02 05:38:35 games-strategy/wormux,removed,mr_bones_,2011-08-04 17:23:34 media-libs/libwpg,removed,scarabeus,2011-08-04 17:40:15 Added Packages: dev-perl/AnyEvent-I3,added,xarthisius,2011-08-01 06:16:16 x11-libs/libXaw3d,added,mattst88,2011-08-02 05:34:21 media-sound/minitunes,added,hwoarang,2011-08-02 14:39:46 dev-python/envisage,added,bicatali,2011-08-03 23:47:33 dev-python/pyface,added,bicatali,2011-08-03 23:48:32 dev-python/traitsui,added,bicatali,2011-08-03 23:49:29 dev-python/etsproxy,added,bicatali,2011-08-04 00:25:58 app-text/libwpg,added,scarabeus,2011-08-04 16:25:30 sys-libs/ldb,added,maksbotan,2011-08-04 18:33:24 dev-haskell/tar,added,slyfox,2011-08-04 20:04:47 sci-astronomy/ds9-bin,added,bicatali,2011-08-05 20:26:51 media-libs/libbluray-xine,added,radhermit,2011-08-05 21:27:38 dev-python/pyds9,added,bicatali,2011-08-05 21:55:30 dev-python/libnatpmp,added,blueness,2011-08-07 02:51:55 sec-policy/selinux-pan,added,blueness,2011-08-07 11:10:33 media-libs/libmetalink,added,hwoarang,2011-08-07 17:35:40 net-misc/mulk,added,hwoarang,2011-08-07 17:38:25 Done.
Re: [gentoo-dev] new virtual/yacc
On Sun, Aug 7, 2011 at 11:21 PM, Mike Frysinger vap...@gentoo.org wrote: now that yacc is no longer part of system, and we have multiple providers of yacc, we need a virtual. so unless there are any complaints, i'll be adding virtual/yacc which has || ( sys-devel/bison dev-util/yacc ). once that settles, i'll probably relocate bison to dev-util. -mike Might also be worth looking at https://bugs.gentoo.org/show_bug.cgi?id=90089 at the same time. Matt
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On Sat, Aug 06, 2011 at 04:13:52PM +0200, Fabian Groffen wrote: - tree generation is dynamic + easy to move packages around, their category is specified by the tree configuration, the repository the package lives in doesn't change, probably overlays, betagarden, graveyard, sunset, etc. can all go - per package branches + instead of developing in overlays, simply branches could be used, such that a single place is sufficient to for each package Recreating the overlay experience with many repos sounds difficult. Many overlays include multi-component packages or changes to interdependent packages. Using per-package branching instead of overlays would complicate this, with a user (or layman) having to search each package's repository for branches associated with a particular overlay when trying to guess which overlay a package should be pulled from. The current behavior of PORTDIR_OVERLAY is quite well-defined and easier to understand. It even allows overlays to gracefully fall behind in keeping their packages up to date. For example, when a fix in an overlay is committed to gentoo-x86 as a new ebuild revision, the overlay maintainer can forget that he has a stale version of the package without harming anyone because portage chooses the newest package. It seems that the traditional overlay idea -- where overlays overlay gentoo-x86 and eachother -- can't quite exist with per-package branches. To recreate this idea, you'd need to have one checkout per package per repo (including overlays) and you'd still use PORTDIR_OVERLAY. I sorta like how overlays work currently ;-). -- binki Look out for missing or extraneous apostrophes! pgpkfdJI7hpcw.pgp Description: PGP signature
Re: [gentoo-dev] new virtual/yacc
On Aug 8, 2011 12:22 AM, Mike Frysinger vap...@gentoo.org wrote: virtual/yacc which has || ( sys-devel/bison dev-util/yacc ). No dev-util/byacc?
