[gentoo-dev] ALSA...

[gentoo-dev] ALSA...

[Zach Forrest]

I seem to recall someone saying that the new version of alsa will not 
work with KDE (i.e. that it needed to be compiled *without* alsa 
support). Is this the case? I haven't been able to get sound working in 
KDE since upgrading. Are there still outstanding issues?

Thanks,
Zach

Re: [gentoo-dev] ALSA...

[Dan Armak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 06 May 2002 22:00, Zach Forrest wrote:
> I seem to recall someone saying that the new version of alsa will not
> work with KDE (i.e. that it needed to be compiled *without* alsa
> support). Is this the case? I haven't been able to get sound working in
> KDE since upgrading. Are there still outstanding issues?
>

arts and kdelibs do compile against alsa 0.9, but kdemultimedia doesn't. 
You'll have to compile it without alsa support for now. noatun etc. will work 
because they access alsa through arts, but kmidi and kmix won't.

- -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE82DMJUI2RQ41fiVERApgfAJ44sJhBagzmnaZLiNK9p3Y1uTYCmgCeLwaq
b1RX+vGRNSi3nGlcgruGdp0=
=ABMP
-----END PGP SIGNATURE-----

Re: [gentoo-dev] ALSA...

[Zach Forrest]

Thanks, Dan.

Zach

Dan Armak wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday 06 May 2002 22:00, Zach Forrest wrote:
> 
>>I seem to recall someone saying that the new version of alsa will not
>>work with KDE (i.e. that it needed to be compiled *without* alsa
>>support). Is this the case? I haven't been able to get sound working in
>>KDE since upgrading. Are there still outstanding issues?
>>
> 
> 
> arts and kdelibs do compile against alsa 0.9, but kdemultimedia doesn't. 
> You'll have to compile it without alsa support for now. noatun etc. will work 
> because they access alsa through arts, but kmidi and kmix won't.
> 
> - -- 
> Dan Armak
> Gentoo Linux developer (KDE)
> Matan, Israel
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE82DMJUI2RQ41fiVERApgfAJ44sJhBagzmnaZLiNK9p3Y1uTYCmgCeLwaq
> b1RX+vGRNSi3nGlcgruGdp0=
> =ABMP
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 

Re: [gentoo-dev] ALSA...

[Zach Forrest]

Dan, would it make sense to have an alsa0.9 USE setting? That way the 
kdemultimedia (or other) ebuild could be setup to deal with the problem 
until it plays nice with ALSA. Just a thought.

Zach

Dan Armak wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday 06 May 2002 22:00, Zach Forrest wrote:
> 
>>I seem to recall someone saying that the new version of alsa will not
>>work with KDE (i.e. that it needed to be compiled *without* alsa
>>support). Is this the case? I haven't been able to get sound working in
>>KDE since upgrading. Are there still outstanding issues?
>>
> 
> 
> arts and kdelibs do compile against alsa 0.9, but kdemultimedia doesn't. 
> You'll have to compile it without alsa support for now. noatun etc. will work 
> because they access alsa through arts, but kmidi and kmix won't.
> 
> - -- 
> Dan Armak
> Gentoo Linux developer (KDE)
> Matan, Israel
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE82DMJUI2RQ41fiVERApgfAJ44sJhBagzmnaZLiNK9p3Y1uTYCmgCeLwaq
> b1RX+vGRNSi3nGlcgruGdp0=
> =ABMP
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 

Re: [gentoo-dev] ALSA...

[Arcady Genkin]

Zach Forrest <zach@disinformation.ca> writes:

> Dan, would it make sense to have an alsa0.9 USE setting? That way the
> kdemultimedia (or other) ebuild could be setup to deal with the
> problem until it plays nice with ALSA. Just a thought.

IMO this is just a transient problem and not worth a separate USE
flag.  The ebuild for the broken apps may be adjusted to somehow work
around this while they are still broken.
-- 
Arcady Genkin
Thanks God I'm still an atheist! -- Luis Bunuel

Re: [gentoo-dev] ALSA...

[Zach Forrest]

Fair enough.

Arcady Genkin wrote:
> Zach Forrest <zach@disinformation.ca> writes:
> 
> 
>>Dan, would it make sense to have an alsa0.9 USE setting? That way the
>>kdemultimedia (or other) ebuild could be setup to deal with the
>>problem until it plays nice with ALSA. Just a thought.
> 
> 
> IMO this is just a transient problem and not worth a separate USE
> flag.  The ebuild for the broken apps may be adjusted to somehow work
> around this while they are still broken.

[gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Philippe Lafoucrière]

I was reading the new newsletter, especially the part : "Releases do not
matter in Gentoo Linux.".If releases really doesn't matter, why 1.4
isn't out ? I DO know you can use a 1.4RC1/2/3/4 live cd have an up to
date system with emerge -u, but newbies don't.

This is a really bad idea to add more and more features to live cds
without release. People that have never tried gentoo would think this is
a permanent BETA, which is not. Gentoo is really mature and stable now.

Maybe we'll need a Gentoo Project Leader, as Debian did. If there's
already one, he has to communicate much more ! Gentoo really needs some
serious management, and especially a ROADMAP. Gentoo users are walking
in fog now...

Philippe







-- 
Philippe Lafoucrière <lafou@wanadoo.fr>
InFuzzion


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

On Mon, Jun 23, 2003 at 08:22:11AM +0200, Philippe Lafoucrière wrote:
> I was reading the new newsletter, especially the part : "Releases do not
> matter in Gentoo Linux.".If releases really doesn't matter, why 1.4
> isn't out ? I DO know you can use a 1.4RC1/2/3/4 live cd have an up to
> date system with emerge -u, but newbies don't.

Bringing out a final version (1.4 in this case) is more than just telling
people it's okay to use this version. It is also an event that will get
noticed by other parties, not only distrowatch, linuxtoday and other
newssites, but also LUGs and companies.

Therefor a 1.4-release should be a milestone with certain criteria in mind.
One of them (which I take very seriously) is documentation: you cannot
release a final version without having all documentation ready. The same goes
for the translations.

Another one are the milestone-targets that were made public some weeks ago:
	* Baselayout independent of tmpfs
	* CFLAGS documentation or a tool that gives CFLAGS-building
	  functionality
	* GRP creation and testing
	* Kernelscript to help ppl configure their kernel

Most of those demands have been met, but GRP still needs some testing
(correct me if I am wrong).

Also, the LiveCD should work with as many configurations as possible. If you
check bugs.gentoo.org for the term "livecd" you'll see that there are still
bugs to be addressed. 

Avenj (Gentoo Release Coordinator), seemant (Development Manager) and
drobbins (Chief Architect) should _all_ be able to sleep tight when
the release is made. If one of them isn't sure about something, then the
release should be delayed.

Wkr,
	Sven Vermeulen
	Gentoo Documentation
	Dutch Translations
-- 
Thanks to DRM, you know that something has been built in environment of 
unspecified degree of security, from source you cannot check, written by 
programmers you don't know, released after passing QA of unknown quality and 
which is released under a license that disclaims any responsibility...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

On Mon, Jun 23, 2003 at 08:22:11AM +0200, Philippe Lafoucrière wrote:
> I was reading the new newsletter, especially the part : "Releases do not
> matter in Gentoo Linux.".If releases really doesn't matter, why 1.4
> isn't out ? I DO know you can use a 1.4RC1/2/3/4 live cd have an up to
> date system with emerge -u, but newbies don't.
> 
> This is a really bad idea to add more and more features to live cds
> without release. People that have never tried gentoo would think this is
> a permanent BETA, which is not. Gentoo is really mature and stable now.
> 
> Maybe we'll need a Gentoo Project Leader, as Debian did. If there's
> already one, he has to communicate much more ! Gentoo really needs some
> serious management, and especially a ROADMAP. Gentoo users are walking
> in fog now...
> 

There are two versions: release versions and profile versions.

Release versions _only apply to install media_.

Profile versions (such as default-x86-1.4) define the characteristics of 
your installed system.

1.4 isn't out because it's not ready. Frankly, I can cook you up a 
half-baked LiveCD and set of stages with absolutely no value over rc4 
right now, if you're that obsessed with having something out there with 
'1.4' on it. Instead, we're trying to get you, the user, things like 
GRP, an enhanced LiveCD, automatic CFLAGS generation and kernel initrd 
creation, and so on.

Futurely we will probably be removing 'rc' from the version number 
because it suggests 'beta' to people, which is not the case. We will 
probably move to a system like 1.5, 1.5.1, 1.5.2...

I am not sure what you mean by 'project leader' - do you think that 
currently there is nobody in charge at all? Perhaps you can elaborate 
here. (Daniel Robbins is effectively our 'project leader' - I am the 
releases coordinator.)

What kinds of communication are you looking for? When anyone has asked, 
I have been happy to tell them what's going on with releases. With 
regards to a roadmap, what kind of roadmap? For what in particular? 
Portage? Releases?

Looking for constructive suggestions,

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Philippe Lafoucrière]

