Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
"xorg-server-1.13.0-r1.ebuild" broken : ">=virtual/udev-150"
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
UncleVan
n00b
n00b


Joined: 08 Feb 2011
Posts: 47

PostPosted: Wed Dec 05, 2012 8:14 pm    Post subject: "xorg-server-1.13.0-r1.ebuild" broken : "> Reply with quote

In case someone experiences strange behavior in "world" updates with still (older) "sys-fs/udev-164-r2" : in recent portage trees the "xorg-server-1.13.0-r1.ebuild" got broken:

older:
Code:
56     udev? ( >=sys-fs/udev-150 )

recent:
Code:
56     udev? ( >=virtual/udev-150 )

Reason: There is no "virtual/udev-150"; should be probably ">=virtual/udev-0"

Somebody be nice to post a bug ? - Thanks !

Your UncleVan.
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2330
Location: UK

PostPosted: Thu Dec 06, 2012 12:06 am    Post subject: Reply with quote

Quote:
There is no "virtual/udev-150"

Correct — there are only virtual/udev-171 (keyworded stable) and virtual/udev-196 (keyworded ~) to satisfy that >= requirement. What problem are you having again?
Back to top
View user's profile Send private message
UncleVan
n00b
n00b


Joined: 08 Feb 2011
Posts: 47

PostPosted: Thu Dec 06, 2012 2:54 pm    Post subject: Reply with quote

Well, first of all it is obviously wrong...;-)

Now, if one has anything greater then - ">sys-fs/udev-164-r2" - , there is nothing noticable, because ">=virtual/udev-150" is satisfied due to "virtual/udev-171".

Unfortunately, the "sys-fs/udev-171-r5" and later ones dont work for me, because of some bug in the transition from "/dev/.udev" to the "/run/udev" directory - udevd quits in the middle, leaving me without serial controller and keyboard (i8042.ko and atkbd.ko are build as modules on my systems. Here is a longer discussion - to no avail...http://forums.gentoo.org/viewtopic-t-913312-start-0-postdays-0-postorder-asc-highlight-.html).

Therefore Ive masked >sys-fs/udev-164-r2 to workaround on this. Whith ">=virtual/udev-150" this leads to portage trying to pull some completely wrong packages/versions and to blocking mess... With ">=virtual/udev-0" all updates are running smoothly.

Admittedly its a rather rare issue, it should nevertheles be corrected.

Your UncleVan.
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8920

PostPosted: Thu Dec 06, 2012 10:49 pm    Post subject: Reply with quote

Is it wrong? Does the new X server work with the older udev?

With regard to your prior thread, if you know that you need those kernel options for a working console, why do you build them as modules?
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Fri Dec 07, 2012 11:35 am    Post subject: Reply with quote

Quote:
Does the new X server work with the older udev?


Working without problems with udev-171-r9.
_________________
TIA
Back to top
View user's profile Send private message
UncleVan
n00b
n00b


Joined: 08 Feb 2011
Posts: 47

PostPosted: Fri Dec 07, 2012 3:31 pm    Post subject: ... Reply with quote

Thanks for the response !

To Hu:
=====
1.) Yes, imho it is wrong. The kind of change is suggesting that the developer meant any >=sys-fs/udev-150; or with virtuals it should be ">=virtual/udev-0" . (indeed Firefox is working well with this). And, once more, there is no "virtual/udev-150" anyway.
If one says ">=virtual/udev-171" then she/he would make recent firefox versions unusable (under circumstances).

2.) Concerning my problem with sys-fs/udev-171-r5 and newer - I tried everything to no resque; I did find some ghastly bugs (trying to write into non existing directory "/run/udev/rules.d/..."), but problem seems to be deeper, maybe not in udev itself. BTW why should I change my kernel configuration to meet possibly new (undocumented ?) udev requirements ? Especially when it was going well for years ? Any bloody distro wont do it either...;-) (This failure is reproducable on all my machines - Thinkpads).

To wcg : In this context I dont get your point ... ?
=====

Your UncleVan.
Back to top
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4248

PostPosted: Fri Dec 07, 2012 8:16 pm    Post subject: Re: ... Reply with quote

UncleVan wrote:
BTW why should I change my kernel configuration to meet possibly new (undocumented ?) udev requirements ?

Because newer kernels won't be able to run with that old udev, and so your system have security holes because of the old kernel you are running.
Upto you to consider this like you wish, but for a laptop, security holes shouldn't be ignore if you move it to public places.
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8920

PostPosted: Fri Dec 07, 2012 10:50 pm    Post subject: Re: ... Reply with quote

wcg wrote:
Quote:
Does the new X server work with the older udev?


Working without problems with udev-171-r9.
Thanks for the report, but I meant a udev old enough that UncleVan would run it. :)
UncleVan wrote:
To Hu:
=====
1.) Yes, imho it is wrong. The kind of change is suggesting that the developer meant any >=sys-fs/udev-150; or with virtuals it should be ">=virtual/udev-0" . (indeed Firefox is working well with this). And, once more, there is no "virtual/udev-150" anyway.
If one says ">=virtual/udev-171" then she/he would make recent firefox versions unusable (under circumstances).
You restated your position, but did not answer my question. It is only wrong to require >=150 if versions <150 are known to work. I inquired whether that was the case, but you did not answer that. You had earlier stated that "all updates are running smoothly," but it is unclear from that statement whether the resulting system runs correctly or if you only meant that you are able to build with an older udev.

