Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-07 Thread Michal Schmidt

On 06/06/2012 04:25 PM, Michal Schmidt wrote:

We will split out a systemd-libs subpackage to be more multilib-friendly.


Done in systemd-185-4.gita2368a3.fc18.

Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-07 Thread Josh Boyer
On Tue, Jun 5, 2012 at 11:30 AM, Adam Jackson a...@redhat.com wrote:
 I think we can also take this to mean that an explicit:

 Requires: udev

 is now redundant?  In which case the following (F17) packages can be cleaned
 up:

 % repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm}
 --whatrequires udev | sort -u

snip

 iwl1000-firmware-39.31.5.1-2.fc17.src.rpm
 iwl100-firmware-39.31.5.1-3.fc17.src.rpm
 iwl5150-firmware-8.24.2.2-3.fc17.src.rpm
 iwl6000-firmware-9.221.4.1-3.fc17.src.rpm
 iwl6000g2a-firmware-17.168.5.3-2.fc17.src.rpm
 iwl6000g2b-firmware-17.168.5.2-2.fc17.src.rpm
 iwl6050-firmware-41.28.5.1-4.fc17.src.rpm

Those are actually going to be retired as soon as linville gets around
to it.  They've been sucked into linux-firmware.

 linux-firmware-20120206-0.3.git06c8f81.fc17.src.rpm

Fixed.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread Jiri Popelka

On 06/05/2012 04:33 PM, Michal Schmidt wrote:

On 06/05/2012 03:52 AM, Kay Sievers wrote:

Systemd includes libudev.so.1, while the old libudev.rpm provided
libudev.so.0. Therefore, all packages using udev need to be rebuilt.


Here's a list of owners with packages that currently require
libudev.so.0 in Rawhide.

twaugh system-config-printer


fixed

--
Jiri

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread Adam Jackson
On Wed, 2012-06-06 at 01:12 +0200, Sandro Mani wrote:

 #yum update mesa-libgbm
 [...]
 --- Package mesa-libgbm.i686 0:8.1-0.5.fc18 will be updated
 --- Package mesa-libgbm.x86_64 0:8.1-0.5.fc18 will be updated
 --- Package mesa-libgbm.i686 0:8.1-0.6.fc18 will be an update
 -- Processing Dependency: libudev.so.1(LIBUDEV_183) for package: 
 mesa-libgbm-8.1-0.6.fc18.i686
 -- Processing Dependency: libudev.so.1 for package: 
 mesa-libgbm-8.1-0.6.fc18.i686
 --- Package mesa-libgbm.x86_64 0:8.1-0.6.fc18 will be an update
 -- Running transaction check
 --- Package systemd.i686 0:185-2.fc18 will be installed
 
 After having had some funny issues in the past due to there being two 
 systemds (x86_64, i686) installed for some reason, something tells me 
 that it's a bad idea to proceed with the update. Or am I wrong?

