Re: [gentoo-dev] lastrite: net-fs/coda-kernel (treecleaners)

2008-04-24 Thread Dirk Heinrichs

ext Daniel Drake schrieb:

Samuli Suominen wrote:

# Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008)
# Masked by treecleaners for bug 160267. Removed in ~60 days.
# Has been included in 2.6 kernel series.
net-fs/coda-kernel


Are you sure? codafs has been in the kernel for years but I think the 
external package is something different.


I'd say the only difference is the version. Don't know how frequently 
the in-kernel module code is updated, though.


Bye...

Dirk
--
Dirk Heinrichs  | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: [EMAIL PROTECTED]
Wanheimerstraße 68  | Web:  http://www.capgemini.com
D-40468 Düsseldorf  | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] config_eth0 deprecated - new name?

2008-04-24 Thread Roy Marples
On Thursday 24 April 2008 00:01:01 Robin H. Johnson wrote:
 The problem in this is that you cannot set the properties for each
 address or route. Please don't take us back to the stoneage of writing
 the advanced networking configuration manually.

 As an example of an ip address line with properties:
 ${ext}.30/32 broadcast - scope host

Correct as usual. However, the existing config_foo isn't going anyway anytime 
soon, so your power user config still works.
However, it will be moving to the right place
ifconfig_eth0
ip_addr_eth0

And we'll stop parsing it. You'll have to know the syntax for the module 
you're using. I'm going to trying to map between them which will make the 
code lighter and less error prone.


 An an example of a route with properties:
 ${int}.192/27 dev bond0 mtu 1500 table internal scope link
 (my normal mtu on the internal link is 9k, but part of the subnet runs
 at 1500 for netbooting on dumb cards)

You can do this with the BSD style syntax

static_routes_bond0=int0 int192 defint
route_int0=${int}.0/8 dev bond0 table internal scope link
route_int192=${int}.192/27 dev bond0 mtu 1500 table internal scope link
route_defint=default via ${int}.2 bond0 table internal

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] config_eth0 deprecated - new name?

2008-04-24 Thread Roy Marples
On Wednesday 23 April 2008 23:01:38 Graham Murray wrote:
 Roy Marples [EMAIL PROTECTED] writes:
  On Wednesday 23 April 2008 21:46:18 Robin H. Johnson wrote:
  See my attached example from work, we use a lot of the various options
  on stuff.
 
  No, we won't support that. However, we will bring back ip ranges for the
  last ocet like so
  1.2.3.4-10/24

 It looks to me as though you are intending to remove the capability to
 set up complex network environments.

No I'm not.
I'm making it easy for simple configs AND complex ones. Just not through the 
same variable.

 [1] But in my opinion, the baselayout-1 /etc/net.conf syntax is better than
 that in baselayout-2. Though I have not yet migrated any of the systems
 with complex networking to baselayout-2.

Sadly, default scripts we ship have to work with shells other than bash.
Of course, you're still welcome to use config_eth0 as a bash array as that 
still works and will for the foreseeable future.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] config_eth0 deprecated - new name?

2008-04-24 Thread Luca Barbato

Roy Marples wrote:

On Thursday 24 April 2008 00:01:01 Robin H. Johnson wrote:

The problem in this is that you cannot set the properties for each
address or route. Please don't take us back to the stoneage of writing
the advanced networking configuration manually.

As an example of an ip address line with properties:
${ext}.30/32 broadcast - scope host


Correct as usual. However, the existing config_foo isn't going anyway anytime 
soon, so your power user config still works.

However, it will be moving to the right place
ifconfig_eth0
ip_addr_eth0


Looks like some documentation could be useful.

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Last Rights: x11-themes/openbox-themes

2008-04-24 Thread David Shakaryan

# David Shakaryan [EMAIL PROTECTED] (24 Apr 2008)
# Masked for removal in 30 days. (bug #197277)
# Extremely old compilation of themes not utilising new features.
# Openbox is intended to move to a new theme format in the future.
x11-themes/openbox-themes

--
David Shakaryan
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Last Rights: x11-themes/openbox-themes

