Description of problem: The version of glib2-devel that ships with fedora 15 adds files that install in /usr/share/dlib-2.0/gdb. This results in conflicts if you try to install both the 32-bit and 64-bit versions of this package. This essentially makes it no longer possible to develop 32-bit software under a 64-bit version of fedora. This has always worked in previous versions. Version-Release number of selected component (if applicable): glib2-devel-2.28.8-1.fc15.i686 How reproducible: Always Steps to Reproduce: 1. yum install glib2-devel.x86_64 2. yum install glib2-devel.i686 3. Actual results: Conflicts in various files in /usr/share/glib-2.0/gdb resulting in failure of the installation. Expected results: Expect both packages to be able to be installed. Additional info: This impacts my ability to do Mozilla software development.
i confirm this bug, you must think to merge this new file into a separete package
Created attachment 513368 [details] patch to solve the bug i have add a patch to solve the bug, if the maintener would like add it and rebuild the package.
Silly me just installed fedora 16 and assumed this would have been fixed by now. But, alas the issue still exists.
Issue exists for me too.
I have also experienced this issue on Fedora 16 x86_64.
*** Bug 784269 has been marked as a duplicate of this bug. ***
Looking over the guidelines, there is nothing that states that -devel packages have to be multiarch compatible. I think this is likely an oversight. I would recommend opening a bug for the FPC[1] to add to the guidelines that -devel packages have to be parallel-installable with multiarch. [1]https://fedorahosted.org/fpc/
*** Bug 757174 has been marked as a duplicate of this bug. ***
Created attachment 571730 [details] rebased fix
(In reply to comment #9) > Created attachment 571730 [details] > rebased fix Some spelling errors: undependant -> independent commun -> common Also, the "#%" thing can make RPM unhappy; just changing the % to a # is usually done.
Created attachment 574199 [details] 2.32.0-2 based glib2.spec patch Rebased on 2.32.0, corrected both spelling errors, added space between "#" and "%" which is just what the version before the patch had. Alon
Created attachment 574201 [details] 2.32.0 based, replaced # % with # to avoid macro in comment warnings from rpmlint Or use this version, it passes rpmlint with no warnings and errors using the suggestion the second before last comment. (and the patch is correctly named, it's 2.32, not 2.33 - but that was just the patch name). Alon
forget both comments, my bad - there are move changes then just bumping the version. Looks like a glib2-common would also be needed. Here is the list of conflicts: glib2-devel conflicts that can go to glib2-common-devel /usr/include/* /usr/bin/glib-gettextize /usr/bin/glib-mkenums /usr/bin/gtester-report -> all three are perl/python/posix scripts. glib2 conflicts (glib2-common?) /usr/share/man/man1/* /usr/share/locale/* /usr/share/doc/glib2-2.32.0/* /etc/bash_completion.d/*
Still present in 2.32.3-1.fc17: Transaction Check Error: file /usr/bin/gdbus-codegen from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64 file /usr/share/glib-2.0/gdb/glib.pyc from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64 file /usr/share/glib-2.0/gdb/glib.pyo from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64 file /usr/share/glib-2.0/gdb/gobject.pyc from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64 file /usr/share/glib-2.0/gdb/gobject.pyo from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64 file /usr/share/systemtap/tapset/glib.stp from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64 file /usr/share/systemtap/tapset/gobject.stp from install of glib2-devel-2.32.3-1.fc17.i686 conflicts with file from package glib2-devel-2.32.3-1.fc17.x86_64
Working on FC15. Has a workaround / patch been identified for 2.6.43.8-1.fc15.x86_64?
Created attachment 596788 [details] Workaround shell script This it the workaround I am using. Instead of installing glib2-devel.i686, I just run this script as root each time glib2-devel is updated.
Oh I should mention that in addition to the above script you also need to make sure you install glib2.i686 and elfutils-libelf.i686 which would normally be dependencies fo the glib2-devel.i686 package.
You should install those before running the workaround shell script.
Bill, How does your script help with all the -devel packages which depend on glib-devel.i686 ?
(In reply to comment #19) > Bill, > > How does your script help with all the -devel packages which depend on > glib-devel.i686 ? Unfortunately it doesn't. However, what it does do is permit to build 32-bit versions of Mozilla products, which was my original issue that prompted me to file this bug.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Reopening as this issue still exists on F-17.
*** Bug 846717 has been marked as a duplicate of this bug. ***
*** Bug 828448 has been marked as a duplicate of this bug. ***
One should use mock (or equivalent) to build 32 bit binares on a 64 bit host. However, I'd review a patch if someone cared enough to rebase against rawhide/master. Note that the -static subpackage is gone now.
(In reply to comment #25) > One should use mock (or equivalent) to build 32 bit binares on a 64 bit host. In that case, we can drop *-devel.i686 on x86_64. But I wish we wouldn't, this was a useful feature for me until this bug.
(In reply to comment #25) > One should use mock (or equivalent) to build 32 bit binares on a 64 bit host. One of the main reasons I use 32bit devel packages on 64bit hosts is to quickly build 32bit executables, e.g. to check architecture-dependent differences in the binaries, like when some types only overflow on 32bit, but not 64bit. It's pretty handy when dealing with security issues. > However, I'd review a patch if someone cared enough to rebase against > rawhide/master. Note that the -static subpackage is gone now. Sure. I want to compare the current sub-packages between 64bit and 32bit to ensure that I catch all conflicts.
This also blocks inclusion of gstreamer support in wine.
+1 to co-developing 32-bit and 64-bit binaries without actually having to create a separate vm install, or whatever. This used to work... surely a simple matter of appropriate subpackaging?
(In reply to comment #29) > +1 to co-developing 32-bit and 64-bit binaries without actually having > to create a separate vm install, or whatever. This used to work... > surely a simple matter of appropriate subpackaging? You don't need a separate virtual machine - mock creates relatively lightweight containers.
(In reply to comment #30) > (In reply to comment #29) > > +1 to co-developing 32-bit and 64-bit binaries without actually having > > to create a separate vm install, or whatever. This used to work... > > surely a simple matter of appropriate subpackaging? > > You don't need a separate virtual machine - mock creates relatively > lightweight containers. When I looked into this, it seemed lightweight as opposed to VM but seemed that I would need to install packages that I already need on the native OS in order to run 32-bit apps again under mock so that I was wasting a lot of disk space doing things that way.
BTW. The way I have been doing 32-bit installs under 64-bit OS had worked at least since fedora version 6.
(In reply to comment #30) > You don't need a separate virtual machine - mock creates relatively > lightweight containers. Unfortunately, mock is not the ideal development environment either for hacking on/debugging things.
(In reply to comment #33) > Unfortunately, mock is not the ideal development environment either for > hacking on/debugging things. Yes, ./configure CC='gcc -m32' is way easier than mock, VMs, or whatnot. Fedora has mostly been very good with the 32/64 bit library coexistence, but there's always a few straggler packages that break, mostly for stupid things (did anyone say Doxygen?). I always end up filing and refiling dozens of bugs every release :-/
(In reply to comment #34) > I always end up filing and refiling dozens of bugs every release :-/ That's because multilib as it exists in Fedora/OpenSUSE/RHEL was *never designed* for this. It was just a hack so you could *run* 32 bit binaries on a 64 bit host system; nothing to do with compiling. On the other hand, Debian's multiarch is designed for this: http://wiki.debian.org/Multiarch
But the problem here is that there is a bunch of python crap having zero to do with the traditional lib-devel packages that is provided with both packages is the same in both packages , but is not marked a non-conflicting. I mean really why are we arguing about his crap?
OH may not have been python i did not really check cause i don't remember but the part that conflicts really does not because it is identical in both packages.
Ok so there's two roots to this: 1) Python .py{c,o} files embed architecture-specific data, but we're installing them in %{datadir} 2) The systemtap tapsets encode the absolute path to the shared library, which is architecture-specific Splitting off a noarch -devel-common is really a hack, because it doesn't solve that - in fact, whether or not the tapset will work will be a random function of whatever architecture the builder happened to be!
Comment on attachment 513368 [details] patch to solve the bug Breaks systemtap.
(In reply to comment #36) > But the problem here is that there is a bunch of python crap having zero to > do with the traditional lib-devel packages that is provided with both > packages is the same in both packages , but is not marked a non-conflicting. > I mean really why are we arguing about his crap? We can relatively easily solve the Python bytecode conflict by simply deleting it, and in fact I will commit a patch to F18 to do this now. Solving the systemtap one is not that easy.
(In reply to comment #35) > (In reply to comment #34) > > > I always end up filing and refiling dozens of bugs every release :-/ > > That's because multilib as it exists in Fedora/OpenSUSE/RHEL was *never > designed* for this. It was just a hack so you could *run* 32 bit binaries > on a 64 bit host system; nothing to do with compiling. > > On the other hand, Debian's multiarch is designed for this: > http://wiki.debian.org/Multiarch OK, SO you are saying that for my Mozilla developement activities I should switch form fedora to Debian? Seems like an odd suggestion to be coming form someone with a redhat email address.
BTW this is why I am still doing my Mozilla development under fedora 14. But if the answer is this will not be fixed and works under debian, I could easily just switch distro's.
(In reply to comment #41) > OK, SO you are saying that for my Mozilla developement activities I should > switch form fedora to Debian? Seems like an odd suggestion to be coming > form someone with a redhat email address. I used to be a Debian developer and in fact, wrote the second most popular Debian build system (CDBS). My highest loyalty is to Free Software, not a particular packaging format. That said, you can't switch to the current release of Debian and have it work - multiarch is targeted for Wheezy in 2013 last I heard (http://lwn.net/Articles/482952/) So, I do really want to help you use Fedora (or more ideally Red Hat Enterprise Linux) for the Mozilla build system. I'll pull the Systemtap people into this discussion and figure out how we can have multilib tapsets.
*** Bug 708442 has been marked as a duplicate of this bug. ***
Several possible solutions to the systemtap part of the problem: - use autoconf or whatnot to generate a arch/version-tagged set of .stp files (which would contain in them the arch/version-specific shared library names) e.g. for glib.stp, rename to x86-64-v2.0-glib.stp (Last I checked, hotspot does this.) - use wildcards in the .stp files (so that their content is arch/version-invariant: e.g. for glib.stp: - probe FOO = process("/lib64/libglib-2.0.so.0.3000.3").mark("quark__new") + probe FOO = process("/lib*/libglib*").mark("quark__new") (and/or /usr/lib*) - nag us harder to implement http://sourceware.org/bugzilla/show_bug.cgi?id=10485 which is a non-wildcard way of doing approx. the same thing
(In reply to comment #45) > Several possible solutions to the systemtap part of the problem: > > - use autoconf or whatnot to generate a arch/version-tagged set of .stp > files (which would contain in them the arch/version-specific shared library > names) > e.g. for glib.stp, rename to x86-64-v2.0-glib.stp > (Last I checked, hotspot does this.) Testing a build with this now.
fche, out of curiosity, do you if libdl dynamic string tokens work? e.g., probe FOO = process("/$LIB/libglib-2.0.so.0.3000.3").mark("quark__new") (not advocating it over the other possiblities, just curious)
Depends on upstream fix: https://bugzilla.gnome.org/show_bug.cgi?id=685012 We could probably backport this for Fedora 18 though.
(In reply to comment #38) > 1) Python .py{c,o} files embed architecture-specific data, but we're > installing them in %{datadir} They're likely to only differ due to the timestamp embedded in the header, which is the mtime of the corresponding .py file. If this is coming from the tarball, these ought to be the same on every arch you build for. If you're touching the .py file during the build, you can fix the timestamp back by running: touch -r PATH_TO_SOME_SOURCE_FILE PATH_TO.py so that they have the timestamp from the tarball.
(In reply to comment #49) > (In reply to comment #38) > > 1) Python .py{c,o} files embed architecture-specific data, but we're > > installing them in %{datadir} > They're likely to only differ due to the timestamp embedded in the header, > which is the mtime of the corresponding .py file. Hm, doesn't at least in some cases the generated bytecode differ depending on sizeof(long)?
(In reply to comment #49) > If > you're touching the .py file during the build, you can fix the timestamp > back by running: > > touch -r PATH_TO_SOME_SOURCE_FILE PATH_TO.py > > so that they have the timestamp from the tarball. Ok, so it turns out that using make install DESTDIR=${RPM_BUILD_ROOT} INSTALL="install -p -c" fixes the .py{c,o} timestamps for everything except config.py, which is generated at build time. I could hack this by resetting the timestamp to some known quantity (config.py.in time, 0, 42, ...), but it would seem cleaner to me to either: 1) Disable the timestamp in .py{c,o} files - e.g. somehow force Python to use 0 2) Not ship the .py{c,o} files
Pile of hacks, but: http://koji.fedoraproject.org/koji/taskinfo?taskID=4549425
(In reply to comment #52) > Pile of hacks, but: > http://koji.fedoraproject.org/koji/taskinfo?taskID=4549425 Works for me on F-18, thanks! And sorry for dropping this before I went on vacation (I mostly stumbled over the systemtap stuff and kind of gave up). (In reply to comment #51) > 2) Not ship the .py{c,o} files It's desirable to have these packaged as otherwise python might want to (re)create them during runtime and if successful they wouldn't be cleaned up when the package is uninstalled. Or (maybe even more likely) trigger SELinux alerts if the policy disallows this (which should be true in most cases).
This works as of: glib2-devel-2.37.1-1.fc20.x86_64 Can anyone confirm for F19 so this can be closed?
Works for me on F-18 and F-19: glib2-devel-2.34.2-2.fc18 glib2-devel-2.36.3-1.fc19
Works for me also, and I am the original reporter.
And works for me on F19 (beta).
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Created attachment 1103971 [details] conflicting systemtap tapset fix The global variables in {32,64}-{gobject,glib}.stp are conflicting. See also, https://sourceware.org/bugzilla/show_bug.cgi?id=17587. Systemtap 3.0 has introduced a "private" keyword to allow limiting scope of globals.