Having two systemd packages installed isn't necessarily a problem, rpm's
color concept on ELF objects should mean that x86_64 should win
wherever the two packages' files collide, which should only be
in /usr/*bin.  It's still not the prettiest thing in the world, I admit;
I'd be happier if there were a systemd-libs even if it were effectively
not optional.

But if there's not going to be a systemd-libs subpackage, any issues you
do have with this scenario are systemd bugs.

- ajax


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread Michal Schmidt

On 06/06/2012 03:26 PM, Adam Jackson wrote:

But if there's not going to be a systemd-libs subpackage, any issues you
do have with this scenario are systemd bugs.


We discussed it recently with Kay. We will split out a systemd-libs 
subpackage to be more multilib-friendly. That said, we are not aware of 
any specific issues with having both systemd.{x86_64,i686} installed.


Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread Sandro Mani


 We discussed it recently with Kay. We will split out a systemd-libs
 subpackage to be more multilib-friendly. That said, we are not aware of any
 specific issues with having both systemd.{x86_64,i686} installed.

 Just to elaborate: The issues I was referring to happened during a
F16-rawhide upgrade last December, when mistakenly doing yum upgrade
instead of distro-sync. I don't recall the specific symptoms, and didn't
investigate further since they went away with a yum erase --remove-leaves
systemd.i686. However, they might also have been caused by one of systemd's
dependencies.

Anyway, thanks for the clarifications.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread Nathanael D. Noblet

On 06/05/2012 09:30 AM, Adam Jackson wrote:

On 6/4/12 9:52 PM, Kay Sievers wrote:

We merged the upstream udev repository entirely into the systemd
repository. There is no standalone upstream udev project anymore.

The version of systemd which includes udev has landed in rawhide a
couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm
and no libudev-devel.rpm.


I think we can also take this to mean that an explicit:

Requires: udev

is now redundant? In which case the following (F17) packages can be
cleaned up:


I presume that I can remove the requires from packages in the list 
below, and that no changes to parts such as


%config(noreplace) %{_sysconfdir}/udev/rules.d/*

are required?

Come to think of it... shouldn't the rules that come with a package be 
in /lib/udev/rules.d?





% repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm}
--whatrequires udev | sort -u
aic94xx-firmware-30-3.fc17.src.rpm
alsa-firmware-1.0.25-1.fc17.src.rpm
alsa-tools-1.0.25-2.fc17.src.rpm
android-tools-20111220git1b251bd-2.fc17.src.rpm
ar9170-firmware-2009.05.28-4.fc17.src.rpm
argyllcms-1.3.6-2.fc17.src.rpm
b43-openfwwf-5.2-7.fc17.src.rpm
barry-0.17.1-7.fc17.src.rpm
bfa-firmware-3.0.0.0-2.fc17.src.rpm
biosdevname-0.3.11-6.fc17.src.rpm
bluez-4.98-3.fc17.src.rpm
btkbdd-1.2-1.fc17.src.rpm
clamtk-4.39-1.fc17.src.rpm
crda-1.1.2_2011.04.28-2.fc17.src.rpm
cups-1.5.2-12.fc17.src.rpm
device-mapper-multipath-0.4.9-25.fc17.src.rpm
dracut-018-35.git20120510.fc17.src.rpm
drbd-8.3.11-5.fc17.src.rpm
em8300-0.18.0-6.fc17.src.rpm
fbterm-1.6-5.fc17.src.rpm
fxload-2002_04_11-11.fc17.src.rpm
gpsd-3.4-1.fc17.src.rpm
hplip-3.12.4-2.fc17.src.rpm
i2c-tools-3.1.0-1.fc17.src.rpm
initscripts-9.37-1.fc17.src.rpm
iscan-firmware-2.26.4-2.fc17.src.rpm
isdn4k-utils-3.2-81.fc17.src.rpm
isight-firmware-tools-1.6-2.fc17.src.rpm
iwl1000-firmware-39.31.5.1-2.fc17.src.rpm
iwl100-firmware-39.31.5.1-3.fc17.src.rpm
iwl5150-firmware-8.24.2.2-3.fc17.src.rpm
iwl6000-firmware-9.221.4.1-3.fc17.src.rpm
iwl6000g2a-firmware-17.168.5.3-2.fc17.src.rpm
iwl6000g2b-firmware-17.168.5.2-2.fc17.src.rpm
iwl6050-firmware-41.28.5.1-4.fc17.src.rpm
libconcord-0.23-9.fc17.src.rpm
libdrm-2.4.33-1.fc17.src.rpm
libertas-sd8686-firmware-9.70.20.p0-2.fc17.src.rpm
libftdi-0.19-3.fc17.src.rpm
libgpod-0.8.2-4.fc17.src.rpm
libguestfs-1.17.36-2.fc17.src.rpm
libmtp-1.1.3-2.fc17.src.rpm
libnjb-2.2.7-2.fc17.src.rpm
libosinfo-0.1.1-1.fc17.src.rpm
libphidget-2.1.8.20120123-1.fc17.src.rpm
libvirt-0.9.11.3-1.fc17.src.rpm
linux-firmware-20120206-0.3.git06c8f81.fc17.src.rpm
lvm2-2.02.95-6.fc17.src.rpm
MAKEDEV-3.24-10.fc17.src.rpm
mdadm-3.2.3-6.fc17.src.rpm
media-player-info-16-1.fc17.src.rpm
microcode_ctl-1.17-24.fc17.src.rpm
NetworkManager-0.9.4.0-7.git20120403.fc17.src.rpm
netxen-firmware-4.0.534-5.fc17.src.rpm
nut-2.6.3-2.fc17.src.rpm
olpc-utils-2.0.7-1.fc17.src.rpm
openct-0.6.20-3.fc17.src.rpm
openni-primesense-5.0.3.3-2.fc17.src.rpm
os-prober-1.53-1.fc17.src.rpm
ovirt-node-2.3.0-1.fc17.src.rpm
pcmciautils-018-2.fc17.src.rpm
pulseaudio-1.1-9.fc17.src.rpm
rdma-1.0-11.fc17.src.rpm
sane-backends-1.0.22-9.fc17.src.rpm
svxlink-11.11.1-4.fc17.src.rpm
synce-sync-engine-0.15.1-3.fc17.src.rpm
systemd-44-8.fc17.src.rpm
udev-182-1.fc17.src.rpm
udisks-1.0.4-6.fc17.src.rpm
udisks2-1.94.0-4.fc17.src.rpm
upower-0.9.16-1.fc17.src.rpm
usb_modeswitch-data-20111023-2.fc17.src.rpm
util-linux-2.21.1-1.fc17.src.rpm
v4l-utils-0.8.7-1.fc17.src.rpm
vdr-1.7.27-1.fc17.src.rpm
vdr-remote-0.4.0-19.fc17.src.rpm
xen-4.1.2-15.fc17.src.rpm
xorg-x11-drv-synaptics-1.6.0-1.fc17.src.rpm
xorg-x11-drv-vmmouse-12.8.0-1.fc17.src.rpm
xorg-x11-drv-wacom-0.14.0-2.fc17.src.rpm

- ajax




--
Nathanael d. Noblet
t 403.875.4613
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread Garrett Holmstrom

On 2012-06-06 6:26, Adam Jackson wrote:

On Wed, 2012-06-06 at 01:12 +0200, Sandro Mani wrote:

After having had some funny issues in the past due to there being two
systemds (x86_64, i686) installed for some reason, something tells me
that it's a bad idea to proceed with the update. Or am I wrong?


Having two systemd packages installed isn't necessarily a problem, rpm's
color concept on ELF objects should mean that x86_64 should win
wherever the two packages' files collide, which should only be
in /usr/*bin.  It's still not the prettiest thing in the world, I admit;
I'd be happier if there were a systemd-libs even if it were effectively
not optional.


Does rpm handle binaries' colors everywhere, or just in selected 
locations?  I'm especially curious about /usr/lib.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread Michal Schmidt

On 06/06/2012 05:39 PM, Nathanael D. Noblet wrote:

Come to think of it... shouldn't the rules that come with a package be
in /lib/udev/rules.d?


Yes, but add the /usr prefix: %{_prefix}/lib/udev/rules.d/

Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread Michal Schmidt

On 06/06/2012 05:52 PM, Garrett Holmstrom wrote:

Does rpm handle binaries' colors everywhere, or just in selected
locations? I'm especially curious about /usr/lib.


I don't know the answer in the general case, but it definitely works for 
binaries in /usr/lib/systemd/. No conflicts are reported when installing 
systemd for both archs and all ELFs there come out as 64-bit as they should.


Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread John Reiser
On 06/06/2012 07:25 AM, Michal Schmidt wrote:

  We will split out a systemd-libs subpackage to be more multilib-friendly. 
 That said, we are not aware of any specific issues with having both 
 systemd.{x86_64,i686} installed.

As long as systemd.rpm has content that is platform-dependent, then
it is likely that there will be overlap in some files; in this
case, such as x86_64 and i686 versions of the same binary executable
file.  In theory the rpm feature of executable flavors should resolve
such an overlap (in favor of .x86_64 in this case), but this feature
relies on the corresponding .x86_64 and .i686 packages always having
the same n-v-r. The mirror system isn't that reliable [I see a sync
failure a few times per year], so the dreaded yum error protected
multilib versions likely will occur.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-06 Thread Peter Hutterer
On Tue, Jun 05, 2012 at 11:30:57AM -0400, Adam Jackson wrote:
 On 6/4/12 9:52 PM, Kay Sievers wrote:
 We merged the upstream udev repository entirely into the systemd
 repository. There is no standalone upstream udev project anymore.
 
 The version of systemd which includes udev has landed in rawhide a
 couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm
 and no libudev-devel.rpm.
 
 I think we can also take this to mean that an explicit:
 
 Requires: udev
 
 is now redundant?  In which case the following (F17) packages can be
 cleaned up:
 
 % repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm}
 --whatrequires udev | sort -u

 xorg-x11-drv-synaptics-1.6.0-1.fc17.src.rpm
 xorg-x11-drv-vmmouse-12.8.0-1.fc17.src.rpm
 xorg-x11-drv-wacom-0.14.0-2.fc17.src.rpm

done.
 
Cheers,
  Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Michal Schmidt

On 06/05/2012 03:52 AM, Kay Sievers wrote:

Systemd includes libudev.so.1, while the old libudev.rpm provided
libudev.so.0. Therefore, all packages using udev need to be rebuilt.


Here's a list of owners with packages that currently require 
libudev.so.0 in Rawhide.


# repoquery --whatrequires libudev.so.0 --qf '%{sourcerpm}' | rev | cut 
-f3- -d- | rev | sort | uniq | fedoradev-pkgowners | sort | column -t


ajax   libdrm
bskeggsxorg-x11-drv-nouveau
davidz udisks
lennartlibatasmart
lennartlibcanberra
lennartpulseaudio
libvirt-maint  libvirt
lvm-team   lvm2
pgfolpc-kbdshim
rdieterqt-mobility
rhughesweston
rrelyeapcsc-lite
twaugh system-config-printer
udev-maint udev
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Adam Jackson

On 6/4/12 9:52 PM, Kay Sievers wrote:

We merged the upstream udev repository entirely into the systemd
repository. There is no standalone upstream udev project anymore.

The version of systemd which includes udev has landed in rawhide a
couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm
and no libudev-devel.rpm.


I think we can also take this to mean that an explicit:

Requires: udev

is now redundant?  In which case the following (F17) packages can be 
cleaned up:


% repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm} 
--whatrequires udev | sort -u

aic94xx-firmware-30-3.fc17.src.rpm
alsa-firmware-1.0.25-1.fc17.src.rpm
alsa-tools-1.0.25-2.fc17.src.rpm
android-tools-20111220git1b251bd-2.fc17.src.rpm
ar9170-firmware-2009.05.28-4.fc17.src.rpm
argyllcms-1.3.6-2.fc17.src.rpm
b43-openfwwf-5.2-7.fc17.src.rpm
barry-0.17.1-7.fc17.src.rpm
bfa-firmware-3.0.0.0-2.fc17.src.rpm
biosdevname-0.3.11-6.fc17.src.rpm
bluez-4.98-3.fc17.src.rpm
btkbdd-1.2-1.fc17.src.rpm
clamtk-4.39-1.fc17.src.rpm
crda-1.1.2_2011.04.28-2.fc17.src.rpm
cups-1.5.2-12.fc17.src.rpm
device-mapper-multipath-0.4.9-25.fc17.src.rpm
dracut-018-35.git20120510.fc17.src.rpm
drbd-8.3.11-5.fc17.src.rpm
em8300-0.18.0-6.fc17.src.rpm
fbterm-1.6-5.fc17.src.rpm
fxload-2002_04_11-11.fc17.src.rpm
gpsd-3.4-1.fc17.src.rpm
hplip-3.12.4-2.fc17.src.rpm
i2c-tools-3.1.0-1.fc17.src.rpm
initscripts-9.37-1.fc17.src.rpm
iscan-firmware-2.26.4-2.fc17.src.rpm
isdn4k-utils-3.2-81.fc17.src.rpm
isight-firmware-tools-1.6-2.fc17.src.rpm
iwl1000-firmware-39.31.5.1-2.fc17.src.rpm
iwl100-firmware-39.31.5.1-3.fc17.src.rpm
iwl5150-firmware-8.24.2.2-3.fc17.src.rpm
iwl6000-firmware-9.221.4.1-3.fc17.src.rpm
iwl6000g2a-firmware-17.168.5.3-2.fc17.src.rpm
iwl6000g2b-firmware-17.168.5.2-2.fc17.src.rpm
iwl6050-firmware-41.28.5.1-4.fc17.src.rpm
libconcord-0.23-9.fc17.src.rpm
libdrm-2.4.33-1.fc17.src.rpm
libertas-sd8686-firmware-9.70.20.p0-2.fc17.src.rpm
libftdi-0.19-3.fc17.src.rpm
libgpod-0.8.2-4.fc17.src.rpm
libguestfs-1.17.36-2.fc17.src.rpm
libmtp-1.1.3-2.fc17.src.rpm
libnjb-2.2.7-2.fc17.src.rpm
libosinfo-0.1.1-1.fc17.src.rpm
libphidget-2.1.8.20120123-1.fc17.src.rpm
libvirt-0.9.11.3-1.fc17.src.rpm
linux-firmware-20120206-0.3.git06c8f81.fc17.src.rpm
lvm2-2.02.95-6.fc17.src.rpm
MAKEDEV-3.24-10.fc17.src.rpm
mdadm-3.2.3-6.fc17.src.rpm
media-player-info-16-1.fc17.src.rpm
microcode_ctl-1.17-24.fc17.src.rpm
NetworkManager-0.9.4.0-7.git20120403.fc17.src.rpm
netxen-firmware-4.0.534-5.fc17.src.rpm
nut-2.6.3-2.fc17.src.rpm
olpc-utils-2.0.7-1.fc17.src.rpm
openct-0.6.20-3.fc17.src.rpm
openni-primesense-5.0.3.3-2.fc17.src.rpm
os-prober-1.53-1.fc17.src.rpm
ovirt-node-2.3.0-1.fc17.src.rpm
pcmciautils-018-2.fc17.src.rpm
pulseaudio-1.1-9.fc17.src.rpm
rdma-1.0-11.fc17.src.rpm
sane-backends-1.0.22-9.fc17.src.rpm
svxlink-11.11.1-4.fc17.src.rpm
synce-sync-engine-0.15.1-3.fc17.src.rpm
systemd-44-8.fc17.src.rpm
udev-182-1.fc17.src.rpm
udisks-1.0.4-6.fc17.src.rpm
udisks2-1.94.0-4.fc17.src.rpm
upower-0.9.16-1.fc17.src.rpm
usb_modeswitch-data-20111023-2.fc17.src.rpm
util-linux-2.21.1-1.fc17.src.rpm
v4l-utils-0.8.7-1.fc17.src.rpm
vdr-1.7.27-1.fc17.src.rpm
vdr-remote-0.4.0-19.fc17.src.rpm
xen-4.1.2-15.fc17.src.rpm
xorg-x11-drv-synaptics-1.6.0-1.fc17.src.rpm
xorg-x11-drv-vmmouse-12.8.0-1.fc17.src.rpm
xorg-x11-drv-wacom-0.14.0-2.fc17.src.rpm

- ajax

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Adam Jackson

On 6/5/12 10:33 AM, Michal Schmidt wrote:


Here's a list of owners with packages that currently require
libudev.so.0 in Rawhide.

# repoquery --whatrequires libudev.so.0 --qf '%{sourcerpm}' | rev | cut
-f3- -d- | rev | sort | uniq | fedoradev-pkgowners | sort | column -t

ajax libdrm
bskeggs xorg-x11-drv-nouveau
davidz udisks

 rhughes weston

Fixed.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Jon Ciesla
On Tue, Jun 5, 2012 at 10:30 AM, Adam Jackson a...@redhat.com wrote:
 On 6/4/12 9:52 PM, Kay Sievers wrote:

 We merged the upstream udev repository entirely into the systemd
 repository. There is no standalone upstream udev project anymore.

 The version of systemd which includes udev has landed in rawhide a
 couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm
 and no libudev-devel.rpm.


 I think we can also take this to mean that an explicit:

 Requires: udev

 is now redundant?  In which case the following (F17) packages can be cleaned
 up:

 % repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm}
 --whatrequires udev | sort -u

 argyllcms-1.3.6-2.fc17.src.rpm
 clamtk-4.39-1.fc17.src.rpm

Fixed.

-J

 - ajax

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Sandro Mani


On 06/05/2012 03:52 AM, Kay Sievers wrote:

Systemd includes libudev.so.1, while the old libudev.rpm provided
libudev.so.0. Therefore, all packages using udev need to be rebuilt.


Here is what's happening on my x86_64 rawhide install which has some 
i686 packages (in particular, mesa) installed due to wine:


#yum update mesa-libgbm
[...]
--- Package mesa-libgbm.i686 0:8.1-0.5.fc18 will be updated
--- Package mesa-libgbm.x86_64 0:8.1-0.5.fc18 will be updated
--- Package mesa-libgbm.i686 0:8.1-0.6.fc18 will be an update
-- Processing Dependency: libudev.so.1(LIBUDEV_183) for package: 
mesa-libgbm-8.1-0.6.fc18.i686
-- Processing Dependency: libudev.so.1 for package: 
mesa-libgbm-8.1-0.6.fc18.i686

--- Package mesa-libgbm.x86_64 0:8.1-0.6.fc18 will be an update
-- Running transaction check
--- Package systemd.i686 0:185-2.fc18 will be installed

After having had some funny issues in the past due to there being two 
systemds (x86_64, i686) installed for some reason, something tells me 
that it's a bad idea to proceed with the update. Or am I wrong?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel