| View previous topic :: View next topic |
| Author |
Message |
UncleVan
n00b
Joined: 08 Feb 2011
Posts: 72
|
 Posted: Wed Dec 05, 2012 8:14 pm Post subject: "xorg-server-1.13.0-r1.ebuild" broken : "> |
 |
|
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 |
|
 |
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Thu Dec 06, 2012 12:06 am Post subject: |
|
|
| 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 |
|
|
UncleVan
n00b
Joined: 08 Feb 2011
Posts: 72
|
| Posted: Thu Dec 06, 2012 2:54 pm Post subject: |
|
|
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...https://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 |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21586
|
| Posted: Thu Dec 06, 2012 10:49 pm Post subject: |
|
|
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 |
|
|
wcg
Guru
Joined: 06 Jan 2009
Posts: 588
|
| Posted: Fri Dec 07, 2012 11:35 am Post subject: |
|
|
| Quote: | | Does the new X server work with the older udev? |
Working without problems with udev-171-r9.
_________________
TIA |
|
| Back to top |
|
|
UncleVan
n00b
Joined: 08 Feb 2011
Posts: 72
|
| Posted: Fri Dec 07, 2012 3:31 pm Post subject: ... |
|
|
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 |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Fri Dec 07, 2012 8:16 pm Post subject: Re: ... |
|
|
| 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 |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21586
|
| Posted: Fri Dec 07, 2012 10:50 pm Post subject: Re: ... |
|
|
| 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 |
|
|
wcg
Guru
Joined: 06 Jan 2009
Posts: 588
|
| Posted: Sat Dec 08, 2012 3:15 am Post subject: |
|
|
| 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:
_________________
TIA |
|
| Back to top |
|
|
UncleVan
n00b
Joined: 08 Feb 2011
Posts: 72
|
| Posted: Sat Dec 08, 2012 4:40 pm Post subject: |
|
|
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 ? https://forums.gentoo.org/viewtopic-t-913312-start-0-postdays-0-postorder-asc-highlight-.html
Thanks to all so far !
Your UncleVan. |
|
| Back to top |
|
|
hkmaly
n00b
Joined: 13 Jul 2006
Posts: 45
|
| Posted: Sat Feb 16, 2013 11:00 pm Post subject: |
|
|
| 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 |
|
|
|
Portage & Programming