2008-04-24 Thread David Shakaryan

David Shakaryan wrote:

# David Shakaryan [EMAIL PROTECTED] (24 Apr 2008)
# Masked for removal in 30 days. (bug #197277)
# Extremely old compilation of themes not utilising new features.
# Openbox is intended to move to a new theme format in the future.
x11-themes/openbox-themes


Argh! Regarding the subject, homophones suck at 2am. :(

--
David Shakaryan
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] config_eth0 deprecated - new name?

2008-04-24 Thread Graham Murray
Roy Marples [EMAIL PROTECTED] writes:

 On Wednesday 23 April 2008 23:01:38 Graham Murray wrote:
 It looks to me as though you are intending to remove the capability to
 set up complex network environments.

 No I'm not.
 I'm making it easy for simple configs AND complex ones. Just not through the 
 same variable.

Sorry, I misunderstood.
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Prioritising contact information in metadata.xml

2008-04-24 Thread Jeroen Roovers
 Hi developers and other users,


since jakub[1] went completely missing a few weeks ago a few others and
I have been wrangling the bugs. I've heard rumours that this isn't
working smoothly yet. Of course most of that can be fully blamed on
bugzilla itself, but there are some things that need to be pointed out
or discussed.

One thing I'd like to point out is that if you don't agree with a
specific mangle, just CC whoever did it on the bug and explain.
If you don't give me the feedback, I can never know how you would
rather have wanted to get bugs delivered.

One other thing is that it is sometimes difficult to figure out to
whom a bug should be assigned, because metadata.xml for many packages
simply isn't clear. If you list a few developers as well as a herd,
does that mean you want bugs assigned to the herd or to a single
developer who happens to be in that list? Some packages list several
herds in metadata.xml. Bugs can be assigned to just one address
(or you get Assignee: [EMAIL PROTECTED],[EMAIL PROTECTED] did not
match anything).

[2] has nothing explicit to say on this subject, sadly. It seems some
editors of metadata.xml use the file as a sort of CREDITS or AUTHORS.
While that may seem OK, the file is intended to give information about
ebuilds. ChangeLog is intended to credit authors (specifically
mentioning ebuild authors and contributors[3]).

So maybe this needs to be layed out more specifically in the Developer
Handbook, or maybe this needs to be discussed more. I can tell that
from my end, and possibly from the viewpoint of any user who is seeking
support contacts, listing more than one contact in metadata.xml is
rather pointless, unless descriptions are added so that it's clear
which component of a package is supported by whom.

All in all I guess we need to make the rules up as we go and decide
policy later. I suggest the first herd/address in the list should be
the primary contact. If you don't agree with that, please consult
metadata.xml for the package or reassign to bug-wranglers with an
explanation (and perhaps a promise to quickly change metadata.xml. :)


Kind regards,
 JeR


[1] Where is the old bugger? Anyone know? On a strictly human level, I
am getting quite worried.
[2]
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=4
[3]
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1#doc_chap3_sect6
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Prioritising contact information in metadata.xml

2008-04-24 Thread Mike Frysinger
On Thursday 24 April 2008, Jeroen Roovers wrote:
 One other thing is that it is sometimes difficult to figure out to
 whom a bug should be assigned, because metadata.xml for many packages
 simply isn't clear. If you list a few developers as well as a herd,
 does that mean you want bugs assigned to the herd or to a single
 developer who happens to be in that list? Some packages list several
 herds in metadata.xml.

unfortunately this is dependent on the herd/developers.  debating which is 
correct is pointless.  let's add a priority or some other marker to the dtd 
so people updating the xml can indicate the preference themselves.

 Bugs can be assigned to just one address 
 (or you get Assignee: [EMAIL PROTECTED],[EMAIL PROTECTED] did not
 match anything).

that's why the CC list exists

 [2] has nothing explicit to say on this subject, sadly. It seems some
 editors of metadata.xml use the file as a sort of CREDITS or AUTHORS.
 While that may seem OK, the file is intended to give information about
 ebuilds. ChangeLog is intended to credit authors (specifically
 mentioning ebuild authors and contributors[3]).

