[gentoo-dev] 2004.2 Feature Requests

[gentoo-dev] 2004.2 Feature Requests

[John Davis]

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

Hi all -
To start preparing for 2004.2 in July, releng is opening up Feature
Requests that the community would like to see included in 2004.2. The
last day that we are accepting requests is Friday, May 7th at which
point releng will hold a meeting and decide which requests are feasible
for both the alloted time and workload. Thank you for your time and your
requests.

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


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

Re: [gentoo-dev] 2004.2 Feature Requests

[Joshua Brindle]

John Davis wrote:
> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.
> 
> Cheers,
> //zhen

gpg signed manifests

glsa integration into portage (emerge --security or whatever)

config tool rename (gcc-config vs. config-gcc or whatever) -- spyderous 
is working on this, i just want to make sure it's done for 2004.2

installer, at least a beta.. what is the status on the installer guys?

I think it would be nice to also offer dvd iso's that have full of all 
the love, stages, grp, etc.. do we have the space for this? is this 
something that users might want?

Thats all I can think of for now :)

Joshua Brindle


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Kurt Lieber]

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

On Fri, Apr 30, 2004 at 01:03:01AM -0500 or thereabouts, Joshua Brindle wrote:
> gpg signed manifests

By FAR this is the most important feature that we need, imo.  Yes, I'm a
broken record on this.  No, I won't shut up.

> glsa integration into portage (emerge --security or whatever)
> 
> config tool rename (gcc-config vs. config-gcc or whatever) -- spyderous 
> is working on this, i just want to make sure it's done for 2004.2
> 
> installer, at least a beta.. what is the status on the installer guys?

I'd like to see these as well, but only after the gpg signed manifests have
been implemented.

--kurt

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Pieter Van den Abeele]

On 30 Apr 2004, at 09:25, Kurt Lieber wrote:

> On Fri, Apr 30, 2004 at 01:03:01AM -0500 or thereabouts, Joshua 
> Brindle wrote:
>> gpg signed manifests
>
> By FAR this is the most important feature that we need, imo.  Yes, I'm 
> a
> broken record on this.  No, I won't shut up.
>
>> glsa integration into portage (emerge --security or whatever)
>>
>> config tool rename (gcc-config vs. config-gcc or whatever) -- 
>> spyderous
>> is working on this, i just want to make sure it's done for 2004.2
>>
>> installer, at least a beta.. what is the status on the installer guys?
>
> I'd like to see these as well, but only after the gpg signed manifests 
> have
> been implemented.

I haven't seen anything tangible about a beta installer.

History learns that it will most likely be totally PPC incompatible and 
require hours of patching on my part. Hours I'd like to spend on some, 
more thrilling parts such as portage-ng.

Pieter

>
> --kurt


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Donnie Berkholz]

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

On Fri, 2004-04-30 at 12:37, Pieter Van den Abeele wrote:
> I haven't seen anything tangible about a beta installer.
> 
> History learns that it will most likely be totally PPC incompatible and 
> require hours of patching on my part. Hours I'd like to spend on some, 
> more thrilling parts such as portage-ng.

Perhaps you or another member of the PPC team could jump in early, while
it's easiest to deal with any issues, instead of a preemptive complaint.
Communication is the key here. People without PPC expertise can't
magically make things work on PPC without knowing all the issues at
hand.

gentoo-installer is the mailing list, #gentoo-installer is the IRC
channel, esammer is the guy to talk to (I know he's posted to this
thread, but the thread is very long and it can't hurt much to have the
information twice).
-- 
Donnie Berkholz
Gentoo Linux

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Pieter Van den Abeele]

On 02 May 2004, at 19:01, Donnie Berkholz wrote:

> On Fri, 2004-04-30 at 12:37, Pieter Van den Abeele wrote:
>> I haven't seen anything tangible about a beta installer.
>>
>> History learns that it will most likely be totally PPC incompatible 
>> and
>> require hours of patching on my part. Hours I'd like to spend on some,
>> more thrilling parts such as portage-ng.
>
> Perhaps you or another member of the PPC team could jump in early, 
> while
> it's easiest to deal with any issues, instead of a preemptive 
> complaint.
> Communication is the key here. People without PPC expertise can't
> magically make things work on PPC without knowing all the issues at
> hand.

I noted that projects whose requirements indicate they will be (amongst 
other architectures) ppc compatible, but are implemented and designed 
by people without much ppc expertise and whose lead hasn't proactively 
involved people with ppc expertise, at least for testing (assuming 
something testable is available), will require a lot of work on my part 
when they suddenly become obliged (as in: a feature for all the 
architectures releasing), in this case less than 2 weeks before I need 
to start building the 2004.2 release. (check releng release roadmap).

A few remarks:

- The uml/design looks good, but I can't seem to find any code. I would 
like to point out that release features need to be completed (and 
tested) before the release is build, which is rather soon, 
unfortunately.
- The ppc livecd differs from the x86 livecd. Can you check your 
dependencies against our release doc and let me know in advance what 
needs to be added. That way the ppc livecd is ready by the time you 
want to include something for testing.
- I think the GLIarchitectureTemplate and GLIInstallProfile subclasses 
need to be implemented by the architectures. Can you let me know the 
specifics.
- X needs to be set up semi-automatically on the ppc X-enabled livecds, 
Xeasyconf-ng will probably/hopefully change that.
- Genkernel is a bottleneck, in theory a new genkernel release is 
needed for each kernel revision, otherwise the kernel won't be 
installable. (My suggestion is to include a livecd .config in the 
kernel ebuild, or drop the user to menuconfig/Xconfig otherwise)
- Is there an eta for a beta ebuild?

Best regards,

Pieter Van den Abeele


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Nathaniel McCallum]

On Sun, 2004-05-02 at 21:34 +0200, Pieter Van den Abeele wrote:
> I noted that projects whose requirements indicate they will be
(amongst 
> other architectures) ppc compatible, but are implemented and designed 
> by people without much ppc expertise and whose lead hasn't
proactively 
> involved people with ppc expertise, at least for testing (assuming 
> something testable is available), will require a lot of work on my
part 
> when they suddenly become obliged (as in: a feature for all the 
> architectures releasing), in this case less than 2 weeks before I
need 
> to start building the 2004.2 release. (check releng release roadmap).
> 
> A few remarks:
> 
> - The uml/design looks good, but I can't seem to find any code. I
would 
> like to point out that release features need to be completed (and 
> tested) before the release is build, which is rather soon, 
> unfortunately.
Code is in cvs under the gentoo/src/installer/ directory.  It will be
tough to get the installer included in the 2004.2 release as we are
trying very hard to structure it so that it will be easily portable to
other architectures.

> - The ppc livecd differs from the x86 livecd. Can you check your 
> dependencies against our release doc and let me know in advance what 
> needs to be added. That way the ppc livecd is ready by the time you 
> want to include something for testing.

All we really need is python and then whatever partitioning utility will
be used (preferably pyparted, currently marked only ~x86, but probably
works on other arches).

> - I think the GLIarchitectureTemplate and GLIInstallProfile
subclasses 
> need to be implemented by the architectures. Can you let me know the 
> specifics.

We have debated this.  Esammer has me working on delegation instead.
However, I'm beginning to think that it will take much more time to use
delegation instead of inheritance.  I'd like to eventually move to that
model (delegation) as it is generally a better design.

> - X needs to be set up semi-automatically on the ppc X-enabled
livecds, 
> Xeasyconf-ng will probably/hopefully change that.

There is no X/GTK/KDE based GUI yet, so we don't need that yet.

> - Genkernel is a bottleneck, in theory a new genkernel release is 
> needed for each kernel revision, otherwise the kernel won't be 
> installable. (My suggestion is to include a livecd .config in the 
> kernel ebuild, or drop the user to menuconfig/Xconfig otherwise)

Agreed.  Warpzero and I are writing a GLEP for genkernel.

> - Is there an eta for a beta ebuild?

Not yet... However, I want to try and get one out soon.  I'll talk to
esammer about this.  However, I don't suspect that alpha builds will
have non-x86 support.  That will probably be a beta feature.

Nathaniel


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Paul de Vrieze]

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

On Sunday 02 May 2004 21:34, Pieter Van den Abeele wrote:

> I noted that projects whose requirements indicate they will be (amongst
> other architectures) ppc compatible, but are implemented and designed
> by people without much ppc expertise and whose lead hasn't proactively
> involved people with ppc expertise, at least for testing (assuming
> something testable is available), will require a lot of work on my part
> when they suddenly become obliged (as in: a feature for all the
> architectures releasing), in this case less than 2 weeks before I need
> to start building the 2004.2 release. (check releng release roadmap).

Maybe in general it might be an idea (also for other archs) to make a list of 
the most common pitfalls (and their fixes) when using that arch. To mind come 
things like big or little endian, and 64 vs. 32 bits. We might even go so far 
as to write a description on how to correct broken upstream source.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Eric Sammer]

Joshua Brindle wrote:
> installer, at least a beta.. what is the status on the installer guys?

Significant (imo, at least) progress has been made. I've been trying to 
send steady progress updates to the gentoo-installer list as of late, so 
most of your answers are probably there.

For those interested, see the archives at:
http://news.gmane.org/gmane.linux.gentoo.installer/cutoff=67
and the project page at:
http://www.gentoo.org/proj/en/releng/installer/index.xml

Of course, all are welcome to join us in #gentoo-installer.

Regards.
-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Jason Huebel]

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

Joshua Brindle wrote:
| glsa integration into portage (emerge --security or whatever)

I'll throw a vote at this one...

| config tool rename (gcc-config vs. config-gcc or whatever) -- spyderous
| is working on this, i just want to make sure it's done for 2004.2

This one too...

| I think it would be nice to also offer dvd iso's that have full of all
| the love, stages, grp, etc.. do we have the space for this? is this
| something that users might want?

I'd like a DVD ISO, but I don't see that being used as widely as the CD
ISOs.  Plus, that puts a larger burden on the mirrors for bandwidth...

Jason Huebel
Gentoo/amd64 Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAlyjtbNgbbJup4jARAv6BAJ0TvgKYvczvC5N/bW81WrRVQh0JCgCfWpUI
ssb9G5u/ycAmrvPfg2C5Hoo=
=S7fb
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Bjoern Michaelsen]

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

On Tue, May 04, 2004 at 12:23:59AM -0500, Jason Huebel wrote:
> I'd like a DVD ISO, but I don't see that being used as widely as the CD
> ISOs.  Plus, that puts a larger burden on the mirrors for bandwidth...
How about a bittorrent-only DVD iso?

This leads directly to another feature request for 2004.2:
Torrents for the isos!

Greetz, Björn
-- 
Björn Michaelsen
pub  1024D/C9E5A256 2003-01-21 Björn Michaelsen <bmichaelsen@gmx.de>
   Key fingerprint = D649 8C78 1CB1 23CF 5CCF  CA1A C1B5 BBEC C9E5 A256

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Troy Dack]

On 04/05/2004, at 3:23 PM, Jason Huebel wrote:
>
> | I think it would be nice to also offer dvd iso's that have full of 
> all
> | the love, stages, grp, etc.. do we have the space for this? is this
> | something that users might want?
>
> I'd like a DVD ISO, but I don't see that being used as widely as the CD
> ISOs.  Plus, that puts a larger burden on the mirrors for bandwidth...
>

If not a dvd iso, maybe an ebuild that deps on catalyst and can be used 
to generate an iso image.

-- 
	Troy Dack
	<tad@gentoo.org>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Allen D Parker]

that would be very nice...

but you'd have to offer cd/dvd creation options, etc to have it really fly
with users :-D

On Tue, 4 May 2004, Troy Dack wrote:

> On 04/05/2004, at 3:23 PM, Jason Huebel wrote:
> >
> > | I think it would be nice to also offer dvd iso's that have full of
> > all
> > | the love, stages, grp, etc.. do we have the space for this? is this
> > | something that users might want?
> >
> > I'd like a DVD ISO, but I don't see that being used as widely as the CD
> > ISOs.  Plus, that puts a larger burden on the mirrors for bandwidth...
> >
>
> If not a dvd iso, maybe an ebuild that deps on catalyst and can be used
> to generate an iso image.
>
> --
> 	Troy Dack
> 	<tad@gentoo.org>
>
>
> --
> gentoo-dev@gentoo.org mailing list
>
>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Jason Huebel]

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

Troy Dack wrote:
| If not a dvd iso, maybe an ebuild that deps on catalyst and can be used
| to generate an iso image.

You're assuming that the user is already using Gentoo-- which they most
likely won't be.  I would say a prebuilt DVD ISO is the only way to go.
As far as how it gets distributed, a torrent would work out fine.

What is the status of torrent hosting on one of the Gentoo servers?

Jason Huebel
Gentoo/amd64 Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAl6lUbNgbbJup4jARAs+OAJ9VAwb7ynIROA+ZrQZiH7pXw0JLgACgphrU
LOPUeCj/Z8XoxJCjbx1Rwyo=
=fIyD
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[david]

On Tue, May 04, 2004 at 09:31:49AM -0500, Jason Huebel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Troy Dack wrote:
> | If not a dvd iso, maybe an ebuild that deps on catalyst and can be used
> | to generate an iso image.
> 
> You're assuming that the user is already using Gentoo-- which they most
> likely won't be.  I would say a prebuilt DVD ISO is the only way to go.
> As far as how it gets distributed, a torrent would work out fine.
> 
> What is the status of torrent hosting on one of the Gentoo servers?
> 

I don't know about the gentoo servers but alot of system/network
admins I know complain about bittorrent because it requires a very
large amount of ports to be open.
This is especially frustrating if the admin of the machine is not the
network admin and has to justify opening 10-100 ports to the world.
Expect some resistence.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Georgi Georgiev]

maillog: 04/05/2004-10:00:27(-0700): david@futuretel.com types
> I don't know about the gentoo servers but alot of system/network
> admins I know complain about bittorrent because it requires a very
> large amount of ports to be open.
> This is especially frustrating if the admin of the machine is not the
> network admin and has to justify opening 10-100 ports to the world.
> Expect some resistence.

Hm, Azureus only requires one port to be open regardless of the number of
torrents. True, it is a GUI-only program, but is there nothing similar?

-- 
\    Georgi Georgiev   \  "I'd crawl over an acre of 'Visual This++'   \
/     chutz@gg3.net    /  and 'Integrated Development That' to get to  /
\   +81(90)6266-1163   \  gcc, Emacs, and gdb. Thank you." (By Vance   \
/  ------------------- /  Petree, Virginia Power)                      /

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Josh Grebe]

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

bittorrent has 2 terminal-based frontends (btdownloadheadless.py,
btdownloadcurses.py)
Ack on the ports.


Georgi Georgiev wrote:

| maillog: 04/05/2004-10:00:27(-0700): david@futuretel.com types
|
|> I don't know about the gentoo servers but alot of system/network
|> admins I know complain about bittorrent because it requires a
|> very large amount of ports to be open. This is especially
|> frustrating if the admin of the machine is not the network admin
|> and has to justify opening 10-100 ports to the world. Expect some
|> resistence.
|
|
| Hm, Azureus only requires one port to be open regardless of the
| number of torrents. True, it is a GUI-only program, but is there
| nothing similar?
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAmBkfT/OY5rt9JCMRApKnAKCSxKianagQxavN9evdRpuc1X5r7wCg03Ek
8DEEVTfszEeveezSk2wB/CI=
=0oal
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Georgi Georgiev]

maillog: 04/05/2004-17:28:48(-0500): Josh Grebe types
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> bittorrent has 2 terminal-based frontends (btdownloadheadless.py,
> btdownloadcurses.py)
> Ack on the ports.

I was referring to a client that like Azureus only needs one open port for all
the torrents you want to download. btdownload*.py only support one torrent,
don't they?

-- 
(*   Georgi Georgiev   (* The end of the world will occur at three     (*
*)    chutz@gg3.net    *) p.m., this Friday, with symposium to follow. *)
(*  +81(90)6266-1163   (*                                              (*

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[John Davis]

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

On Tue, 2004-05-04 at 10:31, Jason Huebel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Troy Dack wrote:
> | If not a dvd iso, maybe an ebuild that deps on catalyst and can be used
> | to generate an iso image.
> 
> You're assuming that the user is already using Gentoo-- which they most
> likely won't be.  I would say a prebuilt DVD ISO is the only way to go.
> As far as how it gets distributed, a torrent would work out fine.
> 
> What is the status of torrent hosting on one of the Gentoo servers?
> 

From what I have heard with infra, it is ready to go, so expect some
torrents in 2004.2.

Cheers,
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


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

Re: [gentoo-dev] 2004.2 Feature Requests

[Kumba]

John Davis wrote:
> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.
> 
> Cheers,
> //zhen


Just out of curiosity, how many releases are we looking at pulling off 
for this year?  My guess is that at the current rate (1 release every 
~2.3 months), it's looking like the possibility of a 2004.5 being 
capable by early december.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Joshua Brindle]

Kumba wrote:

> John Davis wrote:
> 
>> Hi all -
>> To start preparing for 2004.2 in July, releng is opening up Feature
>> Requests that the community would like to see included in 2004.2. The
>> last day that we are accepting requests is Friday, May 7th at which
>> point releng will hold a meeting and decide which requests are feasible
>> for both the alloted time and workload. Thank you for your time and your
>> requests.
>>
>> Cheers,
>> //zhen
> 
> 
> 
> Just out of curiosity, how many releases are we looking at pulling off 
> for this year?  My guess is that at the current rate (1 release every 
> ~2.3 months), it's looking like the possibility of a 2004.5 being 
> capable by early december.
> 
> 
> --Kumba
> 
the number after the year designates the quarter, starting at .0 for the 
first quarter, .1 for the second and so on. by definition that gives 4 
releases per year

Joshua Brindle

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Kumba]

Joshua Brindle wrote:

> the number after the year designates the quarter, starting at .0 for the 
> first quarter, .1 for the second and so on. by definition that gives 4 
> releases per year

It's starting to look like we'll pull 5 off this year to me.  I.e.:

  Feb 2004 - 2004.0
  Apr 2004 - 2004.1
  Jul 2004 - 2004.2
~Oct 2004 - 2004.3
~Dec 2004 - 2004.4
~Feb 2005 - 2005.0


I dunno, maybe instead of a July target for 2004.2, we can aim for late 
August.  Gives several months to get some new features integrated and 
tested.  While I forsee emerge --security getting integrated beforehand, 
testing wil another thing, because the best test of a fewture like that 
is after several live GLSA's go out.

I'd also like the whole summer to play around with some new mips stuff, 
i.e., liveCDs (SGI's are a PITA to make a bootable CD for, no iso9660). 
  I didn't have alot of time during 2004.0 and 2004.1 because I was 
usually messing with class stuff (although I more or less shoved that 
off to the side during April for no reason).

Assume a late Aug date

  Feb 2004 - 2004.0
  Apr 2004 - 2004.1
  Aug 2004 - 2004.2
  Nov 2004 - 2004.3
~Jan 2005 - 2005.0


$0.02, ¥2.21

--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Sven Vermeulen]

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

On Fri, Apr 30, 2004 at 03:43:35AM -0400, Kumba wrote:
> Assume a late Aug date
> 
>  Feb 2004 - 2004.0
>  Apr 2004 - 2004.1
>  Aug 2004 - 2004.2
>  Nov 2004 - 2004.3
> ~Jan 2005 - 2005.0

The initial idea was to:

2004.0: Jan
2004.1: Apr
2004.2: Jul
2004.3: Oct
2005.0: Jan
...

There's just that little deviation for 2004.1 because of child diseases :)

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Sven Vermeulen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 972 bytes --]