There is no need for a specific =virtual/udev-150 when using a greater-equal operation. This probably happened because there was a =sys-fs/udev-150 and the developer just changed it to virtual without adjusting the number. If <sys-fs/udev-150 is not known to work and <virtual/udev-150 is satisfied by <sys-fs/udev-150, then allowing <virtual/udev-150 is wrong.

Could you elaborate on your Firefox comments? I have a working Firefox on a system using udev-171.
UncleVan wrote:
2.) Concerning my problem with sys-fs/udev-171-r5 and newer - I tried everything to no resque; I did find some ghastly bugs (trying to write into non existing directory "/run/udev/rules.d/..."), but problem seems to be deeper, maybe not in udev itself. BTW why should I change my kernel configuration to meet possibly new (undocumented ?) udev requirements ? Especially when it was going well for years ? Any bloody distro wont do it either...;-) (This failure is reproducable on all my machines - Thinkpads).
You should change your kernel configuration because the old setup is suboptimal and because it does not work. If you insist on using the original configuration, go ahead. However, the change I proposed is simple, safe, and likely to lead to less trouble, rather than more trouble.
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Sat Dec 08, 2012 3:15 am    Post subject: Reply with quote

Quote:
o wcg : In this context I dont get your point ... ?

I was only answering Hu's question about Xorg-1.13.x and udev.
I think of "old" udev as "<udev-181" and "new" udev as ">=udev-181"
(masked on my system). This was the watershed between support
for separate /usr and /var partitions (old) and no support for separate
/usr and /var partitions (new). udev-171-r9 is in the old group, and
works fine with current stable Xorg.

I would expect that udev-171-r9 is the version that you would want
if you want it to work "the way it always has" (wihout changes to
partitions, init scripts, initramfs, etc).

The moving of /var/run/ to /run/ mounted on a tmpfs. with /var/run/
as a symbolic link to /run/, is a minor irritation. Some packages
complain but still work, and I assume that there is a performance
benefit when creating or removing pid files. Scripts which write
to files in some directory that used to be persistent under
/var/run/ need to be changed to mkdir first, because the real
directory that /var/run/ references now is not persistent across
reboots. Directories/files under /var/run/ that stored information
expected to persist across reboots (wrong place to put them
from the beginning; /var/run/ was not a place designed to store
persistent configuration information) have probably been
relocated by the packages that use them, or still need to be.

Note: my "virtual/udev" is "virtual/udev-171".

In /etc/portage/package.mask/sys-fs:
Code:

>=sys-fs/udev-181

_________________
TIA
Back to top
View user's profile Send private message
UncleVan
n00b
n00b


Joined: 08 Feb 2011
Posts: 47

PostPosted: Sat Dec 08, 2012 4:40 pm    Post subject: Reply with quote

Just to not get lost in translations...

1.) Xorg - x11-base/xorg-server-1.13.0-r1 - gets build without any problems and is working perfectly with sys-fs/udev-164-r2, which corr. to virtual/udev-0; hence also with "<virtual/udev-150"

2.) Earlear contents of this very same xorg-server-1.13.0-r1.ebuild sayd ">=sys-fs/udev-150", which was/is also OK with sys-fs/udev-164-r2.
Recently this changed to ">=virtual/udev-150", which
[*] a.) is imho mistaken, typo
[*] b.) pulls in newer udev, which doesnt work for me.
[*] c.) without any new revision or whatsoever.
3. I tried almost everything, including your suggestion to compile i8042 and atkbd into the kernel just in February - to no success. It is extremly difficult to recherche this on a "live" system, so I let it be for now - and here this is prob. off-topic.

The point is only this change in xorg-server-1.13.0-r1.ebuild to be bug-posted to the developer.

@ krinn and wcg:
===========
Im greatful for any of your help and suggestions in this matter.

I am using the most recent stabil kernel still with ys-fs/udev-164-r2 :

[IP-] [ ] sys-kernel/gentoo-sources-3.5.7:3.5.7

- no problems so far.

I couldnt exclude some other obscure kernel conf - concerning tmpfs etc.; but I cant find it out by myself. And you would probably agree that no new udev "feature" should prevent well known modules from loading ;-) - if ...

Could we agree to use the other thread ? http://forums.gentoo.org/viewtopic-t-913312-start-0-postdays-0-postorder-asc-highlight-.html

Thanks to all so far !

Your UncleVan.
Back to top
View user's profile Send private message
hkmaly
n00b
n00b


Joined: 13 Jul 2006
Posts: 20

PostPosted: Sat Feb 16, 2013 11:00 pm    Post subject: Reply with quote

UncleVan wrote:
Just to not get lost in translations...

1.) Xorg - x11-base/xorg-server-1.13.0-r1 - gets build without any problems and is working perfectly with sys-fs/udev-164-r2, which corr. to virtual/udev-0; hence also with "<virtual/udev-150"


Personally I didn't have virtual/udev-0 anywhere, so I just created virtual/udev-164-r2 and installed it. Works too (and I mean that the xorg-server-1.12 works).
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum