Bug#621036: udev fails to load modules at startup: cannot create /run/udev//root-link-rule: Read-only file system
On Wed, 6 Apr 2011, Marco d'Itri wrote: reassign 621036 base-files retitle 621036 base-files creates an unuseable /run, breaking udev and the whole system affects 621036 udev block 620995 with 621036 620191 thanks On Apr 06, Gianluigi Tiesi sher...@netfarm.it wrote: Indeed this happens because your system has /run/ but it is not writeable. udev does not depend on /run being available, but if it exists then it must be useable. I do not believe this to be unreasonable. I think this bug clearly shows that it is unreasonable indeed, because currently /run exists but the package in charge of making it useable has not been modified yet. I just was told to create /run as a placeholder but certainly base-files will not be in charge of making it work. For this reason I fail to see how this breakage is supposed to be fixed in base-files (according to your reassign). Do you mean that base-files should also make /run to work? That *is* unreasonable, a lot more than udev using /run without it being ready, IMHO. So: Would it be too much difficult for udev not to use /run until it is ready? I think that would be the best solution for this, so I would ask you to reconsider this reassign that you made. (Otherwise I will simply remove /run and leave it to initscripts. I think that would be a pity, because it would be a sign of how inflexible our software is). Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621036: fixing it
On Wed, 6 Apr 2011, Marco d'Itri wrote: On Apr 06, Norbert Preining prein...@logic.at wrote: Does the maintainer of soemthing like *base-files* at least *once* reboot into his own machine before he uploads? It seems not so, that is a bug that does effect everyone as far as I see. In his defense, the bug only causes problems after udev is upgraded. In my defense, I still believe that creating a broken /run is stupid. The directory /run is already created. If there are changes in udev to make, undoing the change in base-files would be quite stupid at this point. So, the issue now is: Can I expect an udev release fixing this in a day or two? I would be willing to revert the change (temporarily) if the answer is no, but as a courtesy to users of unstable, not because I really believe the bug is in base-files. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621036:
reassign 621036 udev retitle 621036 udev should not assume that /run works just because it exists thanks I have just dropped /run in base-files 6.3. But this is still a bug in udev. I still believe it makes no sense to treat /run as if it was functional just because it exists. I will be more than happy to reintroduce /run once all the other packages are ready for it, but this seems not to be the case right now. Users of unstable: Please rm -rf /run and reboot. This base-files upload is not supposed to fix your system for you, it's just for the benefit of users who have not upgraded their systems yet. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: Processed: found 620157 in 6.3
El 07/04/11 01:14, Debian Bug Tracking System escribió:
Processing commands for cont...@bugs.debian.org:
found 620157 6.3
Bug #620157 {Done: Santiago Vilasanv...@debian.org} [base-files] base-files:
Please add top-level /run
Bug Marked as found in versions base-files/6.3 and reopened.
Hmm, what sense does it make to reopen a bug which I can't fix because
of pending work in other packages?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621462: base-files: missing AGPL-3 license
reassign 621462 debian-policy thanks On Thu, 7 Apr 2011, onlyjob wrote: Package: base-files Version: 6.0squeeze1 Severity: wishlist Tags: patch AGPL-3 missing from /usr/share/common-licenses The debian policy group decides about this, not me (please read base-files FAQ). Reassigning. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621716: hello: README-dev is missing
On Fri, 8 Apr 2011, Wang Xiaolin wrote: Package: hello Version: 2.7-1 Severity: normal The file named 'README-dev' mentioned in README is missing. You are right. There is not even a README-dev in the original tarball, so this is definitely an upstream bug. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621757: base-files: /etc/issue still reflects 6.0 after the 6.0.1 point release
El 08/04/11 16:31, Scott Anderson escribió: Package: base-files Version: 6.0squeeze1 Severity: minor After performing a dist-upgrade on my Debian 6.0 install, I noticed that /etc/issue still shows 6.0 where /etc/debian_version shows 6.0.1. I know it's minor, but I was confused. The release managers asked me not to touch /etc/issue, as that's a file which is often customized by the user. For now, only debian_version is supposed to change, as it happened during the 5.0.x release. Is this enough for you, or do you think I should document this somewhere? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files 6.3 removes /run
El 08/04/11 14:10, Anthony Campbell escribió: Package: base-files Version: 6.3 Followup-For: Bug #620157 I installed base-files 6.3 today and /run disappeared. Kernel 2.6.38 then failed to boot, stopping at the nouveau driver. 2.6.37 booted normally. Imade/run myself and kernel 2.6.38 booted again. We are not supposed to use /run yet. Anything which *requires* /run to exist right now is a bug. Please consider reporting that as a kernel bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608181: /usr/bin/xgettext: xgettext segmentation fault
On Tue, 28 Dec 2010, Jean-Luc Coulon (f5ibh) wrote: Package: gettext Version: 0.18.1.1-3 Severity: important File: /usr/bin/xgettext -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While trying to extract translatable strings (from WordPress), I get a Segmentation fault. I use the following command: xgettext --width=80 --from-code=utf-8 \ --keyword=__ --keyword=_e --keyword=esc_attr__ --keyword=esc_attr_e \ --keyword=esc_html__ --keyword=esc_html_e \ --keyword=_x:1,2c --keyword=esc_attr_x:1,2c --keyword=esc_html_x:1,2c \ --keyword=_n:1,2 --keyword=_nx:1,2,4c \ --keyword=_ex:1,2c \ --keyword=_n_noop:1,2 --keyword=_nx_noop:1,2,3c \ --default-domain=wp \ --language=php \ --files-from=fichiersphp.lst \ --exclude-file=cities.pot \ --exclude-file=ms.pot \ --output=wp.pot I should forward this upstream, but before doing so, we should find a minimal test case showing the error. As I don't have the contents of fichiersphp.lst, this is imposible for me. Could you please provide a minimal test case which is complete, so that I can forward this upstream? Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems
On Mon, 4 Jul 2011, Aurelien Jarno wrote: Package: base-files Version: 6.4 Severity: wishlist Up to know libc6 is providing a /lib64 - /lib symlink on amd64, kfreebsd-amd64, ppc64 and sparc64. With multiarch it's not possible for libc6 to provide such a symlink anymore as the package can be installed (using multiarch) on a 32-bit system. See bug#632176 for more details. It looks like the best place to place such a symbolic link is in base-files. Could you please provide it in base-files for the above architectures? For that you need to add a Replace: libc6 ( 2.13-10) (to be adjusted to the current libc6 version). When done, I'll remove the symlink from libc6 and add the necessary dependencies. Ok. Do you mean both /lib64 and /usr/lib64, or just /lib64? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632726: libsane-common should probably be Arch: all
Package: libsane-common Version: 1.0.22-4 This package contains just architecture independent data, so it would make sense to make it Architecture: all. Reading multiarch docs I see there is a paragraph about libfoo-data packages like this one: The Multi-Arch: foreign field must be set on such support packages regardless of whether they are Architecture: any, or Architecture: all, so I fail to see what would Architecture: any be necessary because of multiarch. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638430: closed by Santiago Vila sanv...@unex.es (Re: Bug#638430: missing AGPL in /usr/share/common-licenses/)
El 31/08/11 13:38, Steffen Möller escribió: I have not found the FAQ but google gave the answer that the AGPL is not found in packages frequently enough. Great to hear that it is requested frequently enough to make it in the frequently AQ. Sorry for not explaining everything before. I refer to this: Q. Why isn't license foo included in common-licenses? A. I delegate such decisions to the policy group. If you want to propose a new license you should make a policy proposal to modify the paragraph in policy saying Packages distributed under the UCB BSD license, Artistic license, GNU GPL and GNU LGPL should refer to the files in /usr/share/common-licenses. The way of doing this is explained in the debian-policy package. As usual, you should always take a look at already reported bugs against debian-policy before submitting a new one. which can be read in /usr/share/doc/base-files/FAQ. If you prefer, you can reopen and reassign this bug to debian-policy but it's already reported. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#287682: diff: -I options documentation for regexp is wrong
On Fri, 5 Aug 2011, jari wrote: In the year of 2011, the regexps people understand/expect to use are those of class of egrep as found in many of the programming languages. No. In the year 2011 there are *still* basic regular expressions and extended regular expressions. Time does not make basic regular expressions to disappear, and diff is not a programming language as such. If you ask the authors they will tell you that the info manual now reads like this: To ignore insertions and deletions of lines that match a `grep'-style regular expression, use the `--ignore-matching-lines=REGEXP' (`-I REGEXP') option. so I will consider this documented enough in diffutils 3.1. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#287682: diff: -I options documentation for regexp is wrong
| If you ask the authors they will tell you that the info manual now | reads like this: | | To ignore insertions and deletions of lines that match a `grep'-style | regular expression, use the `--ignore-matching-lines=REGEXP' (`-I | REGEXP') option. | | so I will consider this documented enough in diffutils 3.1. Please include this in the manual page; to manetion grep, as mentioned in original bug report. Sorry but no. You are looking for an excuse to not read the manual. In Debian Linux, the info pages are not considered the primary source of infomation. I don't know where did you got that idea, but for GNU packages I would consider it fundamentally flawed. This is what Debian policy says: 12.4. Preferred documentation formats - The unification of Debian documentation is being carried out via HTML. If your package comes with extensive documentation in a markup format that can be converted to various other formats you should if possible ship HTML versions in a binary package, in the directory `/usr/share/doc/appropriate-package' or its subdirectories.[1] If you don't like the info system to read documentation, that's ok, but in the end, for GNU packages, the info manual and the HTML manual have essentially the same content, as both are derived from the texinfo source. So yes, for GNU packages, the main manual, the one that you can use as a reference, is the one you can read (not exclusively) in info format. Once this is properly documented in the texinfo manual for diffutils 3.1, if you still don't want to read the manual, I'm very sorry, but it will be your problem, not mine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636706: Messages sent to -forwarded are not forwarded to maintainer
Package: bugs.debian.org Hello. I have just realized, by reading the web pages for Bug #608181, that there are a few emails between submitter and author which I missed completely, maybe because they were sent to the nn-forwar...@bugs.debian.org address and not to the proper nnn...@bugs.debian.org address. Would be possible to modify the server behaviour so that emails to -forwarded are also Cc:ed to the Debian maintainer? I would say that in cases like this it would be better to err on the side of sending duplicates than on the side of not sending some emails. Thanks a lot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608181: /usr/bin/xgettext: xgettext segmentation fault (fwd)
B1;2801;0cOn Sun, 31 Jul 2011, Jean-Luc Coulon (f5ibh) wrote: I is a consequence the way I've got an unstripped version of xgettext: 1st, I grabbed the debian source (apt-get source gettext) 2dn I applied your patch to the tree 3rd I build it (debuid) and installed it (debi) As the default behaviour is to build binaries unstripped, I moved the unstripped version from the tree to /usr/bin. Ok, some comments: *) Sorry, I forgot: Please reply to the 608...@bugs.debian.org address, so that I can receive all the emails automatically. [ Not a big problem because I can retrieve past messages from the web page ]. *) You don't need to move binaries around, you can also do this export DEB_BUILD_OPTIONS=noopt,nostrip dpkg-buildpackage and you get .deb pacakges with unstripped binaries and without optimization that you can install with dpkg -i. This is not just for gettext, every Debian package should support DEB_BUILD_OPTIONS according to policy. *) I can't reproduce the segfault anymore after applying the patch by Bruno (thanks a lot, Bruno!) which is why I have uploaded a new version and closed the bug. If you can still reproduce it, just report another bug as Bruno says. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636723: xgettext SIGSEGV
On Fri, 5 Aug 2011, Jean-Luc Coulon (f5ibh) wrote: I have reported #608181 which is now closed. On the same test case, I get also segmentation fault (SIGSEGV) with the patch applied. I have also tested with the latest version of the package in incoming. Attached the gdb backtrace and the test case. Go to ./wp/wp-content/languages and run ./extracticities.sh, then extractms.sh and then extractpo.sh!: this one triggers the problem. Well, I can't reproduce it. I tried on a system running testing and also on a qemu virtual machine running unstable. Do you have something unusual in your system? I see this in your log: /usr/local/bin/xgettext Can you reproduce it after removing such file from your system and actually using the gettext version I've just uploaded for unstable? (you say that you retrieved it from incoming). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643659: Missing Depends: base-passwd
reassign 643659 cdebootstrap thanks On Wed, 28 Sep 2011, Goswin von Brederlow wrote: Package: base-files Version: 6.0squeeze2 Severity: normal Hi, I'm not sure what changed but today when I tried to create a chroot cdebootstrap gave the following error: O: Setting up base-files (6.0squeeze2) ... P: Configuring package base-files O: chown: invalid user: `root:root' O: dpkg: error processing base-files (--configure): O: subprocess installed post-installation script returned error exit status 1 O: Setting up libc-bin (2.11.2-10) ... P: Configuring package libc-bin O: dpkg: dependency problems prevent configuration of bash: O: bash depends on base-files (= 2.1.12); however: O: Package base-files is not configured yet. O: dpkg: error processing bash (--configure): O: dependency problems - leaving unconfigured O: Setting up base-passwd (3.5.22) ... P: Configuring package base-passwd O: Errors were encountered while processing: O: base-files O: bash E: Internal error: install As far as I can tell the problem is that there is no /etc/passwd until base-passwd postinst runs and creates one. So until base-passwd is configured you can't use symbolic names in chown. Of course I can, because base-passwd is Essential: yes. base-files, like any other package, is right to assume that every essential package is ready to be used. It looks to me like base-files should have a Depends: base-passwd to ensure the corect ordering when configuring. But I have no idea why that shows up now all of a sudden. No. This is not a problem base-files should try to solve. This is exactly the type of problem that tools like cdebootstrap are supposed to solve, i.e. breaking all the implicit circular dependencies, hence the reassign. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643659: Missing Depends: base-passwd
El 28/09/11 17:13, Goswin von Brederlow escribió: I disagree. The configure order of packages is something the package should declare and that should not have to be duplicated in every bootstrap tool out there even if the order is only relevant for the initial install. There is no such thing as proper configure order when dealing with bootstrapping. Every package in the Essential: yes set may depend on any other package in the same set, so such set is expected to have a lot of circular dependencies. Making circular dependencies explicit does not make them less circular, so it would not be an improvement at all to make them explicit. We take for granted that a package which is Essential: yes will always work. If a package which is Essential: yes does not work when it has not been configured for the first time, then it follows that the meaning of Essential: yes should include the fact that it has been configured at least once in the past, as Colin Watson has pointed out. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641371: xgettext -k_ hello.scm fails if block-comment are used inside a function (fwd)
Hello. I received this report from the Debian BTS. Please keep the Cc: lines when replying (you can omit the -forwarded address). Thanks. -- Forwarded message -- From: David Pirotte da...@altosw.be To: Debian Bug Tracking System sub...@bugs.debian.org Date: Mon, 12 Sep 2011 20:52:32 -0300 Subject: Bug#641371: xgettext -k_ hello.scm fails if block-comment are used inside a function Package: gettext Version: 0.18.1.1-4 Severity: important Dear Maintainer, As I was trying to use xgettext on my own scheme files, it always failed. So I decided to try to run it on the example that comes with gettext-doc and it worked like a charm. Digging into what could cause this strange 'working on the distro scheme example file but not on any of my scheme files', I found that xgettext will properly work until it reaches a block-comment inside a scheme function [as opposed to a toplevel block-comment which xgettext appears to propely manage. On the modified hello.scm below, if you run: xgettext -k_ -o hello.pot hello.scm and cat hello.pot, you'll see that xgettext 'stopped' working properly after extracting let's see: xgettext 1. In case you could not reproduce exactly, I'll also attach the hello.pot I got here. ;; hello.scm [modified] starts here #!@GUILE@ -s !# ;;; Example for use of GNU gettext. ;;; This file is in the public domain. ;;; Source code of the GNU guile program. (use-modules (ice-9 format)) (catch #t (lambda () (setlocale LC_ALL )) (lambda args #f)) (textdomain hello-guile) (bindtextdomain hello-guile @localedir@) (define _ gettext) (display (_ Hello, world!)) (newline) (format #t (_ This program is running as process number ~D.) (getpid)) (newline) #! this toplevel block-comment does seem to confuse ngettext (_ this first string should not be extracted) !# (define (further-testing-xgettext) (_ let's see: xgettext 1) #! then for some reason, i'v noticed that xgettext gets confused if block-comment is used inside a function, unlike @ toplevel (_ this second string should not be extracted) !# (_ let's see: xgettext 2)) (display (_ let's see: xgettext 3)) ;; hello.scm [modified] ends here ;; hello.pot starts here # SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR EMAIL@ADDRESS, YEAR. # #, fuzzy msgid msgstr Project-Id-Version: PACKAGE VERSION\n Report-Msgid-Bugs-To: \n POT-Creation-Date: 2011-09-12 20:42-0300\n PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n Last-Translator: FULL NAME EMAIL@ADDRESS\n Language-Team: LANGUAGE l...@li.org\n Language: \n MIME-Version: 1.0\n Content-Type: text/plain; charset=CHARSET\n Content-Transfer-Encoding: 8bit\n #: hello.scm:15 msgid Hello, world! msgstr #: hello.scm:17 #, scheme-format msgid This program is running as process number ~D. msgstr #: hello.scm:26 msgid let's see: xgettext 1 msgstr ;; hello.pot ends here [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640783: please add multi-arch support for m4
On Wed, 7 Sep 2011, Riku Voipio wrote: Package: m4 Version: 1.4.16-2 Severity: normal User: debian-d...@lists.debian.org Usertags: multiarch Tags: patch Hi, The attached patch adds Multi-Arch: foreign field to m4, to annotate the fact that a m4 of foreign architecture can satisfy (build-)depends of m4. [ Sorry for the late reply ] Hmm, I thought multiarch was for library packages, which m4 is not. I'm reading the Debian wiki and it does not say a word about cases like this. Could you please elaborate on why m4 needs to be modified? (If possible, pointing to appropriate documentation). Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643659: Missing Depends: base-passwd
On Wed, 5 Oct 2011, Goswin von Brederlow wrote: I think it is safe to say that essential packages have to be configured before the rest by any bootstraping tool. The job of any bootstrapping tools is precisely to configure the essential packages. By creating the essential flag, we have all agreed that we will not use the Depends field on any package which is Essential: yes. This means that the knowledge about which package should be configured first is left as a task for bootstrapping tools. I understand that you want to see this issue fixed, but you are looking for the wrong solution, which is to ignore completely the definition of essential flag. Instead, I would try to see why this used to work in the past and why it does no longer work. Lack of a dependency which policy says we should not make explicit does not count as a cause, and it's therefore the wrong fix. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files: Please add top-level /run
[ Note: Thanks a lot for the patch and sorry for not answering before ]. El 26/05/11 16:37, Roger Leigh escribió: @@ -32,8 +33,6 @@ var/lib/dpkg var/lib/misc var/local -var/lock var/log -var/run var/spool var/tmp So, you propose that base-files des not contain var/lock or var/run anymore. I think that will not work: If we make var/run and var/lock to be symlinks, and then we upgrade base-files to a version which does not contain var/lock and var/run anymore, the symlinks will disappear, as dpkg will remove them. So, if the symlinks are useful at all, it will not be because base-files creates them, but instead because some other package creates them (which I think it is already the case), in which case we don't really need base-files to deal with them. This is why I think the best thing base-files can do for the good of the whole system is exactly to do nothing about this, which includes not removing var/lock and var/run if/when they are converted to symlinks by another package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files: Please add top-level /run
Ok, I'm starting to understand the idea of making symlinks only in the initial install. Assuming that I manage to do the same in a different way, it would be ok for you, right? (In particular, I'm thinking about creating /var/run and /var/lock symlinks even if they are provided as directories inside the .deb. As far as they are never dropped, I think that would be cleaner than letting dpkg remove them and restoring afterwards). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files: Please add top-level /run
El 27/05/11 10:59, Roger Leigh escribió: On Fri, May 27, 2011 at 10:49:52AM +0200, Santiago Vila wrote: Ok, I'm starting to understand the idea of making symlinks only in the initial install. Assuming that I manage to do the same in a different way, it would be ok for you, right? Absolutely. (In particular, I'm thinking about creating /var/run and /var/lock symlinks even if they are provided as directories inside the .deb. As far as they are never dropped, I think that would be cleaner than letting dpkg remove them and restoring afterwards). I was thinking about this while waking up this morning. I've attached a patch to do this. We retain /var/run and /var/lock as directories. This means all upgrades will be reliable--there's no gap where they might not exist. In the initial install we convert them to symlinks in the postinst. I've created a shell function to do this, which also takes care to move the contents (if any). At this point it's extremely unlikely anything will be present (there isn't testing with debootstrap), but it doesn't hurt. No moving things, please. You told me this was for bootstrapping only, so I'll skip that part. If base-files is going to be officially in charge of creating those symlinks in the initial install, I hope that nobody else is fiddling with them (in the initial install). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628458: Please add /opt to base-files
El 29/05/11 08:25, Jonathan Nieder escribió: Package: base-files Version: 6.4 Severity: wishlist Hi, Eddy Petrișor wrote[1]: I've just found this bug and I must say is a real pain for vendors which package stuff which installs in /opt. I also found an easy way to reproduce the bug. See the bottom of this message for details. As a test one of the guys at work made /opt a symlink and we observed that, although other directories were present in /opt, after the removal of any of the packages that has files in /opt, the symlink is gone somewhere right after or during prerm. I would only expect that to happen when the last package owning /opt is removed. But that much sounds believable, which makes this sound like a good reason to add /opt to base-files. Santiago, what do you think? Hmm, do you mean the change made in 2.2.14 is not enough? /opt is created by default on every new install since Debian 3.0. It is not part of the package itself to give users the freedom to remove it if they wish and not see it recreated at every base-files upgrade, as no part of Debian needs it. If you remove it but you still need it, why do you blame base-files? I don't see why this is reported as a bug against base-files. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628478: base-files: please remove 'Pre-Depends: awk'
The essential status of awk was decided more than 13 years ago. Sorry, my packaging knowledge is limited, but I don't get it :( Do you mean base-files is used to ensure that awk is essential? Yes, exactly. base-files depends on awk, base-files is essential. Therefore, you will always have some awk installed. I might be missing something vital, but is that the proper way to make a package essential, although a package header exists: Essential: yes That's valid only for real packages. Package 'awk' is purely virtual. Neither gawk nor mawk, which provides awk, are essential. Care to help me understand? The predependency of base-files on awk will ensure that you always have some awk installed and working, but the system does not force the user to install any of them in particular. That's why neither gawk, mawk or original-awk is essential by itself. None the less, base-files does _not_ need awk att all. tail and cut (smaller canons) from coreutils (which _is_ essential) will do the job nicely. Yes, but since awk is essential, I prefer the awk way of doing things. It looks more readable to me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628458: Please add /opt to base-files
On Sun, 29 May 2011, Jonathan Nieder wrote: 4. Encourage sysadmins to use bind mounts instead of symlinks for this purpose. All are incomplete or have downsides. (1) prevents the sysadmin from removing /opt, as you mentioned. (2) complicates the package creation procedure, so much so that I'm not sure whether it would work. (3) would prevent directories first created in maintainer scripts and later incorporated into the files list from being cleaned up on removal. (4) has no clear downside --- what would be a good document to advertise this in? I don't know. Would it help if I add a question to base-files FAQ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628594: zipnote fails to update the archive
On Mon, 30 May 2011, Tomas 'ebik' Ebenlendr wrote: Package: zip Version: 3.0-3 Severity: normal Tags: patch Zipnote fails to update archive. The fail is caused by fclose(x), where 'x' is either undefined or already closed. Simple patch follows. --- zipnote.c 2008-05-08 10:17:08.0 +0200 +++ zipnote-patched.c 2011-05-30 16:10:40.0 +0200 @@ -661,7 +661,6 @@ if ((r = zipcopy(z)) != ZE_OK) ziperr(r, was copying an entry); } - fclose(x); Thanks a lot for the report. This bug was introduced in version 3.0, and I see that it's fixed in the latest beta version with this changelog entry: 4. Fix bug in zipnote where undefined file x was being closed instead of in_file. zipnote.c (Christian) and this patch: @@ -661,7 +661,7 @@ if ((r = zipcopy(z)) != ZE_OK) ziperr(r, was copying an entry); } - fclose(x); + fclose(in_file); /* Write central directory and end of central directory with new comments */ if ((c = zftello(y)) == (zoff_t)-1)/* get start of central */ so I'll do that in the next upload. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633978: diffutils: diff -r reports spurious differences
El 15/07/11 17:48, Christian Pernegger escribió: Package: diffutils Version: 1:3.0-1 Severity: normal I've just migrated our media server to new disks using cp -ar and just to make sure everything went over alright I compared the old and the new set with diff -rq, with the attached result. (Sorry for the German locale: - 'Nur in' = 'Only in' - 'Dateien [...] und [...] sind verschieden' = 'Files [...] and [...] are different / differ' ) The thing is, there *aren't actually* any differences (verified with fdupes and md5sum) and diff's result even varies depending on the paths it's called with. diff -rq crypt crypt.new # see log diff -rq crypt/Crypt/Misc/Bernhard/Ongaku crypt.new/Crypt/Misc/Bernhard/Ongaku # see log diff -rq crypt/Crypt/Misc/Bernhard/Ongaku/前野健太 - さみしいだけ crypt.new/Crypt/Misc/Bernhard/Ongaku/前野健太 - さみしいだけ # no differences, same for the other album #copy Crypt/Misc/Bernhard/Ongaku/前野健太* from both mount points to new directories and diff those = no differences Before you ask, I've lots of Japanese, Hindi and Korean file names on the fs, these are the only files that triggered. So I'm guessing there's something wrong with diff's file name / path name handling, maybe length-dependent?. The diff.log.gz that you sent shows that there is indeed something wrong in your system, but it is yet to be seen that you don't have filesystem corruption somewhere, or bad RAM chips. In either case, this is not enough for me to forward this upstream. So please, provide a minimal test case allowing this to be *reproduced*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632682: base-files: please provide a /lib64 - /lib symlink on 64-bit systems
reassign 632682 libc6 retitle 632682 we should probably remove /lib64 - lib symlink (with care) thanks Hi. After discussing about this today, it seems what we really need for multiarch to work is to remove those symlinks, hence this reassign. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634607: Add Affero GPL license to /usr/share/common-licenses
reassign 634607 debian-policy thanks On Tue, 19 Jul 2011, Mike Gabriel wrote: Package: base-files Version: 6.3 Severity: wishlist Tags: sid Hi, please add AGPL-n license files to /usr/share/common-licenses, so that people can refer to that from within their packages. More and more projects are changing over to AGPL, currently. As Debian allows AGPL since 12/2008, it would be nice to have the license shipped with this package. Hi. Sometime ago, I decided not to decide about this myself. Instead, the debian-policy group decides about this (see base-files FAQ), so I'm reassigning to policy. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630902: m4: FTBFS: FAIL: test-readlink
B1;2403;0cOn Mon, 20 Jun 2011, Eric Blake wrote:
For the record, this is what git bisect says:
65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit
commit 65cfc6722361570bfe255698d9cd4dccaf47570d
Author: Al Viro v...@zeniv.linux.org.uk
Date: Sun Mar 13 15:56:26 2011 -0400
readlinkat(), fchownat() and fstatat() with empty relative pathnames
For readlinkat() we simply allow empty pathname; it will fail unless
we have dfd equal to O_PATH-opened symlink, so we are outside of
POSIX scope here. For fchownat() and fstatat() we allow AT_EMPTY_PATH;
let the caller explicitly ask for such behaviour.
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
Yes, most likely this is a kernel and/or glibc bug. POSIX requires
readlinkat(dfd, , buf, size) to fail with ENOENT, if dfd is either
AT_FDCWD or open on a directory. Which does strace say about the
syscall made just before the gnulib test-readlink fails?
Sorry for the late reply. I'm including the complete strace at the end.
I'll try and reproduce this setup myself, [...]
Please do so. Apparently this is an issue with just Linux and m4, and
does not seem to be specifical to Debian at all, so it should be easy
to reproduce indeed.
The strace output:
execve(./test-readlink, [./test-readlink], [/* 19 vars */]) = 0
brk(0) = 0x1c9
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f91ab64d000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9189, ...}) = 0
mmap(NULL, 9189, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f91ab64a000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\300\357\1\0\0\0\0\0..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1570832, ...}) = 0
mmap(NULL, 3684440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f91ab0ac000
mprotect(0x7f91ab226000, 2097152, PROT_NONE) = 0
mmap(0x7f91ab426000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17a000) = 0x7f91ab426000
mmap(0x7f91ab42b000, 18520, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f91ab42b000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f91ab649000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f91ab648000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f91ab647000
arch_prctl(ARCH_SET_FS, 0x7f91ab648700) = 0
mprotect(0x7f91ab426000, 16384, PROT_READ) = 0
mprotect(0x7f91ab64f000, 4096, PROT_READ) = 0
munmap(0x7f91ab64a000, 9189)= 0
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f91ab0de480}, {SIG_DFL, [],
0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f91ab0de480}, {SIG_DFL, [],
0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0x7fff370e7318) = 12511
wait4(12511, [{WIFEXITED(s) WEXITSTATUS(s) == 0}], 0, NULL) = 12511
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f91ab0de480}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f91ab0de480}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
readlink(no_such, 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory)
readlink(no_such/, 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory)
readlink(, 0x7fff370e7340, 80)= -1 EINVAL (Invalid argument)
write(2, test-readlink.h:41: assertion fa..., 37test-readlink.h:41: assertion
failed
) = 37
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid()= 12510
tgkill(12510, 12510, SIGABRT) = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608181: /usr/bin/xgettext: xgettext segmentation fault
As I don't have the contents of fichiersphp.lst, this is imposible for me. Could you please provide a minimal test case which is complete, so that I can forward this upstream? Thanks. Please find it attached. It is the list of *.php files from a wordpress tree. Sorry. I'm still unable to reproduce it. Please provide a *minimal* test case, which is complete*. By complete I mean that every time the command line references a file, you should send me the file as well. You don't need to send me all the .php files. If you tell me that they are taken *verbatim* from some known wordpress version (preferably, the latest that you can find), that's ok. By minimal I mean that you should try to trim both the command line and the number of files as much as you can and see if you can reproduce it with a shorter command line or less files. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632887: base-files: When bash is called as sh it should behave as sh
On Wed, 6 Jul 2011, Georgios M. Zarkadas wrote: I don't know if letting /etc/bash.bashrc to be sourced even on the sh case has been done deliberately, but IMHO is not good, since code in /etc/bash.bashrc typically assumes that the full bash featureset is available, which is this case is a wrong assumption. It's not done deliberately, it's just that this is subtle enough that no one has noticed it until now. Will be fixed in the next upload. I see that you are also trying to define a sane PS1 if bash.bashrc does not exist. I decided not to apply that part of the patch because if bash.bashrc does not exist, then I can assume that the user removed or modified it, in which case it is up to the user (i'd like to keep /etc/profile as short as possible). If that kind of site-wide customisation is desired for sh shells it would be better to be implemented as an `ENV=/etc/sh.shrc ; export ENV' sequence of commands for the general sh case (so that it is also available for dash and possibly other shells). I attach a supplementary patch for that, in case you find this possibility of interest (etc_profile-sh.shrc.patch). I think this is more or less what /etc/profile.d is for. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679103: liblapack3gf: should be in section oldlibs
Package: liblapack3gf
Version: 3.4.1-3
Please put this package in section oldlibs, as it's proper for
transitional packages. This should help tools like deborphan
to signal this package as candidate for removal.
Thanks.
diff -ru lapack-3.4.1.original/debian/control lapack-3.4.1/debian/control
--- lapack-3.4.1.original/debian/control2012-06-17 14:21:27.0
+0200
+++ lapack-3.4.1/debian/control 2012-06-26 13:26:08.671362975 +0200
@@ -27,6 +27,7 @@
Package: liblapack3gf
Architecture: any
+Section: oldlibs
Depends: ${misc:Depends}, ${shlibs:Depends}, liblapack3
Description: Transitional package for liblapack3
LAPACK version 3.X is a comprehensive FORTRAN library that does
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679104: libblas3gf: should be in section oldlibs
Package: libblas3gf
Version: 3.4.1-3
Please put this package in section oldlibs, as it's proper for
transitional packages. This should help tools like deborphan
to signal this package as candidate for removal.
In addition, the package should be probably Architecture: all, as
it is just a dependency package and it's empty otherwise.
Thanks.
diff -ru blas-1.2.20110419.original/debian/control
blas-1.2.20110419/debian/control
--- blas-1.2.20110419.original/debian/control 2012-06-02 17:31:52.0
+0200
+++ blas-1.2.20110419/debian/control2012-06-26 13:32:31.273058995 +0200
@@ -28,7 +28,8 @@
This package contains a shared version of the library.
Package: libblas3gf
-Architecture: any
+Architecture: all
+Section: oldlibs
Depends: ${shlibs:Depends}, ${misc:Depends}, libblas3
Description: Transitional package for libblas
Several minor changes to the C interface have been incorporated.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679103: liblapack3gf: should be in section oldlibs
On Wed, 27 Jun 2012, Julien Cristau wrote: Section changes are handled by ftpmaster, not the package itself. I know, but you can change it in the package and reassign to ftp.debian.org afterwards, as a way to tell ftpmaster I agree with this change. BTW: Being a dummy package, it should be Architecture: all as well. (If you wanted a good reason for a new upload, this could be one). Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679356: For users who had base-files 6.8 installed, dpkg considers /etc/profile an (obsolete) conffile
On Wed, 27 Jun 2012, Josh Triplett wrote:
Package: base-files
Version: 6.11
Severity: normal
base-files 6.8 had /etc/profile as a conffile. Thus, users who had
6.8 installed and subsequently upgraded to a later version will have
/etc/profile marked as an obsolete conffile in the dpkg database:
~$ dpkg-query -f '${Conffiles}\n' -W base-files | grep obsolete
/etc/profile 91901ce5707909cfec8b3a1a6efbfa61 obsolete
So what's the dpkg command that I can use in postinst to tell dpkg
that this file is not really obsolete but just a configuration file
which is not a conffile? Is there one such dpkg command?
Or are you suggesting that I fiddle with dpkg database directly?
(I hope not).
This seems more a dpkg bug/feature which affects base-files than
a base-files bug to me.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661055: postfix-gld: Greylisting fails for IPv6 because the ip field in the database is too short
On Thu, 23 Feb 2012, Edwin Top wrote: Package: postfix-gld Version: 1.7-3 Severity: important Tags: ipv6 The program fails to match sender MTA's correctly in most cases when an IPv6 address is used. This is because the field ip of the table greylist in the MySQL Database is only a char(16) in /usr/share/gld/tables.mysql To be able to store IPv6 addresses correctly it should be at least char(39) (8x4 characters plus 7 for the separating ':'). Or, if you want to take into account IPv4 tunneling features it should be able to store e.g. [::::::192.168.0.1] and should then be char(45). No reply from the author so far. I was considering to change the tables.mysql file as you suggest but I fear that by doing so I could be putting an IPv6 ready stick to this package when in fact I have no idea about how everything else would work with IPv6 (for example, what would happen with LIGHTGREY, which uses a /24 mask?). Will try to contact the author again. I agree that this bug is important, so I'm sorry not to have it fixed in wheezy. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664989: this bug makes googlecl almost useless
severity 664989 serious
thanks
This bug makes googlecl useless for me, as I only use to retrieve
documents from Google Drive in this way:
google --format ods docs get ${document} .
In fact, I have python-gdata 2.0.14-2 on hold because of this bug.
IMHO, when you start putting packages on hold it's a clear sign that
those packages should probably not have entered testing.
I'm raising the severity only to mean that this bug deserves to be
fixed in wheezy as a freeze exception.
Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681064: octave: does not configure properly
Package: octave Version: 3.6.2-2 Severity: serious I had a wheezy system which was updated to wheezy last week. After apt-get update; apt-get upgrade; apt-get dist-upgrade today I decided to install octave and octave-info, then purge octave3.2 and octave3.2-info. Now octave does not configure: # dpkg --pending --configure Setting up octave (3.6.2-2) ... warning: X11 DISPLAY environment variable not set error: could not find the file or path /usr/share/octave/packages error: called from: error: /usr/share/octave/3.6.2/m/pkg/pkg.m at line 1234, column 5 error: /usr/share/octave/3.6.2/m/pkg/pkg.m at line 418, column 16 error: /usr/share/octave/3.6.2/m/startup/octaverc at line 26, column 1 dpkg: error processing octave (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for menu ... Errors were encountered while processing: octave Attached complete (gzipped) dpkg.log for today in case it's useful to diagnose the problem. Thanks. dpkg.log.gz Description: Binary data
Bug#681065: octave: Please use --no-window-system in postinst
Package: octave
Version: 3.6.2-2
Severity: minor
When octave is installed I see this:
Configurando octave (3.6.2-2) ...
warning: X11 DISPLAY environment variable not set
As apt-get upgrade is supposed to work on a terminal, this warning
about DISPLAY variable not set is a little bit misleading and it would
be much better to avoid it if possible.
The following patch seems to disable the warning:
diff -ru octave-3.6.2.original/debian/octave.postinst
octave-3.6.2/debian/octave.postinst
--- octave-3.6.2.original/debian/octave.postinst2012-06-05
21:02:56.0 +0200
+++ octave-3.6.2/debian/octave.postinst 2012-07-10 13:33:02.924950342 +0200
@@ -7,7 +7,7 @@
#DEBHELPER#
rebuild_pkg_database () {
-octave --silent --no-history --no-init-file\
+octave --silent --no-history --no-init-file --no-window-system \
--eval pkg ('rebuild');
}
Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675731: base-files: Please add VERSION entry to /etc/os-release for unstable/testing too
On Sat, 2 Jun 2012, Jeremy Bicha wrote:
Package: base-files
Version: 6.8
Severity: wishlist
As requested in http://bugs.debian.org/659853 Debian now includes
/etc/os-release. Therefore, I'd like to drop the lsb-release
dependency from epiphany-browser. We use three pieces of info for the
OS-specific part of the useragent: the distro name, the distro
version, and the package version. Those three pieces (and some
punctuation) currently result in Debian/unstable (3.4.2-1) or
Ubuntu/12.10 (3.5.1-0ubuntu1).
I'd like to use the ID and VERSION fields of /etc/os-release to fill
in these fields, but Debian's implementation does not include a
VERSION entry except for stable releases.
Which is right. Wheezy is not a version, it's just a codename.
It will become Debian 7.0 when it's stable, but it's wrong to think
of wheezy as a version.
I feel that you are trying to fix an aesthetic bug in the user-agent
by requesting that everybody else does things in a different way.
If you want wheezy, why can't you do this if VERSION is empty?
echo $PRETTY_NAME | awk '{ print $3 }' | sed -e 's#/.*##'
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678106: base-files: dummy bug, please ignore
Package: base-files Version: 6.11 Severity: serious If this release reaches testing before initscripts 2.88dsf-27, the following will happen to anybody installing a new system from scratch: base-files creates /etc/motd as a real file. initscripts in testing removes the first line of /etc/motd to create /etc/motd.tail Then, when you upgrade to initscripts in unstable, the file /etc/motd.tail is moved back to /etc/motd. The problem with this is that the /etc/motd which is created by base-files 6.11 already has the first line trimmed (i.e. it is already in motd.tail format). I could have avoided this by using a Breaks: but such relation is too strong. It is ok to have base-files 6.11 and initscripts 2.88dsf-22.1 in the system as far as you bootstrapped the system with base-files 6.9 or earlier. So, this is a dummy bug to prevent base-files 6.11 to enter testing. Should be closed as soon as initscripts 2.88dsf-27 or later reaches testing. If they enter testing at the same time, even better. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673271: libc-bin: Please include /etc/nsswitch.conf
Package: libc-bin
Version: 2.13-32
We should probably move /etc/nsswitch.conf from base-files to libc-bin,
as it is really a configuration file for libc6.
The file was in base-files for historical reasons, but now that there
is a libc-bin package and it's essential, that would be its real place.
[ You can take the master copy from /usr/share/base-files/nsswitch.conf
from any Debian system ].
This file is currently installed by base-files postinst in this way:
#!/bin/sh
set -e
install_from_default() {
if [ ! -f $2 ]; then
cp -p $1 $2
fi
}
[...]
if [ $1 = configure ] [ $2 = ]; then
install_from_default /usr/share/base-files/nsswitch.conf /etc/nsswitch.conf
[...]
i.e. the file is put there when base-files is installed by
debootstrap, and it's not touched again.
For now, I think you can simply do a similar thing in libc-bin at any
given time (i.e. copy the file from a directory owned by libc-bin),
as this move does not require any coordination between libc-bin and
base-files (nothing bad will happen if two different packages put the
same file there when the file is not there).
We could then wait for a stable release to happen (ideally, wheezy),
and then I could remove this stuff from base-files.
Please note that people is now asking for a procedure to add and
remove entries to this file (see Bug#649265), and for that reason the
file should not be a conffile.
Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673767: base-files: prompting due to modified conffiles which were not modified by the user
On Mon, 21 May 2012, Andreas Beckmann wrote: Package: base-files Version: 6.8 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed the piuparts upgrade test because dpkg detected a conffile as being modified and then prompted the user for an action. I would say that's not exact. dpkg does not detect a conffile as being modified, dpkg detects the file as being different from the *default*, which is probably correct. In squeeze, /etc/profile was created by postinst from a default file in /usr/share/base-files. In base-files 6.5, the default changed. Finally, in base-files 6.8, the file is now a conffile. How is this supposed to be handled? The URLs you give explain how to remove a conffile or how to rename it, but not how to make a conffile when it was not a conffile. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673767: base-files: prompting due to modified conffiles which were not modified by the user
On Mon, 21 May 2012, Andreas Beckmann wrote: I'd probably * collect md5sums of all previous versions of the defaults (going back to lenny, eventually even earlier as this is an essential package and we don't want to annoy people with long grown systems ... don't forget point releases (or even historic versions in sid/testing) that might have changed the defaults But checking md5sums should be dpkg job, that's precisely what the conffile mechanism is for. If the job of dpkg has to be duplicated in preinst and postinst, there is something fundamentally wrong here. Sorry, I'm going to revert this change for now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681064: [Pkg-octave-devel] Bug#681064: octave: does not configure properly
On Tue, 10 Jul 2012, Rafael Laboissiere wrote: I suspect that your system has some file left over from another package that may be causing the problem. If this is true, then what you are reporting is a real bug that must be fixed, but it is perhaps not caused by the octave package. I can assure that there is a real bug here, because this happened on twenty different computers at work, and everything I did was normal, i.e. apt-get update, apt-get upgrade, apt-get dist-upgrade, dpkg --purge not-needed-package, etc. I will not change the severity again because I don't want to start a bug severity war, but I still think this bug deserves a freeze exception (i.e. it should be RC). After the analysis by Thomas Weber, do you still need a precise way to reproduce this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680990: Diff does not show BOM difference.
On Mon, 9 Jul 2012, jmg wrote:
Package: diff
Version: 1:3.0-1
Please note that when reporting bugs, you should try the latest
version if possible. In this case, wheezy has version 3.2.
Severity: normal
When diff is used to compare two files which are identical line by
line and a unique difference which is wether BOM is present or not
to indicates UTF-8 encoding, diff does not indicate the good
difference.
Please explain what do you mean by does not indicate the good difference.
I have used this
#include stdio.h
int main() {
printf(%c%c%c, 0xef,0xbb,0xbf);
return 0;
}
to create a UTF8 BOM and then I've created two text files, one with
the BOM at the beginning and another one without it. This is what I
*see* when I make the diff:
1c1
Hello.
---
Hello.
but if I redirect the output to a file and use patch, the first file
becomes identical to the second file, so the diff is correct.
Are you reporting that BOM is invisible like spaces?
Why should we consider that as a bug in the diff program?
If it's invisible, blame the terminal, not diff!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680990: Diff does not show BOM difference.
On Sun, 15 Jul 2012, jeanmichel@free.fr wrote: *see* when I make the diff: 1c1 Hello. --- Hello. Yes, this is the issue I consider in this bugreport. First, the example here-above shows the difference in not visible with a regular terminal. So what? The same happens with spaces. You don't see the spaces because they are invisible. But this is not a bug in diff. Spaces were already invisible before diff existed. diff does not make them more invisible, diff respects them as they are. And the same happens with BOM. It is respected. Secondly, when I copy your diff I received by mail to $(cat | od -c) command, this gives: 000 1 c 1 \n H e l l o . 020 \n - - - \n H e l l o 040 . \n 042 which just means in one way diff output is not copiable lossless. No, this is wrong because I didn't try to copy the output losslessly in the above example. I typed the above by hand. Whatever output you might obtain from od -c on my previous email does not show anything but the already known fact that BOM is as invisible as spaces. Please forget the contents of my previous email and run od -c on text files created as I explained. You will see that diff output is correct. For a regular user, this does mean the output of diff is simply not understandable, in at least two ways (first and second). You seem to imply that every character that might be in the output of diff should be visible. The fact that spaces are invisible invalidates your theory. Only advanced geek can understand this diff output. You would be confused by extra spaces in exactly the same way. Do you have to be a geek to understand a diff which is caused by extra spaces? For me, it is because diff output is not compatible with unicode specification. What do you mean by that? Does unicode specification mandates that BOM should be visible? Please give a reference for that. but if I redirect the output to a file and use patch, the first file becomes identical to the second file, so the diff is correct. This just means that diff is a tool campatible with patch tool. Such a compatibility is essential. But one can expect more from a diff command: For instance, one can expect output should be copiable by mail lossless; this is not the case as explained above. Again, you are drawing conclusions by assuming that I used diff output as is in my previous email. This is not the case, I typed it by hand. In fact, I made emphasis on the word see to indicate that was *just* what I *saw*. Third, you suggest to store diff output to file. I wonder how such a file should be considered. Is this an octet stream (binary file) to be handled with byte oriented tools? It is not what it looks like. Is this a character stream (text file) compliant with UTF-8, to be handled with text tools? I do not think so as explained above, because any byte sequence is not valid UTF8. This is ambiguous, and I hope a future version including UTF-8 support make it less ambiguous. Where do you take the idea that diff does not support UTF-8? A text file including ñ or é is diffed correctly. A text file containing BOM is also diffed correctly. The only problem is that the BOM itself is not visible but I repeat that diff is not to blame for that. Are you reporting that BOM is invisible like spaces? Why should we consider that as a bug in the diff program? If it's invisible, blame the terminal, not diff! Fourthly, if BOM is invisible like spaces, diff -w should take care of it. This is not the case. The meaning of diff -w is explained in the texinfo manual: `-w' `--ignore-all-space' Ignore white space when comparing lines. *Note White Space::. White space characters include tab, vertical tab, form feed, carriage return, and space; Because BOM is neither tab, vertical tab, form meed, carriage return or space, diff is right in showing a difference for that. But I can understand that including BOM in the mix would be useful. I'll consider that as a wishlist item and will forward it upstream. Five, if we can have a message such as «No newline at end of file», we should also have a message such as «No BOM at start of file»/«BOM at start of file». That would probably complicate the work for the patch program. To summarize: I don't see the point in modifying the output of diff without -w, because the output is correct. The only thing I see where diff could improve is in the output of diff -w. I'll forward that upstream as wishlist.
Bug#681942: dialog: file browser to select : no SSHFS dir
On Wed, 18 Jul 2012, ubuntu6226 wrote: Package: dialog Version: 1.1-20100428-1 Severity: normal Hello, I am so happy that dialog still exists. thanks dialog --backtitle hello --fselect /home/user/dir 15 86 this does not list the mounted sshfs mount: ...sshfs type fuse.sshfs (rw,nosuid,nodev,max_read=65536,user=...) Have you tried dialog --backtitle hello --fselect /home/user/dir/ 15 86 instead? (note the final / at the end of the path). It works for me that way. I wonder if this has anything to do with sshfs at all. Remember also that directories mounted by sshfs (fuse, in general) are only available for the user actually mounting the directory. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670588: gettext, does not scan libraries directly under debian/gettext/usr/lib/ for shlibs
On Fri, 27 Apr 2012, peter green wrote: Package: gettext Version: 0.18.1.1-5 Severity: important While working on an unofficial hardfloat port of debian for the Pi I discovered a missing dependency on libcroco3 in the newly built gettext package. I tracked this down to libraries directly under debian/gettext/usr/lib/ not being scanned for shlibs. In official debian the dependency is picked up anyway because the binaries in /bin are uselessly linked against libcroco3 but for some reason this doesn't happen in my environment. I do not know why why the binaries pick up this useless linkage in debian and don't pick it up in the armhf for pi variant I'm working on. Neverthless packages are required by policy 8.6 to pass all binaries and shared libraries to dpkg-shlibdebs (not just a subset that happen to give the right results) so this is a bug that should be fixed in debian. Patch is attatched. Thanks a lot. I believe this is the same bug as Bug#604778, which I finally understand. Will try to upload a fixed version soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646034: Please split libgettextpo0 out for multiarch
Hello Steve. I have just uploaded gettext_0.18.1.1-6 for unstable using (most) of your patch. Thanks a lot! While looking at the patch I noticed a few missing things that you might want to fix in Ubuntu: - There were no Section and Priority for libgettextpo0. As a result, this library seems to be in section devel in Ubuntu 12.04. - There was not a call to dpkg-shlibdeps in libgettextpo0. As a result, libgettextpo0 has a lot of unwanted dependencies, as it seems to reuse the shlibs:Depends variable from gettext binary package. There are also some things for which I'm unsure: - As we are both moving libgettextpo0 to another package and moving to multiarch, libgettextpo0 does not really share any files with gettext, so the Replaces was not strictly necessary, but I can think about some scenarios where it could still be useful (for example, compatibility with a backport to squeeze which does not do multiarch yet), and that's why I've decided to keep it. - It is not clear to me where static .a libraries should go in multiarch. I've done what the patch did, which is to keep them in /usr/lib in gettext (which is a -dev package) as I understand that the priority here was to switch library packages. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666467: indent: should “Suggests: indent-doc”
On Mon, 2 Apr 2012, Ben Finney wrote: On 01-Apr-2012, Santiago Vila wrote: In this particular case, there is a manpage which is generated via texinfo2man, so the indent-doc package does not add any info which is not already in the manpage. I agree that a mere HTML rendering of what is already in the ‘info’ document and the man page is not useful enough to suggest to ‘indent’ users. I wonder why it is packaged, then? Because it's mandated by Debian policy: 12.4 Preferred documentation formats The unification of Debian documentation is being carried out via HTML. If your package comes with extensive documentation in a markup format that can be converted to various other formats you should if possible ship HTML versions in a binary package, in the directory /usr/share/doc/appropriate-package or its subdirectories.[107] The footnote says: The rationale: The important thing here is that HTML docs should be available in *some* package, not necessarily in the main binary package. May I close this bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671066: ftp.debian.org: upload urgencies should not accumulate
Package: ftp.debian.org I see that diffutils_1:3.2-6, which was uploaded with urgency=low, will only need 5 days to enter testing, probably because I made 1:3.2-4 to be urgency=medium. I don't know when you changed the algorithm but I think it is a bad change. In this case, the reason to modify the urgency was that 1:3.2-4 just tried to disable a test which failed, while 1:3.2-6 has real code changes which IMHO, deserve the usual 10 days in unstable. The traditional meaning of urgency has always been the time required for *this* upload to supersede the version currently in testing and that's why I used urgency=low in 1:3.2-6. However, if urgencies accumulate, how are we supposed to really mean 10 days after an upload not of low priority? It's impossible! So please reconsider the way urgencies are handled. The traditional way worked well enough and the current behaviour is a lot confusing. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671066: ftp.debian.org: upload urgencies should not accumulate
On Tue, 1 May 2012, Philipp Kern wrote: However, if urgencies accumulate, how are we supposed to really mean 10 days after an upload not of low priority? It's impossible! No. The idea is that if you specify urgency=medium that *this* *change* (not upload!) should go into testing in an expedited fashion. Well, I understand the idea, but the idea still seems wrong to me. It is not the changes the ones that go to testing, it's the upload the one that goes to testing. Accordingly, the urgency is put on the upload, not on the changes. There is not a way to put an urgency on the changes other than putting an urgency on the upload. When I put an urgency on an upload, I put it on that upload, not on the upload and all the uploads that come next. If you then go and upload something else in the meantime that's your problem, as we still want the change in testing. You speak we as if you were excluding the maintainer from such we. Please consider the possibility that we the maintainers still want our urgencies to be honored! You could a) wait for the previous version to hit testing or b) ask the release team to override the urgency of your most recent upload. The only case where urgencies should not accumulate is if you take a different branch and upload it without the changes in the previous version. And here you speak the only case as if it were a rare exception. How do you know that the upload is not trying to fix the same thing in a better way¿ Answer: You don't. For that reason, the assumption that the upload is on the same branch is gratuitous. It could be the case, but it could be not the case as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671066: ftp.debian.org: upload urgencies should not accumulate
On Tue, 1 May 2012, Cyril Brulebois wrote: Adam D. Barratt a...@adam-barratt.org.uk (01/05/2012): It's been that way for at least four years; I suspect a good deal longer but don't have the evidence immediately available. The start of the release team's britney1 repository, when we took over direct running of it rather than ftp-master doing so on our behalf, already includes urgencies being sticky. Thanks for the confirmation, closing as not a bug accordingly. Hmm, not a bug accordingly?. It may not be a bug in the sense that it follows the specifications, but I was not reporting it as a misbehaviour with respect to the specifications, but as *design flaw*. Design flaws do not get fixed magically by saying that behaviour follow the specifications. It is not the changes who have urgencies, it is uploads who have them. If a package in unstable does not propagate to testing and there is a new upload, the maintainer is fully aware that the upload supersedes the previous version in unstable *for all purposes*, and this should mean that the urgency of the new upload should supersede as well the urgency of the current version at unstable for consistency. Whether the new package is based on the same branch or on another branch is not something britney should try to guess, because it will often fail at doing so. Anyway, I'm afraid you guys are now so used to the new behaviour that there is no room for debate here, which is sad, so I'll stop here. BTW: I'm curious: Am I really the very first maintainer to complain about this behaviour? That would be really surprising. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671066: ftp.debian.org: upload urgencies should not accumulate
El 02/05/12 00:01, Adam D. Barratt escribió: After a little bit of research, the mighty archive.org has old copies of the code, albeit not in a revision-controlled format. The earliest version recorded there is from April 2004 and assuming I'm reading its read_urgencies method correctly already implemented sticky urgencies. Thanks a lot for the research (I'm amazed :-). If you really feel this is the right behaviour for britney, please consider documenting it in policy. The current text reads this way: 5.6.17 Urgency This is a description of how important it is to upgrade to this version from previous ones. so I believe there is room here to explain it better. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671186: netgen: usage of profile.d violates policy
Package: netgen Version: 4.9.13.dfsg-4 Policy says: 9.9 Environment variables A program must not depend on environment variables to get reasonable defaults. [...] If a program usually depends on environment variables for its configuration, the program should be changed to fall back to a reasonable default configuration if these environment variables are not present. If this cannot be done easily (e.g., if the source code of a non-free program is not available), the program must be replaced by a small wrapper shell script which sets the environment variables if they are not already defined, and calls the original program. Therefore, using profile.d to define environment variables (which netgen does by putting small files there) is against policy. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671257: gettext: msgfmt output format prevents multiarch migration
severity 671257 wishlist thanks El 02/05/12 20:56, Paul Martin escribió: Package: gettext Version: 0.18.1.1-6 Severity: important Tags: l10n msgfmt produces binary files which vary dependent on the endianness of the system you build on. As localization files are supposed to be placed in /usr/share/ this means that packages with localized strings fail the requirement of multiarch of all shared files being identical across architectures. For example, bug #670023. There is a workaround: split such packages in two, with a binary package and a localization package. This, I've been told by the FTP team is not a desirable action. The better way out of this (and the one preferred by the FTP team) is for msgfmt always to produce .mo files of the same endianness, regardless of the platform it's run on. I think including .mo files in a library package is wrong by itself, with or without multiarch, because the next sonme bump will force the new library package to conflict the old one, which is contrary to the general design of libraries where you are normally allowed to install as many different versions of a library as you need without conflicts. So: Can you give me an example where common endianness in .mo files is desired for multiarch which is *not* a library? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670023: libpopt0: arch-dependent files in multiarch: same package
On Sun, 22 Apr 2012, Julien Cristau wrote: Package: libpopt0 Version: 1.16-3 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi, libpopt0 is marked as Multi-Arch: same, but contains files in arch-independent paths with arch-specific contents: [...] The following patch should make .mo files to be always little endian. Not that I think it is a good idea to mix .mo files and libraries in the same package, but definitely the current gettext package does *not* prevent you from doing so. --- a/debian/rules +++ b/debian/rules @@ -45,6 +45,8 @@ objdir = $(CURDIR)/obj-$(DEB_HOST_GNU_TYPE) objdir_udeb = $(objdir)-udeb +MSGFMT = /usr/bin/msgfmt --endianness little + configure: configure-deb-stamp configure-udeb-stamp configure-deb-stamp: dh_testdir @@ -52,7 +54,7 @@ mkdir $(objdir) # Add here commands to configure the package. cd $(objdir) \ - ../configure --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) --prefix=/usr --mandir=/usr/share/man --enable-shared $(CROSS) + MSGFMT=$(MSGFMT) ../configure --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) --prefix=/usr --mandir=/usr/share/man --enable-shared $(CROSS) touch $@ configure-udeb-stamp: @@ -61,7 +63,7 @@ mkdir $(objdir_udeb) # Add here commands to configure the package. cd $(objdir_udeb) \ - ../configure --prefix=/usr --mandir=/usr/share/man --enable-shared $(CROSS) + MSGFMT=$(MSGFMT) ../configure --prefix=/usr --mandir=/usr/share/man --enable-shared $(CROSS) touch $@ build: build-arch build-indep -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671257: gettext: msgfmt output format prevents multiarch migration (fwd)
[ Adding Steve Langasek, multiarch architect in Debian, to Cc list ]. On Thu, 3 May 2012, Bruno Haible wrote: Hi Santiago, A long time ago, people working on embedded systems in Debian had the idea that it would be a good thing to have .mo files in the same endianness as the architecture on which they are used. However, the saving in cpu time was too small to justify the need to have native endianness everywhere. Well, the fact is that this change was made in gettext after all, and now msgfmt creates .mo files in native endianness I don't know where you got this history from. AFAIK, GNU 'msgfmt' always created .mo files in native endianness since the beginning (1995), up until 2005-08-26, when the option --endianness was introduced. Hmm, 2005-08-26? Are you sure of that? I remember well the bug by Neil Williams: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468209 where he asked --endianness to be documented, as he was thinking about using it in his embedded projects to override the current msgfmt default of always creating little endian .mo files. This was in 2008. At that time, msgfmt always created little endian .mo files. The response we gave to him was basically: You don't need this option, as .mo files are always little endian and gettext tools handle both forms just fine. Period. By we I mean the response I gave to him which later you mostly agreed as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468209#37 So, imagine my surprise when I started to receive requests from multiarch people so that msgfmt changes to be always little endian. Paul Martin writes: packages with localized strings fail the requirement of multiarch of all shared files being identical across architectures. Maybe the workaround is simply to exclude *.mo files from this requirement? Have you proposed this to the Debian people? I guess people in charge of multiarch would much prefer not to do any exceptions. In some way, they have declared the war to gratuitous differences in binary files, because, well, they are gratuitous! i.e. we would like msgfmt to create always little endian .mo files, as before. You can achieve this behaviour by setting the two environment variables MSGFMT=/usr/bin/msgfmt --endianness=little GMSGFMT=/usr/bin/msgfmt --endianness=little during the 'configure' run, and forcing an update of the .mo files through cd po ; make update-po after make has run. Yes, we could do that, in each and every package, but somehow we feel that's not the best way to solve this. I think it is not too difficult to integrate these two additions into Debian's build system (.spec files, templates, whatever)? Debian's build system is a lot more heterogeneous than that. Some people use debhelper, some people do not and write debian/rules in their own style. Some people use debhelper ultrasimplified dh format, some people do not. The opinion of people in charge of multiarch is that in the long run, it would be much better if msgfmt's default changed in gettext to be little endian again. [ Steve: I think this summarizes your feelings about this, feel free to add any thing I forgot or I didn't explain well to Bruno ]. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668304: mailman: Translations should use unicode charset
On Tue, 10 Apr 2012, Ralf Jung wrote: Package: mailman Version: 1:2.1.13-5 Severity: wishlist Tags: l10n The mailman translations should use uncide as character set instead of the language-specific local character sets. I see no reason not to use unicode nowadays, and after some manual conversion as described on http://www.divideandconquer.se/2009/08/17/convert-mailman-translation-to-utf-8/ mailman is working fine with unicode as charset for the German and English translation. That solution is a hack, really. The gettext system was designed to allow translators to use whatever charset encoding they wish, and there is no need to change all the translations for that. What you need is translations to be *shown* in your own charset, not translations to *be* in UTF8, which is usually irrelevant. The gettext system takes care of charset conversion but apparently it's not working properly. So yes, there seems to be a bug somewhere, but modifying all the translations is the wrong solution. (I was going to report this as a bug but I see that it's already reported) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671353: gettext-el: fails to upgrade from squeeze
tags 671353 + help thanks On Thu, 3 May 2012, Andreas Beckmann wrote: Package: gettext-el Version: 0.18.1.1-6 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'squeeze'. It installed fine in 'squeeze', then the upgrade to 'sid' fails. Thanks for the report. I tried to reproduce it on a qemu virtual machine without success. Therefore, I'm tagging this as help just in case anybody reading this is able to explain what's happening here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671353: gettext-el: fails to upgrade from squeeze
On Fri, 4 May 2012, Agustin Martin wrote: On Fri, May 04, 2012 at 05:52:47PM +0200, Agustin Martin wrote: seems that install/gettext is run twice, one by emacs flavour and other by gettext-el. Links are already created in first run, so second run complains and fails. Indeed I think that my problem appeared when upgrading gettext-el together with emacs-snapshot. I'd consider either using 'ln -sf' to create those symlinks (my preferred choice) Forget about this choice, this will cause byte-compiling twice for no good reason if both emacs flavour and gettext-el are installed in the same run. Sorry, too late, I'm reading this just after dupload run. In either case, what you call no good is the result of following emacs policy. IMHO, if there is anything to improve here, it would be emacs policy, not whatever individual packages do to follow it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671353: gettext-el: fails to upgrade from squeeze
On Sat, 5 May 2012, Andreas Beckmann wrote: On 2012-05-04 19:07, Santiago Vila wrote: IMHO, if there is anything to improve here, it would be emacs policy, not whatever individual packages do to follow it. Will you follow up on this emacs policy problem? I assume it could show up in more packages ... Well, I was talking specifically about the optimization suggested by Agustín (i.e. the fact that the install script is called twice). We want .elc files to be regenerated if you upgrade either the emacs flavour or the foo-el package containing emacs lisp code, and the install script does not know which package will be configured next, or which package has already been configured. The safe thing to do is to follow emacs policy, even if this means calling the script twice. Otherwise maybe we run the risk of building only with the wrong emacs (the one that has not been upgraded yet). Maybe this needs to be implemented in a completely different way, for example using dpkg triggers. Feel free to suggest that to the emacs maintainers. On the other hand, there is actually one thing which definitely needs to be improved, namely, this sample file: /usr/share/doc/emacsen-common/sample-package-install-foo.gz Following such sample to the letter will surely lead to bugs like this one in gettext-el. I'll file a bug for that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671353: gettext-el: fails to upgrade from squeeze
Hi. I see that using triggers has already been suggested: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618720 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671676: emacsen-common: sample install file does not work properly
Package: emacsen-common
Version: 1.4.23
Severity: important
While implementing the new emacs policy in gettext-el I noticed there
are at least two bugs in this line
ln -s ../../emacs/site-lisp/foo/$el .
from sample-package-install-foo.gz.
One: If we are in ${elc_dir}, then we need ../../.. before entering
emacs/site-lisp, not just ../...
Second: Upgrading both an emacs flavour and foo-el results in such
ln -s trying to create a symlink where there is already one created,
making the package configure to fail. The simple fix is to use
ln -sf instead of ln -s. See Bug#671353 for details.
To summarize, please change the above line to this:
ln -sf ../../../emacs/site-lisp/foo/$el .
Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671257: gettext: msgfmt output format prevents multiarch migration
On Sun, 6 May 2012, Steve Langasek wrote: On Wed, May 02, 2012 at 10:23:41PM +0200, Santiago Vila wrote: I think including .mo files in a library package is wrong by itself, with or without multiarch, because the next sonme bump will force the new library package to conflict the old one, which is contrary to the general design of libraries where you are normally allowed to install as many different versions of a library as you need without conflicts. As a counterexample, please see the apt library packages: $ dpkg -L libapt-inst1.3 | grep 'es.*\.mo' /usr/share/locale/es/LC_MESSAGES/libapt-inst1.3.mo Aha! That's it. Different gettext domains for different sonames so that you can install several library packages simultaneously. I believe this should be codified in debian-policy somewhere. Would you second a proposal for that? You can't safely assume that libraries of different sonames can share the same messages anyway; if a new version of the library has dropped a certain string, and the old version of the library is still installed, trying to share the .mo file would mean the old string is untranslated. Yes, I fully agree. I think this is the correct way to handle translations for libraries in nearly all cases, and libc is an exception because of the extraordinary committment to never change the ABI. So yes, keeping the .mo files in the shared library package is otherwise sensible, and it would be preferable to avoid splitting out a -common package just for the translations. Ok, I agree. Library packages may contain .mo files *if done right* (i.e. different gettext domains for different sonames). I am now convinced that this is the way to go. Unless there are objections, I will apply this patch in the next gettext upload: --- a/gettext-tools/src/msgfmt.c +++ b/gettext-tools/src/msgfmt.c @@ -208,6 +208,9 @@ /* Set default value for global variables. */ alignment = DEFAULT_OUTPUT_ALIGNMENT; + /* Changed by Debian: Default is little-endian, not native */ + byteswap = ENDIANNESS; + /* Set program name for messages. */ set_program_name (argv[0]); error_print_progname = maybe_print_progname; -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645518: Source package diffutils-doc is now obsolete
Package: ftp.debian.org I'm not sure if this would be done automatically or not. In either case, here is an explanation in case manual intervention is needed. The source package diffutils-doc is obsolete and may/should be removed from unstable, as the binary package diffutils-doc is now generated from the diffutils source package (as of version 1:3.2). This move is the result of a license relaxation in the manual for upstream diffutils. Previously it was GFDL with front-cover and back-cover texts, which was not dfsg-free, so diffutils-doc was generated from a forked source which was still dfsg-free and contained only the manual in texinfo format. Thanks a lot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514893: cmp: please allow comparing multiple files (fwd)
Hello. A long time ago, I received this from the Debian bug system. [ I realize that this is unlikely to be implemented, but I am supposed to forward upstream bugs upstream in either case ]. Thanks. -- Forwarded message -- From: Michael Stransky qmysjwxb8zhc...@temporaryinbox.com To: Debian Bug Tracking System sub...@bugs.debian.org Date: Wed, 11 Feb 2009 19:26:52 +0100 Subject: cmp: please allow comparing multiple files Package: diff Version: 2.8.1-11 Severity: wishlist It would be great if cmp could handle more then 2 files. cmp -c file1 file2 file3 would output for example: (byte file1 file2 file3) 1 100 101 102 2 100 100 101 7 100 101 102 cmp: EOF on file2. 9 100 102 cmp: EOF on file3. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553490: wdiff: Does not handle UTF-8 properly (fwd)
Hello. I received this from the Debian bug system. I've checked and the current version (1.0.1) still shows the bug. [ Please keep the Cc: lines when replying, thanks ]. [ Apologies to the submitter for taking so long to process this ] -- Forwarded message -- From: Josh Triplett j...@joshtriplett.org To: Debian Bug Tracking System sub...@bugs.debian.org Date: Sat, 31 Oct 2009 11:39:08 -0700 Subject: wdiff: Does not handle UTF-8 properly Package: wdiff Version: 0.5-19 Severity: normal wdiff -a uses backspace and overstrike to provide emphasis; thus, it will emphasize 'x' by printing 'x^Hx'. When it encounters a UTF-8 character, it does this for each byte, rather than for each character; thus, emphasis of E28099 (U+2019 RIGHT SINGLE QUOTATION MARK) looks like 'E2^HE280^H8099^H99', when it should look like 'E28099^HE28099'. - Josh Triplett [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646072: dialog: 'Segmentation fault' after '--inputbox'
On Fri, 21 Oct 2011, Thomas Dickey wrote: On Thu, 20 Oct 2011, A. Costa wrote: Package: dialog Version: 1.1-20111018-1 Severity: important Today after upgrading 'dialog' I find an often used several year old script (that uses 'dialog') has broken. Run the following line, then hit 'Enter', or mouse click on either OK or Cancel: % dialog --inputbox Edit subject line... 6 75 foo bar ; echo $? Segmentation fault 139 I think this is fixed in 20111020 Yes, I've checked and the segfault no longer happens, so I've closed this bug in the 20111020 upload I've just made. (However, I have not looked at the code, so I don't know why it segfaulted, and I don't know why it no longer does. I leave this to you :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#468209: msgfmt: no documentation of the --endianness option
El 03/11/11 16:24, Jakub Wilk escribió:
* Santiago Vila sanv...@unex.es, 2008-02-28, 12:10:
msgfmt does support --endianness {big|little} from the source in
gettext-tools/src/msgfmt.c
neil@dwarf:po$ file messages.mo
messages.mo: GNU message catalog (little endian), revision 0, 14
messages
neil@dwarf:po$ msgfmt --endianness big cs.po
neil@dwarf:po$ file messages.mo
messages.mo: GNU message catalog (big endian), revision 0, 14 messages
neil@dwarf:po$
Please document this in the manpage and ask upstream if it can also
be output in the --help output.
(endianness is important when crossbuilding packages containing PO
files.)
No, it is not. Binary .mo files as used by libc and gettext are always
little endian, regardless of the machine architecture.
Hmm, this doesn't seem to be the case (anymore?). As far as I can see,
msgfmt produces files with native endianness.
I didn't know but yes, that seems to be the case now. I've just checked
by running file * on a locale directory in my old powerpc.
With the advent of multi-arch, such behavior has become a problem. If a
package is marked as Multi-Arch: same all the files (including *.mo)
have to be identical across all architectures.
Hmm, why do they have to be identical?
It is not enough that both types of systems (big and little endian) are
able to read and use both types of .mo files, as it seems to be the case?
If .mo files are useable everywhere, regardless of their endianess, I
would say that the multi-arch requirement is not reasonable.
Either the --endianness option should be documented (so that M-A:same
packages could use when needed), or msgfmt should produce little-endian
files even on big-endian architectures. Please tell if I should reopen
this bug, or rather file a new one requesting using little-endian
everywhere.
I would prefer a new bug because the rationale for considering it as a
bug would be quite different. Previously it was said about performance
reasons, but figures about that never were shown.
However, I'm happy to discuss about this in this old report first, at
least until I really understand the nature of the new bug.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675731: base-files: Please add VERSION entry to /etc/os-release for unstable/testing too
El 02/11/12 22:15, Luca Capello escribió: If I read the os-release manpage correctly, Jeremy is right and VERSION is the place where 'wheezy' should be: http://www.freedesktop.org/software/systemd/man/os-release.html The same manpage says this: Note that operating system vendors may choose not to provide version information, for example to accommodate for rolling releases. In this case VERSION and VERSION_ID may be unset. And also: Applications should not rely on these fields to be set. Because of the above, I think this can't never be a bug in base-files which makes others packages to fail. Instead, those packages who fail should be fixed. Introducing a VERSION when there is only a codename would make all those bugs to be hidden and unfixed. Please also note that the current behavior is inconsistent WRT /etc/debian_version, which has either the version number when on stable or the codename when (in the form $NEXT_STABLE/sid). Do you suggest that /etc/debian_version is removed in testing? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675731: base-files: Please add VERSION entry to /etc/os-release for unstable/testing too
El 02/11/12 22:15, Luca Capello escribió: * squeeze NAME=Debian GNU/Linux VERSION=6.0.6 (squeeze) VERSION_ID=6.0.6 PRETTY_NAME=$NAME $VERSION Well, since it's about time, I would be happy to upload now the base-files version saying 7.0. Then people who write scripts that assume the user is running a stable version may easily test how their scripts will behave when wheezy becomes stable. But IMHO, this should not be an excuse to write scripts that *only* work on stable releases. In fact, it would be much better if scripts that may do things in different ways according to the OS version do things in a way or in another way because of detected features, not because of a certain OS version, i.e. something like autoconf/configure. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672364: libcairo2: an extreme slowdown for text-drawing operations
I can't reproduce this anymore on wheezy as of today (at least on my computer at work), but I don't know why, as the system still has libcairo2_1.12.2-2. Workaround in another package? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646034: Please split libgettextpo0 out for multiarch
On Thu, 20 Oct 2011, Steve Langasek wrote: Package: gettext Version: 0.18.1.1-5 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu precise ubuntu-patch Hi Santiago! Because wine in Ubuntu has gettext support via libgettextpo0, and wine is a target for multiarch for this Ubuntu cycle, I've applied the attached patch to gettext in Ubuntu to split the library out into its own package so that it's possible to install the i386 and amd64 versions alongside one another. Ideally we would have something similar for libasprintf in gettext-base; however, nothing outside of gettext is using libasprintf in the archive, so that's a low priority. For that matter, libgettextpo0 may be a low priority for Debian as well, since the wine package in Debian doesn't seem to use this library. This may be something that will be enabled in a later upstream version of wine. Will be considered for the next upload (whenever it will be). I will probably use Debian versions for the versioned dependencies, as I prefer not to track Ubuntu releases there, but other than that, the patch will surely be used almost entirely. Will probably consider also splitting libasprintf so that multi-arch stuff is really over and I don't have to worry about it anymore. Thanks a lot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#468209: msgfmt: no documentation of the --endianness option
El 10/11/11 12:34, Jakub Wilk escribió: * Santiago Vila sanv...@unex.es, 2011-11-03, 18:38: With the advent of multi-arch, such behavior has become a problem. If a package is marked as Multi-Arch: same all the files (including *.mo) have to be identical across all architectures. Hmm, why do they have to be identical? It is not enough that both types of systems (big and little endian) are able to read and use both types of .mo files, as it seems to be the case? If .mo files are useable everywhere, regardless of their endianess, I would say that the multi-arch requirement is not reasonable. Multi-Arch: same makes it possible for users to install a package for more than one architecture at the same time. If files with same name are not identical across architectures, package manager has to resolve the conflict somehow, and it does it by simply aborting the installation, e.g. like that: | # apt-get install -qq libavahi-common-data:powerpc | (Reading database ... 59644 files and directories currently installed.) | Unpacking libavahi-common-data:powerpc (from .../libavahi-common-data_0.6.30-5_powerpc.deb) ... | dpkg: error processing /var/cache/apt/archives/libavahi-common-data_0.6.30-5_powerpc.deb (--unpack): | './usr/share/locale/he/LC_MESSAGES/avahi.mo' is different from the same file on the system | configured to not write apport reports | dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) | Errors were encountered while processing: | /var/cache/apt/archives/libavahi-common-data_0.6.30-5_powerpc.deb | E: Sub-process /usr/bin/dpkg returned an error code (1) Does it make things clear? Yes, I now see what the problem is, but I don't see that making every .mo file to be always little endian again is the best solution. We could also tell dpkg somehow that different files in /usr/share/locale are ok in this case. Note that the problem would affect only tiny minority of packages: Multi-Arch: same is useful mainly for shared libraries and they rarely come with translations. In such case, making those packages to depend on another Arch: all package containing just the translations would solve the issue, would it not? (For the record, I happen to maintain a library containing translations, and I have always seen it as an anomaly, this would force me to do what I feel is the right thing). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683560: unblock: base-files/6.11
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package base-files This release should ideally reach testing at the same time as initscripts 2.88dsf-29 (source: sysvinit) which is now 9 days old (because of differences in the way /etc/motd is handled). I filed dummy Bug #678106 to prevent inclusion in testing, but the freeze exception has expired, so closing the bug would not work anymore. If you can do that base-files 6.11 and sysvinit 2.88dsf-29 enter testing at exactly the same time, even better (maybe by blocking sysvinit now, and unblocking base-files and sysvinit tomorrow). It is ok if you close Bug #678106 yourself as a way to achieve this. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Mon, 24 Sep 2012, Wookey wrote: Santiago, have you reached an opinion on whether you'd prefer to 1) split the gettext package into an MA:same libgettext-dev part and an MA:foreign gettext part (and change corresponding dependencies), or 2) mark it MA:allowed and change all the dependencies that only need the build-tool part to 'gettext:any' ? I think splitting is probably the best option here, following Steve's advice: Steve Langasek wrote: You could split the packages and put the issue to bed once and for all The thing I don't like about the proposed patch is that it creates a single new package which is really the combination of two different -dev packages. So my plan would be to split it the right way, by creating two additional packages: libasprintf-dev and libgettextpo-dev. We would then drop the Provides: in gettext, we would not have to add them anywhere, and it would be clear that those names are the right ones to be put in a build-depends. [ This is what I had in mind, but since we are in a freeze I had this issue postponed. Sorry for the late reply ]. Does this help? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688804: m4 can accidentally link to libsigsegv
Hi. [ Cc: debian-release for advice ]. I have received this report which is really two different bugs: A) The initial one reported by Igor: Building m4 creates a package linked with libsigsegv or not depending on the environment. This should never happen in a Debian package and that's why we have Build-Depends, Build-Conflicts and so on. A Debian package, when built, should always create the same .deb. B) The real fix by Eric: m4 should really be linked against libsigsegv. Release managers: Is it too late in the freeze to fix B? (The patch would be very small, it would be a matter of adding a Build-Depends). In case it is too late: May I fix bug A in wheezy at least? (In this case the .deb would not change in functionality, but the build process would never create a different .deb by accident). Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693423: base-files: Packaging rules do not work well enough for derivatives
On Fri, 16 Nov 2012, Raphaël Hertzog wrote: Package: base-files Version: 6.12 Severity: normal Hi Santiago, I forked base-files for a derivative and I added a file to origins/ because that's what I'm supposed to do... the resulting package has a lintian errors: E: base-files: file-in-etc-not-marked-as-conffile etc/dpkg/origins/kali W: base-files: file-missing-in-md5sums etc/dpkg/origins/kali That would be really only one, because fixing the first one would probably fix the other as well. This is because the list of conffiles is hardcoded in debian/conffiles while the norm is to let dh_installdeb generate that file. The debian/* directory is clearly hand-made. If you are going to fork a package, you should naturally take in account the way it's made, regardless of what we might call the norm. As the package does not use any helper package, it follows that you have to update debian/conffiles by hand. I don't really understand why you haven't modernized the rules with debhelper... The list of conffiles in base-files does not change often enough. Maybe this is the first non-debhelper package you have had to fork in a long time, and I'm sorry that you had to remember to modify debian/conffiles for this time, but I don't think it's fair to report package foo does not use debhelper (which is what this report essentially boils down to) as a bug, unless you are also willing to report several hundred more bugs like that. May I close this bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693427: base-files: does not update lsb-release
The submitter will probably have to read the reply from the BTS web page. The mail system hramr...@centrum.cz: host xmx2.centrum.cz[46.255.224.55] said: 550 #5.1.0 Address rejected. (in reply to RCPT TO command) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693823: Add multiarch metadata
El 20/11/12 19:16, Wookey escribió: Multi-Arch: foreign Ok. Will be done in the next upload. I'm curious: How many packages have indent in their build-depends? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
El 21/11/12 18:31, Colin Watson escribió: I would say that only things tightly associated with libasprintf and libgettextpo - so autosprintf.h / gettext-po.h respectively plus the corresponding .a/.so - should go in the -dev package. Everything else (and in particular everything under /usr/share/aclocal/ and /usr/share/gettext/) should stay exactly where it is, in the main gettext package; it's generally only intended for being copied into people's source packages by various tools. Yes, that's what I believe as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Fri, 23 Nov 2012, Colin Watson wrote: It also occurred to me that gettext should depend on libasprintf-dev and libgettextpo-dev, otherwise anything that Build-Depends on gettext expecting to be able to use one of those libraries will immediately FTBFS. Perhaps it will be possible to get rid of this dependency later after a migration period, as in some ways it's a bit odd for gettext to suck in development libraries. I also thought about that, but the names of the new packages have been in gettext Provides for a long time, which means any package which fails to build properly because of this split was already buggy in the first place. Moreover, somebody in this same thread, if I remember will, did a check and found that there were no packages affected, so my preference would be to not add those Depends if they are not necessary for our own packages. I've confirmed that these -dev packages are multiarch-coinstallable, which is good. There is one remaining niggle here: while /usr/share/info/autosprintf.info.gz is currently identical across architectures, it starts with a line containing produced by makeinfo version 4.13. That means that if gettext ever happens to be built when texinfo is at different upstream versions on different architectures, the results will not be multiarch-coinstallable. I think this is a bit of a timebomb and we should avoid it. Perhaps it would make sense to leave that info documentation in the gettext package, and add a Suggests: gettext in libasprintf-dev? (We could move it to gettext-doc instead, but that seems like fairly pointless deckchair-rearrangement to me.) I'd like to get this into Ubuntu as soon as possible to replace our current Multi-Arch: allowed hack in sufficient time to undo all the build-dependencies we've accumulated on gettext:any. Do you think it might be possible to have this patch applied in experimental, or should we apply it ourselves once we've agreed on package names and contents? Perhaps we should probably do the split in Debian unstable, as multiarch is a release goal for wheezy. Are splits already forbidden in unstable? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Thu, 9 Aug 2012, P. J. McDermott wrote: I wonder if the gettext binary package should instead be split. Perhaps gettext-runtime (M-A: same) should provide the libraries, gettext-tools (M-A: foreign) should provide the tools, and gettext should be a metapackage that depends on both of the former packages? Please note that the Debian gettext source package currently in wheezy/sid generates all the following binary packages: gettext-base gettext gettext-el gettext-doc autopoint libgettextpo0 libasprintf0c2 Moreover, all the libraries which are meant to be used by other packages are already multi-arched and they are in their own package (the last two in the list above). So: What exactly did you mean by split? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Tue, 14 Aug 2012, P. J. McDermott wrote: So there appear to be three ways to make gettext capable of satisfying cross build dependencies of packages such as those Johannes listed: 1. Mark gettext Multi-Arch: allowed. All depending packages that are to be cross built will need to depend on gettext:any. 2. Split the remaining libraries out of gettext (my original proposed solution). Mark gettext Multi-Arch: foreign and the new libraries package(s) Multi-Arch: same. 3. Remove the aforementioned symbolic links and declare the libraries in gettext for internal use only (as is libbfd-2.22-system.so in binutils, for example). The libraries in gettext are certainly for internal use only. This is reflected by lack of shlibs files for them, and it's also documented in /usr/share/lintian/overrides/gettext (not that this is a good place to document things, but certainly it is not a secret). So I would go for option 3, for simplicity, at least for now. Question: In this case we should still add Multi-Arch: foreign to gettect, right? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Tue, 14 Aug 2012, Steve Langasek wrote: against the libs, are shipped in the 'gettext' binary package; when cross-building a package that build-depends on gettext, we have to know whether they're using the tools or the libraries. Please note that if they are using the libraries, they should build-depend on libasprintf-dev and/or libgettextpo-dev, currently provided by gettext, not on gettext itself. Build-depending on gettext instead of libasprintf-dev and/or libgettextpo-dev if the build-depends is really for the libraries should be a bug. Now the question: Do libasprintf-dev and libgettextpo-dev really need to be in a different package than gettext? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675979: dpkg-dev: dpkg-buildpackage does not always support building twice in a row
Package: dpkg-dev Version: 1.16.3 Severity: important If I untar the orig.tar.gz by hand, then copy the debian/* files and then invoke dpkg-buildpackage, dpkg-buildpackage realizes that the patches need to be applied first, so it applies them and then the package is built. This is ok so far. The problem is that at the same time, dpkg-buildpackage seems to unapply the patches *after* building the package, when the source tree is full of executables, objects, Makefiles and so on. This is when a disaster might happen, as some of the patches might be required so that the clean target works properly. As a result, building the package twice in a row by invoking dpkg-buildpackage twice fails. So, IMHO, one of the following things should be done: * The feature of applying the patches automatically when they are detected not to be applied yet is removed completely, as it is not well supported. * dpkg-buildpackage should not unapply the patches on a built tree, by doing so the tree might become un-cleanable. I discovered this while converting the recode package to dh. There is a huge patch which updates all the libtool stuff. If the patches are unapplied after the build, make distclean tries to recreate the Makefiles by running config.status --recheck, which in turn fails with this funny error: checking build system type... Invalid configuration `x86_64-linux-gnu': machine `x86_64' not recognized as config.sub and config.guess have been reverted back to the stone age (!). To summarize: IMHO, unapplying patches after the build is fundamentally wrong, the fact that they had to be applied before the build is not a reason good enough to unapply them after the build. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675979: dpkg-buildpackage does not always support building twice in a row
On Mon, 4 Jun 2012, Jonathan Nieder wrote: Hi Santiago, Santiago Vila wrote: The problem is that at the same time, dpkg-buildpackage seems to unapply the patches *after* building the package, when the source tree is full of executables, objects, Makefiles and so on. This is when a disaster might happen, as some of the patches might be required so that the clean target works properly. As a result, building the package twice in a row by invoking dpkg-buildpackage twice fails. Can you give an example? I would think that the second dpkg-buildpackage would apply patches again, so in principle I don't see how this would break. You are right, I had not tried that. The second dpkg-buildpackage would indeed realize that the patches are not applied and it would apply them. However, what I was trying over and over again was this: dpkg-buildpackage debian/rules clean dpkg-buildpackage This is what it does not work, and I think it should. It could be argued that the possible states of a package may be thought as being in a stack: A. Unpackaged with patches not applied. B. Unpackaged with patches applied and clean tree. C. Unpackaged with patches applied and built. The state built with patches unapplied is neither A nor B nor C, so it does not fit in the stack easily. Im fact, it is a dead end: if you want to go to C, you would reapply the patches, which is easy, but if you want to go to B, you would have to reapply the patches as well before doing the clean, as not doing so might result in a disaster. So: how it is useful at all that the patches are unapplied, then, if whatever other usual state that you want to go should start by reapplying the patches? I see it as an inconsistent state which does not make any sense. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675979: dpkg-buildpackage does not always support building twice in a row
On Mon, 4 Jun 2012, Jonathan Nieder wrote: Santiago Vila wrote: You are right, I had not tried that. The second dpkg-buildpackage would indeed realize that the patches are not applied and it would apply them. However, what I was trying over and over again was this: dpkg-buildpackage debian/rules clean dpkg-buildpackage Thanks again for explaining, and sorry for the ramble. I think this is a duplicate of one of the two following bugs: #643043 dpkg-buildpackage: --no-unapply-patches to keep patches applied #649531 dpkg-buildpackage -T: manpage should explain need to run dpkg-source --before-build first Do you agree? They are basically the same, yes. Unfortunately, none of the previous submitters seem to have succeeded at convincing you the maintainers that this default behaviour is suboptimal and inconsistent. So, I wish this report not to be considered just a duplicate. Quote from #643043: [The current behaviour] causes a problem where the clean rules of the upstream makefile have been patched to ensure that the clean works. This is exactly my claim, but in that bug it's suggested to use -tc and the following objection is not addressed: Well -tc option certainly works and will sometimes be what I want. What however happens when I want to inspect the debian/package directories? Bug #649531 is also very similar. The submitter says it just wastes my time, which is exactly the feeling I have. In fact, I fully agree with this from such report: For that reason I believe if dpkg-source wants to unapply patches, `debian/rules clean' should be run before. But in such a case it shouldn't automatically unapply anything. This matches completely my idea that the states of a package are in a stack: If the patches have to be unapplied at all, it should only be done after a clean. I'll try to reply to your earlier message: As far as I can tell, most people starting from the patches-unapplied state keep that form in version control. If the build does not involve modifying any source files (the usual case), they can use usual commands like vcs diff and vcs commit when done --- that is, dpkg-buildpackage returns the package to a normal state. If dpkg left patches applied, we would get complaints that, after running debian/rules clean by hand, the source tree is not clean and ready to be committed. Hmm, why do you say that the usual case does not involve modifying any source files? Creating new patches in debian/patches is one of the maintainer's tasks. If the patches are unapplied after a build, this task becomes a lot more complex than it should be. Even in Bug #649531 you say this: In dpkg's source format v3, the patched source is considered to be standard unpacked form. So if you run dpkg-source -x foo.dsc cd foo-* dpkg-buildpackage; # just builds the package then patches will be applied in the first step and never unapplied. So, consider the following flow: (A) === (B) === (C) | (D) I want to reach C, which is package with patches applied and built. If my starting point is B, package with patches applied and not built, dpkg-buildpackage just builds the package and does not do anything else. If my starting point is A, package with patches unapplied and not built, dpkg-buildpackage is right to think package is not in standard form let's move from (A) to (B). However, I still want to reach (C), not a dead end state like (D). It's nice from dpkg-buildpackage that it moves from (A) to (B) automatically, but this move is really unsupported and useless if it *also* moves from (C) to (D) after the build. Because move from (A) to (B) is not properly supported, for the purposes of not making a lot of people to waste a lot of time (which is what happened to me), I would have preferred that dpkg-buildpackage just stops with an error if I try to invoke it with pacthes unapplied. But of course it would be a pity to remove a useful feature, and I still think that it would be much better to keep the patches applied after a build, as that's what we consider the canonical form in dpkg v3. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675979: dpkg-buildpackage does not always support building twice in a row
On Mon, 4 Jun 2012, Jonathan Nieder wrote: Can you give an example? I uploaded recode 3.6-19 yesterday, the package I was working on. If you want to have some fun, ensure you have unstable in a deb-src source line and try this: apt-get -d source recode tar xzvf recode_3.6.orig.tar.gz cd recode-3.6 tar xzvf ../recode_3.6-19.debian.tar.gz dpkg-buildpackage -uc -us debian/rules clean === real fun -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664270: FTCBFS: calls wrong-arch strip when crossbuilding
El 16/03/12 20:14, Wookey escribió: Package: diffutils Version: 1:3.2-2 Severity: normal Tags: patch As part of a general goal of making Debian bootstrappable we are ensuring that the base system cross-builds properly. When cross-built using sbuild --host=arch or plain dpkg-buildpackage -aarch diffutils calls the wrong strip so the build fails right at the end. This patch fixes that. Thanks for the report. I remember a similar problem with another package. I suppose this would not happen if diffutils used dh. Considering that a lot of packages use debhelper, is it right to think that adding debhelper to Build-Depends does not make it less bootstrappable? (I'm considering a switch). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656268: Please enabled hardened build flags
On Tue, 17 Jan 2012, Moritz Muehlenhoff wrote: Package: unzip Version: 6.0-5 Severity: important Tags: patch Please enabled hardened build flags through dpkg-buildflags. Patch attached. (dpkg-buildflags abides noopt from DEB_BUILD_OPTIONS) I had to disable format string checking using DEB_BUILD_MAINT_OPTIONS=hardening=-format. The errors exposed are weird, it would be nice if you can clean these up as well. Thanks a lot for the report. I am now reading about dpkg-buildflags and friends. Will probably update hello, then diffutils and then this one. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599266: wdiff: Word context (fwd)
Hello. Received this from the Debian BTS. [ Please drop only the -forwarded address when replying ]. Thanks. -- Forwarded message -- From: Joachim Breitner nome...@debian.org To: Debian Bug Tracking System sub...@bugs.debian.org Date: Wed, 06 Oct 2010 11:46:33 +0200 Subject: wdiff: Word context Package: wdiff Version: 0.6.3-1 Severity: wishlist File: /usr/bin/wdiff Hi, wdiff is great, but I don’t like that it always prints the whole document, even if just a few words were changed. I avoid this problem somewhat by using diff -U 0 | wdiff -d, so that only changed lines are printed. But with my documents (LaTeX files), this is often still too much. I’d like to see an option to wdiff that makes it print the changed words with a context measured in words, e.g. the 5 words before and after the change – similar to diff’s -u option. Thanks, Joachim [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650792: excess spaces in wdiff of column-based files (fwd)
Hello.
I received this from the Debian BTS (this is the last one for now).
I've checked and wdiff 1.1.0 still behaves the same.
Thanks.
-- Forwarded message --
From: Alan Curry pac...@kosh.dhis.org
To: Debian Bug Tracking System sub...@bugs.debian.org
Date: Fri, 02 Dec 2011 23:47:33 -0500
Subject: Bug#650792: excess spaces in wdiff of column-based files
Resent-Sender: Santiago Vila sanv...@master.debian.org
Package: wdiff
Version: 0.6.3-1
Severity: normal
Tags: upstream
wdiff produces some strange-looking output when comparing text aligned in
columns.
$ cat file1
A B
AAB
AAA B
B
A B
AAB
AAA B
B
A B
$ cat file2
A C
AAC
AAA C
C
A C
AAC
AAA C
C
A C
$ wdiff file1 file2
A [-B-] {+C+}
AA[-B-]{+C+}
AAA [-B-] {+C+}
[-B-] {+C+}
A [-B-] {+C+}
AA[-B-]{+C+}
AAA [-B-] {+C+}
[-B-] {+C+}
A [-B-] {+C+}
$
I can't think of any reasoning that supports the need for multiple spaces
after the [-B-], since the actual spaces in the input file are only to the
left of the B.
[...]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#468209: Towards multi-arch: Multi-Arch: same file conflicts
On Fri, 25 Nov 2011, Steve Langasek wrote: No, having to split this data out into separate packages is a significant cost for maintainers and on the archive and simply the wrong way to do it. Automatic package splits for the likes of tdebs are fine, but we should not be forced to split binary packages in the archive for data files such as .mo files that could readily be made architecture-independent. Ok, I'm not 100% convinced, but after reading this, I'm willing to ask gettext authors that they make little-endian the default again, or at least they tell me how we could achieve that (configure options, environment variables, whatever). Steve: Could you please report this as a *new* bug and summarize the problems that native endianness in gettext create to multi-arch? (I would prefer to keep this issue as a different one from the old bug). A Subject like msgfmt creates mo files in native endianness would be fine. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
