Re: [gentoo-dev] last call for xml2 (#116346)
On Wednesday 07 June 2006 12:03, Mike Frysinger wrote: you guys have had plenty of time to do this ... so last call before i scrub xml2 from use.desc and repoman starts complaining :P -mike Stable samba-3.0.22 has both xml and xml2 still. -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, Jun 05, 2006 at 08:58:46PM +0100, Luis Medinas wrote: Xmms will be removed soon... Lot's of users still use xmms mostly because it has many plugins that others don't. Xmms is still stable but the upstream is dead so it won't take our patchset. In the end of this year i would like to remove xmms and all plugins but before i need to prepare users for this changes and clean some maintainer-wanted bugs for plugins. Provide migration options for the plugins - some of the code is out there, it's not in the tree yet, three that I actively use are xosd (the XMMS plugin is with the xosd package), xmms-realrandom and xmms-morestate. There are SUSE rpms for audacious-xosd, but I haven't found the SRPM or other source anywhere. In the past, the base xmms plugins were all split to be seperate packages, could something similar happen with audacious? It is possible to reduce some of the memory overhead? Comparing a clean start of xmms to a clean start of audacious with my playlist takes twice as much virt space, and 50% more resident memory - long term the numbers look even worse for audacious. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpp58HRKkcGu.pgp Description: PGP signature
[gentoo-dev] parallel fun in src_install - going beyond the serial monotony of 'make install'
In the present devmanual, for src_install, it notes that
make install DESTDIR=${D}
is the preferred way to fire off the install, and to not use emake, for
fear of parallel issues.
This has four nasty side effects:
- Global assumption that make is GNU Make (Hi flameeyes).
- Doesn't pass MAKEOPTS for options other than -jX.
- Removes ability to use EXTRA_EMAKE.
- Large package installs are make very slow.
I did a bit of checking of a random selection of packages (looking at
the Makefile and internal dependancy trees, as well as a test with -j7
on my 4-way box), and found very few problems with the concept of
parallel installs.
For a start, practically all Makefiles generated by a recent version
(newer than 2001 for definite) are parallel safe. There are a few minor
cases I saw where this wasn't true, but those packages also had other
parallel build problems.
For packages that are definitely aren't parallel-install safe, we should
use 'emake -j1', just like the src_compile phase.
I'm not saying we should change the entire existing tree, but for new
packages, please consider emake for your src_install phase.
A nice use for EXTRA_EMAKE while debugging is being able to pass in
--debug=basic to make, and have it tell you why it rebuilt a target in
src_install, since src_install should not be compiling things ;-).
To forestall one question I expect, I'd like to point a basic fact about
how Makefiles work:
Multiple commands in a single target will always be executed in series,
and not parallel - so this target will work fine:
install:
mkdir -p $(DESTDIR)/bin
cp -f bar $(DESTDIR)/bin
--
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpYq4AAQJjuc.pgp
Description: PGP signature
Re: [gentoo-dev] parallel fun in src_install - going beyond the serial monotony of 'make install'
On Thu, Jun 08, 2006 at 01:58:07AM -0700, Robin H. Johnson wrote: For a start, practically all Makefiles generated by a recent version (newer than 2001 for definite) are parallel safe. There are a few minor cases I saw where this wasn't true, but those packages also had other parallel build problems. Typo here, I left out the word 'autotools'. Corrected version: For a start, practically all Makefiles generated by a recent version of autotools (newer than 2001 for definite) are parallel safe. There are a few minor cases I saw where this wasn't true, but those packages also had other parallel build problems. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpA1os0Kuvnm.pgp Description: PGP signature
Re: [gentoo-dev] last call for xml2 (#116346)
On Thursday 08 June 2006 02:58, Roy Marples wrote: On Wednesday 07 June 2006 12:03, Mike Frysinger wrote: you guys have had plenty of time to do this ... so last call before i scrub xml2 from use.desc and repoman starts complaining :P Stable samba-3.0.22 has both xml and xml2 still. tell it to the samba maintainers -mike pgp7Ij7YPdoOl.pgp Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
On Wednesday 07 June 2006 19:12, Alec Warner wrote: I would be more concerned with convincing the rest of the developers. adding crap in base profile.bashrc will affect 99% of users, so it better be friggin correct and useful, otherwise you will piss a ton of people off. versus the people who are really annoyed that such support hasnt yet been integrated into portage proper ? yes, from the portage side of things, it may be a pita to implement per-package env ... but from the user side of things, it's a huge help -mike pgpiJ4RDZUg3v.pgp Description: PGP signature
Re: [gentoo-dev] parallel fun in src_install - going beyond the serial monotony of 'make install'
On Thu, Jun 08, 2006 at 01:58:07AM -0700, Robin H. Johnson wrote:
In the present devmanual, for src_install, it notes that
make install DESTDIR=${D}
is the preferred way to fire off the install, and to not use emake, for
fear of parallel issues.
Actually, it uses `make DESTDIR=${D} install`. Is there a reason you
changed it around, or does it simply not matter at all?
I completely agree with the rest of what you wrote.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
On Wednesday 07 June 2006 16:10, Zac Medico wrote: Grant Goodyear wrote: Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT] Mike Frysinger wrote: this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do not want to go through every single package i maintain and add 'debug-build' to IUSE or 'inherit some-new-eclass' Sometimes it takes a little extra work to do things right, but hopefully it will pay off in the long run. A poor design decision made now can haunt us for years to come. A little extra work? I'm pretty sure that such an eclass would be required for better than half the tree (every package that contains some C or C++). If almost everybody has to add the same piece of boilerplate to their ebuilds, then perhaps a sane package manager should be able to figure out what to do without the boilerplate. That It's a slippery slope when we start to incorporate special cases like that into a generic package manager. Where does it end? The same argument could be made again and again to add more special cases that further pollute the package manager. We already have a standard solution for cases such as this, and that is to share the specialized functionality via an eclass. the package maintainer provides some sane defaults ... the idea is for the full configuration to be offloaded to the profiles Well, I'd say that per-package environment variables would be a better way to implement per-package CFLAGS, CXXFLAGS, etc.. There is a patch attached to bug 44796 that implements this. Note that the debug-build.bashrc attached to my last post actually allows per-package debug-build via package.use. ok ? so what's stopping it from being integrated ? people want it ;) -mike pgpdKMt1pCthw.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 15:58, Luis Medinas wrote: On Mon, 2006-06-05 at 21:22 +0200, Wernfried Haas wrote: On Mon, Jun 05, 2006 at 07:03:57PM +0200, Stefan Schweizer wrote: today I would like to propose a few default keywords for removal. They are outdated and no longer needed on current systems: What do you want to remove, the use flags themselves or just turn them off in the profiles? -xmms - xmms depends on gtk-1 and has been superseeded by audacious/bmpx xmms is still in the tree? People (ok, at least me ;-) ) still use it? I don't mind if it has to go and there are alternatives, but why would you just want to remove its use flag and not the package itself? If it needs to go, either dump all of it or nothing. Xmms will be removed soon... Lot's of users still use xmms mostly because it has many plugins that others don't. Xmms is still stable but the upstream is dead so it won't take our patchset. In the end of this year i would like to remove xmms and all plugins but before i need to prepare users for this changes and clean some maintainer-wanted bugs for plugins. i think removing xmms is inappropriate at this time or in the near future -mike pgpnzk17tQbeq.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Thu, 2006-06-08 at 01:30 -0700, Robin H. Johnson wrote: On Mon, Jun 05, 2006 at 08:58:46PM +0100, Luis Medinas wrote: Xmms will be removed soon... Lot's of users still use xmms mostly because it has many plugins that others don't. Xmms is still stable but the upstream is dead so it won't take our patchset. In the end of this year i would like to remove xmms and all plugins but before i need to prepare users for this changes and clean some maintainer-wanted bugs for plugins. Provide migration options for the plugins - some of the code is out there, it's not in the tree yet, three that I actively use are xosd (the XMMS plugin is with the xosd package), xmms-realrandom and xmms-morestate. There are SUSE rpms for audacious-xosd, but I haven't found the SRPM or other source anywhere. Yes we will provide migrations to the plugins. Audacious is currently the only player on the tree that supports xmms plugins. Maybe it's time to develop some plugins or start packaging. In the past, the base xmms plugins were all split to be seperate packages, could something similar happen with audacious? It is possible to reduce some of the memory overhead? Comparing a clean start of xmms to a clean start of audacious with my playlist takes twice as much virt space, and 50% more resident memory - long term the numbers look even worse for audacious. Ask Audacious upstream but since it's build with gtk+-2 you can find it a little bit slower. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
This is just a mine question, but it seems that since gcc-4.1 got it's way into portage (~branch) things are getting slower. Lots of the bugs blocking bug #117482 - http://bugs.gentoo.org/show_bug.cgi?id=117482 - have a patch in the report or an ebuild for revision bump, tested working. They just don't get committed (or, sometimes, closed). IMHO these bugs should get some kind of priority, cause actually any unstable system having one of these blocking ebuilds in world tree will have issue emerging,for sure. ( for who didn't noticed: gcc-4.1 is actually in portage testing , no more unmasked). thanks for your time and for listening my 2 cents. mattepiu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
Matteo Azzali wrote: This is just a mine question, but it seems that since gcc-4.1 got it's way into portage (~branch) things are getting slower. Lots of the bugs blocking bug #117482 - http://bugs.gentoo.org/show_bug.cgi?id=117482 - have a patch in the report or an ebuild for revision bump, tested working. They just don't get committed (or, sometimes, closed). IMHO these bugs should get some kind of priority, cause actually any unstable system having one of these blocking ebuilds in world tree will have issue emerging,for sure. ( for who didn't noticed: gcc-4.1 is actually in portage testing , no more unmasked). Sometimes people get busy, I know I haven't looked at my bugs all week, been busy at work 12 hours a day. As such if it's a big problem you can always gcc-config some-other-compiler-version and then compile any problem packages. I know that breaks the whole 'my whole system is compiled w/gcc-4.1' deal, but if it's that big of a blocker, take action. Or hell, patch the ebuild yourself. I think this distro was (or is?) about giving users the ability to do what they needed. If something is masked, you can unmask it, if it's not keyworded you can keyword it, if it's not patched, you can patch it thanks for your time and for listening my 2 cents. mattepiu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] parallel fun in src_install - going beyond the serial monotony of 'make install'
On Thursday 08 June 2006 06:08, Harald van Dijk wrote:
On Thu, Jun 08, 2006 at 01:58:07AM -0700, Robin H. Johnson wrote:
In the present devmanual, for src_install, it notes that
make install DESTDIR=${D}
is the preferred way to fire off the install, and to not use emake, for
fear of parallel issues.
Actually, it uses `make DESTDIR=${D} install`. Is there a reason you
changed it around, or does it simply not matter at all?
it doesnt matter
I completely agree with the rest of what you wrote.
some people have started using `emake -j1 DESTDIR=${D} install`
-mike
pgpxc8J3qYtgC.pgp
Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Wednesday 07 June 2006 16:10, Zac Medico wrote: Grant Goodyear wrote: Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT] Mike Frysinger wrote: this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do not want to go through every single package i maintain and add 'debug-build' to IUSE or 'inherit some-new-eclass' Sometimes it takes a little extra work to do things right, but hopefully it will pay off in the long run. A poor design decision made now can haunt us for years to come. A little extra work? I'm pretty sure that such an eclass would be required for better than half the tree (every package that contains some C or C++). If almost everybody has to add the same piece of boilerplate to their ebuilds, then perhaps a sane package manager should be able to figure out what to do without the boilerplate. That It's a slippery slope when we start to incorporate special cases like that into a generic package manager. Where does it end? The same argument could be made again and again to add more special cases that further pollute the package manager. We already have a standard solution for cases such as this, and that is to share the specialized functionality via an eclass. the package maintainer provides some sane defaults ... the idea is for the full configuration to be offloaded to the profiles Well, I'd say that per-package environment variables would be a better way to implement per-package CFLAGS, CXXFLAGS, etc.. There is a patch attached to bug 44796 that implements this. Note that the debug-build.bashrc attached to my last post actually allows per-package debug-build via package.use. ok ? so what's stopping it from being integrated ? people want it ;) Is this question about per-package env, per-package debug-build, or both? In this thread, I've already posted a sample bashrc implementation of debug-build. Also, bug 44796 has a comment with a link to a bashrc implementation of per-package env: http://article.gmane.org/gmane.linux.gentoo.user/143322 The support already exists in portage for both of these. Either or both of them can be added to $PORTDIR/profiles/base/profile.bashrc and every package will inherit the functionality. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEiAwA/ejvha5XGaMRAlXnAJ9yNx47G/ERA6/VLLH9CmKHOhmUeQCfUqK9 mWIvUdJihBDcXBQT0SsC8j4= =7d2s -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
Hum, maybe my little english is not good to explain my thoughts. I already have a /usr/local/portage overlay bigger than 500Kb. What I was asking is if it's a normal behaviour that emerge stops for unstable branch users. I asked myself this after looking some ebuilds that have more than 4 versions in portage but still none of these (neither unstable or masked) works with gcc-4.1.x (for example fox, 11 different versions in portage and the gcc-4.1.x ebuild (stabled upstream) still floating in bugreport #132407 of 5-apr-2006 and bug #128917 of 5-may-2006 , but fox is just an example, and there could be causes I don't know...) No meant to harm anyone, sorry if you get mad, still completely my personal opinion and nothing more. mattepiu Alec Warner wrote: Matteo Azzali wrote: This is just a mine question, but it seems that since gcc-4.1 got it's way into portage (~branch) things are getting slower. Lots of the bugs blocking bug #117482 - http://bugs.gentoo.org/show_bug.cgi?id=117482 - have a patch in the report or an ebuild for revision bump, tested working. They just don't get committed (or, sometimes, closed). IMHO these bugs should get some kind of priority, cause actually any unstable system having one of these blocking ebuilds in world tree will have issue emerging,for sure. ( for who didn't noticed: gcc-4.1 is actually in portage testing , no more unmasked). Sometimes people get busy, I know I haven't looked at my bugs all week, been busy at work 12 hours a day. As such if it's a big problem you can always gcc-config some-other-compiler-version and then compile any problem packages. I know that breaks the whole 'my whole system is compiled w/gcc-4.1' deal, but if it's that big of a blocker, take action. Or hell, patch the ebuild yourself. I think this distro was (or is?) about giving users the ability to do what they needed. If something is masked, you can unmask it, if it's not keyworded you can keyword it, if it's not patched, you can patch it thanks for your time and for listening my 2 cents. mattepiu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] last call for xml2 (#116346)
On Thursday 08 June 2006 11:00, Mike Frysinger wrote: On Thursday 08 June 2006 02:58, Roy Marples wrote: On Wednesday 07 June 2006 12:03, Mike Frysinger wrote: you guys have had plenty of time to do this ... so last call before i scrub xml2 from use.desc and repoman starts complaining :P Stable samba-3.0.22 has both xml and xml2 still. tell it to the samba maintainers -mike samba maintainers ^^ :P -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
On 08/06/06, Matteo Azzali [EMAIL PROTECTED] wrote: Hum, maybe my little english is not good to explain my thoughts. I already have a /usr/local/portage overlay bigger than 500Kb. I can beat that, try 23MB :-/ Anyway, back to your point - yes, there are lots of bugs with patches attached that aren't being added to the main tree. And there are lots of bugs where the ebuild or fix is ending up in an overlay rather than the main tree. It's getting complicated to keep track - all I can really advise is that if you'd like to see fixes and ebuilds being added to the main tree, then become a developer and start doing it (although it is complex for something like gcc compile fixes which are spread across packages owned by multiple developers who will get upset if you touch their package). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
On Thu, 08 Jun 2006 06:49:39 -0400 Alec Warner [EMAIL PROTECTED] wrote: Mike Frysinger wrote: On Wednesday 07 June 2006 19:12, Alec Warner wrote: I would be more concerned with convincing the rest of the developers. adding crap in base profile.bashrc will affect 99% of users, so it better be friggin correct and useful, otherwise you will piss a ton of people off. versus the people who are really annoyed that such support hasnt yet been integrated into portage proper ? yes, from the portage side of things, it may be a pita to implement per-package env ... but from the user side of things, it's a huge help -mike My e-mail was basically worded as to say Solar paste your crap to this ML. Is there any reason you need package.env in portage proper as opposed to bashrc? I remember portage people asserting before that package.env tricks from bashrc don't work completely, in that it needs to be in place for portage.py before the bashrc script is sourced. Is this no longer a problem? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 02:42 +0200, Stefan Schweizer wrote: Hi, I have founded a new Gentoo Project for the Gentoo User Overlay. The intention is to give contributors a single place to put their ebuilds - a place where they can be downloaded, updated and be moved to portage more easily than through bugzilla. It is also a good place for users who would like to become developers to learn how to commit and how to not break the tree. We already *have* a single place. It is bugzilla. Wasn't it decided that we would *not* end up with some giant overlay that houses all of the non-tree stuff before the overlays project was brought into being? Does this not completely fly in the face of that? You can find the project page as a subproject of the overlays project [1] The overlay is available on overlays.gentoo.org [2] Initially jokey and myself will be working on this. The current focus is to migrate ebuilds from bugzilla into the overlay and to get contributors to commit their changes to the overlay instead of updating the bugzilla every time. Please keep the games bugs in bugzilla. Making this change is a direct change in games team policy without any prior notice to the games team and without our permission. Anyone who wants to help, please stop by in #gentoo-overlays @ freenode [1] http://gentoo.org/proj/en/overlays/sunrise [2] http://overlays.gentoo.org/svn/proj/sunrise - Stefan PS: This is an announcement - No flamewars allowed Perhaps you should have discussed this before going and making an assumption for the entire developer pool. The idea itself isn't so bad as the fact that you've now essentially taken it upon yourself to decide how *every single one of us* is going to accept ebuilds from now on without any form of discussion. -- 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] fix binary debug support, part elevenity billion + 1
On Thu, 2006-06-08 at 06:49 -0400, Alec Warner wrote:
Mike Frysinger wrote:
On Wednesday 07 June 2006 19:12, Alec Warner wrote:
I would be more concerned with convincing the rest of the developers.
adding crap in base profile.bashrc will affect 99% of users, so it
better be friggin correct and useful, otherwise you will piss a ton of
people off.
versus the people who are really annoyed that such support hasnt yet been
integrated into portage proper ?
yes, from the portage side of things, it may be a pita to implement
per-package env ... but from the user side of things, it's a huge help
-mike
My e-mail was basically worded as to say Solar paste your crap to this
ML.
Alright...
tail -n 6 /usr/portage/profiles/uclibc/profile.bashrc
#for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
# if [[ -r /etc/portage/env/$CATEGORY/${conf} ]]; then
# . /etc/portage/env/$CATEGORY/${conf}
# break
# fi
#done
Is there any reason you need package.env in portage proper as
opposed to bashrc?
Nope.. bashrc is the only way to access the variables in a way that
is the most friendly to the bash side of things.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 08 Jun 2006 09:20:18 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Please keep the games bugs in bugzilla. Making this change is a direct change in games team policy without any prior notice to the games team and without our permission. No one needs permission to put ebuilds from bugs.gentoo.org into an overylay. The ebuilds, assuming they have the proper header, are all Distributed under the terms of the GNU General Public License v2. ~tcort pgpp7kESK1ig9.pgp Description: PGP signature
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
On Thu, 2006-06-08 at 13:42 +0100, Chris Bainbridge wrote: On 08/06/06, Matteo Azzali [EMAIL PROTECTED] wrote: Hum, maybe my little english is not good to explain my thoughts. I already have a /usr/local/portage overlay bigger than 500Kb. I can beat that, try 23MB :-/ Anyway, back to your point - yes, there are lots of bugs with patches attached that aren't being added to the main tree. And there are lots of bugs where the ebuild or fix is ending up in an overlay rather than the main tree. It's getting complicated to keep track - all I can really advise is that if you'd like to see fixes and ebuilds being added to the main tree, then become a developer and start doing it (although it is complex for something like gcc compile fixes which are spread across packages owned by multiple developers who will get upset if you touch their package). Actually, this isn't exactly true. In the case of a compile fix, such as this, the developer is aware of the issue, and gcc-porting@ is on the bug, too, as CC, usually. If someone from gcc-porting were to go around committing patches to my ebuilds, I know I wouldn't mind. It would reduce my workload greatly, especially as they're the experts on what is and isn't allowed in gcc 4.1, versus myself, who is a gcc 4.1 amateur. ;] The truth is that there's tens of thousands of possible patch-providers (users) and only ~300 people with commit rights. Even fewer when you consider that the package in question may have a single maintainer, or only a small team. Most of the packages that are blocking that bug are games. We're working on them, but there's a small group of us and a very large number of packages, many of which are very poorly coded and require a lot of work and testing. -- 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] fix binary debug support, part elevenity billion + 1
Ned Ludd wrote:
On Thu, 2006-06-08 at 06:49 -0400, Alec Warner wrote:
Mike Frysinger wrote:
On Wednesday 07 June 2006 19:12, Alec Warner wrote:
I would be more concerned with convincing the rest of the developers.
adding crap in base profile.bashrc will affect 99% of users, so it
better be friggin correct and useful, otherwise you will piss a ton of
people off.
versus the people who are really annoyed that such support hasnt yet been
integrated into portage proper ?
yes, from the portage side of things, it may be a pita to implement
per-package env ... but from the user side of things, it's a huge help
-mike
My e-mail was basically worded as to say Solar paste your crap to this
ML.
Alright...
tail -n 6 /usr/portage/profiles/uclibc/profile.bashrc
#for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
# if [[ -r /etc/portage/env/$CATEGORY/${conf} ]]; then
# . /etc/portage/env/$CATEGORY/${conf}
# break
# fi
#done
Ideas on multipile sources?
Aka, I want all these env things enable for kde-base/* but for
kde-base/foo I want extra stuff ( or to negate things ), it looks like
this only sources things once?
Could we define a stacking order here and let them stack?
Is there any reason you need package.env in portage proper as
opposed to bashrc?
Nope.. bashrc is the only way to access the variables in a way that
is the most friendly to the bash side of things.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 09:32 -0400, Thomas Cort wrote: On Thu, 08 Jun 2006 09:20:18 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Please keep the games bugs in bugzilla. Making this change is a direct change in games team policy without any prior notice to the games team and without our permission. No one needs permission to put ebuilds from bugs.gentoo.org into an overylay. The ebuilds, assuming they have the proper header, are all Distributed under the terms of the GNU General Public License v2. I'm sorry, but what does this have to do with me making a request for games ebuilds to not be included? I really don't care if the games ebuilds are in the overlay, so long as the latest ebuilds are *also* in bugzilla, where they belong. Of course, it makes it rather pointless to have to update an ebuild in two locations, but we already *have* an official location for ebuild submissions, and that is bugzilla. Having to troll through some overlay only increases our work load. -- 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] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
Ehrm, I'm already becomed developer (some days) *, I'm already the author of lots of patches/comment in those reports, and as you pointed out I must follow rules and can't jump maintainers (who surely have better understanding of the issue involved than me). That's the cause of the question,my (little?) brain asked me Why there are so much version of a package in portage, and why following bugs for version that aren't the latest stable and the latest unstable (for any arch) instead of ensuring that those 2/3 versions work fine? , I mean, because in some cases a revision bump is necessary to let unstable work fine, (and these will be necessary however when gcc-4.x will become stable) why delaying trying to fix bugs specific of older versions, probably resolved upstream with new ones? (I know, my brain is nasty and doesn't works as others may expect). Other than this, 23MB of overlay? But you clean it or you keep stored every line of code you wrote? If you regularly clean your overlay (keeping no more than 2-3 ebuilds for package), then it's really huge and impressive! [EMAIL PROTECTED] * (I'm not sending mails through gentoo.org account cause http://www.gentoo.org/proj/en/infrastructure/dev-email.xml asks me to not use it to send mails unless absolutely necessary. , and I have others mean of sending emails) Chris Bainbridge wrote: On 08/06/06, Matteo Azzali [EMAIL PROTECTED] wrote: Hum, maybe my little english is not good to explain my thoughts. I already have a /usr/local/portage overlay bigger than 500Kb. I can beat that, try 23MB :-/ Anyway, back to your point - yes, there are lots of bugs with patches attached that aren't being added to the main tree. And there are lots of bugs where the ebuild or fix is ending up in an overlay rather than the main tree. It's getting complicated to keep track - all I can really advise is that if you'd like to see fixes and ebuilds being added to the main tree, then become a developer and start doing it (although it is complex for something like gcc compile fixes which are spread across packages owned by multiple developers who will get upset if you touch their package). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thursday 08 June 2006 15:46, Chris Gianelloni wrote: Having to troll through some overlay only increases our work load. +1 for chris -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpciKqnLh3FT.pgp Description: PGP signature
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
[EMAIL PROTECTED] * (I'm not sending mails through gentoo.org account cause http://www.gentoo.org/proj/en/infrastructure/dev-email.xml asks me to not use it to send mails unless absolutely necessary. , and I have others mean of sending emails) You should always use it on official gentoo mailing lists. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Having to troll through some overlay only increases our work load. That and it would become an an official Gentoo BMG-style repo. Please, let us not officially encourage the ricers. Some of us work very hard to discourage this type of user behavior. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, Jun 08, 2006 at 09:32:13AM -0400, Thomas Cort wrote: On Thu, 08 Jun 2006 09:20:18 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Please keep the games bugs in bugzilla. Making this change is a direct change in games team policy without any prior notice to the games team and without our permission. No one needs permission to put ebuilds from bugs.gentoo.org into an overylay. The ebuilds, assuming they have the proper header, are all Distributed under the terms of the GNU General Public License v2. ~tcort I do not object to the concept of ebuilds in overlays. I do very much object to using any gentoo.org infrastructure or subdomains to do so. If someone is going to tackle that, it should be done outside of Gentoo proper. We don't need to be stuck maintaining and supporting a semiofficial overlay. -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
Ned Ludd wrote:
-for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
+for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
Call it 'default' ?
Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
you can have a package-specific setting, and override it for specific
versions.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thursday 08 June 2006 02:42, Stefan Schweizer wrote: Initially jokey and myself will be working on this. The current focus is to migrate ebuilds from bugzilla into the overlay and to get contributors to commit their changes to the overlay instead of updating the bugzilla every time. Can't agree with that. Users should a) post their ebuilds at bugzilla, since it is the place, we track request and b) get them from there, forced to maintain their own overlay (and actually look at each ebuild), than trust some arbitrary overlay, that is neither supported security wise, nor is ensured that the ebuilds have a minimal quality (do not fubar a users system). Overlays make sense to perform changes how a whole range of packages are handled, to be merged with the official Portage tree, later. What you intend to do is just broken. Don't! Carsten pgpxYMIpJj0pw.pgp Description: PGP signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Jon Portnoy wrote: On Thu, Jun 08, 2006 at 09:32:13AM -0400, Thomas Cort wrote: On Thu, 08 Jun 2006 09:20:18 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Please keep the games bugs in bugzilla. Making this change is a direct change in games team policy without any prior notice to the games team and without our permission. No one needs permission to put ebuilds from bugs.gentoo.org into an overylay. The ebuilds, assuming they have the proper header, are all Distributed under the terms of the GNU General Public License v2. ~tcort I do not object to the concept of ebuilds in overlays. I do very much object to using any gentoo.org infrastructure or subdomains to do so. If someone is going to tackle that, it should be done outside of Gentoo proper. We don't need to be stuck maintaining and supporting a semiofficial overlay. It is my understanding the the Sunrise overlay is not open to anyone to commit, so it is not a contrib/ The sunrise project is the owner of the overlay and they are responsible for it's contents. The people commiting are responsible for what they commit. The point of the Sunrise project as I understand it is to aid in the development of ebuilds in maintainer-wanted, such that they may improve and be added to the tree; as well as to give frequent 'not quite a dev' and 'I don't have a bunch of time but would like to help' people a place to commit to. -Alec -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Jon Portnoy wrote: On Thu, Jun 08, 2006 at 09:32:13AM -0400, Thomas Cort wrote: On Thu, 08 Jun 2006 09:20:18 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Please keep the games bugs in bugzilla. Making this change is a direct change in games team policy without any prior notice to the games team and without our permission. We have good instructions on our trac wiki page[1] for how to work with the overlay. The bottom of the page, point 6) adresses your problem. I do not object to the concept of ebuilds in overlays. I do very much object to using any gentoo.org infrastructure or subdomains to do so. If someone is going to tackle that, it should be done outside of Gentoo proper. We don't need to be stuck maintaining and supporting a semiofficial overlay. This is a problem, that we are working on, see [2] It is obvioous to see if an ebuild comes from an overlay or not with that change. Due to the good metastructure and project support in gentoo it is possible to have most of the overlay-work done in the projects [3] and [4] [1] http://overlays.gentoo.org/proj/sunrise [2] http://bugs.gentoo.org/136031 [PATCH] Display a warning when an overlay-ebuild fails [3] http://www.gentoo.org/proj/en/overlays [4] http://www.gentoo.org/proj/en/overlays/sunrise I am still against the idea of turning this into a flamewar. Better no comments than flaming comments. Please - keep it constructive. Kind regards, - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 11:12 -0400, Alec Warner wrote: It is my understanding the the Sunrise overlay is not open to anyone to commit, so it is not a contrib/ The sunrise project is the owner of the overlay and they are responsible for it's contents. The people commiting are responsible for what they commit. The point of the Sunrise project as I understand it is to aid in the development of ebuilds in maintainer-wanted, such that they may improve and be added to the tree; as well as to give frequent 'not quite a dev' and 'I don't have a bunch of time but would like to help' people a place to commit to. I don't think the problem with maintainer-wanted ebuilds is that they are crappy, but that there is no dev willing to maintain them and ensure their quality over time. 'sunrise' (who came up with that name ? cheap asian poetry attempt) doesn't change that by adding it to an 'official' overlay. Instead of tackling the real problem -the lack of maintainers to deal with all requests- 'sunrise' is trying to create a backdoor for unreliable maintained stuff to enter the tree. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
On Thu, 2006-06-08 at 07:49 -0700, Donnie Berkholz wrote:
Ned Ludd wrote:
-for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
+for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
Call it 'default' ?
Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
you can have a package-specific setting, and override it for specific
versions.
You mean this if only the 'break' is in not in there right?
Thanks,
Donnie
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 11:12 -0400, Alec Warner wrote: It is my understanding the the Sunrise overlay is not open to anyone to commit, so it is not a contrib/ The sunrise project is the owner of the overlay and they are responsible for it's contents. The people commiting are responsible for what they commit. The point of the Sunrise project as I understand it is to aid in the development of ebuilds in maintainer-wanted, such that they may improve and be added to the tree; as well as to give frequent 'not quite a dev' and 'I don't have a bunch of time but would like to help' people a place to commit to. Ehh... except there's *already* ebuilds that are *not* under maintainer-wanted in the overlay. It also doesn't answer the questions of security and maintenance. Are genstef and jokey going to be responsible for the security of every single package in the overlay? Are they going to be responsible for ensuring that the packages adhere to current ebuild standards? How are ebuilds going to get from this overlay into the official repository? Not a single one of these questions has been answered, yet many perfectly valid objections have been brought up by a few developers, with no answers being given. -- 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: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
foser wrote: I don't think the problem with maintainer-wanted ebuilds is that they are crappy, but that there is no dev willing to maintain them and ensure their quality over time. 'sunrise' (who came up with that name ? cheap asian poetry attempt) doesn't change that by adding it to an 'official' overlay. The sunrise name name from Patrick Lauer and I personally really like it :) Instead of tackling the real problem -the lack of maintainers to deal with all requests- 'sunrise' is trying to create a backdoor for unreliable maintained stuff to enter the tree. Please, you are confusing overlay and tree here. And yes - I do try to tackle the real problem with this project. I am hoping to teach quite a few people how to write ebuilds and contribute with the overlay. I am already beeing contacted by interested people and it will only help the situation come better. Eventually a few good recruits might be the result of this project Also the sunriose overlay is an attempt to solve the unreliable maintained problem. You see that for example today we are committing a bunch of gcc-4.1 fixes for ebuilds that are obviously unreliable maintained in gentoo. The sunrise overlay helps to fix stuff quicker and extends the basis of people that can do maintaining work. Please do not comment on this if you have no real improvements to make and just fell like commenting, flaming it. Kind regards, - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Stefan Schweizer wrote: Please do not comment on this if you have no real improvements to make and just fell like commenting, flaming it. Please stop ending every reply by ignoring the real issues and claiming its just people 'flaming'. If you honestly think that every person that replies against your idea is flaming then you need to open your eyes up and see the valid concerns they have (which I agree most on). I'm not at all impressed by your answers for all the questions brought up thus far. Please be more detailed in the reasoning and follow through on questions. Ignoring them will only make the project less credible. I do not support such tactics on infra if this is certainly the case. Cheers- -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 08 Jun 2006 02:42:03 +0200, Stefan Schweizer wrote: Hi, I have founded a new Gentoo Project for the Gentoo User Overlay. The intention is to give contributors a single place to put their ebuilds - a place where they can be downloaded, updated and be moved to portage more easily than through bugzilla. It is also a good place for users who would like to become developers to learn how to commit and how to not break the tree. I think this answers an important shortcoming of the bugzilla approach: vis, some bugs will never make it to the tree -- for any number of reasons. Take, for example, http://bugs.gentoo.org/show_bug.cgi?id=103354, which has an enhancement request for what is now called beyond-sources. A amalgamation of the arch, ck, tiger, nitro, and suspend2 sources. While on the kernel, IRC, I enquired about it, since I had just updated an ebuild for it, and was told unequivocally that there was no interest on the kernel team's part for adding this source tree to sys-kernel. Not maybe, not let's have a look at it, not come back in a month after testing. Just NO. And, I'm fine with that. That's their job -- to protect the quality of their project, and to keep things relatively safe and manageable. Nonetheless, the bug is active, with a good number of people subscribing to it and contributing to it. The sunshine overlay would be an ideal place to store a kernel source tree or any project which would never find a home in portage. As I see it, there are really two main issues with bugzilla. One, is to resolve open ebuild enhancement bugs. Mark them somehow so it's clear the bug has been reviewed and an action determined. CANTFIX/WONTFIX is harsh, but if that's what it is, then mark it! The second issue is the orphaning of packages which have merit, but no maintainer. Again, the sunshine overlay would provide a home for those packages. It will also allow the user to take ownership of a project, get some experience, and maybe decide to become a dev. And, should that occur, then, lo, the orphaned package may have a maintainer someday. So, hopefully, as the overlay project moves forward, it will help take some of the heat off bugzilla and allow for the offering of more ebuilds to userland. JM2C -- Peter -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, Jun 08, 2006 at 10:13:45AM -0400, Stephen P. Becker wrote: That and it would become an an official Gentoo BMG-style repo. Please, let us not officially encourage the ricers. Some of us work very hard to discourage this type of user behavior. I wholeheartedly agree with Stephen on this. You should have brought up the idea for the Sunricers project on this mailing for discussion instead of just going ahead and implementing it. Personally, I dislike the idea of having officially supported (read: hosted on *.gentoo.org infrastructure) overlays for unmaintained ebuilds for which nobody did any real quality assurance. I fear this will drag Gentoo back into the old-ages of having a reputation of a ricer-distribution; a reputation I for one have worked very hard to get rid of during the past 2 years. Please put this project on hold until is has been discussed properly on this mailing list. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpdZwna9ltFc.pgp Description: PGP signature
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 17:29 +0200, Stefan Schweizer wrote: Jon Portnoy wrote: On Thu, Jun 08, 2006 at 09:32:13AM -0400, Thomas Cort wrote: On Thu, 08 Jun 2006 09:20:18 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Please keep the games bugs in bugzilla. Making this change is a direct change in games team policy without any prior notice to the games team and without our permission. We have good instructions on our trac wiki page[1] for how to work with the overlay. The bottom of the page, point 6) adresses your problem. Not really. You've taken what was a simple and open way of addressing ebuild requests, and turned it into a closed forum. With a bug, anyone with a bugzilla account can *contribute* anything that they want, and it is all peer-reviewed. With this overlay, only people that are given access will be allowed to contribute anything. Also, who is going to control access to this resource? Why *is* there access controls? I know that I'm going to hear security as a response, but it is a false one. We already had a completely open resource where any of our users can contribute any ebuilds that they want. You've created a more restrictive and less useful version of this and increased the workload on any developers whose packages are affected, such as the games team with the inclusion of xmoto, which has been rejected in its current state, and knights, which is currently in the tree *and* maintained. I do not object to the concept of ebuilds in overlays. I do very much object to using any gentoo.org infrastructure or subdomains to do so. If someone is going to tackle that, it should be done outside of Gentoo proper. We don't need to be stuck maintaining and supporting a semiofficial overlay. This is a problem, that we are working on, see [2] It is obvioous to see if an ebuild comes from an overlay or not with that change. Due to the good metastructure and project support in gentoo it is possible to have most of the overlay-work done in the projects [3] and [4] [1] http://overlays.gentoo.org/proj/sunrise [2] http://bugs.gentoo.org/136031 [PATCH] Display a warning when an overlay-ebuild fails [3] http://www.gentoo.org/proj/en/overlays [4] http://www.gentoo.org/proj/en/overlays/sunrise I am still against the idea of turning this into a flamewar. Better no comments than flaming comments. Please - keep it constructive. Nobody has turned this into a flame war. We are trying to provide constructive comments. Just because a comment points out ways why this is a bad idea doesn't make it a flame. The only thing that bothers me is the fact that this was done and is something that was explicitly stated would not happen with the overlays project. We now have a semi-official secondary repository, run by a small group of developers, allowed to touch *any* package in the tree however they see fit, whether it goes against the policies of the package's maintainers or not. I'm sorry, but this is not in the spirit of cooperation and working together so much as it is in the spirit of doing what you want, policies be damned. Were this limited *solely* to packages that need maintainers, I would have less of a problem than it being used, as it is currently, to explicitly work outside of the policies of established projects. As I stated several times to you now when you brought up the idea of a games overlay just so you could maintain packages how you wanted, you're more than willing to keep packages that belong under the games herd in a personal *developer* overlay. However, what you've done here is said that you're more important than the established practices of another project, and blatantly disregarded their policies, establishing a project that gives you free reign to do whatever you wish. Does anyone else see this as a problem? -- 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] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 17:45 +0200, foser wrote: Instead of tackling the real problem -the lack of maintainers to deal with all requests- 'sunrise' is trying to create a backdoor for unreliable maintained stuff to enter the tree. Don't forget the free reign it gives to the sunrise development team to bypass any policies in place by the teams responsible for packages that are already in 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: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 18:04 +0200, Stefan Schweizer wrote: Please do not comment on this if you have no real improvements to make and just fell like commenting, flaming it. No. A flame is being insulting to someone. Pointing out problems with an idea is not flaming. Please quit trying to use this term to stifle any comments from anyone that thinks this idea is not good, and has valid points why they think so. -- 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] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Lohrke wrote: On Thursday 08 June 2006 02:42, Stefan Schweizer wrote: Initially jokey and myself will be working on this. The current focus is to migrate ebuilds from bugzilla into the overlay and to get contributors to commit their changes to the overlay instead of updating the bugzilla every time. Can't agree with that. Users should a) post their ebuilds at bugzilla, since it is the place, we track request and b) get them from there, forced to maintain their own overlay (and actually look at each ebuild), than trust some arbitrary overlay, that is neither supported security wise, nor is ensured that the ebuilds have a minimal quality (do not fubar a users system). Overlays make sense to perform changes how a whole range of packages are handled, to be merged with the official Portage tree, later. Agreed. While this is in theory an excellent idea, it won't help right now. In my opinion, what we really need is for some community members to step up and create the world's lauditory adjective Gentoo-ebuild-related clearinghouse, better than BMG etc., that could be used as a better means of submitting ebuilds to bugzie. That way there's much more outside testing and widespread use before (hopefully) very high quality ebuilds and/or overlays are submitted to bugzilla for official Gentoo review. So the workload on the Gentoo devs would be greatly reduced, instead of having to (now) police ebuilds in at least two different locations. Overlays are a pain to manage as it is. I understand that Sunrise is trying to solve the central problem of maintainers, but right now it sounds like it's doing it in a very roundabout, ineffective manner. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEiFKFrsJQqN81j74RAu9XAKCOuXMRWIKQqlVXpAzA9s2DvGA03QCfaGjp f2zhH9DNu9dLONvnh1ACtK4= =kuou -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Peter wrote: Nonetheless, the bug is active, with a good number of people subscribing to it and contributing to it. The sunshine overlay would be an ideal place to store a kernel source tree or any project which would never find a home in portage. Pardon me if I'm totally confused, but isn't this what BMG is for? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On 08/06/06, foser [EMAIL PROTECTED] wrote: I don't think the problem with maintainer-wanted ebuilds is that they are crappy, but that there is no dev willing to maintain them and ensure their quality over time. 'sunrise' (who came up with that name ? cheap asian poetry attempt) doesn't change that by adding it to an 'official' overlay. One of the problems is that developer interest is transitory. The current system suggests that a developer take personal responsibility for ebuilds they maintain, and they maintain them until another developer steps up. It would be nice (and I guess this is one of the aims of sunrise) if there were a way for people to contribute ebuilds that they are interested in at the time, but don't want to promise to maintain forever. Think about wikipedia - how many pages would there be if every page creator had to guarantee that they would maintain each page indefinately? The time it takes to actually apply fixes etc. is another point. Bugzilla is a poor system for sharing and managing the flow of ebuilds and patches. It would be nice if there were a way for non-devs to publish ebuilds/fixes using a VCS so that they could be shared and easily pulled and applied to the main tree. It takes too long to browse bugzilla, find bugs, find ebuilds and patches, download them, copy to an overlay, fix digests, emerge, etc. and most users will figure it's not worth the hassle. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Henrik Brix Andersen wrote: Personally, I dislike the idea of having officially supported (read: hosted on *.gentoo.org infrastructure) overlays for unmaintained ebuilds for which nobody did any real quality assurance. I fear this will drag Gentoo back into the old-ages of having a reputation of a ricer-distribution; a reputation I for one have worked very hard to get rid of during the past 2 years. I agree here. When I decided to help out the overlays project, I thought I had made it clear that I didn't want to support a BMG-style repo on official hardware. It was for things like php, perl, etc that had their own overlay and were actively working out specific issues for their project. What you're proposing goes against what I supported initially. There was a lengthy discussion about this months ago, but apparently this group decided to ignore all the points in it and just go with this without consulting the group first. If you can't sort out the issues that have been brought out here, I'm afraid I'm going to have to decline my support on infra hardware for this specific project (but not the other overlays so people don't have a fit :-) ). -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
Ned Ludd wrote:
On Thu, 2006-06-08 at 07:49 -0700, Donnie Berkholz wrote:
Ned Ludd wrote:
-for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
+for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
Call it 'default' ?
Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
you can have a package-specific setting, and override it for specific
versions.
You mean this if only the 'break' is in not in there right?
Didn't catch that on the quick glance -- Actually I'd like if you
removed the break so you can do what I suggested.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT] Initially jokey and myself will be working on this. The current focus is to migrate ebuilds from bugzilla into the overlay and to get contributors to commit their changes to the overlay instead of updating the bugzilla every time. I'm not opposed to what would essentially be an overlay of maintainier-wanted ebuilds, but I would actually prefer to see that happen by pulling from the bugzilla database instead of trying to replace bugzilla altogether. My reasoning is that bugzilla provides a place for community development of an ebuild (including commentary!), which would not be true of just the overlay. If one were instead to add a magical bugs whiteboard status or keyword that let a script know that there's an ebuild to pull from bugzilla that should be added to the there-be-dragons-here overlay, I'd think that would make life much simpler for everybody. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpcquPFfyhuM.pgp Description: PGP signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On 08/06/06, Jon Portnoy [EMAIL PROTECTED] wrote: I do very much object to using any gentoo.org infrastructure or subdomains to do so. If someone is going to tackle that, it should be done outside of Gentoo proper. We don't need to be stuck maintaining and supporting a semiofficial overlay. There are already loads of semi-official overlays. Besides the stuff actually hosted by gentoo (random example http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official groups (again, not picking on anyone but exampes would be java, php, webapps...) with semi-official overlays. I don't know if the overlays are actually hosted on gentoo hardware, but when they're run by gentoo devs, publically available, and referred to in forums, bugzilla, mailing lists etc. then that at least makes them semi-official. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Chris Bainbridge wrote: On 08/06/06, Jon Portnoy [EMAIL PROTECTED] wrote: I do very much object to using any gentoo.org infrastructure or subdomains to do so. If someone is going to tackle that, it should be done outside of Gentoo proper. We don't need to be stuck maintaining and supporting a semiofficial overlay. There are already loads of semi-official overlays. Besides the stuff actually hosted by gentoo (random example http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official groups (again, not picking on anyone but exampes would be java, php, webapps...) with semi-official overlays. I don't know if the overlays are actually hosted on gentoo hardware, but when they're run by gentoo devs, publically available, and referred to in forums, bugzilla, mailing lists etc. then that at least makes them semi-official. These overlays are completely controlled by Gentoo developers, which is what the overlays.gentoo.org was going to be, simply a single location for all these developer controlled overlays. This project is an overlay (un)controlled by random users, with no quality checks or any standards of any kind. This is fine for non-gentoo hosted stuff (like BMG), but hosting stuff like this on *.gentoo.org, and not having the use go through hoops to use it is probably not a good idea from either a security or QA standpoint. Currently 3rd party ebuilds can live in bugzilla, and the use must create their own overlay, and generate their own digests to use them. Making a user put this extra work into encourages users to be more careful, and hopefully look stuff over before using it. It also reinforces that the package is _unsupported_, hence discouraging them from filing any new bugs. Having a semi-official overlay where users can contribute ebuilds will open possible security problems (malicious commits) as well as be a QA/bug triaging nightmare as developers will have to figure out whether the ebuild the user is using came from the official overlay or the official tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Grant Goodyear wrote: Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT] Initially jokey and myself will be working on this. The current focus is to migrate ebuilds from bugzilla into the overlay and to get contributors to commit their changes to the overlay instead of updating the bugzilla every time. I'm not opposed to what would essentially be an overlay of maintainier-wanted ebuilds, but I would actually prefer to see that happen by pulling from the bugzilla database instead of trying to replace bugzilla altogether. My reasoning is that bugzilla provides a place for community development of an ebuild (including commentary!), which would not be true of just the overlay. If one were instead to add a magical bugs whiteboard status or keyword that let a script know that there's an ebuild to pull from bugzilla that should be added to the there-be-dragons-here overlay, I'd think that would make life much simpler for everybody. -g2boojum- FYI I've been tinkering with something similar using gentoo-bugger, but I haven't had time to work on it recently. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's ready to be removed from package.mask sometime soon (next week). Before that happens, I'd like to get some feedback from a broader test base, so if you have some time and aren't using eselect-compiler yet, I'd appreciate your testing. All you need to do is add the following to /etc/portage/package.unmask: This aliases g77 to gfortran and gfortran to g77. They are entirely different compilers and do not accept all the same options. This is incredibly broken behavior, it masks issues in a number of packages and creates new issues in many others. Please fix it. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eselect-compiler updates and unmasking
Donnie Berkholz wrote: This aliases g77 to gfortran and gfortran to g77. They are entirely different compilers and do not accept all the same options. This is incredibly broken behavior, it masks issues in a number of packages and creates new issues in many others. Please fix it. It also doesn't run env-update, so the library paths aren't updated. In the past, all that was necessary was to source /etc/profile. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Retirement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Howdy All, I've decided that its time for me to move on from Gentoo. I have no ill feelings and still enjoy using the distribution. With work and everything else going on in life I don't have much time to devote to the distribution anymore. I am sure at some point I'll emerge from retirement. Happy Gentooing. Regards, Ryan Phillips -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEiGxU6cLeDQrpxL8RAvVgAJ4tFZNEeFQe7vnAqOUXgTMntbjKSwCfU65a 4oXr2dqIXVPjAQ3kec5hAfs= =/oEx -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, Jun 08, 2006 at 12:27:47PM -0400, Chris Gianelloni wrote: Does anyone else see this as a problem? I think it is clear from the comments in this thread that your view is shared by many other Gentoo developers. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpLMwBnP2GUo.pgp Description: PGP signature
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, Jun 08, 2006 at 12:26:50PM -0400, Peter wrote: And, I'm fine with that. That's their job -- to protect the quality of their project, and to keep things relatively safe and manageable. Nonetheless, the bug is active, with a good number of people subscribing to it and contributing to it. The sunshine overlay would be an ideal place to store a kernel source tree or any project which would never find a home in portage. What's wrong with using BMG for uofficial and potentially broken stuff like your proposed beyond-sources? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpQCfkMPAMYB.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
To clarify things a bit (hopefully): 1) security This is not the main tree, just a normal overlay. Okay, some non-devs contribute here but doesn't change the fact that it is just an overlay as any other out there in the world. Well, it is a bit different. Here are some devs keeping an eye on the evolution and can help people with doing it right and thus get better contributions in the end. 2) responsibility As already mentioned at 1), it is an overlay. The devs on sunrise do keep an eye on it and all ebuilds do have to pass at least repoman and some basic QA checks (currently done when porting them from bugs.g.o) so that they don't do some rm -rf / thing. They should be improved by the contributors then so that we have two things here: a) a contributor who can contribute good-quality ebuils and b) a good ebuild to be picked up by a dev and ported to the tree 3) replacement for bugs.g.o This project isn't a try to replace the contributions to bugs. It should just help to fetch and update things. We have help from bug-wranglers here (well, at least from jakub) to keep the overlay in sync with it so that one can say Yeah, my-example/myapp r158 has this and this issue, here is a fix for it and then either the sunrise-devs or one of the project-contributors commits it to the overlay. 4) workload on devs Well I really have problems to see increased workload on devs here who don't actively support the project. They can scour bugzie for interesting ebuilds and instead of fetching files, renaming them, moving them to a local overlay dir, just do a svn co http://overlays.gentoo.org/svn/proj/sunrise/sys-auth/pam_skey/ (as an example here) and you have all needed files already prepared to look at them or to give them a try. 5) the tarball problem On some bugs we also notice that people contribute tarballs instead of ebuilds and the files as such. Some apps need a change on a bunch of files with every version bump. Take MailScanner as an example ( http://bugs.gentoo.org/show_bug.cgi?id=36060 ). Many devs cry out loud when they come across a tarball on bugzie. It is not the best way of contribution, I know that myself. But take it the otherway around. Someone out there took time (on some apps it is really much time) and provided an ebuild. Maybe he is new to it and doesn't know much about bugzie (no usability talk required here, done every 3 months on bugzie devel ml) then they post their hard work there. Then a dev comes along and says never ever do attach tarballs blah blubb, the contributor feels scared as it was his first contribution and the dev was crying out loud and would surely think twice if the work done is worth it. 6) problems on infra hardware Well Lance arised that, so if infra has that big concerns about this project (I personally see no hard reason for it, but let the infra guys handle it how they want), then feel free to drop me a note and we host it elsewhere. I really see a great chance for contributors here as they can improve themselves here and if they contribute good quality, even commit themselves and learn how to handle maintainership. You all know we also have some people out there that would like to maintain just one or two packages. Now we call it proxy maintainership but why not giving them commit access to sunrise then? They can maintain it here without the whole workload as dev, but maybe they get encouraged by doing so and then become a dev later. Lots of options are possible here. 7) non maintainer-wanted things Some ebuilds found their way into the overlay, we talked about that internally and I'll remove them after this mail is sent out, so that we stick to maintainer-wanted things here. Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Markus Ullmann wrote: 6) problems on infra hardware Well Lance arised that, so if infra has that big concerns about this project (I personally see no hard reason for it, but let the infra guys handle it how they want), then feel free to drop me a note and we host it elsewhere. I really see a great chance for contributors here as they can improve themselves here and if they contribute good quality, even commit themselves and learn how to handle maintainership. You all know we also have some people out there that would like to maintain just one or two packages. Now we call it proxy maintainership but why not giving them commit access to sunrise then? They can maintain it here without the whole workload as dev, but maybe they get encouraged by doing so and then become a dev later. Lots of options are possible here. Thanks for the clarification. To clarify my point, I'm all for helping our distro, but I just don't want this project to be labeled as a more official BMG. If you suit the needs of what the devs think is the right way to do this, then I'm all for it. I just noticed several mails from the project that seemed to be ignoring the issues at hand and I wasn't going to support the project on infra if they continued to be like that. Thanks for answering most of those questions. I'll let the developer community decide if they like them or not :-). -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, Jun 08, 2006 at 08:58:48PM +0200, Markus Ullmann wrote: This is not the main tree, just a normal overlay. Okay, some non-devs contribute here but doesn't change the fact that it is just an overlay as any other out there in the world. Well, it is a bit different. Here are some devs keeping an eye on the evolution and can help people with doing it right and thus get better contributions in the end. It's not a normal overlay as I see it. You've promoted it to be an official overlay. The difference is huge in my opinion. As already mentioned at 1), it is an overlay. The devs on sunrise do keep an eye on it and all ebuilds do have to pass at least repoman and some basic QA checks (currently done when porting them from bugs.g.o) so that they don't do some rm -rf / thing. Will you also review the code each and every ebuild pull down over the internet? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpbX3aW1uIEb.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thursday 08 June 2006 20:58, Markus Ullmann wrote: 3) replacement for bugs.g.o I would prefer if people would still comment on the bugs when they do some changes on the overlay so that at least we know that. Some ebuilds found their way into the overlay, we talked about that internally and I'll remove them after this mail is sent out, so that we stick to maintainer-wanted things here. This is appreciated. On this note, I would like to ask what are you going to do with eclasses. From my POV I'd ask to absolutely _not_ touching eclasses at all in the overlay. I have bad past experiences with overlays replacing eclasses. As bad as with xgl overlay rewriting some of the kde packages and breaking then with gcc 4.1 :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpO5e5GSRzQc.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Чтв, 2006-06-08 at 21:20 +0200, Henrik Brix Andersen wrote: It's not a normal overlay as I see it. You've promoted it to be an official overlay. The difference is huge in my opinion. IMO such overlay should be official! Why not to keep all (partially) broken ebuilds in one place? This is the same story as with German gentoo forum that is outside gentoo.org and thus none of devs wanted to keep eyes there, so forum became much less useful. Another problem with BMG is that it is gnome oriented, as cleary stated on About page and thus I never thought that my, fex, www-apps could be there. As already mentioned at 1), it is an overlay. The devs on sunrise do keep an eye on it and all ebuilds do have to pass at least repoman and some basic QA checks (currently done when porting them from bugs.g.o) so that they don't do some rm -rf / thing. Will you also review the code each and every ebuild pull down over the internet? And that is really exciting moment. :) The main difference between such overlay and wiki is that reading text never does `rm -rf /`. How can one stop such jokes? I think if this problem will be solved such overlay should be. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Чтв, 2006-06-08 at 21:20 +0200, Henrik Brix Andersen wrote: It's not a normal overlay as I see it. You've promoted it to be an official overlay. The difference is huge in my opinion. IMO such overlay should be official! Why not to keep all (partially) broken ebuilds in one place? This is the same story as with German gentoo forum that is outside gentoo.org and thus none of devs wanted to keep eyes there, so forum became much less useful. Another problem with BMG is that it is gnome oriented, as cleary stated on About page and thus I never thought that my, fex, www-apps could be there. As already mentioned at 1), it is an overlay. The devs on sunrise do keep an eye on it and all ebuilds do have to pass at least repoman and some basic QA checks (currently done when porting them from bugs.g.o) so that they don't do some rm -rf / thing. Will you also review the code each and every ebuild pull down over the internet? And that is really exciting moment. :) The main difference between such overlay and wiki is that reading text never does `rm -rf /`. How can one stop such jokes? I think if this problem will be solved such overlay should be. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 12:26 -0400, Peter wrote: I think this answers an important shortcoming of the bugzilla approach: vis, some bugs will never make it to the tree -- for any number of reasons. Take, for example, http://bugs.gentoo.org/show_bug.cgi?id=103354, which has an enhancement request for what is now called beyond-sources. A amalgamation of the arch, ck, tiger, nitro, and suspend2 sources. While on the kernel, IRC, I enquired about it, since I had just updated an ebuild for it, and was told unequivocally that there was no interest on the kernel team's part for adding this source tree to sys-kernel. Not maybe, not let's have a look at it, not come back in a month after testing. Just NO. And, I'm fine with that. That's their job -- to protect the quality of their project, and to keep things relatively safe and manageable. Nonetheless, the bug is active, with a good number of people subscribing to it and contributing to it. The sunshine overlay would be an ideal place to store a kernel source tree or any project which would never find a home in portage. See, that's the misconception. An overlay for this set of sources, and possibly other sources, would be what fits in better with the original idea of overlays.gentoo.org, as it was presented before it was approved. Here's the problem, as I see it. If you're filing a bug and you have this sunshine overlay in your overlay list, I have exactly 0 clue what you might be using from this overlay, since it covers *everything*. This means that I, as a package maintainer, have no idea if you've used some modified kernel/glibc/gcc/whatever that could be affecting my package inadvertently. This means I have exactly 2 choices, spend time researching what is and isn't in this overlay and determine if any of it could possibly effect my package and *then* start to try to troubleshoot the bug, or mark it as RESOLVED-INVALID (or whatever) and ask you to try again without the overlay. It is a *huge* amount of overhead. On the other hand, if you had a kernel-sources overlay, and are having a problem compiling a non-kernel package, it is not very likely that the kernel is the source of the problem, so the overhead is minimal to none. The name of the overlay matches what the project would be, and everything is transparent to both the user and also to the developer. Were there a rule that said that *nothing* from the tree could be present in this overlay, then it wouldn't be nearly as much of a problem. It would still have the problem presented above, but it would be slightly less of a problem, since I now don't have to worry about if your version of knights is the one from the tree or from the overlay. As I see it, there are really two main issues with bugzilla. One, is to resolve open ebuild enhancement bugs. Mark them somehow so it's clear the bug has been reviewed and an action determined. CANTFIX/WONTFIX is harsh, but if that's what it is, then mark it! The second issue is the orphaning of packages which have merit, but no maintainer. Again, the sunshine overlay would provide a home for those packages. It will also allow the user to take ownership of a project, get some experience, and maybe decide to become a dev. And, should that occur, then, lo, the orphaned package may have a maintainer someday. This is something that I do not get. Why exactly does everything have to be resolved in some specific time frame? Is when I get to it not good enough? I mean, it works for Linus, right? ;p As for packages that have merit, this is quite simple. If the package has enough of a good following, it will get picked up. The likely reason why many of the maintainer-wanted packages are in the state they're in is simply because there isn't enough interest in the package. In this particular instance, I can see an external overlay being useful. However, there already is one. It is called breakmygentoo. Do we really need to duplicate their functionality? So, hopefully, as the overlay project moves forward, it will help take some of the heat off bugzilla and allow for the offering of more ebuilds to userland. I sincerely hope it doesn't effect bugzilla in any way. I have no problem with users getting access to ebuilds, but many of these ebuilds simply are not ready for anyone to get them automatically. Having an ebuild on a bug makes it easily searchable. Having an ebuild on a bug makes it easy to peer review. Having an ebuild on a bug means the user needs to explicitly add the ebuild to their overlay. The idea behind the overlays project, as it was presented, was to assist projects in doing development by allowing outside contributors to more easily interact with specific projects or teams. It was not designed to bypass Gentoo's security or quality assurance policies, nor was it designed to allow a mechanism to give our users substandard ebuilds. The idea isn't so bad, but the benefits definitely do not outweigh the negatives.
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Henrik Brix Andersen wrote: It's not a normal overlay as I see it. You've promoted it to be an official overlay. The difference is huge in my opinion. Well partly you're right. As it is promoted that way it is a bit more official but anyway still an overlay. Will you also review the code each and every ebuild pull down over the internet? Well at least briefly. We decided to maintain it in an official way and thus keep an eye on the quality of the checkins. As said, at least a briefly view at it and also a repoman scan. We're going to have some contributors at it so it wouldn't be an easy job but I think we can get some more of them that way. Searched my inbox and found a mail saying this: --- Paste --- He was trying to recruit me as a Gentoo developer. Unfortunately, I turned him down, the main reason being time. Also, I don't really need/want the status/powers/responsibilities that come with being a developer, so that was another reason. He then suggested that I become an arch-tester, or maybe contribute to this public overlay that you have in mind. The arch-tester position didn't seem that appealing to me. The public overlay on the other hand is more suitable for me. I like to write the occasional ebuild and there are some ebuilds writen by me in Bugzilla that are currently assigned to maintainer-wanted so getting these in an overlay would be nice. Also, I would assume that the barrier of entry and time requirements are lower than the developer position. --- Paste --- Sounds he likes to contribute / maintain some apps, just not the whole thing you have to do when being a full dev. But he expressed his interest in this as a possible entry point. So I guess we can keep an eye on him... But one thing is important: As the project has some overlay nature, there _may_ be the one or other small issue with it. On the other hand what ebuild is 100% bugfree? ;) QA would have nothing todo then... And here we don't break the (stable) tree if some really nasty issue ever slips through our fingers. Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Hi, Both the current discussion as well as the overlay docs don't seem to cover the support topic as far i could see. This is an issue for us forums people though - our daily work involves classifying misplaced threads into officially supported (read: in the tree) and unsupported (someone installed some ebuild he found somewhere else) threads. The latter go into the Unsupported Software forum [1]. For now, we've added Bugs/errors caused by ebuilds from overlays.gentoo.org are covered by this forum, too. to the description of this forum because we think the primary objective of the forums is supporting officially supported ebuilds - those in the tree. I'm not saying it has to be/stay this way forever, but to be honest we are quite taken by surprise to have a new project appear that is both official(?) and unsupported(?) at the same time. So if at some time you intend to point the users of the overlay at the forums, please let them know the US-forum is the place to be. cheers, Wernfried [1] http://forums.gentoo.org/viewforum-f-51.html -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpRxjA9GTxsM.pgp Description: PGP signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 17:48 +0100, Chris Bainbridge wrote: The time it takes to actually apply fixes etc. is another point. This is where I'd respectfully disagree. Bugzilla is a poor system for sharing and managing the flow of ebuilds and patches. It would be nice if there were a way for non-devs to publish ebuilds/fixes using a VCS so that they could be shared and easily pulled and applied to the main tree. It takes too long to browse bugzilla, find bugs, find ebuilds and patches, download them, copy to an overlay, fix digests, emerge, etc. and most users will figure it's not worth the hassle. You mean all of the things that developers have to do, right? Funny, but I thought the idea for the overlays was to groom developers, not to provide low-quality half-working ebuilds to users. Perhaps if we had a bug-tracking system that integrated better with a version control system, allowing for easier access to the ebuilds/patches/etc within a bug report, yet without providing a free for all as the current project suggests? I really don't know what kind of solution would be proper for this, but I do know that the current idea of an overlay for the entire tree is not something that should be taken lightly and definitely not something that should *ever* be done without discussion. -- 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] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
My intention was to solve some parts with him directly and then send out some solutions but he wants to do everything on list, so I'm sending it out for you to know. -- LOGPOST -- [22:09:15] jokey so after reading your posts I get the impression you fear that this project will end up in some BMG overlay just with an official gentoo stamp on it. Am I right here? [22:10:22] wolf31o2|work please read what I said in #-releng [22:11:45] jokey Yes I want to do it public, maybe just attach a log of this to a mail sent to -dev afterwards. just want to avoid having that much emails just for seeking the issues instead of finding solutions for them [22:11:52] wolf31o2|work I think it is a bad idea [22:12:21] wolf31o2|work quite simply, when the overlays project was formed, this was something that was specifically said would never happen [22:12:41] wolf31o2|work I'm going to fight it tooth and nail, because I never would have accepted a project such as overlays if it was going to be abused like this [22:13:02] wolf31o2|work and please don't even say it won't be abused when there's already examples of it being done so [22:13:07] wolf31o2|work and the overlay just began [22:13:16] wolf31o2|work and that's really all I have to say about it [22:13:39] wolf31o2|work (sorry, I prefer my discussions on things that affect *everyone* be done completely in public) [22:14:31] jokey okay, I'll attach this then to a mail just that everybody knows about it then -- LOGPOST -- Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Grant Goodyear wrote: Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT] My reasoning is that bugzilla provides a place for community development of an ebuild (including commentary!), which would not be true of just the overlay. If one were instead to add a magical bugs whiteboard status or keyword that let a script know that there's an ebuild to pull from bugzilla that should be added to the there-be-dragons-here overlay, I'd think that would make life much simpler for everybody. +1 -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 08 Jun 2006 15:51:25 -0400, Chris Gianelloni wrote: First, let me say that I'm approaching this from a user's perspective. I have no insight or knowledge as to the history of the overlay project or any of the people involved. I _do_ know that since late 2004 when I first switched to Gentoo, each week there are more bugs opened than closed. There are also many open bugs that go back years. In my particular frame, I want ebuilds I need or have contributed to get into the tree. Having to download new ebuilds into local, and then have no way to emerge update them is frustrating. My point was about two things: 1) ebuilds that will never be committed to portage, and 2) ebuilds that have been orphaned due to lack of interest. As for breakmygentoo, here is my thought. As a user, I would prefer to do all my shopping in one place. Gentoo has portage and uses ebuilds as a package distribution mechanism. I would prefer to use gentoo's facilities to get additional off-tree ebuilds. I don't want to have to sync all over the place to get ebuilds of unknown origin. I would prefer to have a sanctioned alt-gentoo ebuild repository where I know some q/a is applied and standards adhered to. My inference of the sunshine project was that there would be oversight and control. That if _I_, for example wished to contribute, then I would have to meet standards. And, on the flip side, anyone who would care to download an ebuilt from o.g.o would be confident that the ebuild at least meets certain quality standards. o.g.o, of course would have to disclose that these packages are testing, and possibly experimental, but it's a terrific opportunity to find a home for many orphaned and ignored packages. Using the example I brought up, about the kernel-sources, o.g.o would be a perfect home for such a project. snip. As I see it, there are really two main issues with bugzilla. One, is to resolve open ebuild enhancement bugs. Mark them somehow so it's clear the bug has been reviewed and an action determined. CANTFIX/WONTFIX is harsh, but if that's what it is, then mark it! The second issue is the orphaning of packages which have merit, but no maintainer. Again, the sunshine overlay would provide a home for those packages. It will also allow the user to take ownership of a project, get some experience, and maybe decide to become a dev. And, should that occur, then, lo, the orphaned package may have a maintainer someday. This is something that I do not get. Why exactly does everything have to be resolved in some specific time frame? Is when I get to it not good enough? I mean, it works for Linus, right? ;p Why? Because having two year old bugs is simply inexcusable. Especially when many have not had any activity for a long time. Having maintainer-wanted bugs for months on end is silly. Giving a user who files a ebuild request or submits an ebuild deserves the chance to take ownership of it. It's a good way to get a more experienced user, and hopefully one day, a future dev. As for packages that have merit, this is quite simple. If the package has enough of a good following, it will get picked up. The likely reason why many of the maintainer-wanted packages are in the state they're in is simply because there isn't enough interest in the package. In this particular instance, I can see an external overlay being useful. However, there already is one. It is called breakmygentoo. Do we really need to duplicate their functionality? Well as for packages getting picked up, this is not completely accurate. Some will never get picked up, either because they are inappropriate (hot-babe, for example), or too experimental (the kernel-source example I cited). As for bmg, which I have to admit I had never heard about before today, as a user, I would prefer to have everything genoo-sanctioned and controlled. So, hopefully, as the overlay project moves forward, it will help take some of the heat off bugzilla and allow for the offering of more ebuilds to userland. I sincerely hope it doesn't effect bugzilla in any way. I have no problem with users getting access to ebuilds, but many of these ebuilds simply are not ready for anyone to get them automatically. Having an ebuild on a bug makes it easily searchable. Having an ebuild on a bug makes it easy to peer review. Having an ebuild on a bug means the user needs to explicitly add the ebuild to their overlay. Users would not be getting o.g.o ebuilds automatically. They would have to actively emerge layman, and then select the ebuilds they want. I agree with you that the o.g.o and the main portage tree should never be comingled. But, I do argue that bugzilla is inefficient in getting ebuilds resolved. And, just because o.g.o exists does not in any way mean a user would have to or be advised to skip bugzilla. Some ebuilds will get picked right up, others after some review. All I am suggesting is that o.g.o will help find a home for ebuilds
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 08 Jun 2006 23:52:50 +0400 Peter Volkov (pva) [EMAIL PROTECTED] wrote: | Will you also review the code each and every ebuild pull down over | the internet? | | And that is really exciting moment. :) The main difference between | such overlay and wiki is that reading text never does `rm -rf /`. How | can one stop such jokes? I think if this problem will be solved such | overlay should be. Somehow I think certain people aren't quite grasping the potential security breaches with this whole thing... Slipping in malicious and hard to detect code that gets executed by everybody is very very easy. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Why? Because having two year old bugs is simply inexcusable. Especially when many have not had any activity for a long time. Having maintainer-wanted bugs for months on end is silly. Giving a user who files a ebuild request or submits an ebuild deserves the chance to take ownership of it. It's a good way to get a more experienced user, and hopefully one day, a future dev. Why inexcusable? Why is leaving a bug open indefinately a bad thing? If someone wants it, they can comment on the bug. This isn't a software development project (for the most part :)) so leaving a bug open causes no harm, other than to make it a bit difficult in some instances to find what you are looking for among the large number of filings. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On 6/8/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: Will you also review the code each and every ebuild pull down over the internet? The policy for overlays.gentoo.org hosting [1] is hopefully clear: as the project leads, they're ultimately responsible (and therefore accountable) for what goes into their project overlay - no matter whether it's committed by a dev or by a user who has been entrusted with commit rights to the overlay. The policy for what can go into an overlay is also hopefully clear: overlays are for package trees, their patchsets, any docs, and any downloadable tarballs that have nowhere else to be hosted. It's not there to be $UPSTREAM, except for eselect modules, -config scripts and the like that exist purely to support ebuilds in the package tree. I expect projects and developers who are using overlays to be respectful of others. The whole point of the overlays project is to continue our work in trying to get our users much more involved in developing Gentoo. It's there to be a stepping stone for getting packages into the tree - although I do not expect every package in overlays to end up in the tree. Any hostile hijacking of other people's packages doesn't fit into that vision, and there's no place for it on o.g.o. I also expect projects and developers who are not using overlays to be equally respectful of those who are. There are projects and developers who find overlays an excellent way of safely testing and developing ebuilds, and who find overlays to be a good way to help train and develop the next generation of Gentoo developers (good developers are something we really need more of). If any overlay is ultimately an abuse of the hosting that the overlays project provides, then your first course of redress is with the overlay's owner. If you're still unhappy, then come and talk to me as the Overlays Project team lead. I'm here to listen, and if necessary to act. If I don't agree, you can still go to the Council as a last resort if you feel that strongly about it. [1] http://www.gentoo.org/proj/en/overlays/policy.xml Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, Jun 08, 2006 at 09:35:07PM +0100, Ciaran McCreesh wrote: On Thu, 08 Jun 2006 23:52:50 +0400 Peter Volkov (pva) [EMAIL PROTECTED] wrote: | Will you also review the code each and every ebuild pull down over | the internet? | | And that is really exciting moment. :) The main difference between | such overlay and wiki is that reading text never does `rm -rf /`. How | can one stop such jokes? I think if this problem will be solved such | overlay should be. Somehow I think certain people aren't quite grasping the potential security breaches with this whole thing... Slipping in malicious and hard to detect code that gets executed by everybody is very very easy. My point exactly. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpFg6scJLgGu.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, Jun 08, 2006 at 10:05:38PM +0100, Stuart Herbert wrote: On 6/8/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: Will you also review the code each and every ebuild pull down over the internet? The policy for overlays.gentoo.org hosting [1] is hopefully clear: as the project leads, they're ultimately responsible (and therefore accountable) for what goes into their project overlay - no matter whether it's committed by a dev or by a user who has been entrusted with commit rights to the overlay. [snip] I don't really see how this answers my question, but I do appreciate the summary of the policy for overlays.g.o. I have no problems with the overlay project in general - my concern is about the Sunshine project. [1] http://www.gentoo.org/proj/en/overlays/policy.xml While reading the policy above, I stumbled across this line: Bug Tracking: bugs.g.o is the OneTrueBugTrackingSystem(tm), even for overlays. Could you please elaborate on this? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpnHA655xWmO.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 20:58 +0200, Markus Ullmann wrote: To clarify things a bit (hopefully): 1) security This is not the main tree, just a normal overlay. Okay, some non-devs contribute here but doesn't change the fact that it is just an overlay as any other out there in the world. Well, it is a bit different. Here are some devs keeping an eye on the evolution and can help people with doing it right and thus get better contributions in the end. I know that when I spoke of security, I was not only talking about the security of letting non-developers commit to an overlay that is, by design, for end users, but also of the implications of ensuring that any packages in these overlays are not vulnerable to exploits. 2) responsibility As already mentioned at 1), it is an overlay. The devs on sunrise do keep an eye on it and all ebuilds do have to pass at least repoman and some basic QA checks (currently done when porting them from bugs.g.o) so that they don't do some rm -rf / thing. They should be improved by the contributors then so that we have two things here: a) a contributor who can contribute good-quality ebuils and b) a good ebuild to be picked up by a dev and ported to the tree The problem is that you are only checking on the initial commit. Go back to point #1 (security). Again, the entire concept of overlays.gentoo.org was stated again and again that this would *not* be the result of the project. Many of the maintainer-wanted ebuilds are quite good, many need to be completely rewritten to even work properly. This also completely missing the point that most of the things in maintainer-wanted are there because there is not a developer interested in them. How will this change by moving the ebuild into an overlay, I have yet to hear. 3) replacement for bugs.g.o This project isn't a try to replace the contributions to bugs. It should just help to fetch and update things. We have help from bug-wranglers here (well, at least from jakub) to keep the overlay in sync with it so that one can say Yeah, my-example/myapp r158 has this and this issue, here is a fix for it and then either the sunrise-devs or one of the project-contributors commits it to the overlay. Honestly, having to break out a subversion client to check a fix immediately sounds like extra work. It is usually much easier to simply look at the attachment online and make a decision immediately. 4) workload on devs Well I really have problems to see increased workload on devs here who don't actively support the project. They can scour bugzie for interesting ebuilds and instead of fetching files, renaming them, moving them to a local overlay dir, just do a svn co http://overlays.gentoo.org/svn/proj/sunrise/sys-auth/pam_skey/ (as an example here) and you have all needed files already prepared to look at them or to give them a try. Except that I can *look* at an ebuild without having to break out a subversion client currently. Also, you completely gloss over the fact that this is a overlay designed for end-user usage. This means that anything in this overlay is *very* likely to be on user's machines and cause any number of possible problems. Let's use your pam_skey as an example. Now, let's say that someone has this installed, and has configured it improperly. They file a bug because they are unable to login, and the pam maintainers receive the bug. How exactly are they supposed to know that this user has pam_skey even *available* to them when all they see as an overlay is sunrise and not the project-specific overlays that overlays.gentoo.org was designed for? All of the time wasted to determine that the user has done something unsupported to break their system is time that this developer could be working on a problem with a package that is actually in the portage tree, which is our primary product. 5) the tarball problem On some bugs we also notice that people contribute tarballs instead of ebuilds and the files as such. Some apps need a change on a bunch of files with every version bump. Take MailScanner as an example ( http://bugs.gentoo.org/show_bug.cgi?id=36060 ). Many devs cry out loud when they come across a tarball on bugzie. It is not the best way of contribution, I know that myself. But take it the otherway around. Someone out there took time (on some apps it is really much time) and provided an ebuild. Maybe he is new to it and doesn't know much about bugzie (no usability talk required here, done every 3 months on bugzie devel ml) then they post their hard work there. Then a dev comes along and says never ever do attach tarballs blah blubb, the contributor feels scared as it was his first contribution and the dev was crying out loud and would surely think twice if the work done is worth it. An overlay will have exactly 0 impact on this. You have already stated that the ebuilds will come from bugzilla. That means that a user can still post a tarball and can still
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Hi Henrik, On 6/8/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: While reading the policy above, I stumbled across this line: Bug Tracking: bugs.g.o is the OneTrueBugTrackingSystem(tm), even for overlays. Could you please elaborate on this? Sure ... in the discussion we had on -dev earlier in the year about the overlays service, it was agreed that we wouldn't maintain separate bug tracking systems for each overlay. All the bugs for each overlay will go into bugs.gentoo.org. This means that the following cycle can happen: a) User A submits ebuild via bugzilla b) Developer takes ebuild from bugzilla, and adds it to overlay for testing fixing c) User B submits bug in bugzilla about the ebuild in the overlay For example, we've been working that way in the webapps overlay for some months now, and it's worked well for us (although we haven't been using bugzilla until this week). Hope that answers your question. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 21:57 +0200, Markus Ullmann wrote: Well at least briefly. We decided to maintain it in an official way and thus keep an eye on the quality of the checkins. As said, at least a briefly view at it and also a repoman scan. A repoman scan won't catch subtle bugs caused in other packages by packages in this overlay. It *will* add extra maintenance to any package maintainer within Gentoo. Sounds he likes to contribute / maintain some apps, just not the whole thing you have to do when being a full dev. But he expressed his interest in this as a possible entry point. So I guess we can keep an eye on him... Yes. This person is also fully capable of continuing to provide ebuilds to bugzilla. But one thing is important: As the project has some overlay nature, there _may_ be the one or other small issue with it. On the other hand what ebuild is 100% bugfree? ;) QA would have nothing todo then... And here we don't break the (stable) tree if some really nasty issue ever slips through our fingers. No, but the ebuilds are also checked by the team in question, that actually knows the packages, versus a couple of developers that will be overworked, dealing with packages that they are completely unfamiliar with and have no experience with. I just don't see the two as equal in any way. I also do not see how this helps Gentoo development. The only thing that this does is allows for a few packages that hardly anyone is interested in having become available for our users. That's a noble effort, but there's usually a reason why these packages do not get picked up. -- 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] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 22:20 +0200, Luca Barbato wrote: Grant Goodyear wrote: Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT] My reasoning is that bugzilla provides a place for community development of an ebuild (including commentary!), which would not be true of just the overlay. If one were instead to add a magical bugs whiteboard status or keyword that let a script know that there's an ebuild to pull from bugzilla that should be added to the there-be-dragons-here overlay, I'd think that would make life much simpler for everybody. +1 You mean like: REVIEWED ? -- 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: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 16:23 -0400, Peter wrote: I did not read anything that implied o.g.o would bypass anything other than a lengthy wait in bugzilla land. Other distros have their experimental/testing branches, why can't gentoo? *cough* ~arch *cough* What everybody seems to miss is that having the ebuild in the overlay doesn't bypass any sort of wait. It still is not in the tree. It is still unsupported. Having a couple developers do a 30 second check over an ebuild does not instantly make it good quality. -- 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] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 21:35 +0100, Ciaran McCreesh wrote: On Thu, 08 Jun 2006 23:52:50 +0400 Peter Volkov (pva) [EMAIL PROTECTED] wrote: | Will you also review the code each and every ebuild pull down over | the internet? | | And that is really exciting moment. :) The main difference between | such overlay and wiki is that reading text never does `rm -rf /`. How | can one stop such jokes? I think if this problem will be solved such | overlay should be. Somehow I think certain people aren't quite grasping the potential security breaches with this whole thing... Slipping in malicious and hard to detect code that gets executed by everybody is very very easy. You mean like: perl -e 'print i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' I'm sure everyone will get what that means in a quick cursory glance... and of course repoman will know what it does, right? *grin* -- 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] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: No, but the ebuilds are also checked by the team in question, that actually knows the packages, versus a couple of developers that will be overworked, dealing with packages that they are completely unfamiliar with and have no experience with. I just don't see the two as equal in any way. I also do not see how this helps Gentoo development. Being able to maintain these ebuilds in version control rather than random attachments to bugzilla is a huge improvement. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
First let me state this one really important thing: The sunrise project is a project on its own. We're about to convert it to a TLP to make clear that it shares nothing with the overlay project except the hardware ressources and the overlay feature of portage. Chris Gianelloni wrote: On Thu, 2006-06-08 at 20:58 +0200, Markus Ullmann wrote: To clarify things a bit (hopefully): 1) security I know that when I spoke of security, I was not only talking about the security of letting non-developers commit to an overlay that is, by design, for end users, but also of the implications of ensuring that any packages in these overlays are not vulnerable to exploits. You're right here, there is a chance that your system gets vulnerable. But this isn't limited to this one overlay. All overlays are affected here. 2) responsibility As already mentioned at 1), it is an overlay. The devs on sunrise do keep an eye on it and all ebuilds do have to pass at least repoman and some basic QA checks (currently done when porting them from bugs.g.o) so that they don't do some rm -rf / thing. They should be improved by the contributors then so that we have two things here: a) a contributor who can contribute good-quality ebuils and b) a good ebuild to be picked up by a dev and ported to the tree The problem is that you are only checking on the initial commit. Go back to point #1 (security). You just assume this, no real reason/example for it. Again, the entire concept of overlays.gentoo.org was stated again and again that this would *not* be the result of the project. Many of the maintainer-wanted ebuilds are quite good, many need to be completely rewritten to even work properly. First let me say this. We don't blindly commit things here nor do we commit everything from m-w bugs. There is this interface inbetween called human intelligence. So I can convince you that I do look at things that are committed. This also completely missing the point that most of the things in maintainer-wanted are there because there is not a developer interested in them. How will this change by moving the ebuild into an overlay, I have yet to hear. Well if you can look / test a bit easier, that helps a lot... Some (won't exclude myself here) are just a bit lazy if they see a bunch of things to download, rename and move instead of a single checkout command ;) 3) replacement for bugs.g.o This project isn't a try to replace the contributions to bugs. It should just help to fetch and update things. We have help from bug-wranglers here (well, at least from jakub) to keep the overlay in sync with it so that one can say Yeah, my-example/myapp r158 has this and this issue, here is a fix for it and then either the sunrise-devs or one of the project-contributors commits it to the overlay. Honestly, having to break out a subversion client to check a fix immediately sounds like extra work. It is usually much easier to simply look at the attachment online and make a decision immediately. You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ 4) workload on devs Well I really have problems to see increased workload on devs here who don't actively support the project. They can scour bugzie for interesting ebuilds and instead of fetching files, renaming them, moving them to a local overlay dir, just do a svn co http://overlays.gentoo.org/svn/proj/sunrise/sys-auth/pam_skey/ (as an example here) and you have all needed files already prepared to look at them or to give them a try. Except that I can *look* at an ebuild without having to break out a subversion client currently. See my answer in 3) Also, you completely gloss over the fact that this is a overlay designed for end-user usage. This means that anything in this overlay is *very* likely to be on user's machines and cause any number of possible problems. Let's use your pam_skey as an example. Now, let's say that someone has this installed, and has configured it improperly. They file a bug because they are unable to login, and the pam maintainers receive the bug. How exactly are they supposed to know that this user has pam_skey even *available* to them when all they see as an overlay is sunrise and not the project-specific overlays that overlays.gentoo.org was designed for? Well as the ebuilds in there already have open bugs, comments can be attached there. Secondly, the portage team already integrates a patch to show you a bright warning in the error that you use an overlay... also, if you take a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast that in case you don't find the ebuild in tree that it doesn't belong there. (We even get bugs originating at other overlay's ebuils...) All of
[gentoo-dev] Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 08 Jun 2006 18:09:04 -0400, Chris Gianelloni wrote: On Thu, 2006-06-08 at 16:23 -0400, Peter wrote: I did not read anything that implied o.g.o would bypass anything other than a lengthy wait in bugzilla land. Other distros have their experimental/testing branches, why can't gentoo? *cough* ~arch *cough* What everybody seems to miss is that having the ebuild in the overlay doesn't bypass any sort of wait. It still is not in the tree. It is still unsupported. Having a couple developers do a 30 second check over an ebuild does not instantly make it good quality. You're right. However it allows certain ebuilds to get published long before they would (if ever) waiting in bugzilla maintainer-wanted. Unless I am totally naive or utopian or foolish (or all of the above), what is wrong for having an overlay for orphaned or ebuilds that will never be supported. Things not being in the tree is the whole purpose of the overlay as I understand it. Some things should not be in the tree, some things should. However, for many different reasons, some things that should be in the tree just don't get there. Quality is subjective. I could write a perfect ebuild for foo.bar, but the program could suck. Or, someone could write a piss poor ebuild for best program ever and q/a would slam it rightfully so. Such an ebuild would likely not get onto overlay either. But for those motivated enough to want to push an ebuild, the o.g.o provides such an outlet. And, for me again as a user, using a gentoo-hosted overlay is preferable to a third party repository. This is a personal bias on my part -- and maybe unwarranted. Warn users that ebuild in o.g.o come with no assurances whatsoever, and let the market decide if this is a source worthy of use! -- Peter -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Retirement
Hi Ryan, On 6/8/06, Ryan Phillips [EMAIL PROTECTED] wrote: Howdy All, I've decided that its time for me to move on from Gentoo. I have no ill feelings and still enjoy using the distribution. With work and everything else going on in life I don't have much time to devote to the distribution anymore. I am sure at some point I'll emerge from retirement. Happy Gentooing. Regards, Ryan Phillips I'm sorry to see you go. You were a big help to me when I first came to Gentoo, and one of the reasons I let Seemant and Kurt talk me into becoming a dev :) Best of luck with your retirement. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] herds.xml
So, what would people think of moving herds.xml from gentoo/misc into the portage tree, with the rationale being that local tools could use that information for various useful purposes (compiling statistics, doing something that I can't think of right now, whatever)? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpfhsskhp9M2.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 15:22 -0700, Donnie Berkholz wrote: Chris Gianelloni wrote: No, but the ebuilds are also checked by the team in question, that actually knows the packages, versus a couple of developers that will be overworked, dealing with packages that they are completely unfamiliar with and have no experience with. I just don't see the two as equal in any way. I also do not see how this helps Gentoo development. Being able to maintain these ebuilds in version control rather than random attachments to bugzilla is a huge improvement. Of course they would be, to the team in question. To a few random developers being responsible for *any* kind of package, it won't make much difference since their familiarity level is very near zero. Good examples of this *working* are php, webapps, or even vmware. Bad examples would be this overlay. Instead of a directed and focused overlay, designed to ease testing and development on otherwise intrusive changes to the tree, it is a dumping ground for ebuilds that either weren't good enough, or weren't interesting enough for inclusion. Either that, or they're ebuilds related to an already-established project where the team members simply don't have the time. This is probably the only case where the ebuilds in question might make it into the tree after being in this overlay. This overlay is a dumping ground for the barely-wanted, and little more. As I have said, I don't see it actually improving the situation nearly as much as it will be detrimental to 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] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote: I know that when I spoke of security, I was not only talking about the security of letting non-developers commit to an overlay that is, by design, for end users, but also of the implications of ensuring that any packages in these overlays are not vulnerable to exploits. You're right here, there is a chance that your system gets vulnerable. But this isn't limited to this one overlay. All overlays are affected here. Not like you think that they are. Let me try to make this clearer. The php overlay is maintained by the php developers. They are intimately aware of the issues with their package, and are probably aware of any security bugs before the rest of us. You are talking about a random collection of ebuilds with absolutely no cohesiveness other than they were submitted to bugzilla. How are you going to maintain any form of security on this project? 2) responsibility As already mentioned at 1), it is an overlay. The devs on sunrise do keep an eye on it and all ebuilds do have to pass at least repoman and some basic QA checks (currently done when porting them from bugs.g.o) so that they don't do some rm -rf / thing. They should be improved by the contributors then so that we have two things here: a) a contributor who can contribute good-quality ebuils and b) a good ebuild to be picked up by a dev and ported to the tree The problem is that you are only checking on the initial commit. Go back to point #1 (security). You just assume this, no real reason/example for it. No. It clearly says that you would be doing the basic QA checks and repoman checking on initial commit. You even said it right above where I commented! Honestly, having to break out a subversion client to check a fix immediately sounds like extra work. It is usually much easier to simply look at the attachment online and make a decision immediately. You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Umm... so now I need to go and instead of clicking a nice link in bugzilla, trawl through the subversion repository and find what I'm looking for? How exactly is downloading things via http any different than downloading them from bugzilla, which is also http? Now, I know that you're not an idiot, so please don't treat me like one. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Another thing that people tend to miss is that not all improved versions of ebuilds submitted to bugzilla are done byt he original authors. There are many cases where an initial ebuild is done, a developer makes comments on what needs to be changed, and *another* contributor gives a fixed ebuild. How exactly will this streamline that process? No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. Except that I can *look* at an ebuild without having to break out a subversion client currently. See my answer in 3) See mine. ;] How exactly are they supposed to know that this user has pam_skey even *available* to them when all they see as an overlay is sunrise and not the project-specific overlays that overlays.gentoo.org was designed for? Well as the ebuilds in there already have open bugs, comments can be attached there. This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. Secondly, the portage team already integrates a patch to show you a bright warning in the error that you use an overlay... also, if you take a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast that in case you don't find the ebuild in tree that it doesn't belong there. (We even get bugs originating at other overlay's ebuils...) Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote: I know that when I spoke of security, I was not only talking about the security of letting non-developers commit to an overlay that is, by design, for end users, but also of the implications of ensuring that any packages in these overlays are not vulnerable to exploits. You're right here, there is a chance that your system gets vulnerable. But this isn't limited to this one overlay. All overlays are affected here. Not like you think that they are. Let me try to make this clearer. The php overlay is maintained by the php developers. They are intimately aware of the issues with their package, and are probably aware of any security bugs before the rest of us. You are talking about a random collection of ebuilds with absolutely no cohesiveness other than they were submitted to bugzilla. How are you going to maintain any form of security on this project? The approach is to get them maintained... But there is a chance that there'll be security bugs in it, I admit that. Once we know about it, we p.mask it as we have support for it in the overlay. I'm following most common vuln lists and run some automated scripts already on installed packages, should be easy to adapt them to search one other dir as well. 2) responsibility No. It clearly says that you would be doing the basic QA checks and repoman checking on initial commit. You even said it right above where I commented! You're doing some witch hunting here... I said we keep an eye on non-devs commits. Honestly, having to break out a subversion client to check a fix immediately sounds like extra work. It is usually much easier to simply look at the attachment online and make a decision immediately. You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Umm... so now I need to go and instead of clicking a nice link in bugzilla, trawl through the subversion repository and find what I'm looking for? How exactly is downloading things via http any different than downloading them from bugzilla, which is also http? the key difference is that you only need one wget command to get a completely prepared dir to work on, no ebuild renaming manual files/ population needed. Now, I know that you're not an idiot, so please don't treat me like one. Was really not the intention.. You keeped the svn requirement which is simply wrong. Needed to make that clear. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Another thing that people tend to miss is that not all improved versions of ebuilds submitted to bugzilla are done byt he original authors. There are many cases where an initial ebuild is done, a developer makes comments on what needs to be changed, and *another* contributor gives a fixed ebuild. How exactly will this streamline that process? No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. we want to encourage users to contribute and if they do good contributions in bugzilla they get commit access to the overlay. and then the workload is drastically reduced... How exactly are they supposed to know that this user has pam_skey even *available* to them when all they see as an overlay is sunrise and not the project-specific overlays that overlays.gentoo.org was designed for? Well as the ebuilds in there already have open bugs, comments can be attached there. This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on new bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. Secondly, the portage team already integrates a patch to show you a bright warning in the error that you use an overlay... also, if you take a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast that in case you don't find the ebuild in tree that it doesn't belong there. (We even get bugs originating at other overlay's ebuils...) Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a
Re: [gentoo-dev] herds.xml
On 6/9/06, Grant Goodyear [EMAIL PROTECTED] wrote: So, what would people think of moving herds.xml from gentoo/misc into the portage tree, with the rationale being that local tools could use that information for various useful purposes (compiling statistics, doing something that I can't think of right now, whatever)? How exactly would that be performed and what negative effects would the change produce? -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Stefan Schweizer wrote: ..commit their changes to the overlay instead of updating the bugzilla every time. it is actually encouraged to update bugzilla when changes are made in the overlay. Here are some more things I found in the current thread: chris It also doesn't answer the questions of security and maintenance. Are genstef and jokey going to be responsible for the security of every single package in the overlay? Yes, we will be acting upon all issues that we hear about. chris How are ebuilds going to get from this overlay into the official repository? The people who committed them to the overlay will move them to the tree eventually when they are developers - otherwise any developer can move them if he likes to. Of course taking full responsibility of it, it is also mentioned in the overlay project documentation, that automatic tools for committing to the tree are not allowed. antarus The point of the Sunrise project as I understand it is to aid in the development of ebuilds in maintainer-wanted, such that they may improve and be added to the tree; as well as to give frequent 'not quite a dev' and 'I don't have a bunch of time but would like to help' people a place to commit to. Have to agree here :) chris Why is there access controls? Because we are just following the overlays.g.o standards. There is no actual access controls, because we are not refusing valid requests currently. valid requests = come with a valid change they want to make. carlo that is neither supported security wise, nor is ensured that the ebuilds have a minimal quality (do not fubar a users system). we do support it security wise, we will be reacting upon security issues. We do have package.mask support in the overlay and we are going to use it. The ebuilds have a quality, repoman is required to be run. Also contributors should be knowing what they are doing - they are submitting an ebuild to the sunrise overlay, it needs to follow certain standards. peter The sunshine overlay nice name :) Warn users that ebuild in o.g.o come with no assurances whatsoever, and let the market decide if this is a source worthy of use! That is the plan. g2boojum made some interesting suggestions about how bugzilla could be automatically connected with an overlay - unfortunately no one is working on that. flameeyes 21:38:17 I would prefer if people would still comment on the bugs when they do some changes on the overlay so that at least we know that. yeah that is already suggested by the current guide it is useful for maintainers to know about contributors. eclasses The eclass/ subdirectory has been blocked in the overlay - It is not possible to commit there. If eclasses are needed they need to go through the usual gentoo-dev-review and need to be committed to the main portage tree. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
Matteo Azzali [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] * (I'm not sending mails through gentoo.org account cause http://www.gentoo.org/proj/en/infrastructure/dev-email.xml asks me to not use it to send mails unless absolutely necessary. , and I have others mean of sending emails) I just took a look at that. It's asking that you don't relay mail through dev.gentoo.org unless you can't send mail through your usual means of sending mail. For example, if your ISP blocks mail if the From: header indicates something other @myisp.com, then you need to relay through dev.gentoo.org. In any case, it's not telling you to avoid using your @gentoo.org account. Of course, somebody flame me if I'm wrong. -- my other signature is witty pgpdkdniUrIZu.pgp Description: PGP signature
Re: [gentoo-dev] herds.xml
On Fri, Jun 09, 2006 at 02:54:08AM +0200, Ioannis Aslanidis wrote: On 6/9/06, Grant Goodyear [EMAIL PROTECTED] wrote: So, what would people think of moving herds.xml from gentoo/misc into the portage tree, with the rationale being that local tools could use that information for various useful purposes (compiling statistics, doing something that I can't think of right now, whatever)? How exactly would that be performed and what negative effects would the change produce? Couple of ways- either 1) actual cvs move of the file. Changes required are updating any scripts relying on the existing cvs location (namely http://www.gentoo.org/proj/en/metastructure/herds/herds.xml) 2) placing a copy of the file in the rsync image. Downside, any tool reliant on herds.xml being in the tree will not behave perfectly for cvs users (they don't get the metadata directory typically). One additional to this- the location for the file in the tree *should* be metadata/ - shoving it into profiles is the wrong location (it's not profile data, it's repo metadata). ~harring pgpXPxNuAHvdz.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 09 Jun 2006 02:49:14 +0200 Markus Ullmann [EMAIL PROTECTED] wrote: | No. It clearly says that you would be doing the basic QA checks and | repoman checking on initial commit. You even said it right above | where I commented! | | You're doing some witch hunting here... I said we keep an eye on | non-devs commits. How much do you want to bet that I couldn't sneak malicious code past you? And if you accept that I could do it, you're also admitting that quite a few other random people, some of whom don't share my own ethical objections to such a stunt, could also pull it off given sufficient time and effort... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Peter wrote: On Thu, 08 Jun 2006 02:42:03 +0200, Stefan Schweizer wrote: Hi, I have founded a new Gentoo Project for the Gentoo User Overlay. The intention is to give contributors a single place to put their ebuilds - a place where they can be downloaded, updated and be moved to portage more easily than through bugzilla. It is also a good place for users who would like to become developers to learn how to commit and how to not break the tree. I think this answers an important shortcoming of the bugzilla approach: vis, some bugs will never make it to the tree -- for any number of reasons. Take, for example, http://bugs.gentoo.org/show_bug.cgi?id=103354, which has an enhancement request for what is now called beyond-sources. A amalgamation of the arch, ck, tiger, nitro, and suspend2 sources. While on the kernel, IRC, I enquired about it, since I had just updated an ebuild for it, and was told unequivocally that there was no interest on the kernel team's part for adding this source tree to sys-kernel. Not maybe, not let's have a look at it, not come back in a month after testing. Just NO. And, I'm fine with that. That's their job -- to protect the quality of their project, and to keep things relatively safe and manageable. Nonetheless, the bug is active, with a good number of people subscribing to it and contributing to it. The sunshine overlay would be an ideal place to store a kernel source tree or any project which would never find a home in portage. If the ebuild will never find a home in portage, then it shouldn't be officially supported. What you are proposing is like to setup a parallel portage tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Chris Bainbridge wrote: On 08/06/06, foser [EMAIL PROTECTED] wrote: I don't think the problem with maintainer-wanted ebuilds is that they are crappy, but that there is no dev willing to maintain them and ensure their quality over time. 'sunrise' (who came up with that name ? cheap asian poetry attempt) doesn't change that by adding it to an 'official' overlay. One of the problems is that developer interest is transitory. The current system suggests that a developer take personal responsibility for ebuilds they maintain, and they maintain them until another developer steps up. It would be nice (and I guess this is one of the aims of sunrise) if there were a way for people to contribute ebuilds that they are interested in at the time, but don't want to promise to maintain forever. Think about wikipedia - how many pages would there be if every page creator had to guarantee that they would maintain each page indefinately? The time it takes to actually apply fixes etc. is another point. Bugzilla is a poor system for sharing and managing the flow of ebuilds and patches. It would be nice if there were a way for non-devs to publish ebuilds/fixes using a VCS so that they could be shared and easily pulled and applied to the main tree. It takes too long to browse bugzilla, find bugs, find ebuilds and patches, download them, copy to an overlay, fix digests, emerge, etc. and most users will figure it's not worth the hassle. Yes, i agree, writting and maintaining ebuilds is a hard and *time-consuming* task. So if an user can't even take the time to fix a digest, why we should support him officially?. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Chris Bainbridge wrote: On 08/06/06, Jon Portnoy [EMAIL PROTECTED] wrote: I do very much object to using any gentoo.org infrastructure or subdomains to do so. If someone is going to tackle that, it should be done outside of Gentoo proper. We don't need to be stuck maintaining and supporting a semiofficial overlay. There are already loads of semi-official overlays. Besides the stuff actually hosted by gentoo (random example http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official groups (again, not picking on anyone but exampes would be java, php, webapps...) with semi-official overlays. I don't know if the overlays are actually hosted on gentoo hardware, but when they're run by gentoo devs, publically available, and referred to in forums, bugzilla, mailing lists etc. then that at least makes them semi-official. I don't agree with that semi-official term. We for example have an overlay for the Haskell project. Nevertheless, we consider it the official overlay for our group, but not for Gentoo. So that way we can use it as our sand-box, to play with it as much as we can, and giving commit access to even non-developers, the advantage with this model, is that at some degree we compromise ourselves as a group with the little base users who dare to test experimental stuff (that probably will *never* find its way into portage), but we keep Gentoo as project excluded from such a responsibility. And.. isn't that the real sense behind the overlay concept?, to have an official overlay wouldn't break the main goal of it?, and even more, an official maintainer-wanted overlay sounds more crazy to me. Regards, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Peter wrote: On Thu, 08 Jun 2006 15:51:25 -0400, Chris Gianelloni wrote: First, let me say that I'm approaching this from a user's perspective. I have no insight or knowledge as to the history of the overlay project or any of the people involved. I _do_ know that since late 2004 when I first switched to Gentoo, each week there are more bugs opened than closed. There are also many open bugs that go back years. In my particular frame, I want ebuilds I need or have contributed to get into the tree. Having to download new ebuilds into local, and then have no way to emerge update them is frustrating. My point was about two things: 1) ebuilds that will never be committed to portage, and 2) ebuilds that have been orphaned due to lack of interest. As for breakmygentoo, here is my thought. As a user, I would prefer to do all my shopping in one place. Gentoo has portage and uses ebuilds as a package distribution mechanism. I would prefer to use gentoo's facilities to get additional off-tree ebuilds. I don't want to have to sync all over the place to get ebuilds of unknown origin. I would prefer to have a sanctioned alt-gentoo ebuild repository where I know some q/a is applied and standards adhered to. My inference of the sunshine project was that there would be oversight and control. That if _I_, for example wished to contribute, then I would have to meet standards. And, on the flip side, anyone who would care to download an ebuilt from o.g.o would be confident that the ebuild at least meets certain quality standards. o.g.o, of course would have to disclose that these packages are testing, and possibly experimental, but it's a terrific opportunity to find a home for many orphaned and ignored packages. Using the example I brought up, about the kernel-sources, o.g.o would be a perfect home for such a project. snip. As I see it, there are really two main issues with bugzilla. One, is to resolve open ebuild enhancement bugs. Mark them somehow so it's clear the bug has been reviewed and an action determined. CANTFIX/WONTFIX is harsh, but if that's what it is, then mark it! The second issue is the orphaning of packages which have merit, but no maintainer. Again, the sunshine overlay would provide a home for those packages. It will also allow the user to take ownership of a project, get some experience, and maybe decide to become a dev. And, should that occur, then, lo, the orphaned package may have a maintainer someday. This is something that I do not get. Why exactly does everything have to be resolved in some specific time frame? Is when I get to it not good enough? I mean, it works for Linus, right? ;p Why? Because having two year old bugs is simply inexcusable. You are always free to fix them. Or even better, free to become a dev and maintain them. Especially when many have not had any activity for a long time. Having maintainer-wanted bugs for months on end is silly. Giving a user who files a ebuild request or submits an ebuild deserves the chance to take ownership of it. It's a good way to get a more experienced user, and hopefully one day, a future dev. I agree. It depends at the end upon the user interest to submit/maintain an ebuild. Though that is our current situation with bugzilla too, so i don't see what is the advantage of the overlay here. As for packages that have merit, this is quite simple. If the package has enough of a good following, it will get picked up. The likely reason why many of the maintainer-wanted packages are in the state they're in is simply because there isn't enough interest in the package. In this particular instance, I can see an external overlay being useful. However, there already is one. It is called breakmygentoo. Do we really need to duplicate their functionality? Well as for packages getting picked up, this is not completely accurate. Some will never get picked up, either because they are inappropriate (hot-babe, for example), or too experimental (the kernel-source example I cited). As for bmg, which I have to admit I had never heard about before today, as a user, I would prefer to have everything genoo-sanctioned and controlled. So, hopefully, as the overlay project moves forward, it will help take some of the heat off bugzilla and allow for the offering of more ebuilds to userland. I sincerely hope it doesn't effect bugzilla in any way. I have no problem with users getting access to ebuilds, but many of these ebuilds simply are not ready for anyone to get them automatically. Having an ebuild on a bug makes it easily searchable. Having an ebuild on a bug makes it easy to peer review. Having an ebuild on a bug means the user needs to explicitly add the ebuild to their overlay. Users would not be getting o.g.o ebuilds automatically. They would have to actively emerge layman, and then select the ebuilds they want. I agree with you that the o.g.o and the main portage tree should never
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Stuart Herbert wrote: On 6/8/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: Will you also review the code each and every ebuild pull down over the internet? The policy for overlays.gentoo.org hosting [1] is hopefully clear: as the project leads, they're ultimately responsible (and therefore accountable) for what goes into their project overlay - no matter whether it's committed by a dev or by a user who has been entrusted with commit rights to the overlay. The policy for what can go into an overlay is also hopefully clear: overlays are for package trees, their patchsets, any docs, and any downloadable tarballs that have nowhere else to be hosted. It's not there to be $UPSTREAM, except for eselect modules, -config scripts and the like that exist purely to support ebuilds in the package tree. I expect projects and developers who are using overlays to be respectful of others. The whole point of the overlays project is to continue our work in trying to get our users much more involved in developing Gentoo. It's there to be a stepping stone for getting packages into the tree - although I do not expect every package in overlays to end up in the tree. Any hostile hijacking of other people's packages doesn't fit into that vision, and there's no place for it on o.g.o. I also expect projects and developers who are not using overlays to be equally respectful of those who are. There are projects and developers who find overlays an excellent way of safely testing and developing ebuilds, and who find overlays to be a good way to help train and develop the next generation of Gentoo developers (good developers are something we really need more of). That is being done with the per-group overlays. No need to have a maintainer-wanted official overlay for it. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Project Sunrice: arch team perspective
Starting a new thread here for a new angle... As Stuart mentioned, bugs for any ebuild on o.g.o would go through Gentoo bugzilla. It seems like genstef and jokey have completely ignored support from arch teams for this overlay. What are you proposing with respect to arch keywords and package.mask? Do you actually expect us to do anything but close assigned bugs for sunrice ebuilds as WONTFIX? Where else would these bugs go except for arch teams, seeing as we clearly can't assign them to end users who originally submitted the maintainer-wanted ebuilds? -Steve -- gentoo-dev@gentoo.org mailing list
