Bug#217605: dselect: cannot configure xdm, it works with other pkgs though. it says: basename: toomany arguments
Package: dselect Version: 1.10.10 Severity: normal -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux paperino 2.6.0-test8 #1 Thu Oct 23 22:13:51 CEST 2003 i586 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages dselect depends on: ii libc6 2.3.2-7GNU C Library: Shared libraries an ii libgcc1 1:3.3.2-0pre5 GCC support library ii libncurses5 5.3.20030719-1 Shared libraries for terminal hand ii libstdc++51:3.3.2-0pre5 The GNU Standard C++ Library v3 -- debconf information Configuro xdm (4.2.1-12.1) ... basename: troppi argomenti Usare `basename --help' per ulteriori informazioni. dpkg: errore processando xdm (--configure): il sottoprocesso post-installation script ha restituito un codice di errore 1 Sono occorsi degli errori processando: xdm E: Sub-process /usr/bin/dpkg returned an error code (1) _ Il servizio Postemail sottopone tutti i documenti a una scansione automatica antivirus con i programmi TREND MICRO.
Bug#217622: dpkg: ldconfig runs everytime a library has to be configured
Package: dpkg Version: 1.10.15 Severity: wishlist Tags: sid Why don't add to dpkg a way to schedule command executions, evoiding to run a command everytime a package is configured. ldconfig runs everytime a library is configured, I have a slow laptop and I think it could be useful to schedule ldconfig instead of run it and run it just once before dpkgs exits. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux goljadkin 2.6.0-test3 #3 Wed Oct 8 12:47:58 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages dpkg depends on: ii dselect 1.10.15a user tool to manage Debian packa ii libc6 2.3.2-8GNU C Library: Shared libraries an -- no debconf information
Bug#213524: automake: serious breakage with new install-info behaviour
Adam Heath wrote: I'm not fixing this bug. automake should not be doing what it is doing, as it was bound to fail. automake was depending on questionable, and wrong behaviour, and it's not surprising it died as it has. Yes, we all agree on that, but the issue here is not to blame dpkg or automake but instead saving the sarge release from a very great breakage. We all agree that this is an automake bug and not a dpkg bug, but if we release sarge in this way, there will be a lot of packages that, when built from source, will not yield the same binary that we distribute in the archive. This is some sort of FTBFS, since source and binary do not match. What we are asking you is that you keep the old behaviour of install-info (even if we all agree it's the wrong behaviour) *only* for the sarge release, to prevent a lot of breakage in a lot of other packages (which are buggy anyway, I'm not proposing that we do not fix them as well). The day sarge is released, install-info could be modified again in testing and unstable to do what it should do (the current behaviour in unstable). This is not very different from enabling dpkg --force-overwrite by default in stable and disabling it in unstable, or what coreutils maintainer has done with the POSIX stuff by allowing chown user.group in sarge for now. If we want to release a sarge with the current install-info that it's not completely broken as far as binaries which match sources is concerned, we should verify that none of the current source packages in the archive yields a package containing /usr/share/info/dir when compiled using current tools. Can you imagine what a huge task is this, or even whether or not we will be able to do that?
Bug#213524: marked as done (dpkg: new install-info creates serious breakage, see #213524)
reopen 213524 thanks Adam Heath [EMAIL PROTECTED] wrote: From: Santiago Vila [EMAIL PROTECTED] [...] In the most recent dpkg package, install-info --version now shows its output on stdout, not stderr. As a result, this code in /usr/share/automake-1.7/am/texinfos.am does not work as expected anymore: [...] @if (install-info --version \ install-info --version | grep -i -v debian) /dev/null 21; then list='$(INFO_DEPS)'; \ [...] I'm not fixing this bug. automake should not be doing what it is doing, as it was bound to fail. automake was depending on questionable, and wrong behaviour, and it's not surprising it died as it has. Hello, Nobody is arguing that the test is not broken and automake1.7 has already been fixed [1], however this does not help at all. There are tons of packages in the archive with the broken test from automake included that do not invoke automake at build-time, *all* of these suddenly have a (hidden) rc-bug, only appearing when building on a system with dpkg = 1.10.11. When we are thinking about a release introducing a big number of rc-bugs to fix a cosmetical issue in dpkg is not acceptable. cu andreas PS: Pleae do'nt cc me on replies, I am subscribed to both -devel and -bugs-rc. [1] 1.6 hasn't, I have submitted a bug report -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Processed: Re: Bug#213524: marked as done (dpkg: new install-info creates serious breakage, see #213524)
Processing commands for [EMAIL PROTECTED]: reopen 213524 Bug#213524: dpkg: new install-info creates serious breakage, see #213524 Bug reopened, originator not changed. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Another attempt at the build-arch problem (fwd)
What do you guys think of this idea? I think it's one of the smartest I've heard for a while, and leaves open the possibility of further extensions. Another possibility is to have something like debian/rules.features, which would have a list of features supported by the debian/rules file. For example, current possible features, based on musings on the -policy list, could include build-arch and test. For example, if debian/rules.features had one keyword per line, then dpkg-buildpackage et al could do something like: if [ -r debian/rules.features ] grep -q build-arch debian/rules.features then ... else ... fi This would potentially be more flexible than debian/rules.version, but also potentially more confusing. - Forwarded message from Bill Allombert [EMAIL PROTECTED] - Date: Thu, 23 Oct 2003 00:58:19 +0200 From: Bill Allombert [EMAIL PROTECTED] Subject: Re: Bug#216492: FTBFS (unstable/all) missing build-dep To: debian-policy@lists.debian.org [...] So I come up with a different proposal: Introducing a new file, say debian/rules.version. If this file does not exist, we declare that version=0, else version=`cat debian/rules.version`. Currently 2 versions are defined: 0: debian/rules support rules described as mandatory by policy. 1: as 0, but debian/rules also support build-arch and build-indep. Future version of policy can define higher version. dpkg-buildpackage just need to read this file before deciding whether it can call debian/rules build-arch. What do you think ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. - End forwarded message - Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Another attempt at the build-arch problem (fwd)
Hi. Frankly, I believe the whole build-arch idea is flawed. The introduction of a new package format five years ago was a huge improvement over the previous format. The proposals I've seen to improve the current source format add a lot of complexities for very little gain.
Bug#151662: #151662: dselect: changes selections without notice
On Wed, Oct 15, 2003 at 06:50:28PM +0100, Colin Watson wrote: On Sat, Oct 04, 2003 at 12:16:18AM +0100, Colin Watson wrote: I think the following patch is the right fix. I'm cc'ing Joey on this because I'd like him to confirm that it makes sense with the original intent of his change. Joey said that he didn't recall the details of the code, but that the analysis seemed complete and to go ahead. I see there was a dpkg upload today, but it didn't fix this. Please, is there any chance that this patch could be applied before sarge? dselect makes bad mistakes due to this bug, and it will result in much confusion if it makes it into a stable release. I've been using a locally-built version of dselect with this patch applied for the last three weeks, and have had no problems whatsoever. Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#217415: #217415: dpkg: failed to lock dir for editing! Operation not permitted
* Adam Heath [EMAIL PROTECTED] [2003-10-25 12:50]: To: [EMAIL PROTECTED] tag 217415 moreinfo severity 217415 important thanks Can you repeat this? I need more info. I do try to install Debian on my new powerbookG4 but I can't. The only thing I could do was to boot with a Gentoo Live! cd and copy a hierarchy made with debootstrap. Also, debootstrap did not put a kernel, and the system is not completly usable, so I did try to do as I can: rewrite the /var/lib/dpkg/status file, reinstall libc6, and so on with the important libraries. After that, I did try to install the rest of the system but now I am not able to install no package that use install-info. because of the error I reported. So if you think the error is because my system is in a bad shape, feel free to close the bug. I do not have the problem on other box (I have several ix86 and a G3). Also, the report bug says i386, but the bug is for a G4... in a bad shape. I hope you have enough informations to close the bug and/or help me finishing the installation! ;) Best regards, -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. pgpBKueh6Z6nf.pgp Description: PGP signature
Processed: your mail
Processing commands for [EMAIL PROTECTED]: tags 151662 + pending Bug#151662: dselect: changes selections without notice Tags were: patch Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#217605: dselect: cannot configure xdm, it works with other pkgs though. it says: basename: toomany arguments
reassign 217605 xdm thanks On Sun, 26 Oct 2003, Aldo Maggi wrote: Configuro xdm (4.2.1-12.1) ... basename: troppi argomenti Usare `basename --help' per ulteriori informazioni. dpkg: errore processando xdm (--configure): il sottoprocesso post-installation script ha restituito un codice di errore 1 Sono occorsi degli errori processando: xdm E: Sub-process /usr/bin/dpkg returned an error code (1) The bug is in xdm, not dselect, not dpkg, not apt.
Bug#213524: automake: serious breakage with new install-info behaviour
On Sun, 26 Oct 2003, Santiago Vila wrote: Adam Heath wrote: I'm not fixing this bug. automake should not be doing what it is doing, as it was bound to fail. automake was depending on questionable, and wrong behaviour, and it's not surprising it died as it has. Yes, we all agree on that, but the issue here is not to blame dpkg or automake but instead saving the sarge release from a very great breakage. We all agree that this is an automake bug and not a dpkg bug, but if we release sarge in this way, there will be a lot of packages that, when built from source, will not yield the same binary that we distribute in the archive. This is some sort of FTBFS, since source and binary do not match. Better to fix the bugs now, before release, then have them hang around after. For instance, if we delay this 'fix' until after sarge is release, we will *still* have the problem then. There will be backed in sarge that *will not build* when sarge+1 is released. What we are asking you is that you keep the old behaviour of install-info (even if we all agree it's the wrong behaviour) *only* for the sarge release, to prevent a lot of breakage in a lot of other packages (which are buggy anyway, I'm not proposing that we do not fix them as well). The day sarge is released, install-info could be modified again in testing and unstable to do what it should do (the current behaviour in unstable). This is not very different from enabling dpkg --force-overwrite by default in stable and disabling it in unstable, or what coreutils maintainer has done with the POSIX stuff by allowing chown user.group in sarge for now. And I'm not going to enable that either. As for coreutils, that's different. Admin scripts make use of the user.group syntax. I highly doubt any make use of where --version goes. As for fixing automake, just make a new upload of the various automakes, that no longer have the issue, and place all them into sarge. Users can then just rerun automake on their sources. If we want to release a sarge with the current install-info that it's not completely broken as far as binaries which match sources is concerned, we should verify that none of the current source packages in the archive yields a package containing /usr/share/info/dir when compiled using current tools. Can you imagine what a huge task is this, or even whether or not we will be able to do that? Bugs should be fixed, not masked over or hidden. I have *never* liked that --force-overwrite is enabled. Ever. It showcased a problem with our tools. I mean, we *absolutely* know what was in the previous stable. All versions of it. We can be *absolutely* certain what files are there. Why can't we write file overlap detection?
Bug#151662: #151662: dselect: changes selections without notice
On Sun, 26 Oct 2003, Colin Watson wrote: I see there was a dpkg upload today, but it didn't fix this. Please, is there any chance that this patch could be applied before sarge? dselect makes bad mistakes due to this bug, and it will result in much confusion if it makes it into a stable release. Because it's hard to see things in the bug list. :| Volunteers willing to do bug triage will be gladly accepted.
Processed: Re: Bug#217605: dselect: cannot configure xdm, it works with other pkgs though. it says: basename: toomany arguments
Processing commands for [EMAIL PROTECTED]: reassign 217605 xdm Bug#217605: dselect: cannot configure xdm, it works with other pkgs though. it says: basename: toomany arguments Bug reassigned from package `dselect' to `xdm'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#213524: automake: serious breakage with new install-info behaviour
* Adam Heath ([EMAIL PROTECTED]) [031026 19:55]: For instance, if we delay this 'fix' until after sarge is release, we will *still* have the problem then. There will be backed in sarge that *will not build* when sarge+1 is released. No. If you change this as soon as sarge is out, it's very likly that all failures of other packages are detected during the release-cycle. (And the reason for this is that it's likly that most packages are recompiled on sid between two releases. So, these bugs will be detected then, and not short before a release.) However, changes now do introduce hidden failures on packages just very short before release, and that could make it very hard to produce fixes e.g. for security problems. And it's very likly that these problems won't be fixed before sarge is out, because nobody is just now compiling all packages to check that all packages are compilable on sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#212796: still broken
reopen 212796 thanks Now dpkg-checkbuilddeps requires arch dependent build-deps on all archs, not just the specified arch: Build-Depends: debhelper ( 4), cdbs (= 0.4.5.3), autotools-dev, libttf-dev (=1.4pre.20030402-1), libglib1.2-dev, libgtk1.2-dev, liborbit-dev, libncurses5-dev, xlibs-dev, libesd0-dev, libartsc0-dev, libasound2-dev [alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc], nasm [i386], libmusicbrainz2-dev (= 2.0.1), libgdk-pixbuf-dev, libid3-3.8.3-dev, libvorbis-dev (= 1.0.0), libgdbm-dev, zlib1g-dev on mipsel, results in: dpkg-checkbuilddeps: Unmet build dependencies: nasm -- Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED]) The opinions expressed here are my own.
Processed: still broken
Processing commands for [EMAIL PROTECTED]: reopen 212796 Bug#212796: dpkg-checkbuilddeps fails with arch-restricted build-deps Bug reopened, originator not changed. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: Re: Bug#213524: marked as done (dpkg: new install-info creates serious breakage, see #213524)
Processing commands for [EMAIL PROTECTED]: close 213524 Bug#213524: dpkg: new install-info creates serious breakage, see #213524 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Santiago Vila [EMAIL PROTECTED] thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
