* [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
* 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