On Fri, Apr 30, 2004 at 02:16:06AM -0400, Kumba wrote:
> Just out of curiosity, how many releases are we looking at pulling off 
> for this year?  My guess is that at the current rate (1 release every 
> ~2.3 months), it's looking like the possibility of a 2004.5 being 
> capable by early december.

Afaik the main intention was to keep it at 4 releases per year, although it
does look like we're going to have 5 or 6 if we keep the current pace.

Of course, if releasing is easy and not too stressful (i.e. just running
catalyst once in a while on boxes that would otherwise be idling) this is no
biggie :)

I'm sure the (non-x86 mostly) release coördinators will be able to give a
better perspective on this. How's the pressure on you guys for releases?

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Kumba]

Sven Vermeulen wrote:

> I'm sure the (non-x86 mostly) release coördinators will be able to give a
> better perspective on this. How's the pressure on you guys for releases?

Releasing has been interesting.  It was a lot smoother on mips for 
2004.1 than 2004.0 (even though all of mips 2004.1 is sitting in my dev 
space right now until I give it some final touch ups and dump it to the 
mirrors).  I ran into some random glitches and obscure bugs in both 
catalyst and chrooted userland during 2004.0 that were fixed for 2004.1 
(i.e., make-3.80 will segfault on glibc-2.3.2 on an R5K Indy in chroot 
only).

Hopefully 2004.2 will be even smoother.  I was able to get the stages 
done relatively quickly, but GRP took a little more cause it was the 
first grp set I've generated, and it still needs work.  In the case of 
the cobalt-mips support, GRP gave me an xfree build for a system which 
is completely headless.  So I'm hoping by 2004.2, I'll be able to have a 
smoother run through GRP and all.


--Kumba


-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Pieter Van den Abeele]

On 30 Apr 2004, at 09:25, Sven Vermeulen wrote:

> I'm sure the (non-x86 mostly) release coördinators will be able to 
> give a
> better perspective on this. How's the pressure on you guys for 
> releases?

It gets better and better. Both ppc64 and ppc32 are definitely in need 
of a somebody whois willing to learn the black art of building a 
ppc32/ppc64 release to watch the building process when I'm asleep. I'm 
trying to automate catalyst (automated specfile generation) that helps 
alot.

Everything in the current stable profile builds just fine, a new 
release is just a matter of typing ./newrelease.sh.  Livecd kernels can 
be a pita, I'm hoping to keep the 2004.1 ones for 2004.2.

Pieter

> Wkr,
>       Sven Vermeulen
>
> -- 
>  ^__^   And Larry saw that it was Good.
>  (oo)                                      Sven Vermeulen
>  (__)   http://www.gentoo.org              Documentation & PR


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Pieter Van den Abeele]

On 30 Apr 2004, at 08:16, Kumba wrote:

> John Davis wrote:
>> Hi all -
>> To start preparing for 2004.2 in July, releng is opening up Feature
>> Requests that the community would like to see included in 2004.2. The
>> last day that we are accepting requests is Friday, May 7th at which
>> point releng will hold a meeting and decide which requests are 
>> feasible
>> for both the alloted time and workload. Thank you for your time and 
>> your
>> requests.
>> Cheers,
>> //zhen
>
>
> Just out of curiosity, how many releases are we looking at pulling off 
> for this year?  My guess is that at the current rate (1 release every 
> ~2.3 months), it's looking like the possibility of a 2004.5 being 
> capable by early december.

All fine for me, but note that 5 releases a year means a full-time job. 
Building releases is not exactly thrilling.

Pieter

>
> --Kumba
>
> -- 
> "Such is oft the course of deeds that move the wheels of the world: 
> small hands do them because they must, while the eyes of the great are 
> elsewhere."  --Elrond
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Stuart Herbert]

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

On Friday 30 April 2004 04:42, John Davis wrote:
> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.
>
> Cheers,
> //zhen

Are you going to put these requests online somewhere?

Thanks,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Missed the php|cruise?             http://dev.gentoo.org/~stuart/cruise-2004/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

[gentoo-dev] Re: 2004.2 Feature Requests

[Johannes Segitz]

John Davis <zhen@gentoo.org> wrote:
> Requests that the community would like to see included in 2004.2.

A way to have your own patches applied to the source of a package before
it is build. Preferably with a way to deal with rejects and update the
patch for this version accordingly

Regards,
Johannes


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Marius Mauch]

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

On 04/29/04  John Davis wrote:

> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2.

- netcat on LiveCDs for cloning

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Lars Strojny]

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

On Fri, 30 Apr 2004 19:37:17 +0200
Marius Mauch <genone@gentoo.org> wrote:

> On 04/29/04  John Davis wrote:
> 
> > Hi all -
> > To start preparing for 2004.2 in July, releng is opening up Feature
> > Requests that the community would like to see included in 2004.2.

- A Kernel 2.6 boot-CD. I think, the current in experimental should be 
  fixed, there are many problems for example with some PCMCIA-Cards
  because it is Kernel 2.6.0 :(

Greetings
Lars Strojny
-- 
"Um Rekursion zu verstehen, muss man erst Rekursion verstehen"
 
name: Lars Strojny         web: http://strojny.net 
street: Yorckstrasse 22    jabber: sinistra@amessage.de
city: D-71636 Ludwigsburg  mail: lars@strojny.net
f-print: 6663 1055 543E 3106 3FD3  4F40 AC74 CD1F C327 14BD
weblog: http://sinistra.is-a-geek.net/l_blog

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Sven Vermeulen]

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

On Fri, Apr 30, 2004 at 08:15:55PM +0200, Lars Strojny wrote:
> - A Kernel 2.6 boot-CD. I think, the current in experimental should be 
>   fixed, there are many problems for example with some PCMCIA-Cards
>   because it is Kernel 2.6.0 :(

Most 2004.1 LiveCDs have a 2.6 kernel on board, except when the architecture
itself isn't well supported by the 2.6 kernel.

For instance, for the x86 LiveCD, the smp kernel is a 2.6 kernel. And you
don't need a dual(+) CPU system to use that kernel.

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

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

Re: [gentoo-dev] 2004.2 Feature Requests

[N. Owen Gunden]

On 04/29/04  John Davis wrote:
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2.

Ooh, how about getting ufed on the live CD?  It's always annoying to have
to do USE flags by hand that first time.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Jon Portnoy]

On Fri, Apr 30, 2004 at 06:51:14PM -0400, N. Owen Gunden wrote:
> On 04/29/04  John Davis wrote:
> > To start preparing for 2004.2 in July, releng is opening up Feature
> > Requests that the community would like to see included in 2004.2.
> 
> Ooh, how about getting ufed on the live CD?  It's always annoying to have
> to do USE flags by hand that first time.
> 

I think you mean in the stage 8)

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[N. Owen Gunden]

On Fri, Apr 30, 2004 at 07:07:34PM -0400, Jon Portnoy wrote:
> On Fri, Apr 30, 2004 at 06:51:14PM -0400, N. Owen Gunden wrote:
> > Ooh, how about getting ufed on the live CD?  It's always annoying to have
> > to do USE flags by hand that first time.
> > 
> 
> I think you mean in the stage 8)

Oh yeah, doh.  But stage 1 -- the earlier the better!

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Jon Portnoy]

On Fri, Apr 30, 2004 at 07:21:21PM -0400, N. Owen Gunden wrote:
> On Fri, Apr 30, 2004 at 07:07:34PM -0400, Jon Portnoy wrote:
> > On Fri, Apr 30, 2004 at 06:51:14PM -0400, N. Owen Gunden wrote:
> > > Ooh, how about getting ufed on the live CD?  It's always annoying to have
> > > to do USE flags by hand that first time.
> > > 
> > 
> > I think you mean in the stage 8)
> 
> Oh yeah, doh.  But stage 1 -- the earlier the better!
> 

I suspect ufed would bring in a lot of unwanted dependencies, such as 
ncurses.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Stuart Herbert]

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

On Saturday 01 May 2004 00:29, Jon Portnoy wrote:
> I suspect ufed would bring in a lot of unwanted dependencies, such as
> ncurses.

Try building ufed against slang instead then.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Missed the php|cruise?             http://dev.gentoo.org/~stuart/cruise-2004/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Dan Podeanu]

Hey,

Just a quick addon, I'd like to have it set up automatically that in
rc.local or equivallent (ie. at the end of booting) the output of dmesg is
save (overwritten or appended -- I'd rather have it overwritten) over some
newly introduced /var/log/dmesg

It can be a life saver.

Thanks,
Dan.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Chris Gianelloni]

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

How about udev compatible scripts in catalyst so one can make a
udev-enabled CD instead?  I know I sure would like that, especially with
devfs being deprecated.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Greg KH]

On Sat, May 01, 2004 at 03:10:32PM -0400, Chris Gianelloni wrote:
> How about udev compatible scripts in catalyst so one can make a
> udev-enabled CD instead?  I know I sure would like that, especially with
> devfs being deprecated.

Heh, I've already asked for this, and offered up any help that may be
needed to implement this.

greg k-h

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: 2004.2 Feature Requests

[Jerry McBride]

N. Owen Gunden wrote:

> On 04/29/04  John Davis wrote:
>> To start preparing for 2004.2 in July, releng is opening up Feature
>> Requests that the community would like to see included in 2004.2.
> 
> Ooh, how about getting ufed on the live CD?  It's always annoying to have
> to do USE flags by hand that first time.
> 

If nothing else is done, I'll vote for this one too.

-- 

******************************************************************************
                     Registered Linux User Number 185956
          http://groups.google.com/groups?hl=en&safe=off&group=linux
             Join me in chat at #linux-users on irc.freenode.net
    Buy an Xbox for $149.00, run linux on it and Microsoft loses $150.00!
     1:11pm  up 11 days, 16:32,  5 users,  load average: 2.85, 2.94, 2.90


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Lisa Seelye]

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

On Thu, 2004-04-29 at 23:42, John Davis wrote:
> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.

Things I've been hearing:

Distcc worked into the stage 1 tarballs so that distcc can be used
without messing around with the emerge -O distcc (and the rest of setup
as per the Guide).

Distcc on the LiveCD ("much in the same way as OpenSSH is available") on
to facilitate easy borging of machines.

Releng, definitely bug me for assistance here if needed.

-- 
Regards,
-Lisa
<Quidquid latine dictum sit, altum viditur>

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

Re: [gentoo-dev] 2004.2 Feature Requests

[John Davis]

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

On Thu, 2004-04-29 at 23:42, John Davis wrote:
> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.
> 
> Cheers,
> //zhen

Ok, sorry for the lag in response, I had 2 exams today plus I am
fighting a cold. I will try to answer all of the questions :) If I
forget any, please send jforman my way with a baseball bat, he loves
that type of thing.

First, if your request is a package inclusion request (such as distcc,
netcat) please bug it on bugs.gentoo.org and assign it to
release@gentoo.org. These requests are rather trivial to implement, so a
full blown feature request is not needed. Necessary dicussion can be
carried out on bugs.gentoo.org.

Next, the release schedule. There are a couple of ways to go about this.
I think Daniel built an end of the year/ holiday break into the release
schedule when he first came up with the quarterly schedule. The break
from (late) October -> January/ February is meant to accomodate this.
Personally, I think it is a good idea as it gives us all time to
re-group, spend time with family, and perhaps hack in our spare time on
the harder features, etc. Of course, if people want to change this, we
can change the release cycle so that the big break is over the summer
and the regular 2 month cycle at the end of the year. Alternatively, we
could redo the schedule so that those extra months at the end of the
year are reabsorbed into the schedule to space out all of the releases
equally. I am very open to ideas, so please provide your input.

Portage enhancements are a tough one. I know that genone has emerge
security almost there and GPG manifest signing is somewhere in the
middle (need verification here). The problem in making these release
guidelines is the fact that they are totally dependent on 2 people's
time and work. Releng does not have control over whether or not these
can be completed, so putting them on the feature list usually ends up
being an exercise in futility. If some people are willing to help out
carpaski and genone, then I will add it to the list, but if they are
left implementing and testing these two rather substantial features
themselves, I am not adding them to the list.

Ok, that should cover it, thanks for the input and please keep at it :)

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


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

Re: [gentoo-dev] Key policy for GPG verification [was: 2004.2 Feature Requests]

[Marius Mauch]

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

On 04/30/04  John Davis wrote:

> Portage enhancements are a tough one. I know that genone has emerge
> security almost there and GPG manifest signing is somewhere in the
> middle (need verification here). The problem in making these release
> guidelines is the fact that they are totally dependent on 2 people's
> time and work. Releng does not have control over whether or not these
> can be completed, so putting them on the feature list usually ends up
> being an exercise in futility. If some people are willing to help out
> carpaski and genone, then I will add it to the list, but if they are
> left implementing and testing these two rather substantial features
> themselves, I am not adding them to the list.

Ok, guess I should repeat that the most important thing for GPG signing
(actually the missing part is verification) that's still missing is a
key policy: where to store keys, how to check if they are trustworthy
and so on. If we can agree on a simple and effective solution there it
shouldn't be too difficult to implement this feature (talking about code
here, not the tree). The last time we had a way too long thread with way
too many details and discussions about problem scenarios, please let's
try to avoid that. 
And to get everyone on track I'll start with a very simple proposal
(idea stolen from Spanky IIRC), I won't say that it's really effective
though:
- keys are stored in a keyring and are installed by an ebuild
- a key is trustworthy if it is in that keyring
- expiration is handled by removing the key from that keyring
- each modification to the keyring involves a version bump on the ebuild
That's about the easiest for implementation and doesn't require anything
new for our infrastructure or key-signing-sessions. It does not say who
will manage that keyring though as that is not important for the
implementation. I'm pretty sure that the idea has a number of flaws, but
we have to start somewhere.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] Key policy for GPG verification [was: 2004.2 Feature Requests]

[Chris Bainbridge]

On Friday 30 April 2004 21:23, Marius Mauch wrote:
> Ok, guess I should repeat that the most important thing for GPG signing
> (actually the missing part is verification) that's still missing is a
> key policy: where to store keys, how to check if they are trustworthy
> and so on. If we can agree on a simple and effective solution there it
> shouldn't be too difficult to implement this feature (talking about code
> here, not the tree). The last time we had a way too long thread with way
> too many details and discussions about problem scenarios, please let's
> try to avoid that.
> And to get everyone on track I'll start with a very simple proposal
> (idea stolen from Spanky IIRC), I won't say that it's really effective
> though:
> - keys are stored in a keyring and are installed by an ebuild
> - a key is trustworthy if it is in that keyring
> - expiration is handled by removing the key from that keyring
> - each modification to the keyring involves a version bump on the ebuild
> That's about the easiest for implementation and doesn't require anything
> new for our infrastructure or key-signing-sessions. It does not say who
> will manage that keyring though as that is not important for the
> implementation. I'm pretty sure that the idea has a number of flaws, but
> we have to start somewhere.
>
> Marius

Uh oh.. this again ;-) 

The above proposal doesn't allow recovery from a compromise, since someone 
could update the new keys ebuild to a new one containing only their key. The 
master key / monthly signing multi-server keys proposal was better. See the 
archives for details.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Spider]

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

begin  quote
On Thu, 29 Apr 2004 23:42:38 -0400
John Davis <zhen@gentoo.org> wrote:

> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are
> feasible for both the alloted time and workload. 

> Thank you for your time and your requests.

Working detection and documentation for SATA devices. I've spent far too
many hours on irc trying to make this work today and yesterday. I'm
utterly grumpy at this.  **mutters hideousness**

Please also make sure theese are supported by both 2.4 and 2.6 kernels.
( "why do I have to use smp? I don't have smp?" ) 


//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Heinrich Wendel]

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

Am Friday 30 April 2004 05:42 schrieb John Davis:
> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.

This has nothing to do with releng, but it would be nice if we could get UTF-8
support workin:

http://bugs.gentoo.org/show_bug.cgi?id=18375


>
> Cheers,
> //zhen
mfg, Heinrich :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAk48AevY57Fted3ERArhEAKDUtxEZ7n2iFDYSNzxUO+9lE4VQ8ACfQaXR
OKLPD5LNH52r7fsSW0kgy5Q=
=PKjh
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: 2004.2 Feature Requests

[Jerry McBride]

John Davis wrote:

> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.
> 
> Cheers,
> //zhen

Move all documentation to html and place it into a directory that apache can
disseminate from. Having a central, online, browseable doc tree would be
beautiful. Priceless...

Move away from the filesystem database that portage currently uses to
something with a bit more perfomance... mysql, sqlite even postgres... An
SQL backend interface would be WONDERFUL.

Port portage to c or c++. Python sucks in the performance department... If
not port to c then atleast start using psyco for a small perf boost...
Rebuilding the cache (reading files) after a sync is... terrible... What a
kludge...

Work on eliminating the constant caching of dependencies and other caching
processes during boot up... On some of my boxes, these caching periods take
longer than it does for KDE to boot to a usable desktop... What a drag on a
laptop that I use to display linux with.... It's the first thing that
windows advocates point and laugh at... Give me a break and cache the damn
things when changes are MADE, not everytime you boot the box...

We need a better portage tool that easily displays ebuild dependencies...
Can epm finally be completed so it offers the same functions for portrage
that rpm has for it's own packages? 

Tone down the amount of noise that emerge prints to the screen when using
it. I don't need or want to see maybe 99.99% of all the stuff it prints
during it operations. All you need is... either "THERE WAS AN ERROR" or
"THERE WERE NO ERRORS". That in and of itself would boost performance a
lot!... Less console updates, more cpu for the task at hand... Less user
confusion...

PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS
BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS
BARS...PROGRESS BARS...

Got the point??? :')

And above all else... make it all available as user options... that way
nobody will cry-baby with the changes.... 


-- 

******************************************************************************
                     Registered Linux User Number 185956
          http://groups.google.com/groups?hl=en&safe=off&group=linux
             Join me in chat at #linux-users on irc.freenode.net
    Buy an Xbox for $149.00, run linux on it and Microsoft loses $150.00!
    12:54pm  up 11 days, 16:15,  5 users,  load average: 2.89, 2.96, 2.91


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: 2004.2 Feature Requests

[Jon Portnoy]

On Sat, May 01, 2004 at 01:46:00PM -0400, Jerry McBride wrote:
> 
> Move all documentation to html and place it into a directory that apache can
> disseminate from. Having a central, online, browseable doc tree would be
> beautiful. Priceless...

