[gentoo-dev] Minor change in pkg-config behavior, starting with 0.28, late heads up for maintainers
This is from Fedora Devel Mailing List. I found it to be news worthy also for Gentoo maintainers. So here it is: snip Remi Collet Fedora at FamilleCollet.com Thu Mar 28 10:39:52 UTC 2013 Previous versions $ echo ==$(pkg-config --cflags-only-I openssl)== == == New version $ echo ==$(pkg-config --cflags-only-I openssl)== This space to empty string output can breaks some poorly written autoconf script. Remi. P.S.1: I hope it could helps some packager... avoid losing too much time on this... P.S.2: example of broken script http://git.php.net/?p=php-src.git;a=commitdiff;h=640e72ce91d8e591b92cd93c18d1bfe3befe3424 /snip
[gentoo-dev] Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
This is required for stabilizing new udev (bug #463614)
And required otherwise too as people are still confused from what I have
seen in forums
I hope this isn't too much of an hand holding
Will push it tomorrow'ish if noone complains (and fix grammar later too
if required)
Thanks for looking into it!
Title: The new default predictable network interface naming with udev
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2013-03-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-fs/udev-201
If you still have network interface renaming rules in /etc/udev/rules.d,
like 70-persistent-net.rules, you will need to modify or remove them.
If you choose to modify them, you will need to pick a free namespace (like
net* or internet*) that is not reserved by the kernel (like eth* or wlan*)
because in-place renaming has been deprecated[1].
You should also rename the file to something else, like 70-my-network.rules
to silence the deprecation warning coming from when you emerge udev.
This is old format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=eth0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=eth1
This is new format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=net0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=net1
With the new predictable network interface naming scheme which upstream enabled
by default you don't have to rename anymore because the names will be static
and not randomly rename when you, for example, upgrade the kernel. This can be
very important aspect, for example, security in mind.
If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a
symlink to /dev/null, the new names will be disabled and kernel will do
all the interface naming, which will be random.
The new names can also be disabled using net.ifnames=0 kernel option.
In normal new installation there is no files put in /etc/udev/rules.d and if
you haven't edited any files you have in there, you should most likely delete
(backup) them all out of the way.
You can find out using udevadm command what your interfaces will be called
before booting to make necessary changes, such as changing net.* symlinks
in /etc/init.d.
This is the example command:
# udevadm test-builtin net_id /sys/class/net/eth0 2 /dev/null
The output could be (and I'm only picking the most important line for this
example):
ID_NET_NAME_PATH=enp2s0f0
This would mean your eth0 will be called enp2s0f0 if there is no previously
mentioned files blocking the new names taking place in /etc/udev/rules.d.
This is documented more throughly at upstream wiki[2] which everyone should
read at least once.
This feature will also replace the functionality of sys-apps/biosdevname which
you should uninstall. However, you can still keep using sys-apps/biosdevname
if you want.
[1] http://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html
[2] http://www.freedesktop.org/wiki/Software/systemd/
PredictableNetworkInterfaceNames
Re: [gentoo-dev] Collecting items for EAPI 6
Dne Čt 28. března 2013 19:15:59, Michał Górny napsal(a): Hello, As discussed with ulm, I'd like to start a thread for collecting initial items for EAPI 6. Preferably items which are either almost ready or are easy to implement and are non-controversial. In other words, thing which are practically ready to get on the actual list. As usual, each item should have a corresponding 'Future EAPI' bug which blocks the tracker [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=future-eapi As it goes we have lafile removal scripts in eclass already and there seems to be no harm done to users anymore with by-default punting with new eapi. https://bugs.gentoo.org/show_bug.cgi?id57561 Patches array from base eclass to default as it is last thing in base eclass that has some relevant stuff. https://bugs.gentoo.org/show_bug.cgi?idF3692 Other than that I would like to see some improvements on binary packages (no bugs). Something like different binary pkgs for various IUSE (so they are not always rewritten)... so the tinderbox can get more usefull :-) Cheers Tom signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
Samuli Suominen posted on Fri, 29 Mar 2013 10:09:27 +0200 as excerpted: This feature will also replace the functionality of sys-apps/biosdevname which you should uninstall. However, you can still keep using sys-apps/biosdevname if you want. I'd suggest... This feature can optionally replace... can uninstall. IOW... s/will also/can optionally/ s/should/can/ It sounds less menacing than your suggested wording, making it clearer that it's an optional replacement and lessening the apparent conflict and possible confusion with the next sentence saying it can still be used if desired. I'd say that's a particularly good idea given the sensitivity around the all engulfing gray goo that systemd has seemed to many to have become. Given that upstream specifically designed this feature to cooperate with existing biosdevname installations, let's not unnecessarily poke that hornet's nest by implying otherwise, even if the next sentence /does/ basically say it's an optional change anyway. =:^/ -- 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
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 12:24, Duncan wrote:
Samuli Suominen posted on Fri, 29 Mar 2013 10:09:27 +0200 as excerpted:
This feature will also replace the functionality of sys-apps/biosdevname
which you should uninstall. However, you can still keep using
sys-apps/biosdevname if you want.
I'd suggest...
This feature can optionally replace... can uninstall.
IOW...
s/will also/can optionally/
s/should/can/
It sounds less menacing than your suggested wording, making it clearer
that it's an optional replacement and lessening the apparent conflict and
possible confusion with the next sentence saying it can still be used if
desired.
I'd say that's a particularly good idea given the sensitivity around the
all engulfing gray goo that systemd has seemed to many to have become.
Given that upstream specifically designed this feature to cooperate with
existing biosdevname installations, let's not unnecessarily poke that
hornet's nest by implying otherwise, even if the next sentence /does/
basically say it's an optional change anyway. =:^/
OK, new one attached, should be better
Title: The new default predictable network interface naming with udev
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2013-03-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-fs/udev-201
If you still have network interface renaming rules in /etc/udev/rules.d,
like 70-persistent-net.rules, you will need to modify or remove them.
If you choose to modify them, you will need to pick a free namespace (like
net* or internet*) that is not reserved by the kernel (like eth* or wlan*)
because in-place renaming has been deprecated[1].
You should also rename the file to something else, like 70-my-network.rules
to silence the deprecation warning coming from when you emerge udev.
This is old format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=eth0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=eth1
This is new format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=net0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=net1
With the new predictable network interface naming scheme which upstream enabled
by default you don't have to rename anymore because the names will be static
and not randomly rename when you, for example, upgrade the kernel. This can be
very important aspect, for example, security in mind.
If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a
symlink to /dev/null, the new names will be disabled and kernel will do
all the interface naming, which will be random.
The new names can also be disabled using net.ifnames=0 kernel option.
In normal new installation there is no files put in /etc/udev/rules.d and if
you haven't edited any files you have in there, you should most likely delete
(backup) them all out of the way.
You can find out using udevadm command what your interfaces will be called
before booting to make necessary changes, such as changing net.* symlinks
in /etc/init.d.
This is the example command:
# udevadm test-builtin net_id /sys/class/net/eth0 2 /dev/null
The output could be (and I'm only picking the most important line for this
example):
ID_NET_NAME_PATH=enp2s0f0
This would mean your eth0 will be called enp2s0f0 if there is no previously
mentioned files blocking the new names taking place in /etc/udev/rules.d.
This is documented more throughly at upstream wiki[2] which everyone should
read at least once.
This feature can also replace the functionality of sys-apps/biosdevname, but
you can still keep using it if you want.
[1] http://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html
[2] http://www.freedesktop.org/wiki/Software/systemd/
PredictableNetworkInterfaceNames
Re: [gentoo-dev] Collecting items for EAPI 6
El jue, 28-03-2013 a las 19:15 +0100, Michał Górny escribió: Hello, As discussed with ulm, I'd like to start a thread for collecting initial items for EAPI 6. Preferably items which are either almost ready or are easy to implement and are non-controversial. In other words, thing which are practically ready to get on the actual list. As usual, each item should have a corresponding 'Future EAPI' bug which blocks the tracker [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=future-eapi My propositions: a) for improving self-consistency of EAPI (high priority): - #463586: move get_libdir to EAPI (since it is used in econf). - #459692: split the doc-installation part of default_src_install (e.g. as einstalldocs). - #451938: provide a 'die' variant respecting 'nonfatal' (to implement custom helpers respecting 'nonfatal'). b) for improving ebuild eclass development: - #449862: tidy up IUSE checking. - #449806: support using DOCS to append to the standard document list. - #431340: allow bash-4.2 (may require additional policy restrictions). - #273101: explicit variable for no. of parallel jobs (rather than hacking MAKEOPTS). I would also add, if possible: https://bugs.gentoo.org/show_bug.cgi?id=449862 - Suggest to specify a way to query for values in IUSE
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 11:26, Samuli Suominen wrote: With the new predictable network interface naming scheme which upstream enabled by default you don't have to rename anymore because the names will be static and not randomly rename when you, for example, upgrade the kernel. This can be very important aspect, for example, security in mind. You do know this is false, right? The names are supposed to be predictable, not persistent. If you do happen to MOVE your network card because the new videocard you add to your system does not fit otherwise, the name _will_ change. If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a symlink to /dev/null, the new names will be disabled and kernel will do all the interface naming, which will be random. Avoid spreading FUD about naming being random. Thanks. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 12:46, Diego Elio Pettenò wrote: On 29/03/2013 11:26, Samuli Suominen wrote: With the new predictable network interface naming scheme which upstream enabled by default you don't have to rename anymore because the names will be static and not randomly rename when you, for example, upgrade the kernel. This can be very important aspect, for example, security in mind. You do know this is false, right? The names are supposed to be predictable, not persistent. If you do happen to MOVE your network card because the new videocard you add to your system does not fit otherwise, the name _will_ change. Not false, but configurable, and linked from the news item -- nobody stopping you from eg. using MAC addresses instead of PCI slots for defining the names, just like one would have renamed them using MAC with 70-persistent-net.rules If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a symlink to /dev/null, the new names will be disabled and kernel will do all the interface naming, which will be random. Avoid spreading FUD about naming being random. Thanks. Not FUD, but a fact, depends on the driver code (in kernel) if it'll change or not That's random enough as we can't force people to track kernel source tree and drivers code
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 11:50, Samuli Suominen wrote: Not false, but configurable, and linked from the news item -- nobody stopping you from eg. using MAC addresses instead of PCI slots for defining the names, just like one would have renamed them using MAC with 70-persistent-net.rules Which I usually do. But With the new predictable ... scheme ... the names will be static and not randomly rename ... is false. The name will be predictable before rebooting (maybe?) but it could very easily change randomly on udev update. Not FUD, but a fact, depends on the driver code (in kernel) if it'll change or not That's random enough as we can't force people to track kernel source tree and drivers code Hm hm. It's still FUD. If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. Whereas, with the new predictable scheme, if I move that card around, it will change name. Tell me which one is random, again? --- I'm not saying you shouldn't enable it (feel free to screw up user as much as you want, just don't complain if they don't like you), but since both kernel naming and predictable naming have their chance to change, don't spread FUD. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] net-misc/dibbler needs a new maintainer
Hi, I no longer have IPv6 so I don't use this package anymore. If someone is willing to maintain it please add yourself to metadata.xml. There are currently 2 open bugs [1][2]. If a user wants to help, contact proxy-maint_at_gentoo_dot_org[3] [1] https://bugs.gentoo.org/show_bug.cgi?id=439796 [2] https://bugs.gentoo.org/show_bug.cgi?id=461556 [3] http://www.gentoo.org/proj/en/qa/proxy-maintainers/ -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, 29 Mar 2013, Samuli Suominen wrote: Title: The new default predictable network interface naming with udev This is too long. GLEP 42 says: | Title: A short (maximum 44 characters) descriptive title. Also: | The text body should be wrapped at 72 characters. Ulrich
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 13:01, Diego Elio Pettenò wrote:
On 29/03/2013 11:50, Samuli Suominen wrote:
Not false, but configurable, and linked from the news item -- nobody
stopping you from eg. using MAC addresses instead of PCI slots for
defining the names, just like one would have renamed them using MAC with
70-persistent-net.rules
Which I usually do. But
With the new predictable ... scheme ... the names will be static and
not randomly rename ...
is false.
The name will be predictable before rebooting (maybe?) but it could very
easily change randomly on udev update.
Not FUD, but a fact, depends on the driver code (in kernel) if it'll
change or not
That's random enough as we can't force people to track kernel source
tree and drivers code
Hm hm. It's still FUD.
If my desktop only has one Ethernet interface, no matter how many kernel
changes happen, it'll always be eth0.
Whereas, with the new predictable scheme, if I move that card around, it
will change name.
Tell me which one is random, again?
I see. You politely wanted to point out these lacks in the news item.
Sorry, it was hard to see it through from all the sarcasm.
(New item attached, and also covers ulm's concerns from the another reply.)
---
I'm not saying you shouldn't enable it (feel free to screw up user as
much as you want, just don't complain if they don't like you),
I don't remember complaining about users not liking me, nor caring about
it. If they want to shoot the messenger, that's fine by me.
but since
both kernel naming and predictable naming have their chance to change,
don't spread FUD.
One you can control, the another you can't. So still not FUD.
Title: The new predictable net iface names
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2013-03-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-fs/udev-201
If you still have network interface renaming rules in /etc/udev/rules.d,
like 70-persistent-net.rules, you will need to modify or remove them.
If you choose to modify them, you will need to pick a free namespace
(like net* or internet*) that is not reserved by the kernel
(like eth* or wlan*) because in-place renaming has been deprecated[1].
You should also rename the file to something else, like
70-my-network.rules to silence the deprecation warning coming from when
you emerge udev.
This is old format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=eth0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=eth1
This is new format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=net0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=net1
With the new predictable network interface naming scheme which upstream
enabled by default you don't have to rename anymore because the names
will be static and not randomly rename when you, for example, upgrade
the kernel. The default name is calculated from the slot being used for
the card, but it can be changed to be, for example, MAC based. This is
documented in the upstream wiki[2]. This can be very important aspect,
for example, security in mind.
If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
a symlink to /dev/null, the new names will be disabled and kernel will
do all the interface naming, which will be random.
The new names can also be disabled using net.ifnames=0 kernel option.
However, if your system has only one network interface card,
for example, eth0, you don't necessarily need this feature at all.
Use the forementioned methods to disable the feature in that case if
you want.
In normal new installation there is no files put in /etc/udev/rules.d
and if you haven't edited any files you have in there, you should most
likely delete (backup) them all out of the way.
You can find out using udevadm command what your interfaces will be
called before booting to make necessary changes, such as changing
net.* symlinks in /etc/init.d.
This is the example command:
# udevadm test-builtin net_id /sys/class/net/eth0 2 /dev/null
The output could be (and I'm only picking the most important line for
this example):
ID_NET_NAME_PATH=enp2s0f0
This would mean your eth0 will be called enp2s0f0 if there is no
previously mentioned files blocking the new names taking place in
/etc/udev/rules.d.
This is documented more throughly at upstream wiki[2] which everyone
should read at least once.
This feature can also replace the functionality of sys-apps/biosdevname,
but you can still keep using it if you want.
[1] http://www.kernel.org/doc/htmldocs/device-drivers/
API-device-rename.html
[2] http://www.freedesktop.org/wiki/Software/systemd/
PredictableNetworkInterfaceNames
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Whereas, with the new predictable scheme, if I move that card around, it will change name. It's even worse, if you mess with kernel parameters (esp. pci=assign-busses for PCMCIA) then the device numbering might change without hardware moving around. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 12:29, Samuli Suominen wrote: One you can control, the another you can't. So still not FUD. You do not really control it any more than the kernel. The fact that me and you can edit an udev ruleset to control it, does not mean that most users see it as a black box. The news item reads better. I would still either avoid showing the NET_PATH example or describe that that is not the final result because on a laptop, NET_PATH almost certainly will *not* match the final interface name: flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1 2/dev/null ID_NET_NAME_MAC=enx0026b9d7bf1f ID_OUI_FROM_DATABASE=Dell Inc ID_NET_NAME_ONBOARD=eno1 ID_NET_LABEL_ONBOARD=en Onboard LAN ID_NET_NAME_PATH=enp0s25 And I would not expect users to all go read the wiki and try to figure out why you said it would be named enp0s25 when it gets the name eno1. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote: Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Okay let me re-qualify the statement: If my desktop only has one Ethernet interface, and I don't mess up with it in userspace at all, no matter how many kernel changes happen, it'll always be eth0. Yes, the previous persistent rules for udev would have messed that one up when e1000e got split, or if you switched between the Broadcom-provided driver to the kernel one or vice-versa. The deathforce drivers come in mind as well. Whereas, with the new predictable scheme, if I move that card around, it will change name. It's even worse, if you mess with kernel parameters (esp. pci=assign-busses for PCMCIA) then the device numbering might change without hardware moving around. Sweet I didn't think about that. Yai for predictably variable names. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 13:38, Diego Elio Pettenò wrote:
On 29/03/2013 12:29, Samuli Suominen wrote:
One you can control, the another you can't. So still not FUD.
You do not really control it any more than the kernel. The fact that me
and you can edit an udev ruleset to control it, does not mean that
most users see it as a black box.
I don't agree with that, /etc/udev/rules.d and overriding udev rules is
very basic administration, very basic...
I'll put a bit more trust on our users.
The news item reads better. I would still either avoid showing the
NET_PATH example or describe that that is not the final result because
on a laptop, NET_PATH almost certainly will *not* match the final
interface name:
flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1 2/dev/null
ID_NET_NAME_MAC=enx0026b9d7bf1f
ID_OUI_FROM_DATABASE=Dell Inc
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=en Onboard LAN
ID_NET_NAME_PATH=enp0s25
And I would not expect users to all go read the wiki and try to figure
out why you said it would be named enp0s25 when it gets the name eno1.
Nod.
Attached new version again, more generic than before.
Hope it'll do what it's meant to do... push users into right direction...
It's not meant to be a complete documentation or rewrite of the upstream
wiki page :-p
Just a push...
Title: The new predictable net iface names
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2013-03-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-fs/udev-201
If you still have network interface renaming rules in /etc/udev/rules.d,
like 70-persistent-net.rules, you will need to modify or remove them.
If you choose to modify them, you will need to pick a free namespace
(like net* or internet*) that is not reserved by the kernel
(like eth* or wlan*) because in-place renaming has been deprecated[1].
You should also rename the file to something else, like
70-my-network.rules to silence the deprecation warning coming from when
you emerge udev.
This is old format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=eth0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=eth1
This is new format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=net0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=net1
With the new predictable network interface naming scheme which upstream
enabled by default you don't have to rename anymore because the names
will be static and not randomly rename when you, for example, upgrade
the kernel. The default names can be calculated from the slots being
used for the cards, but it can be changed to use, for example, MAC
addresses. This is documented in the upstream wiki[2].
If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
a symlink to /dev/null, the new names will be disabled and kernel will
do all the interface naming, which will be random.
The new names can also be disabled using net.ifnames=0 kernel option.
However, if your system has only one network interface card,
for example, eth0, you don't necessarily need this feature at all.
Use the forementioned methods to disable the feature in that case if
you want.
In normal new installation there is no files put in /etc/udev/rules.d
and if you haven't edited any files you have in there, you should most
likely delete (backup) them all out of the way.
You can find out using udevadm command what your interfaces will be
called before booting to make necessary changes, such as changing
net.* symlinks in /etc/init.d.
This is the example command for getting attributes of the current eth0
network device:
# udevadm test-builtin net_id /sys/class/net/eth0 2 /dev/null
Assuming there are no leftover rules in /etc/udev/rules.d that would
prevent the new names from being enabled, it's most likely either
ID_NET_NAME_ONBOARD or ID_NET_NAME_PATH lines you should be looking
at for the new name in default configuration. This ordering is
documented more throughly at upstream wiki[2] which everyone should
read at least once.
This feature can also replace the functionality of sys-apps/biosdevname,
but you can still keep using it if you want.
[1] http://www.kernel.org/doc/htmldocs/device-drivers/
API-device-rename.html
[2] http://www.freedesktop.org/wiki/Software/systemd/
PredictableNetworkInterfaceNames
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 13:20, Samuli Suominen wrote: I don't agree with that, /etc/udev/rules.d and overriding udev rules is very basic administration, very basic... I'll put a bit more trust on our users. Let's agree to disagree then. To me, it's much more consistent the kernel's behaviour than these predictable names. Is my WWAN interface wwan0, wwp0s29u1u2i1, wws1u1i1 or wwp0s29u1u3i1 today? Attached new version again, more generic than before. Hope it'll do what it's meant to do... push users into right direction... It's not meant to be a complete documentation or rewrite of the upstream wiki page :-p Better, not perfect IMHO, but definitely better. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 03/29/2013 08:20 AM, Samuli Suominen wrote: On 29/03/13 13:38, Diego Elio Pettenò wrote: On 29/03/2013 12:29, Samuli Suominen wrote: One you can control, the another you can't. So still not FUD. You do not really control it any more than the kernel. The fact that me and you can edit an udev ruleset to control it, does not mean that most users see it as a black box. I don't agree with that, /etc/udev/rules.d and overriding udev rules is very basic administration, very basic... I'd love to believe that, but do you have any idea how many people aren't familiar with it? It took a long time before the default response to help, I've replaced my NIC or motherboard, and eth0 is gone! became find and remove this line from /etc/udev/rules.d/70-persistent-net.rules instead of remove /etc/udev/rules.d/70-persistent-net.rules Something else...I've not encountered *one* other person to use anything other than the system-default names for NICs...except myself. And when I've done it, and despite giving them descriptive names, other people are completely flummoxed when they see my configurations. What's this 'wan', 'lan' and 'wifilan'? Where are eth0, eth1 and eth2? And of those I've found who knew of the feature and knew how to use it, none have ever felt motivated to use it except when hardware was replaced. (Personally, I find the feature underused; I could easily see networks benefiting from rules like any interface prefixed with 'p' is public facing without the benefit of a firewall, any interface prefixed with 's' points to a SAN or any interface prefixed with a 'c' is touches a network region where PCI-compliance rules are in effect.) I'll put a bit more trust on our users. The news item reads better. I would still either avoid showing the NET_PATH example or describe that that is not the final result because on a laptop, NET_PATH almost certainly will *not* match the final interface name: flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1 2/dev/null ID_NET_NAME_MAC=enx0026b9d7bf1f ID_OUI_FROM_DATABASE=Dell Inc ID_NET_NAME_ONBOARD=eno1 ID_NET_LABEL_ONBOARD=en Onboard LAN ID_NET_NAME_PATH=enp0s25 And I would not expect users to all go read the wiki and try to figure out why you said it would be named enp0s25 when it gets the name eno1. Nod. Attached new version again, more generic than before. Hope it'll do what it's meant to do... push users into right direction... It's not meant to be a complete documentation or rewrite of the upstream wiki page :-p Just a push... I would probably replace this: If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a symlink to /dev/null, the new names will be disabled and kernel will do all the interface naming, which will be random. With something like this: If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a symlink to /dev/null, the new names will be disabled and kernel will do all the interface naming, and the resulting names will vary by kernel and hardware configuration, and may vary by kernel version. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
Am Freitag, 29. März 2013, 13:20:20 schrieb Samuli Suominen: On 29/03/13 13:38, Diego Elio Pettenò wrote: On 29/03/2013 12:29, Samuli Suominen wrote: One you can control, the another you can't. So still not FUD. You do not really control it any more than the kernel. The fact that me and you can edit an udev ruleset to control it, does not mean that most users see it as a black box. I don't agree with that, /etc/udev/rules.d and overriding udev rules is very basic administration, very basic... I'll put a bit more trust on our users. Not really. Every time I modified anything in there, it just took a few udev versions and suddenly I was flooded with deprecation warnings a la things work different now, find out on your own how to fix it... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 9:24 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Not really. Every time I modified anything in there, it just took a few udev versions and suddenly I was flooded with deprecation warnings a la things work different now, find out on your own how to fix it... Not to mention at least in the past it has tended to accumulate orphans. I was getting tons of warnings on boot-up and discovered that config protection left a ton of files in there from who-knows-when. Granted, this is on a system that has been running Gentoo for about a decade now (every part in it has changed several times, but the OS has steadily migrated along). Now I'm down to 5 files in there, and only one of them is my local.rules file. If udev is going to stick stuff in /etc then it really needs to have better communication when this stuff needs to be modified/cleaned/etc, and what users are and aren't supposed to touch. Rich
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 15:30, Rich Freeman wrote: On Fri, Mar 29, 2013 at 9:24 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Not really. Every time I modified anything in there, it just took a few udev versions and suddenly I was flooded with deprecation warnings a la things work different now, find out on your own how to fix it... Not to mention at least in the past it has tended to accumulate orphans. I was getting tons of warnings on boot-up and discovered that config protection left a ton of files in there from who-knows-when. Granted, this is on a system that has been running Gentoo for about a decade now (every part in it has changed several times, but the OS has steadily migrated along). Now I'm down to 5 files in there, and only one of them is my local.rules file. If udev is going to stick stuff in /etc then it really needs to have better communication when this stuff needs to be modified/cleaned/etc, and what users are and aren't supposed to touch. Rich What do you have there? We cover bunch of those in pkg_postinst of udev already.
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 9:44 AM, Samuli Suominen ssuomi...@gentoo.org wrote: What do you have there? We cover bunch of those in pkg_postinst of udev already. After a bunch of cleanup (after which I have yet to detect any problems), I have: 70-persistent-cd.rules 70-persistent-net.rules 80-net-name-slot.rules kino.rules local.rules Only media-video/kino actually claims one of those files. If I missed an elog message somewhere, I'm ready for my flogging. :) Rich
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 16:35, Rich Freeman wrote: On Fri, Mar 29, 2013 at 9:44 AM, Samuli Suominen ssuomi...@gentoo.org wrote: What do you have there? We cover bunch of those in pkg_postinst of udev already. After a bunch of cleanup (after which I have yet to detect any problems), I have: 70-persistent-cd.rules 70-persistent-net.rules 80-net-name-slot.rules kino.rules local.rules Only media-video/kino actually claims one of those files. If I missed an elog message somewhere, I'm ready for my flogging. :) Rich I fixed kino but I didn't revision bump for it. Waiting for something bigger to revbump it. If you re-emerge kino, the rule will move to /lib/udev/rules.d. Those 70-* and 80-* are in udev pkg_postinst, this news item, everywhere... can all 3 be deleted if you haven't modified them yourself. So that leaves one... local.rules... dunno about that. I'm curious. - Samuli
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 10:45 AM, Samuli Suominen ssuomi...@gentoo.org wrote: Those 70-* and 80-* are in udev pkg_postinst, this news item, everywhere... can all 3 be deleted if you haven't modified them yourself. So that leaves one... local.rules... dunno about that. I'm curious. Excellent, sounds good then. The local rules are exactly what it sounds like - my own stuff. Some of what it does is obsolete now. It maps persistent symlinks to two pl2303 rs232 usb interfaces (which I believe is a solved problem now). It maps persistent symlinks to a few video capture devices (not a solved problem afaik). It assigns firewire ports to the video group (no idea if that is now in the standard rules). Rich
[gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 2013-03-29, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote: Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Okay let me re-qualify the statement: If my desktop only has one Ethernet interface, and I don't mess up with it in userspace at all, no matter how many kernel changes happen, it'll always be eth0. Yes, the previous persistent rules for udev would have messed that one up when e1000e got split, or if you switched between the Broadcom-provided driver to the kernel one or vice-versa. The deathforce drivers come in mind as well. IMHO this is really relevant. It is annoying seeing how many people go oh you *must not* use the old scheme, because it won't work. The new naming scheme does *not* prevent you from using eth0, users should really just be told they can *disable* udev rules (and told how to do it) if they are happy with the kernel name of their sole network card, instead of being told that they *must* upgrade to the new rules. The messages so far seem to imply that you can't have eth0. You *can*, but udev won't be able to do anything if the device appears as something else and there's already another eth0. If you don't already have eth0, the udev rules *will* work, even if your card is named in the eth namespace. The *only* thing that breaks is renaming network devices to names that are already in use inside the kernel namespaces. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29 March 2013 16:21, Nuno J. Silva (aka njsg) nunojsi...@ist.utl.ptwrote: On 2013-03-29, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote: Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Okay let me re-qualify the statement: If my desktop only has one Ethernet interface, and I don't mess up with it in userspace at all, no matter how many kernel changes happen, it'll always be eth0. Yes, the previous persistent rules for udev would have messed that one up when e1000e got split, or if you switched between the Broadcom-provided driver to the kernel one or vice-versa. The deathforce drivers come in mind as well. IMHO this is really relevant. It is annoying seeing how many people go oh you *must not* use the old scheme, because it won't work. The new naming scheme does *not* prevent you from using eth0, users should really just be told they can *disable* udev rules (and told how to do it) if they are happy with the kernel name of their sole network card, instead of being told that they *must* upgrade to the new rules. The messages so far seem to imply that you can't have eth0. You *can*, but udev won't be able to do anything if the device appears as something else and there's already another eth0. If you don't already have eth0, the udev rules *will* work, even if your card is named in the eth namespace. The *only* thing that breaks is renaming network devices to names that are already in use inside the kernel namespaces. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/ I sort of agree here. The news item is rather scary for people maintaining remote boxes. Couldn't we just preserve the old behavior with an opt-in for people who want to use this new feature? Or am I reading the message wrong? In my mind, the message says either remove 70-* and setup 80-* or your system will end up broken. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Minor change in pkg-config behavior, starting with 0.28, late heads up for maintainers
Le vendredi 29 mars 2013 à 08:30 +0200, Samuli Suominen a écrit : This is from Fedora Devel Mailing List. I found it to be news worthy also for Gentoo maintainers. Thanks for the heads up, it will probably save some time figuring out magic/sudden break up :)
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 12:40 PM, Markos Chandras hwoar...@gentoo.org wrote: In my mind, the message says either remove 70-* and setup 80-* or your system will end up broken. The other bit is that modifying symlinks in /etc/init.d is only mentioned in passing. That is a VERY important step unless your new name happens to be the same as your old one, otherwise on the next boot the system will not have a working network interface, which will hamper efforts to fix for casual/new users, and cause real trouble for those doing remote administration (though anybody doing anything serious on a remotely-administered box should have some kind of console-level access outside of the OS - like serial console or iLO/etc support). Rich
Re: [gentoo-dev] Collecting items for EAPI 6
Am Donnerstag, 28. März 2013, 19:15:59 schrieb Michał Górny: Hello, As discussed with ulm, I'd like to start a thread for collecting initial items for EAPI 6. Preferably items which are either almost ready or are easy to implement and are non-controversial. In other words, thing which are practically ready to get on the actual list. As usual, each item should have a corresponding 'Future EAPI' bug which blocks the tracker [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=future-eapi IUSE_RUNTIME support. Please. https://bugs.gentoo.org/show_bug.cgi?idB4283 -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Collecting items for EAPI 6
On Fri, 29 Mar 2013 18:54:52 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Donnerstag, 28. März 2013, 19:15:59 schrieb Michał Górny: Hello, As discussed with ulm, I'd like to start a thread for collecting initial items for EAPI 6. Preferably items which are either almost ready or are easy to implement and are non-controversial. In other words, thing which are practically ready to get on the actual list. As usual, each item should have a corresponding 'Future EAPI' bug which blocks the tracker [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=future-eapi IUSE_RUNTIME support. Please. https://bugs.gentoo.org/show_bug.cgi?idB4283 Without a reference implementation, and experience of how it works in practice? No chance. We have both of these for 'suggested' dependencies, if you prefer. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 18:21, Nuno J. Silva (aka njsg) wrote: On 2013-03-29, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote: Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Okay let me re-qualify the statement: If my desktop only has one Ethernet interface, and I don't mess up with it in userspace at all, no matter how many kernel changes happen, it'll always be eth0. Yes, the previous persistent rules for udev would have messed that one up when e1000e got split, or if you switched between the Broadcom-provided driver to the kernel one or vice-versa. The deathforce drivers come in mind as well. IMHO this is really relevant. It is annoying seeing how many people go oh you *must not* use the old scheme, because it won't work. The new naming scheme does *not* prevent you from using eth0, users should really just be told they can *disable* udev rules (and told how to do it) if they are happy with the kernel name of their sole network card, instead of being told that they *must* upgrade to the new rules. The messages so far seem to imply that you can't have eth0. You *can*, but udev won't be able to do anything if the device appears as something else and there's already another eth0. If you don't already have eth0, the udev rules *will* work, even if your card is named in the eth namespace. The *only* thing that breaks is renaming network devices to names that are already in use inside the kernel namespaces. I think you may have not seen the latest version, it says for eg. If you only have one interface card, you don't necessarily have much use for this feature as the name almost always stays at eth0, you can easily disable it using forementioned methods. After first listing 3 different ways of disabling the new names earlier. http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob_plain;f=2013/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt;hb=HEAD But I'd prefer not to lead people to the path of renaming into namespace already taken... that can lead to issues. It sounds almost as hackish as the script that frees the whole namespace by using temporary names: https://bugs.gentoo.org/attachment.cgi?id=336774 Still trying to decipher people if there is more to adjust in the news though, it doesn't have to be frozen as is, if you have better wording, please provide a patch against the current. Thanks :) - Samuli
Re: [gentoo-dev] Collecting items for EAPI 6
Am Freitag, 29. März 2013, 17:57:34 schrieb Ciaran McCreesh: [snip] /dev/null -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 2013-03-29, Samuli Suominen ssuomi...@gentoo.org wrote: On 29/03/13 18:21, Nuno J. Silva (aka njsg) wrote: On 2013-03-29, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote: Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Okay let me re-qualify the statement: If my desktop only has one Ethernet interface, and I don't mess up with it in userspace at all, no matter how many kernel changes happen, it'll always be eth0. Yes, the previous persistent rules for udev would have messed that one up when e1000e got split, or if you switched between the Broadcom-provided driver to the kernel one or vice-versa. The deathforce drivers come in mind as well. IMHO this is really relevant. It is annoying seeing how many people go oh you *must not* use the old scheme, because it won't work. The new naming scheme does *not* prevent you from using eth0, users should really just be told they can *disable* udev rules (and told how to do it) if they are happy with the kernel name of their sole network card, instead of being told that they *must* upgrade to the new rules. The messages so far seem to imply that you can't have eth0. You *can*, but udev won't be able to do anything if the device appears as something else and there's already another eth0. If you don't already have eth0, the udev rules *will* work, even if your card is named in the eth namespace. The *only* thing that breaks is renaming network devices to names that are already in use inside the kernel namespaces. I think you may have not seen the latest version, it says for eg. If you only have one interface card, you don't necessarily have much use for this feature as the name almost always stays at eth0, you can easily disable it using forementioned methods. Yeah, I didn't. Checking the new version, it is definitely much better! Just two notes/questions: If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a symlink to /dev/null, the new names will be disabled and kernel will do all the interface naming, and the resulting names will vary by kernel and hardware configuration, and may vary by kernel version. IIRC, it can also vary from boot to boot, with the same kernel and hardware, if there is some kind of race condition. Also, the forementioned old 70-persistent-net.rules might interfere with the new enabling of the new predictable interface names! might? I never checked, but I thought that, in order to enable the new naming rules, one had to remove the 70-persistent-net.rules file from /etc. How does this work, exactly? After first listing 3 different ways of disabling the new names earlier. http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob_plain;f=2013/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt;hb=HEAD But I'd prefer not to lead people to the path of renaming into namespace already taken... that can lead to issues. It sounds almost as hackish as the script that frees the whole namespace by using temporary names: https://bugs.gentoo.org/attachment.cgi?id=336774 Can, but only if there is more than one device using that namespace for their final names. I'm probably biased, because of having had udev configuration issues and having to hear half of the time you *can't* use ethX, just because of the FUD. I'd say the key is more avoiding leading people to a different system of rules when they may be fine with the kernel namespace. Perhaps the approach should be more like: If you need persistent naming for some reason (such as two network devices in the same kernel namespace), you will need to change your rules and use namespaces that are not used by your kernel. This will also imply changing all relevant configurations (firewalling, init scripts) to refer to the new device names. If you do not need to avoid clashes (only one network device or more devices on separate namespaces (e.g. eth0 and wlan0)), you can just keep the current configuration. Still trying to decipher people if there is more to adjust in the news though, it doesn't have to be frozen as is, if you have better wording, please provide a patch against the current. Thanks :) -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I don't have enough time to go through the rest of this thread, but if the first sentence hasn't been adjusted yet: On 29/03/13 08:20 AM, Samuli Suominen wrote: If you still have network interface renaming rules in /etc/udev/rules.d, like 70-persistent-net.rules, you will need to modify or remove them. Might I recommend at least a little bit of context before going right into you have to remove these rules? IE - if a user wants to keep the old mac-based rules they already have, can't they? 80-*.rules doesn't override that now, does it? I'd recommend: As of version 197, udev now provides predictable interface renaming based directly on [hardware addresses and whatever other info]. The old MAC-based relabelling in prior udev versions has been removed, and it is highly recommended to migrate to the new version. ...as the first paragraph. Then follow with the rest. Friendly? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlFV6WMACgkQ2ugaI38ACPAMAAD/aJC64ISmRlspep2FU3vuBHuB o+tEueMLIrNnHgNtC7sA/0JIl9H5gbX6talhmPkxKLbMdcaAAWvB4osN1pgWC45H =XH7f -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 20:20, Ian Stakenvicius wrote: Might I recommend at least a little bit of context before going right into you have to remove these rules? IE - if a user wants to keep the old mac-based rules they already have, can't they? 80-*.rules doesn't override that now, does it? It doesn't override it _but_ if you were using the old eth* names, it will drop support for the in-place renaming (i.e. the ability to swap eth0 and eth1). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] licensing query : Splice
I noticed a couple of games which have been added to the tree thought it worth giving them a try. One of them resulted in this : root:512 ~ emerge -pv games-puzzle/splice These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N F ] games-puzzle/splice-20121120 298,671 kB Total: 1 package (1 new), Size of downloads: 298,671 kB Fetch Restriction: 1 package (1 unsatisfied) Fetch instructions for games-puzzle/splice-20121120: * Please buy download splice-linux-1353389454.tar.gz from: * http://www.cipherprime.com/games/splice/ * and move it to /usr/portage/distfiles I've never seen this before in 10 years using Gentoo. Has anyone verified that Splice's licence is compatible with Gentoo ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] licensing query : Splice
On 03/29/2013 09:26 PM, Philip Webb wrote: I noticed a couple of games which have been added to the tree thought it worth giving them a try. One of them resulted in this : root:512 ~ emerge -pv games-puzzle/splice These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N F ] games-puzzle/splice-20121120 298,671 kB Total: 1 package (1 new), Size of downloads: 298,671 kB Fetch Restriction: 1 package (1 unsatisfied) Fetch instructions for games-puzzle/splice-20121120: * Please buy download splice-linux-1353389454.tar.gz from: * http://www.cipherprime.com/games/splice/ * and move it to /usr/portage/distfiles I've never seen this before in 10 years using Gentoo. Has anyone verified that Splice's licence is compatible with Gentoo ? Compatible with Gentoo? What does that mean?
Re: [gentoo-dev] licensing query : Splice
On Fri, Mar 29, 2013 at 4:26 PM, Philip Webb purs...@ca.inter.net wrote: I've never seen this before in 10 years using Gentoo. Has anyone verified that Splice's licence is compatible with Gentoo ? What do you mean by compatible with Gentoo? Gentoo is not a party to the distribution or use of splice, so why would Gentoo need to be concerned with its licensing? We are merely providing a script that helps a user who legally has the right to install/use it to do so. The license listed in the ebuild is listed as a convenience to the user. Gentoo is fairly unique among Linux distros in that we separate the distribution of the content of a package from its installation script/metadata/etc. If a package has a license which does not permit redistribution we simply don't redistribute the portions of it for which we do not hold a license. That is also why you won't find any Iceweasels or such in Gentoo - we don't distribute modified upstream files, therefore we are not subject to any restrictions on the distributions of such. There is nothing illegal with providing an installation script for somebody else's binary, as long as you don't distribute the binary. Look at the long tradition of Windows install/patch tools for an example of this. Rich
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 01:38:03PM -0400, Rich Freeman wrote On Fri, Mar 29, 2013 at 12:40 PM, Markos Chandras hwoar...@gentoo.org wrote: In my mind, the message says either remove 70-* and setup 80-* or your system will end up broken. The other bit is that modifying symlinks in /etc/init.d is only mentioned in passing. That is a VERY important step unless your new name happens to be the same as your old one, otherwise on the next boot the system will not have a working network interface, which will hamper efforts to fix for casual/new users, and cause real trouble for those doing remote administration (though anybody doing anything serious on a remotely-administered box should have some kind of console-level access outside of the OS - like serial console or iLO/etc support). That's only the beginning for the necessary changes. I'm running mdev on this machine, so it won't affect me, but here goes... [d531][root][~] grep -rl eth[0-9] /etc/* /etc/conf.d/net /etc/conf.d/network /etc/conf.d/netmount /etc/dosemu/dosemu.conf /etc/hibernate/common.conf /etc/rc.conf I've eliminated some specific stuff that only I do. * /etc/conf.d/net Is going to have to be modified by users. * I believe /etc/conf.d/network is a doc file for /etc/conf.d/net. * /etc/conf.d/netmount Who changes that? * /etc/dosemu/dosemu.conf It's an app, but may require changes. * /etc/hibernate/common.conf It's an app, but may require changes. * /etc/rc.conf Is going to have to be modified by users. Fun for users, and app upstreams. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