agreed. metadata.xml is certainly not the place for giving credit.  use the 
ChangeLog file.
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] config_eth0 deprecated - new name?

2008-04-24 Thread Mike Frysinger
On Thursday 24 April 2008, Luca Barbato wrote:
 Roy Marples wrote:
  On Thursday 24 April 2008 00:01:01 Robin H. Johnson wrote:
  The problem in this is that you cannot set the properties for each
  address or route. Please don't take us back to the stoneage of writing
  the advanced networking configuration manually.
 
  As an example of an ip address line with properties:
  ${ext}.30/32 broadcast - scope host
 
  Correct as usual. However, the existing config_foo isn't going anyway
  anytime soon, so your power user config still works.
  However, it will be moving to the right place
  ifconfig_eth0
  ip_addr_eth0

 Looks like some documentation could be useful.

documentation is a requirement, but not everyone reads it.  existing configs 
have to keep working and warning on their use is much smoother/easier on 
everyone.
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Prioritising contact information in metadata.xml

2008-04-24 Thread Robin H. Johnson
On Thu, Apr 24, 2008 at 10:05:35PM +0200, Jeroen Roovers wrote:
 All in all I guess we need to make the rules up as we go and decide
 policy later. I suggest the first herd/address in the list should be
 the primary contact. If you don't agree with that, please consult
 metadata.xml for the package or reassign to bug-wranglers with an
 explanation (and perhaps a promise to quickly change metadata.xml. :)
Review the posts I made on the list last year about how to do assignment
in a sane fashion. I'll link them tonight when I'm back from the party
I'm hitting up.

They do describe all the cases that people came up with, including where
herds are too-specific or too broad.

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpuPH8JfNdXh.pgp
Description: PGP signature


Re: [gentoo-dev] Prioritising contact information in metadata.xml

2008-04-24 Thread Ulrich Mueller
 On Thu, 24 Apr 2008, Luis Francisco Araujo wrote:

 | One other thing is that it is sometimes difficult to figure out to
 | whom a bug should be assigned, because metadata.xml for many packages
 | simply isn't clear. If you list a few developers as well as a herd,
 | does that mean you want bugs assigned to the herd or to a single
 | developer who happens to be in that list? Some packages list several
 | herds in metadata.xml. Bugs can be assigned to just one address

 I'd say that in the case of a herd listed , the bug should be sent
 there.

A common case is a herd plus a specific maintainer, and I think then
it should be assigned to the maintainer, with a CC to the herd's team.

 If it doesn't specify a herd but several developers, sending the bug
 to any or all of them should be the rule.

In this case, it should be assigned to the first developer listed, and
all others in CC.

Ulrich
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Prioritising contact information in metadata.xml

2008-04-24 Thread Luis Francisco Araujo

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ulrich Mueller wrote:
| On Thu, 24 Apr 2008, Luis Francisco Araujo wrote:
|
| | One other thing is that it is sometimes difficult to figure out to
| | whom a bug should be assigned, because metadata.xml for many packages
| | simply isn't clear. If you list a few developers as well as a herd,
| | does that mean you want bugs assigned to the herd or to a single
| | developer who happens to be in that list? Some packages list several
| | herds in metadata.xml. Bugs can be assigned to just one address
|
| I'd say that in the case of a herd listed , the bug should be sent
| there.
|
| A common case is a herd plus a specific maintainer, and I think then
| it should be assigned to the maintainer, with a CC to the herd's team.
|
| If it doesn't specify a herd but several developers, sending the bug
| to any or all of them should be the rule.
|
| In this case, it should be assigned to the first developer listed, and
| all others in CC.
|

If this is the case, I think this should be stated somewhere in the docs
, since the order of listed maintainers don't have any priority, and I
personally would prefer to keep it so.


- --

Luis F. Araujo araujo at gentoo.org
Gentoo Linux

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkgRUVIACgkQNir3WYj9aLoEjQCeIvFaInENgCOhz65K9CaywFa4
C7gAnjjQAT82gerNwWmModYBVEpVHBrF
=V6VD
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list