* [eudev] Is it ready now? @ 2013-01-20 4:30 Dale [not found] ` <50FBCBFD.4000109@gentoo.org> 0 siblings, 1 reply; 7+ messages in thread From: Dale @ 2013-01-20 4:30 UTC (permalink / raw To: eudev Howdy, I just synced my tree and it appears udev wants to upgrade. I have a separate /usr on lvm and really want to avoid udev that COULD break things. I have a init thingy but not sure if it will pass the test or not. Is eudev ready for people to switch to? I use KDE, latest in the tree. Other than that, nothing special really. I'm amd64. Thoughts? Things I should look out for? Thanks. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <50FBCBFD.4000109@gentoo.org>]
* Re: [eudev] Is it ready now? [not found] ` <50FBCBFD.4000109@gentoo.org> @ 2013-01-20 17:53 ` Dale 2013-01-20 18:26 ` Anthony G. Basile 0 siblings, 1 reply; 7+ messages in thread From: Dale @ 2013-01-20 17:53 UTC (permalink / raw To: eudev Anthony G. Basile wrote: > On 01/19/2013 11:30 PM, Dale wrote: >> Howdy, >> >> I just synced my tree and it appears udev wants to upgrade. I have a >> separate /usr on lvm and really want to avoid udev that COULD break >> things. I have a init thingy but not sure if it will pass the test or >> not. >> >> Is eudev ready for people to switch to? I use KDE, latest in the tree. >> Other than that, nothing special really. I'm amd64. >> >> Thoughts? Things I should look out for? >> >> Thanks. >> >> Dale >> >> :-) :-) >> > > eudev is ready. It has not been tested in every situation so there > are unknown issues but this is true of systemd-udev also. I've been > running eudev-1_beta1-r2 on a gnome desktop for a while with no > issues. I'm running it on a few servers. > So it is as simple as unmerging udev and emerging eudev? Do I need to reboot afterwards or is it sufficient to go to boot runlevel, kill anything udev related and then go back to default runlevel? I have done this in the past with udev so I know udev restarts when it switches to default runlevel from boot runlevel. Thanks much for the reply. Also, thanks for the work on eudev. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [eudev] Is it ready now? 2013-01-20 17:53 ` Dale @ 2013-01-20 18:26 ` Anthony G. Basile 2013-01-20 23:59 ` Dale 0 siblings, 1 reply; 7+ messages in thread From: Anthony G. Basile @ 2013-01-20 18:26 UTC (permalink / raw To: eudev On 01/20/2013 12:53 PM, Dale wrote: > Anthony G. Basile wrote: >> On 01/19/2013 11:30 PM, Dale wrote: >>> Howdy, >>> >>> I just synced my tree and it appears udev wants to upgrade. I have a >>> separate /usr on lvm and really want to avoid udev that COULD break >>> things. I have a init thingy but not sure if it will pass the test or >>> not. >>> >>> Is eudev ready for people to switch to? I use KDE, latest in the tree. >>> Other than that, nothing special really. I'm amd64. >>> >>> Thoughts? Things I should look out for? >>> >>> Thanks. >>> >>> Dale >>> >>> :-) :-) >>> >> >> eudev is ready. It has not been tested in every situation so there >> are unknown issues but this is true of systemd-udev also. I've been >> running eudev-1_beta1-r2 on a gnome desktop for a while with no >> issues. I'm running it on a few servers. >> > > So it is as simple as unmerging udev and emerging eudev? Do I need to > reboot afterwards or is it sufficient to go to boot runlevel, kill > anything udev related and then go back to default runlevel? I have > done this in the past with udev so I know udev restarts when it switches > to default runlevel from boot runlevel. > > Thanks much for the reply. Also, thanks for the work on eudev. > > Dale > > :-) :-) > I'm not sure right now what the best migration path would be since udev is also progressing forward ... I migrated by keywording eudev-0 and I've been upgrading from there. I also added USE=openrc globally. If I recall, I got a blocker with udev, unmerged it and then merge eudev. But as of recently you might also get a blocker with kmod. Having said that, the migration was the worst part. After that I was fine. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [eudev] Is it ready now? 2013-01-20 18:26 ` Anthony G. Basile @ 2013-01-20 23:59 ` Dale 2013-01-21 8:46 ` Dale 0 siblings, 1 reply; 7+ messages in thread From: Dale @ 2013-01-20 23:59 UTC (permalink / raw To: eudev Anthony G. Basile wrote: > On 01/20/2013 12:53 PM, Dale wrote: >> Anthony G. Basile wrote: >>> On 01/19/2013 11:30 PM, Dale wrote: >>>> Howdy, >>>> >>>> I just synced my tree and it appears udev wants to upgrade. I have a >>>> separate /usr on lvm and really want to avoid udev that COULD break >>>> things. I have a init thingy but not sure if it will pass the test or >>>> not. >>>> >>>> Is eudev ready for people to switch to? I use KDE, latest in the >>>> tree. >>>> Other than that, nothing special really. I'm amd64. >>>> >>>> Thoughts? Things I should look out for? >>>> >>>> Thanks. >>>> >>>> Dale >>>> >>>> :-) :-) >>>> >>> >>> eudev is ready. It has not been tested in every situation so there >>> are unknown issues but this is true of systemd-udev also. I've been >>> running eudev-1_beta1-r2 on a gnome desktop for a while with no >>> issues. I'm running it on a few servers. >>> >> >> So it is as simple as unmerging udev and emerging eudev? Do I need to >> reboot afterwards or is it sufficient to go to boot runlevel, kill >> anything udev related and then go back to default runlevel? I have >> done this in the past with udev so I know udev restarts when it switches >> to default runlevel from boot runlevel. >> >> Thanks much for the reply. Also, thanks for the work on eudev. >> >> Dale >> >> :-) :-) >> > > I'm not sure right now what the best migration path would be since > udev is also progressing forward ... I migrated by keywording eudev-0 > and I've been upgrading from there. I also added USE=openrc > globally. If I recall, I got a blocker with udev, unmerged it and > then merge eudev. But as of recently you might also get a blocker with > kmod. > > Having said that, the migration was the worst part. After that I was > fine. > > > > I have the udev USE flag set for some reason, I'm sure something needed it at some point. Should I turn that off or does it matter? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [eudev] Is it ready now? 2013-01-20 23:59 ` Dale @ 2013-01-21 8:46 ` Dale 2013-01-21 12:24 ` Anthony G. Basile 0 siblings, 1 reply; 7+ messages in thread From: Dale @ 2013-01-21 8:46 UTC (permalink / raw To: eudev Dale wrote: > Anthony G. Basile wrote: > >> I'm not sure right now what the best migration path would be since >> udev is also progressing forward ... I migrated by keywording eudev-0 >> and I've been upgrading from there. I also added USE=openrc >> globally. If I recall, I got a blocker with udev, unmerged it and >> then merge eudev. But as of recently you might also get a blocker with >> kmod. >> >> Having said that, the migration was the worst part. After that I was >> fine. >> >> > I have the udev USE flag set for some reason, I'm sure something needed > it at some point. Should I turn that off or does it matter? > > Dale > > :-) :-) > OK. I went with the idea that the udev USE flag would work with either package. So, I switched. I only noticed one thing that could possibly, maybe, sort of need fixing. I had dracut emerged. I was building the init thingy until eudev came along. Anyway, it seems that dracut insists on having udev and eudev is not a option for some reason. I found this in the ebuild: CDEPEND=">sys-fs/udev-166 dracut_modules_systemd? ( sys-apps/systemd ) " Shouldn't that either depend on the virtual udev or something instead of only on udev itself? Sort of let eudev be a option too? Other than that, works fine. It took me a minute to get my mask/unmask/keyword files sorted but works fine. Dale :-) :-) P. S. No reboot needed either. I did the switch in the boot runlevel. When it was done, just stopped and restarted udev then went back to default runlevel. -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [eudev] Is it ready now? 2013-01-21 8:46 ` Dale @ 2013-01-21 12:24 ` Anthony G. Basile 2013-01-22 7:18 ` Dale 0 siblings, 1 reply; 7+ messages in thread From: Anthony G. Basile @ 2013-01-21 12:24 UTC (permalink / raw To: eudev On 01/21/2013 03:46 AM, Dale wrote: > Dale wrote: >> Anthony G. Basile wrote: >> >>> I'm not sure right now what the best migration path would be since >>> udev is also progressing forward ... I migrated by keywording eudev-0 >>> and I've been upgrading from there. I also added USE=openrc >>> globally. If I recall, I got a blocker with udev, unmerged it and >>> then merge eudev. But as of recently you might also get a blocker with >>> kmod. >>> >>> Having said that, the migration was the worst part. After that I was >>> fine. >>> >>> >> I have the udev USE flag set for some reason, I'm sure something needed >> it at some point. Should I turn that off or does it matter? >> >> Dale >> >> :-) :-) >> > OK. I went with the idea that the udev USE flag would work with either > package. So, I switched. I only noticed one thing that could possibly, > maybe, sort of need fixing. I had dracut emerged. I was building the > init thingy until eudev came along. Anyway, it seems that dracut > insists on having udev and eudev is not a option for some reason. I > found this in the ebuild: > > CDEPEND=">sys-fs/udev-166 > dracut_modules_systemd? ( sys-apps/systemd ) > " > > Shouldn't that either depend on the virtual udev or something instead of > only on udev itself? Sort of let eudev be a option too? > > Other than that, works fine. It took me a minute to get my > mask/unmask/keyword files sorted but works fine. > > Dale > > :-) :-) > > P. S. No reboot needed either. I did the switch in the boot runlevel. > When it was done, just stopped and restarted udev then went back to > default runlevel. > It should be the virtual. Can you manually change it to >=virtual/udev-171 and see if dracut builds correctly. If so you should open a bug or ping me back. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [eudev] Is it ready now? 2013-01-21 12:24 ` Anthony G. Basile @ 2013-01-22 7:18 ` Dale 0 siblings, 0 replies; 7+ messages in thread From: Dale @ 2013-01-22 7:18 UTC (permalink / raw To: eudev Anthony G. Basile wrote: > On 01/21/2013 03:46 AM, Dale wrote: >> OK. I went with the idea that the udev USE flag would work with either >> package. So, I switched. I only noticed one thing that could possibly, >> maybe, sort of need fixing. I had dracut emerged. I was building the >> init thingy until eudev came along. Anyway, it seems that dracut >> insists on having udev and eudev is not a option for some reason. I >> found this in the ebuild: >> >> CDEPEND=">sys-fs/udev-166 >> dracut_modules_systemd? ( sys-apps/systemd ) >> " >> >> Shouldn't that either depend on the virtual udev or something instead of >> only on udev itself? Sort of let eudev be a option too? >> >> Other than that, works fine. It took me a minute to get my >> mask/unmask/keyword files sorted but works fine. >> >> Dale >> >> :-) :-) >> >> P. S. No reboot needed either. I did the switch in the boot runlevel. >> When it was done, just stopped and restarted udev then went back to >> default runlevel. >> > It should be the virtual. Can you manually change it to > >=virtual/udev-171 and see if dracut builds correctly. If so you > should open a bug or ping me back. > Sorry it took me a bit. I changed to what you posted and did a emerge -vp dracut. It did NOT want to pull in udev. It was satisfied with eudev after that change. So, that does need fixing. You want to file bug or you going to talk to the maintainer for a correction? Doesn't matter to me. Thanks much. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-01-22 7:18 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-01-20 4:30 [eudev] Is it ready now? Dale [not found] ` <50FBCBFD.4000109@gentoo.org> 2013-01-20 17:53 ` Dale 2013-01-20 18:26 ` Anthony G. Basile 2013-01-20 23:59 ` Dale 2013-01-21 8:46 ` Dale 2013-01-21 12:24 ` Anthony G. Basile 2013-01-22 7:18 ` Dale
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox