Re: [gentoo-user] Re: udev (viable) alternatives ?
On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: 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. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. -- Neil Bothwick The gene pool could use a little chlorine. signature.asc Description: PGP signature
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: 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. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51 -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Fri, 26 Sep 2014 03:22:16 -0500, Canek Peláez Valdés wrote: That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. It certainly was the case. I couldn't test it directly because this laptop doesn't have support for such devices, but plugging, unplugging and replugging a USB ethernet adaptor resulted in a change of device number. I just switched to a different machine and it does indeed give the same name now, so things have been fixed and the interface names are now predictable. Ugly as hell, hard to remember, but they are predictable. -- Neil Bothwick Make it idiot proof and someone will make a better idiot. signature.asc Description: PGP signature
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/14 11:22, Canek Peláez Valdés wrote: On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: 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. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51 I've seen this happening once on a cheap laptop with a stripped down BIOS I can't even recall brand for, it had a kludge in the BIOS settings for hotplugging, turning it off, allowed the port to remain same, turning it on, some machine specific code gets executed and the kernel interprets the same port as different port Bad hardware, bad hardware settings, maybe missing exception for that particular hardware type in the code that determines the name... I'm not sure, I don't have the machine anymore - Samuli
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/14 11:47, Samuli Suominen wrote: On 26/09/14 11:22, Canek Peláez Valdés wrote: On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: 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. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51 I've seen this happening once on a cheap laptop with a stripped down BIOS I can't even recall brand for, it had a kludge in the BIOS settings for hotplugging, turning it off, allowed the port to remain same, turning it on, some machine specific code gets executed and the kernel interprets the same port as different port Bad hardware, bad hardware settings, maybe missing exception for that particular hardware type in the code that determines the name... I'm not sure, I don't have the machine anymore - Samuli Later kernels *can mark interfaces predictable in a new form of metadata*, and udev = 209 can pick that information up, and then it won't do anykind of userspace renaming on it, since kernel has declared the interface name to be steady...predictable...always same, so I hope we are moving towards kernel assigning predictable names for all drivers and we can get rid of the userspace renaming of interfaces all together at some point I really believe this is a task for the kernel to provide predictable names, and all this userspace renaming is just a bandage we can hopefully soon rip off - Samuli
Re: [gentoo-user] Reverse Tethering - How to?
2014-09-17 17:53 GMT+08:00 Helmut Jarausch jarau...@igpm.rwth-aachen.de: On 09/17/2014 11:50:58 AM, J. Roeleveld wrote: On Wednesday, September 17, 2014 11:46:12 AM Helmut Jarausch wrote: On 09/17/2014 11:43:28 AM, J. Roeleveld wrote: On Wednesday, September 17, 2014 11:24:36 AM 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 What do you mean with reverse tethering? That your mobile uses the network connection of your Gentoo box, or your Gentoo box the network connection of your mobile? My mobile should be able to use the (wired) network connection of my Gentoo box. Ok, I assumed that was the case, but wanted to be sure. Generally, the device sharing the connection needs to play WIFI Access Point. How to do that on Gentoo? If your Gentoo box has a wired connection and a wireless one. The wired is currently used and the wireless is not. Then you need to get your wireless card to function as an access point. (Google for Gentoo Linux Howto WIFI Access Point or similar) and you should find some information on how to do this. I should have made it more clear. My GenToo box doesn't have a wireless card. I'd like to connect my mobile to the USB port of my Gentoo box and get access to the (wired) network. Thanks, Helmut I had the same issue. I wrote a small script for that. If my memory is good, it was working pretty good apart for the google play (don't remember the reason thou). ``` #!/bin/bash ifconfig usb0 192.168.42.135 up echo 1 /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE adb start-server adb shell su -c '/system/xbin/busybox ifconfig usb0 192.168.42.130 up' adb shell su -c '/system/xbin/busybox route add -net default gw 192.168.42.135 usb0' adb shell su -c 'setprop net.dns1 8.8.8.8' adb shell su -c 'setprop net.dns2 8.8.8.4' ```
[gentoo-user] Re: /dev/ttyUSB* group changed from uucp to root?
On 2014-09-25, Mike Gilbert flop...@gentoo.org wrote: On Thu, Sep 25, 2014 at 11:28 AM, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2014-09-25, Mike Gilbert flop...@gentoo.org wrote: On Wed, Sep 24, 2014 at 6:28 PM, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2014-09-24, Neil Bothwick n...@digimed.co.uk 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 The test trace shows that rule setting the group to 14 (uucp). I suppose it is possible that some later rule overrides it, but I don't see anything obvious. It appears to be overridden by /lib64/udev/rules.d/99-openocd.rules Which sets the group to 0 (root). The weird thing is that I don't know where that file came from. Dong an equery belongs doesn't show it belonging to any package. I do have dev-embedded/openocd installed, but it doesn't own that file... But, doing an emerge -C openocd removed the file /lib64/udev/rules.d/99-openocd.rules. It looks like a bug in the openOCD rules is causing it to recognize somthing that it shouldn't. Checking the emerge logs shows that openocd was emerged about a week prior to the udev update (and I must have been mistaken about exactly when the failure started). -- Grant
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Fri, 26 Sep 2014 12:04:47 +0300, Samuli Suominen (ssuomi...@gentoo.org) wrote about Re: [gentoo-user] Re: udev (viable) alternatives ? (in 54252c2f.1030...@gentoo.org): [snip] Later kernels *can mark interfaces predictable in a new form of metadata*, and udev = 209 can pick that information up, and then it won't do anykind of userspace renaming on it, since kernel has declared the interface name to be steady...predictable...always same, so I hope we are moving towards kernel assigning predictable names for all drivers and we can get rid of the userspace renaming of interfaces all together I hope these kernel-assigned interface names are configurable, as I have been naming the interfaces on my machines with *mnemonic* names for many years now. [These are names like inet and lan for interfaces that connect the machine to the Internet or my LAN.] I certainly do not want to go back to eth0 and the like -- or worse still, udev's predictable names -- as these are not mnemonic in any way. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Re: [gentoo-user] Re: /dev/ttyUSB* group changed from uucp to root?
On Fri, Sep 26, 2014 at 12:12 PM, Grant Edwards grant.b.edwa...@gmail.com wrote: Which sets the group to 0 (root). The weird thing is that I don't know where that file came from. Dong an equery belongs doesn't show it belonging to any package. I do have dev-embedded/openocd installed, but it doesn't own that file... But, doing an emerge -C openocd removed the file /lib64/udev/rules.d/99-openocd.rules. udev rules get installed to /lib/udev/rules.d, not /lib64/udev/rules.d. Most Gentoo systems have a symlink at /lib pointing at /lib64, but equery does not look at this. It only looks at the contents of /var/db/pkg/*/*/CONTENTS, which would contain lib instead of lib64.
[gentoo-user] Re: devmanual searching
Jc García jyo.garcia at gmail.com writes: There's 'app-doc/devmanual' that is basically the html files that make the devmanual but, if you have them in your pc you can convert them to plain text and grep them, plus you have the manual even if offline. Ok, some years (decades?) ago I use html2txt. It must have been part of a deprecated package, as now I do not find it. So what's the best method to convert the devmanual installed locally now, app-doc/devmanual~, to a singular large text file for searching? file:///usr/share/doc/devmanual/html/index.html I see many tools for converting text to html, but not the otherway? Besides are there probably newer, slicker ways to do this conversion to a singular flat text file, that I'm not aware of.. Then, with that flat file in the same dir as above, I'll just point the browser straight to the flat file version and use the searchbox built into the browser. all suggestions are most welcome. James
Re: [gentoo-user] Re: devmanual searching
On 09/26/2014 03:38 PM, James wrote: Jc García jyo.garcia at gmail.com writes: There's 'app-doc/devmanual' that is basically the html files that make the devmanual but, if you have them in your pc you can convert them to plain text and grep them, plus you have the manual even if offline. Ok, some years (decades?) ago I use html2txt. It must have been part of a deprecated package, as now I do not find it. app-text/html2text or dev-python/html2text? links -dump url also works.
Re: [gentoo-user] Re: devmanual searching
On Fri, 26 Sep 2014 19:38:27 + (UTC), James wrote: Ok, some years (decades?) ago I use html2txt. It must have been part of a deprecated package, as now I do not find it. So what's the best method to convert the devmanual installed locally now, app-doc/devmanual~, to a singular large text file for searching? app-text/html2text Note the extra e. -- Neil Bothwick Q. What is the difference between Queensland and yoghurt? A. Yoghurt has an active culture. signature.asc Description: PGP signature
[gentoo-user] Re: snapper (btrfs)
Neil Bothwick neil at digimed.co.uk writes: I use snapper from portage. Snapper itself works just fine. Good to know found that trying to integrate it into portage (before/after snapshots on every emerge) is just way too much overhead (it goes fast, but you end up with a bazillion snapshots). Also, I've had deadlock problems with deleting multiple snapshots at once, which is certainly a kernel problem. Also very good to know. Ftrace/trace-cmd/kernelshark surely would be great to use for this. http://zougloub.eu/overlay/sys-kernel/trace-cmd/ I have not tested this yet.. So, right now I'm using snapper to manage snapshots but I do not use time/event-based snapshots at all - I just create them when needed and clean them up manually, and carefully. Well my setup is going to be (2) 2T sata-3 drives in a mirrored configuration. So yea, manual will porbably be just fine for me too. 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. Sounds good. I grabbed a copy. I drop you a line, if I run into troubles using buttersnap. cheers, James
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/14 19:47, David W Noon wrote: On Fri, 26 Sep 2014 12:04:47 +0300, Samuli Suominen (ssuomi...@gentoo.org) wrote about Re: [gentoo-user] Re: udev (viable) alternatives ? (in 54252c2f.1030...@gentoo.org): [snip] Later kernels *can mark interfaces predictable in a new form of metadata*, and udev = 209 can pick that information up, and then it won't do anykind of userspace renaming on it, since kernel has declared the interface name to be steady...predictable...always same, so I hope we are moving towards kernel assigning predictable names for all drivers and we can get rid of the userspace renaming of interfaces all together I hope these kernel-assigned interface names are configurable, as I have been naming the interfaces on my machines with *mnemonic* names for many years now. [These are names like inet and lan for interfaces that connect the machine to the Internet or my LAN.] I certainly do not want to go back to eth0 and the like -- or worse still, udev's predictable names -- as these are not mnemonic in any way. Later kernel marks some drivers interface names predictable or stable, not sure which word is best to use here, and then udev won't rename it by default to anything. The kernel assigned name could be anything, and I doubt it's in the eth* namespace And they can still be renamed by custom rules, that won't change, it's just that they won't get renamed by *default* anymore
Re: [gentoo-user] Re: /dev/ttyUSB* group changed from uucp to root?
On 26/09/14 20:59, Mike Gilbert wrote: On Fri, Sep 26, 2014 at 12:12 PM, Grant Edwards grant.b.edwa...@gmail.com wrote: Which sets the group to 0 (root). The weird thing is that I don't know where that file came from. Dong an equery belongs doesn't show it belonging to any package. I do have dev-embedded/openocd installed, but it doesn't own that file... But, doing an emerge -C openocd removed the file /lib64/udev/rules.d/99-openocd.rules. udev rules get installed to /lib/udev/rules.d, not /lib64/udev/rules.d. Most Gentoo systems have a symlink at /lib pointing at /lib64, but equery does not look at this. It only looks at the contents of /var/db/pkg/*/*/CONTENTS, which would contain lib instead of lib64. That's why latest portage-utils supports: # qfile -b -v 99-openocd.rules The new -b argument allows to skip the directory. - Samuli
[gentoo-user] Playing timidity patches via keyboard?
Hi, I am looking for some sort of software, for which I have no words (neiter I am a native english speaker nor I am a musician...;): There is a program called Timidity, which is able to play midifiles and produce sound. The sound is taken from patchsets (GUS?). Is there any GPLed/OpensSource Software, which does the same thing but for notes I am playing on the midi keyboard? Thank you very much in advance for any help! Best regards, mcc
Re: [gentoo-user] Playing timidity patches via keyboard?
2014-09-26 23:42 GMT-06:00 meino.cra...@gmx.de: Hi, I am looking for some sort of software, for which I have no words (neiter I am a native english speaker nor I am a musician...;): There is a program called Timidity, which is able to play midifiles and produce sound. The sound is taken from patchsets (GUS?). Is there any GPLed/OpensSource Software, which does the same thing but for notes I am playing on the midi keyboard? Maybe 'media-sound/lmms' is what you are looking for? Homepage:http://lmms.sourceforge.net/ Thank you very much in advance for any help! Best regards, mcc
Re: [gentoo-user] Playing timidity patches via keyboard?
Jc García jyo.gar...@gmail.com [14-09-27 07:48]: 2014-09-26 23:42 GMT-06:00 meino.cra...@gmx.de: Hi, I am looking for some sort of software, for which I have no words (neiter I am a native english speaker nor I am a musician...;): There is a program called Timidity, which is able to play midifiles and produce sound. The sound is taken from patchsets (GUS?). Is there any GPLed/OpensSource Software, which does the same thing but for notes I am playing on the midi keyboard? Maybe 'media-sound/lmms' is what you are looking for? Homepage:http://lmms.sourceforge.net/ Thank you very much in advance for any help! Best regards, mcc not really...it plays samples (sound files). GUS patches are of higher quality as far as I know...
