Re: [gentoo-user] gentoo-systemd-only deprecation
On 01/08/2013 00:25, Stroller wrote: On 31 July 2013, at 22:43, Alan McKinnon wrote: ... Are we OK on this for now, or is there more to discuss? Yes, that's great. I'm glad we can be open and honest when we've got these kinds of problems. On other occasions I've worried that you might have driven away someone who was seeking help here, but I've felt like it wasn't my place to intervene. The only advice I can perhaps give you is to read the question twice and hesitate before replying. If you wait an hour before hitting reply, maybe you'll be less likely to do so with your initial certainty. You'll notice I post significantly less in the last 18 months or so. Most of that is when I did think twice, some still slips through though. Oh well. Shit happens I suppose I get to just deal with it :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Gentoo is so AWESOME
On 07/31/2013 02:05 PM, Michael Palimaka wrote: On 1/08/2013 04:34, Michael Orlitzky wrote: It seems a little rude to pop in, address them personally, and ask them each if they'd devote months of their time towards mentoring me. (Doing so can pressure someone into agreeing to something he doesn't want to do, or makes him reject you personally which many people find awkward.) I definitely understand that. I wonder if it would help if we had a page where developers could register their interest in being a mentor. I think that'd be a great idea. If each developer could state where their interests/expertise laid and what type of dev they'd be interested in mentoring, that could make the selection process more natural for both prospective devs and established devs. The problem I have is I don't know what I'd want to work on. I love vim, tmux, and fluxbox, but I believe they already have capable maintainers. I'm learning C and Python, and know PHP, so there's probably a bit I could learn about C and Python. And my competency in PHP may qualify me for some packages. Which ones, I don't know. Overall I just can't think of a reason for Gentoo to take me.
Re: [gentoo-user] Recommendation for CPU type in QEMU?
Am 01.08.2013 03:02, schrieb Walter Dnes: On Wed, Jul 31, 2013 at 11:45:48AM +0100, Kerin Millar wrote Please provide the content of /proc/cpuinfo on the host. The first one is my shiney almost new desktop (Dell Inspiron 660) and the second one is my hot backup (more like emergency backup, 6-year-old Dell Dimension 530). I'll be on the new machine unless it breaks. But I do want to be able to port the QEMU VM to the older machine as part of its hot backup status. On any other distro, it wouldn't matter, but I have -march=native in make.conf, so I do have to worry about keeping binaries compatable. If I build for Intel Core 2 Duo CPU E4600 on both machines, would I be losing noticable performance? Right now, it's just one Windows program that I'll be running occasionally. So I'd rather trade off a bit less speed on the new machine, versus compatability issues. I also prefer to be able to scp the VM disk images to the backup machine, rather than having to do a separate install on each machine. You can use march=native on your gentoo hosts, that's no problem, as long as you don't use it on your guests. That's the hole idea of VMs: being able to move the virtual machine to another machine, that might be completely different in terms of hardware. The goal is, to be machine independent. In your case, I'd say it would make sense to chose core2duo as qemu host cpu. Both of your host cpus support the feature set of core2duo, so no performance penalty for costly software emulation of missing cpu features :-) signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: Gentoo is so AWESOME
On Tue, 30 Jul 2013 19:48:19 -0400, Michael Orlitzky wrote: I want to become a dev, what's my next step? There is none. Help out, and maybe someone will notice you? Ok, I'm on it. Been doing it for years, and I know several other people in the same situation. It doesn't work, and recruitment numbers are plummeting. There needs to be an explicit, documented process. And someone devoted full-time to mentoring new recruits. I can think of no better long-term investment of the foundation's money. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 documents this from the new developer perspective. Note how it says to contact the recruiters if you don't already have found a mentor yourself. There is also http://www.gentoo.org/proj/en/devrel/recruiters/ which documents this from the inside, but when I wanted to become a developer I found that more useful documentation :-) So it is explicitly documented. Perhaps not well enough? In that case, let us know what you miss. Hans
[gentoo-user] Re: Gentoo is so AWESOME
On Wed, 31 Jul 2013 14:34:41 -0400, Michael Orlitzky wrote: It seems a little rude to pop in, address them personally, and ask them each if they'd devote months of their time towards mentoring me. (Doing so can pressure someone into agreeing to something he doesn't want to do, or makes him reject you personally which many people find awkward.) That doesn't sound rude to me at all. If you explain your interest and ask them if they know anyone that could be your mentor you can also avoid that pressure for the most part. And we're not talking months here either. I've just finished mentoring someone, and it probably took ~15 hours spread over a couple of months. Compared to some of the other Gentoo work not a huge commitment, and one that pays itself back by seeing an otherwise derelict part of Gentoo being maintained again. Hans
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
on 08/01/2013 12:59 AM Paul Hartman wrote the following:
If no disks are attached, I wonder if something is probing it?
I checked my dmesg and every time I plug in my eSATA enclosure, I see
this very similar message:
[156541.724580] ata7: exception Emask 0x10 SAct 0x0 SErr 0x404
action 0xe frozen
[156541.724587] ata7: irq_stat 0x0040, connection status changed
[156541.724593] ata7: SError: { CommWake DevExch }
[156541.724604] ata7: hard resetting link
[156551.725559] ata7: softreset failed (device not ready)
[156551.725567] ata7: hard resetting link
(and then a bunch of lines initializing all of the disks in the enclosure).
Me too. That's exactly how I use this Sata port, so it must be related
to the way the kernel handles/probes it.
BTW, I use a cable which is sata - eSata, i.e. sata for the
motherboard side and eSata for the external disk side, and I keep the
cable connected to the motherboard and the disk connected to the cable.
I just power on the eSata external disk enclosure whenever I need to use
the disk, and before switching the power off, I just unmount the disk.
Is that a correct procedure?
[gentoo-user] euse after portage upgrade
Hi All, Yesterday there was an portage upgrade and after that I got it if I would like to use euse: sayusi-desktop sayusi # euse -E gtk3 ERROR: $PORTDIR couldn't be determined What is it and why that variable not determined? I did not do anything and my machine was estarted since portage upgrade. According to the logs I use sys-apps/portage-2.1.13.2 - 07/30/2013 and gentoolkit package was re-emerged. Should I file a bug on bugs.gentoo.org? Thanks for any help! András -- -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu -- http://facebook.com/andras.csanyi -- Trust in God and keep your gunpowder dry! - Cromwell
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
on 08/01/2013 01:10 AM Bruce Hill wrote the following: On Wed, Jul 31, 2013 at 11:17:02PM +0300, Thanasis wrote: on 07/31/2013 10:06 PM Paul Hartman wrote the following: There are a few approaches to try figuring it out explained here: http://serverfault.com/questions/244944/linux-ata-errors-translating-to-a-device-name Looking into /sys/dev/block it seems like /dev/sda is on ata1 and /dev/sdb is on ata2, and since there is nothing else attached to the system, the ata6 problem may be related to a controller (as Bruce said), and hopefully not a disk drive. Sorry I don't have time to reply atm. If either drive has errors continuing, please change the SATA cable for a new one. Or, at least, reseat them, and aftewards report results. I keep the cable connected to both the motherboard's sata port and to the external eSata disk enclosure. I noticed that the cable indeed needed reseating, but on the other hand, the external disk had *not* been powered on since last reboot, i.e. before these errors or warnings in dmesg had appeared. FWIW, after reseating the cable, I powered the external disk on, run a forced fsck on it, and no errors where reported.
Re: [gentoo-user] how to tell you are using systemd?
Wang Xuerui idontknw.w...@gmail.com wrote: 在 2013-8-1 上午10:26， cov...@ccs.covici.com写道： Can a shell script tell if systemd is the init? I have a couple of places where it would be nice to know this. Thanks in advance for any suggestions. Check /proc/1/comm or something like that, IIRC... OK, thanks. -- 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] euse after portage upgrade
On 08/01/2013 09:42:35 AM, András Csányi wrote: Hi All, Yesterday there was an portage upgrade and after that I got it if I would like to use euse: sayusi-desktop sayusi # euse -E gtk3 ERROR: $PORTDIR couldn't be determined What is it and why that variable not determined? I did not do anything and my machine was estarted since portage upgrade. According to the logs I use sys-apps/portage-2.1.13.2 - 07/30/2013 and gentoolkit package was re-emerged. Should I file a bug on bugs.gentoo.org? Thanks for any help! András I think this bug is known. A work-around is to add the line PORTDIR=/usr/portage (or something different if your portage tree is not in /usr/portage) to your /etc/portage/make.conf file Helmut
Re: [gentoo-user] gentoo-systemd-only deprecation
On Wed, Jul 31, 2013 at 02:00:23AM -0500, Canek Peláez Valdés wrote On Wed, Jul 31, 2013 at 1:24 AM, Daniel Campbell li...@sporkbox.us wrote: You need an OpenRC use flag to install OpenRC init scripts? That's simply a lie. An apology to Daniel might be in order. I start my USE flag with -*. During a recent install, I found out the hard way that eudev (and udev) do not install their init scripts without the openrc flag. As you can see from the ebuild fragments below, they require the openrc flag to pull in sys-fs/udev-init-scripts From sys-fs/udev/udev-197-r8.ebuild === PDEPEND==virtual/udev-197-r1 hwdb? ( =sys-apps/hwids-20130114[udev] ) openrc? ( =sys-fs/udev-init-scripts-19-r1 ) From sys-fs/eudev/eudev-1_beta4-r1.ebuild = PDEPEND==virtual/udev-180 openrc? ( =sys-fs/udev-init-scripts-18 ) -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] gentoo-systemd-only deprecation
On Wed, Jul 31, 2013 at 06:11:02PM +0530, Yohan Pereira wrote On 31/07/13 at 08:30am, Tanstaafl wrote: So, how should this be used to 'opt out of systemd completely'? from main make.conf Use this variable if you want to selectively prevent certain files from being copied into your file system tree. .. You can use it to prevent ebuilds from installing unit files or open-rc scripts from doing so (based on what you want to opt-out of). From the man page... INSTALL_MASK = [space delimited list of file names] I do not want to input umpteen files names, or even extensions. The man page says nothing about masking out directories. Here's what I had on my system a few minutes ago before executing rm -rf /usr/lib/systemd/ [i660][waltdnes][/usr/lib] ll -ogR /usr/lib/systemd /usr/lib/systemd: total 56 drwxr-xr-x 3 4096 May 12 20:42 . drwxr-xr-x 53 45056 Jul 28 03:18 .. drwxr-xr-x 4 4096 Jun 14 02:45 system /usr/lib/systemd/system: total 44 drwxr-xr-x 4 4096 Jun 14 02:45 . drwxr-xr-x 3 4096 May 12 20:42 .. -rw-r--r-- 1 155 Jun 14 02:45 acpid.service -rw-r--r-- 1 119 Jun 14 02:45 acpid.socket -rw-r--r-- 1 220 Jun 14 02:45 alsa-restore.service -rw-r--r-- 1 168 Jun 14 02:45 alsa-store.service drwxr-xr-x 2 4096 Jun 14 02:45 basic.target.wants drwxr-xr-x 2 4096 Jun 14 02:45 shutdown.target.wants -rw-r--r-- 1 242 May 12 19:27 sshd.service -rw-r--r-- 1 136 May 12 19:27 sshd.socket -rw-r--r-- 1 176 May 12 19:27 sshd@.service /usr/lib/systemd/system/basic.target.wants: total 8 drwxr-xr-x 2 4096 Jun 14 02:45 . drwxr-xr-x 4 4096 Jun 14 02:45 .. lrwxrwxrwx 1 23 Jun 14 02:45 alsa-restore.service - ../alsa-restore.service /usr/lib/systemd/system/shutdown.target.wants: total 8 drwxr-xr-x 2 4096 Jun 14 02:45 . drwxr-xr-x 4 4096 Jun 14 02:45 .. lrwxrwxrwx 1 21 Jun 14 02:45 alsa-store.service - ../alsa-store.service Maybe I should simply make a wrapper script that throws in... rm -rf /usr/lib/systemd/ at the end of an emerge. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] which VM do you recommend?
On Tuesday 30 Jul 2013 07:45:39 Helmut Jarausch wrote: Hi, I've been running a Windows 7 (professional)guest with Virtualbox on my GenToo system for some years. But recently I have a broken network either due to Virtualbox or due to some (automatic) Windows updates. The situation is more than strange. Sometime using a backed up Virtualbox image the network seems to work but only for a very short time (some minutes?) Windows error analyzing tools don't see any network problems but it does not work. Trying ping -n 100 IP only a few packets come back but with a large delay (40-50 times larger delay compared to ping on the GenToo host) Does ifconfig show dropped packets/errors? Is the mtu the same on MSWindows and Linux host and router? MSWindows can corrupt its TCP/IP stack, or if you try to modify its parameters too much (size of receive/send window et al) things could go wrong. There is some Microsoft fix file for this (I recall one available for WinXP at least) which resets the stack to its default values. On the odd occasion I had to stop/start an MSWindows connection which would not come up on boot up, but this hasn't happened for quite some time now. It might have been dodgy firmware on my router; I don' know and never found out what was the cause of it, because it only happened a few times. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] gentoo-systemd-only deprecation
On Thu, 1 Aug 2013 06:24:17 -0400, Walter Dnes wrote: You can use it to prevent ebuilds from installing unit files or open-rc scripts from doing so (based on what you want to opt-out of). From the man page... INSTALL_MASK = [space delimited list of file names] I do not want to input umpteen files names, or even extensions. The man page says nothing about masking out directories. Everything is a file, nor does the man page say anything about not using it to mask out directories. Bearing in mind that this is the means chosen by the devs, it is reasonable to assume that it is practicable. Maybe I should simply make a wrapper script that throws in... rm -rf /usr/lib/systemd/ at the end of an emerge. Or you could simply try INSTALL_MASK=/usr/lib/systemd/ in make.conf. It's not like your computer is going to explode if it fails to mask the service files. -- Neil Bothwick Women live longer than men because they have so many clothes that they wouldn't be caught dead in. signature.asc Description: PGP signature
[gentoo-user] Re: Gentoo is so AWESOME
The 01/08/13, Hans de Graaff wrote: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 documents this from the new developer perspective. Note how it says to contact the recruiters if you don't already have found a mentor yourself. There is also http://www.gentoo.org/proj/en/devrel/recruiters/ which documents this from the inside, but when I wanted to become a developer I found that more useful documentation :-) So it is explicitly documented. Perhaps not well enough? In that case, let us know what you miss. I've proposed myself some years ago. Things might have changed since then but at that time the mail I sent to the dev list got no response. Process recruitement is incredibely busy and over-complicated compared to all other projects I've been involved into. I think this stands like that because most developers are afraid to give wirte acces to the whole portage CVS tree to others. In all other projects, it's almost a question of subscribing to a mailing list and send git patches. With time, you get direct write access. With Gentoo, you have to find a mentor, officially call for being a member, success the online tests, keep mentored some time. Not very light and efficient... Now, I'm away from Gentoo and it's fine. :-) -- Nicolas Sebrecht
Re: [gentoo-user] Re: Gentoo is so AWESOME
On Thu, Aug 1, 2013 at 2:17 PM, Nicolas Sebrecht nsebre...@piing.fr wrote: The 01/08/13, Hans de Graaff wrote: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 documents this from the new developer perspective. Note how it says to contact the recruiters if you don't already have found a mentor yourself. There is also http://www.gentoo.org/proj/en/devrel/recruiters/ which documents this from the inside, but when I wanted to become a developer I found that more useful documentation :-) So it is explicitly documented. Perhaps not well enough? In that case, let us know what you miss. I've proposed myself some years ago. Things might have changed since then but at that time the mail I sent to the dev list got no response. Process recruitement is incredibely busy and over-complicated compared to all other projects I've been involved into. I think this stands like that because most developers are afraid to give wirte acces to the whole portage CVS tree to others. In all other projects, it's almost a question of subscribing to a mailing list and send git patches. I don't see the major difference between that and opening a bug and attaching the patch. Only that bugzilla allow to manage the process, not have leftovers, and future people can resume past discussions. With time, you get direct write access. In time you can be become either proxy maintainer or gentoo developer (direct access to source repository). With Gentoo, you have to find a mentor, officially call for being a member, success the online tests, keep mentored some time. Not very light and efficient... Can you please suggest a different method to ensure quality? Now, I'm away from Gentoo and it's fine. :-) -- Nicolas Sebrecht
Re: [gentoo-user] euse after portage upgrade
On 1 August 2013 11:18, Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote: On 08/01/2013 09:42:35 AM, András Csányi wrote: Hi All, Yesterday there was an portage upgrade and after that I got it if I would like to use euse: sayusi-desktop sayusi # euse -E gtk3 ERROR: $PORTDIR couldn't be determined What is it and why that variable not determined? I did not do anything and my machine was estarted since portage upgrade. According to the logs I use sys-apps/portage-2.1.13.2 - 07/30/2013 and gentoolkit package was re-emerged. Should I file a bug on bugs.gentoo.org? Thanks for any help! András I think this bug is known. A work-around is to add the line PORTDIR=/usr/portage (or something different if your portage tree is not in /usr/portage) to your /etc/portage/make.conf file Hi Helmut, Thanks for the solution. -- -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu -- http://facebook.com/andras.csanyi -- Trust in God and keep your gunpowder dry! - Cromwell
[gentoo-user] Re: Gentoo is so AWESOME
The 01/08/13, Alon Bar-Lev wrote: I don't see the major difference between that and opening a bug and attaching the patch. Only that bugzilla allow to manage the process, not have leftovers, and future people can resume past discussions. The bugzilla thing is what makes the difference, IMHO. git-push and git-send-email are one shoot simple commands to get things done. Having to open the web browser, connect to bugzilla, attach the patch and comment online is too much busy. With Gentoo, you have to find a mentor, officially call for being a member, success the online tests, keep mentored some time. Not very light and efficient... Can you please suggest a different method to ensure quality? Yes, having a few maintainers team with write access to the whole portage tree and contributors sending patches to them or to official package maintainers making the first review before they do the merge and submit to the main maintainers. Something like the kernel with the main maintainers, the lieutenants and open contributors. -- Nicolas Sebrecht
Re: [gentoo-user] Re: Gentoo is so AWESOME
On 08/01/2013 02:11 PM, Nicolas Sebrecht wrote: The 01/08/13, Alon Bar-Lev wrote: I don't see the major difference between that and opening a bug and attaching the patch. Only that bugzilla allow to manage the process, not have leftovers, and future people can resume past discussions. The bugzilla thing is what makes the difference, IMHO. git-push and git-send-email are one shoot simple commands to get things done. Having to open the web browser, connect to bugzilla, attach the patch and comment online is too much busy. You can use the command line too. www-client/pybugz With Gentoo, you have to find a mentor, officially call for being a member, success the online tests, keep mentored some time. Not very light and efficient... Can you please suggest a different method to ensure quality? Yes, having a few maintainers team with write access to the whole portage tree and contributors sending patches to them or to official package maintainers making the first review before they do the merge and submit to the main maintainers. Something like the kernel with the main maintainers, the lieutenants and open contributors. Git workflow has been on the todo list for a long time, as well as review systems such as gerrit. It is non trivial to implement and none of it is an excuse for not contributing IMO ;) Those are enhancements and we are already working on it. Get your hands dirty.
[gentoo-user] Re: Gentoo is so AWESOME
The 01/08/13, hasufell wrote: You can use the command line too. www-client/pybugz I know this tool. I did try it. At that time it was buggy and did not work for me. Though, this would still be a busy process as this is just another interface og the bugzilla thing. Git workflow has been on the todo list for a long time, as well as review systems such as gerrit. It is non trivial to implement Other than the git repository size requiring a huge initial clone, it's very easy to do. And yes, I've read all the headaches on the Gentoo mailing lists about the git migration. Also, Gentoo organization has two heads making ambitious dicisions hard to take. And AFAIKS, to decision process in Gentoo is not helping at all. We are far from how it worked at the genesis/beginning of Gentoo. It is non trivial to implement and none of it is an excuse for not contributing IMO ;) Those are enhancements and we are already working on it. Get your hands dirty. Oh, yes. Pass the recruitement process to enhance the recruitement process, workflow and decision process (not possible to change, IMO). Funny! :-) Again, I proposed myself to the dev list two times in the past. Nobody cared and I had no answers. -- Nicolas Sebrecht
Re: [gentoo-user] Re: Gentoo is so AWESOME
On 08/01/2013 03:15 PM, Nicolas Sebrecht wrote: The 01/08/13, hasufell wrote: You can use the command line too. www-client/pybugz I know this tool. I did try it. At that time it was buggy and did not work for me. Though, this would still be a busy process as this is just another interface og the bugzilla thing. Git workflow has been on the todo list for a long time, as well as review systems such as gerrit. It is non trivial to implement Other than the git repository size requiring a huge initial clone, it's very easy to do. Let's not make this yet another git migration discussion. Sufficient to say, that it is not trivial to implement in Gentoo since we have to migrate history, tools (not just end-user tools, this is also about infra) and a lot of other stuff without breaking everything. Also: A lot of gentoo projects have an overlay on github or similar where they accept pull requests already. Including sunrise. Also, Gentoo organization has two heads making ambitious dicisions hard to take. And AFAIKS, to decision process in Gentoo is not helping at all. We are far from how it worked at the genesis/beginning of Gentoo. There is a lot of room for improvement in the political aspects of gentoo. In order to change it, you have to get more involved. It is non trivial to implement and none of it is an excuse for not contributing IMO ;) Those are enhancements and we are already working on it. Get your hands dirty. Oh, yes. Pass the recruitement process to enhance the recruitement process, workflow and decision process (not possible to change, IMO). Funny! :-) Again, I proposed myself to the dev list two times in the past. Nobody cared and I had no answers. I think the dev ML is not the right place to ask for a mentor, you actually have to _find_ one. Discuss on IRC, help out on bugzie, send pull requests to official gentoo overlays and then you might already know a few devs who work in that area you are intested in. If you are unable to find one, the recruiters will help you with that, just contact them. Also: we approach people ourselves who force us to commit for them every single time. It is annoying, so we want them to become devs ;)
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
Hello,
On Wed, 31 Jul 2013, Paul Hartman wrote:
http://serverfault.com/questions/244944/linux-ata-errors-translating-to-a-device-name
All flawed IMHO. My version (works with PATA too), possibly flawed too:
~/bin/ataid_to_drive.sh
#!/bin/bash
oIFS=$IFS
IFS=$'\n'
CTRLS=( $(/sbin/lspci | grep 'ATA\|IDE') )
IFS=$oIFS
for arg; do
if test -z ${arg/ata*}; then
arg=${arg/ata}
fi
if test -z ${arg/*.*}; then
ata=${arg%.*}
subid=$(printf %i ${arg##*.})
else
ata=$arg
fi
echo ata${ata}${subid/*/.$(printf %02i $subid)} is:
for ctrl in ${CTRLS[@]%% *}; do
idpath=/sys/bus/pci/devices/*${ctrl}/*/*/*/unique_id
grep ^${ata}$ $idpath 2/dev/null
host=$(grep ^${ata}$ $idpath 2/dev/null | \
sed 's@.*/host\([0-9A-Fa-f]\+\)/.*@\1@')
if test -n $host; then
dmesg | grep \] s[dr] $host:0:$subid.*Attached
fi
done
done
Usage samples:
$ ataid_to_drive.sh ata23.00
$ ataid_to_drive.sh ata23.01
$ ataid_to_drive.sh ata23
$ ataid_to_drive.sh 23.01
$ ataid_to_drive.sh 23.1
$ ataid_to_drive.sh 23
$ ataid_to_drive.sh $(seq 1 4)
So you can use cp from dmest/syslog or enter the number(s) yourself.
HTH,
-dnh
--
This space intentionally left aligned.
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
On Thu, Aug 1, 2013 at 2:51 AM, Thanasis thana...@asyr.hopto.org wrote: on 08/01/2013 01:10 AM Bruce Hill wrote the following: On Wed, Jul 31, 2013 at 11:17:02PM +0300, Thanasis wrote: on 07/31/2013 10:06 PM Paul Hartman wrote the following: There are a few approaches to try figuring it out explained here: http://serverfault.com/questions/244944/linux-ata-errors-translating-to-a-device-name Looking into /sys/dev/block it seems like /dev/sda is on ata1 and /dev/sdb is on ata2, and since there is nothing else attached to the system, the ata6 problem may be related to a controller (as Bruce said), and hopefully not a disk drive. Sorry I don't have time to reply atm. If either drive has errors continuing, please change the SATA cable for a new one. Or, at least, reseat them, and aftewards report results. I keep the cable connected to both the motherboard's sata port and to the external eSata disk enclosure. I noticed that the cable indeed needed reseating, but on the other hand, the external disk had *not* been powered on since last reboot, i.e. before these errors or warnings in dmesg had appeared. Some internal SATA ports apparently don't support hotplugging. I don't know if perhaps your chipset is one of them, if you Google your motherboard's SATA chipset maybe you can find out. If it has always worked before and now suddenly throws errors, that seems unlikely to be the cause... FWIW, after reseating the cable, I powered the external disk on, run a forced fsck on it, and no errors where reported. Or maybe that's all it was. :)
Re: [gentoo-user] euse after portage upgrade
On Thu, Aug 1, 2013 at 2:42 AM, András Csányi sayusi.a...@sayusi.hu wrote: Hi All, Yesterday there was an portage upgrade and after that I got it if I would like to use euse: sayusi-desktop sayusi # euse -E gtk3 ERROR: $PORTDIR couldn't be determined What is it and why that variable not determined? I did not do anything and my machine was estarted since portage upgrade. According to the logs I use sys-apps/portage-2.1.13.2 - 07/30/2013 and gentoolkit package was re-emerged. Should I file a bug on bugs.gentoo.org? When I upgraded portage yesterday, it added this PORTDIR line to make.conf for me when I ran etc-update. Did you update your config files after upgrading portage?
Re: [gentoo-user] euse after portage upgrade
On 1 August 2013 16:16, Paul Hartman paul.hartman+gen...@gmail.com wrote: When I upgraded portage yesterday, it added this PORTDIR line to make.conf for me when I ran etc-update. Did you update your config files after upgrading portage? I remember there was an etc-update, but make.conf was not among those files where an update is required as far as I remember. Hopefully, I was not pay any attention. I did the update manually and the error message disappeared. -- -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu -- http://facebook.com/andras.csanyi -- Trust in God and keep your gunpowder dry! - Cromwell
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
On Thu, Aug 01, 2013 at 10:51:56AM +0300, Thanasis wrote: I keep the cable connected to both the motherboard's sata port and to the external eSata disk enclosure. The _only_ time that I am _certain_ I've received that particular error is in a very similar case. My workstation has 2 SATA cables plugged to the motherboard and hanging out of it. Both of them have given such errors before. Internal SATA connectors are a poor design; external (eSATA) is much better. And sometimes one cable works and not the other. I noticed that the cable indeed needed reseating, but on the other hand, the external disk had *not* been powered on since last reboot, i.e. before these errors or warnings in dmesg had appeared. FWIW, after reseating the cable, I powered the external disk on, run a forced fsck on it, and no errors where reported. That might not have been necessary, because according to the error the device was disconnected. Glad you have solved your issue. In order to test/fix/backup/use external drives I'm thinking of purchasing a SATA to eSATA Slot Plate Bracket http://www.amazon.com/StarTech-eSATA-Plate-Bracket-ESATAPLATE2/dp/B000NPKGH4/ref=sr_1_2?s=electronicsie=UTF8qid=1375365716sr=1-2keywords=SATA+to+eSATA+Slot+Plate+Bracket and an eSATA enclosure, something like this http://www.sabrent.com/category/hard-drive-enclosures/ECS-STU35K/ -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
On Thu, Aug 01, 2013 at 10:37:34AM +0300, Thanasis wrote: Me too. That's exactly how I use this Sata port, so it must be related to the way the kernel handles/probes it. BTW, I use a cable which is sata - eSata, i.e. sata for the motherboard side and eSata for the external disk side, and I keep the cable connected to the motherboard and the disk connected to the cable. I just power on the eSata external disk enclosure whenever I need to use the disk, and before switching the power off, I just unmount the disk. Is that a correct procedure? The problem is more than likely with the SATA cable plugged to the motherboard. How is the cable routed from the motherboard to the external enclosure? If it's not stable, that can cause this problem; which is why my present thought is to buy 2 items as shown in the previous post. -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] Re: gentoo-systemd-only deprecation
On Thu, 1 Aug 2013 12:15:28 +0100 Neil Bothwick n...@digimed.co.uk w On Thu, 1 Aug 2013 06:24:17 -0400, Walter Dnes wrote: You can use it to prevent ebuilds from installing unit files or open-rc scripts from doing so (based on what you want to opt-out of). From the man page... INSTALL_MASK = [space delimited list of file names] I do not want to input umpteen files names, or even extensions. The man page says nothing about masking out directories. Everything is a file, nor does the man page say anything about not using it to mask out directories. Bearing in mind that this is the means chosen by the devs, it is reasonable to assume that it is practicable. Elsewhere, man make.conf uses [space delimited list of files and/or directories], e.g. when describing CONFIG_PROTECT's value. IMO it's reasonable to expect the man page to be consistent.
[gentoo-user] Recent 'breakage' of kernel module auto-loading?
For months I've been using apps that need the tun and fuse kernel modules, and I've never needed to modprobe those two modules until about a week ago. The modules were loaded automagically when those apps started up. (I never understood how that happened, BTW.) Suddenly those two apps won't start until I manually load those kernel modules first. Anyone else seeing this new behavior?
Re: [gentoo-user] Re: gentoo-systemd-only deprecation
On Thu, 1 Aug 2013 10:46:04 -0500, »Q« wrote: Everything is a file, nor does the man page say anything about not using it to mask out directories. Bearing in mind that this is the means chosen by the devs, it is reasonable to assume that it is practicable. Elsewhere, man make.conf uses [space delimited list of files and/or directories], e.g. when describing CONFIG_PROTECT's value. IMO it's reasonable to expect the man page to be consistent. Reasonable yes, but also a little optimistic considering the way it has grown organically. However that doesn't change my main point , that one could simply try it - which is how I determined that directories worked. -- Neil Bothwick We shall shortly be landing. Please return your stewardess to the upright position. signature.asc Description: PGP signature
Re: [gentoo-user] gentoo-systemd-only deprecation
On Thu, Aug 1, 2013 at 4:43 AM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Jul 31, 2013 at 02:00:23AM -0500, Canek Peláez Valdés wrote On Wed, Jul 31, 2013 at 1:24 AM, Daniel Campbell li...@sporkbox.us wrote: You need an OpenRC use flag to install OpenRC init scripts? That's simply a lie. An apology to Daniel might be in order. I start my USE flag with -*. During a recent install, I found out the hard way that eudev (and udev) do not install their init scripts without the openrc flag. As you can see from the ebuild fragments below, they require the openrc flag to pull in sys-fs/udev-init-scripts From sys-fs/udev/udev-197-r8.ebuild === PDEPEND==virtual/udev-197-r1 hwdb? ( =sys-apps/hwids-20130114[udev] ) openrc? ( =sys-fs/udev-init-scripts-19-r1 ) From sys-fs/eudev/eudev-1_beta4-r1.ebuild = PDEPEND==virtual/udev-180 openrc? ( =sys-fs/udev-init-scripts-18 ) udev/eudev are special cases: the first is systemd with systemd removed at make install time; the second is a fork of systemd with systemd exorcised. The systemd package also uses the openrc USE flag to install OpenRC init scripts; I hope you agree that it is also an special case (systemd, which is a whole init system, provides init scripts for another init system). The package sys-apps/kmod also uses the openrc USE flag to install an init script, which Create[s] [a] list of required static device nodes for the current kernel. I have no idea why this is necessary, but kmod is a dependency of systemd, and the developers of both projects collaborate a lot between them. No other package in the tree uses an openrc USE flag (or at least they don't appear in /usr/portage/profiles/use.local.desc), except for plymouth, and that it's to install a plugin for OpenRC, not to install its OpenRC scripts. So no package in the tree uses an openrc USE flag to install init scripts, except for one somewhat related to systemd, two forks and/or special handling of systemd, and systemd itself. In *ALL* the other packages in the tree, the OpenRC init scripts are installed unconditionally, as the systemd unit files are. And that's how it should be. Lastly, the ebuilds for udev/eudev should work out of the box in a sane configuration. You have been told several times, both by users and developers, that USE=-* is not really supported; you broke your system by using it, you get to keep the pieces. Gentoo is about choice (or so I keep hearing); that doesn't mean it shouldn't strive to have sane defaults that keep the majority happy: http://blogs.gentoo.org/mgorny/2013/07/23/keeping-the-majority-happy/ Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] Moving from old udev to eudev
Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone?
Re: [gentoo-user] Recent 'breakage' of kernel module auto-loading?
On Thu, Aug 1, 2013 at 11:04 AM, walt w41...@gmail.com wrote: For months I've been using apps that need the tun and fuse kernel modules, and I've never needed to modprobe those two modules until about a week ago. The modules were loaded automagically when those apps started up. (I never understood how that happened, BTW.) Suddenly those two apps won't start until I manually load those kernel modules first. Anyone else seeing this new behavior? Yeah, months and months ago. I didn't gave much thought to the matter, I just created /etc/modules-load.d/fuse.conf, with the single line fuse (don't use tun). That works with systemd, but I think they were thinking in adding support for modules-load.d in OpenRC. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
Am 01.08.2013 09:37, schrieb Thanasis:
on 08/01/2013 12:59 AM Paul Hartman wrote the following:
If no disks are attached, I wonder if something is probing it?
I checked my dmesg and every time I plug in my eSATA enclosure, I see
this very similar message:
[156541.724580] ata7: exception Emask 0x10 SAct 0x0 SErr 0x404
action 0xe frozen
[156541.724587] ata7: irq_stat 0x0040, connection status changed
[156541.724593] ata7: SError: { CommWake DevExch }
[156541.724604] ata7: hard resetting link
[156551.725559] ata7: softreset failed (device not ready)
[156551.725567] ata7: hard resetting link
(and then a bunch of lines initializing all of the disks in the enclosure).
Me too. That's exactly how I use this Sata port, so it must be related
to the way the kernel handles/probes it.
BTW, I use a cable which is sata - eSata, i.e. sata for the
motherboard side and eSata for the external disk side, and I keep the
cable connected to the motherboard and the disk connected to the cable.
I just power on the eSata external disk enclosure whenever I need to use
the disk, and before switching the power off, I just unmount the disk.
Is that a correct procedure?
.
that is not an error. That is the linux kernel initializing the sata
connection.
stuff like that always happens if you hotplug a (e)sata device.
Re: [gentoo-user] Moving from old udev to eudev
On Thu, Aug 1, 2013 at 11:28 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? (I haven't done it myself, but...) I assume one would simply unmerge sys-fs/udev and emerge sys-fs/eudev and then do any configuration file changes necessary. virtual/udev covers the possibility of using either package. Unless you're asking more about the configuration changes themselves, in which case I have no idea.
Re: [gentoo-user] Moving from old udev to eudev
On 2013-08-01 12:28 PM, Tanstaafl tansta...@libertytrek.org wrote: I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. Neglected to mention, it is still running 171-r10
Re: [gentoo-user] Moving from old udev to eudev
Am 01.08.2013 18:28, schrieb Tanstaafl: I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. Well I also upgraded recently my system to udev 200. I still have got though the old interface names. This turned out pretty easy to achieve. Just boot your kernel with the following parameter: net.ifnames=0 (tell LILO/GRUB to do so) and you won't get any of those predictable network interface names AND running udev 200, it will still use your old established interface names.
Re: [gentoo-user] Moving from old udev to eudev
Am 01.08.2013 19:16, schrieb Marc Stürmer: net.ifnames=0 Worked like a charm to me. Forgot to mention the more thorough documentation though, so here it is: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ http://wiki.gentoo.org/wiki/Udev/upgrade You should read at last the latter from the official wiki.
[gentoo-user] Crossdev problems
Hi, System is an AMD64. I am trying to follow these instructions: http://dev.gentoo.org/~armin76/arm/beagleboneblack/install.xml and get problems while executing Build a crosscompiler Code Listing 3.2: Building a crosscompiler # crossdev -S armv7a-hardfloat-linux-gnueabi gcc --version gcc (Gentoo 4.6.3 p1.13, pie-0.5.2) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcc-config -l [1] x86_64-pc-linux-gnu-4.4.7 [2] x86_64-pc-linux-gnu-4.6.3 * After the command crossdev -S armv7a-hardfloat-linux-gnueabi failed once, I emerge -C all related installation (as given with eix -I) and tryied it again. It fails again. The output was: * gcc failed :( * If you file a bug, please attach the following logfiles: * /var/log/portage/cross-armv7a-hardfloat-linux-gnueabi-info.log * /var/log/portage/cross-armv7a-hardfloat-linux-gnueabi-gcc-stage1.log.xz * /var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabi/gcc*/temp/gcc-config.logs.tar.xz I do *not* include the above files here to not to pollute the mailinglist - but I will do it on request. How can I make the crossdev-command work? Best regards, mcc
Re: [gentoo-user] Moving from old udev to eudev
On Thursday 01 August 2013 12:28:38 Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? Maybe just mask sys-fs/udev? Then sys-fs/eudev will be pulled by virtual/udev, probably.
Re: [gentoo-user] Crossdev problems
On 01/08/13 at 08:07pm, meino.cra...@gmx.de wrote: Hi, System is an AMD64. I am trying to follow these instructions: http://dev.gentoo.org/~armin76/arm/beagleboneblack/install.xml and get problems while executing Build a crosscompiler Code Listing 3.2: Building a crosscompiler # crossdev -S armv7a-hardfloat-linux-gnueabi gcc --version gcc (Gentoo 4.6.3 p1.13, pie-0.5.2) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcc-config -l [1] x86_64-pc-linux-gnu-4.4.7 [2] x86_64-pc-linux-gnu-4.6.3 * After the command crossdev -S armv7a-hardfloat-linux-gnueabi failed once, I emerge -C all related installation (as given with eix -I) and tryied it again. It fails again. The output was: * gcc failed :( * If you file a bug, please attach the following logfiles: * /var/log/portage/cross-armv7a-hardfloat-linux-gnueabi-info.log * /var/log/portage/cross-armv7a-hardfloat-linux-gnueabi-gcc-stage1.log.xz * /var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabi/gcc*/temp/gcc-config.logs.tar.xz I do *not* include the above files here to not to pollute the mailinglist - but I will do it on request. Let me be the first to request that you include those files :D -- - Yohan Pereira The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
Re: [gentoo-user] Moving from old udev to eudev
On Thu, 01 Aug 2013 12:28:38 -0400, Tanstaafl wrote: I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. emerge -Ca udev emerge -1a eudev But there's not a lot of point as eudev isn't that different to udev now, AFAICT, and a recent update forced me to switch back to udev because eudev hadn't been updated (on ~amd64). -- Neil Bothwick Give me ambiguity or give me something else. signature.asc Description: PGP signature
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
on 08/01/2013 05:43 PM Bruce Hill wrote the following: On Thu, Aug 01, 2013 at 10:37:34AM +0300, Thanasis wrote: Me too. That's exactly how I use this Sata port, so it must be related to the way the kernel handles/probes it. BTW, I use a cable which is sata - eSata, i.e. sata for the motherboard side and eSata for the external disk side, and I keep the cable connected to the motherboard and the disk connected to the cable. I just power on the eSata external disk enclosure whenever I need to use the disk, and before switching the power off, I just unmount the disk. Is that a correct procedure? The problem is more than likely with the SATA cable plugged to the motherboard. How is the cable routed from the motherboard to the external enclosure? If it's not stable, that can cause this problem; which is why my present thought is to buy 2 items as shown in the previous post. I didn't say it from the start for simplicity's sake, but actually, I am using a bracket like the one you said, and the reseating was needed at the bracket's eSata (external) port. I think that there are specs for eSata cables and ports so that the connection between them is made secure and doesn't get easily loose, but in my case, either the (external) eSata cable or the Bracket's ports (or both cable and bracket) do not follow these specs.
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
on 08/01/2013 07:38 PM Volker Armin Hemmann wrote the following:
Am 01.08.2013 09:37, schrieb Thanasis:
on 08/01/2013 12:59 AM Paul Hartman wrote the following:
If no disks are attached, I wonder if something is probing it?
I checked my dmesg and every time I plug in my eSATA enclosure, I see
this very similar message:
[156541.724580] ata7: exception Emask 0x10 SAct 0x0 SErr 0x404
action 0xe frozen
[156541.724587] ata7: irq_stat 0x0040, connection status changed
[156541.724593] ata7: SError: { CommWake DevExch }
[156541.724604] ata7: hard resetting link
[156551.725559] ata7: softreset failed (device not ready)
[156551.725567] ata7: hard resetting link
that is not an error. That is the linux kernel initializing the sata
connection.
stuff like that always happens if you hotplug a (e)sata device.
Thanks Volker, and thank you all for your help.
Re: [gentoo-user] Moving from old udev to eudev
Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? I switched when it was still fresh and it wasn't to bad from what I recall. Just emerge -C udev and emerge eudev. I think I masked udev to make sure it didn't get pulled in any more by something else but other than that, it just worked. I would recommend going to boot runlevel and restarting udev after the switch tho, just to be sure it restarts OK. Oh, the init script is still called udev not eudev. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Moving from old udev to eudev
On 2013-08-01 4:04 PM, Dale rdalek1...@gmail.com wrote: I switched when it was still fresh and it wasn't to bad from what I recall. Just emerge -C udev and emerge eudev. I think I masked udev to make sure it didn't get pulled in any more by something else but other than that, it just worked. I would recommend going to boot runlevel and restarting udev after the switch tho, just to be sure it restarts OK. Oh, the init script is still called udev not eudev. Thanks Dale. Hmmm... so, do I have to do any of the things recommended if updating to the new version of udev? Ie: Remove the udev-postmount init script Make sure CONFIG_DEVTMPFS=y is set in the kernel configuration etc... ?
Re: [gentoo-user] Moving from old udev to eudev
On 01/08/13 19:28, Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? First of all, eudev only has IUSE=rule-generator that is backported from udev-171. It's otherwise same in users point of view with sys-fs/udev, except sys-fs/eudev is constantly out of date and the code forwarding from upstream is not very reliable process. Futhermore sys-fs/udev is not 'old' but it's the new one and will be the default for OpenRC for long as OpenRC is in Portage. I don't want to bash anything or anybody but sys-fs/eudev as-is in the Portage is currently useless and a bit buggy.
Re: [gentoo-user] Recommendation for CPU type in QEMU?
On Thu, Aug 01, 2013 at 08:41:56AM +0200, Michael Hampicke wrote You can use march=native on your gentoo hosts, that's no problem, as long as you don't use it on your guests. That's the hole idea of VMs: being able to move the virtual machine to another machine, that might be completely different in terms of hardware. The goal is, to be machine independent. I want to clarify one item, so please pardon me if it looks like I'm asking the same question over again. Assume that I launch QEMU with -cpu core2duo and set -march=native in the guest's make.conf. My understanding is that the gcc compiler on the guest will see a core2duo, not the physical i5 cpu on my desktop. We may be looking at different ways of doing the same thing. You're suggesting -march=core2 in the guest's make.conf. I'm suggesting -march=native in the guest's make.conf, which would pick up the cpu type that QEMU sets (cor2duo). I'm trying to make things simpler, by only having to specify the cpu type once, on the QEMU commandline, and leaving gcc to adapt to the QEMU-specified cpu. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Moving from old udev to eudev
Tanstaafl wrote: On 2013-08-01 4:04 PM, Dale rdalek1...@gmail.com wrote: I switched when it was still fresh and it wasn't to bad from what I recall. Just emerge -C udev and emerge eudev. I think I masked udev to make sure it didn't get pulled in any more by something else but other than that, it just worked. I would recommend going to boot runlevel and restarting udev after the switch tho, just to be sure it restarts OK. Oh, the init script is still called udev not eudev. Thanks Dale. Hmmm... so, do I have to do any of the things recommended if updating to the new version of udev? Ie: Remove the udev-postmount init script Make sure CONFIG_DEVTMPFS=y is set in the kernel configuration etc... ? When the version of udev came out that was said to require a init thingy or /usr on /, that is when I switched to eudev. I haven't used the newer versions of udev. I do have this in my kernel config tho: root@fireball / # cat /usr/src/linux/.config | grep -i CONFIG_DEVTMPFS CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y root@fireball / # It may be best to search the archives for eudev and my email addy. I don't recall it being anything difficult. The issues I did run into has since been fixed. As I posted earlier, I installed the very early version. From my understanding now tho, it should be as easy as unmerge udev and emerge eudev. I'd look at the messages after it emerges tho, just in case. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Moving from old udev to eudev
Samuli Suominen wrote: On 01/08/13 19:28, Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? First of all, eudev only has IUSE=rule-generator that is backported from udev-171. It's otherwise same in users point of view with sys-fs/udev, except sys-fs/eudev is constantly out of date and the code forwarding from upstream is not very reliable process. Futhermore sys-fs/udev is not 'old' but it's the new one and will be the default for OpenRC for long as OpenRC is in Portage. I don't want to bash anything or anybody but sys-fs/eudev as-is in the Portage is currently useless and a bit buggy. That's odd. I been using eudev since like the second version that came out and have had zero issues with it. Ask anyone here, if it had a problem, I'd be found it by now. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Any .config for vbox gentoo guest
On 30/07/2013 22:04, walt wrote: On 07/29/2013 06:29 PM, Harry Putnam wrote: Can anyone post a .config for a 3.8.13 kernel that is known to work on a vbox install of gentoo as guest. Working on a fresh install but don't have gentoo running anywhere to rob a .config from. This one worked for me. snip This config is missing various options that would significantly enhance kernel performance in its capacity as a guest. For core paravirtualization support: CONFIG_PARAVIRT_GUEST CONFIG_KVM_CLOCK CONFIG_KVM_GUEST For virtio support: CONFIG_VIRTIO CONFIG_VIRTIO_PCI CONFIG_VIRTIO_BLK CONFIG_SCSI_VIRTIO CONFIG_VIRTIO_NET For the scsi/net virtio drivers to work in the guest, qemu must be started with the appropriate options. Further details can be found here: http://www.linux-kvm.org/page/Virtio --Kerin
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 00:49, Dale wrote: Samuli Suominen wrote: On 01/08/13 19:28, Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? First of all, eudev only has IUSE=rule-generator that is backported from udev-171. It's otherwise same in users point of view with sys-fs/udev, except sys-fs/eudev is constantly out of date and the code forwarding from upstream is not very reliable process. Futhermore sys-fs/udev is not 'old' but it's the new one and will be the default for OpenRC for long as OpenRC is in Portage. I don't want to bash anything or anybody but sys-fs/eudev as-is in the Portage is currently useless and a bit buggy. That's odd. I been using eudev since like the second version that came out and have had zero issues with it. Ask anyone here, if it had a problem, I'd be found it by now. lol Then you haven't been following. It's multiple issues per week, if not even day. And like said, you don't gain anything by using sys-fs/eudev. The package is useless.
Re: [gentoo-user] Recommendation for CPU type in QEMU?
On 01/08/2013 22:38, Walter Dnes wrote:
On Thu, Aug 01, 2013 at 08:41:56AM +0200, Michael Hampicke wrote
You can use march=native on your gentoo hosts, that's no problem, as
long as you don't use it on your guests. That's the hole idea of VMs:
being able to move the virtual machine to another machine, that might be
completely different in terms of hardware. The goal is, to be machine
independent.
I want to clarify one item, so please pardon me if it looks like I'm
asking the same question over again. Assume that I launch QEMU with
-cpu core2duo and set -march=native in the guest's make.conf. My
understanding is that the gcc compiler on the guest will see a core2duo,
not the physical i5 cpu on my desktop.
That's correct. Try running this in the guest:
gcc -march=native -Q --help=target | grep march | awk '{print $2}'
We may be looking at different ways of doing the same thing. You're
suggesting -march=core2 in the guest's make.conf. I'm suggesting
-march=native in the guest's make.conf, which would pick up the cpu
type that QEMU sets (cor2duo). I'm trying to make things simpler, by
only having to specify the cpu type once, on the QEMU commandline, and
leaving gcc to adapt to the QEMU-specified cpu.
--Kerin
[gentoo-user] nvidia-drivers segfault when starting X
Hi there, When I start X (or start kdm), I get a segmentation fault and no X. The Xorg-log says: [ 8675.702] (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 [ 8675.702] (==) NVIDIA(0): RGB weight 888 [ 8675.702] (==) NVIDIA(0): Default visual is TrueColor [ 8675.702] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) [ 8675.702] (**) NVIDIA(0): Option TwinViewOrientation LeftOf [ 8675.703] (**) NVIDIA(0): Option AddARGBGLXVisuals [ 8675.703] (**) NVIDIA(0): Option UseEvents false [ 8675.703] (**) NVIDIA(0): Enabling 2D acceleration [ 8676.186] (II) NVIDIA(GPU-0): Display (Samsung SyncMaster (DFP-0)) does not support NVIDIA [ 8676.186] (II) NVIDIA(GPU-0): 3D Vision stereo. [ 8676.253] (II) NVIDIA(GPU-0): Display (Eizo L565 (DFP-1)) does not support NVIDIA 3D Vision [ 8676.253] (II) NVIDIA(GPU-0): stereo. [ 8676.255] (II) NVIDIA(0): NVIDIA GPU GeForce 7600 GT (G73) at PCI:1:0:0 (GPU-0) [ 8676.255] (--) NVIDIA(0): Memory: 262144 kBytes [ 8676.255] (--) NVIDIA(0): VideoBIOS: 05.73.22.18.00 [ 8676.255] (II) NVIDIA(0): Detected PCI Express Link width: 16X [ 8676.255] (--) NVIDIA(0): Interlaced video modes are supported on this GPU [ 8676.255] (--) NVIDIA(0): Valid display device(s) on GeForce 7600 GT at PCI:1:0:0 [ 8676.255] (--) NVIDIA(0): CRT-0 [ 8676.255] (--) NVIDIA(0): CRT-1 [ 8676.255] (--) NVIDIA(0): TV-0 [ 8676.255] (--) NVIDIA(0): Samsung SyncMaster (DFP-0) (connected) [ 8676.255] (--) NVIDIA(0): Eizo L565 (DFP-1) (connected) [ 8676.255] (--) NVIDIA(0): CRT-0: 400.0 MHz maximum pixel clock [ 8676.255] (--) NVIDIA(0): CRT-1: 400.0 MHz maximum pixel clock [ 8676.255] (--) NVIDIA(0): TV-0: 400.0 MHz maximum pixel clock [ 8676.255] (--) NVIDIA(0): TV encoder: Unknown [ 8676.255] (--) NVIDIA(0): Samsung SyncMaster (DFP-0): 330.0 MHz maximum pixel clock [ 8676.255] (--) NVIDIA(0): Samsung SyncMaster (DFP-0): Internal Dual Link TMDS [ 8676.255] (--) NVIDIA(0): Eizo L565 (DFP-1): 165.0 MHz maximum pixel clock [ 8676.255] (--) NVIDIA(0): Eizo L565 (DFP-1): Internal Single Link TMDS [ 8676.255] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display [ 8676.255] (**) NVIDIA(0): device Samsung SyncMaster (DFP-0) (Using EDID frequencies [ 8676.255] (**) NVIDIA(0): has been enabled on all display devices.) [ 8676.255] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display [ 8676.255] (**) NVIDIA(0): device Eizo L565 (DFP-1) (Using EDID frequencies has been [ 8676.255] (**) NVIDIA(0): enabled on all display devices.) [ 8676.255] (II) NVIDIA(0): Validated MetaModes: [ 8676.255] (II) NVIDIA(0): DFP-0:nvidia-auto-select,DFP-1:nvidia-auto- select [ 8676.255] (II) NVIDIA(0): Virtual screen size determined to be 3200 x 1200 [ 8676.256] (WW) NVIDIA(0): Unable to support custom viewPortOut 1920 x 1080 +0 +60 [ 8676.256] (WW) NVIDIA(0): Unable to support custom viewPortOut 1920 x 1080 +0 +60 [ 8676.256] (--) NVIDIA(0): DPI set to (93, 95); computed from UseEdidDpi X config [ 8676.256] (--) NVIDIA(0): option [ 8676.256] (**) NVIDIA(0): Enabling 32-bit ARGB GLX visuals. [ 8676.256] (--) Depth 24 pixmap format is 32 bpp [ 8676.262] (II) NVIDIA(0): Setting mode DFP-0:nvidia-auto- select,DFP-1:nvidia-auto-select [ 8676.286] (EE) [ 8676.286] (EE) Backtrace: [ 8676.286] (EE) 0: X (xorg_backtrace+0x34) [0x5cd634] [ 8676.286] (EE) 1: X (0x40+0x1d1ca9) [0x5d1ca9] [ 8676.286] (EE) 2: /lib64/libpthread.so.0 (0x7fe689cb+0x10810) [0x7fe689cc0810] [ 8676.286] (EE) 3: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0x11643b) [0x7fe6841ee43b] [ 8676.286] (EE) 4: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0x72773) [0x7fe68414a773] [ 8676.286] (EE) 5: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0xeaa01) [0x7fe6841c2a01] [ 8676.286] (EE) 6: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0xe30e4) [0x7fe6841bb0e4] [ 8676.286] (EE) 7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0xe3820) [0x7fe6841bb820] [ 8676.286] (EE) 8: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0x9447b) [0x7fe68416c47b] [ 8676.286] (EE) 9: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0x8fedb) [0x7fe684167edb] [ 8676.286] (EE) 10: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0xde8f6) [0x7fe6841b68f6] [ 8676.286] (EE) 11: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0x56f6bb) [0x7fe6846476bb] [ 8676.286] (EE) 12: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe6840d8000+0x5609f1) [0x7fe6846389f1] [ 8676.286] (EE) 13: X (AddScreen+0x75) [0x43ddb5] [ 8676.286] (EE) 14: X (InitOutput+0x3ec) [0x48b20c] [ 8676.286] (EE) 15: X (0x40+0x29910) [0x429910] [ 8676.286] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xec) [0x7fe68890a4cc] [ 8676.286] (EE) 17: X (0x40+0x2a22d) [0x42a22d] [ 8676.286] (EE) [ 8676.286] (EE)
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 00:28, Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? Something like olympus ~ # cat /etc/portage/package.mask =sys-fs/udev-180 ... olympus ~ # olympus ~ # grep udev /etc/portage/package.keywords sys-fs/eudev ~amd64 =virtual/udev-206 ~amd64 olympus ~ # unmerge everything udev emerge eudev its been much less fuss and bother than trying to stick with the udev machinations - I have maybe 15 machines and vm's running eudev, no udev ... :) BillK
[gentoo-user] Re: nvidia-drivers segfault when starting X
On 01/08/13 23:02, Alexander Puchmayr wrote: Hi there, When I start X (or start kdm), I get a segmentation fault and no X. [...] Kernel 3.8.18, nvidia-drivers 304.88 (Last to support the GeForce7600, newer drivers do not support it any more). Any ideas? Try manually rolling your own ebuild for 307.83. This is the latest version for your card, but unfortunately it's not in portage. 304.88 are a year old.
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 02:27, William Kenworthy wrote: On 02/08/13 00:28, Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? Something like olympus ~ # cat /etc/portage/package.mask =sys-fs/udev-180 ... olympus ~ # olympus ~ # grep udev /etc/portage/package.keywords sys-fs/eudev ~amd64 =virtual/udev-206 ~amd64 olympus ~ # unmerge everything udev emerge eudev its been much less fuss and bother than trying to stick with the udev machinations - I have maybe 15 machines and vm's running eudev, no udev ... :) nope, you just believed all the FUD there has been out there. i've said it many times, and i'll say it again: the only real different is USE=rule-generator and that's it and sys-fs/eudev is constantly out of date and haven't developed any features of their own so why follow with unreliable fork, when there is the official package available with equal features?
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 07:42, Samuli Suominen wrote: On 02/08/13 02:27, William Kenworthy wrote: On 02/08/13 00:28, Tanstaafl wrote: ... so why follow with unreliable fork, when there is the official package available with equal features? easy - it works and while I had machines running some of each it was only the udev machines that needed continual maintenance in that area. The latest and greatest isnt always the best. I believe one of the goals of eudev was stability and the old way of doing things which I want and get ... after removing gnome3 and installing LXDE where I need a desktop (and LXDE is moving from gnome2 to QT, even better) I am getting less and less interested in creating ongoing pain for myself with udev/systemd/gnome etc. There may be bugs, but on my installations its been udev thats created the hassles. BillK
[gentoo-user] Re: Any .config for vbox gentoo guest
On 08/01/2013 03:08 PM, Kerin Millar wrote: On 30/07/2013 22:04, walt wrote: On 07/29/2013 06:29 PM, Harry Putnam wrote: Can anyone post a .config for a 3.8.13 kernel that is known to work on a vbox install of gentoo as guest. Working on a fresh install but don't have gentoo running anywhere to rob a .config from. This one worked for me. snip This config is missing various options that would significantly enhance kernel performance in its capacity as a guest. For core paravirtualization support: CONFIG_PARAVIRT_GUEST CONFIG_KVM_CLOCK CONFIG_KVM_GUEST For virtio support: CONFIG_VIRTIO CONFIG_VIRTIO_PCI CONFIG_VIRTIO_BLK CONFIG_SCSI_VIRTIO CONFIG_VIRTIO_NET For the scsi/net virtio drivers to work in the guest, qemu must be started with the appropriate options. Further details can be found here: http://www.linux-kvm.org/page/Virtio Thanks Kerin. I don't know about Harry, but I'm no expert in virtualization. Just to clarify: I know that virtualbox and kvm are both extensions of qemu, but not exactly identical to each other. Would those same kernel options be useful in virtualbox as well as kvm/qemu?
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 07:42, Samuli Suominen wrote: On 02/08/13 02:27, William Kenworthy wrote: On 02/08/13 00:28, Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? Something like olympus ~ # cat /etc/portage/package.mask =sys-fs/udev-180 ... olympus ~ # olympus ~ # grep udev /etc/portage/package.keywords sys-fs/eudev ~amd64 =virtual/udev-206 ~amd64 olympus ~ # unmerge everything udev emerge eudev its been much less fuss and bother than trying to stick with the udev machinations - I have maybe 15 machines and vm's running eudev, no udev ... :) nope, you just believed all the FUD there has been out there. i've said it many times, and i'll say it again: the only real different is USE=rule-generator and that's it and sys-fs/eudev is constantly out of date and haven't developed any features of their own so why follow with unreliable fork, when there is the official package available with equal features? and I just searched gentoo's bugzilla for eudev and there is a single bug which is a stabilisation request. Looking at the eudev github page recent updates range from hours to days though some are months as one would expect. If its unreliable, where are the bugs? Try doing a search of gentoo's bugzilla for udev instead of eudev ... BillK
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 03:19, William Kenworthy wrote: On 02/08/13 07:42, Samuli Suominen wrote: On 02/08/13 02:27, William Kenworthy wrote: On 02/08/13 00:28, Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? Something like olympus ~ # cat /etc/portage/package.mask =sys-fs/udev-180 ... olympus ~ # olympus ~ # grep udev /etc/portage/package.keywords sys-fs/eudev ~amd64 =virtual/udev-206 ~amd64 olympus ~ # unmerge everything udev emerge eudev its been much less fuss and bother than trying to stick with the udev machinations - I have maybe 15 machines and vm's running eudev, no udev ... :) nope, you just believed all the FUD there has been out there. i've said it many times, and i'll say it again: the only real different is USE=rule-generator and that's it and sys-fs/eudev is constantly out of date and haven't developed any features of their own so why follow with unreliable fork, when there is the official package available with equal features? and I just searched gentoo's bugzilla for eudev and there is a single bug which is a stabilisation request. Looking at the eudev github page recent updates range from hours to days though some are months as one would expect. If its unreliable, where are the bugs? Try doing a search of gentoo's bugzilla for udev instead of eudev ... The bugs assigned to udev-bugs@ apply also to sys-fs/eudev in almost every case. And the sys-fs/eudev specific bugs are in the github page at 'Tickets', and some in bugzilla. And yes, there are attempt at keeping up-to-date but everytime I (or we) review how it was done, bits are missing from here and there. So still, eudev is the unnecessary experimental toy trying to catch up udev, and sys-fs/udev will be the default for long as sys-apps/openrc is the default.
Re: [gentoo-user] Moving from old udev to eudev
On Fri, Aug 02, 2013 at 02:42:36AM +0300, Samuli Suominen wrote nope, you just believed all the FUD there has been out there. i've said it many times, and i'll say it again: the only real different is USE=rule-generator and that's it and sys-fs/eudev is constantly out of date and haven't developed any features of their own What are the new features? What have Lennart/Kay broken recently? First it was firmware loading in udev, which got them reamed out by Linus. Then it was (un)predictable network interface names. Gentoo is not Facebook http://www.geek.com/news/mark-zuckerberg-says-you-need-to-move-fast-and-break-things-922432/ The key to the real innovation, says Zuckerberg, is to move fast and break things. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Moving from old udev to eudev
On Thu, Aug 01, 2013 at 12:28:38PM -0400, Tanstaafl wrote Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. Step 1) keyword sys-fs/eudev-1_beta2-r2 Step 2) ensure that kmod and openrc and -modutils USE flags are set (at least for sys-fs/eudev). tools flag needs to be set for sys-apps/kmod (usually a system default) Step 3) unmerge udev sys-apps/modutils (You *MUST* specify sys-apps/modutils to avoid confusion with virtual/modutils) Step 4) emerge eudev (should pull in kmod) Step 5) The following message shows up in elog. Do as it says... WARN: postinst You need to restart eudev as soon as possible to make the upgrade go into effect: /etc/init.d/udev --nodeps restart -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 04:01, Walter Dnes wrote: On Fri, Aug 02, 2013 at 02:42:36AM +0300, Samuli Suominen wrote nope, you just believed all the FUD there has been out there. i've said it many times, and i'll say it again: the only real different is USE=rule-generator and that's it and sys-fs/eudev is constantly out of date and haven't developed any features of their own What are the new features? What have Lennart/Kay broken recently? First it was firmware loading in udev, which got them reamed out by Linus. Then it was (un)predictable network interface names. Gentoo is not Facebook http://www.geek.com/news/mark-zuckerberg-says-you-need-to-move-fast-and-break-things-922432/ The key to the real innovation, says Zuckerberg, is to move fast and break things. Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on.
Re: [gentoo-user] Moving from old udev to eudev
Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli
Re: [gentoo-user] Moving from old udev to eudev
Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli So any bug that udev has eudev has too? Then with that logic, udev is just as unstable as eudev. You claim eudev has a bug that udev doesn't, let's see them. Based on your posts, there should be plenty of them. Funny I haven't ran into any of them yet tho. Here is the deal OK. Udev went in a direction I do NOT like. I CHOSE not to use it and plan to not use it. I PREFER eudev whether you like that decision or not. I also plan to use eudev as long as it serves my needs as I suspect others will as well. You can preach FUD all you want but it works here for me and as others have posted, it works fine for them. The OP asked for assistance in switching to eudev not for you to second guess their choice or to second guess anyone else who chooses to use it. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 11:01, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli From my point of view, its udev/systemd that should be punted - what about user choice? - Ive decided I no longer want to buy into the flaky, unusable systems gnome3 and udev/systemd integration caused me even though I didn't have systemd installed, so why should I be forced to? A group have come up with a way to keep my systems running properly without those packages and its working better than udev ever has for me ... BillK
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 06:14, Dale wrote: Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli So any bug that udev has eudev has too? Yes, because eudev is copying the upstream code over from udev. Then with that logic, udev is just as unstable as eudev. Except it isn't because as already explained, eudev makes additional changes on top of udev changes. You claim eudev has a bug that udev doesn't, Which is true. let's see them. Based on your posts, there should be plenty of them. Funny I haven't ran into any of them yet tho. I'm not suprised, because the current status is so similar between udev vs. eudev. Only regression that's known currently is IUSE=+rule-generator that doesn't do it's job correctly and 70-persistent-net.rules it is generating can't be trusted. Here is the deal OK. Udev went in a direction I do NOT like. What direction is that? Everything same is in sys-fs/udev than is in sys-fs/eudev, except the buggy rule-generator. I CHOSE not to use it and plan to not use it. I PREFER eudev whether you like that decision or not. I also plan to use eudev as long as it serves my needs as I suspect others will as well. You can preach FUD all you want but it works here for me and as others have posted, it works fine for them. The OP asked for assistance in switching to eudev not for you to second guess their choice or to second guess anyone else who chooses to use it. I feel pity for you, too bad the eudev in tree causes such level of ignorance. - Samuli
Re: [gentoo-user] gentoo-systemd-only deprecation
Canek Peláez Valdés can...@gmail.com wrote: On Thu, Aug 1, 2013 at 4:43 AM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Jul 31, 2013 at 02:00:23AM -0500, Canek Peláez Valdés wrote On Wed, Jul 31, 2013 at 1:24 AM, Daniel Campbell li...@sporkbox.us wrote: You need an OpenRC use flag to install OpenRC init scripts? That's simply a lie. An apology to Daniel might be in order. I start my USE flag with -*. During a recent install, I found out the hard way that eudev (and udev) do not install their init scripts without the openrc flag. As you can see from the ebuild fragments below, they require the openrc flag to pull in sys-fs/udev-init-scripts From sys-fs/udev/udev-197-r8.ebuild === PDEPEND==virtual/udev-197-r1 hwdb? ( =sys-apps/hwids-20130114[udev] ) openrc? ( =sys-fs/udev-init-scripts-19-r1 ) From sys-fs/eudev/eudev-1_beta4-r1.ebuild = PDEPEND==virtual/udev-180 openrc? ( =sys-fs/udev-init-scripts-18 ) udev/eudev are special cases: the first is systemd with systemd removed at make install time; the second is a fork of systemd with systemd exorcised. The systemd package also uses the openrc USE flag to install OpenRC init scripts; I hope you agree that it is also an special case (systemd, which is a whole init system, provides init scripts for another init system). The package sys-apps/kmod also uses the openrc USE flag to install an init script, which Create[s] [a] list of required static device nodes for the current kernel. I have no idea why this is necessary, but kmod is a dependency of systemd, and the developers of both projects collaborate a lot between them. No other package in the tree uses an openrc USE flag (or at least they don't appear in /usr/portage/profiles/use.local.desc), except for plymouth, and that it's to install a plugin for OpenRC, not to install its OpenRC scripts. So no package in the tree uses an openrc USE flag to install init scripts, except for one somewhat related to systemd, two forks and/or special handling of systemd, and systemd itself. In *ALL* the other packages in the tree, the OpenRC init scripts are installed unconditionally, as the systemd unit files are. And that's how it should be. Lastly, the ebuilds for udev/eudev should work out of the box in a sane configuration. You have been told several times, both by users and developers, that USE=-* is not really supported; you broke your system by using it, you get to keep the pieces. Gentoo is about choice (or so I keep hearing); that doesn't mean it shouldn't strive to have sane defaults that keep the majority happy: http://blogs.gentoo.org/mgorny/2013/07/23/keeping-the-majority-happy/ So, I hope the package maintainers will create or install systemd units and init.d files so we can have the choice and not spend tons of time maintaining the system -- it gets to the point of being rediculous after a while. Systemd sounds nice, but its frustrating because of this. -- 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] Moving from old udev to eudev
Samuli Suominen ssuomi...@gentoo.org writes: Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. In what way are network interface names predictable? A new system arrives on your desk, what is the name of the first (or only) Ethernet interface? Under the 'old' system, you know it will be 'eth0'[1]. With the new scheme you do not know until the system is booted. The interface name is (mostly) consistent once you know it, but it is not predictable. [1] On a multi-interface system you may not have known which physical port was eth0, but you knew that one of them was.
Re: [gentoo-user] Moving from old udev to eudev
Samuli Suominen wrote: On 02/08/13 06:14, Dale wrote: Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli So any bug that udev has eudev has too? Yes, because eudev is copying the upstream code over from udev. Then with that logic, udev is just as unstable as eudev. Except it isn't because as already explained, eudev makes additional changes on top of udev changes. You claim eudev has a bug that udev doesn't, Which is true. Let's see them. I'll help you: https://bugs.gentoo.org/buglist.cgi?quicksearch=eudevlist_id=1920856 let's see them. Based on your posts, there should be plenty of them. Funny I haven't ran into any of them yet tho. I'm not suprised, because the current status is so similar between udev vs. eudev. Only regression that's known currently is IUSE=+rule-generator that doesn't do it's job correctly and 70-persistent-net.rules it is generating can't be trusted. So still no links to any bug reports that are eudev specific huh? See above. Here is the deal OK. Udev went in a direction I do NOT like. What direction is that? Everything same is in sys-fs/udev than is in sys-fs/eudev, except the buggy rule-generator. I CHOSE not to use it and plan to not use it. I PREFER eudev whether you like that decision or not. I also plan to use eudev as long as it serves my needs as I suspect others will as well. You can preach FUD all you want but it works here for me and as others have posted, it works fine for them. The OP asked for assistance in switching to eudev not for you to second guess their choice or to second guess anyone else who chooses to use it. I feel pity for you, too bad the eudev in tree causes such level of ignorance. - Samuli Here is some FUD for you. Eudev just left beta. From the eudev changelog. *eudev-1.2 (01 Aug 2013) 01 Aug 2013; Ian Stakenvicius a...@gentoo.org +eudev-1.2.ebuild, -eudev-1.2_beta.ebuild: version bump, remove beta Just keep telling yourself this stuff and maybe one day you will convince someone besides yourself. In the meantime, others and myself will continue to use eudev, whether you agree or not. Keep the pity for yourself OK. I don't need it. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 08:28, Dale wrote: Samuli Suominen wrote: On 02/08/13 06:14, Dale wrote: Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli So any bug that udev has eudev has too? Yes, because eudev is copying the upstream code over from udev. Then with that logic, udev is just as unstable as eudev. Except it isn't because as already explained, eudev makes additional changes on top of udev changes. You claim eudev has a bug that udev doesn't, Which is true. Let's see them. I'll help you: https://bugs.gentoo.org/buglist.cgi?quicksearch=eudevlist_id=1920856 Help yourself instead and use correct search parameters, like below... let's see them. Based on your posts, there should be plenty of them. Funny I haven't ran into any of them yet tho. I'm not suprised, because the current status is so similar between udev vs. eudev. Only regression that's known currently is IUSE=+rule-generator that doesn't do it's job correctly and 70-persistent-net.rules it is generating can't be trusted. So still no links to any bug reports that are eudev specific huh? See above. Search bugzilla for udev-b...@gentoo.org and 90% of them apply also to eudev. Search bugzilla for eu...@gentoo.org and those all apply. Search eudev github page Tickets and those all apply. Here is the deal OK. Udev went in a direction I do NOT like. What direction is that? Everything same is in sys-fs/udev than is in sys-fs/eudev, except the buggy rule-generator. I CHOSE not to use it and plan to not use it. I PREFER eudev whether you like that decision or not. I also plan to use eudev as long as it serves my needs as I suspect others will as well. You can preach FUD all you want but it works here for me and as others have posted, it works fine for them. The OP asked for assistance in switching to eudev not for you to second guess their choice or to second guess anyone else who chooses to use it. I feel pity for you, too bad the eudev in tree causes such level of ignorance. - Samuli Here is some FUD for you. Eudev just left beta. From the eudev changelog. *eudev-1.2 (01 Aug 2013) 01 Aug 2013; Ian Stakenvicius a...@gentoo.org +eudev-1.2.ebuild, -eudev-1.2_beta.ebuild: version bump, remove beta And how did they get there? By udev maintainers forcing them to upgrade to the new keymap hwdb which required version to be raised to up-to-par with udev-206. Anyway, have fun with pointless udev fork which will never be the default. I don't care if you don't want the system up-to-par with production level system. :-) - Samuli
