[gentoo-dev] Re: Defining the Tree: a proto-GLEP.
Luca Barbato [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 13 Jun 2006 03:27:28 +0200: Alec Warner wrote: I prefer gentoo-x86, although others hate that x86-centric moniker ;) ebuilds' tree could be ok (now after the transgender cow Larry we greet the transgenic fruits that grown on trees but have to be herded: the Ebuilds!) Ok, I should not post after midnight, local time... I don't know... the idea seems to fit in perfectly with the idiosyncratic Larry the cow, the mystery of the UFO guy, etc. Come up with some sort of tree graphic and the next step is a wallpaper with Larry under the tree, and the UFO guy in the background... and the Gentoo logo, of course! =8^) Something like that would be great to run at the various conference Gentoo booths, and I can envision myself running it as well. To the topic at hand, however... IMO, we need to choose a name, or rather two of them, that address and make unambiguous the difference between the overall package manager tree (including all the overlays and multiple repositories that may exist on a local instance), and the official Gentoo tree (which Alec referred to as gentoo-x86, correct if not now accurate, due to history). Disambiguating between the two should prove very useful/helpful/dis-confusing, and choosing names that are clear both to users and devs (unlike gentoo-x86, which can be quite confusing to a user) will reduce confusion on bugzilla and the like, as well. Unfortunately, I don't have any good suggestions, but I'm sure others can come up with some. =8^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
On Tue, Jun 13, 2006 at 12:00:43AM +0100, Stephen Bennett wrote: My current idea is to draw up a formal specification of what ebuilds are allowed to do, and what to assume about the environment in which they run, as well as defining the formats of everything under profiles/, metadata.xml files, and other auxiliary information in the tree. I would envision the first version of this document to more or less codify existing practise, perhaps excluding some dubious tricks that are known to break in some cases. Generally, it should be possible to make the tree conform to the first version of the specification by changes no more significant than currently have QA bugs filed for them. +1 from my side. I'd like to be involved in the Manifest side, and something I'm presently working on I should hopefully post in 2-3 days will I hope clarify a few items at once, mainly revolving around signing - please don't comment now, wait until I post said rough proposals. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpyaMQKWXk86.pgp Description: PGP signature
[gentoo-dev] Re: backups: remove Portage cruft?
[snip - Mike, Robin, Joerg, Alec and Marius were kind enough to answer my questions...] Thanks guys! That should shave a couple of hours off each nightly backup.. :-)) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
On Mon, 12 Jun 2006 20:14:02 -0400 Daniel Ostrow [EMAIL PROTECTED] wrote: One thing I do ask...Lets all start now getting used to calling the portage tree something different. I'm all for terms like the tree or the ebuild tree or the package tree but at this point, given the prompting subject matter, the idea of it being a tree which belongs to portage seems outdated. This may seem like a small thing (like the teams vs. herds argument that has been brought up countless times before) but it is the silly little things like this that really do lower the mental bar for new and exciting things to happen. On related note, why virtual/portage ? Why not virtual/packagemanager, or something like that? -- Andrej Ticho Kacian ticho at gentoo dot org Gentoo Linux Developer - net-mail, antivirus, sound, x86 signature.asc Description: PGP signature
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
On Tue, 2006-06-13 at 13:38 +0200, Andrej Kacian wrote: On related note, why virtual/portage ? Why not virtual/packagemanager, or something like that? Because it already exists and is the least intrusive change. bug #69208 -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
Stephen Bennett wrote: On Mon, 12 Jun 2006 19:04:39 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: I like the idea. This would be some kind of portage-tree standard? This would be, in essence, a formal definition of the layout of the tree, and the format of and assumptions made by every file contained within it. Thanks, i do like the idea. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Sharing portage?
Hi Follow-up question to the backup thingy. Is there an easy way to share Portage's database between multiple virtual machines? Optimally, I would emerge --sync and the results would land in a filesystem that I'd share between VMs, so I don't have to do emerge --sync in each and all of them. The filesystem could perhaps be readonly to the virtual machines, except for the one doing the --sync of course. (Currently, I run emerge --sync in all virtual machines.) Thanks! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] backups: remove Portage cruft?
On Mon, 2006-06-12 at 22:36 +0200, Molle Bestefich wrote: Hi Portage takes up a lot of space and time when doing server backups. How much of Portage needs to be backup up? Any large parts of the tree that I can just dump? You don't need to backup any of it. Everything under /usr/portage can be regained with an emerge --sync except distfiles, and those are redownloaded the next time you merge a package that requires it. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Profiles Part 2
On Mon, 2006-06-12 at 21:58 +0100, Stephen Bennett wrote: Comments? Please postpone any such changes, if approved, until at least July, as we will be doing a snapshot before then, and I would prefer not having to spend our entire release cycle just fixing possible problems from these changes. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Sharing portage?
Molle Bestefich wrote: Hi Follow-up question to the backup thingy. Is there an easy way to share Portage's database between multiple virtual machines? unionfs is your friend =) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sharing portage?
Molle Bestefich wrote:
Hi
Follow-up question to the backup thingy.
Is there an easy way to share Portage's database between multiple
virtual machines?
Optimally, I would emerge --sync and the results would land in a
filesystem that I'd share between VMs, so I don't have to do emerge
--sync in each and all of them. The filesystem could perhaps be
readonly to the virtual machines, except for the one doing the --sync
of course.
I share /usr/portage across several machines as an nfs mount. 'emerge
--sync' is done on only one machine.
Until recently, 'emerge --metadata' was still needed on the other
machines, but thanks to the metadata_overlay database, this is no longer
necessary. And most emerge-related activities are much, much faster.
[To use the new database module, with portage-2.1, put
in /etc/portage/modules:
portdbapi.auxdbmodule = cache.metadata_overlay.database
in /etc/make.conf:
FEATURE=-metadata-transfer
and remove /var/cache/edb/dep/\${PORTDIR} ]
To have distfiles safely shared across the many machines, you need
FEATURES=distlocks and you'll need to relocate (or mount separately)
${DISTDIR} if ${PORTDIR} is read-only.
Also, I think you're getting into questions that should be on -user. ;)
j.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Profiles Part 2
On Mon, 2006-06-12 at 14:15 -0700, Brian Harring wrote: On Mon, Jun 12, 2006 at 09:58:01PM +0100, Stephen Bennett wrote: Many things were discussed in the last round of this thread (Paludis and Profiles, in case anyone missed it), and many useful points raised. One of these, which seems to have been largely missed in amongst the other noise, forms the basis of this proposal. It is in some ways more and in some ways less intrusive than the previous proposal, and is also completely package-manager-agnostic. In short, I would like to suggest replacing sys-apps/portage atoms in the base and default-linux profiles with virtual/portage, and removing the python dependencies from them. For most users this would have an effective zero change, since the default provider for virtual/portage is sys-apps/portage, and the python dependency will be pulled in by Portage when calculating system deps. According to my understanding, this should also produce no change when building release media, due to both Portage and Python being in packages.build. The only change introduced by this is that it becomes possible to bootstrap a system with a different package manager simply by installing it before 'system'. There are a couple more changes needed to allow this -- namely that a few system packages have old dependencies on =portage-2.0.49, but these can be resolved seperately. Any problems caused by packages depending implicitly upon Python will show up only on systems not using Portage, and can be easily fixed with the cooperation of package maintainers. I would like to think that this proposal addresses most of the concerns raised in the last thread -- it implies nothing about support for any other package manager, and introduces nothing that could cause problems for Portage users, while still allowing alternative package managers to use the tree without needing Portage installed. I am also aware that this falls roughly under what the Council was asked to discuss in its June meeting, but since that seems to have not happened, I'm bringing it up anyway, since I would like to get something done here. +1, dependant on A) catalyst folk not poking holes in it, B) council outcome tomorrow (no point in changing it till they've weighed in on the whole enchilada). As the catalyst folk I can say that it shouldn't affect us in any way. So long as packages.build still has sys-apps/portage, packages has virtual/portage, and virtuals has sys-apps/portage as the default for the virtual, it won't affect us. My only request is that this work gets held off on until after we make our 2006.1 snapshot, to reduce the possibility of us having to hunt down possibly hundreds of potential problems in release-building. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
On Mon, 2006-06-12 at 20:14 -0400, Daniel Ostrow wrote: One thing I do ask...Lets all start now getting used to calling the portage tree something different. I'm all for terms like the tree or the ebuild tree or the package tree but at this point, given the prompting subject matter, the idea of it being a tree which belongs to portage seems outdated. This may seem like a small thing (like the teams vs. herds argument that has been brought up countless times before) but it is the silly little things like this that really do lower the mental bar for new and exciting things to happen. I suggest we start calling it Larry's tree and be done with it. Also, I am definitely for having an actual written standard for what defines an ebuild. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Future of tetex
Is app-text/texlive usable for now? I only have a basic tetex installation that I will need for my master grade at university and I would want to make the switch to texlive really fast! Maybe I can help? Thanks Gabriel Lavoie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sharing portage?
On Tue, 2006-06-13 at 15:31 +0200, Molle Bestefich wrote: Hi Follow-up question to the backup thingy. Is there an easy way to share Portage's database between multiple virtual machines? Optimally, I would emerge --sync and the results would land in a filesystem that I'd share between VMs, so I don't have to do emerge --sync in each and all of them. The filesystem could perhaps be readonly to the virtual machines, except for the one doing the --sync of course. (Currently, I run emerge --sync in all virtual machines.) I current use NFS to share my portage tree at home. All you need is to store the portage tree on one machine. I would suggest the actual machine the virtual machines run on, rather than the virtual machines themselves, but you really can put them anywhere. You want the tree to be writable, too, so that you can sync from any machine and also because of distfiles. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Profiles Part 2
On Tue, 13 Jun 2006 09:42:16 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Please postpone any such changes, if approved, until at least July, as we will be doing a snapshot before then, and I would prefer not having to spend our entire release cycle just fixing possible problems from these changes. Sounds reasonable. These changes can easily wait until after the 2006.1 release as far as I'm concerned, though ideally I wouldn't want to delay them any longer than necessary without a good reason. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Future of tetex
Gabriel Lavoie wrote: Is app-text/texlive usable for now? I only have a basic tetex installation that I will need for my master grade at university and I would want to make the switch to texlive really fast! Maybe I can help? No it is not usable right now, hence the mask :-) The biggest problem (aside from some minor problems with the ebuild) is figuring out how to provide a texmf tree. The texmf tree that ships with the current ebuild is several 100 MB, which I think is too much. I like some way to provide a light, medium and heavy texmf tree. The problem is not making an ebuild but making the tree it self. So if you feel like figuring out which tex packages should go into which of the three trees then I would appreciate it very much! (remember that there are also deps between the packages). Martin Ehmsen -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Future of tetex
I suppose for now that the best way to check the texmf tree dependencies is to install TeX Live using the .iso file? Gabriel Martin Ehmsen a écrit : Gabriel Lavoie wrote: Is app-text/texlive usable for now? I only have a basic tetex installation that I will need for my master grade at university and I would want to make the switch to texlive really fast! Maybe I can help? No it is not usable right now, hence the mask :-) The biggest problem (aside from some minor problems with the ebuild) is figuring out how to provide a texmf tree. The texmf tree that ships with the current ebuild is several 100 MB, which I think is too much. I like some way to provide a light, medium and heavy texmf tree. The problem is not making an ebuild but making the tree it self. So if you feel like figuring out which tex packages should go into which of the three trees then I would appreciate it very much! (remember that there are also deps between the packages). Martin Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Future of tetex
Gabriel Lavoie wrote: I suppose for now that the best way to check the texmf tree dependencies is to install TeX Live using the .iso file? I'm not sure I understand your question... The tex packages that should go into the three trees is not necessarily the packages that ships with texlive (the texmf tree that is downloaded with the current texlive ebuild is the same as the one shipped in the .iso file), they could just as well come from ctan (or any other place for that matter, as long as the licenses are clear). So what one should do is go to ctan and figure out the interdeps between packages that goes into the texmf trees. And some of the bigger packages (beamer,...) should _not_ be in the texmf trees, since we want to be able to upgrade those without making a new release of the temxf trees (which forces users to download a large file again). Martin Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sharing portage?
On Tue, 13 Jun 2006 10:02:59 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: You want the tree to be writable, too, so that you can sync from any machine and also because of distfiles. Or you can put distfiles dir outside of portage by adjusting the $DISTDIR variable in make.conf. -- Andrej Ticho Kacian ticho at gentoo dot org Gentoo Linux Developer - net-mail, antivirus, sound, x86 signature.asc Description: PGP signature
Re: [gentoo-dev] Did portage 2.1 change default use flags?
On Monday 12 June 2006 12:57, Bo Ørsted Andresen wrote: On Monday 12 June 2006 12:42, Peter wrote: All of a sudden, emerge -uD --newuse world is showing dozens of ebuild that are replaced due to removed use flags. Did someone change the default use flags? Upgraded yesterday to portage 2.1. Look at the first section of [1]. Just so you know it this could have been answered on -user too. [1] http://www.gentoo.org/news/en/gwn/20060116-newsletter.xml As far as I can see this is not mentioned in either this weeks GWN [1], the portage 2.1 release notes [2] or the 2.1 news page [3]. I'm sure a lot of people running stable don't remember the GWN from January. Shouldn't this be mentioned somewhere now? [1] http://www.gentoo.org/news/en/gwn/20060612-newsletter.xml [2] http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup [3] http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup -- Bo Andresen pgpaAvpXftUMy.pgp Description: PGP signature
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, 2006-06-13 at 11:10 -0500, Grant Goodyear wrote: Over the years we've had a fairly consistent stream of suggestions that we should open up the e-build maintaining process to users instead of just devs. The main arguments against it are the security issues and an expectation that it would add to developer workloads. The former is certainly a real problem, although signing (assuming a reasonable web-of-trust) could mitigate that some (at least we'd know who to blame). The latter, however, is conjecture, and the only good way to verify it would be to actually try it and see what happens. Oh, and there's also a very real fear that if things go horribly wrong, that Gentoo's reputation would suffer quite badly. Perhaps I'm naive, but I tend to think that if we were to advertise project sunrise as experimental, temporary, use-at-your-own-risk, and might-break-your-system, and even put it on hardware without a gentoo.org address and add a portage hook that warns whenever the project sunrise overlay is used, then our reputation isn't really likely to suffer even if it's a complete disaster. So, Chris, what have I failed to address that would make this a really bad idea? That this describes break-my-gentoo, that it is as old as Gentoo itself and that it only creates problems for the 'supported' tree : the unexplained bugs, the weird errors, the continuous suspicion devs need to have on reported errors. Keep that stuff separated, don't mingle it with Gentoo. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, Jun 13, 2006 at 11:10:47AM -0500, Grant Goodyear wrote: Over the years we've had a fairly consistent stream of suggestions that we should open up the e-build maintaining process to users instead of just devs. The main arguments against it are the security issues and an expectation that it would add to developer workloads. The former is certainly a real problem, although signing (assuming a reasonable web-of-trust) could mitigate that some (at least we'd know who to blame). The latter, however, is conjecture, and the only good way to verify it would be to actually try it and see what happens. Oh, and there's also a very real fear that if things go horribly wrong, that Gentoo's reputation would suffer quite badly. Perhaps I'm naive, but I tend to think that if we were to advertise project sunrise as experimental, temporary, use-at-your-own-risk, and might-break-your-system, and even put it on hardware without a gentoo.org address and add a portage hook that warns whenever the project sunrise overlay is used, then our reputation isn't really likely to suffer even if it's a complete disaster. So, Chris, what have I failed to address that would make this a really bad idea? As I've said all along - I do not have any problems with Project Sunrise. I have a problem with it being an official project hosted on *.gentoo.org, as I fear most users will think hey, it's official, it's hosted on *.gentoo.org - it can't be that bad. Judging from the few users who have posted to the previous threads on this subject, my fear seems to be reasonable. If the project was to be hosted on a non *.gentoo.org domain (I'll let infra comment on whether or not non *.gentoo.org domains can be hosted on infra hardware) my current issues with this project would be gone. If the project proves to be healthy and not affect the reputation of Gentoo in a bad way, we could consider adopting it as an official project after a period of time. Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpyQV6aukXgs.pgp Description: PGP signature
[gentoo-dev] Re: Did portage 2.1 change default use flags?
On Tue, 13 Jun 2006 18:08:03 +0200, Bo Ørsted Andresen wrote: On Monday 12 June 2006 12:57, Bo Ørsted Andresen wrote: On Monday 12 June 2006 12:42, Peter wrote: All of a sudden, emerge -uD --newuse world is showing dozens of ebuild that are replaced due to removed use flags. Did someone change the default use flags? Upgraded yesterday to portage 2.1. Look at the first section of [1]. Just so you know it this could have been answered on -user too. [1] http://www.gentoo.org/news/en/gwn/20060116-newsletter.xml As far as I can see this is not mentioned in either this weeks GWN [1], the portage 2.1 release notes [2] or the 2.1 news page [3]. I'm sure a lot of people running stable don't remember the GWN from January. Shouldn't this be mentioned somewhere now? [1] http://www.gentoo.org/news/en/gwn/20060612-newsletter.xml [2] http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup [3] http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup And, from a user pov, these changes are difficult to assess. It is not obvious what removing mysql, or db, or idn, or gmp might mean, especially if the user never put them there in the first place! And, how to you explain that openoffice-bin now has -java instead of java? Or, why gnupg lost bzip2? Too many things occurred without explanation. What _I_ ended up doing was hacking make.conf and essentially put back all the changed -use flags until I could examine this further. Maybe this corrected an error from prior ebuilds or portage versions. But, from where I sit, the cure seems worse than the original problem. Thanks for researching this, Bo. -- Peter -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
Henrik Brix Andersen wrote: As I've said all along - I do not have any problems with Project Sunrise. I have a problem with it being an official project hosted on *.gentoo.org, as I fear most users will think hey, it's official, it's hosted on *.gentoo.org - it can't be that bad. Judging from the few users who have posted to the previous threads on this subject, my fear seems to be reasonable. Do you also expect that once I'm able to move my overlay to overlays.g.o, it will become this amazing beautiful thing that never has any work-in-progress stuff in it that's incredibly broken? (I would love if that were the case.) The same goes for any other personal or project overlays there, as I doubt many users will distinguish between them. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Sharing portage?
Jonathan Adamczewski wrote:
Molle Bestefich wrote:
Hi
Follow-up question to the backup thingy.
Is there an easy way to share Portage's database between multiple
virtual machines?
Optimally, I would emerge --sync and the results would land in a
filesystem that I'd share between VMs, so I don't have to do emerge
--sync in each and all of them. The filesystem could perhaps be
readonly to the virtual machines, except for the one doing the --sync
of course.
I share /usr/portage across several machines as an nfs mount. 'emerge
--sync' is done on only one machine.
Until recently, 'emerge --metadata' was still needed on the other
machines, but thanks to the metadata_overlay database, this is no longer
necessary. And most emerge-related activities are much, much faster.
[To use the new database module, with portage-2.1, put
in /etc/portage/modules:
portdbapi.auxdbmodule = cache.metadata_overlay.database
in /etc/make.conf:
FEATURE=-metadata-transfer
and remove /var/cache/edb/dep/\${PORTDIR} ]
Please Please Please read the docs before using metadata_overlay; there
are some stipulations you need to follow when turning it on,
specifically you cannot edit eclasses. Otherwise, let it loose ;)
To have distfiles safely shared across the many machines, you need
FEATURES=distlocks and you'll need to relocate (or mount separately)
${DISTDIR} if ${PORTDIR} is read-only.
Also, I think you're getting into questions that should be on -user. ;)
j.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, 13 Jun 2006 10:06:56 -0700, Donnie Berkholz wrote: Henrik Brix Andersen wrote: As I've said all along - I do not have any problems with Project Sunrise. I have a problem with it being an official project hosted on *.gentoo.org, as I fear most users will think hey, it's official, it's hosted on *.gentoo.org - it can't be that bad. Judging from the few users who have posted to the previous threads on this subject, my fear seems to be reasonable. Do you also expect that once I'm able to move my overlay to overlays.g.o, it will become this amazing beautiful thing that never has any work-in-progress stuff in it that's incredibly broken? (I would love if that were the case.) The same goes for any other personal or project overlays there, as I doubt many users will distinguish between them. Thanks, Donnie But, we're NOT just talking about borked and incomplete packages. We are ALSO talking about good, normal, and useful packages which, for a variety of reasons, just can't seem to make it to the main portage tree. This idea that everything in sunrise is going to be uber-experimental, possibly bad, and likely-to-break-your-machine, is overstating the case. And, again, considering your user-community, a user MUST make a few concrete action steps in order to open up [the Pandora's box that some thing this is] Sunrise. No one will ever accidentally be able to download a Sunrise hosted project without consciously choosing to do so. As for where it is hosted, as a user. myop says, it should be on .gentoo.org, and on .gentoo infra. Why? Because of the link to gentoo's bugzilla. If there is going to be a relation between bugs on bz - Sunrise - bz (and ultimately, maybe) - main portage tree, then having o.g.o and sunrise together makes a lot of sense. Otherwise, you end up confusing matters even more. While I realize there is a lot at stake, and probably some policy issues and security issues that deserve discussion, I think that the degree of doom some of you ascribe to this project is not worthy. I think, should Sunrise get a green light, that it will turn out to be a developer and prospective-developer playground and testing site largely ignored by users. Any user who choose to use Sunrise will have a specific, very specific need. As an example, there is a kernel source build I've been playing with. I know, from the kernel team, it will never, repeat NEVER, get onto the portage tree. they want no part of it. However, the bug is widely followed, and if Sunrise were to be a home to it, then these bug readers would be able to continue to work on the project. Why should it just waste away on bz? See bug # 103354 started by Scott Jones who did most of the work on it. This kernel source is also tracked on the gentoo forums. This kernel source will not cause Armageddon to arrive, cause smoke to issue from your power supply, nor interfere with other ebuilds. I think it Sunrise belongs part of .gentoo.org, and it should be given a probationary period, say 90 days, for review. I am sure tracking of downloads, uploads, and problems can easily be done. I think portage can also be reprogrammed to spit out warnings, even require a positive acknowledgment, when requesting an overlay the first time. Something like: YOU ARE REQUESTING AN OVERLAY EBUILD There are inherent risks associated with this action. Overlay ebuilds are not official parts of the Gentoo main tree, and as such, should be considered experimental. Do you acknowledge this: (Yes). If yes, then touch a file somewhere and the user won't be nagged again. Am I being to simplistic or naive? -- Peter -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, Jun 13, 2006 at 01:29:55PM -0400, Peter wrote: [snip] This kernel source will not cause Armageddon to arrive, cause smoke to issue from your power supply, nor interfere with other ebuilds. That's funny. Did you just claim that a sys-kernel/*-sources ebuild with the patch-sets listed below would have no possibility of interfering with other ebuilds? If so, you've just proven my point that many users wont be able to judge how ebuilds from overlays may affect the stable tree. Features -ck(s) Con Kolivas Patchset, (server version available as option) -ide libATA/ide updates, Alsa updates and fixes, Dothan Speedstep, Pentium M undervolt, IBM ACPI fan control, Suspend2, vesafb-tng, reiser4, unionfs squashfs, realtime-lsm, fbsplash, configurable mouse polling support, custom dsdt, Layer7, various fixes and updates. [1] Am I being to simplistic or naive? Both, it seems. Regards, Brix [1]: http://bugs.gentoo.org/show_bug.cgi?id=103354#c51 -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpUVjE0JAgg3.pgp Description: PGP signature
[gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, 13 Jun 2006 19:54:47 +0200, Henrik Brix Andersen wrote: On Tue, Jun 13, 2006 at 01:29:55PM -0400, Peter wrote: [snip] This kernel source will not cause Armageddon to arrive, cause smoke to issue from your power supply, nor interfere with other ebuilds. That's funny. Did you just claim that a sys-kernel/*-sources ebuild with the patch-sets listed below would have no possibility of interfering with other ebuilds? If so, you've just proven my point that many users wont be able to judge how ebuilds from overlays may affect the stable tree. I did. Sources don't affect anything. The ck-sources are in the tree, and there is dire warning associated with them. Only the -mm sources have any sort of warning. If a user CHOOSES to use a hacked up kernel, then they obviously choose to. Just like, if a user chooses to try out reiserfs-4, they get what they pay for. Sources don't affect anything. Features -ck(s) Con Kolivas Patchset, (server version available as option) -ide libATA/ide updates, Alsa updates and fixes, Dothan Speedstep, Pentium M undervolt, IBM ACPI fan control, Suspend2, vesafb-tng, reiser4, unionfs squashfs, realtime-lsm, fbsplash, configurable mouse polling support, custom dsdt, Layer7, various fixes and updates. [1] Am I being to simplistic or naive? Both, it seems. Regards, Brix [1]: http://bugs.gentoo.org/show_bug.cgi?id=103354#c51 And I think these are worthwhile features. Some, actually are part of the gentoo-base and gentoo-extra patches (see the excludes list). It also includes spocks vesa-tng and fbsplash. Look, you can't micro-control all aspects of a user's computing experience. If someone downloads tmpwatch and mistakenly puts / in the list of directories to prune, what will you do? Put tmpwatch into package.mask because it MIGHT be misued? Or, will you package.mask vixie.cron because someone may not be capable of writing a bash script? Honestly, I do not see the difference, AND because the kernel is experimental (or, at least I call it experimental), and widely followed, I think Sunrise is ideal for it. JM2C. -- Peter -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, Jun 13, 2006 at 02:14:24PM -0400, Peter wrote: I did. Sources don't affect anything. The ck-sources are in the tree, and there is dire warning associated with them. Only the -mm sources have any sort of warning. If a user CHOOSES to use a hacked up kernel, then they obviously choose to. Just like, if a user chooses to try out reiserfs-4, they get what they pay for. Sources don't affect anything. I rest my case. ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpVvny7JAkoB.pgp Description: PGP signature
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, Jun 13, 2006 at 02:15:12PM -0400, Ned Ludd wrote: Would moving it from overlays.g.o to overlays.dev.g.o, overlays.experimental.dev.g.o help ? It could then be viewed officially unofficial as the tinderboxing repository's I've been working on. It wouldn't be the ideal solution to me. Or not? That's an option as well. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpbfQNDxLv1t.pgp Description: PGP signature
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
Would moving it from overlays.g.o to overlays.dev.g.o, overlays.experimental.dev.g.o help ? It could then be viewed officially unofficial as the tinderboxing repository's I've been working on. I think it won't make a big difference. It's stated clearly that the sunrise overlay is experimental and unsupported. If some user is really that blind he won't read the link either. And overlays.experimental.dev.gentoo.org domain is a bit unfriendly, don't you think so? Next step would be sunrise.the.experimental.and.unsupported.overlay.hosted.on.dev.overlays.gentoo.org Personally I know I would like to have a place to park pic, iconv, nls patches in testing, and embedded-kernels that are say vital for some devices but for one reason or another should not be in the official tree. Sunrise would be a good place i think ;] -- Best Regards, Peper -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, 2006-06-13 at 11:10 -0500, Grant Goodyear wrote: Over the years we've had a fairly consistent stream of suggestions that we should open up the e-build maintaining process to users instead of just devs. The main arguments against it are the security issues and an expectation that it would add to developer workloads. The former is certainly a real problem, although signing (assuming a reasonable web-of-trust) could mitigate that some (at least we'd know who to blame). The latter, however, is conjecture, and the only good way to verify it would be to actually try it and see what happens. Oh, and there's also a very real fear that if things go horribly wrong, that Gentoo's reputation would suffer quite badly. Perhaps I'm naive, but I tend to think that if we were to advertise project sunrise as experimental, temporary, use-at-your-own-risk, and might-break-your-system, and even put it on hardware without a gentoo.org address and add a portage hook that warns whenever the project sunrise overlay is used, then our reputation isn't really likely to suffer even if it's a complete disaster. So, Chris, what have I failed to address that would make this a really bad idea? Honestly, I'm not feeling the urge to retype everything I put into my last email again, just because someone else asked it. This has come up time and time again, and every time it gets shot down for lots of reasons. Why is it suddenly a good idea now, when it has always been a bad idea before? Is it just that now we have a lot of developers who are willing to allow users to break their boxes? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, 2006-06-13 at 13:29 -0400, Peter wrote: As an example, there is a kernel source build I've been playing with. I know, from the kernel team, it will never, repeat NEVER, get onto the portage tree. they want no part of it. However, the bug is widely followed, and if Sunrise were to be a home to it, then these bug readers would be able to continue to work on the project. Why should it just waste away on bz? See bug # 103354 started by Scott Jones who did most of the work on it. This kernel source is also tracked on the gentoo forums. Using your example, if it will *never* make it into the tree, then what is it doing on *.gentoo.org infrastructure? The authors are more than welcome to host this on their own. There's absolutely zero reason for us to support it in any way, including our infrastructure, if there's absolutely no way that it will *ever* make it into the tree. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, Jun 13, 2006 at 01:41:21PM -0500, Grant Goodyear wrote: Care to elaborate? The wise, all-knowing Zen argument isn't particularly helpful All software runs on top of the core of the operating system, the kernel. If the kernel is buggy it will be reflected in all the software running on top of it, be it portage, compilers, daemons or graphical user environments. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpaXplztf3ud.pgp Description: PGP signature
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
(...) Is it just that now we have a lot of developers who are willing to allow users to break their boxes? Just tell me one thing, are you breaking your box everytime you use an overlay? -- Best Regards, Peper -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
Ned Ludd wrote: On Tue, 2006-06-13 at 18:26 +0200, Henrik Brix Andersen wrote: I have a problem with it being an official project hosted on *.gentoo.org, as I fear most users will think hey, it's official, it's hosted on *.gentoo.org - it can't be that bad. Judging from the few users who have posted to the previous threads on this subject, my fear seems to be reasonable. If the project was to be hosted on a non *.gentoo.org domain (I'll let infra comment on whether or not non *.gentoo.org domains can be hosted on infra hardware) my current issues with this project would be gone. Would moving it from overlays.g.o to overlays.dev.g.o, overlays.experimental.dev.g.o help ? It could then be viewed officially unofficial as the tinderboxing repository's I've been working on. I like the idea, helps to differentiate a bit. Though - frankly said I don't really understand what's this paranoia about. You don't have control over users' systems. There are tons of overlays users are using daily [1] - but obviously according to some people the one like Sunrise must definitely be the worst overlay ever, which will just make users boxes massively explode in smoke, kill Gentoo, all its reputation and half of the near universe. The main reason being that it's been hosted on overlays.gentoo.org and hence it's obviously official and we must guarantee that it will be 130% working and won't bring a single bad byte on users' boxes, otherwise - whee kabm, the end of the world! [1] http://gentoo-wiki.com/TIP_Overlays Personally I know I would like to have a place to park pic, iconv, nls patches in testing, and embedded-kernels that are say vital for some devices but for one reason or another should not be in the official tree. Erm, better host it somewhere else, you'll save yourself trouble and it will be more effective. If the project proves to be healthy and not affect the reputation of Gentoo in a bad way, we could consider adopting it as an official project after a period of time. Or not? Shrug... The question is whether the maintainers will be interested in becoming an official project or if they'll just choose to save themselves the trouble. Getting tired of this thread, really. Talk about too much ado for nothing. So, how about we stop wasting time, let people who are interested to do something do it, and the rest of us can focus on more important stuff than endless debates on mailing list and bothering Gentoo Council - such as fixing current bugs and cleaning the dead cruft in the tree, or fixing things not yet ported for modular X, or unported for gcc-4.x, or whatever else? Mailing list threads that don't fix one screen resolution suck, you can expect another funding request from blubb any time soon, it seems. :P -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: Using your example, if it will *never* make it into the tree, then what is it doing on *.gentoo.org infrastructure? OK, I'll speak up. I plan on using overlay.gentoo.org for the perl team overlay repository. dev-perl alone has 600+ ebuilds - we are at the point where we are only adding those modules that have specific support requirements (makes foo work, etc). But there are plenty of packages we'd love to add, but don't have the manpower/resources to do it. Catalyst comes to mind - awesome take on the rails phenom, but the size and volume makes it tough to fit into our tree, and its one of the first things I plan on putting up in the overlay. As for the next bit: The authors are more than welcome to host this on their own. There's absolutely zero reason for us to support it in any way, including our infrastructure, if there's absolutely no way that it will *ever* make it into the tree. I don't have the resources to support it somewhere, simply put. I don't have a server somewhere I can point users to, or the kind of friends that will run an open svn (or whatever) on their boxes and host my overlays for me. Plus, this gives me/us a place to combine our resources, our overlays, into a cohesive whole. Some of it may make it in the tree one day; some not; some of it has too small an audience to add the requirements of maintainership to it - but at least it would be going somewhere. Just my two cents. Not sure about sunrise, but I'm all behind the overlays. ~mcummings -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEjw6Zq1ztTp5/Ti4RAlBFAJ0TEsgWyNC1z0LoN1kipYOXWbZILQCgoqs0 UzZvAcL5AtQNU33yt1MZB5Y= =NM8w -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.
Henrik Brix Andersen wrote: [Tue Jun 13 2006, 01:52:18PM CDT] All software runs on top of the core of the operating system, the kernel. If the kernel is buggy it will be reflected in all the software running on top of it, be it portage, compilers, daemons or graphical user environments. Oh, I'm sorry, I thought you were referring to the kernel in terms of ebuild dependencies. Isn't your reason why emerge --info lists the kernel? (Also, the kernel probably isn't the best example, since I suspect that if there's any single package that people are likely to install outside of portage, the kernel would be it.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpong75Uwgt9.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, 13 Jun 2006 13:41:21 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | Henrik Brix Andersen wrote: [Tue Jun 13 2006, 01:30:27PM CDT] | On Tue, Jun 13, 2006 at 02:14:24PM -0400, Peter wrote: | I did. Sources don't affect anything. The ck-sources are in the | tree, and there is dire warning associated with them. Only the | -mm sources have any sort of warning. If a user CHOOSES to use a | hacked up kernel, then they obviously choose to. Just like, if a | user chooses to try out reiserfs-4, they get what they pay for. | Sources don't affect anything. | | I rest my case. | | Care to elaborate? The wise, all-knowing Zen argument isn't | particularly helpful It's perfect proof that there are users that are utterly clueless about what is best for their system, and utterly clueless about how using third party software can cause problems for other software. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, 13 Jun 2006 20:30:27 +0200, Henrik Brix Andersen [EMAIL PROTECTED] wrote: On Tue, Jun 13, 2006 at 02:14:24PM -0400, Peter wrote: I did. Sources don't affect anything. The ck-sources are in the tree, and there is dire warning associated with them. Only the -mm sources have any sort of warning. If a user CHOOSES to use a hacked up kernel, then they obviously choose to. Just like, if a user chooses to try out reiserfs-4, they get what they pay for. Sources don't affect anything. I rest my case. ./Brix I fail to understand your case, and I will admit to not having followed this thread extremely closely due to the fact that we are getting ready to roll out our 2.0 release, you are saying that people should, or should not have the choice? Or that people are free to have the choice as long as it isn't on infra controlled Gentoo hardware? Emerging the kernel sources, as far as I understand it, doesn't affect anything (except perhaps external drivers, but then again, what doesn't - you have some wireless drivers that require some options be set in the kernel, and others not be set, and it gets worse when you are trying to test both pieces of hardware at the same time as they refuse to co-exist due to the way the drivers are being written these days) The way I see it, this could be a huge step forward, and bug reports should have the emerge --info in them anyways, and you would see they are using sunrise there. So is the real issue that people would use the overlay or that the overlay is hosted on Gentoo hardware and that makes it bad? I really wish I could follow this thread better. Can someone summarize? -- gentoo-dev@gentoo.org mailing list