Which documentation?

> 
> Move away from the filesystem database that portage currently uses to
> something with a bit more perfomance... mysql, sqlite even postgres... An
> SQL backend interface would be WONDERFUL.
> 
> Port portage to c or c++. Python sucks in the performance department... If
> not port to c then atleast start using psyco for a small perf boost...
> Rebuilding the cache (reading files) after a sync is... terrible... What a
> kludge...

The performance issues are db-related, nothing at all to do with Python.

> 
> Work on eliminating the constant caching of dependencies and other caching
> processes during boot up... On some of my boxes, these caching periods take
> longer than it does for KDE to boot to a usable desktop... What a drag on a
> laptop that I use to display linux with.... It's the first thing that
> windows advocates point and laugh at... Give me a break and cache the damn
> things when changes are MADE, not everytime you boot the box...

It shouldn't be recaching everything at boot time AFAIK. Run depscan.sh.

> 
> We need a better portage tool that easily displays ebuild dependencies...
> Can epm finally be completed so it offers the same functions for portrage
> that rpm has for it's own packages?

emerge --tree?
 
> 
> Tone down the amount of noise that emerge prints to the screen when using
> it. I don't need or want to see maybe 99.99% of all the stuff it prints
> during it operations. All you need is... either "THERE WAS AN ERROR" or
> "THERE WERE NO ERRORS". That in and of itself would boost performance a
> lot!... Less console updates, more cpu for the task at hand... Less user
> confusion...

emerge blah > /dev/null

That will only display stderr.

> 
> PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS
> BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS
> BARS...PROGRESS BARS...
> 

How would you calculate progress bars for most operations? They would be 
meaningless at best...

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: 2004.2 Feature Requests

[Jason Stubbs]

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

On Sunday 02 May 2004 12:40, Jon Portnoy wrote:
> On Sat, May 01, 2004 at 01:46:00PM -0400, Jerry McBride wrote:
> > Move away from the filesystem database that portage currently uses to
> > something with a bit more perfomance... mysql, sqlite even postgres... An
> > SQL backend interface would be WONDERFUL.
> >
> > Port portage to c or c++. Python sucks in the performance department...
> > If not port to c then atleast start using psyco for a small perf boost...
> > Rebuilding the cache (reading files) after a sync is... terrible... What
> > a kludge...
>
> The performance issues are db-related, nothing at all to do with Python.

The performance issues are partially db-related, but the biggest "problem" is 
having to call bash. The current caching in portage is still stored in a 
file-based "database". The difference in access times of the portage database 
and the cache is that the cache files have a set format.

Dropping the cache "kludge" and reading directly from the portage database 
(whether flat-file or sql or whatever) would require huge changes in the 
structure of ebuilds themselves. At minimum, it would require no usage of 
bash in the global section. This is something that will need a *lot* of work.

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQJTHo1oikN4/5jfsAQJw0gP/Q4d+A8x2iXPPwheO8j5g06ppAWQMGMB3
US1KqkK3ECp0Gjq1aSCMkEycadcbgByO0GE+boKciLSKf2Fqvceit4XTTsL3cco5
ZO+YaTObO/ihfNYuNw/q58cvYpfjYyk+IgJ0LEnxL+rrtfmq3e5fQ2brRT32B8dj
ICxTHxJ/Np4=
=Km24
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: 2004.2 Feature Requests

[Jason Wever]

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

On Sun, 2 May 2004 19:04:16 +0900
Jason Stubbs <jstubbs@gentoo.org> wrote:

> The performance issues are partially db-related, but the biggest
> "problem" is having to call bash. The current caching in portage is
> still stored in a file-based "database". The difference in access times
> of the portage database and the cache is that the cache files have a set
> format.

Most emerge commands, be it to sync the tree or perform a
package operation are very slow due to this bash handicap.  On one of the
faster sparc32 machines you can get, I'm seeing the following for a
pretend emerge of a package with few dependencies to calculate;

reliant root # time emerge -pv dnsmasq

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] net-dns/dnsmasq-2.5   0 kB

Total size of downloads: 0 kB


real    0m23.827s
user    0m21.750s
sys     0m1.310s

A good portion of this time doesn't even show any output from emerge at
all.

Cheers,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

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

Re: [gentoo-dev] Re: 2004.2 Feature Requests

[Grant Goodyear]

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

Jerry McBride wrote: [Sat May 01 2004, 01:46:00PM EDT]
> Got the point??? :')

Are you willing to write code?  Seriously, Gentoo is a community
distribution, not a commercial one.  We're all working on improving
Gentoo in our spare time, and there's always considerably more work to
do than people to do it.  Most of the items you listed are, indeed,
things that need to be accomplished (and, in fact, there are already
bugs filed for them), and we are incredibly grateful whenever anybody
adds working code to a bug.

Best,
g2boojum
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

Re: [gentoo-dev] Re: 2004.2 Feature Requests

[Paul de Vrieze]

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

On Saturday 01 May 2004 19:46, Jerry McBride wrote:
> Move all documentation to html and place it into a directory that apache
> can disseminate from. Having a central, online, browseable doc tree would
> be beautiful. Priceless...

All package documentation is accessible from http://localhost/doc/ in the 
default apache configuration files.

> Move away from the filesystem database that portage currently uses to
> something with a bit more perfomance... mysql, sqlite even postgres... An
> SQL backend interface would be WONDERFUL.

The biggest problem is that the ebuilds can only be parsed using bash. If that 
restriction can be lifted (by restricting / changing the ebuild format) 
parsing should go a lot faster. Really the installed package database is not 
the problem.

> Port portage to c or c++. Python sucks in the performance department... If
> not port to c then atleast start using psyco for a small perf boost...
> Rebuilding the cache (reading files) after a sync is... terrible... What a
> kludge...

Ever heard of the 10/90 rule. Really python is not the problem, the cache 
rebuilding is again ebuild parsing.

>
> Work on eliminating the constant caching of dependencies and other caching
> processes during boot up... On some of my boxes, these caching periods take
> longer than it does for KDE to boot to a usable desktop... What a drag on a
> laptop that I use to display linux with.... It's the first thing that
> windows advocates point and laugh at... Give me a break and cache the damn
> things when changes are MADE, not everytime you boot the box...

Probably those calculations should be rethought and a better algorithm should 
be devised. Calculating at boot time does make sense though as we have no way 
to know when the calculations are invalid.

> Tone down the amount of noise that emerge prints to the screen when using
> it. I don't need or want to see maybe 99.99% of all the stuff it prints
> during it operations. All you need is... either "THERE WAS AN ERROR" or
> "THERE WERE NO ERRORS". That in and of itself would boost performance a
> lot!... Less console updates, more cpu for the task at hand... Less user
> confusion...
>
> PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS
> BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS
> BARS...PROGRESS BARS...
>
> Got the point??? :')

I see what you mean. There are two problems. It is very hard to make a 
progress bar as using useflags means that we cannot give a good idea of the 
amount of code to be compiled in total. Even measuring what has allready been 
done is hard. Also removing the build output creates much problems for 
bug-hunting.

If you don't want to see the compilation happen. Use "emerge foo &>/dev/null&" 
and you will see nothing. When bash has finished it will tell you whether it 
was successfull. (Instead you could direct to a file that you can check upon 
once in a while)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Re: 2004.2 Feature Requests

[John Nilsson]

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

> All package documentation is accessible from http://localhost/doc/ in the 
> default apache configuration files.

What about /usr/share/doc/, /usr/share/man/ and /usr/share/info/?

app-text/man2html and app-text/info2html seems to be the right tools.

/usr/share/doc/ would need ebuild support to be converted to html
though.
my system has 361 dirs in /usr/share/doc/ of which 68 has a html/
subdir.


> > Move away from the filesystem database that portage currently uses to
> > something with a bit more perfomance... mysql, sqlite even postgres... An
> > SQL backend interface would be WONDERFUL.
> 
> The biggest problem is that the ebuilds can only be parsed using bash. If that 
> restriction can be lifted (by restricting / changing the ebuild format) 
> parsing should go a lot faster. Really the installed package database is not 
> the problem.

It seems that a lot of the information in ebuilds could be stated
declarative rather than imperative as it is now. Changing the ebuild
format to xml could be beneficial. The imperative sections could remain
and then fed to bash as the result of an xslt transformation.
I see no reason why portage couldn't support two formats in a transition
period.

A small performance/space improvement would be to keep one file per
package rather then by version.

> I see what you mean. There are two problems. It is very hard to make a 
> progress bar as using useflags means that we cannot give a good idea of the 
> amount of code to be compiled in total. Even measuring what has allready been 
> done is hard. Also removing the build output creates much problems for 
> bug-hunting.

This is not a portage issue. Make could be patched to calculate the
amount of code (in kb) that would be considered for a particular target.
I have no idea what kind of overhead we are talking about here though.

-John

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

Re: [gentoo-dev] Re: 2004.2 Feature Requests

[Brian Friday]

Just a lurker point his nose in but here I go

The contents of "/usr/share/doc" can be found when apache is 
installed and the default for the doc directory isn't change 
at the url of "= http://localhost/doc". It works great, your 
web browser is smart enough to uncompress the gzipped 
content so space is saved in a manner which is both elegant 
and productive.

As for switching man pages or info pages to html 
automatically and or by default I've got to ask the obvious 
question of why. The current setup of the doc directory is: 
1) useful with apache, less, zcat, lynx etc; 2) doesn't 
require a serious amount of effort on the part of the ebuild 
maker to put the docs in a location users can get them, 3) 
doesn't require transforming those docs into something other 
than the original makers intended. By keepings points 2 and 
3 intact it means less hoops ebuild makers and maintainers 
have to jump through which for my money translates into 
happier makers/maintainers and more initial ebuilds 
submitted by joe/jane "I want this app" submitter.