> There are two versions: release versions and profile versions.
> 
> Release versions _only apply to install media_.



> Profile versions (such as default-x86-1.4) define the characteristics of 
> your installed system.

I know that. This is not cleary explained on gentoo website. Newbies may
be confused about that.

> 1.4 isn't out because it's not ready. Frankly, I can cook you up a 
> half-baked LiveCD and set of stages with absolutely no value over rc4 
> right now, if you're that obsessed with having something out there with 
> '1.4' on it. Instead, we're trying to get you, the user, things like 
> GRP, an enhanced LiveCD, automatic CFLAGS generation and kernel initrd 
> creation, and so on.

That what I said. What's wrong with rc4 livecd ? Gentoo is experiencing
some bad use of RCs. RC is a release Candidate. It means that no more
feature would appear between 2 RCs. A new RC is just fixed bugs.

Here is some confusion between RC and BETA I think. Since you add some
features, Gentoo 1.4 RC4 is in fact GENTOO 1.4 BETA4 (yeah, it sucks).

> Futurely we will probably be removing 'rc' from the version number 
> because it suggests 'beta' to people, which is not the case. We will 
> probably move to a system like 1.5, 1.5.1, 1.5.2...

I hope. User/Newbies would better understand.

> I am not sure what you mean by 'project leader' - do you think that 
> currently there is nobody in charge at all? Perhaps you can elaborate 
> here. (Daniel Robbins is effectively our 'project leader' - I am the 
> releases coordinator.)

I've never seen a mail of Daniel Robbins here. I saw his name on
gentoo.org, and some IBM articles (developper works).Gentoo management
is really "opaque".

> What kinds of communication are you looking for? When anyone has asked, 
> I have been happy to tell them what's going on with releases. With 
> regards to a roadmap, what kind of roadmap? For what in particular? 
> Portage? Releases?

First, for that:

"""
        * Baselayout independent of tmpfs
        * CFLAGS documentation or a tool that gives CFLAGS-building
          functionality
        * GRP creation and testing
        * Kernelscript to help ppl configure their kernel
"""

You'll have to read all newsletters to find such infos. Newbies won't.
Maybe we lack a section on the gentoo website.

> Looking for constructive suggestions

Take a look at a simple but precise Roadmap :
http://kopete.sourceforge.net/index.php?page=roadmap

note : there are no dates in front of tasks !

This would help so much since volonteers would help on remaining tasks,
instead of asking every time.


best regards 
Philippe


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Michael Kohl]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

On 23 Jun 2003 10:03:08 +0200
Philippe Lafoucrière <lafou@wanadoo.fr> wrote:

> I've never seen a mail of Daniel Robbins here. 

Not to long ago he posted in the "Portage ported to OS X". But I guess
he's spending more of his time on gentoo-core and doing actual work.
Bad?

Michael

-- 
www.cargal.org 
GnuPG-key-ID: 0x90CA09E3
Jabber-ID: citizen428 [at] cargal [dot] org
Registered Linux User #278726

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Luke Graham]

On Mon, 23 Jun 2003 06:10 pm, Michael Kohl wrote:
> On 23 Jun 2003 10:03:08 +0200
>
> Philippe Lafoucrière <lafou@wanadoo.fr> wrote:
> > I've never seen a mail of Daniel Robbins here.
>
> Not to long ago he posted in the "Portage ported to OS X". But I guess
> he's spending more of his time on gentoo-core and doing actual work.
> Bad?

I have a couple of hundred mails with his name on them from this list alone, 
not so many recent ones, but hes certainly out there somewhere.

There is a question in the FAQ that addresses the updating question, but it is 
vague and should be fixed. I really couldnt care less about the names of 
unstable livecd's, new users should always use the recommended version and 
then forget about it. Once they understand the way versions work, they wont 
care either.

If anything in the newsletters is really vital for newbies, it will also be 
put into the installation instructions or whereever. Or you could start a 
hints-and-tricks page if you wanted.

As far as the roadmap goes, gentoo is a much bigger project than kopete, and 
there are actually a few different teams taking it in different directions 
(embeddedgentoo, hardenedgentoo, ebuild-janitor, mac-gentoo, frontends, etc, 
etc). These projects arent under the control of the main project.

-- 
luke

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] ALSA

[Ovidiu Ghinet]

What about what i have post about ALSA a few days ago isn;t anyone 
interest in fixing those bugs? at least so i can know what i can do i mean 
i may fix that but after that if a wanna share them who is to be 
contacted..


For those that do not remember my issue about alsa it was about 
alsa-driver.ebuild that in may opinion need to be different so that sound 
will work with both 2.4 kernel and 2.5.x kernel

OPLEASE REPLY..


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ALSA

[Jon Ellis]

On Monday, June 23, 2003, at 05:46  PM, Ovidiu Ghinet wrote:
>
> For those that do not remember my issue about alsa it was about
> alsa-driver.ebuild that in may opinion need to be different so that 
> sound
> will work with both 2.4 kernel and 2.5.x kernel

Please open a bug and assign it to gentoo-sound. We can discuss there.

Thanks

j.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Svyatogor]

Hi!
You know all this listing of featues which we're trying to get by 1.4 made me 
wonder if there is any kind of roadmap, which tells which features will be in 
the next version. Of course I don't expect to see plans for version 1.6 and 
so on but I'd love to know what are those functions which will be in the next 
release.

On Monday 23 June 2003 07:05, Jon Portnoy wrote:
>
> 1.4 isn't out because it's not ready. Frankly, I can cook you up a
> half-baked LiveCD and set of stages with absolutely no value over rc4
> right now, if you're that obsessed with having something out there with
> '1.4' on it. Instead, we're trying to get you, the user, things like
> GRP, an enhanced LiveCD, automatic CFLAGS generation and kernel initrd
> creation, and so on.
>

-- 
Sergey Kuleshov <svyatogor@gentoo.org>
Let the Force be with us!


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ALSA

[Ovidiu Ghinet]

You see there is no gentoo-sound bugzilla accoun i submited the bug 
without assigning it


On Mon, 23 Jun 2003, Jon Ellis wrote:

> On Monday, June 23, 2003, at 05:46  PM, Ovidiu Ghinet wrote:
> >
> > For those that do not remember my issue about alsa it was about
> > alsa-driver.ebuild that in may opinion need to be different so that 
> > sound
> > will work with both 2.4 kernel and 2.5.x kernel
> 
> Please open a bug and assign it to gentoo-sound. We can discuss there.
> 
> Thanks
> 
> j.
> 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

On Mon, Jun 23, 2003 at 04:10:21PM +0800, Michael Kohl wrote:
> On 23 Jun 2003 10:03:08 +0200
> Philippe Lafoucrière <lafou@wanadoo.fr> wrote:
> 
> > I've never seen a mail of Daniel Robbins here. 
> 
> Not to long ago he posted in the "Portage ported to OS X". But I guess
> he's spending more of his time on gentoo-core and doing actual work.
> Bad?
> 
> Michael
> 
> -- 
> www.cargal.org 
> GnuPG-key-ID: 0x90CA09E3
> Jabber-ID: citizen428 [at] cargal [dot] org
> Registered Linux User #278726

Daniel is very busy. There's no reason he should have to be constantly 
out in the community - do you get upset if Linus Torvalds isn't posting 
to every Linux-related mailing list all the time?

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

On Mon, Jun 23, 2003 at 01:14:10PM -0400, Jon Portnoy wrote:
> On Mon, Jun 23, 2003 at 04:10:21PM +0800, Michael Kohl wrote:
> > On 23 Jun 2003 10:03:08 +0200
> > Philippe Lafoucrière <lafou@wanadoo.fr> wrote:
> > 
> > > I've never seen a mail of Daniel Robbins here. 
> > 
> > Not to long ago he posted in the "Portage ported to OS X". But I guess
> > he's spending more of his time on gentoo-core and doing actual work.
> > Bad?
> > 
> > Michael
> > 
> > -- 
> > www.cargal.org 
> > GnuPG-key-ID: 0x90CA09E3
> > Jabber-ID: citizen428 [at] cargal [dot] org
> > Registered Linux User #278726
> 
> Daniel is very busy. There's no reason he should have to be constantly 
> out in the community - do you get upset if Linus Torvalds isn't posting 
> to every Linux-related mailing list all the time?
> 

Sorry, I should clarify: This was directed at Philippe, not Michael.


-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

I'm wondering, is there a page anywhere that documents and explains the GRP?  Is it just an expanded set of pkgname-bin ebuilds, with the bins ready to go on an install cd?

On Mon, 23 Jun 2003 08:43:51 +0200
Sven Vermeulen <swift@gentoo.org> wrote:

> Another one are the milestone-targets that were made public some weeks ago:
> 	* Baselayout independent of tmpfs
> 	* CFLAGS documentation or a tool that gives CFLAGS-building
> 	  functionality
> 	* GRP creation and testing
> 	* Kernelscript to help ppl configure their kernel

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

On Mon, Jun 23, 2003 at 04:28:05PM -0700, Matt Thrailkill wrote:
> I'm wondering, is there a page anywhere that documents and explains the GRP?  Is it just an expanded set of pkgname-bin ebuilds, with the bins ready to go on an install cd?
> 

No page that I know of. It's just a set of prebuilt .tbz2 binaries for 
big apps.


-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Stewart]

Jon Portnoy wrote:
> What kinds of communication are you looking for? When anyone has asked, 
> I have been happy to tell them what's going on with releases. With 
> regards to a roadmap, what kind of roadmap? For what in particular? 
> Portage? Releases?

It would be nice to be able to visit www.gentoo.org and see a roadmap of 
desired (major) functionality in the up-coming Gentoo releases. The 
things detailed in previous e-mails to this list, as well as the other 
major functionality differences (ie; GCC 3) would be fantastic.

I'd also like to see, even if it's not quite so prevalent on the page, a 
Portage roadmap. Every time somebody mentions the Portage changes, 
they're pointed to the CVS commit log. Frankly, that's not good enough 
for new users, corporate users (sponsors?), or, really, any 
non-developers. A roadmap of major development to the core of our 
distribution would be helpful, rather than having major functionality 
sprung on us. I'll bet most users don't know about such changes until 
the (beeping) einfo at the end of the portage update.

As far as releases go, the Mozilla project has a great roadmap, found 
here; <http://www.mozilla.org/roadmap.html> detailing goals and 
explanations of each, as well as a listing of primary developers.

-- 
Stewart Honsberger
http://blackdeath.snerk.org/
"Capitalists, by nature, organize to protect themselves.
-- Geeks, by nature, resist organizaion."


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

Why not go all the way and have prebuilt bzips for all the apps that come with a release?  That'd be really nifty.  Too much server space?

On Mon, 23 Jun 2003 20:58:13 -0400
Jon Portnoy <avenj@gentoo.org> wrote:
> 
> No page that I know of. It's just a set of prebuilt .tbz2 binaries for 
> big apps.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Tue, Jun 24, 2003 at 03:16:03AM -0700, Matt Thrailkill wrote:
> Why not go all the way and have prebuilt bzips for all the apps that come
> with a release?  That'd be really nifty.  Too much server space?

This is almost impossible, due to the many combinations of tools with respect
to USE-flag settings. The GRPs are made so that the users are able to have a
working desktop so that they don't have to wait 2 days before having a
functional KDE :)

Wkr,
	Sven Vermeulen

-- 
Thanks to DRM, you know that something has been built in environment of 
unspecified degree of security, from source you cannot check, written by 
programmers you don't know, released after passing QA of unknown quality and 
which is released under a license that disclaims any responsibility...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

On Tue, Jun 24, 2003 at 03:16:03AM -0700, Matt Thrailkill wrote:
> Why not go all the way and have prebuilt bzips for all the apps that come with a release?  That'd be really nifty.  Too much server space?
> 
> On Mon, 23 Jun 2003 20:58:13 -0400
> Jon Portnoy <avenj@gentoo.org> wrote:
> > 
> > No page that I know of. It's just a set of prebuilt .tbz2 binaries for 
> > big apps.
> 
> --
> gentoo-dev@gentoo.org mailing list

What do you mean by 'come with a release'? Very little comes with a 
release, just the base system.

By big apps I mean things like KDE and GNOME.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

What combination of use flags do the GRPs use?  The ones that would be in the default make.conf upon installation of v1.4?  Different ones depending on the whims of the maintainer of that GRP app?  If the former... then use those flags on all the prebuilt bzip2s.  Make it so I can give up the bleeding edge on something for the ability to have a working app without waiting an hour to compile :)

