Re: Bug#571776: document symbols
Hi, On Sun, 12 Aug 2012, Russ Allbery wrote: I'm looking for seconds so that we can finally merge this monster. Presented as a diff since that was the request last time, but the branch has also been pushed to the Policy Git repository, so if you want to review it various other ways, you can start at: Seconded. Thank you very much for this work! Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ signature.asc Description: Digital signature
Processed: tagging 684702, found 682574 in live-tools/3.0.3-1, notfound 682574 in live-utils/3.0.3-1 ...
Processing commands for cont...@bugs.debian.org:
tags 684702 + pending
Bug #684702 [fglrx-legacy-driver] fglrx-legacy-driver dispalay a AMD Testing
use only watermark on the bottom right corner
Added tag(s) pending.
found 682574 live-tools/3.0.3-1
Bug #682574 {Done: Daniel Baumann dan...@debian.org} [live-tools,procps]
live-tools, procps: live-tools and procps must consistently handle
/usr/bin/uptime
Marked as found in versions live-tools/3.0.3-1.
notfound 682574 live-utils/3.0.3-1
Bug #682574 {Done: Daniel Baumann dan...@debian.org} [live-tools,procps]
live-tools, procps: live-tools and procps must consistently handle
/usr/bin/uptime
The source live-utils and version 3.0.3-1 do not appear to match any binary
packages
No longer marked as found in versions live-utils/3.0.3-1.
affects 671711 + mono-tools monodoc-clutter-manual octave-vrml liblapack3
libblas3 octave src:octave src:monodoc-browser
Bug #671711 [dpkg] monodoc-browser: fails to upgrade from 'testing'
Bug #678848 [dpkg] liblapack3: octave has upgrade problems: liblapack.so.3gf:
cannot open shared object file: No such file or directory
Added indication that 671711 affects src:octave
Added indication that 678848 affects src:octave
thanks
Stopping processing here.
Please contact me if you need assistance.
--
671711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671711
678848: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678848
682574: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682574
684702: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684702
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606825: mingw-w64 triplets/ostable
Hi, Guillem Jover wrote: The main issue I have with this request is that the upstream triplet just seems wrong, as it encodes part of the ABI in the vendor field. That's AFAIR, from reading the thread back then. For dpkg tools the vendor is irrelevant, and having to take it into account would imply changing the underlaying infrastructure which might not be a problem per se, if the reason for requiring this wan't wrong. I'm inclined to agree that something like i386-windows-mingw_w64 or i386-mingw32-w64, to more closely parallel i386-linux-gnu, would be nicer. For reference for forgetful people like me: the tuple used in the wild is i686-w64-mingw32. That could mean a multiarch triplet of i386-w64-mingw32. (Anything except the Debian arch name and multiarch triplet can be easily changed later without rebuilding many packages and is thus not something to worry about much yet.) gcc/doc/install.texi advertises: GCC contains support for x86-64 using the mingw-w64 runtime library, available from http://mingw-w64.sourceforge.net/. This library should be used with the target triple x86_64-pc-mingw32. That's out of date. If I understand correctly, the mingw-w64 runtime supports two different target triplets, the difference being based on the vendor tag: with vendor=pc, it stays compatible with the mingw.org runtime, while with vendor=w64, it enables some extensions. NightStrike wrote[2]: | On Wed, Dec 15, 2010 at 11:08 AM, Dmitrijs Ledkovs | dmitrij.led...@ubuntu.com wrote: | *nod* So is the best technical solution right now to create | cpu-vendor-windows GNU tripplet and slowly start patching | config.sub, config.guess and all of upstream projects? | | That's very debatable. I personally think it is, if you ignore 1) the | politics of the matter, and 2) the ginormous amount of work required | to update everything (though the transitional approach I mentioned | eases that somewhat.) [...] | In fact, that's the very reason we started using the vendor | tag for mingw-w64.sf.net-specific stuff. We got tired of debating | with people as to what the $os part of the triplet should be. If mingw-w64 only adds extensions on top of the mingw.org runtime and an app built against a mingw.org-built DLL will still run fine against a mingw-w64-built DLL, then we could avoid all these questions and use a single Debian arch for both. (That would be analagous to the case of i386 and i686 being the same Debian arch.) If I have understood the previous discussion correctly, that is not the case, and the mingw-w64 and mingw.org ABIs are significantly different. Do we have an example? E.g., what happens if, targetting 32-bit Windows: - I build my program against mingw-w64-built zlib, then try to run it against mingw.org-built zlib - I build my program against a mingw-w64-built library that uses more sophisticated features, like exceptions and threads, then try to run it against the mingw.org-built version of the same library - etc If the ABIs really are significantly different, then it would presumably be possible to move to a triplet like i686-pc-mingw32-w64 or i686-w64-mingw32-w64 upstream. If the ABIs are compatible, then dpkg can treat the existing tuples with -pc- and -w64- identically and rely on package dependencies to pull in the appropriate packages at build time or run time when it matters. And if we just don't know, we can leave it alone with an understanding that we might need to rebuild everything to use a different multiarch tuple later. Any of those three options seems fine to me. Thanks, Jonathan [1] http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/1286 [2] http://bugs.debian.org/606825#100 -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678848: libarpack2: please add Breaks: octave3.2
clone 678848 -1 reassign -1 libarpack2 3.1.1-2 retitle -1 libarpack2: please add Breaks: octave3.2 thanks After digging a bit more into this octave upgrade problem, I found a workaround: libarpack2 needs to add Breaks: octave3.2 There is already a similar conflict in libblas3 (#677399). Having the Breaks reorders the upgrade order so that octave3.2 is removed in a few more cases (tested so far with octave-benchmark, octave-vrml) before the libblas/liblapack links get broken and octave3.2 cannot be triggered successfully any longer. At the time when the trigger failed, octave3.2 was linked against both libblas.so.3gf (directly) and against libblas.so.3 (via libarpack.so.2), so libarpack2 seems to be the next promising candidate to add such a conflict. There should probably be a better way to properly describe this conflict, but due to dpkg bug #678848 dpkg may do trigger-processing of a package that has its dependencies currently not satisfied. Anyway, the workaround I suggested here should circumvent these problems. Andreas -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed (with 3 errors): libarpack2: please add Breaks: octave3.2
Processing commands for cont...@bugs.debian.org:
clone 678848 -1
Bug #678848 [dpkg] liblapack3: octave has upgrade problems: liblapack.so.3gf:
cannot open shared object file: No such file or directory
Bug #671711 [dpkg] monodoc-browser: fails to upgrade from 'testing'
Failed to clone 678848: Bug is marked as being merged with others. Use an
existing clone.
reassign -1 libarpack2 3.1.1-2
Failed to clear fixed versions and reopen on -1: The 'bug' parameter (-1) to
Debbugs::Control::set_package did not pass regex check
Debbugs::Control::set_package('transcript', 'GLOB(0x24253e8)',
'requester', 'Andreas Beckmann deb...@abeckmann.de', 'request_addr',
'cont...@bugs.debian.org', 'request_msgid', '50293ef3.4090...@abeckmann.de',
'request_subject', ...) called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 254
eval {...} called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 253
Debbugs::Control::Service::control_line('line', 'reassign -1 libarpack2
3.1.1-2', 'clonebugs', 'HASH(0x23829e8)', 'limit', 'HASH(0x2382430)',
'common_control_options', 'ARRAY(0x2382478)', 'errors', ...) called at
/usr/lib/debbugs/service line 471
retitle -1 libarpack2: please add Breaks: octave3.2
Failed to set the title of -1: The 'bug' parameter (-1) to
Debbugs::Control::set_title did not pass regex check
Debbugs::Control::set_title('transcript', 'GLOB(0x24253e8)',
'requester', 'Andreas Beckmann deb...@abeckmann.de', 'request_addr',
'cont...@bugs.debian.org', 'request_msgid', '50293ef3.4090...@abeckmann.de',
'request_subject', ...) called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 513
eval {...} called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 512
Debbugs::Control::Service::control_line('line', 'retitle -1 libarpack2:
please add Breaks: octave3.2', 'clonebugs', 'HASH(0x23829e8)', 'limit',
'HASH(0x2382430)', 'common_control_options', 'ARRAY(0x2382478)', 'errors', ...)
called at /usr/lib/debbugs/service line 471
thanks
Stopping processing here.
Please contact me if you need assistance.
--
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678848: libarpack2: please add Breaks: octave3.2
unmerge 678848 clone 678848 -1 retitle 671711 dpkg: runs trigger processing even if depedencies are not satisfied merge 671711 678848 reassign -1 libarpack2 3.1.1-2 retitle -1 libarpack2: please add Breaks: octave3.2 thanks -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed (with 1 errors): Re: libarpack2: please add Breaks: octave3.2
Processing commands for cont...@bugs.debian.org:
unmerge 678848
Bug #678848 [dpkg] liblapack3: octave has upgrade problems: liblapack.so.3gf:
cannot open shared object file: No such file or directory
Bug #671711 [dpkg] monodoc-browser: fails to upgrade from 'testing'
Disconnected #678848 from all other report(s).
clone 678848 -1
Bug #678848 [dpkg] liblapack3: octave has upgrade problems: liblapack.so.3gf:
cannot open shared object file: No such file or directory
Bug 678848 cloned as bug 684773
retitle 671711 dpkg: runs trigger processing even if depedencies are not
satisfied
Bug #671711 [dpkg] monodoc-browser: fails to upgrade from 'testing'
Changed Bug title to 'dpkg: runs trigger processing even if depedencies are not
satisfied' from 'monodoc-browser: fails to upgrade from 'testing''
merge 671711 678848
Bug #671711 [dpkg] dpkg: runs trigger processing even if depedencies are not
satisfied
Unable to merge bugs because:
affects of #678848 is
'monodoc-clutter-manual,octave,octave-vrml,mono-tools,src:monodoc-browser,src:octave,liblapack3,libblas3'
not
'monodoc-clutter-manual,octave,octave-vrml,mono-tools,src:monodoc-browser,liblapack3,src:octave,libblas3'
Failed to merge 671711: Did not alter merged bugs
Debbugs::Control::set_merged('transcript', 'GLOB(0x190c1e0)',
'requester', 'Andreas Beckmann deb...@abeckmann.de', 'request_addr',
'cont...@bugs.debian.org', 'request_msgid', '50294460.7040...@abeckmann.de',
'request_subject', ...) called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 537
eval {...} called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 536
Debbugs::Control::Service::control_line('line', 'merge 671711 678848',
'clonebugs', 'HASH(0x18839e8)', 'limit', 'HASH(0x1883430)',
'common_control_options', 'ARRAY(0x1883478)', 'errors', ...) called at
/usr/lib/debbugs/service line 471
reassign -1 libarpack2 3.1.1-2
Bug #684773 [dpkg] liblapack3: octave has upgrade problems: liblapack.so.3gf:
cannot open shared object file: No such file or directory
Bug reassigned from package 'dpkg' to 'libarpack2'.
No longer marked as found in versions dpkg/1.14.17.
Ignoring request to alter fixed versions of bug #684773 to the same values
previously set
Bug #684773 [libarpack2] liblapack3: octave has upgrade problems:
liblapack.so.3gf: cannot open shared object file: No such file or directory
Marked as found in versions arpack/3.1.1-2.
retitle -1 libarpack2: please add Breaks: octave3.2
Bug #684773 [libarpack2] liblapack3: octave has upgrade problems:
liblapack.so.3gf: cannot open shared object file: No such file or directory
Changed Bug title to 'libarpack2: please add Breaks: octave3.2' from
'liblapack3: octave has upgrade problems: liblapack.so.3gf: cannot open shared
object file: No such file or directory'
thanks
Stopping processing here.
Please contact me if you need assistance.
--
671711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671711
678848: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678848
684773: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684773
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: forcibly merging 671711 678848
Processing commands for cont...@bugs.debian.org: forcemerge 671711 678848 Bug #671711 [dpkg] dpkg: runs trigger processing even if depedencies are not satisfied Bug #678848 [dpkg] liblapack3: octave has upgrade problems: liblapack.so.3gf: cannot open shared object file: No such file or directory Removed indication that 678848 affects octave-vrml, mono-tools, monodoc-clutter-manual, octave, src:monodoc-browser, src:octave, liblapack3, and libblas3 Added indication that 678848 affects monodoc-clutter-manual,octave,octave-vrml,mono-tools,src:monodoc-browser,liblapack3,src:octave,libblas3 Merged 671711 678848 thanks Stopping processing here. Please contact me if you need assistance. -- 671711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671711 678848: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678848 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684776: dpkg incorrectly complains about conffile contents being different for MA packages
Package: dpkg Version: 1.16.4.3 Severity: normal Dear Maintainer, when an MA: same package contains a conffile, re-installing it causes dpkg to error out, complaining that the content of the conffile differs between the architectures - even though it does not. To reproduce (on current testing): I assume an amd64 system with i386 as foreign architecture. libpam- modules:amd64 is installed, libpam-modules:i386 is not. $ sudo dpkg --install libpam-modules_1.1.3-7.1_i386.deb (working all right - the dependencies must already be installed) $ sudo dpkg --install libpam-modules_1.1.3-7.1_amd64.deb libpam- modules_1.1.3-7.1_i386.deb (Reading database ... 227374 files and directories currently installed.) Preparing to replace libpam-modules:amd64 1.1.3-7.1 (using libpam- modules_1.1.3-7.1_amd64.deb) ... Unpacking replacement libpam-modules:amd64 ... Preparing to replace libpam-modules:i386 1.1.3-7.1 (using libpam- modules_1.1.3-7.1_i386.deb) ... Unpacking replacement libpam-modules:i386 ... dpkg: error processing libpam-modules_1.1.3-7.1_i386.deb (--install): trying to overwrite shared '/etc/security/limits.conf', which is different from other instances of package libpam-modules:i386 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Setting up libpam-modules:amd64 (1.1.3-7.1) ... Processing triggers for man-db ... Errors were encountered while processing: libpam-modules_1.1.3-7.1_i386.deb Interesting enough, if I reinstall just one of the two packages, things work fine. Only if I tell dpkg to reinstall both architectures at the same time, above error shows up. This is not specific to libpam-modules (for which I reported this as bug [1]), it also happens in my local multiarched version of libxvmc [2], which has a conffile as well. Kind regards, Ralf [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684703 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-3 ii libc62.13-33 ii liblzma5 5.1.1alpha+20120614-1 ii libselinux1 2.1.9-5 ii tar 1.26-4 ii zlib1g 1:1.2.7.dfsg-13 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.9.7.2 -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684776: dpkg incorrectly complains about conffile contents being different for MA packages
Hi! On Mon, 2012-08-13 at 20:45:08 +0200, Ralf Jung wrote: Package: dpkg Version: 1.16.4.3 Severity: normal when an MA: same package contains a conffile, re-installing it causes dpkg to error out, complaining that the content of the conffile differs between the architectures - even though it does not. To reproduce (on current testing): I assume an amd64 system with i386 as foreign architecture. libpam- modules:amd64 is installed, libpam-modules:i386 is not. $ sudo dpkg --install libpam-modules_1.1.3-7.1_i386.deb (working all right - the dependencies must already be installed) $ sudo dpkg --install libpam-modules_1.1.3-7.1_amd64.deb libpam- modules_1.1.3-7.1_i386.deb (Reading database ... 227374 files and directories currently installed.) Preparing to replace libpam-modules:amd64 1.1.3-7.1 (using libpam- modules_1.1.3-7.1_amd64.deb) ... Unpacking replacement libpam-modules:amd64 ... Preparing to replace libpam-modules:i386 1.1.3-7.1 (using libpam- modules_1.1.3-7.1_i386.deb) ... Unpacking replacement libpam-modules:i386 ... dpkg: error processing libpam-modules_1.1.3-7.1_i386.deb (--install): trying to overwrite shared '/etc/security/limits.conf', which is different from other instances of package libpam-modules:i386 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Setting up libpam-modules:amd64 (1.1.3-7.1) ... Processing triggers for man-db ... Errors were encountered while processing: libpam-modules_1.1.3-7.1_i386.deb Interesting enough, if I reinstall just one of the two packages, things work fine. Only if I tell dpkg to reinstall both architectures at the same time, above error shows up. This is not specific to libpam-modules (for which I reported this as bug [1]), it also happens in my local multiarched version of libxvmc [2], which has a conffile as well. Yeah, reproduced here, and looking into it right now. I have a hunch I've already fixed this in my 1.17.x branch, though. thanks, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684776: dpkg incorrectly complains about conffile contents being different for MA packages
Control: found -1 dpkg/1.16.2 Control: severity -1 serious On Mon, 2012-08-13 at 22:50:28 +0200, Guillem Jover wrote: On Mon, 2012-08-13 at 20:45:08 +0200, Ralf Jung wrote: Package: dpkg Version: 1.16.4.3 Severity: normal when an MA: same package contains a conffile, re-installing it causes dpkg to error out, complaining that the content of the conffile differs between the architectures - even though it does not. [...test case...] Interesting enough, if I reinstall just one of the two packages, things work fine. Only if I tell dpkg to reinstall both architectures at the same time, above error shows up. This is not specific to libpam-modules (for which I reported this as bug [1]), it also happens in my local multiarched version of libxvmc [2], which has a conffile as well. Yeah, reproduced here, and looking into it right now. I have a hunch I've already fixed this in my 1.17.x branch, though. Ok, I fixed this locally and been running some tests, will do some more tests and ponder a bit about the implications of the fix before pushing to master. thanks, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#684776: dpkg incorrectly complains about conffile contents being different for MA packages
Processing control commands: found -1 dpkg/1.16.2 Bug #684776 [dpkg] dpkg incorrectly complains about conffile contents being different for MA packages Marked as found in versions dpkg/1.16.2. severity -1 serious Bug #684776 [dpkg] dpkg incorrectly complains about conffile contents being different for MA packages Severity set to 'serious' from 'normal' -- 684776: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684776 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