Now if your talking "I'm a user who wants to take the 
additional step of using man2html and info2html" well 
perhaps thats different but thats a second step maybe we can 
document for end-users but leave it up to them if they want 
to implement it. If there is a serious feeling of adventure 
maybe making it a use flag or portage option which acts just 
like packages and warns the user that they must run 
"man2html" or "info2html" in order to insure that the 
man/info files they just installed with the application are 
available. Of course like fixpackages a "this could take a 
lot of time and or use additional space" warning would be 
appropriate.

them's my pennies!

John Nilsson wrote:

> What about /usr/share/doc/, /usr/share/man/ and /usr/share/info/?
> 
> app-text/man2html and app-text/info2html seems to be the right tools.
> 
> /usr/share/doc/ would need ebuild support to be converted to html
> though.
> my system has 361 dirs in /usr/share/doc/ of which 68 has a html/
> subdir.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: 2004.2 Feature Requests

[Paul de Vrieze]

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

On Monday 03 May 2004 06:48, John Nilsson wrote:
> > All package documentation is accessible from http://localhost/doc/
> > in the default apache configuration files.
>
> What about /usr/share/doc/, /usr/share/man/ and /usr/share/info/?
>
> app-text/man2html and app-text/info2html seems to be the right tools.
>
> /usr/share/doc/ would need ebuild support to be converted to html
> though.
> my system has 361 dirs in /usr/share/doc/ of which 68 has a html/
> subdir.

/usr/share/doc is available. It is not available as html, but normally 
the compression is handled transparently by the browser. Man and info 
are more complicated and some cgi scripts are needed for it.

> > The biggest problem is that the ebuilds can only be parsed using
> > bash. If that restriction can be lifted (by restricting / changing
> > the ebuild format) parsing should go a lot faster. Really the
> > installed package database is not the problem.
>
> It seems that a lot of the information in ebuilds could be stated
> declarative rather than imperative as it is now. Changing the ebuild
> format to xml could be beneficial. The imperative sections could
> remain and then fed to bash as the result of an xslt transformation. I
> see no reason why portage couldn't support two formats in a transition
> period.

That is right, we will have a declarative ebuild format for portage-ng, 
but there are too many ebuilds currently using imperative features.

> A small performance/space improvement would be to keep one file per
> package rather then by version.

This is not really an option.

>
> > I see what you mean. There are two problems. It is very hard to make
> > a progress bar as using useflags means that we cannot give a good
> > idea of the amount of code to be compiled in total. Even measuring
> > what has allready been done is hard. Also removing the build output
> > creates much problems for bug-hunting.
>
> This is not a portage issue. Make could be patched to calculate the
> amount of code (in kb) that would be considered for a particular
> target. I have no idea what kind of overhead we are talking about here
> though.

If you would create the patch I think that it would be useful for some 
people. Know though that many make files (almost all automake files) are 
broken and will not lead to a proper dependency tree (also causing "make 
- -j" problems) and as might not be easy to put into a progress counter.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAlfsibKx5DBjWFdsRAtTnAJ9g7ib8qGiqyRYqMz80rSlcQA/oRQCeLaMt
hj9gdUNBf6ey4gpD6orhrWE=
=rTMg
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] still missing local use flags

[Michael Sterrett -Mr. Bones.-]

Still missing local use flags in use.local.desc for this stuff:

   app-office/gnumeric/gnumeric-1.2.2.ebuild: gnomedb
   app-office/pointless/pointless-0.5.ebuild: freetype
   app-sci/blas-reference/blas-reference-19940131.ebuild: ifc
   dev-libs/redland/redland-0.9.15.ebuild: php
   gnome-base/gnome-vfs/gnome-vfs-2.6.1.1.ebuild: gnutls
   media-gfx/gimp/gimp-2.0.0.ebuild: mng
   media-gfx/gnuplot/gnuplot-4.0.ebuild: xemacs
   media-libs/openvrml/openvrml-0.14.1.ebuild: javascript
   media-libs/openvrml/openvrml-0.14.3.ebuild: javascript
   media-sound/rhythmbox/rhythmbox-0.6.8.ebuild: faad
   media-sound/rhythmbox/rhythmbox-0.8.1.ebuild: faad
   media-sound/rhythmbox/rhythmbox-0.6.1-r1.ebuild: faad
   media-sound/rhythmbox/rhythmbox-0.8.0-r1.ebuild: faad
   media-sound/rhythmbox/rhythmbox-0.8.3.ebuild: faad
   media-video/vlc/vlc-0.6.1.ebuild: faad
   media-video/vlc/vlc-0.6.2-r1.ebuild: faad
   media-video/vlc/vlc-0.6.2.ebuild: faad
   media-video/vlc/vlc-0.7.1-r1.ebuild: faad
   media-video/vlc/vlc-0.7.1.ebuild: faad
   sys-devel/hardened-gcc/hardened-gcc-4.0.3.3.2-r1.ebuild: multilib
   sys-devel/hardened-gcc/hardened-gcc-4.0.3.3.2-r2.ebuild: multilib
   sys-devel/hardened-gcc/hardened-gcc-4.0.3.3.3-r1.ebuild: multilib
   sys-devel/hardened-gcc/hardened-gcc-4.0.3.3.3-r1.ebuild: nogcj
   sys-kernel/alpha-sources/alpha-sources-2.4.21-r3.ebuild: usagi
   sys-kernel/alpha-sources/alpha-sources-2.4.21-r4.ebuild: usagi
   sys-kernel/alpha-sources/alpha-sources-2.4.21-r2.ebuild: usagi
   sys-kernel/alpha-sources/alpha-sources-2.4.21-r5.ebuild: usagi
   sys-kernel/alpha-sources/alpha-sources-2.4.21-r6.ebuild: usagi
   sys-kernel/hppa-sources/hppa-sources-2.4.23_p4-r1.ebuild: xfs
   sys-kernel/hppa-sources/hppa-sources-2.4.23_p4-r2.ebuild: xfs
   sys-kernel/hppa-sources/hppa-sources-2.4.24_p0.ebuild: xfs
   sys-kernel/hppa-sources/hppa-sources-2.4.24_p0-r1.ebuild: xfs
   sys-kernel/ppc-sources-benh/ppc-sources-benh-2.4.22-r5.ebuild: xfs
   sys-kernel/ppc-sources-benh/ppc-sources-benh-2.4.22-r6.ebuild: xfs
   sys-kernel/ppc-sources-benh/ppc-sources-benh-2.4.22-r7.ebuild: xfs
   x11-libs/fltk/fltk-1.1.4.ebuild: nptl
   x11-libs/gtk-sharp/gtk-sharp-0.16.ebuild: gnomedb
   x11-libs/gtk-sharp/gtk-sharp-0.17.ebuild: gnomedb
   x11-libs/gtk-sharp/gtk-sharp-0.18.ebuild: gnomedb
   x11-libs/gtk-sharp/gtk-sharp-0.91.1.ebuild: gnomedb

Find yours and add it please.

Michael Sterrett
  -Mr. Bones.-
mr_bones_@gentoo.org

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Jason Stubbs]

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

On Friday 30 April 2004 12:42, John Davis wrote:
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.

On Sunday 02 May 2004 00:56, Paul de Vrieze wrote:
> ps. Besides this I feel the need to allow per-ebuild descriptions on
> useflags. Those descriptions would describe what the consequences of the
> useflags are. Like for subversion the berkdb useflag signifies whether the
> server part gets build (because berkdb is needed for that), it would be
> very usefull to have some easilly accessible description for it.

A big +1 on this.

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQJQ1ploikN4/5jfsAQJf6gQAoO4ZW7uovyHIDuQgunQSLRXw2lVyHNMZ
Gsc5rtgYapB8r/Izy/WFRlmxRE1Kbyay+7GI4/tIp400sQnjlMwgHmCKP4fsTPXK
rWlUfO4upmRnazZKmhQitCV8R716SwdZUSrg53bDyJxGmW/JiQmkGiG2fNTcSAaW
koOlAqo3fk8=
=hxZc
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Josh Glover]

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

Quoth John Davis (Thu 2004-04-29 11:42:38PM -0400):

> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.

Here is one for Portage:

Notes displayed with einfo should be logged somewhere, so that when you
emerge 100 packages at a time, you can go back and read the little tweaks
that you might want to make to your XF86Config-4 file, etc.

-- 
Josh Glover

GPG keyID 0xDE8A3103 (C3E4 FA9E 1E07 BBDB 6D8B  07AB 2BF1 67A1 DE8A 3103)
gpg --keyserver pgp.mit.edu --recv-keys DE8A3103

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Peter Ruskin]

On Monday 03 May 2004 12:05, Josh Glover wrote:
> Here is one for Portage:
>
> Notes displayed with einfo should be logged somewhere, so that when
> you emerge 100 packages at a time, you can go back and read the
> little tweaks that you might want to make to your XF86Config-4 file,
> etc.

I use Owen Gunden's "emergemail" and have all those messages mailed to 
me.  See http://bugs.gentoo.org/show_bug.cgi?id=11359 Comment #25.

I do wish Gentoo would incorporate this excellent feature into portage.

-- 
Peter
========================================================================
Gentoo Linux: Portage 2.0.50-r6.	kernel-2.6.5-gentoo-r1.
i686 AMD Athlon(tm) XP 3200+.		gcc(GCC): 3.3.2.
KDE: 3.2.2.				Qt: 3.3.2.
========================================================================

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: 2004.2 Feature Requests