On Tue, 24 Jun 2003 14:08:07 +0200
Sven Vermeulen <swift@gentoo.org> wrote:

> On Tue, Jun 24, 2003 at 03:16:03AM -0700, Matt Thrailkill wrote:
> > Why not go all the way and have prebuilt bzips for all the apps that come
> > with a release?  That'd be really nifty.  Too much server space?
> 
> This is almost impossible, due to the many combinations of tools with respect
> to USE-flag settings. The GRPs are made so that the users are able to have a
> working desktop so that they don't have to wait 2 days before having a
> functional KDE :)
> 
> Wkr,
> 	Sven Vermeulen

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

Well which versions of KDE and GNOME?  Something random that has nothing to do with the ebuilds that come with v1.4?  Will new GRPs of KDE and GNOME be built every single time an ebuild for them is updated?

On Tue, 24 Jun 2003 13:18:10 -0400
Jon Portnoy <avenj@gentoo.org> wrote:

> What do you mean by 'come with a release'? Very little comes with a 
> release, just the base system.
> 
> By big apps I mean things like KDE and GNOME.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

On Tue, Jun 24, 2003 at 04:26:32PM -0700, Matt Thrailkill wrote:
> What combination of use flags do the GRPs use?  The ones that would be in the default make.conf upon installation of v1.4?  Different ones depending on the whims of the maintainer of that GRP app?  If the former... then use those flags on all the prebuilt bzip2s.  Make it so I can give up the bleeding edge on something for the ability to have a working app without waiting an hour to compile :)
> 
> On Tue, 24 Jun 2003 14:08:07 +0200
> Sven Vermeulen <swift@gentoo.org> wrote:
> 
> > On Tue, Jun 24, 2003 at 03:16:03AM -0700, Matt Thrailkill wrote:
> > > Why not go all the way and have prebuilt bzips for all the apps that come
> > > with a release?  That'd be really nifty.  Too much server space?
> > 
> > This is almost impossible, due to the many combinations of tools with respect
> > to USE-flag settings. The GRPs are made so that the users are able to have a
> > working desktop so that they don't have to wait 2 days before having a
> > functional KDE :)
> > 
> > Wkr,
> > 	Sven Vermeulen
> 
> --
> gentoo-dev@gentoo.org mailing list

As far as I know, default flags are used.

CC'ing jmorgan, who is managing GRP.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

On Tue, Jun 24, 2003 at 04:27:33PM -0700, Matt Thrailkill wrote:
> Well which versions of KDE and GNOME?  Something random that has nothing to do with the ebuilds that come with v1.4?  Will new GRPs of KDE and GNOME be built every single time an ebuild for them is updated?
> 
> On Tue, 24 Jun 2003 13:18:10 -0400
> Jon Portnoy <avenj@gentoo.org> wrote:
> 
> > What do you mean by 'come with a release'? Very little comes with a 
> > release, just the base system.
> > 
> > By big apps I mean things like KDE and GNOME.
> 
> --
> gentoo-dev@gentoo.org mailing list

I'm not sure what you mean.

GRP is only built for releases (and only final releases). The current 
stable version at the time of building is used.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

On Tue, Jun 24, 2003 at 09:22:00PM -0700, Matt Thrailkill wrote:
> Tracing back up the thread, I should have clarified that when I said "apps that come with a release", I meant the version of the Portage tree at the time of release.
> 
> When the actual 1.4 release is made, there's an exact Portage tree frozen in time that *is* that release, no?  Whether its actually tagged in cvs or something, or only exists in the install isos, there is a version of the portage tree that I would call the 1.4 release.  Or am I all wrong and noone keeps such close track of the Portage tree?

You're correct. We use a snapshot of the tree to build stages. However, 
stages have (relatively) few apps... most of them small.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

Tracing back up the thread, I should have clarified that when I said "apps that come with a release", I meant the version of the Portage tree at the time of release.

When the actual 1.4 release is made, there's an exact Portage tree frozen in time that *is* that release, no?  Whether its actually tagged in cvs or something, or only exists in the install isos, there is a version of the portage tree that I would call the 1.4 release.  Or am I all wrong and noone keeps such close track of the Portage tree?

Debian and the BSDs seem to keep pretty close tracks of their trees.  When they make a release they fork the tree off and call the fork a stable or release version, just update it with security fixes, etc.

On Tue, 24 Jun 2003 20:30:39 -0400
Jon Portnoy <avenj@gentoo.org> wrote:

> I'm not sure what you mean.
> 
> GRP is only built for releases (and only final releases). The current 
> stable version at the time of building is used.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

Has there been any talk of having an option to select a snapshot of the Portage tree to be pulled down during rsyncing?  Or perhaps even forks of the tree to represent stable, unstable, this version, that version?  I suppose the different profiles facilitate this somewhat, but it doesn't seem terribly granular.

I think it'd be really great to be able to install Gentoo on a server box, and tell it "Keep the Portage tree locked to v1.4-Stable" and be confident that every time I update my world, I'm only getting critical bug and security fixes, that there is no risk of wildly different init scripts or config files coming down, or broken ebuilds, or silly snafu's of apps that suddenly don't work -- all of which seem to still occur even if I leave ACCEPT_KEYWORDS undefined.

And then having that server locked to the specific release branch, I could rely on GRP packages rather than putting it under load when I need to install something, or at the least having to wait however long it may take to compile whatever it is.  And I know that because I'm sticking to the stable tree, I'm running the stuff that the maintainers have beat on and tested and that the maintainers have confidence in the reliability and quality of what was put in that release.

On Wed, 25 Jun 2003 00:19:56 -0400
Jon Portnoy <avenj@gentoo.org> wrote:

> You're correct. We use a snapshot of the tree to build stages. However, 
> stages have (relatively) few apps... most of them small.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

(Do you think you could fix word wrapping in your client? When reading 
mails it doesn't matter, but it screws up quoting on replies... hence 
this top-post)

We plan to have functionality to allow you to only merge security 
updates. I don't know the status of this...

On Tue, Jun 24, 2003 at 09:49:04PM -0700, Matt Thrailkill wrote:
> Has there been any talk of having an option to select a snapshot of the Portage tree to be pulled down during rsyncing?  Or perhaps even forks of the tree to represent stable, unstable, this version, that version?  I suppose the different profiles facilitate this somewhat, but it doesn't seem terribly granular.
> 
> I think it'd be really great to be able to install Gentoo on a server box, and tell it "Keep the Portage tree locked to v1.4-Stable" and be confident that every time I update my world, I'm only getting critical bug and security fixes, that there is no risk of wildly different init scripts or config files coming down, or broken ebuilds, or silly snafu's of apps that suddenly don't work -- all of which seem to still occur even if I leave ACCEPT_KEYWORDS undefined.
> 
> And then having that server locked to the specific release branch, I could rely on GRP packages rather than putting it under load when I need to install something, or at the least having to wait however long it may take to compile whatever it is.  And I know that because I'm sticking to the stable tree, I'm running the stuff that the maintainers have beat on and tested and that the maintainers have confidence in the reliability and quality of what was put in that release.
> 
> On Wed, 25 Jun 2003 00:19:56 -0400
> Jon Portnoy <avenj@gentoo.org> wrote:
> 
> > You're correct. We use a snapshot of the tree to build stages. However, 
> > stages have (relatively) few apps... most of them small.
> 
> --
> gentoo-dev@gentoo.org mailing list

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

