[gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Steve Long
Donnie Berkholz wrote:
 Ciaran McCreesh wrote:
 What, you really think that Donnie doesn't know how the X licence
 handling situation breaks GLEP 23? Just how exactly is ACCEPT_LICENSE
 usable when you have this?
 
 [ cropped groups of similar license combinations ]
 
 Pretty usable, when you consider that it specifies groups. Throw all
 that stuff into an MIT group and you're good to go.
 
Ciaran McCreesh wrote:
 On Mon, 20 Nov 2006 02:56:18 -0800 Donnie Berkholz
 [EMAIL PROTECTED] wrote:
 | But I guess you don't think that's good enough for some reason. Since
 | you've already done the work to analyze the various groups, why don't
 | you finish it by figuring out the applicable licenses, and whether
 | new ones need to get added, and send a patch out?
 
 All things considered, I've little inclination to do your job for
 you... QA and not screwing over Gentoo users is your responsibility, not
 mine.
 
Ciaran: does the group stuff Donnie mentioned above fix this? Secondly, how
difficult would it be for you to do what he asked? I know it's not your
responsibility, I just want to know whether you can do it fairly easily.


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Herds, take your marks...get set...take stuff!

2006-12-01 Thread Alec Warner
If you look at gpnl[1] you will see a list of packages with NO 
maintainer and NO herd.  If you are a dev and are interested in a 
package please take it.  For herds, you may wish to glance around the 
categories and pick up some packages that you use/are useful/are in your 
herd.


For users, if you see something you use, you may become a 
proxy-maintainer for it.  I'm going to try and improve treecleaners in 
that regard over the next few months.


[1] http://spaceparanoids.org/gentoo/gpnl/qa.php?q=no-herd-maintainer
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Monthly Gentoo Council Reminder for December

2006-12-01 Thread Mike Frysinger
This is your monthly friendly reminder !  Same bat time (typically the
2nd Thursday at 2000 UTC), same bat channel (#gentoo-council @
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Versioning the tree

2006-12-01 Thread Duncan
Steve Long [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on  Fri, 01 Dec 2006 07:23:09
+:

 Excellent; pkgcore really sounds great- is there any possibility that it'll
 become the new portage?

Possibility, yes.  It's not certain, as there are multiple contenders
(paludis is the other), and it will be some time, in any case.

The current problem is that there's no standard definition for what
constitutes an acceptable ebuild, beyond the basic gentoo dev guidelines.
The de facto definition is whatever works with versions of portage
currently in the tree (or just barely removed), but that presents many
difficulties, including both slow upgrades since backward compatibility
must be maintained for longer even when the former functionality is
considered b0rken, and questions of what's broken, the package manager or
the ebuild, when something fails to work as expected.

Thus, all three package managers, the current portage solution, and paludis
and pkgcore as well, are currently under slower development than they might
otherwise be, while interested parties attempt to hash out a working
standard definition of what actually constitutes a proper ebuild, and
what helper functions said ebuild can in fact depend upon the package
manager to make available.  Once that's decided and approved, the playing
field upon which the merits of the next generation package managers can be
judged will be much fairer for all.  Of course, with that defined, portage
itself will be freer to progress at speed as well, and it may be that it
will remain the default approved solution for quite some time.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Ciaran McCreesh
On Fri, 01 Dec 2006 08:05:49 + Steve Long
[EMAIL PROTECTED] wrote:
| Ciaran: does the group stuff Donnie mentioned above fix this?

No. That's a massive abuse of groups. If people wanted to just accept
any licence necessary to install a particular package, they'd disable
licence filtering. The purpose of groups is to allow people to quickly
select licences that have been approved by various organisations that
have lawyers checking this kind of thing.

| Secondly, how difficult would it be for you to do what he asked? I
| know it's not your responsibility, I just want to know whether you
| can do it fairly easily.

It's a couple of hours work, and it requires tree access...

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13



signature.asc
Description: PGP signature


Re: [gentoo-dev] Herds, take your marks...get set...take stuff!

2006-12-01 Thread Michael Cummings
On Fri, 2006-12-01 at 05:15 -0500, Alec Warner wrote:
 [1] http://spaceparanoids.org/gentoo/gpnl/qa.php?q=no-herd-maintainer

If someone takes adocman, would you be willing to move it out of
dev-perl? (since it isn't a module)
-- 

-o()o--
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-o()o--



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


Re: [gentoo-dev] Treecleaneres

2006-12-01 Thread Michael Cummings
On Thu, 2006-11-30 at 00:59 -0500, Alec Warner wrote:
 In the meantime, please don't remove stuff.

Just to be a pain - you're referring only to treecleaner removals,
right?
-- 

-o()o--
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-o()o--



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


Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Brian Harring
On Fri, Dec 01, 2006 at 12:27:39PM +, Ciaran McCreesh wrote:
 On Fri, 01 Dec 2006 08:05:49 + Steve Long
 | Secondly, how difficult would it be for you to do what he asked? I
 | know it's not your responsibility, I just want to know whether you
 | can do it fairly easily.
 
 It's a couple of hours work, and it requires tree access...

anoncvs is available, just split a patch (tree wide changes could 
stand reviewing anyways).

~harring


pgpUUCjGzJczd.pgp
Description: PGP signature


Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Ciaran McCreesh
On Fri, 1 Dec 2006 04:37:44 -0800 Brian Harring [EMAIL PROTECTED]
wrote:
| On Fri, Dec 01, 2006 at 12:27:39PM +, Ciaran McCreesh wrote:
|  On Fri, 01 Dec 2006 08:05:49 + Steve Long
|  | Secondly, how difficult would it be for you to do what he asked? I
|  | know it's not your responsibility, I just want to know whether you
|  | can do it fairly easily.
|  
|  It's a couple of hours work, and it requires tree access...
| 
| anoncvs is available, just split a patch (tree wide changes could 
| stand reviewing anyways).

Yeah, because a tree-wide patch against a changing tree is really
practical.

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13



signature.asc
Description: PGP signature


[gentoo-dev] net-firewall/ipp2p maintainer needed

2006-12-01 Thread Jakub Moc

net-firewall/ipp2p ebuild is outdated and useless w/ 2.6.17+ kernels
(Bug 141700). It needs a bump to 0.8.2 and some active maintainer,
eradicator apparently doesn't care.

Please, see https://bugs.gentoo.org/show_bug.cgi?id=141700 if you are
interested in maintaining this.

Thanks.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Add ALSA_CARDS to USE_EXPAND

2006-12-01 Thread Diego 'Flameeyes' Pettenò
On Friday 01 December 2006 08:25, Petteri Räty wrote:
 It should give you what the emerge -pv line says. If it says nothing is
 enabled then, it should not give you everything. This is because other
 USE_EXPANDed stuff works this way.
Err, LINGUAS does not work this way for smaller packages (you ask nothing you 
get everything to be safe), and last I knew also INPUT_DRIVERS had that...

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpIasHgH4iLM.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Add ALSA_CARDS to USE_EXPAND

2006-12-01 Thread Ciaran McCreesh
On Fri, 1 Dec 2006 13:55:15 +0100 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| On Friday 01 December 2006 08:25, Petteri Räty wrote:
|  It should give you what the emerge -pv line says. If it says
|  nothing is enabled then, it should not give you everything. This is
|  because other USE_EXPANDed stuff works this way.
|
| Err, LINGUAS does not work this way for smaller packages (you ask
| nothing you get everything to be safe), and last I knew also
| INPUT_DRIVERS had that...

That's not really a reason not to do it for ALSA_CARDS, since it's so
easy in this particular case...

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13



signature.asc
Description: PGP signature


[gentoo-dev] app-admin/webmin needs a maintainer

2006-12-01 Thread Jakub Moc
Sune Kloppenborg Jeppesen napsal(a):
 the maintainer of app-admin/{webmin|usermin} eradicator is not responding to 
 bugmail and the packages have an open security bug.

In fact, webmin has a bunch of open bugs completely unanswered by the
maintainer for months. If anyone is interested in taking over this
package, please see the following bugs:

https://bugs.gentoo.org/show_bug.cgi?id=130336
https://bugs.gentoo.org/show_bug.cgi?id=142293
https://bugs.gentoo.org/show_bug.cgi?id=144644
https://bugs.gentoo.org/show_bug.cgi?id=150569

Thanks.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Add ALSA_CARDS to USE_EXPAND

2006-12-01 Thread Diego 'Flameeyes' Pettenò
On Friday 01 December 2006 14:01, Ciaran McCreesh wrote:
 That's not really a reason not to do it for ALSA_CARDS, since it's so
 easy in this particular case...
Uh, no.
Because the cards supported changes from release to release.

Although yes from one side it's easy to provide some more or less sane 
defaults, I'd rather stick with -* representing all cards.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpHn2Ay5qcDE.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Add ALSA_CARDS to USE_EXPAND

2006-12-01 Thread Diego 'Flameeyes' Pettenò
On Thursday 30 November 2006 22:40, Marius Mauch wrote:
 Not if you take care of providing the proper defaults in
 make.defaults (the sample above should not be the default).
Okay, let's get with a non-complete default, it would probably also help as 
you won't need PNP support on x86 and amd64 kernels by default...

For x86/amd64, I think this would cover a good part of users, but I'm open for 
better suggestion from arch teams:

ali5451 atiixp atiixp-modem cmipci emu10k1 emu10k1x ens1370 ens1371 fm801 
hda-intel intel8x0 intel8x0m maestro3 mpu401 usb-audio via82xx via82xx-modem

For PPC, at least the following for Apple platforms, if someone has 
suggestions for other PPC non-Apple platforms they are welcome

aoa aoa-fabric-layout aoa-onyx aoa-soundbus aoa-soundbus-i2s aoa-tas 
aoa-toonie powermac

For SPARC, I'd say at lesat the following by their name, but also here I'd 
leave to the arch team to provide suggestions

sun-amd7930 sun-cs4231 sun-dbri

other arches, please advise.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgphTRlYuRCni.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: Versioning the tree

2006-12-01 Thread Andrew Gaffney

Steve Long wrote:

There'll always be GLSA's to respond to.  That's another issue that
needs to be handled w/ a slow-moving tree.  Are you going to restrict
changes in the slow-moving tree only to changes against a GLSA?

That's what we've said.


I don't have a problem with this at all. The slow-moving tree isn't; it's a
release tree. The only question I have, which Stuart also mentioned, is
whether all security updates go thru the GLSA process.


Are you asking if all security updates that are done to the release will have 
gone through the GLSA process? I'd say the answer is yes, since the only updates 
that will go in the release tree are security updates from GLSAs :P


--
Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/
Gentoo Linux Developer   Installer Project
Today's lesson in political correctness:  Go asphyxiate on a phallus
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Brian Harring
On Fri, Dec 01, 2006 at 12:43:18PM +, Ciaran McCreesh wrote:
 On Fri, 1 Dec 2006 04:37:44 -0800 Brian Harring [EMAIL PROTECTED]
 wrote:
 | On Fri, Dec 01, 2006 at 12:27:39PM +, Ciaran McCreesh wrote:
 |  On Fri, 01 Dec 2006 08:05:49 + Steve Long
 |  | Secondly, how difficult would it be for you to do what he asked? I
 |  | know it's not your responsibility, I just want to know whether you
 |  | can do it fairly easily.
 |  
 |  It's a couple of hours work, and it requires tree access...
 | 
 | anoncvs is available, just split a patch (tree wide changes could 
 | stand reviewing anyways).
 
 Yeah, because a tree-wide patch against a changing tree is really
 practical.

Your changes will be fairly limited; pretty much tweaking LICENSE 
vars, mangling/adding to license/.  Yes, the tree changes, but it 
doesn't change fast enough for such a patch to be instantly worthless 
(nor worthless in a few weeks, albeit a bit dated).

Such a change *should* have review anyways, since LICENSE isn't 
something that should be arbitrarily screwed with.

Keep in mind that someone else is going to have to handle the patch 
anyways, so it's out of your hands at that point; let them worry about 
how to handle it, meanwhile you're after the change so throw the 
delta their way.

Donnie already stated he'd take a patch, so throw the patch his 
direction if you want things changed.

~harring


pgpLXmfgrUl8v.pgp
Description: PGP signature


Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Ciaran McCreesh
On Fri, 1 Dec 2006 05:29:22 -0800 Brian Harring [EMAIL PROTECTED]
wrote:
| Donnie already stated he'd take a patch, so throw the patch his 
| direction if you want things changed.

If you don't want it to be broken, fix it yourself is hardly a viable
QA policy...

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13



signature.asc
Description: PGP signature


[gentoo-dev] sys-fs/evms needs a maintainer

2006-12-01 Thread Jakub Moc
sys-fs/evms is broken with 2.6.17+ kernels [1], has a couple of other
bugs open, like linking against wrong glib version [2], or ocfs2-tools
issues [3] and unresponsive maintainer.

[1] https://bugs.gentoo.org/show_bug.cgi?id=154924
[2] https://bugs.gentoo.org/show_bug.cgi?id=147281
[3] https://bugs.gentoo.org/show_bug.cgi?id=147276

If you are interested in fixing this package, please see the above bugs.

Thanks.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Re: Re: Versioning the tree

2006-12-01 Thread Chris Gianelloni
On Fri, 2006-12-01 at 07:23 +, Steve Long wrote:
  Well count me in as a volunteer to help set this up and maintain an x86
  release. I'm a pretty good coder if that helps.
  
  There wouldn't be an x86 release or anything.  It would be the whole
  thing.  All or nothing.
  
 I hear you- it's the tree that's being released. I guess x86 is the most
 common architecture anyway, so testers for it aren't gonna be hard to find.

Actually, it depends on what you're testing.  For x86, there's much more
hardware to test, so there's always some problem which couldn't be
tested for before-hand.  When it comes to software, it's usually easier
to test for, so it depends on the package quite a bit.

Now, we can definitely use help in testing the snapshot.  We're going to
be announcing a new round of Release Testers for 2007.0 once we get
ramped up into the release cycle.  I am going to be working with the
rest of the Release Engineering team to try to come up with some testing
methodologies for people to use when testing, as well as a standard
report for successes and failures.

  Wrt security updates, is it possible to tie into GLSAs so that we could
  automate updating packages that need it? By updating I mean adding the
  ebuilds and any dependencies (or dependants that might require updating.)
  
  What were you expecting that we would do?
  
 Lol; exactly that. I guess I was asking how difficult it is to automate the
 process.
 
 Although Andrew wrote that he didn't think it was necessarily the best idea.
 Why is that?

Well, these sort of things are hard to automate, for one.  Second, if
we're trying to produce a quality product, we want to have some checks
in place prior to updates hitting the world.  Having a set of human eyes
helps.

  or a vulnerable package's dependencies
  
 Sure, if the update meant the dependencies needed updating too. Again,
 that'd need automating, so we're talking about checking the tree in both
 directions (dependencies and dependants in my terms, sorry if I'm using the
 words wrongly.)

Why does it need automating?  We generally don't get more than 10 or so
GLSA a week.  Even doing everything by hand, this would be a very
minimal workload to keep updated.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation


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


[gentoo-dev] udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Sven Köhler
Hi,

when does udev load all the modules and does coldplug?
Is it happening before /etc/init.d/modules?

If yes, than i would like to shout: are you crazy?

Well, until udev became stable, /etc/modules.autoload.d/kernel-2.? was a
good place, to load modules in a specific order - before coldplug.

Unfortunatly, the order of loading of modules defines the ordner of the
network-interfaces (if you different types of network cards).

So can you imagine, loading the modules before udev's coldplug happens?


Greetings,
  Sven



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Re: Versioning the tree

2006-12-01 Thread Chris Gianelloni
On Fri, 2006-12-01 at 07:22 -0600, Andrew Gaffney wrote:
 Steve Long wrote:
  There'll always be GLSA's to respond to.  That's another issue that
  needs to be handled w/ a slow-moving tree.  Are you going to restrict
  changes in the slow-moving tree only to changes against a GLSA?
  That's what we've said.
 
  I don't have a problem with this at all. The slow-moving tree isn't; it's a
  release tree. The only question I have, which Stuart also mentioned, is
  whether all security updates go thru the GLSA process.
 
 Are you asking if all security updates that are done to the release will have 
 gone through the GLSA process? I'd say the answer is yes, since the only 
 updates 
 that will go in the release tree are security updates from GLSAs :P

Actually, we would have to review the process, since not everything that
gets a security bug ends up with a GLSA.  My current loose rule is that
if it deserves a GLSA, then it deserves and update, but I don't know the
exact criteria the security team uses to decide if something warrants a
GLSA or not.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation


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


Re: [gentoo-dev] [RFC] Add ALSA_CARDS to USE_EXPAND

2006-12-01 Thread Luca Barbato
Diego 'Flameeyes' Pettenò wrote:
 
 aoa aoa-fabric-layout aoa-onyx aoa-soundbus aoa-soundbus-i2s aoa-tas 
 aoa-toonie powermac
 

add usb-audio

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Neil Bothwick
On Fri, 01 Dec 2006 15:40:33 +0100, Sven Köhler wrote:

 Unfortunatly, the order of loading of modules defines the ordner of the
 network-interfaces (if you different types of network cards).

You can use udev to name the interfaces, which is far less kludgy than
relying on the order in which modules are loaded.


-- 
Neil Bothwick

There are no stupid questions, just too many inquisitive idiots.


signature.asc
Description: PGP signature


Re: [gentoo-dev] udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Stephen Bennett
On Fri, 01 Dec 2006 15:40:33 +0100
Sven Köhler [EMAIL PROTECTED] wrote:

 Unfortunatly, the order of loading of modules defines the ordner of
 the network-interfaces (if you different types of network cards).

This is what udev's interface renaming capability is for. Define names
for your interfaces according to their MAC address, for example, and
all is good. It's also more reliable than relying on the order of
module loading to get it right.

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Sven Köhler
 Unfortunatly, the order of loading of modules defines the ordner of
 the network-interfaces (if you different types of network cards).
 
 This is what udev's interface renaming capability is for. Define names
 for your interfaces according to their MAC address, for example, and
 all is good. It's also more reliable than relying on the order of
 module loading to get it right.

OK, Damn. Here i have a lack of knowledge.

So what do i have to do, to configure udev that way?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Jean-François Gagnon Laporte

On 12/1/06, Sven Köhler [EMAIL PROTECTED] wrote:

 Unfortunatly, the order of loading of modules defines the ordner of
 the network-interfaces (if you different types of network cards).

 This is what udev's interface renaming capability is for. Define names
 for your interfaces according to their MAC address, for example, and
 all is good. It's also more reliable than relying on the order of
 module loading to get it right.

OK, Damn. Here i have a lack of knowledge.

So what do i have to do, to configure udev that way?



This address is a good place to start.

http://www.reactivated.net/writing_udev_rules.html#example-netif

Regards,

JF

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Greg KH
On Fri, Dec 01, 2006 at 03:40:33PM +0100, Sven K?hler wrote:
 Hi,
 
 when does udev load all the modules and does coldplug?

When it first runs.

 Is it happening before /etc/init.d/modules?

Yes.

 If yes, than i would like to shout: are you crazy?

Of course, I wouldn't be doing this work if I wasn't :)

 Well, until udev became stable, /etc/modules.autoload.d/kernel-2.? was a
 good place, to load modules in a specific order - before coldplug.
 
 Unfortunatly, the order of loading of modules defines the ordner of the
 network-interfaces (if you different types of network cards).

If you rely on the specific loading order of modules, you were the crazy
one in the first place :)

As others have said, look at using udev to name your network devices in
a persistant manner, it's the best solution.

Or you can just blacklist the modules, and then load them yourself in
your modules startup location.

The problem with doing this is the modules.d stuff is still broken for
blacklisting, it will only work on the first reboot of the system,
there's an open bug for this issue :(

Hope this helps,

greg k-h
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Herds, take your marks...get set...take stuff!

2006-12-01 Thread Philip Webb
061201 Alec Warner wrote:
 If you look at 
   http://spaceparanoids.org/gentoo/gpnl/qa.php?q=no-herd-maintainer
 you will see a list of packages with NO maintainer and NO herd.
 For users, if you see something you use,
 you may become a proxy-maintainer for it.

A quick run thro' the pkgs listed reveals  5  which seem important :

  gle -- for Xscreensaver
  libwmf -- for Imagemagick
  libidn -- for Mutt Curl Kdelibs
  openmotif + motif-config -- for Gvim

There are  6  more which are surely useful,  3  installed here :

  e3 -- excellent tiny editor (installed)
  ckermit -- powerful tool for accessing remote machines
 (I have it installed in  /usr/local ,
 not having realised there was a Gentoo pkg)
  sc -- spreadsheet in a terminal, ie it doesn't need X (IIRC)
  nedit -- powerful pgmers' editor popular in some places
  yudit -- Unicode editor (installed)
  expect -- useful tool for automating interactive tasks

Perhaps you should tell users briefly what proxy-maintenance involves.

PS another thread mentioned Cgoban : this is very useful for Go players.

-- 
,,
SUPPORT ___//___,  Philip Webb : [EMAIL PROTECTED]
ELECTRIC   /] [] [] [] [] []|  Centre for Urban  Community Studies
TRANSIT`-O--O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Herds, take your marks...get set...take stuff!

2006-12-01 Thread James Ausmus

On 12/1/06, Philip Webb [EMAIL PROTECTED] wrote:

061201 Alec Warner wrote:
 If you look at
   http://spaceparanoids.org/gentoo/gpnl/qa.php?q=no-herd-maintainer
 you will see a list of packages with NO maintainer and NO herd.
 For users, if you see something you use,
 you may become a proxy-maintainer for it.

snipe

Perhaps you should tell users briefly what proxy-maintenance involves.



So depending on what exactly is involved with proxy-maintenance, I
could be interested in taking care of some or (up to) all of the
following:

x11-drivers/synaptics
dev-libs/libaio
dev-lang/fpc-source
app-office/mdbtools
app-laptop/configure-thinkpad
app-arch/rar


-James (Just a User (tm)) ;)
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Herds, take your marks...get set...take stuff!

2006-12-01 Thread Donnie Berkholz

James Ausmus wrote:

x11-drivers/synaptics


This should be x11-drivers, but somebody misspelled it with a capital X. 
Same goes for other stuff in this category and x11-base as well as ttmkfdir.


Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Herds, take your marks...get set...take stuff!

2006-12-01 Thread Donnie Berkholz

Donnie Berkholz wrote:

James Ausmus wrote:

x11-drivers/synaptics


This should be x11-drivers, but somebody misspelled it with a capital X. 
Same goes for other stuff in this category and x11-base as well as 
ttmkfdir.


With the exception of xdirectfb. Someone please take that if you want 
it. (Maybe Josh does?)


Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] net-misc/openswan needs a maintainer

2006-12-01 Thread Jakub Moc
This thing has been neglected for ages, needs a version bump and has
lots of stale open bugs:

http://bugs.gentoo.org/show_bug.cgi?id=62970
http://bugs.gentoo.org/show_bug.cgi?id=105272
http://bugs.gentoo.org/show_bug.cgi?id=124272
http://bugs.gentoo.org/show_bug.cgi?id=127288
http://bugs.gentoo.org/show_bug.cgi?id=127314
http://bugs.gentoo.org/show_bug.cgi?id=134484
http://bugs.gentoo.org/show_bug.cgi?id=137737
http://bugs.gentoo.org/show_bug.cgi?id=147116

If you are using IPSec and would like to make it working again on
Gentoo, please step up and see the above bugs.

Thanks.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Herds, take your marks...get set...take stuff!

2006-12-01 Thread Harald van Dijk
On Fri, Dec 01, 2006 at 10:48:03AM -0800, James Ausmus wrote:
 On 12/1/06, Philip Webb [EMAIL PROTECTED] wrote:
 061201 Alec Warner wrote:
  If you look at
http://spaceparanoids.org/gentoo/gpnl/qa.php?q=no-herd-maintainer
  you will see a list of packages with NO maintainer and NO herd.
  For users, if you see something you use,
  you may become a proxy-maintainer for it.
 snipe
 Perhaps you should tell users briefly what proxy-maintenance involves.
 
 
 So depending on what exactly is involved with proxy-maintenance, I
 could be interested in taking care of some or (up to) all of the
 following:
 
 dev-lang/fpc-source

This should just go away. It's been replaced by dev-lang/fpc with the
'source' USE flag. I'll see if I can get rid of whatever still needs it
over the weekend, and fpc-source itself after that.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Treecleaneres

2006-12-01 Thread Alec Warner

Michael Cummings wrote:

On Thu, 2006-11-30 at 00:59 -0500, Alec Warner wrote:

In the meantime, please don't remove stuff.


Just to be a pain - you're referring only to treecleaner removals,
right?


Of course ;)
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Re: Versioning the tree

2006-12-01 Thread Steve Long
Chris Gianelloni wrote:

 On Fri, 2006-12-01 at 07:22 -0600, Andrew Gaffney wrote:
 Steve Long wrote:
  The only question I have, which Stuart also
  mentioned, is whether all security updates go thru the GLSA process.
 
 Are you asking if all security updates that are done to the release will
 have gone through the GLSA process? I'd say the answer is yes, since the
 only updates that will go in the release tree are security updates from
 GLSAs :P
 
 Actually, we would have to review the process, since not everything that
 gets a security bug ends up with a GLSA.  My current loose rule is that
 if it deserves a GLSA, then it deserves and update, but I don't know the
 exact criteria the security team uses to decide if something warrants a
 GLSA or not.
 
Well, I'm guessing that the bugs are entered and reviewed as security bugs
on some system or another. If so, we can just get the basic list automated
to tie into a script collection.

Who would know what criteria the security people use?


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Re: Re: Versioning the tree

2006-12-01 Thread Steve Long
Chris Gianelloni wrote:

 Now, we can definitely use help in testing the snapshot.  We're going to
 be announcing a new round of Release Testers for 2007.0 once we get
 ramped up into the release cycle.  I am going to be working with the
 rest of the Release Engineering team to try to come up with some testing
 methodologies for people to use when testing, as well as a standard
 report for successes and failures.
 
Well I volunteer for one. I'm guessing you can get someone to post to the
forums as and when you're ready to get more volunteers ;)

  Wrt security updates, is it possible to tie into GLSAs so that we
  could automate updating packages that need it? By updating I mean
  adding the ebuilds and any dependencies (or dependants that might
  require updating.)
  
  What were you expecting that we would do?
  
 Lol; exactly that. I guess I was asking how difficult it is to automate
 the process.
 
 Although Andrew wrote that he didn't think it was necessarily the best
 idea. Why is that?
 
 Well, these sort of things are hard to automate, for one.  Second, if
 we're trying to produce a quality product, we want to have some checks
 in place prior to updates hitting the world.  Having a set of human eyes
 helps.
 
I totally understand the process point in terms of QA. As for automation,
isn't there an existing system used to process security bugs?

  or a vulnerable package's dependencies
  
 Sure, if the update meant the dependencies needed updating too. Again,
 that'd need automating, so we're talking about checking the tree in both
 directions (dependencies and dependants in my terms, sorry if I'm using
 the words wrongly.)
 
 Why does it need automating?  We generally don't get more than 10 or so
 GLSA a week.  Even doing everything by hand, this would be a very
 minimal workload to keep updated.
 
I didn't know the frequency of GLSAs. According to the other thread, not all
security bugs warrant an advisory. In any event, I don't see why we
shouldn't automate it while we can to save us the tedious workload later.


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Sven Köhler
 As others have said, look at using udev to name your network devices in
 a persistant manner, it's the best solution.

Yes, i agree. But i have thought about it, and i wonder, if it's going
to work if:

1. udev loads the modules which results in a natural order: saying
eth0 and eth1 are used.
2. my udev-rules say, that the network-card which has the natural name
eth1 has to be called eth0

Will udev rename the card eth1 to eth0 and the card eth0 to eth1?

Maybe udev also loads the modules in a way, so that the cards don't get
any natural name by the kernel and instead, the udev-daemon has the
full power to assign the names.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Versioning the tree

2006-12-01 Thread Steve Long
Duncan wrote:

 Steve Long [EMAIL PROTECTED] posted
 [EMAIL PROTECTED], excerpted below, on  Fri, 01 Dec 2006 07:23:09
 +:
 
 Excellent; pkgcore really sounds great- is there any possibility that
 it'll become the new portage?
 
 Possibility, yes.  It's not certain, as there are multiple contenders
 (paludis is the other), and it will be some time, in any case.
 
 The current problem is that there's no standard definition for what
 constitutes an acceptable ebuild, beyond the basic gentoo dev guidelines.
 The de facto definition is whatever works with versions of portage
 currently in the tree (or just barely removed), but that presents many
 difficulties, including both slow upgrades since backward compatibility
 must be maintained for longer even when the former functionality is
 considered b0rken, and questions of what's broken, the package manager or
 the ebuild, when something fails to work as expected.
 
I'd vote for the defacto with strict backward compatibility, and perhaps a
directive/ alias for newer scripts. If something really doesn't work and
someone cares (bug reporter), ask them to update the ebuild if needed. So
long as good docs are in place (the dev handbook I've seen somewhere is an
example) for the update process, that's acceptable in my book.

 Thus, all three package managers, the current portage solution, and
 paludis and pkgcore as well, are currently under slower development than
 they might otherwise be, while interested parties attempt to hash out a
 working standard definition of what actually constitutes a proper ebuild,
 and what helper functions said ebuild can in fact depend upon the package
 manager to make available.  Once that's decided and approved, the playing
 field upon which the merits of the next generation package managers can be
 judged will be much fairer for all.  Of course, with that defined, portage
 itself will be freer to progress at speed as well, and it may be that it
 will remain the default approved solution for quite some time.
 
As for helper functions, I'd guess a union of all available ;)


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Steve Long
Ciaran McCreesh wrote:

 On Fri, 1 Dec 2006 05:29:22 -0800 Brian Harring [EMAIL PROTECTED]
 wrote:
 | Donnie already stated he'd take a patch, so throw the patch his
 | direction if you want things changed.
 
 If you don't want it to be broken, fix it yourself is hardly a viable
 QA policy...
 
No, but you are an ex-dev so it hardly counts as asking a newbie to do it.

As for your other point:
 | Ciaran: does the group stuff Donnie mentioned above fix this?
 
 No. That's a massive abuse of groups. If people wanted to just accept
 any licence necessary to install a particular package, they'd disable
 licence filtering. The purpose of groups is to allow people to quickly
 select licences that have been approved by various organisations that
 have lawyers checking this kind of thing.

Is there any consensus on that?


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Richard Fish

On 12/1/06, Sven Köhler [EMAIL PROTECTED] wrote:

Will udev rename the card eth1 to eth0 and the card eth0 to eth1?


Yes.

For this, I'd recommend running /lib/udev/write_net_rules
all_interfaces and then edit
/etc/udev/rules.d/70-persistent-net.rules to set the names like you
want.

I'd also recommend moving this thread to gentoo-user, since this
really doesn't have much to do with gentoo development AFAICS.

-Richard

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Greg KH
On Fri, Dec 01, 2006 at 09:24:33PM +0100, Sven K?hler wrote:
  As others have said, look at using udev to name your network devices in
  a persistant manner, it's the best solution.
 
 Yes, i agree. But i have thought about it, and i wonder, if it's going
 to work if:
 
 1. udev loads the modules which results in a natural order: saying
 eth0 and eth1 are used.
 2. my udev-rules say, that the network-card which has the natural name
 eth1 has to be called eth0
 
 Will udev rename the card eth1 to eth0 and the card eth0 to eth1?

Have you tried it, you might be supprised :)

Or just pick a better name, there are nicer ones other than 'eth0' and
'eth1'.  Some distros refuse to use those old names anymore...

 Maybe udev also loads the modules in a way, so that the cards don't get
 any natural name by the kernel and instead, the udev-daemon has the
 full power to assign the names.

Nope, udev will not guarantee any order that the modules are loaded in,
sorry.  Again, you should never rely on that ordering anyway.

thanks,

greg k-h
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Herds, take your marks...get set...take stuff!

2006-12-01 Thread Joshua Baergen
Donnie Berkholz wrote:
 Donnie Berkholz wrote:
 This should be x11-drivers, but somebody misspelled it with a capital
 X. Same goes for other stuff in this category and x11-base as well as
 ttmkfdir.
 
 With the exception of xdirectfb. Someone please take that if you want
 it. (Maybe Josh does?)
 
 Thanks,
 Donnie

I do not :)  I was only fixing bugs until we disowned it, and I'm not
sure if it's even feasible to maintain against modular X.

Josh



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: net-firewall/ipp2p maintainer needed

2006-12-01 Thread Steve Long
Jakub Moc wrote:

 
 net-firewall/ipp2p ebuild is outdated and useless w/ 2.6.17+ kernels
 (Bug 141700). It needs a bump to 0.8.2 and some active maintainer,
 eradicator apparently doesn't care.
 
 Please, see https://bugs.gentoo.org/show_bug.cgi?id=141700 if you are
 interested in maintaining this.
 
Would it be possible for one of the users to take it? Saw another post
mentioning proxy maintainer for some other stuff, I don't know what that
allows. In any case some of the users on the forum posting to that bug
report http://forums.gentoo.org/viewtopic-p-3746348.html#3746348 seem to
have a lot of experience.
 

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] sys-fs/submount needs a maintainer

2006-12-01 Thread Daniel Drake

Hi,

submount is an external kernel module which provides automounting 
functionality. It is currently under kernel herd but nobody there has 
interest in this package. I have had to fix it repeatedly in order to 
compile with newer kernels, it's broken again for 2.6.19 and I've had 
enough. Upstream appears to be dead as well.


If nobody steps up within a week it will go in package.mask for removal 
3 weeks later.


Suitable replacements for this package include the in-kernel 
automounter, hal, ivman.


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



Re: [gentoo-portage-dev] [PATCH] keyword anti-match (foo/-foo) overrides other matches

2006-12-01 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Barkalow wrote:
 On Tue, 28 Nov 2006, Zac Medico wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Daniel Barkalow wrote:
 If the configuration has keywords foo bar, and a package has -foo
 bar, mask the package (masked by -bar keyword).

 This is the sensible behavior if we ever make use of listing multiple
 keywords in the configuration, which is currently implemented but not
 used for anything.
 Personally, I'd prefer not to support -foo or -* in the KEYWORDS of
 an ebuild.  For one thing, seems like it's trying to accomplish
 something similar to what package.mask is intended for. 
 
 It's documented in the Ebuild HOWTO (at least, -foo). And the current 
 state is sort of broken: if you manage to get -foo in your 
 ACCEPT_KEYWORDS, you can build a known-broken package, but you can never 
 build a package that doesn't have -foo/~foo/foo. So you can only build a 
 package if you know it doesn't work.
 
 I'd say, make it impossible to set -foo (or -*) in ACCEPT_KEYWORDS. People 
 who want to build -foo packages can use * (or ~*) in their 
 package.keywords, which actually gives you the latest version that's 
 stable somewhere (or testing somewhere).

Having -foo in ACCEPT_KEYWORDS is practically useless, and I think
that alone is probably enough to constrain peoples behavior.  Adding
 some code to explicitly prevent it seems redundant to me.

 With my patch, you'd additionally need -foo in package.keywords to build a 
 -foo package, but then it means don't worry about my foo keyword, which 
 is appropriate and really is the usual incremental stack thing.
 
 Incidently, I think with current trunk a package.keywords value of -x86 
 means use an ebuild if and only if it is broken on x86, meaning that if 
 a newer version actually works, users using the broken version won't 
 upgrade. I bet that's not really what people want.

The user can add -x86 x86 to package.keywords if they want to
accept both.

 Another problem is that is uses -foo and -* in completely different ways
 than they are used elsewhere in portage (for negation of values in
 an incremental stack).
 
 I think KEYWORDS (as opposed to ACCEPT_KEYWORDS) being thought of as an 
 incremental stack is sort of broken. (Not that it isn't done, but I think 
 that KEYWORDS in eclasses is just evil and generally wrong; check out 
 enlightenment.eclass and x11-wm/e/e-.ebuild for weird and wrong.)

Yeah, KEYWORDS are supposed be directly in the ebuild so that arch
teams have control over them for each individual ebuild.

 But maybe !foo would be more appropriate anyway for don't match if foo. 
 It might confuse people if what you do to unmask a !foo package is 
 -foo * (meaning hide my foo keyword, match anything that works), not 
 !foo. Although I think the real way of unmasking these things should be 
 to put a modified version in your overlay.

That would be really annoying if a user need to use an overlay just
to keyword an ebuild.  That's what package.keywords is for.

Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFcNzU/ejvha5XGaMRAmOkAKCSRGd+Gdwef1yRQ8OV/hA5K7yBZQCg2OW5
zEd2p2bT2kv5exGgxmUYZjg=
=uu5H
-END PGP SIGNATURE-
-- 
gentoo-portage-dev@gentoo.org mailing list