[Duncan]

John Davis posted <1083296558.8842.127.camel@woot.uberdavis.com>,
excerpted below,  on Thu, 29 Apr 2004 23:42:38 -0400:

> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The last
> day that we are accepting requests is Friday, May 7th at which point
> releng will hold a meeting and decide which requests are feasible for both
> the alloted time and workload. Thank you for your time and your requests.

Here's (what should be) a simple one.

Include a "man" binary in the stage-one tarballs.

I'm new to Gentoo, having started with 2004.0, but have yet to
successfully get a working system, (after having waited for .1 to come
out before trying again, after a first learning run). A lot of the reason
is the way I go about it, demanding (and eventually getting) a system
customized to my wishes from the get-go, learning huge gobs of stuff along
the way, that it'd otherwise take me quite awhile to learn, as I'd never
be confronted with issues forcing me to learn it in ordinary operations.
Computing is my hobby, not my profession, so I'm not on a deadline, and
I'm fine with all that.

One of the things I've done is analyze the bootstrap(-2.6).sh script and
do a single ebuild at a time (with proper bootstrap and build use flags
where appropriate) what those scripts do in one huge step.  In an earlier
run I got far enough into things to make use of the emerge and friends man
pages, which helped me understand quite a bit more of what was going on. 
Then I decided I wanted to start over, and did so, cleaning the partitions
and installing the new (now 2004.1) stage-one tarball, and going from
there.  However, I was having problems getting one (unstable) package to
properly emerge, and wanted to try the single-step-at-a-time ebuild
command instead.

Trouble was I couldn't remember the steps and man isn't yet installed at
that point in the process.

As it happens, I'm installing using a chroot from a running Mandrake
(AMD64) system, and I got around the problem by creating a script named
gman to be run from OUTSIDE the chroot, that would set $MANPATH to the
Gentoo mounted version (copied from the /etc/profile.env file and modified
to include the gentoo root mountpoint), before calling (the Mandrake) man.
Thus, I could "gman ebuild", "gman portage", etc.  A few commands used
in both distribs are slightly different between them, and with gman
setting the gentoo path exclusively, and my regular mandrake manpath
unmodified, I could call up the manpage for whichever version I wanted,
using either man or gman, from OUTSIDE the gentoo chroot.

I find it rather strange and frustrating that after updating my
chroot environment per the handbook instructions, I have a $MANPATH
variable setup perfectly correctly, within the chroot, but no "man" binary
to use it, until rather later in the bootstrap process.

Thus, my request is simply to provide a man binary in the stage-one, to be
overwritten later when it is compiled, just as with the other basic
binaries from coreutils.  This would be of /tremendous/ help to "stubborn
mules" such as myself <g>, that like to do things the HARD way, learning
as they go.  I definitely found it rather disconcerting to be without a
working man system, even while the documents and manpath itself were
setup.  It's kinda hard to learn as you go when you can't read what you
are supposed to be learning!  <g> 

OTOH, I DID learn how to setup $MANPATH manually to access "foreign"
manpages, something I would have missed if the stage-one HAD supplied a
binary man, and a good place to apply such "theoretical" knowledge, so it
wasn't without its benefits.  I wish I would have thought of it sooner,
however, as I sure wasted enough time trying (without success) to google
for the man pages I needed, first.

That of course is another suggestion:  There are a number of web sources
for various standard man pages.  Couldn't the Gentoo specific ones be
hosted somewhere and a link to them be placed in the handbook?  The
handbook does provide a good introduction to use flags and some of the
additional features of portage and etc, but fails to provide the
detailed info the manpages, particularly the ebuild (1 and 5) manpages,
provide.  Reading them was an invaluable help in parsing the ebuild
scripts so I could understand what was happening, and figure out where I
could customize and/or where an ebuild was failing that I HAD customized. 
I only wish I'd had that info ahead of time, when I'd read the handbook,
and the amd64.gentoo.org documentation, in doing my pre-install research.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Olivier Fisette]

Le jeudi, 29 Avril, 2004 23:42, John Davis a écrit :
> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.
>
> Cheers,
> //zhen

One thing I'd like to see is the possibility for emerge and Portage to manage 
concurrent actions, such as compiling while downloading, multiple 
simultaneous downloads and multiple simultaneous emerge processes. This would 
speed up system and world updates, and allow to safely install other packages 
while such updates are running.

-- 
Olivier Fisette (pilos)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Stuart Herbert]

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

On Friday 07 May 2004 04:33, Olivier Fisette wrote:
> One thing I'd like to see is the possibility for emerge and Portage to
> manage concurrent actions, such as compiling while downloading, multiple
> simultaneous downloads and multiple simultaneous emerge processes. This
> would speed up system and world updates, and allow to safely install other
> packages while such updates are running.

I'll second that request.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Nick Rout]

An X (KDE for personal pref) livecd so I can surf the net whilst
installing. So nice to have the install docs open in a graphical browser
;-)

only as an option of course, its still valuable to have the very
minimalist livecd for quick downloads. gentoo==choice

EITHER gcc/binutils/distcc on the livecd so that idle windows boxes can
be put to use compiling, OR a separate distcc iso.




On Thu, 29 Apr 2004 23:42:38 -0400
John Davis <zhen@gentoo.org> wrote:

> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are feasible
> for both the alloted time and workload. Thank you for your time and your
> requests.
> 
> Cheers,
> //zhen
> -- 
> John Davis
> Gentoo Linux Developer
> <http://dev.gentoo.org/~zhen>
> 
> ----
> GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
> Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47
> 

-- 
Nick Rout <nick@rout.co.nz>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Christian Parpart]

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

On Friday 07 May 2004 6:26 am, Nick Rout wrote:
> An X (KDE for personal pref) livecd so I can surf the net whilst
> installing. So nice to have the install docs open in a graphical browser
> ;-)

just adding x11, kdelibs+kdebase, and mozilla-firefox (for those that can't 
live without), and the real nvidia drivers ;-)

[....]
> EITHER gcc/binutils/distcc on the livecd so that idle windows boxes can
> be put to use compiling, OR a separate distcc iso.

I'd even propose to call such thing a grid-livecd or distributed-livecd and 
additionally put on it the whole dvdrip dependencies and other - rather tiny 
- - packages that support distributed processing.
Or - my personal favorite - what about having an official openmosix 
master/node livecd? However, this would be nice for those beeing in an 
internet cafe/station where often dozents of computers are idling around some 
time.

[....]
Cheers,
Christian Parpart.

- -- 
 08:51:53 up 121 days, 18:19,  1 user,  load average: 1.00, 1.02, 1.00
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAmzNzPpa2GmDVhK0RApVUAJ9OZeN87/TAyIEHCTU8xOX473oh/ACcCDEV
9LonJHfRDQ102qPqUc7vo70=
=HTal
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Donnie Berkholz]

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

On Fri, 2004-05-07 at 02:57, Christian Parpart wrote:
> On Friday 07 May 2004 6:26 am, Nick Rout wrote:
> > EITHER gcc/binutils/distcc on the livecd so that idle windows boxes can
> > be put to use compiling, OR a separate distcc iso.
> 
> I'd even propose to call such thing a grid-livecd or distributed-livecd and 
> additionally put on it the whole dvdrip dependencies and other - rather tiny 
> - - packages that support distributed processing.
> Or - my personal favorite - what about having an official openmosix 
> master/node livecd? However, this would be nice for those beeing in an 
> internet cafe/station where often dozents of computers are idling around some 
> time.

If you're interested in this, it'd be helpful if you coordinated with
the cluster project (gentoo-cluster mailing list, #gentoo-cluster irc).

Thanks,
-- 
Donnie Berkholz
Gentoo Linux

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Chris Bainbridge]

On Friday 07 May 2004 05:26, Nick Rout wrote:
> An X (KDE for personal pref) livecd so I can surf the net whilst
> installing. So nice to have the install docs open in a graphical browser
> ;-)

Knoppix makes a great gentoo install cd ;-) Just mount your install dir, 
unpack the stage1 tar into it, and chroot. 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Matthew Marlowe]

> Hi all -
> To start preparing for 2004.2 in July, releng is opening up Feature
> Requests that the community would like to see included in 2004.2. The
> last day that we are accepting requests is Friday, May 7th at which
> point releng will hold a meeting and decide which requests are
> feasible for both the alloted time and workload. 

The biggest issues I've had with current and prior gentoo releases is the kernel.   I've configured a couple dozen dell boxes of different models over the last 6 months using 1.4, 2004.0, and 2004.1, and invariably one or more of the following occurs:

- smp kernel locks up completely during hardware detection.
- basic gentoo kernel runs, but doesn't always autodetect raid or network drivers
- forced migration to lvm2, because the kernel is configured in 2004.0 for lvm2
- 1-3 processors are idle during system installs because of various smp/apic issues 

Most of these problems would go away if there was a simple documented way to allow users to substitute in their own kernels.  Improving the QA process would help, of course, but I doubt the release eng team has time for this.

I know that the new catalyst system is supposed to make things easier, and I'm researching that now...but it definitly doesn't appear to be as simple as it could be.  I'd really like to see future releases work out of the box for Dell servers.  

Regards,

Matt

--
Matthew Marlowe,
DeployLinux.Net Consulting
http://www.deploylinux.com/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Greg KH]