On Wed, 25 Jun 2003 00:53:43 -0400
Jon Portnoy <avenj@gentoo.org> wrote:

> (Do you think you could fix word wrapping in your client? When reading
> 
> mails it doesn't matter, but it screws up quoting on replies... hence 
> this top-post)

This better?  I wasn't paying attention.. guess Sylpheed doesn't do it
by default.


> We plan to have functionality to allow you to only merge security 
> updates. I don't know the status of this...

Hopefully it'll get hashed out with the manager reorg thing.  I'm still
crossing my fingers for binaries of everything in the snapshot of the
on-release Portage trees, it'd be nifty for quick install & low-power
systems.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jon Portnoy]

On Tue, Jun 24, 2003 at 10:12:57PM -0700, Matt Thrailkill wrote:
> On Wed, 25 Jun 2003 00:53:43 -0400
> Jon Portnoy <avenj@gentoo.org> wrote:
> 
> > (Do you think you could fix word wrapping in your client? When reading
> > 
> > mails it doesn't matter, but it screws up quoting on replies... hence 
> > this top-post)
> 
> This better?  I wasn't paying attention.. guess Sylpheed doesn't do it
> by default.
> 

Much, thanks :)

> 
> > We plan to have functionality to allow you to only merge security 
> > updates. I don't know the status of this...
> 
> Hopefully it'll get hashed out with the manager reorg thing.  I'm still
> crossing my fingers for binaries of everything in the snapshot of the
> on-release Portage trees, it'd be nifty for quick install & low-power
> systems.

Well, GRP does involve everything involved in 'emerge -e <packagename>' 
which means most of the base system should be there...

You should be able to get the current grp list by looking in 
gentoo-src/grp on our viewcvs (http://cvs.gentoo.org should get you 
there) - check emerge -pe on those to see what the full list would be.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[rob holland]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]


Matt,

Gentoo doesn't use cvs tree's in the way that (for example) I know OpenBSD 
does. Generally there is no use of branches at all, everything is in HEAD. 
(Someone please correct me if I'm wrong).

The stable/unstable stuff is done using keywords in portage, rather than 
handled using tags in CVS. The reason being that only developers use CVS so 
the branches would be irrelevant to the users, they'd just get whatever 
branch the rsync mirrors were "tuned to".

The gentoo system is one big lump (no offense intended) rather than one 
quick moving lump (HEAD) and a slow moving one (1_4_STABLE) al la obsd.

I hope that clarifies/helps.

Regards,

Rob

--

robh@gentoo.org / robh:irc.freenode.net
http://cvs.gentoo.org/~robh/robh@gentoo.org.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

For some reason I don't feel to comfortable only being able to choose
between a moving "stable" lump, and a faster moving unstable lump.

Just a meager user comment.  I run Gentoo "stable" on my desktop and
laptop, but it seems like things still change a bit too much and too
largely to where I'd feel comfortable deploying it on a server.

Or heck, if I'm doing a large-scale complex deployment, there doesn't
seem to be a way for me to stick with what I know may be good (i.e.
1.4-release) and still get bug fixes and security updates through
Portage short of me maintaining my own tree and having my machines pull
that down.

When 1.4 is done and 1.5 starts getting all the stuff that is considered
unstable now, is there going to be a new profile for 1.5 I guess?  Or is
it going to be a little sloppier, with both 1.4-stable and 1.4-unstable
slipping forward more and more before a new profile gets made?

Seems like being really anal about profiles, i.e. when the dev team
decides to make a new profile for such and such feature set, could
accomplish most of this.  Even then though, wouldn't the local Portage
tree have to contain all the ebuilds in all the profiles?  That could
start getting fat after a while, since any one machine is only going to
use a subset of ebuilds.  If strict version control was done with
profiles, it might be a good idea then to make rsyncs pull down just the
piece of the tree with the ebuilds for the current profile.

Yes, I know, long long musing to go with such a small quote.  Granular
version control makes me feel comfortable about what goes onto my
machines.


On Wed, 25 Jun 2003 10:07:25 +0000
rob holland <robh@gentoo.org> wrote:

> The stable/unstable stuff is done using keywords in portage, rather
> than handled using tags in CVS. The reason being that only developers
> use CVS so the branches would be irrelevant to the users, they'd just
> get whatever branch the rsync mirrors were "tuned to".

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2416 bytes --]

On Wednesday 25 June 2003 13:22, Matt Thrailkill wrote:
> Or heck, if I'm doing a large-scale complex deployment, there doesn't
> seem to be a way for me to stick with what I know may be good (i.e.
> 1.4-release) and still get bug fixes and security updates through
> Portage short of me maintaining my own tree and having my machines pull
> that down.

If you record the bug fixes and use emerge <packagename> and never emerge -u 
world, things are quite stable, and only required updates are installed.

> When 1.4 is done and 1.5 starts getting all the stuff that is considered
> unstable now, is there going to be a new profile for 1.5 I guess?  Or is
> it going to be a little sloppier, with both 1.4-stable and 1.4-unstable
> slipping forward more and more before a new profile gets made?
>
Version numbers only really matter for the installation CD's, everyone else is 
just running his/her own variant of the gentoo metadistribution. New profiles 
are introduced only for incompatible changes to the base system.

> Seems like being really anal about profiles, i.e. when the dev team
> decides to make a new profile for such and such feature set, could
> accomplish most of this.  Even then though, wouldn't the local Portage
> tree have to contain all the ebuilds in all the profiles?  That could
> start getting fat after a while, since any one machine is only going to
> use a subset of ebuilds.  If strict version control was done with
> profiles, it might be a good idea then to make rsyncs pull down just the
> piece of the tree with the ebuilds for the current profile.

A profile is more like a mask dissallowing certain versions of ebuilds. For 
that the number of "inactive" ebuilds is fairly small. This is esp. true for 
the x86 architecture. Many ebuilds don't have keywords for other 
architectures, but that does not mean they do not work, it just means they 
are untested for the architecture. So you'd still want them probably.
>
> Yes, I know, long long musing to go with such a small quote.  Granular
> version control makes me feel comfortable about what goes onto my
> machines.
>

Do not run emerge -u world. I, personally, never use it except in pretend 
mode. As I'm currently working as a computing scientist, I don't trust 
computers ;-)

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Toby Dickenson]

On Wednesday 25 June 2003 12:31, Paul de Vrieze wrote:

> > Portage short of me maintaining my own tree and having my machines pull
> > that down.
>
> If you record the bug fixes and use emerge <packagename> and never emerge
> -u world, things are quite stable, and only required updates are installed.

That doesnt work if you ever need to install your favourite stable version on 
a new machine, or re-emerge it for any reason. "emerge sync" is likely to 
have removed those old ebuilds.

Ive been running my servers from my own tree since late last year, and it 
works well. My tree is a snapshot of the standard portage tree on that day, 
with any bug-fixes copied from the public portage tree into my 
/usr/local/portage.

I am happy with this arrangement.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[rob holland]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]


--On Wednesday, June 25, 2003 04:22:45 -0700 Matt Thrailkill 
<xwred1@xwredwing.net> wrote:

Firstly, this is not a flame. Please give me the benefit of the doubt in 
that respect :)

> Just a meager user comment.  I run Gentoo "stable" on my desktop and
> laptop, but it seems like things still change a bit too much and too
> largely to where I'd feel comfortable deploying it on a server.

There is no gentoo stable in the same way that Obsd has stable. Obsd stable 
can pretty much be guaranteed to work and play happily. Ebuilds are marked 
stable or unstable based on whether the _ebuild_ is known to be reliable, 
not the package which the ebuild installs.

There is no indication inside of portage as to whether a program is stable 
or not, other than extreme cases where ebuilds are masked because the app 
is very broken. Its not possible for us to say "this is a stable platform" 
for a gentoo "system" can include any number of programs that we may or may 
not have written ebuilds for which can affect the system.

Obsd peeps know exactly what apps are installed in their base system, so 
they can mark the stuff stable when they're fairly sure the base system 
doesn't blow up.

Also, I think you misunderstand "releases". 1.4 is a release of an install 
CD and maybe GRP. Thats it. It makes no difference to the actual system 
once you start running emerge sync you'll be back in the same place as 
someone who installed with a 1.3 install CD and has been running emerge 
sync.

Rob

--

robh@gentoo.org / robh:irc.freenode.net
http://cvs.gentoo.org/~robh/robh@gentoo.org.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Stuart Bouyer]

On Wed, 25 Jun 2003 13:18:11 +0000
rob holland <robh@gentoo.org> wrote:

> 
> --On Wednesday, June 25, 2003 04:22:45 -0700 Matt Thrailkill 
> <xwred1@xwredwing.net> wrote:
> 
> Firstly, this is not a flame. Please give me the benefit of the doubt
> in that respect :)
> 
> > Just a meager user comment.  I run Gentoo "stable" on my desktop and
> > laptop, but it seems like things still change a bit too much and too
> > largely to where I'd feel comfortable deploying it on a server.
> 
<snip,snip>
> Also, I think you misunderstand "releases". 1.4 is a release of an
> install CD and maybe GRP. Thats it. It makes no difference to the
> actual system once you start running emerge sync you'll be back in the
> same place as someone who installed with a 1.3 install CD and has been
> running emerge sync.
I think you misunderstand the complaint here. The problem (which has
been brought up this list previously) is that there is no way to
guarantee that I can get my server back to it's current configuration if
I have to reinstall at a later date. Not only will new versions of
ebuilds have been added to the portage tree, but there is a great chance
that ebuild for the version of the package that I'm happy using will no
longer be in portage tree. What I install using the 1.3 install CD today
will be very different from what I installed 3 months ago.  

If I don't want to update to the new package - and there are many
reasons why I would not want to - then my only optinos are not to emerge
sync (and miss out on the update I do need) or to manually find the
ebuilds I want in the attic of the web cvs gateway.

The lack of a "static" version of gentoo is what is keeping me from
using it on a server.

StuBear
-- 
GnuPG KeyID 1607E7F7
Key fingerprint = 5C38 AA94 A4C1 6AAF 0EE4  C089 EE01 193D 1607 E7F7
gpg --keyserver search.keyserver.net --recv-keys 1607E7F7

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]

 
> Firstly, this is not a flame. Please give me the benefit of the doubt in 
> that respect :)

Neither is this.
 
> There is no gentoo stable in the same way that Obsd has stable. Obsd stable 
> can pretty much be guaranteed to work and play happily. Ebuilds are marked 
> stable or unstable based on whether the _ebuild_ is known to be reliable, 
> not the package which the ebuild installs.

An ebuild is a bash script -- it doesn't take much for an ebuild to be stable.  In this case, rob, your reasoning is completely flawed.  The set of ebuilds marked stable for a specific architecture contains programmes and libraries and utilities, etc etc that are known to work reasonably well (given the large variation in customisation and optimisation settings). 

According to policy, an ebuild is marked stable for a platfrom if and only if recent history (~1 month) shows no new bugs open for it, and all previously opened bugs having been resolved.  That gives us a good indication (assuming, of course, that users use our bug tracker -- and surely gentoo-stats and gentoo-stable websites will start to grow an increasing role in this respect) that the package works reasonably well for the majority of users.


> There is no indication inside of portage as to whether a program is stable 
> or not, other than extreme cases where ebuilds are masked because the app 
> is very broken. Its not possible for us to say "this is a stable platform" 
> for a gentoo "system" can include any number of programs that we may or may 
> not have written ebuilds for which can affect the system.

Rob, you, your mentor and I need to have a chat.  If _we_ did not write it, then _we_ should have checked it, and _carefully_.  And if it did not pass basic tests of functionality, syntax, etc, then _we_ should not have put the damned thing into portage in the first place.


> 
> Obsd peeps know exactly what apps are installed in their base system, so 
> they can mark the stuff stable when they're fairly sure the base system 
> doesn't blow up.

Gentoo peeps know exactly what apps are installed in their base system, so we can mark stuff stable when we're fairly sure the base system doesn't blow up.

> Also, I think you misunderstand "releases". 1.4 is a release of an install 
> CD and maybe GRP. Thats it. It makes no difference to the actual system 
> once you start running emerge sync you'll be back in the same place as 
> someone who installed with a 1.3 install CD and has been running emerge 
> sync.


You got this one right.


-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://www.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Patrick Kursawe]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

On Wed, Jun 25, 2003 at 07:43:36AM -0700, Seemant Kulleen wrote:
> According to policy, an ebuild is marked stable for a platfrom if and
> only if recent history (~1 month) shows no new bugs open for it, and all
> previously opened bugs having been resolved.  That gives us a good
> indication (assuming, of course, that users use our bug tracker -- and
> surely gentoo-stats and gentoo-stable websites will start to grow an
> increasing role in this respect) that the package works reasonably well
> for the majority of users.

Though this all sounds very reasonable - could you point me to the
place in the policy documentation where I can find this (especially the
time estimate)?		

Just wondering,

Patrick	

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Stuart Bouyer]

On Wed, 25 Jun 2003 15:14:46 +0000
rob holland <robh@gentoo.org> wrote:

> 
> 
> --On Wednesday, June 25, 2003 23:08:44 +0900 Stuart Bouyer 
> <stubear@bouyer.no-ip.org> wrote:
> 
> I perfectly understand the complaint you've just made. I don't think
> it was clear from the previous emails, maybe its just me.
> 
> > Not only will new versions of
> > ebuilds have been added to the portage tree, but there is a great
> > chance that ebuild for the version of the package that I'm happy
> > using will no longer be in portage tree. What I install using the
> > 1.3 install CD today will be very different from what I installed 3
> > months ago.
> 
> Please don't confuse which install CD you used with which packages you
> have installed. The two are completely unlrelated unless you have
> never updated anything from the stage3 build of the CD.
> 
> I'd like to reiterate that "releases" are only releases of the install
> CD, not the system.
> 
Yes, I'm well aware of this (I used to be the CJK developer before
real-life rudely interrupted), and this
is my biggest concern with Gentoo at the momoent, there is no way (apart
from the snapshots Christian mentioned) to ensure that 2 instalations on
the same "release" will be the same. In an office environment where I'm
mainitaining 50+ machines this is a major concern for me. I know that
with my Mandrake or RedHat install disks all machines are running the
same versions of applications, but with Gentoo this is not true unless
all machines are installed and updated at the same time. 

