Re: [gentoo-user] snapper (btrfs)
on 09/25/2014 12:11 AM Neil Bothwick wrote the following: I use a home-brewed script to make time based snapshots, called from cron - a little like zfs-auto-snapshot. I set a limit on the number of each type of snapshot so the script generally creates one snapshot and deletes one snapshot for each subvolume whenever it is called, avoiding the need to ever have a gazillion snapshots to delete. Do you mind sharing the script please? “You are forgiven for your happiness and your successes only if you generously consent to share them.” ― Albert Camus
[gentoo-user] Depends or not depends? That is the question. :)
Running #emerge --depclean --backtrack=60 --ask after updating my system today, I have got the following: >>> These are the packages that would be unmerged: dev-lang/tk selected: 8.5.15 protected: none omitted: none dev-lang/tcl selected: 8.5.15-r1 protected: none omitted: none All selected packages: dev-lang/tk-8.5.15 dev-lang/tcl-8.5.15-r1 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. Would you like to unmerge these packages? [Yes/No] On the other hand, $ equery depends gives $ equery depends tk * These packages depend on tk: app-text/epspdf-0.6.0 (tk ? dev-lang/tk) dev-lang/R-3.0.1 (tk ? dev-lang/tk) dev-lang/ocaml-3.12.1 (tk ? >=dev-lang/tk-3.3.3) dev-lang/python-2.7.7 (tk ? >=dev-lang/tk-8.0) dev-lang/python-3.3.5-r1 (tk ? >=dev-lang/tk-8.0) dev-libs/libisoburn-1.3.4 (launch-frontend ? dev-lang/tk:0) (launch-frontend-setuid ? dev-lang/tk:0) dev-ml/lablgl-1.05 (tk ? >=dev-lang/tk-8.3) dev-vcs/git-1.8.5.5 (tk ? dev-lang/tk) What does it means? Do all these packages depend on dev-lang/tk or not? Can I answer Yes to emerge --depclean --ask?
Re: [gentoo-user] Depends or not depends? That is the question. :)
On 25/09/2014 11:02, Gevisz wrote: > Running > #emerge --depclean --backtrack=60 --ask > after updating my system today, I have got the following: These are the packages that would be unmerged: > > dev-lang/tk > selected: 8.5.15 >protected: none > omitted: none > > dev-lang/tcl > selected: 8.5.15-r1 >protected: none > omitted: none > > All selected packages: dev-lang/tk-8.5.15 dev-lang/tcl-8.5.15-r1 > 'Selected' packages are slated for removal. 'Protected' and 'omitted' packages will not be removed. > > Would you like to unmerge these packages? [Yes/No] > > On the other hand, > $ equery depends > gives > $ equery depends tk > * These packages depend on tk: > app-text/epspdf-0.6.0 (tk ? dev-lang/tk) > dev-lang/R-3.0.1 (tk ? dev-lang/tk) > dev-lang/ocaml-3.12.1 (tk ? >=dev-lang/tk-3.3.3) > dev-lang/python-2.7.7 (tk ? >=dev-lang/tk-8.0) > dev-lang/python-3.3.5-r1 (tk ? >=dev-lang/tk-8.0) > dev-libs/libisoburn-1.3.4 (launch-frontend ? dev-lang/tk:0) > (launch-frontend-setuid ? dev-lang/tk:0) > dev-ml/lablgl-1.05 (tk ? >=dev-lang/tk-8.3) > dev-vcs/git-1.8.5.5 (tk ? dev-lang/tk) > > What does it means? > > Do all these packages depend on dev-lang/tk or not? > > Can I answer Yes to emerge --depclean --ask? equery depends gets it's output directly from the ebuild, it is not a list of what *you* have and how you are affected. The ebuilds are saying that if you have "tk" in USE, then portage must install tk. Same with tcl. So it all depends on what you have in USE. We don't know what you need or want, that is your call. If you know you need tk/tcl then add it to USE. If you don't need them, let them be depcleaned. If you are not sure, let them be depcleaned and if stuff breaks, then add them back to USE and update world. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Depends or not depends? That is the question. :)
On Thu, 25 Sep 2014 11:10:00 +0200 Alan McKinnon wrote: > On 25/09/2014 11:02, Gevisz wrote: > > Running > > #emerge --depclean --backtrack=60 --ask > > after updating my system today, I have got the following: > These are the packages that would be unmerged: > > > > dev-lang/tk > > selected: 8.5.15 > >protected: none > > omitted: none > > > > dev-lang/tcl > > selected: 8.5.15-r1 > >protected: none > > omitted: none > > > > All selected packages: dev-lang/tk-8.5.15 dev-lang/tcl-8.5.15-r1 > > > 'Selected' packages are slated for removal. > 'Protected' and 'omitted' packages will not be removed. > > > > Would you like to unmerge these packages? [Yes/No] > > > > On the other hand, > > $ equery depends > > gives > > $ equery depends tk > > * These packages depend on tk: > > app-text/epspdf-0.6.0 (tk ? dev-lang/tk) > > dev-lang/R-3.0.1 (tk ? dev-lang/tk) > > dev-lang/ocaml-3.12.1 (tk ? >=dev-lang/tk-3.3.3) > > dev-lang/python-2.7.7 (tk ? >=dev-lang/tk-8.0) > > dev-lang/python-3.3.5-r1 (tk ? >=dev-lang/tk-8.0) > > dev-libs/libisoburn-1.3.4 (launch-frontend ? dev-lang/tk:0) > > (launch-frontend-setuid ? dev-lang/tk:0) > > dev-ml/lablgl-1.05 (tk ? >=dev-lang/tk-8.3) > > dev-vcs/git-1.8.5.5 (tk ? dev-lang/tk) > > > > What does it means? > > > > Do all these packages depend on dev-lang/tk or not? > > > > Can I answer Yes to emerge --depclean --ask? > > > equery depends gets it's output directly from the ebuild, it is not a > list of what *you* have and how you are affected. > > The ebuilds are saying that if you have "tk" in USE, then portage must > install tk. Same with tcl. > > So it all depends on what you have in USE. > We don't know what you need or want, that is your call. If you know > you need tk/tcl then add it to USE. If you don't need them, let them > be depcleaned. If you are not sure, let them be depcleaned and if > stuff breaks, then add them back to USE and update world. Thank you for explanation. I depcleaned them all. So far so good. :)
Re: [gentoo-user] Depends or not depends? That is the question. :)
On 25/09/2014 13:09, Gevisz wrote: > On Thu, 25 Sep 2014 11:10:00 +0200 > Alan McKinnon wrote: > >> On 25/09/2014 11:02, Gevisz wrote: >>> Running >>> #emerge --depclean --backtrack=60 --ask >>> after updating my system today, I have got the following: >> These are the packages that would be unmerged: >>> >>> dev-lang/tk >>> selected: 8.5.15 >>>protected: none >>> omitted: none >>> >>> dev-lang/tcl >>> selected: 8.5.15-r1 >>>protected: none >>> omitted: none >>> >>> All selected packages: dev-lang/tk-8.5.15 dev-lang/tcl-8.5.15-r1 >>> >> 'Selected' packages are slated for removal. >> 'Protected' and 'omitted' packages will not be removed. >>> >>> Would you like to unmerge these packages? [Yes/No] >>> >>> On the other hand, >>> $ equery depends >>> gives >>> $ equery depends tk >>> * These packages depend on tk: >>> app-text/epspdf-0.6.0 (tk ? dev-lang/tk) >>> dev-lang/R-3.0.1 (tk ? dev-lang/tk) >>> dev-lang/ocaml-3.12.1 (tk ? >=dev-lang/tk-3.3.3) >>> dev-lang/python-2.7.7 (tk ? >=dev-lang/tk-8.0) >>> dev-lang/python-3.3.5-r1 (tk ? >=dev-lang/tk-8.0) >>> dev-libs/libisoburn-1.3.4 (launch-frontend ? dev-lang/tk:0) >>> (launch-frontend-setuid ? dev-lang/tk:0) >>> dev-ml/lablgl-1.05 (tk ? >=dev-lang/tk-8.3) >>> dev-vcs/git-1.8.5.5 (tk ? dev-lang/tk) >>> >>> What does it means? >>> >>> Do all these packages depend on dev-lang/tk or not? >>> >>> Can I answer Yes to emerge --depclean --ask? >> >> >> equery depends gets it's output directly from the ebuild, it is not a >> list of what *you* have and how you are affected. >> >> The ebuilds are saying that if you have "tk" in USE, then portage must >> install tk. Same with tcl. >> >> So it all depends on what you have in USE. >> We don't know what you need or want, that is your call. If you know >> you need tk/tcl then add it to USE. If you don't need them, let them >> be depcleaned. If you are not sure, let them be depcleaned and if >> stuff breaks, then add them back to USE and update world. > > > Thank you for explanation. > > I depcleaned them all. > > So far so good. :) > > > That's the nice thing about depcleaning stuff - if you break it, one quick emerge brings it all back :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] [Security] Update bash *NOW*
On 25/09/2014 02:58, Walter Dnes wrote: [snip] ...with malicious stuff, and it could get ugly. app-shells/bash-4.2_p48 has been pushed to Gentoo stable. The same "env" command results in... Unfortunately, that version did fully address the problem. Instead, upgrade to 4.2_p48-r1 or any of the -r1 revision bumps that were recently committed. For further details: https://bugs.gentoo.org/show_bug.cgi?id=523592 --Kerin
Re: [gentoo-user] [Security] Update bash *NOW*
On 25/09/2014 13:54, Kerin Millar wrote: On 25/09/2014 02:58, Walter Dnes wrote: [snip] ...with malicious stuff, and it could get ugly. app-shells/bash-4.2_p48 has been pushed to Gentoo stable. The same "env" command results in... Unfortunately, that version did fully address the problem. Instead, upgrade to 4.2_p48-r1 or any of the -r1 revision bumps that were recently committed. For further details: https://bugs.gentoo.org/show_bug.cgi?id=523592 Oops. Obviously, I meant to write "did not fully address the problem". --Kerin
Re: [gentoo-user] [Security] Update bash *NOW*
Kerin Millar wrote: > On 25/09/2014 02:58, Walter Dnes wrote: > > [snip] > > > ...with malicious stuff, and it could get ugly. app-shells/bash-4.2_p48 > > has been pushed to Gentoo stable. The same "env" command results in... > > Unfortunately, that version did fully address the problem. Instead, > upgrade to 4.2_p48-r1 or any of the -r1 revision bumps that were > recently committed. For further details: > > https://bugs.gentoo.org/show_bug.cgi?id=523592 I cannot update to that, its not in the tree as of last night. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] [Security] Update bash *NOW*
On 2014-09-25 16:02, cov...@ccs.covici.com wrote: Kerin Millar wrote: On 25/09/2014 02:58, Walter Dnes wrote: [snip] > ...with malicious stuff, and it could get ugly. app-shells/bash-4.2_p48 > has been pushed to Gentoo stable. The same "env" command results in... Unfortunately, that version did fully address the problem. Instead, upgrade to 4.2_p48-r1 or any of the -r1 revision bumps that were recently committed. For further details: https://bugs.gentoo.org/show_bug.cgi?id=523592 I cannot update to that, its not in the tree as of last night. Try to rsync from some other mirror.
Re: [gentoo-user] Re: /dev/ttyUSB* group changed from uucp to root?
On Wed, Sep 24, 2014 at 6:28 PM, Grant Edwards wrote: > On 2014-09-24, Neil Bothwick wrote: >> On Wed, 24 Sep 2014 19:42:56 + (UTC), Grant Edwards wrote: >> >>> After an update yesterday, I've noticed that the group assigned to >>> ttyUSB devices has changed from uucp to root. Non-USB serial ports >>> still seem to be uucp. >> >> What did you update? They are still root:uucp here. > > Several things got updated, but the most likely suspect is probably > sys-fs/udev-215-r1 => sys-fs/udev-216. But, I don't see any changes > in the default rules to account for the change in behavior. > I'm running systemd-216, and I see this in /lib/udev/rules.d/50-udev-default.rules: KERNEL=="tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="uucp" I suppose it is possible that some later rule overrides it, but I don't see anything obvious.
[gentoo-user] udev (viable) alternatives ?
Ok, So I have used eudev before, without issue before. Things are moving along so now I see an udev-215 upgrade to udev-261 on a system running lxde. I intend to migrate this system to lxqt in the next few weeks, after I build up a new workstation. So changing from udev-215 to eudev-1.10-r2 is as simple as unmerging the former and emerging the latter ? The sytem is not tweaked very much and still running a 3.13.6 kernel, for now. Any other caveats (short term) on switching udev to eudev? curiously, James
[gentoo-user] Re: /dev/ttyUSB* group changed from uucp to root?
On 2014-09-25, Mike Gilbert wrote:
> On Wed, Sep 24, 2014 at 6:28 PM, Grant Edwards
> wrote:
>> On 2014-09-24, Neil Bothwick wrote:
>>> On Wed, 24 Sep 2014 19:42:56 + (UTC), Grant Edwards wrote:
>>>
After an update yesterday, I've noticed that the group assigned to
ttyUSB devices has changed from uucp to root. Non-USB serial ports
still seem to be uucp.
>>>
>>> What did you update? They are still root:uucp here.
>>
>> Several things got updated, but the most likely suspect is probably
>> sys-fs/udev-215-r1 => sys-fs/udev-216. But, I don't see any changes
>> in the default rules to account for the change in behavior.
>>
>
> I'm running systemd-216, and I see this in
> /lib/udev/rules.d/50-udev-default.rules:
>
> KERNEL=="tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*",
> GROUP="uucp"
>
> I suppose it is possible that some later rule overrides it, but I
> don't see anything obvious.
Yes, I saw that rule (and it hasn't changed recently). I also have a
rule that creates a symlink for a certain USB-serial adapter in
/etc/udev/rules.d/99-user.rules:
SUBSYSTEMS=="usb",\
ATTRS{product}=="FT232R USB UART",\
ATTRS{serial}=="AH026Q3X",\
KERNEL=="ttyUSB*",\
SYMLINK+="ttyDBG",\
GROUP="uucp"
I didn't used to need to set the GROUP in that rule, the device file
just defaulted to having a group of uucp. Yesterday, I had to add the
"GROUP" command to get the behavior I always used to get without it.
--
Grant Edwards grant.b.edwardsYow! My haircut is totally
at traditional!
gmail.com
Re: [gentoo-user] udev (viable) alternatives ?
James wrote: > Ok, > > So I have used eudev before, without issue before. Things are moving along > so now I see an udev-215 upgrade to udev-261 on a system running lxde. > I intend to migrate this system to lxqt in the next few weeks, after > I build up a new workstation. > > So changing from udev-215 to eudev-1.10-r2 is as simple as > unmerging the former and emerging the latter ? The sytem > is not tweaked very much and still running a 3.13.6 kernel, for now. > > > Any other caveats (short term) on switching udev to eudev? > > > curiously, > James > > I switched to eudev back when it was just getting going. Even then, it was as easy as unmerge udev, emerge eudev then restart udev. The init is still called udev, at least it is here. Other than being able to ditch that broken init thingy for booting, I haven't seen any difference. Hope that helps. Dale :-) :-)
Re: [gentoo-user] udev (viable) alternatives ?
On 25/09/14 18:25, James wrote: > Ok, > > So I have used eudev before, without issue before. Things are moving along > so now I see an udev-215 upgrade to udev-261 on a system running lxde. > I intend to migrate this system to lxqt in the next few weeks, after > I build up a new workstation. > > So changing from udev-215 to eudev-1.10-r2 is as simple as > unmerging the former and emerging the latter ? The sytem > is not tweaked very much and still running a 3.13.6 kernel, for now. > > > Any other caveats (short term) on switching udev to eudev? no support for kernel side predictable interface names where the naming should *really* be happening, eudev will always rename your interfaces with or without USE="rule-generator" to be explicit, eudev will ignore /lib/udev/hwdb.d/20-net-ifname.hwdb, eudev will rename interfaces marked as predictable by the kernel metadata, as in, eudev doesn't contain this commit: http://cgit.freedesktop.org/systemd/systemd/commit/network/99-default.link?id=04b67d49254d956d31bcfe80340fb9df7ed332d3 in fact, from what I last checked, eudev's networking is at same level with udev-208, from time before the .link support at all eudev is really useful only for sys-libs/musl users at this time, but you are free to experiment with it! - Samuli
[gentoo-user] Re: udev (viable) alternatives ?
Samuli Suominen gentoo.org> writes: > > Any other caveats (short term) on switching udev to eudev? > in fact, from what I last checked, eudev's networking is at same level > with udev-208, from time before the .link support at all ah, back when ethernet defaulted to eth0 not "enp5s0" ? > eudev is really useful only for sys-libs/musl users at this time, but > you are free to experiment with it! so lilblue (Anthony's amd64 hardened gentoo) is the only candidate I can think of with musl? So I choose this, then profile must be set to: (eslect profile list): [16] hardened/linux/musl/amd64 I'd be better of with a fresh install of lilblue + musl + eudev is what you are really saying here? James
Re: [gentoo-user] Re: udev (viable) alternatives ?
James wrote: > Samuli Suominen gentoo.org> writes: > > >>> Any other caveats (short term) on switching udev to eudev? >> in fact, from what I last checked, eudev's networking is at same level >> with udev-208, from time before the .link support at all > ah, back when ethernet defaulted to eth0 not "enp5s0" ? > Mine still does here. It's been eth0, eth1 etc for ages even after switching. I don't recall doing anything to keep it that way. > > James > Dale :-) :-)
Re: [gentoo-user] snapper (btrfs)
On Thu, 25 Sep 2014 11:22:15 +0300, Thanasis wrote: > > I use a home-brewed script to make time based snapshots, called from > > cron - a little like zfs-auto-snapshot. I set a limit on the number of > > each type of snapshot so the script generally creates one snapshot and > > deletes one snapshot for each subvolume whenever it is called, > > avoiding the need to ever have a gazillion snapshots to delete. > Do you mind sharing the script please? Attached. There are two things about it that I can state with certainty. 1) It works for me. 2) It may or may not work for you. You need to set the location of your snapshots at the top of the script. -- Neil Bothwick Those who live by the sword get shot by those who don't. buttersnap Description: Binary data signature.asc Description: PGP signature
Re: [gentoo-user] File system testing
On 16/09/14 20:07, James wrote: > Hello, > > By now many are familiar with my keen interest in clustering gentoo > systems. So, what most cluster technologies use is a distributed file > system on top of the local (HD/SDD) file system. Naturally not > all file systems, particularly the distributed file systems, have > straightforward instructions. Also, an device file system, such as > XFS and a distibuted (on top of the device file system) combination > may not work very well when paired. So a variety of testing is > something I'm researching. Eliminiation of either file system > listed below, due to Gentoo User Experience is most welcome information, > as well as tips and tricks to setting up any file system. > > > Distributed File Systems (DFS): > HDFS (poor performance) > Lustre > Ceph > XtreemFS > GlusterFS > MooseFS > FhGFS (BeeGFS) soon to be entirely open sourced? > Any other distributed file systems I should consider using? > > Local (Device) File Systems LFS: > btrfs > zfs > ext4 > xfs > > Obviously I do not what to test all combinations of DFS/LocalFS > so your comments are extremely welcome as is any and all > related information. > > James > > howdy, you might also like to see about GFS2, OCFS and OrangeFS. GFS2 for me was major effort to get going on gentoo, OCFS worked almost out of the box, but is from oracle. in all cases writes were the biggest hurdle for me due to the distributed lock mechanisms ymmv
Re: [gentoo-user] File system testing
On 17/09/14 19:21, J. Roeleveld wrote: > AFS has caching and can survive temporary disappearance of the server. > For me, I need to be able to provide Samba filesharing on top of that > layer on 2 different locations as I don't see the network bandwidth to > be sufficient for normal operations. (ADSL uplinks tend to be dead > slow) -- Joost Riverbed wan appliances were always great for this. I would have loved to see an open source version of their hash-zip-send as it worked amazingly well. however, from [1] you can mount.cifs with option fsc, and perhaps (sorry not tried myself) then use something like cachefs to make for a controlled size and location for that cache? also [2] might be of interest to you " fscEnable local disk caching using FS-Cache (off by default). This option could be useful to improve performance on a slow link, heavily loaded server and/or network where reading from the disk is faster than reading from the server (over the network). This could also impact scalability positively as the number of calls to the server are reduced. However, local caching is not suitable for all workloads for e.g. read-once type workloads. So, you need to consider carefully your workload/scenario before using this option. Currently, local disk caching is functional for CIFS files opened as read-only. " [1] https://www.kernel.org/doc/readme/Documentation-filesystems-cifs-README [2] http://www.cyberciti.biz/faq/centos-redhat-install-configure-cachefilesd-for-nfs/
Re: [gentoo-user] Re: /dev/ttyUSB* group changed from uucp to root?
On Thu, Sep 25, 2014 at 11:28 AM, Grant Edwards
wrote:
> On 2014-09-25, Mike Gilbert wrote:
>> On Wed, Sep 24, 2014 at 6:28 PM, Grant Edwards
>> wrote:
>>> On 2014-09-24, Neil Bothwick wrote:
On Wed, 24 Sep 2014 19:42:56 + (UTC), Grant Edwards wrote:
> After an update yesterday, I've noticed that the group assigned to
> ttyUSB devices has changed from uucp to root. Non-USB serial ports
> still seem to be uucp.
What did you update? They are still root:uucp here.
>>>
>>> Several things got updated, but the most likely suspect is probably
>>> sys-fs/udev-215-r1 => sys-fs/udev-216. But, I don't see any changes
>>> in the default rules to account for the change in behavior.
>>>
>>
>> I'm running systemd-216, and I see this in
>> /lib/udev/rules.d/50-udev-default.rules:
>>
>> KERNEL=="tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*",
>> GROUP="uucp"
>>
>> I suppose it is possible that some later rule overrides it, but I
>> don't see anything obvious.
>
> Yes, I saw that rule (and it hasn't changed recently). I also have a
> rule that creates a symlink for a certain USB-serial adapter in
> /etc/udev/rules.d/99-user.rules:
>
> SUBSYSTEMS=="usb",\
> ATTRS{product}=="FT232R USB UART",\
> ATTRS{serial}=="AH026Q3X",\
> KERNEL=="ttyUSB*",\
> SYMLINK+="ttyDBG",\
> GROUP="uucp"
>
> I didn't used to need to set the GROUP in that rule, the device file
> just defaulted to having a group of uucp. Yesterday, I had to add the
> "GROUP" command to get the behavior I always used to get without it.
You could try using udevadm test to see what rules are firing.
sudo udevadm test --action=add /sys/class/tty/ttyUSB0
Re: [gentoo-user] Reverse Tethering - How to?
On 17/09/14 10:24, Helmut Jarausch wrote: > Hi, > > how do I need to configure my Gentoo box to allow for reverse > tethering from my (rooted) Android phone? > > Many thanks for a hint, > Helmut > not sure if you can do this even on a rooted phone. the trouble is that usb tethering starts a dhcp server running on the usb side, and also keeps it's own default gateway to 3G or wherever. you'd need to be able to setup routing on the rooted phone. for just web pages, you might try to setup squidproxy on the gentoo box, and then configure the phone to use the proxy server. or you might be better off with a usb wifi dongle for the gentoo box and setting up hostapd
Re: [gentoo-user] [Security] Update bash *NOW*
On Thu, Sep 25, 2014 at 01:54:10PM +0100, Kerin Millar wrote > On 25/09/2014 02:58, Walter Dnes wrote: > > [snip] > > > ...with malicious stuff, and it could get ugly. app-shells/bash-4.2_p48 > > has been pushed to Gentoo stable. The same "env" command results in... > > Unfortunately, that version did fully address the problem. Instead, > upgrade to 4.2_p48-r1 or any of the -r1 revision bumps that were > recently committed. For further details: > > https://bugs.gentoo.org/show_bug.cgi?id=523592 > > --Kerin OK, I've got app-shells/bash-4.2_p48-r1 installed now. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Thu, Sep 25, 2014 at 07:03:02PM +, James wrote > Samuli Suominen gentoo.org> writes: > > > > > Any other caveats (short term) on switching udev to eudev? > > > in fact, from what I last checked, eudev's networking is at same level > > with udev-208, from time before the .link support at all > > ah, back when ethernet defaulted to eth0 not "enp5s0" ? I buy machines with one ethernet interface. What I find particularly annoying is this doublespeak about calling it "predictable". Before the change, it was predicatbly "eth0". Now, it's different on every different model. -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-user] mesos and openstack
Hello, Here an short article talks about mesos and openstack. http://openstacksv.com/2014/09/02/make-no-small-plans/ enjoy, James
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/2014 02:23, Walter Dnes wrote: > On Thu, Sep 25, 2014 at 07:03:02PM +, James wrote >> Samuli Suominen gentoo.org> writes: >> >> Any other caveats (short term) on switching udev to eudev? >> >>> in fact, from what I last checked, eudev's networking is at same level >>> with udev-208, from time before the .link support at all >> >> ah, back when ethernet defaulted to eth0 not "enp5s0" ? > > I buy machines with one ethernet interface. What I find particularly > annoying is this doublespeak about calling it "predictable". Before the > change, it was predicatbly "eth0". Now, it's different on every > different model. > It's not doublespeak, the interfaces are named exactly according to where they are on the PCI bus. If you had two interfaces, they show up to the kernel in random order by time and sometimes eth0/eth1 are nto the same they were before the reboot. You are just looking at this from the wrong point of view. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 25/09/14 22:03, James wrote: > Samuli Suominen gentoo.org> writes: > > >>> Any other caveats (short term) on switching udev to eudev? >> in fact, from what I last checked, eudev's networking is at same level >> with udev-208, from time before the .link support at all > ah, back when ethernet defaulted to eth0 not "enp5s0" ? nope, 208 was back when 80-net-name-slot.rules predictable rules were used which ignored kernel metadata for predictable networking i.e. the insufficient implementatition, which got replaced by 99-default.link and 80-net-link-setup.rules what you are referring is the buggy pre-udev-197 networking, which you can unfortunately still get with USE="rule-generator", it will keep renaming your interfaces despite kernel telling not to, so kernel drivers that mark eth0 as stable, might get renamed to eg. eth1 if you have 2 cards it's really messy, only 209 (and higher) handles things right, the new .link setup, with kernel naming support > > >> eudev is really useful only for sys-libs/musl users at this time, but >> you are free to experiment with it! > so lilblue (Anthony's amd64 hardened gentoo) is the only candidate I can > think of with musl? So I choose this, then profile must be set to: > > (eslect profile list): > [16] hardened/linux/musl/amd64 > > > I'd be better of with a fresh install of lilblue + musl + eudev > is what you are really saying here? > > > that's the only usecase for eudev currently, yes, otherwise you have no reason to switch