On Sat, May 01, 2004 at 12:37:00AM +0000, Matthew Marlowe wrote:
> > Hi all -
> > To start preparing for 2004.2 in July, releng is opening up Feature
> > Requests that the community would like to see included in 2004.2. The
> > last day that we are accepting requests is Friday, May 7th at which
> > point releng will hold a meeting and decide which requests are
> > feasible for both the alloted time and workload. 
> 
> The biggest issues I've had with current and prior gentoo releases is
> the kernel.   I've configured a couple dozen dell boxes of different
> models over the last 6 months using 1.4, 2004.0, and 2004.1, and
> invariably one or more of the following occurs:
> 
> - smp kernel locks up completely during hardware detection.

That's nasty.  Did you report to the hotplug/kernel people?

Hardware detection is hard for all systems.  If it's not
USB/PCI/Firewire, it is _very_ hard.

> - basic gentoo kernel runs, but doesn't always autodetect raid or network drivers
> - forced migration to lvm2, because the kernel is configured in 2004.0 for lvm2

lvm1 is dead, please migrate as no one is supporting that anymore.

> - 1-3 processors are idle during system installs because of various smp/apic issues 

With a 2.6 kernel you should not have this problem.  You did try this
with the 2.6 kernel, right?

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Ajai Khattri]

On Fri, 30 Apr 2004, Greg KH wrote:

> That's nasty.  Did you report to the hotplug/kernel people?
>
> Hardware detection is hard for all systems.  If it's not
> USB/PCI/Firewire, it is _very_ hard.

Ive had problems with this too on almost every server Ive built.
I generally end up doing "smp-nofb doscsi nodetect nousb nodhcp" to boot
the LiveCD and then load modules by hand...

-- 
Aj.
Sys. Admin / Developer

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[Chris Gianelloni]

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

On Fri, 2004-04-30 at 20:37, Matthew Marlowe wrote:
> > Hi all -
> > To start preparing for 2004.2 in July, releng is opening up Feature
> > Requests that the community would like to see included in 2004.2. The
> > last day that we are accepting requests is Friday, May 7th at which
> > point releng will hold a meeting and decide which requests are
> > feasible for both the alloted time and workload. 
> 
> The biggest issues I've had with current and prior gentoo releases is the kernel.   I've configured a couple dozen dell boxes of different models over the last 6 months using 1.4, 2004.0, and 2004.1, and invariably one or more of the following occurs:
> 
> - smp kernel locks up completely during hardware detection.

I find that "smp nohotplug doscsi" seems to be the best bet on any of
the Dell/Compaq/HP servers that I have dealt with recently.

> - basic gentoo kernel runs, but doesn't always autodetect raid or network drivers
> - forced migration to lvm2, because the kernel is configured in 2004.0 for lvm2
> - 1-3 processors are idle during system installs because of various smp/apic issues 

See above...

> Most of these problems would go away if there was a simple documented way to allow users to substitute in their own kernels.  Improving the QA process would help, of course, but I doubt the release eng team has time for this.

There would be no real way to substitute a kernel, since the livecd is a
read-only environment.  You could build your own CDs via catalyst with
any kernel you choose.  I know that is not the best answer, but the
truth is we try our best to come up with a release that meets the most
possible configurations.  There are many cases where the CD simply
doesn't work, and that is a QA issue, but it is definitely something we
are striving to improve.

> I know that the new catalyst system is supposed to make things easier, and I'm researching that now...but it definitly doesn't appear to be as simple as it could be.  I'd really like to see future releases work out of the box for Dell servers.  

Catalyst makes building a live CD easier, but it doesn't do QA for you. 
This is especially true of the kernels on the CD.  The only thing that
really does any good is testing.  Perhaps you should join the
gentoo-releng mailing list and help with testing on the next release. 
The more machines the beta live CD get exposure to, the more bugs get
resolved before release.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?

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

Re: [gentoo-dev] 2004.2 Feature Requests

[Nick Rout]

On Sat, 01 May 2004 15:10:25 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> On Fri, 2004-04-30 at 20:37, Matthew Marlowe wrote:
> > > Hi all -
> > > To start preparing for 2004.2 in July, releng is opening up Feature
> > > Requests that the community would like to see included in 2004.2. The
> > > last day that we are accepting requests is Friday, May 7th at which
> > > point releng will hold a meeting and decide which requests are
> > > feasible for both the alloted time and workload. 
> > 
> > The biggest issues I've had with current and prior gentoo releases is the kernel.   I've configured a couple dozen dell boxes of different models over the last 6 months using 1.4, 2004.0, and 2004.1, and invariably one or more of the following occurs:
> > 
> > - smp kernel locks up completely during hardware detection.
> 
> I find that "smp nohotplug doscsi" seems to be the best bet on any of
> the Dell/Compaq/HP servers that I have dealt with recently.
> 
> > - basic gentoo kernel runs, but doesn't always autodetect raid or network drivers
> > - forced migration to lvm2, because the kernel is configured in 2004.0 for lvm2
> > - 1-3 processors are idle during system installs because of various smp/apic issues 
> 
> See above...
> 
> > Most of these problems would go away if there was a simple documented way to allow users to substitute in their own kernels.  Improving the QA process would help, of course, but I doubt the release eng team has time for this.
> 
> There would be no real way to substitute a kernel, since the livecd is a
> read-only environment.  You could build your own CDs via catalyst with
> any kernel you choose.  I know that is not the best answer, but the
> truth is we try our best to come up with a release that meets the most
> possible configurations.  There are many cases where the CD simply
> doesn't work, and that is a QA issue, but it is definitely something we
> are striving to improve.
> 
> > I know that the new catalyst system is supposed to make things easier, and I'm researching that now...but it definitly doesn't appear to be as simple as it could be.  I'd really like to see future releases work out of the box for Dell servers.  
> 
> Catalyst makes building a live CD easier, but it doesn't do QA for you. 
> This is especially true of the kernels on the CD.  The only thing that
> really does any good is testing.  Perhaps you should join the
> gentoo-releng mailing list and help with testing on the next release. 
> The more machines the beta live CD get exposure to, the more bugs get
> resolved before release.

How about publishing the .spec files that have been used to make the
releases, so that those who want to make their own CD with their own
kernel, or extra features like distcc, can do so.

I have recently made a distcc livecd, and used a combination of the
example catalyst specs (USE="doc" emerge catalyst), hand coding of the
chroot install image etc. It would have been easier if I had the actual
2004.1 .spec files and a decent howto on catalyst (ie a howto  for
people who are not already in the know.) My livecd is largely a hack and
I don't know if i could repeat it. Of course during this time catalyst
has gone from 1.04 to 1.07 and 2004.1 has been released. But hey
it certainly was easier than using livecd-ng this time a year ago!

Not being critical, but catalyst has great potential for all sorts of
things, its just that IMHO its not that easy to get to  grips with.

Anyway,  publication of the .spec files would surely enhance the
"open-ness" of the release cycle.

(Maybe the .spec files are released, but I don't know where to find them?)


> 
> -- 
> Chris Gianelloni
> Developer, Gentoo Linux
> Games Team
> 
> Is your power animal a penguin?

-- 
Nick Rout <nick@rout.co.nz>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2004.2 Feature Requests

[John Davis]

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

On Sun, 2004-05-02 at 19:46, Nick Rout wrote:

> How about publishing the .spec files that have been used to make the
> releases, so that those who want to make their own CD with their own
> kernel, or extra features like distcc, can do so.
> 
> I have recently made a distcc livecd, and used a combination of the
> example catalyst specs (USE="doc" emerge catalyst), hand coding of the
> chroot install image etc. It would have been easier if I had the actual
> 2004.1 .spec files and a decent howto on catalyst (ie a howto  for
> people who are not already in the know.) My livecd is largely a hack and
> I don't know if i could repeat it. Of course during this time catalyst
> has gone from 1.04 to 1.07 and 2004.1 has been released. But hey
> it certainly was easier than using livecd-ng this time a year ago!
> 
> Not being critical, but catalyst has great potential for all sorts of
> things, its just that IMHO its not that easy to get to  grips with.
> 
> Anyway,  publication of the .spec files would surely enhance the
> "open-ness" of the release cycle.
> 
> (Maybe the .spec files are released, but I don't know where to find them?)

Nick -
There is a livecd stage1 template specfile linked off of the release
guidelines (which are linked off of the releng project page
http://www.gentoo.org/proj/en/releng). As for livecd stage2, we can
surely work on including those either in the release notes or on the cd
itself.

Catalyst documentation is in the works. In my spare time (heh) I am
writing up a comprehensive Catalyst howto - right now it only covers
stages, but after finals are done I am going to try and complete it. You
can find it at
http://www.gentoo.org/proj/en/releng/docs/catalyst-howto.xml.

Hope this helps! 

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


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

Re: [gentoo-dev] 2004.2 Feature Requests

[Jay Maynard]

On Sun, May 02, 2004 at 07:56:06PM -0400, John Davis wrote:
> On Sun, 2004-05-02 at 19:46, Nick Rout wrote:
> > How about publishing the .spec files that have been used to make the
> > releases, so that those who want to make their own CD with their own
> > kernel, or extra features like distcc, can do so.
> There is a livecd stage1 template specfile linked off of the release
> guidelines (which are linked off of the releng project page
> http://www.gentoo.org/proj/en/releng). As for livecd stage2, we can
> surely work on including those either in the release notes or on the cd
> itself.

Perhaps we can have another package in portage, at least: gentoo-livecd-spec
or some such - that has the version number of the release it corresponds to,
with the specfiles in there. Maybe we can simply create a new place in
/usr/portage for them. It would certainly make my job easier in getting Alpha
releases out the door if I could make it simple for other folks to run the
builds, even if I have to set them up...since a full build takes about 36
hours, start to finish, plus whatever time is involved in noticing that one
stage is done and it's time to start the next one.


--
gentoo-dev@gentoo.org mailing list