Sometimes Gentoo is just a little too bleeding-edge

StuBear
-- 
GnuPG KeyID 1607E7F7
Key fingerprint = 5C38 AA94 A4C1 6AAF 0EE4  C089 EE01 193D 1607 E7F7
gpg --keyserver search.keyserver.net --recv-keys 1607E7F7

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[rob holland]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]



--On Wednesday, June 25, 2003 23:08:44 +0900 Stuart Bouyer 
<stubear@bouyer.no-ip.org> wrote:

I perfectly understand the complaint you've just made. I don't think it was 
clear from the previous emails, maybe its just me.

> Not only will new versions of
> ebuilds have been added to the portage tree, but there is a great chance
> that ebuild for the version of the package that I'm happy using will no
> longer be in portage tree. What I install using the 1.3 install CD today
> will be very different from what I installed 3 months ago.

Please don't confuse which install CD you used with which packages you have 
installed. The two are completely unlrelated unless you have never updated 
anything from the stage3 build of the CD.

I'd like to reiterate that "releases" are only releases of the install CD, 
not the system.

> If I don't want to update to the new package - and there are many
> reasons why I would not want to - then my only optinos are not to emerge
> sync (and miss out on the update I do need) or to manually find the
> ebuilds I want in the attic of the web cvs gateway.

Yes and this is a pain. We have no way to fix this currently which is what 
I meant to imply with my email, I obviously failed miserably, sorry about 
that.

Due to the strain on infrastructure we don't allow users to sync their 
portage tree using CVS. I can't see a way round this until we have the 
capacity to allow anonymous CVS access again. Even then it will mean a big 
change in the way gentoo is developed (use of CVS tags and marking some 
kind of "system release") and possibly changes to portage.

Currently only the live/install CDs are "released" as such.

--

robh@gentoo.org / robh:irc.freenode.net
http://cvs.gentoo.org/~robh/robh@gentoo.org.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1394 bytes --]

On Wednesday 25 June 2003 16:56, Stuart Bouyer wrote:
> On Wed, 25 Jun 2003 15:14:46 +0000
>
> Yes, I'm well aware of this (I used to be the CJK developer before
> real-life rudely interrupted), and this
> is my biggest concern with Gentoo at the momoent, there is no way (apart
> from the snapshots Christian mentioned) to ensure that 2 instalations on
> the same "release" will be the same. In an office environment where I'm
> mainitaining 50+ machines this is a major concern for me. I know that
> with my Mandrake or RedHat install disks all machines are running the
> same versions of applications, but with Gentoo this is not true unless
> all machines are installed and updated at the same time.
>
> Sometimes Gentoo is just a little too bleeding-edge

In such a case you might want to run your own cvs ( or subversion) tree of 
"sanctioned ebuilds", and instead of emerge sync run cvs update on the 
slaves. You then can copy only interesting ebuilds to the cvs tree, and only 
wanted changes. Of course this is more work, but if it should not be too hard 
to create a "custom tree" based on the ebuilds that are currently installed. 
You could put that tree, with the required distfiles on a custom gentoo 
bootcd, which you could use to install all clients. 

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

Its looking like this is the most practical way of going about achieving
the stricter version control I and others are thinking about.  And its
not too much work... but its alot of wasted effort when you have a bunch
of people doing it for themselves individually.

Maybe it would be a good idea to have a team/project/whatever who's
responsibility is to create and maintain snapshots of the Portage tree
at different times, and let them take care of assigning Gentoo version
numbers and to those snapshots?  Meanwhile the rest of the Gentoo team
can just keep moving forward with the ever changing metadistribution and
not have to worry too much about distilling it for releases so much as
doing good work and making cool stuff.

Maybe such a project could be a sub-project of stable.gentoo.org, since
they seem to be collecting alot of information about stability of things
in Portage as it is.

I think what you'd end up with would be most of the people working on
advancing Gentoo now would be working on what is analagous to -CURRENT
in FreeBSD, and then this other group of people would be like the
Release Engineering team (looking at drobbins proposal, he already
mentioned one), deciding when -CURRENT was ripe for splitting off and
stabilizing into a release with such and such goals and featureset.

At the least regimented level, it'd be a centralized place for people
like Stuart and I to go and pick a static Portage tree to track for our
servers.  Let the people at that centralized place merge the security
updates and bugfixes into the static trees as they see fit.  And it
shouldn't prove much hindrance to the rest of people working on
advancing the bleeding edge, besides maybe modifications to Portage so
it has the tree selection abilities built in.

On Wed, 25 Jun 2003 21:01:00 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> In such a case you might want to run your own cvs ( or subversion)
> tree of "sanctioned ebuilds", and instead of emerge sync run cvs
> update on the slaves. You then can copy only interesting ebuilds to
> the cvs tree, and only wanted changes. Of course this is more work,
> but if it should not be too hard to create a "custom tree" based on
> the ebuilds that are currently installed. You could put that tree,
> with the required distfiles on a custom gentoo bootcd, which you could
> use to install all clients. 
> 
> Paul

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[jesse]

[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]

this sounds good.. and the tree specification is builtin :P 

SYNC="rsync://mirrors.gentoo.org/gentoo-stable"

SYNC="rsync://mirrors.gentoo.org/gentoo-current"

I would be willing to offer time on a project like this ( part time
unfortunately )  considering i am also already maintaining my own
version of the portage tree for stability reasons. 


On Wed, 2003-06-25 at 14:38, Matt Thrailkill wrote:
> Its looking like this is the most practical way of going about achieving
> the stricter version control I and others are thinking about.  And its
> not too much work... but its alot of wasted effort when you have a bunch
> of people doing it for themselves individually.
> 
> Maybe it would be a good idea to have a team/project/whatever who's
> responsibility is to create and maintain snapshots of the Portage tree
> at different times, and let them take care of assigning Gentoo version
> numbers and to those snapshots?  Meanwhile the rest of the Gentoo team
> can just keep moving forward with the ever changing metadistribution and
> not have to worry too much about distilling it for releases so much as
> doing good work and making cool stuff.
> 
> Maybe such a project could be a sub-project of stable.gentoo.org, since
> they seem to be collecting alot of information about stability of things
> in Portage as it is.
> 
> I think what you'd end up with would be most of the people working on
> advancing Gentoo now would be working on what is analagous to -CURRENT
> in FreeBSD, and then this other group of people would be like the
> Release Engineering team (looking at drobbins proposal, he already
> mentioned one), deciding when -CURRENT was ripe for splitting off and
> stabilizing into a release with such and such goals and featureset.
> 
> At the least regimented level, it'd be a centralized place for people
> like Stuart and I to go and pick a static Portage tree to track for our
> servers.  Let the people at that centralized place merge the security
> updates and bugfixes into the static trees as they see fit.  And it
> shouldn't prove much hindrance to the rest of people working on
> advancing the bleeding edge, besides maybe modifications to Portage so
> it has the tree selection abilities built in.
> 
> On Wed, 25 Jun 2003 21:01:00 +0200
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> 
> > In such a case you might want to run your own cvs ( or subversion)
> > tree of "sanctioned ebuilds", and instead of emerge sync run cvs
> > update on the slaves. You then can copy only interesting ebuilds to
> > the cvs tree, and only wanted changes. Of course this is more work,
> > but if it should not be too hard to create a "custom tree" based on
> > the ebuilds that are currently installed. You could put that tree,
> > with the required distfiles on a custom gentoo bootcd, which you could
> > use to install all clients. 
> > 
> > Paul
> 
> --
> gentoo-dev@gentoo.org mailing list


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Matt Thrailkill]

Yes, I'd be willing to contribute some time and resources to such a
project also.


On 25 Jun 2003 16:13:31 -0700
jesse <yoda@f00bar.com> wrote:

> this sounds good.. and the tree specification is builtin :P 
> 
> SYNC="rsync://mirrors.gentoo.org/gentoo-stable"
> 
> SYNC="rsync://mirrors.gentoo.org/gentoo-current"
> 
> I would be willing to offer time on a project like this ( part time
> unfortunately )  considering i am also already maintaining my own
> version of the portage tree for stability reasons. 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Toby Dickenson]

On Thursday 26 June 2003 00:20, Matt Thrailkill wrote:
> Yes, I'd be willing to contribute some time and resources to such a
> project also.

Me too.

Do you think it makes sense for this to be a shared stable tree?

My private stable portage tree dates from last November. I have added 
bleeding-edge versions of some packages that I know well, and have held back 
from installing security-critical bug fixes to packages where I am not 
exposed to the specific vulnerabilities. I dont think many other people would 
want to use my stable tree.

What do your trees look like?



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Stewart]

Stuart Bouyer wrote:
> I think you misunderstand the complaint here. The problem (which has
> been brought up this list previously) is that there is no way to
> guarantee that I can get my server back to it's current configuration if
> I have to reinstall at a later date. Not only will new versions of
> ebuilds have been added to the portage tree, but there is a great chance
> that ebuild for the version of the package that I'm happy using will no
> longer be in portage tree. What I install using the 1.3 install CD today
> will be very different from what I installed 3 months ago.

A long-standing problem is certainly the trigger-happy nature of so many 
developers when it comes to removing "old" ebuilds. I've seen it to the 
extreme where a new build was committed and all previous builds removed 
before the new version (which already had Bugzilla reports) had even 
been tested, letalone assured to be working.

I've been pushing, and plan to continue to push as hard as possible for 
a policy change where old, stable, ebuilds are concerned.

In a typical situation, we'll have builds versioned like so;

1.0
1.0-r1
1.0-r2
1.0-r3
1.1
1.1-r1
1.1-r2
1.2
1.3
2.0
2.0-r1
2.0-r2
2.0-r3

etc. ad nauseum. Current practises seem to revolve around removing all 
but the last, say, two or three ebuilds. Unfortunately, that leaves a 
/LOT/ of users in the lurch.

My contention is this; -r* builds are intended to fix problems with 
previous -r* builds (and the initial ebuild for a given version), so 
rather than removing everything <2.0, why not remove all the lowest 
numbered -r builds, thus leaving us with;

1.0-r3
1.1-r2
1.2
1.3
2.0-r3

If an ebuild is, for whatever reason, broken enough to warrant a 
revision bump, does it really conpute to leave it in the tree while 
removing a perfectly viable, if only older build in its stead?

Such a system would allow us to maintain upwards of a years' worth of 
builds in the tree without severe bloating and would permit such a 
"static version", as you've said, and would make server administrators 
rest a little easier.

A lot of talk recently about migrating Gentoo from Apache 1.3 to 2 has 
me a little frighteend. Despite assurances that 1.3 will remain in the 
tree, my observations over this past year and a half don't comfort me, 
and I, for one, am not ready (or able) to migrate all my hosting servers 
to Apache 2 just yet.

> If I don't want to update to the new package - and there are many
> reasons why I would not want to - then my only optinos are not to emerge
> sync (and miss out on the update I do need) or to manually find the
> ebuilds I want in the attic of the web cvs gateway.

Agreed completely. All too often a version change involves many late 
nights and heartburn weeding through new features and depracated 
functionality.

Projects, more often than not, will maintain security and critical 
updates for their old(er) versions for this very reason. ISC and the 
Apache Foundation are encouraging their userbase to migrate to the 
latest and greatest, for many reasons, but are in no way leaving their 
legacy customers in the lurch. Security updates to Apache 1.3 and BIND 8 
will continue indefinately (or until the use of such products is 
completely not viable). For that matter, BIND 4 still sees security 
updates when required.

If we're to move off the desktop and onto servers (or, Tux forbid, the 
Enterprise Platform) we need to allow users to stick with what works and 
track critical/security updates.

In the meantime, our best bet is to emerge -bk and store the resultant 
binaries in a centrally available location. The problems, however, with 
ebuilds dissapearing from the tree remain, so even that is imperfect.

-- 
Stewart Honsberger
http://blackdeath.snerk.org/
"Capitalists, by nature, organize to protect themselves.
-- Geeks, by nature, resist organizaion."


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Georgi Georgiev]

On 26/06/2003 at 12:46:08(-0400), Stewart used 3.8K just to say:
> If an ebuild is, for whatever reason, broken enough to warrant a 
> revision bump, does it really conpute to leave it in the tree while 
> removing a perfectly viable, if only older build in its stead?

I couldn't agree more. A nice example would be bug #12844. I am still reluctant
of doing "emerge '>netscape-flash-6'"

-- 
/\   Georgi Georgiev   /\ "...Unix, MS-DOS, and Windows NT (also known /\
\/    chutz@gg3.net    \/ as the Good, the Bad, and the Ugly)." (By    \/
/\  +81(90)6266-1163   /\ Matt Welsh)                                  /\

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Jonathan Kelly]

On Thu, 26 Jun 2003 12:46:08 -0400
Stewart <bdlists@snerk.org> wrote:

> Stuart Bouyer wrote:
> > I think you misunderstand the complaint here. The problem (which has
> > been brought up this list previously) is that there is no way to
> > guarantee that I can get my server back to it's current configuration
> > if I have to reinstall at a later date. Not only will new versions of
> > ebuilds have been added to the portage tree, but there is a great
> > chance that ebuild for the version of the package that I'm happy using
> > will no longer be in portage tree. What I install using the 1.3
> > install CD today will be very different from what I installed 3 months
> > ago.
> 
> A long-standing problem is certainly the trigger-happy nature of so many
> 
> developers when it comes to removing "old" ebuilds. I've seen it to the 
> extreme where a new build was committed and all previous builds removed 
> before the new version (which already had Bugzilla reports) had even 
> been tested, letalone assured to be working.
> 

<rest of extremely good post snipped>

Just wanted to agree whole heartedly. Just yesterday I got so frustrated
with gentoo being such a moving target it's actually stopping me from
doing useful work, I actually considered going back to a prebuilt and
stable distro (slackware). Now that's pretty yukky, but at least I'd be
able to get on with doing what I'm supposed to be doing!

Cheers.
Jonathan Kelly.

|add usual aphorism referring to small change here|

--
gentoo-dev@gentoo.org mailing list