Bug#868040: O: louie -- Python signal dispatching mechanism
Package: wnpp Hi, louie used to be required by another package but should now be ok to remove from the archive unless someone wants to adopt it. Best, -- Loïc Minier
Bug#204975: [debhelper-devel] Bug#204975: [Build-common-hackers] Bug#204975: cdbs: postrm and postinst have useless call to ldconfig
> Le 2 oct. 2016 à 14:25, Niels Thykier <ni...@thykier.net> a écrit : > As for using a path trigger, I believe that was ruled out as they are > recursive. The libc-bin package would have to declare an interest in > *all* of /usr/lib, which will generate tons of false-positives. I > suspect it may also be a bit heavy on the dpkg side. Indeed, it seems one has to specify a dir or specific file and one can not use a regexp. https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/doc/triggers.txt <https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/doc/triggers.txt> - Loïc Minier
Bug#204975: [Build-common-hackers] Bug#204975: cdbs: postrm and postinst have useless call to ldconfig
Hi, Re-reading this bug – filed 12 years ago – I have to agree with Joey Hess (and I find my own tone from 12 years ago pretty bad, sorry about that!): it’s not a good idea to rely on the contents of /etc/ld.so.conf. It’s less big a deal than it used to be because of /etc/ld.so.conf.d/* which is where other packages would change the search path, but it’s still an issue because an admin might have changed the local config and this will affect package builds. > Le 30 sept. 2016 à 02:42, Olly Betts <o...@survex.com> a écrit : > $ /sbin/ldconfig -N -X -v -f /dev/null 2>/dev/null|sed 's,^\(/.*\):\( > (.*)\)\?$,\1,p;d’ This approach looks very good to me; here’s perhaps a lighter sed: sed -n '/^\//s#:$##p’ (match lines leading with slash, remove trailing colon and print them) However it might be worth bringing this discussion to Debian Policy as this currently said that /etc/ld.so.conf contents must be used. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig <https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig> Another perhaps smarter approach would be to do away with postinst requirements entirely by installing a ldconfig file-based trigger in libc for *.so files under interesting directories. This would let libc define when to run libc’s ldconfig rather than having each shared library package carry a build-time and install time snippet… Cheers, - Loïc Minier
Bug#452049: Fwd: Problem with debian vlan package
Cc:ing bug > From: Loïc Minier <loic.min...@dooz.org <mailto:loic.min...@dooz.org>> > Subject: Re : Problem with debian vlan package > Date: 16 mai 2016 22:20:25 UTC+2 > To: Ryan Castellucci <ryan.castellu...@gmail.com > <mailto:ryan.castellu...@gmail.com>> > Cc: Ard van Breemen <a...@kwaak.net <mailto:a...@kwaak.net>>, l...@debian.org > <mailto:l...@debian.org> > > Hi folks, > > And sorry for the delay, was travelling for work last week. (I’m back to my > regular TZ but still jet lagged :-) > > NB: This is an old bug (2007) and the patch in git and revert themselves are > old (2010), so I might not recollect this correctly. > > IIRC, multiple non-trivial changes were landed in git by Arnd, and I couldn’t > easily make sense of all of them. I had to prepare an upload for whatever > reason and I reverted them in git: > http://anonscm.debian.org/cgit/collab-maint/vlan.git/commit/?id=3eed5b7482eb7952425b7455445df22419346047 > > <http://anonscm.debian.org/cgit/collab-maint/vlan.git/commit/?id=3eed5b7482eb7952425b7455445df22419346047> > Thinking it would be easy to fish them out of Git for future uploads. > > If you’d like me to reconsider the whole changes or just the minimal diff for > this bug, I’d be happy to reconsider them one by one; I can’t reapply the > whole revert though, it’s too much for me to review in one go. > > Ideally, we should have some tests along the package to make sure we don’t > introduce any regression. > > Cheers, > - Loïc > >> Le 16 mai 2016 à 21:47, Ryan Castellucci <ryan.castellu...@gmail.com >> <mailto:ryan.castellu...@gmail.com>> a écrit : >> >> Loïc, >> >> What do we need to do to get the fix merged? >> >> On Fri, May 6, 2016 at 1:57 PM, Ryan Castellucci <ryan.castellu...@gmail.com >> <mailto:ryan.castellu...@gmail.com>> wrote: >> Looks like Loïc Minier did the revert. >> >> Loïc, what's the deal here? >> >> Thanks, >> Ryan >> >> On Fri, May 6, 2016 at 2:59 PM, Ard van Breemen <a...@kwaak.net >> <mailto:a...@kwaak.net>> wrote: >> Hi, >> >> Ryan Castellucci schreef op 2016-05-05 22:36: >> Hello, >> >> Could you please respond to this bug? >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452049 >> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452049> >> >> The fix provided is trivial and has no downside that I can see to >> accept. >> >> I've fixed that: >> http://anonscm.debian.org/cgit/collab-maint/vlan.git/commit/?id=6372a3daa44852730762385860327581c0dd67fa >> >> <http://anonscm.debian.org/cgit/collab-maint/vlan.git/commit/?id=6372a3daa44852730762385860327581c0dd67fa> >> and: >> http://anonscm.debian.org/cgit/collab-maint/vlan.git/commit/?id=9e87ff83ca1f80987e98b11eabb9b2408fc47cd0 >> >> <http://anonscm.debian.org/cgit/collab-maint/vlan.git/commit/?id=9e87ff83ca1f80987e98b11eabb9b2408fc47cd0> >> >> My fixes got reverted, so I don't know what I can do about it. >> http://anonscm.debian.org/cgit/collab-maint/vlan.git/tree/?id=cd8950c1dbc21200c5d61fa42fa3ed1f9188dae5 >> >> <http://anonscm.debian.org/cgit/collab-maint/vlan.git/tree/?id=cd8950c1dbc21200c5d61fa42fa3ed1f9188dae5> >> is my last official release that hit my own cloud (300+ servers) before it >> got reverted, and I haven't regained control since. >> >> Regards, >> Ard van Breemen >> >> >> >> -- >> Ryan Castellucci https://rya.nc/ <https://rya.nc/> >> >> >> -- >> Ryan Castellucci https://rya.nc/ <https://rya.nc/>
Bug#758728: Use getopt -T to test for GNU getopt
Package: fakeroot Version: 1.20-3 Severity: minor Tags: patch Hi, (Forgot to send this earlier) An user of fakeroot under a Dutch locale reported that fakeroot (and fakeroot using apps) was broken under this locale: https://bugs.launchpad.net/ubuntu/+source/fakeroot/+bug/1290069 This is because the fakeroot wrapper shell script attempts parsing of the gettext --version output. One option would be to set locale to C before parsing version output, but since the goal is to test whether we have GNU getopt, and since there's a special -T flag to test this, this is what the patch does. (See attached debdiff and patch) Cheers, -- Loïc Minier diff -Nru fakeroot-1.20/debian/changelog fakeroot-1.20/debian/changelog --- fakeroot-1.20/debian/changelog 2014-03-24 05:52:53.0 +0100 +++ fakeroot-1.20/debian/changelog 2014-05-20 15:11:19.0 +0200 @@ -1,3 +1,10 @@ +fakeroot (1.20-3ubuntu3) utopic; urgency=medium + + * New patch, getopt-gnu-test, use getopt -T to test for GNU getopt rather +than parsing the --version output which is locale specific; LP: #1290069. + + -- Loïc Minier loic.min...@ubuntu.com Tue, 20 May 2014 15:10:08 +0200 + fakeroot (1.20-3ubuntu2) trusty; urgency=medium * fix-xattr-prototypes.patch: Fix prototypes for xattr functions. diff -Nru fakeroot-1.20/debian/patches/getopt-gnu-test.patch fakeroot-1.20/debian/patches/getopt-gnu-test.patch --- fakeroot-1.20/debian/patches/getopt-gnu-test.patch 1970-01-01 01:00:00.0 +0100 +++ fakeroot-1.20/debian/patches/getopt-gnu-test.patch 2014-05-20 15:09:07.0 +0200 @@ -0,0 +1,24 @@ +Index: fakeroot-1.20/scripts/fakeroot.in +=== +--- fakeroot-1.20.orig/scripts/fakeroot.in fakeroot-1.20/scripts/fakeroot.in +@@ -43,15 +43,12 @@ export FAKED_MODE + + libfound=no + +-GETOPTEST=`getopt --version` +-case $GETOPTEST in +-getopt*) # GNU getopt ++GETOPTTEST=`getopt -T` ++if test $? -eq 4; then # GNU getopt + FAKE_TEMP=`getopt -l lib: -l faked: -l unknown-is-real -l fd-base: -l version -l help -- +l:f:i:s:ub:vh $@` +-;; +-*) # POSIX getopt ? ++else + FAKE_TEMP=`getopt l:f:i:s:ub:vh $@` +-;; +-esac ++fi + + if test $? -ne 0; then + usage diff -Nru fakeroot-1.20/debian/patches/series fakeroot-1.20/debian/patches/series --- fakeroot-1.20/debian/patches/series 2014-03-24 05:53:23.0 +0100 +++ fakeroot-1.20/debian/patches/series 2014-05-20 15:08:55.0 +0200 @@ -2,3 +2,4 @@ Fix-FTBFS powerpc64le-support.patch fix-xattr-prototypes.patch +getopt-gnu-test.patch Index: fakeroot-1.20/scripts/fakeroot.in === --- fakeroot-1.20.orig/scripts/fakeroot.in +++ fakeroot-1.20/scripts/fakeroot.in @@ -43,15 +43,12 @@ export FAKED_MODE libfound=no -GETOPTEST=`getopt --version` -case $GETOPTEST in -getopt*) # GNU getopt +GETOPTTEST=`getopt -T` +if test $? -eq 4; then # GNU getopt FAKE_TEMP=`getopt -l lib: -l faked: -l unknown-is-real -l fd-base: -l version -l help -- +l:f:i:s:ub:vh $@` -;; -*) # POSIX getopt ? +else FAKE_TEMP=`getopt l:f:i:s:ub:vh $@` -;; -esac +fi if test $? -ne 0; then usage
Bug#645692: Support for hard-float calling convention and flag to select the ARM ABI
Hey On Wed, Jan 08, 2014, Thomas Preud'homme wrote: So you'll be happy to hear that support for armhf will be greatly improved in upcoming tcc release (there was quite some bug in the current version). Nice :-) However I still encounter a problem that when both armel and armhf libraries are installed, ldd shows that armel one are used. I tried playing with EABI version (set it from 4 to 5) but then ldd says the file is not a dynamic binary. Interesting; this might be worth raising on debian-arm@; I think there's another ELF header that one has to set to indicate the hard-float variant of EABI; Steve McIntyre had worked on this some while ago. In fact, it would be nice if TCC allowed selection of the ARM ABI it's targetting, e.g. ARMv4...ARMv7, Thumb/ARM mode, OABI vs. EABI, soft VFP / hard VFP / no VFP. You'll also be happy to hear that there is progress on this front. I've just pushed a patch to be able to select the float ABI at runtime. For now it's limited to softfp and hard since soft is not supported now (as you noticed, tcc produces VFP code even on armel). Supporting ARMv4…ARMv7 as well as Thumb/ARM will not be done neither since tcc is not an optimizing compiler. ARMv4 is always used, no matter what. On the other hand I'd like to be able to select the ABI (OABI Vs EABI) at runtime as well but it requires a bit more change as for now this switch relies heavily on macros. Note that OABI is probably not interesting anymore at this point; support for OABI will progressively be removed, so likely not worth targeting in a compiler right now. BTW you mention TCC uses VFP instructions: note that usage of VFP instructions is not equal to ABI; that is, you may use soft-float calling conventions while using VFP instructions between calls. In fact you may even use hard-float calling conventions in a soft-float library / binary as long as you're calling into the same compiled code and not calling into another object. GCC offers these three options to distinguish the use cases: * hardfp: might use VFP depending on optimization levels; always calls functions in other object files with hard-float calling conventions but might call with soft-float calling conventions within the same object * soft: never uses VFP, always calls functions with soft-float calling conventions * softfp: might use VFP, always calls functions in other object files with soft-float calling conventions but might call with hard-float calling conventions within the same object And it allows selecting the VFP level independently. You must realize that the manpower on tcc is quite small so we are limited in what we can add to tcc. I myself have been more versed in bug fixing as they are many. Understood :-) Cheers and happy new year! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645692: Support for hard-float calling convention and flag to select the ARM ABI
On Wed, Jan 08, 2014, Thomas Preud'homme wrote: I know that. Thus -mfloat-abi switch in gcc is both about use of vfp and calling convention for floats. Right now tcc doesn't know how to do software float computation. It only supports FPA and VFP. By the way, is there some product with FPA these days? I know kernel support for it has been removed recently but if no device has FPA unit then this could be removed too. I am not aware of any modern platform with FPA :-) It also seems to be gone since some years and not worth targeting -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718761: flash-kernel: 'root=' kernel param ignored when flash-kernel package is installed
On Sun, Aug 04, 2013, Erik Speckman wrote: If flash-kernel isn't necessary/required on my device, I would expect it to detect that fact rather than rendering my system in an unbootable state. It's probably necessary as on other Kirkwood devices as to generate an uImage / uInitrd. I realize that my system (a ZyXel NSA320 modified to boot debian) isn't particularly common, but I also know that there is a community of people running debain on Kirkwood devices using the same technique, and I doubt I am the only one to think that flash-kernel might be a useful package to have installed. Sure thing; let's figure out your device specifics and add them to the flash-kernel database; could you send your /proc/cpuinfo? I'm a bit surprized that flash-kernel is running at all since it should detect an unsupported machine and bail out. Also do you have a /proc/device-tree/model file? How did you install Debian on the device and what's the expected root device? Cheers -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711759: flash-kernel: FTBFS in test_db due to sorting vs. locale issues
On Sun, Jun 09, 2013, Cyril Brulebois wrote: I think I'll work around it by exporting LC_ALL=C for wheezy (which is affected by a similar issue with the tagged-but-not-uploaded 3.3+deb7u1), at least until a proper fix lands in master. Fetching more changes from master, including the Bootloader-Sets-Root case change, looks way too intrusive for wheezy, and it isn't sufficient anyway. Yeah, I ran into this when preparing the 3.7 upload, but catched it in sbuild; I fixed this in 67e61b9cfa883d3b6ec234c773de1e0b01e48476 by ignoring the case when sorting (and updating the order of fields in the test), isn't that enough in the backport? Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711356: debchange: Allow config overrides in environment
Package: devscripts
Version: 2.13.2
Severity: wishlist
File: /usr/bin/dch
Tags: patch
Hi there!
It would be nice if dch configs could be overriden from the environment
as per attached patch. This would likely be useful in more than my
specfic use case, but here's why I'd like this feature: I work on
Debian, Linaro and Ubuntu packages with Debian, Ubuntu, Linaro and other
hats and from various environments. I have my shell config to set my
git/bzr/dch name and email address as follow:
alias debian='EMAIL=lool-nospam-debian.org BZR_EMAIL=Loïc Minier
$EMAIL'
alias linaro='EMAIL=loic.minier-nospam-linaro.org BZR_EMAIL=Loïc Minier
$EMAIL'
alias ubuntu='EMAIL=loic.minier-nospam-ubuntu.com BZR_EMAIL=Loïc Minier
$EMAIL'
export NAME=Loïc Minier
export EMAIL=lool-nospam-dooz.org
(inserted nospam in place of @)
This alllows me to work with my Debian hat by prefixing commands with
debian:
debian dch -a
debian debcommit
or to switch my shell config to my Linaro hat with:
linaro
dch -a
debcommit
etc.
I'd like to do the same with the DEBCHANGE_VENDOR which is used for
version number heuristics, but currently devscripts only read from
command-line or config files; hence the attached patch to read from the
environment.
Cheers,
--
Loïc Minier
From 87df467c805c156486e69a4e94e2fc35f3161245 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= loic.min...@ubuntu.com
Date: Thu, 6 Jun 2013 16:06:09 +0200
Subject: [PATCH] debchange: Allow config overrides in environment
---
scripts/debchange.pl | 5 +
1 file changed, 5 insertions(+)
diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index 98acd63..684e5b8 100755
--- a/scripts/debchange.pl
+++ b/scripts/debchange.pl
@@ -314,6 +314,11 @@ if (@ARGV and $ARGV[0] =~ /^--no-?conf$/) {
my $shell_out = `/bin/bash -c '$shell_cmd'`;
@config_vars{keys %config_vars} = split /\n/, $shell_out, -1;
+# Allow overrides in the environment
+foreach my $var (keys %config_vars) {
+$config_vars{$var} = $ENV{$var} if $ENV{$var};
+}
+
# Check validity
$config_vars{'DEBCHANGE_PRESERVE'} =~ /^(yes|no)$/
or $config_vars{'DEBCHANGE_PRESERVE'}='no';
--
1.8.3
Bug#693839: debian-installer: kernel install fails on armel buffalo linkstation pro, missing uboot-mkimage
On Wed, Jun 05, 2013, Cyril Brulebois wrote: Maybe we should also perform a .db check at build time, so that any new such items would be spotted early? The following shell snippet seems to do the trick, and could be added to debian/rules, causing non-zero exit in case there are some hits? Yeah, I've pushed a test_db script which currently only tests for unknown fields (case sensitively) Thanks all for the report and patches, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700959: ITP: doxyqml -- QML filter for Doxygen
Package: wnpp Severity: wishlist Owner: Loïc Minier l...@dooz.org * Package name: doxyqml Version : 0.1 Upstream Author : Aurélien Gâteau agat...@kde.org * URL : http://agateau.com/projects/doxyqml * License : BSD-2-clause Programming Lang: Python Description : QML filter for Doxygen Doxyqml is an input filter for Doxygen, a documentation system for C++ and a few other languages. Doxyqml makes it possible to use Doxygen to document QML files. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644912: Confirming
tag 644912 + confirmed stop I confirm the symptoms mentioned in this bug report; after changing my nsswitch.conf from: hosts: files mdns_minimal4 [NOTFOUND=return] dns mdns4 to: hosts: files mdns_minimal [NOTFOUND=return] dns mdns I could witness IPv6 addresses returned by getent hosts foo.local on various hosts on my network. One of the arguments in the past was that IPv6 was uncommon on local networks but at least iOS 6.1, MacOS X 10.6.8 and Windows 8 respond with IPv6 link-local addresses to .local mDNS queries. However a couple of devices from my ISP (router and TV STB) and a HP C5190 printer didn't, which resulted in ~5 seconds timeouts when connecting to them which I hadn't with the IPv4-only setup. This patch shouldn't definitely be (tested, reviewed and) included to fix handling of IPv6 .local addresses, but it's not clear the default should be changed from IPv4-only lookups to IPv4 + IPv6 lookups. Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698845: Mailcap entries use obsolete -no-oosplash
On Fri, Feb 01, 2013, Rene Engelhard wrote: What? It is. $ soffice -no-oosplash I18N: Operating system doesn't support locale en_US starts It isn't anymore in 4.0, yes. (because the need for it is fixed in oosplash itself), but in 3.5 (what you report it against) and 3.6 it *is* there and needed. Have a mixup of stuff and/or a non-Debian soffice? Hmm that's odd; I tested against the 3.6.2~rc2 Ubuntu packages, not 4.0; sorry for that, it seems the flag is being superseded upstream in 3.6 rc2 but apparently not yet in 3.5.4, my bad! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698845: Mailcap entries use obsolete -no-oosplash
On Fri, Feb 01, 2013, Matthijs Kooijman wrote: I tested this patch (by applying it locally to the files in /usr/lib/mime/packages), but it didn't work for me. My libreoffice version (1:3.6.4-1) uses --nologo instead of --no-logo. Perhaps this is a typo in your patch? It is indeed a typo of my patch when I rebased it to the Debian tree In any case, I've attached an updated patch which works for me (generated from your patch using s/--no-logo/--nologo/). Thanks! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698845: Mailcap entries use obsolete -no-oosplash
Package: libreoffice Version: 1:3.5.4+dfsg-4 Severity: minor Tags: patch Hi there, I sometimes open attached word files from emails in Mutt, and that relies on the Mailcap files (/usr/lib/mime/packages/libreoffice-*) to map MIME types to an external viewer command-line. It seems this has been broken for some time as the -no-oosplash flag to soffice isn't accepted anymore. Simply using --no-logo instead seems to work just fine, as per attached patch. Patch was generated with: sed -i 's/-no-oosplash/--no-logo/g' *.mime against 35692d1403358a6a1e9353de3b7f390fcb0c5638. Thanks! NB: I've tested the change against the Ubuntu packages by adding this to my ~/.mailcap: application/msword; soffice --nologo --writer '%s'; edit=soffice --nologo --writer '%s'; test=test -n $DISPLAY; description=Microsoft Word Document; nametemplate=%s.doc; priority=3 -- Loïc Minier diff --git a/libreoffice-base.mime b/libreoffice-base.mime index 9eb7cfd..b7e98e5 100644 --- a/libreoffice-base.mime +++ b/libreoffice-base.mime @@ -2,10 +2,10 @@ # shared-mime-info # OASIS OpenDocument Format -application/vnd.oasis.opendocument.database; soffice -no-oosplash --base '%s'; edit=soffice -no-oosplash --base '%s'; print=soffice -no-oosplash --base -p '%s'; test=test -n $DISPLAY; description=OpenDocument Database; nametemplate=%s.odb; priority=9 +application/vnd.oasis.opendocument.database; soffice --no-logo --base '%s'; edit=soffice --no-logo --base '%s'; print=soffice --no-logo --base -p '%s'; test=test -n $DISPLAY; description=OpenDocument Database; nametemplate=%s.odb; priority=9 # OpenOffice.org 1.0 -application/vnd.sun.xml.base; soffice -no-oosplash --writer '%s'; edit=soffice -no-oosplash --writer '%s'; description=OpenOffice.org Database; nametemplate=%s.sdb; priority=8 +application/vnd.sun.xml.base; soffice --no-logo --writer '%s'; edit=soffice --no-logo --writer '%s'; description=OpenOffice.org Database; nametemplate=%s.sdb; priority=8 # ### diff --git a/libreoffice-calc.mime b/libreoffice-calc.mime index d182907..845015f 100644 --- a/libreoffice-calc.mime +++ b/libreoffice-calc.mime @@ -2,35 +2,35 @@ # shared-mime-info # Generic -text/csv; soffice -no-oosplash --calc '%s'; edit=soffice -no-oosplash --calc '%s'; test=test -n $DISPLAY; description=CSV Document; nametemplate=%s.csv; priority=3 -text/spreadsheet; soffice -no-oosplash --calc '%s'; edit=soffice -no-oosplash --calc '%s'; test=test -n $DISPLAY; description=Spreadsheet Interchange Document; nametemplate=%s.slk; priority=3 +text/csv; soffice --no-logo --calc '%s'; edit=soffice --no-logo --calc '%s'; test=test -n $DISPLAY; description=CSV Document; nametemplate=%s.csv; priority=3 +text/spreadsheet; soffice --no-logo --calc '%s'; edit=soffice --no-logo --calc '%s'; test=test -n $DISPLAY; description=Spreadsheet Interchange Document; nametemplate=%s.slk; priority=3 # Corel Quattro Pro -application/x-quattropro; soffice -no-oosplash --calc '%s'; edit=soffice -no-oosplash --calc '%s'; test=test -n $DISPLAY; description=Quattro Pro 6 for Windows Spreadsheet; nametemplate=%s.wb2; priority=3 +application/x-quattropro; soffice --no-logo --calc '%s'; edit=soffice --no-logo --calc '%s'; test=test -n $DISPLAY; description=Quattro Pro 6 for Windows Spreadsheet; nametemplate=%s.wb2; priority=3 # dBase dBASE -application/x-dbf; soffice -no-oosplash --calc '%s'; edit=soffice -no-oosplash --calc '%s'; test=test -n $DISPLAY; description=xBase Document; nametemplate=%s.dbf; priority=3 +application/x-dbf; soffice --no-logo --calc '%s'; edit=soffice --no-logo --calc '%s'; test=test -n $DISPLAY; description=xBase Document; nametemplate=%s.dbf; priority=3 # ECMA Office Open XML (Microsoft Office 2007) -application/vnd.ms-excel.sheet.macroEnabled.12; soffice -no-oosplash --calc '%s'; edit=soffice -no-oosplash --calc '%s'; test=test -n $DISPLAY; description=Office Open XML Spreadsheet with Macros Enabled; nametemplate=%s.xlsm; priority=3 -application/vnd.ms-excel.template.macroEnabled.12; soffice -no-oosplash --calc '%s'; edit=soffice -no-oosplash --calc '%s'; test=test -n $DISPLAY; description=Office Open XML Spreadsheet Template with Macros Enabled; nametemplate=%s.xltm; priority=3 -application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; soffice -no-oosplash --calc '%s'; edit=soffice -no-oosplash --calc '%s'; test=test -n $DISPLAY; description=Office Open XML Spreadsheet; nametemplate=%s.xlsx; priority=3 -application/vnd.openxmlformats-officedocument.spreadsheetml.template; soffice -no-oosplash --calc '%s'; edit=soffice -no-oosplash --calc '%s'; test=test -n $DISPLAY; description=Office Open XML Spreadsheet Template; nametemplate=%s.xltx; priority=3 +application/vnd.ms-excel.sheet.macroEnabled.12; soffice --no-logo --calc '%s'; edit=soffice --no-logo --calc '%s'; test=test -n $DISPLAY; description=Office Open XML Spreadsheet with Macros Enabled; nametemplate=%s.xlsm; priority=3 +application/vnd.ms-excel.template.macroEnabled.12; soffice
Bug#693040: [libav-devel] Strange build failure on several archs in Debian.
Hey, On Tue, Nov 13, 2012, Reinhard Tartler wrote: In the context of bug #693040, Måns had an unrelated question that I would like to forward to you, as you have tuned the package flavors for arm. (Cc:ing #693040) On Tue, Nov 13, 2012 at 3:23 PM, Måns Rullgård m...@mansr.com wrote: BTW, why are you building armv4+vfp? That makes no sense whatsoever since VFP has never been used with anything prior to armv5, and in practice it is only found with armv6 and later. First some context: Debian and Ubuntu maintain(ed) multiple ARM ports; usually one port per ABI. arm is an obsolete OABI port. Debian and Ubuntu used mainly an armel port for some years which was EABI and soft-float calling conventions, and both now have an increasingly popular armhf port for EABI with hard-float calling conventions. Debian or Ubuntu releases or any distro derivative can pick different toolchain optimization defaults for the armel and armhf ports -- as long as they honor the calling conventions -- so that Debian squeeze or wheezy or Ubuntu lucid or precise can have different levels of optimizations (armv4, armv5, armv6, armv7 etc.). Some even turn VFP on in the armel port (softfp). The Debian/Ubuntu libav packaging ships multiple builds depending on the distro toolchain defaults. If the toolchain doesn't enable VFP by default, then a VFP pass is built; if the toolchain doesn't enable NEON by default, then a NEON pass is built; etc. I guess the libav build you're seeing with armv4 + softfp is the VFP pass for the Debian armel port. It's using the toolchain defaults (armv4 + float-abi=soft) for the main build and turns on VFP (-mfpu=vfp --float-abi=softfp) for the VFP pass. If there's absolutely NO ARMv4 hardware with VFP ever going to run Debian armel and if enabling ARMv5 would greatly benefit the builds, then we could special case this and force -march=armv5 for the vfp pass if the toolchain defaults to armv4. However, if there's some ARMv4 hardware with VFP around, the vfp flavor of libav might get picked up by hwcaps and that will cause SIGILL at runtime if we enable ARMv5 instructions. I'm afraid I have no knowledge of what ARMv4 hardware we still care for in Debian, nor whether there's a hwcap for ARMv5 that we could use here; happy to follow recommendations! Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691258: Missing / in RE for reducing the advertised EDNS UDP packet size
Package: logcheck
Version: 1.3.15
Severity: minor
Tags: patch
Hi,
Got this log from time to time in System Events:
Oct 23 13:48:16 pig2 named[28880]: success resolving
'26.0/25.218.183.203.in-addr.arpa/PTR' (in '0/25.218.183.203.in-addr.arpa'?)
after reducing the advertised EDNS UDP packet size to 512 octets
Changing the regexp for the (in '...'?) part from:
^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]-]+ named\[[0-9]+\]: success
resolving '[^[:space:]]+' \(in '[.[:alnum:]-]+'\?\) after (disabling
EDNS|reducing the advertised EDNS UDP packet size to 512 octets)$
to:
^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]-]+ named\[[0-9]+\]: success
resolving '[^[:space:]]+' \(in '[/.[:alnum:]-]+'\?\) after (disabling
EDNS|reducing the advertised EDNS UDP packet size to 512 octets)$
fixed it (note addition of a /).
Cheers,
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681198: libgtk-3-0: removal of libgtk-3-0 makes files disappear from libgtk-3-common
On Wed, Aug 01, 2012, Michael Biebl wrote: I can't find the original reason in the changelog / svn log anymore, but I *think* it was due to the cache files /etc/gtk-2.0/gdk-pixbuf.loaders and /etc/gtk-2.0/gtk.immodules which have long been moved elsewhere. The relevant bug seems to be [1], Loïc possibly still remembers the details. It seems to me, like we can safely drop those rm -rf calls from postrm. And if not, we should at least move those calls to libgtk2.0-common resp. libgtk-3-common which nowadays contains the config files from /etc. [1] http://bugs.debian.org/388450 This rm -rf is much older than the changes for this bug, I've traced it back in the SVN history to being *older* than 2.4.0-4 (Apr 2004!) It was probably a big hammer to cleanup /etc/gtk-2.0 from generated files like loaders as you suggest; this is probably long obsolete. I suggest removing the rm -rf; the /etc files should all be conffiles at this point; if this causes any issue, we can add a set of more targeted rm-s. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681198: libgtk-3-0: removal of libgtk-3-0 makes files disappear from libgtk-3-common
On Wed, Aug 01, 2012, Michael Biebl wrote: I assume, piuparts only finds leftover files which are generated during install time? Especially for libraries I guess it's a bit tricky if they generate cache or temporary files during runtime. I don't think that's the case here for Gtk+ though What we wont catch with piuparts are leftover files from very old upgrades (e.g. people who have installed gtk+ years ago and have upgraded to new releases) -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570617: Filtering -Wl,-Bsymbolic-functions out of LDFLAGS
Hi, On Mon, Jul 02, 2012, Jakub Wilk wrote: * Loïc Minier l...@dooz.org, 2010-02-20, 10:17: We were copying the package automatically in Ubuntu unmodified and it was failing to build due to Ubuntu changes to dpkg-dev to set LDFLAGS=-Wl,-Bsymbolic-functions by default (in dpkg-buildpackage). dpkg-dev in Debian doesn't set *FLAGS itself anymore. Is this also true in Ubuntu? Is yes, I suppose this bug could be closed. Indeed, this was very recently changed in Ubuntu quantal which now defaults back to not exporting *FLAGS in the environment and hence to make. I don't think it hurts to filter out this flag out of LDFLAGS in case it's present, but it's not going to break the build in the latest Ubuntu release anymore (only in backports). Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657885: ffmpeg: Illegal instruction on dreamplug (arm cpu)
it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabi. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/ffmpeg...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/ffmpeg [Thread debugging using libthread_db enabled] Program received signal SIGILL, Illegal instruction. 0x00018cf8 in ?? () (gdb) disassemble $pc, $pc+0x20 Cannot access memory at address 0x0 Dump of assembler code from 0x18cf8 to 0x18d18: = 0x00018cf8: movwlr, #2011 ; 0x7db 0x00018cfc: ldr r2, [pc, #148] ; 0x18d98 0x00018d00: ldr r4, [pc, #148] ; 0x18d9c 0x00018d04: ldr r12, [r12] 0x00018d08: ldr r3, [r3, r2] 0x00018d0c: add r4, pc, r4 0x00018d10: ldr r2, [pc, #136] ; 0x18da0 0x00018d14: str lr, [sp, #4] End of assembler dump. More system information: Initializing cgroup subsys cpu Linux version 3.1.10 (kelly@bbb.internal) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 PREEMPT Fri Jan 20 10:47:05 MST 2012 CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 CPU: VIVT data cache, VIVT instruction cache Machine: Marvell GuruPlug Reference Board I see. Your machine is not ARMv7 capable, yet, the baseline flavor of libavcodec does seem to use ARMv7 instructions. cf. http://blogs.arm.com/software-enablement/251-how-to-load-constants-in-assembly-for-arm-architecture/ Can you please retrieve a backtrace with libav-dbg installed? I need to know where exactly in the code the offending instruction occurs in order to determine if it's an upstream bug or a configuration issue. Thanks Reinhard -- regards, Reinhard -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667681: Updated patches for Dreamplug / Marvell Kirkwood FDT
On Wed, Jun 20, 2012, Ian Campbell wrote: Are you suggesting that I should move the non-flash-kernel related content of /dev/sdb1 (e.g. vmlinuz, initramfs etc) to /dev/sdb2:/boot and remove sdb1 from the fstab, leaving it unmounted the majority of the time? Exactly; also it should also keep working if you leave your system untouched (if you keep /dev/sdb1 in fstab and if f-k tries to mount it in /tmp to update boot files, it should just get bind-mounted automatically). I'm happy to do that, just want to make sure I understand before I start moving stuff about. Yup; it's also best if you have some recovery mechanism -- like being able to pull the SD card and changing it from another device -- and some debug mechanism -- like serial console over mini-USB. FYI /boot is 205M on this system (I don't recall if I partitioned it, or if the installer did it or if it came that way), so I'm not worried about space constraints (205M is bigger than the whole disk on my last Pentium based firewall machine ;-)). I think the original partition was VFAT though so that concern is valid. Yup; I'm mostly concerned about the ext2 which is fragile on abrupt shutdowns. It is possible that other DP users will want /dev/sda* (the internal sdcard) instead of /dev/sdb* (the external sdcard). Can I express sda vs sdb in the flash-kernel db somehow? Ah, yes; that's indeed a problem. That means we need some config file to override the boot device (ideally an installer would create this file for you). This is currently missing in flash-kernel, but here I think it should allow overriding parts of the machine db entry. Looking at my sda it seems the partitioning scheme used by the supplier there is 100M VFAT + 3.9G EXT. Right; first partition as a small vfat is typically what I expect; it's more reliable than ext2 but doesn't support links, also 100M is a more serious space constraint (especially if initrds get large and kernel versions pile up). There is also some /dev/mtd devices but I think they are tiny SPI things and not useful for booting. Hmm ok; in terms of size, some Kirkwoods come with a full Debian or Ubuntu rootfs in flash, I think some 512 MiB or so of flash were enough to do this, but I've had various issues with ubifs on a device here that kind of scared me away of it. It's probably all fixable, but the serious issues in the kernel and userspace tools led me to think it wasn't a good option when compared to SD card. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667681: Updated patches for Dreamplug / Marvell Kirkwood FDT
Sorry for the delay
On Mon, Jun 04, 2012, Ian Campbell wrote:
+Machine: Globalscale Technologies Dreamplug
+Kernel-Flavors: kirkwood
+U-Boot-Kernel-Address: 0x8000
+U-Boot-Initrd-Address: 0x0
+Boot-Kernel-Path: /boot/uImage
+Boot-Initrd-Path: /boot/uInitrd
Could we use Boot-Device + relative pathnames instead? I find this to
be a cleaner abstraction for the firmware area, it mounts the firmware
area only when needed, and doesn't impose as many constraints on it; if
one uses /boot to mount the firmware area where the bootloader reads
uImage and such, it has to be sufficiently large to carry all installed
kernel packages, might require support for symlinks (problematic for
vfat) or might break more easily with certain fs types (e.g. ext2) if
the device isn't stopped properly.
--- a/functions
+++ b/functions
@@ -21,6 +21,7 @@
BOOTSCRIPTS_DIR=${FK_CHECKOUT:-$FK_DIR}/bootscript
MACHINE_DB=$(cat ${FK_CHECKOUT:-$FK_DIR}/db/*.db)
PROC_CPUINFO=${FK_PROC_CPUINFO:-/proc/cpuinfo}
+PROC_DTMODEL=${FK_PROC_DRMODEL:-/proc/device-tree/model}
PROC_MTD=/proc/mtd
@@ -94,6 +95,16 @@ check_supported() {
get_cpuinfo_hardware() {
grep ^Hardware $PROC_CPUINFO | sed 's/Hardware\s*:\s*//'
}
+get_dt_model() {
+ cat $PROC_DTMODEL
+}
+get_machine() {
+ if [ -f $PROC_DTMODEL ] ; then
+ get_dt_model
+ else
+ get_cpuinfo_hardware
+ fi
+}
get_kfile_suffix() {
local kfile=$1
@@ -302,7 +313,7 @@ elif [ -n $FK_MACHINE ]; then
machine=$FK_MACHINE
[ x$machine = xnone ] exit
else
- machine=$(get_cpuinfo_hardware)
+ machine=$(get_machine)
fi
if [ x$1 = x--supported ]; then
This looks good! Ideally we'd expand the testsuite
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668658: pbuilder: Builds hangs when used with qemu-debootstrap on mips, mipsel and powerpc
On Fri, Apr 13, 2012, Cyril Lavier wrote: I'm trying to use qemu-debootstrap to build packages for other architectures. But I'm facing problems when building mips, mipsel and powerpc packages (works only with armel) with pbuilder using a chroot made by qemu-debootstrap. If it works with armel and not other architectures, it doesn't sound like a pbuilder problem but like a qemu one? -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667681: flash-kernel: Please add support for Dreamplug / Marvell Kirkwood FDT
Hey (Just noticed this bug; thanks for the heads up Hector) On Mon, Apr 09, 2012, Martin Michlmayr wrote: * Ian Campbell i...@hellion.org.uk [2012-04-06 09:49]: Good question. Some DT stuff gets exported in /proc/device-tree. $ echo $(cat /proc/device-tree/model) Globalscale Technologies Dreamplug But that doesn't say whether the DT was passed to the kernel or whether it was appended to the kernel image? It's good that we can identify the actual board though. In that case, I believe you should modify your flash-kernel patch to check this file so the code your proposed will only run on the Dreamplug and not on other Kirkwood DT devices which might require different behaviour. Right; IIUC we want to do these things: a) if /proc/device-tree/model exist, read machine from it rather than using Machine: in cpuinfo b) add support for either appending the DT to the kernel image, or for installing the DT (e.g. writing to flash or copying it to a specific SD partition etc.) b) depends on the way the boards we care about boot; for instance if Debian provides SD card d-i images which contain u-boot with a certain behavior, this is typically the behavior we would rely on; however it might be important to align this with what u-boot does in devices coming out of the factory. I don't like requiring people to replace their bootloader if it's not on user-swappable media. If it's on user-swappable media, I prefer if it's included from the start in Debian images and updated regularly (with each u-boot package upgrade). But none of that exists sadly. Concerning appending the DT vs. copying it, it would be ideal if we could do the same thing for all boards; I guess appending the DT is universal and would work all the time, but it does require turning on a specific option in the kernel config. At the very least, we should attempt to check that the relevant config is turned on and break if we notice it's not. Another final question is where the DT comes from; I expect it's ship pre-built in the linux-image package, just like vmlinuz, but per board. In Ubuntu, these are shipped as e.g.: /boot/dt-2.6.38-1002-linaro-omap/omap3-overo.dtb we need to be really careful that these are stable names (e.g. if linux upstream splits dreamplug.dtb into dreamplug-v1.dtb and dreamplug-v2.dtb, it will break flash-kernel). (There's another question in the back of my mind with DT: I think we can set things like cmdline args via DT; we could use that to set root= instead of using the initrd, but that's not supported in Debian right now and it's not obvious to me that we can post-process .dtb files easily to do this at the right time.) Next steps: * could we assume Debian-ish kernels for your plaform will provide the .dtb in a reliable location and use that as the .dtb file to install? what's the name of the .dtb file and is this available in Debian .debs? * could we assume Debian-ish kernels for your plaform turn on DTB append in the config? * I see your patch adds an entry which requests generation of uImage/uInitrd, but the default upstream u-boot config doesn't include loading an initrd or a DT; what can we assume out of factory? * can we ship u-boot in Debian images so that we can assume which features/config u-boot has? * you request installation of uImage/uInitrd into /boot; that's what other similar platforms do, but my preference would be to use a partition device name instead (Boot-Device:) just like for OMAP4 Panda board; I find this is a bit nicer for multiple reasons: + it allows /boot to be on any device to store possibly large and numerous vmlinuz files + it doesn't require support for e.g. symlinks in the filesystem used for firmware files such as uImage/uInitrd (if it's mounted as /boot and you request /boot/initrd.img and /boot/vmlinuz symlinks on a filesystem which doesn't support symlinks, things break) + this doesn't keep the filesystem mounted all the time - there is a drawback that fsck might not be run automatically for that filesystem, but since it's shared with the bootloader it's probably a good idea so I'd prefer if you could use Boot-Device: whatever, Boot-Kernel-Path: uImage and Boot-Initrd-Path: uInitrd Hope this helps, Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644583: Extra patch for smtpd_client_port_logging
Hey
Still related to the use of smtpd_client_port_logging = yes in Postfix'
main.cf, here's an extra patch for the too many errors after log
message.
Cheers,
--
Loïc Minier
From 935e6ff75f7df300990525faa1dd6a6b3e2e377d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org
Date: Sat, 18 Feb 2012 09:38:36 +0100
Subject: [PATCH] Allow for port in too many errors Postfix log
---
rulefiles/linux/ignore.d.server/postfix |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/rulefiles/linux/ignore.d.server/postfix b/rulefiles/linux/ignore.d.server/postfix
index d41ca4b..3159b0b 100644
--- a/rulefiles/linux/ignore.d.server/postfix
+++ b/rulefiles/linux/ignore.d.server/postfix
@@ -121,7 +121,7 @@
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: [._[:alnum:]-]+(\[[[:xdigit:].:]{3,39}\](:[[:digit:]]+)?)?: Trusted: subject_CN=[._[:alnum:]-]+, issuer=[ ._[:alnum:]-]+, fingerprint=([[:xdigit:]]{2}:){15,19}[[:xdigit:]]{2}$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: lost connection after [[:upper:]]+( \([[:digit:]]+ bytes\))? from [._[:alnum:]-]+\[(unknown|[[:xdigit:].:]{3,39})\](:(unknown|[[:digit:]]+))?$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: timeout after [-[:upper:]]+( \([[:digit:]]+ bytes\))? from [^[:space:]]+$
-^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: too many errors after ([[:upper:]]{4}|END-OF-MESSAGE|UNKNOWN|DATA \(0 bytes\)) from [._[:alnum:]-]+\[[.[:digit:]]+\]$
+^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: too many errors after ([[:upper:]]{4}|END-OF-MESSAGE|UNKNOWN|DATA \(0 bytes\)) from [._[:alnum:]-]+\[[.[:digit:]]+\](:[[:digit:]]{4,5})?$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: unable to open Berkeley db /etc/sasldb: No such file or directory$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: warning: ([-._[:alnum:]]+): RBL lookup error: Host or domain name not found\. Name service error for name=\1 type=A: Host not found, try again$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: warning: ([[:xdigit:].:]{3,39})+: address not listed for hostname [^[:space:]]+$
--
1.7.9
Bug#659705: libmpeg2-4: Upload 0.5.x to unstable?
On Tue, Feb 14, 2012, Alessio Treglia wrote: I think you are right so I've created two repositories, one for libdvb and another for mpeg2dec, right by git-import-dscs'ing on the packages from the archive. Please have a look, we'll never wipe their old corrispective SVN repos, so fine grained history is preserved. I had a look at the new mpeg2dec one; it seemed fine; I had one weirdness that I don't understand: git show dc81e27ddf6c6058cfd66ca4c2675f456e9728ea and git diff dc81e27ddf6c6058cfd66ca4c2675f456e9728ea^..dc81e27ddf6c6058cfd66ca4c2675f456e9728ea give different results for debian/changelog, I don't really get why. Anyway, looks good! (Obviously Vcs-Svn will need to be updated before upload) -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659705: libmpeg2-4: Upload 0.5.x to unstable?
On Mon, Feb 13, 2012, Alessio Treglia wrote: Loïc, you are listed as the real maintainer of the package and I've seen you used to keep the VCS of mpeg2dec into the pkg-multimedia's ancient SVN repository. Do you agree to move the package under the new Debian Multimedia Maintainers' git area and let us work on it [1]? Yup; that sounds good! Did you get the history from the SVN or from importing the .dscs from e.g. snapshot or launchpad? I also have a strong preference for full source tree in the git repo rather than just debian/ -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659705: libmpeg2-4: Upload 0.5.x to unstable?
On Mon, Feb 13, 2012, Alessio Treglia wrote: I've converted the SVN repo into a new git one, here is the result: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpeg2dec.git There are in my eyes two ways to deal with importing the history of this package: a) start from the history in the packaging SVN repo pros: - fine grained history cons: - doesn't intermix with upstream history very well - mixes upstream files in working tree with just debian/ in working tree - no strict relationship to archive contents b) start from the Debian upload history (.dsc files as downloaded from snapshot.debian.org or from Launchpad, or convert bzr history from lp:debian/mpeg2dec) pros: - matches archive contents - consistenly upstream files in working tree - easy to mix with upstream tarball history cons: - doesn't mix with upstream git history if any Your git repo has partial SVN history, I don't know why; if I svn log the unstable mpeg2dec branch in pkg-multimedia it goes down to commits of David Lehn in October 2000 and has imports of the CVS history; these I don't see in your git repo. I would personally think this kind of deep history isn't terribly useful because its form is inconsistent (e.g. debian/ alone or not) so that you would only be able to git blame certain debian/* files. That's why I would personally recommend b), even if that means not seeing some of the finer grained history (my commits for instance). In any case, we must keep the SVN history somewhere; never wipe the SVN repo (you can commit an empty the tree though). To create b), I think I would either download the .dscs from Launchpad using a script or from snapshot.d.o, and then run git-import-dsc on them. Another separate question is how to integrate with upstream history; you could try mixing it with the Debian history, but you need to ensure that the Debian upload tags in the git repo correspond to uploaded .dscs. It's usually trickier to get this right, and it's really useful when dealing with a large set of cherry-picked upstream patches directly committed in your git repo, not useful when using a patch system though. I would recommend sticking to the branch of imported tarballs as the branch mixing history with the Debian one. You can always push some upstream git-ified history to the repo if you like and cherry-pick from it or export patches to debian/patches from it. Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657682: gcc-4.6: assembler error on armhf Error: can't resolve `.rodata' {.rodata section} - `.LPIC10' {*UND* section}
forwarded 657682 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50313
tags 657682 + confirmed fixed-upstream upstream
stop
Hi
On Fri, Jan 27, 2012, Peter Green wrote:
/tmp/cc1SBNmj.s: Assembler messages:
/tmp/cc1SBNmj.s:2152: Error: can't resolve `.rodata' {.rodata section} -
`.LPIC18' {*UND* section}
make[5]: *** [gmime-param.lo] Error 1
Looks like above bug (fixed upstream); also pending a backport of the
fix in gcc-linaro 4.6:
https://code.launchpad.net/~ramana/gcc-linaro/pr50313-backport/+merge/89058
Cheers,
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657682: gcc-4.6: assembler error on armhf Error: can't resolve `.rodata' {.rodata section} - `.LPIC10' {*UND* section}
Sample backport for gcc-linaro 4.6 at: http://bazaar.launchpad.net/~ramana/gcc-linaro/pr50313-backport/revision/106861?start_revid=106861 -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638880: [libwmf] Please slitlibwmflite
Hi On Mon, Aug 22, 2011, Bastien ROUCARIES wrote: Please split your package. Libwmflite is the only part needed by graphicmagick and surely after patching imagemagick. It will deeply decrease the dependencies of this package. I'm preparing an upload dropping the defoma dependency; is this theone which was bothering you? I checked the other ones, /usr/lib/libwmf-0.2.so.7 has these additional NEEDED entries over /usr/lib/libwmflite-0.2.so.7: NEEDED libfreetype.so.6 NEEDED libX11.so.6 NEEDED libexpat.so.1 NEEDED libjpeg.so.8 NEEDED libpng12.so.0 NEEDED libz.so.1 but libgraphicsmagick3 currently has deps on most of these except libexpat1 (which doesn't pull in anything more itself). so splitting would seem useless after dropping the defoma dep. libwmf0.2-7 also Recommends gsfonts, but so does libgraphicsmagick3. There's another set of dependencies: imagemagick depends on libwmf-bin; but I don't think that's the one you meant. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638880: RE : Re: Bug#638880: [libwmf] Please slitlibwmflite
On Thu, Jan 05, 2012, Bastien ROUCARIES wrote: Next major version of imagemagick will drop x support, so it is really usefull Ok; currently /usr/lib/ImageMagick-6.6.9/modules-Q16/coders/wmf.so is linked against libwmf-0.2.so.7 and libwmflite-0.2.so.7; could you confirm you can link it to libwmflite-0.2.so.7 alone? if that's the case, we could split libwmflite out in its own package. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653397: Missing NEEDEDs on at least libengine
Package: clutter-gesture Version: 0.0.2.1-5 Severity: important Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertag: origin-ubuntu ubuntu-patch precise Hey libengine uses symbols from libraries such as libm and libgobject but doesn't actually link to them; the attached patch fixes the build with -z defs in LDFLAGS for me and also fixes a couple of style issues. While developing this patch, the clutter-gesture wouldn't build for me on an Ubuntu system due to the use of deprecated symbols such as g_thread_init, so I disabled -Werror for deprecated declarations, but ideally this would be ported to the latest glib API. Cheers, -- Loïc Minier diff -Nru clutter-gesture-0.0.2.1/debian/changelog clutter-gesture-0.0.2.1/debian/changelog --- clutter-gesture-0.0.2.1/debian/changelog2011-11-20 08:14:15.0 +0100 +++ clutter-gesture-0.0.2.1/debian/changelog2011-12-27 19:12:26.0 +0100 @@ -1,3 +1,15 @@ +clutter-gesture (0.0.2.1-6) UNRELEASED; urgency=low + + * New patch, 05_no-undefined-symbols, misc correctness link fixes to build +successfully with -z defs in LDFLAGS; this fixes missing links on glib, +gobject and libm for at least libengine. + * rules: Pass --no-undefined to build via LDFLAGS. + * Update patch 02_fix_FTBFS_gcc4.6 to also set +-Wno-error=deprecated-declarations to fix FTBFS with latest glib which +deprecates e.g. g_thread_init. + + -- Loïc Minier l...@debian.org Tue, 27 Dec 2011 19:03:36 +0100 + clutter-gesture (0.0.2.1-5) unstable; urgency=low * debian/patches/04_glex_fix.patch: Fix armel FTBFS (Closes: #649167) diff -Nru clutter-gesture-0.0.2.1/debian/patches/02_fix_FTBFS_gcc4.6.patch clutter-gesture-0.0.2.1/debian/patches/02_fix_FTBFS_gcc4.6.patch --- clutter-gesture-0.0.2.1/debian/patches/02_fix_FTBFS_gcc4.6.patch 2011-07-18 02:57:56.0 +0200 +++ clutter-gesture-0.0.2.1/debian/patches/02_fix_FTBFS_gcc4.6.patch 2011-12-27 19:08:28.0 +0100 @@ -4,16 +4,14 @@ Author: Ying-Chun Liu (PaulLiu) paul...@debian.org Bug-Debian: http://bugs.debian.org/625322 Last-Update: 2011-07-18 -Index: clutter-gesture-0.0.2.1/configure.ac -=== clutter-gesture-0.0.2.1.orig/configure.ac 2011-07-18 08:56:24.316229243 +0800 -+++ clutter-gesture-0.0.2.1/configure.ac 2011-07-18 08:56:48.871833877 +0800 +--- a/configure.ac b/configure.ac @@ -50,7 +50,7 @@ clutter-1.0 = 1.0.0 gobject-2.0 glib-2.0) -CLUTTERGESTURE_CFLAGS=$CLUTTERGESTURE_CFLAGS -Wall -Werror -fPIC -+CLUTTERGESTURE_CFLAGS=$CLUTTERGESTURE_CFLAGS -Wall -Werror -Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter -fPIC ++CLUTTERGESTURE_CFLAGS=$CLUTTERGESTURE_CFLAGS -Wall -Werror -Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter -Wno-error=deprecated-declarations -fPIC AC_SUBST(CLUTTERGESTURE_CFLAGS) AC_SUBST(CLUTTERGESTURE_LIBS) diff -Nru clutter-gesture-0.0.2.1/debian/patches/05_no-undefined-symbols.patch clutter-gesture-0.0.2.1/debian/patches/05_no-undefined-symbols.patch --- clutter-gesture-0.0.2.1/debian/patches/05_no-undefined-symbols.patch 1970-01-01 01:00:00.0 +0100 +++ clutter-gesture-0.0.2.1/debian/patches/05_no-undefined-symbols.patch 2011-12-27 19:08:48.0 +0100 @@ -0,0 +1,37 @@ +Misc correctness link fixes to build successfully with -z defs +* check for libm in configure.ac; needed for atan() and others +* use $(CLUTTERGESTURE_CFLAGS) rather than @CLUTTERGESTURE_CFLAGS@ in + engine/Makefile.am to allow build-time overrides +* set LIBS to CLUTTERGESTURE_LIBS and LIBM in engine/Makefile.am to link with + proper libs; fixes missing NEEDED entries on at least libengine +* configure.ac: don't AC_SUBST() CLUTTERGESTURE_CFLAGS and _LIBS as + PKG_CHECK_MODULES already does that + +--- a/engine/Makefile.am b/engine/Makefile.am +@@ -23,9 +23,10 @@ + + libengine_la_SOURCES = engine.c engine.h plugin.h stroke.c stroke.h gesture_recog.c gesture_recog.h + +-AM_CFLAGS = @CLUTTERGESTURE_CFLAGS@ -DPKGDATADIR=\$(pkgdatadir)\ ++AM_CFLAGS = $(CLUTTERGESTURE_CFLAGS) -DPKGDATADIR=\$(pkgdatadir)\ + +-INCLUDES = @CLUTTERGESTURE_CFLAGS@ ++INCLUDES = $(CLUTTERGESTURE_CFLAGS) ++LIBS = $(CLUTTERGESTURE_LIBS) $(LIBM) + + DISTCLEANFILES = $(MARSHALFILES) + CLEANFILES = *~ engine *~stroke +--- a/configure.ac b/configure.ac +@@ -51,8 +51,8 @@ + gobject-2.0 + glib-2.0) + CLUTTERGESTURE_CFLAGS=$CLUTTERGESTURE_CFLAGS -Wall -Werror -Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter -Wno-error=deprecated-declarations -fPIC +-AC_SUBST(CLUTTERGESTURE_CFLAGS) +-AC_SUBST(CLUTTERGESTURE_LIBS) ++ ++AC_CHECK_LIBM + + #GTK_DOC_CHECK([1.9]) + diff -Nru clutter-gesture-0.0.2.1/debian/patches/series clutter-gesture-0.0.2.1/debian/patches/series --- clutter-gesture-0.0.2.1/debian
Bug#651087: FTBFS: dh_install: gtk3-im-libthai missing files (usr/lib/gtk-3.0/*/immodules/*.so), aborting
Package: gtk-im-libthai Version: 0.2.1-1 Severity: serious Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: ubuntu-patch origin-ubuntu precise Hi there gtk-im-libthai failed to build on armhf, and it would fail to build on other architectures too as gtk+3.0 now uses multiarch pathnames for immodules. Please find a trivial patch attached. Thanks! -- Loïc Minier diff -Nru gtk-im-libthai-0.2.1/debian/changelog gtk-im-libthai-0.2.1/debian/changelog --- gtk-im-libthai-0.2.1/debian/changelog 2011-11-20 06:02:44.0 +0100 +++ gtk-im-libthai-0.2.1/debian/changelog 2011-12-05 18:43:08.0 +0100 @@ -1,3 +1,9 @@ +gtk-im-libthai (0.2.1-1ubuntu1) precise; urgency=low + + * Use Gtk+ multiarch pathnames for gtk+-3.0 immodules. + + -- Loïc Minier loic.min...@ubuntu.com Mon, 05 Dec 2011 18:42:57 +0100 + gtk-im-libthai (0.2.1-1) unstable; urgency=low * New upstream release diff -Nru gtk-im-libthai-0.2.1/debian/gtk3-im-libthai.install gtk-im-libthai-0.2.1/debian/gtk3-im-libthai.install --- gtk-im-libthai-0.2.1/debian/gtk3-im-libthai.install 2011-11-20 04:12:47.0 +0100 +++ gtk-im-libthai-0.2.1/debian/gtk3-im-libthai.install 2011-12-05 18:42:39.0 +0100 @@ -1,2 +1,2 @@ -usr/lib/gtk-3.0/*/immodules/*.so +usr/lib/*/gtk-3.0/*/immodules/*.so debian/im-switch/th-gtk3-im-libthaietc/X11/xinit/xinput.d
Bug#650658: FTBFS with -Werror=format-security
Package: jfsutils
Version: 1.1.15-1
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Uertags: origin-ubuntu precise ubuntu-patch
Hi
jfsutils 1.1.15-1 failed to build on Debian armhf and s390x buildds
(and on Ubuntu armhf buildds) due to -Werror=format-security being
added recently to CFLAGS.
Attached debdiff fixes the build here.
Cheers,
--
Loïc Minier
diff -u jfsutils-1.1.15/debian/control jfsutils-1.1.15/debian/control
--- jfsutils-1.1.15/debian/control
+++ jfsutils-1.1.15/debian/control
@@ -2,7 +2,7 @@
Section: admin
Priority: optional
Maintainer: Stefan Hornburg (Racke) ra...@linuxia.de
-Build-Depends: cdbs, debhelper (= 4.1.0), uuid-dev
+Build-Depends: cdbs, debhelper (= 4.1.0), uuid-dev, quilt
Standards-Version: 3.8.0
Homepage: http://jfs.sourceforge.net/
diff -u jfsutils-1.1.15/debian/rules jfsutils-1.1.15/debian/rules
--- jfsutils-1.1.15/debian/rules
+++ jfsutils-1.1.15/debian/rules
@@ -20,6 +20,7 @@
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk
include /usr/share/cdbs/1/rules/utils.mk
+include /usr/share/cdbs/1/rules/patchsys-quilt.mk
ifeq ($(DEB_BUILD_ARCH),alpha)
LDFLAGS += -Wl,--no-relax
diff -u jfsutils-1.1.15/debian/changelog jfsutils-1.1.15/debian/changelog
--- jfsutils-1.1.15/debian/changelog
+++ jfsutils-1.1.15/debian/changelog
@@ -1,3 +1,10 @@
+jfsutils (1.1.15-1ubuntu1) precise; urgency=low
+
+ * Include patchsys-quilt.mk and add new patch format-security-errors to fix
+FTBFS with -Werror=format-security.
+
+ -- Loïc Minier loic.min...@ubuntu.com Thu, 01 Dec 2011 17:57:25 +0100
+
jfsutils (1.1.15-1) unstable; urgency=low
* new upstream release (Closes: #504713)
only in patch2:
unchanged:
--- jfsutils-1.1.15.orig/debian/patches/series
+++ jfsutils-1.1.15/debian/patches/series
@@ -0,0 +1 @@
+format-security-errors.patch
only in patch2:
unchanged:
--- jfsutils-1.1.15.orig/debian/patches/format-security-errors.patch
+++ jfsutils-1.1.15/debian/patches/format-security-errors.patch
@@ -0,0 +1,37 @@
+--- a/fscklog/display.c
b/fscklog/display.c
+@@ -182,7 +182,7 @@ void dump_service_log()
+ } else {
+ /* the record looks ok */
+ msg_txt = log_entry[log_entry_pos];
+- printf(msg_txt);
++ printf(%s, msg_txt);
+ /*
+* set up for the next record
+*/
+--- a/fscklog/fscklog.c
b/fscklog/fscklog.c
+@@ -252,8 +252,8 @@ int v_send_msg(int msg_num, const char *file_name, int
line_number, ...) {
+
+ sprintf(debug_detail, [%s:%d]\n, basename(file_name), line_number);
+
+- printf(msg_string);
+- printf(debug_detail);
++ printf(%s, msg_string);
++ printf(%s, debug_detail);
+
+ return 0;
+ }
+--- a/logdump/helpers.c
b/logdump/helpers.c
+@@ -95,8 +95,8 @@ int v_fsck_send_msg(int msg_num, const char *file_name, int
line_number, ...) {
+
+ sprintf(debug_detail, [%s:%d]\n, file_name, line_number);
+
+- printf(msg_string);
+- printf(debug_detail);
++ printf(%s, msg_string);
++ printf(%s, debug_detail);
+
+ return 0;
+ }
Bug#646470: Debdiff
On Thu, Dec 01, 2011, Colin Watson wrote:
IMO a better fix for this part would be to fix the IfTrace0 macro
directly. That way we don't have to play whack-a-mole with any other
users that may be added later.
It's a good idea; I actually thought of converting the whole series
into a variadic macro, but it would have been too large a diff.
Attaching a new debdiff with this change
Thanks,
--
Loïc Minier
diff -u t1lib-5.1.2/debian/changelog t1lib-5.1.2/debian/changelog
--- t1lib-5.1.2/debian/changelog
+++ t1lib-5.1.2/debian/changelog
@@ -1,3 +1,18 @@
+t1lib (5.1.2-3ubuntu2) precise; urgency=low
+
+ * Update patch format-security with suggestion from Colin Watson to
+replace printf() with puts() for the model-only IfTrace0 macro.
+
+ -- Loïc Minier loic.min...@ubuntu.com Thu, 01 Dec 2011 23:24:27 +0100
+
+t1lib (5.1.2-3ubuntu1) precise; urgency=low
+
+ * New format-security patch, fixes FTBFS with -Werror=format-security by
+using relevant %s format when passing a variable string to a printf()
+function; Debian #646470.
+
+ -- Loïc Minier loic.min...@ubuntu.com Thu, 01 Dec 2011 00:25:53 +0100
+
t1lib (5.1.2-3build1) lucid; urgency=low
* rebuild rest of main for armel armv7/thumb2 optimization;
diff -u t1lib-5.1.2/debian/patches/series t1lib-5.1.2/debian/patches/series
--- t1lib-5.1.2/debian/patches/series
+++ t1lib-5.1.2/debian/patches/series
@@ -4,0 +5 @@
+format-security.diff
only in patch2:
unchanged:
--- t1lib-5.1.2.orig/debian/patches/format-security.diff
+++ t1lib-5.1.2/debian/patches/format-security.diff
@@ -0,0 +1,33 @@
+--- a/lib/type1/objects.c
b/lib/type1/objects.c
+@@ -957,7 +957,7 @@
+
+sprintf(typemsg, Wrong object type in %s; expected %s, found %s.\n,
+ name, TypeFmt(expect), TypeFmt(obj-type));
+- IfTrace0(TRUE,typemsg);
++ IfTrace1(TRUE, %s, typemsg);
+
+ObjectPostMortem(obj);
+
+--- a/lib/t1lib/t1subset.c
b/lib/t1lib/t1subset.c
+@@ -759,7 +759,7 @@
+tr_len);
+ T1_PrintLog( T1_SubsetFont(), err_warn_msg_buf,
+T1LOG_DEBUG);
+-l+=sprintf( (trailerbuf[l]), linebuf); /* contains the PostScript
trailer */
++l+=sprintf( (trailerbuf[l]), %s, linebuf); /* contains the PostScript
trailer */
+ }
+
+ /* compute size of output file */
+--- a/lib/type1/objects.h
b/lib/type1/objects.h
+@@ -214,7 +214,7 @@
+ /*SHARED*/
+ /* NDW: personally, I want to see status and error messages! */
+ #define IfTrace0(condition,model) \
+-{if (condition) printf(model);}
++{if (condition) fputs(model,stdout);}
+ #define IfTrace1(condition,model,arg0)\
+ {if (condition) printf(model,arg0);}
+ #define IfTrace2(condition,model,arg0,arg1) \
Bug#645300: Debdiff
tag #645300 + patch confirmed upstream
user ubuntu-de...@lists.ubuntu.com
usertag #645300 + ubuntu-patch precise
stop
Hi
Attached debdiff fixes the issue for me and a couple of typos in rules
that I noticed while building tidy; please consider it for Debian and
upstream. (I can't upload it to Ubuntu today, but will likely do so
tomorrow to fix the FTBFS.)
Thanks,
--
Loïc Minier
--- tidy-20091223cvs/debian/rules
+++ tidy-20091223cvs/debian/rules
@@ -12,9 +12,9 @@
build/tidy::
## Generate manpage from tidy output
- LD_LIBRARY_PATH=$(CURDUR)/src/.libs/ \
+
LD_LIBRARY_PATH=$${LD_LIBRARY_PATH:+$$LD_LIBRARY_PATH:}$(CURDIR)/src/.libs/ \
$(CURDIR)/console/tidy -xml-help $(HELPXML)
- LD_LIBRARY_PATH=$(CURDUR)/src/.libs/ \
+
LD_LIBRARY_PATH=$${LD_LIBRARY_PATH:+$$LD_LIBRARY_PATH:}$(CURDIR)/src/.libs/ \
$(CURDIR)/console/tidy -xml-config $(CONFIGXML)
/usr/bin/xsltproc -o $(MANPAGE) $(MANXSL) $(HELPXML)
--- tidy-20091223cvs/debian/changelog
+++ tidy-20091223cvs/debian/changelog
@@ -1,3 +1,18 @@
+tidy (20091223cvs-1ubuntu1) precise; urgency=low
+
+ * New patch, 10format-warnings, fixes FTBFS with -Werror=format-security;
+essentially calls to messageNode() declared printf-alike with a variable
+fmt string, but no subsequent argument; the patch passes %s as format
+and fmt as the only argument; this merely protects this class of calls,
+but not the ones with e.g. always one argument or always two arguments.
+Tested by running tidy on some text and HTML files; warnings still seem to
+be output correctly; Debian #645300.
+ * Use CURDIR instead of CURDUR in rules.
+ * rules: only append to LD_LIBRARY_PATH, don't reset it, as fakeroot relies
+on it.
+
+ -- Loïc Minier loic.min...@ubuntu.com Wed, 30 Nov 2011 23:26:02 +0100
+
tidy (20091223cvs-1) unstable; urgency=low
* New cvs snapshot
only in patch2:
unchanged:
--- tidy-20091223cvs.orig/debian/patches/10format-warnings.patch
+++ tidy-20091223cvs/debian/patches/10format-warnings.patch
@@ -0,0 +1,57 @@
+diff --git a/src/localize.c b/src/localize.c
+index b832c23..e8c8027 100644
+--- a/src/localize.c
b/src/localize.c
+@@ -1373,14 +1373,14 @@ void TY_(ReportAccessWarning)( TidyDocImpl* doc, Node*
node, uint code )
+ {
+ ctmbstr fmt = GetFormatFromCode(code);
+ doc-badAccess |= BA_WAI;
+-messageNode( doc, TidyAccess, node, fmt );
++messageNode( doc, TidyAccess, node, %s, fmt );
+ }
+
+ void TY_(ReportAccessError)( TidyDocImpl* doc, Node* node, uint code )
+ {
+ ctmbstr fmt = GetFormatFromCode(code);
+ doc-badAccess |= BA_WAI;
+-messageNode( doc, TidyAccess, node, fmt );
++messageNode( doc, TidyAccess, node, %s, fmt );
+ }
+
+ #endif /* SUPPORT_ACCESSIBILITY_CHECKS */
+@@ -1399,7 +1399,7 @@ void TY_(ReportWarning)(TidyDocImpl* doc, Node *element,
Node *node, uint code)
+ switch (code)
+ {
+ case NESTED_QUOTATION:
+-messageNode(doc, TidyWarning, rpt, fmt);
++messageNode(doc, TidyWarning, rpt, %s, fmt);
+ break;
+
+ case OBSOLETE_ELEMENT:
+@@ -1480,7 +1480,7 @@ void TY_(ReportError)(TidyDocImpl* doc, Node *element,
Node *node, uint code)
+ case INCONSISTENT_NAMESPACE:
+ case DOCTYPE_AFTER_TAGS:
+ case DTYPE_NOT_UPPER_CASE:
+-messageNode(doc, TidyWarning, rpt, fmt);
++messageNode(doc, TidyWarning, rpt, %s, fmt);
+ break;
+
+ case COERCE_TO_ENDTAG:
+@@ -1499,7 +1499,7 @@ void TY_(ReportError)(TidyDocImpl* doc, Node *element,
Node *node, uint code)
+ case ENCODING_IO_CONFLICT:
+ case MISSING_DOCTYPE:
+ case SPACE_PRECEDING_XMLDECL:
+-messageNode(doc, TidyWarning, node, fmt);
++messageNode(doc, TidyWarning, node, %s, fmt);
+ break;
+
+ case TRIM_EMPTY_ELEMENT:
+@@ -1548,7 +1548,7 @@ void TY_(ReportFatal)( TidyDocImpl* doc, Node *element,
Node *node, uint code)
+ {
+ case SUSPECTED_MISSING_QUOTE:
+ case DUPLICATE_FRAMESET:
+-messageNode(doc, TidyError, rpt, fmt);
++messageNode(doc, TidyError, rpt, %s, fmt);
+ break;
+
+ case UNKNOWN_ELEMENT:
Bug#646470: Debdiff
tags 646470 + confirmed upstream patch user ubuntu-de...@lists.ubuntu.com usertag ubuntu-patch precise stop Hi Attached debdiff fixes format strings and the build here. Cheers, NB: not yet uploaded to Ubuntu as its archive is frozen right now -- Loïc Minier --- t1lib-5.1.2/debian/changelog +++ t1lib-5.1.2/debian/changelog @@ -1,3 +1,11 @@ +t1lib (5.1.2-3ubuntu1) precise; urgency=low + + * New format-security patch, fixes FTBFS with -Werror=format-security by +using relevant %s format when passing a variable string to a printf() +function; Debian #646470. + + -- Loïc Minier loic.min...@ubuntu.com Thu, 01 Dec 2011 00:25:53 +0100 + t1lib (5.1.2-3build1) lucid; urgency=low * rebuild rest of main for armel armv7/thumb2 optimization; --- t1lib-5.1.2/debian/patches/series +++ t1lib-5.1.2/debian/patches/series @@ -4,0 +5 @@ +format-security.diff only in patch2: unchanged: --- t1lib-5.1.2.orig/debian/patches/format-security.diff +++ t1lib-5.1.2/debian/patches/format-security.diff @@ -0,0 +1,22 @@ +--- a/lib/type1/objects.c b/lib/type1/objects.c +@@ -957,7 +957,7 @@ + +sprintf(typemsg, Wrong object type in %s; expected %s, found %s.\n, + name, TypeFmt(expect), TypeFmt(obj-type)); +- IfTrace0(TRUE,typemsg); ++ IfTrace1(TRUE, %s, typemsg); + +ObjectPostMortem(obj); + +--- a/lib/t1lib/t1subset.c b/lib/t1lib/t1subset.c +@@ -759,7 +759,7 @@ +tr_len); + T1_PrintLog( T1_SubsetFont(), err_warn_msg_buf, +T1LOG_DEBUG); +-l+=sprintf( (trailerbuf[l]), linebuf); /* contains the PostScript trailer */ ++l+=sprintf( (trailerbuf[l]), %s, linebuf); /* contains the PostScript trailer */ + } + + /* compute size of output file */
Bug#650350: apr: testsuite hangs on testprocmutex
On Tue, Nov 29, 2011, Hector Oron wrote: Disabling tests produces a package, do you think is sane enough to upload a package to the archive with tests disabled? (its just testprocmux the one failing). BTW, I also tried to disable the test, but I get: .libs/abts.o:abts.c:function alltests: error: undefined reference to 'testprocmutex' collect2: ld returned 1 exit status This reminds me of: https://launchpad.net/bugs/604753 https://bugs.launchpad.net/linaro-toolchain-misc/+bug/643171 I think Ubuntu had at least this particular test disabled for a while. It would be good to know if your Debian eglibc binaries have the patch applied or not. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#328261: desktop-file-utils: doesn't remove mimeinfo.cache on purge
Version: 0.15-2
Hi
On Wed, Sep 14, 2005, Lars Wirzenius wrote:
The postinst calls update-desktop-database, which
creates /usr/share/applications/mimeinfo.cache. When the package is
purged, this file is left behind as cruft on the filesystem. It would
make sense to remove it when the package is removed (or maybe only when
purged?).
This bug was actually fixed in 0.15-2:
[...]
* postrm: remove created caches upon removal.
This is the full changelog entry:
desktop-file-utils (0.15-2) unstable; urgency=low
[ Loic Minier ]
* Depend on ${misc:Depends}.
* Do not hardcode the path to update-desktop-database in postinst.
[ Josselin Mouette ]
* Add myself to uploaders.
* postrm: remove created caches upon removal.
* triggers: register interest in /usr/share/applications.
* postinst: run update-desktop-database when triggered.
* Standards version is 3.8.1.
* Remove defaults.list stuff, it’s all in gnome-session now.
* copyright: refer to versioned GPL.
-- Josselin Mouette j...@debian.org Fri, 10 Apr 2009 15:02:33 +0200
Closing it now.
Cheers,
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648194: Fails to build with -Wl,--as-needed
Package: yforth Version: 0.1beta-22 Severity: wishlist Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch precise Hi Ubuntu's toolchain is configured to set -Wl,--as-needed by default as to automatically strip superfluous ELF dependencies. This change might be adopted to Debian in the future. yforth 0.1beta-22 fails to build with current Ubuntu toolchain setup; a simple make in the source tree fails with: [...] gcc -lm -o yforth block.o blocke.o core.o coree.o double.o doublee.o exceptio.o facility.o file.o filee.o float.o floate.o locals.o localse.o memall.o search.o searche.o string.o tools.o toolse.o udio.o vm.o ycore.o yfinit.o yforth.o yfvinit.o float.o: In function `_floor': float.c:(.text+0x44d): undefined reference to `floorf' float.o: In function `_f_round': float.c:(.text+0x538): undefined reference to `floor' [...] Prefixing -Wl,--no-as-needed to the gcc flags allows it to pass. The fix is to change Makefile as follows; instead of: $(CC) -o yforth $(OBJECTS) $(MATHLIB) use: $(CC) $(MATHLIB) -o yforth $(OBJECTS) $(MATHLIB) Attaching a debdiff to this effect. Thanks, -- Loïc Minier diff -u yforth-0.1beta/Makefile yforth-0.1beta/Makefile --- yforth-0.1beta/Makefile +++ yforth-0.1beta/Makefile @@ -13,7 +13,7 @@ string.h tools.h toolse.h udio.h ver.h ycore.h yforth.h yforth: div.h $(OBJECTS) - $(CC) $(MATHLIB) -o yforth $(OBJECTS) + $(CC) -o yforth $(OBJECTS) $(MATHLIB) div.h: div ./div diff -u yforth-0.1beta/debian/changelog yforth-0.1beta/debian/changelog --- yforth-0.1beta/debian/changelog +++ yforth-0.1beta/debian/changelog @@ -1,3 +1,10 @@ +yforth (0.1beta-23) UNRELEASED; urgency=low + + [ Michael Bienia ] + * Makefile: Move $(MATHLIB) to the end of the linker call. + + -- Loïc Minier l...@dooz.org Wed, 09 Nov 2011 15:19:53 +0100 + yforth (0.1beta-22) unstable; urgency=low * add Vcs entries to the control file
Bug#648196: [p-a-s] Please drop yforth from P-a-s
Package: buildd.debian.org Severity: wishlist Hey After discussion with maintainer in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645642 and we both prefer if the package gets build attempts on other architectures, as to get build logs for FTBFSes on architectures where it needs porting. Would you please drop the yforth entry from P-a-s? Thanks, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#391051: quilt patch
tags 391051 + patch
stop
Hi
Attached is a patch attached for the new quilt-based packaging.
Cheers,
--
Loïc Minier
Author: Ian Jackson i...@ubuntu.com
Description: Do not crash if regexp is too long for our buffer; LP #23494
--- mawk-1.3.3.orig/scan.c
+++ mawk-1.3.3/scan.c
@@ -1033,6 +1033,15 @@
STRING *sval ;
while (1)
+ {
+ if (p == string_buff + SPRINTF_SZ - 2)
+ {
+ compile_error(
+ regular expression /%.10s ...
+ exceeds implementation size limit,
+ string_buff) ;
+ mawk_exit(2) ;
+ }
switch (scan_code[*p++ = next()])
{
case SC_DIV: /* done */
@@ -1070,6 +1079,7 @@
}
break ;
}
+ }
out:
/* now we've got the RE, so compile it */
Bug#391051: quilt patch
tags 391051 + patch
stop
Hi
attached is an updated patch for the new quilt packaging, also merging
the fix and test case from:
http://anonscm.debian.org/gitweb/?p=collab-maint/mawk.git;a=commitdiff;h=e2e6d7ad490a7b19c562af5874a08a4168382b57
Note that the above commit is on top of a newer version of mawk merged
into that git repo, but not actually uploaded to Debian; the packaging
since moved to a bzr branch at:
nosmart+http://bzr.debian.org/bzr/users/vorlon/mawk/trunk/
Cheers,
--
Loïc Minier
Author: Ian Jackson i...@ubuntu.com, Jonathan Nieder jrnie...@gmail.com
Description: Do not crash if regexp is too long for our buffer; LP #23494
--- a/scan.c
+++ b/scan.c
@@ -1033,6 +1033,15 @@
STRING *sval ;
while (1)
+ {
+ if (p = string_buff + SPRINTF_SZ - 2)
+ {
+ compile_error(
+ regular expression /%.10s ...
+ exceeds implementation size limit,
+ string_buff) ;
+ mawk_exit(2) ;
+ }
switch (scan_code[*p++ = next()])
{
case SC_DIV: /* done */
@@ -1070,6 +1079,7 @@
}
break ;
}
+ }
out:
/* now we've got the RE, so compile it */
--- a/test/mawktest
+++ b/test/mawktest
@@ -35,6 +35,13 @@
cmp -s reg-awk.out temp$$ || exit
+# 640 backslashes
+backslashes='\\'
+backslashes=$backslashes$backslashes$backslashes$backslashes
+backslashes=$backslashes$backslashes$backslashes$backslashes
+backslashes=$backslashes$backslashes$backslashes$backslashes
+( set +e; LC_ALL=C $PROG /a$backslashes/ $dat; test $? -eq 2 ) || exit
+
echo regular expression matching OK
###
Bug#391051: quilt patch
On Mon, Nov 07, 2011, Jonathan Nieder wrote: As mentioned at http://bugs.debian.org/244962, this == is wrong. A regex with backslashes can easily skip past the end. Thanks; I had noticed and sent the correct patch later to the Debian bug; I had sent the first one by accident (and just see that now that you comment on it). -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645908: Fails to cross-build
Package: libcap2 Version: 1:2.22-1 Severity: wishlist Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: precise origin-ubuntu ubuntu-patch Hey libcap2 failed to cross-build with xdeb as nothing sets CC/BUILD_CC or build/host architectures. Passing CC/BUILD_CC to the upstream makefile seems to be all that's missing to cross-build libcap2 (attached patch). This was originally reported by Wookey at: https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/872435 which has extra details. Thanks! -- Loïc Minier diff -Nru libcap2-2.22/debian/changelog libcap2-2.22/debian/changelog --- libcap2-2.22/debian/changelog 2011-07-28 07:44:47.0 +0200 +++ libcap2-2.22/debian/changelog 2011-10-19 16:33:51.0 +0200 @@ -1,3 +1,11 @@ +libcap2 (1:2.22-1ubuntu1) precise; urgency=low + + * Fix cross-building by passing CC and BUILD_CC to dh_auto_make; based on a +patch by Colin Watson for the previous CDBS packaging, but adapted for the +new dh-based packaging; LP: #872435. + + -- Loïc Minier loic.min...@linaro.org Wed, 19 Oct 2011 16:30:24 +0200 + libcap2 (1:2.22-1) unstable; urgency=low * New upstream released diff -Nru libcap2-2.22/debian/rules libcap2-2.22/debian/rules --- libcap2-2.22/debian/rules 2011-07-28 07:44:47.0 +0200 +++ libcap2-2.22/debian/rules 2011-10-19 16:30:18.0 +0200 @@ -1,8 +1,20 @@ #!/usr/bin/make -f +DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) + +ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) +CC := gcc +else +CC := $(DEB_HOST_GNU_TYPE)-gcc +endif + %: dh $@ +override_dh_auto_build: + dh_auto_build -- CC=$(CC) BUILD_CC=gcc + override_dh_auto_install: dh_auto_install -- lib=lib RAISE_SETFCAP=no
Bug#645642: Please add armhf to architecture list
On Mon, Oct 17, 2011, Bdale Garbee wrote: It looks like I did that back in 1999 to get around some problem, and then over time people have let me know various other architectures work and so I've added them back in. I think you're right, though, making it 'any' won't hurt at this point... if it doesn't build on all architectures, I may get some FTBFS bugs, but they won't be RC if the package never built on that architecture before... Makes sense; thanks! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645692: Support for hard-float calling convention and flag to select the ARM ABI
On Mon, Oct 17, 2011, Thomas Preud'homme wrote: It would be nice if TCC supported the hard-float ABI used on armhf (uses the FPU regs to pass floating point values). My question might be stupid but are you talking about the code tcc generate or the code in which tcc is compiled? I guess you're talking about the code in which tcc itself is compiled since tcc has only one ABI for generated code as far as I know. TCC itself will build fine on armel and armhf using their calling conventions for the tcc binary itself; the code generated by tcc however depends on which architecture it was built on and currently seems to only support the arm and armel cases (OABI and EABI with or without VFP code, but soft-float calling conventions). In fact, it would be nice if TCC allowed selection of the ARM ABI it's targetting, e.g. ARMv4...ARMv7, Thumb/ARM mode, OABI vs. EABI, soft VFP / hard VFP / no VFP. (Note that currently the supported ABI is the one of the buildd, which might be higher than the base requirement to run the Debian port.) I guess you are refering to the line NATIVE_DEFINES+=$(if $(shell grep -l ^Features.* \(vfp\|iwmmxt\) /proc/cpuinfo),-DTCC_ARM_VFP) in Makefile. Did I miss some other line? That's what tailors the tcc build to target this or that ABI, yes; actually there are two defines: NATIVE_DEFINES+=$(if $(wildcard /lib/ld-linux.so.3),-DTCC_ARM_EABI) NATIVE_DEFINES+=$(if $(shell grep -l ^Features.* \(vfp\|iwmmxt\) /proc/cpuinfo),-DTCC_ARM_VFP) As EABI mandates /lib/ld-linux.so.3. BTW, this will likely cause issue in the future as armhf might remove /lib/ld-linux.so.3 (it's using the multiarch path instead of this one). I would happily work on it as I'm myself using armhf since recently but I don't know enough about the different ARM ABI so could you suggest me a list of ABI and the feature I should put inside (or point me to a documentation for this second part)? With pleasure; the only other ABI that tcc doesn't support at build time is the EABI hard-float variant; that's like soft-float, except that when you call functions with float arguments, you pass them via FPU registers rather than serialized as VFP on the stack. This calling convention is described in the EABI spec, I think it's called AAPCS, it's what you get when calling gcc with -mhard-float on armel or what you get by default on armhf. Some information about the armhf port is at: http://wiki.debian.org/ArmHardFloatPort and the armel port was the one introducing EABI in Debian: http://wiki.debian.org/ArmEabiPort this second page has links to some version of the specs at the bottom of the page. It would be good if tcc was using if()s rather than #ifdefs, as to select the ABI at runtime rather than build-time, but I don't know whether tcc is expected to support that. It doesn't seem to be meant to do weird things like cross-compilation either. :-) By the way, should I wait for this bug to be solved before adding armhf to the list of supported architecture as requested by you in bug #645673 or directly upload with armhf enabled and work in a second time on this issue? Up to you; if you enable armhf in control, it will build and run, but the generated code will only run on armel AFAICT; that's an acceptable and useful interim situation, unless packages build-depend on tcc. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645692: Support for hard-float calling convention and flag to select the ARM ABI
On Tue, Oct 18, 2011, Thomas Preud'homme wrote:
TCC itself will build fine on armel and armhf using their calling
conventions for the tcc binary itself; the code generated by tcc
however depends on which architecture it was built on and currently
seems to only support the arm and armel cases (OABI and EABI with or
without VFP code, but soft-float calling conventions).
Ah ok, I see my mistake. I saw it only as optimisation but completely forgot
it's an ABI change. Maybe it's not too much work then. Unfortunetely I will
not have time to look into it in the next weeks. But I'll try to look at it
as
soon as possible.
Note that one can still generate code using VFP instructions on armel,
which is what gcc does (it's called softfp in gcc speech). I believe
that's what tcc does on armel today when built on a buildd with VFP.
BTW, this will likely cause issue in the future as armhf might remove
/lib/ld-linux.so.3 (it's using the multiarch path instead of this one).
Ok, this is a much easier change. I didn't know the linker itself could be in
a multiarch path. Isn't the multiarch triplet Debian specific (as opposed to
the GNU triplet)?
GNU triplets are tricky: i386-linux-gnu and i486-linux-gnu are actually
the same ABI, but with different levels of optimizations and ISA
requirements (but you can call i386-linux-gnu libraries from
i486-linux-gnu ones and vice-versa). arm-linux-gnueabi unfortunately
doesn't say whether it's hardfp or soft float or softfp; upstreams says
that this is because the same arm-linux-gnueabi toolchain can generate
soft/softfp/hard-float code.
At some point, multiarch triplets were specified and proposed to have
one unique triplet per ABI in an OS vendor neutral way, but the dpkg
maintainers proposed using the oldest CPU of a family as an unique
triplet instead of multiarch triplets, and creating new ones where
missing, so we now have i386-linux-gnu for the Debian i386
architecture, arm-linux-gnueabi for armel and arm-linux-gnueabihf for
armhf and we're hoping other distros will follow this convention.
Concerning EABI, it mandates /lib/ld-linux.so.3 for both armel and
armhf but because the pathname is already used for armel and armhf was
the new port and multiarch was around the corner, the plan is to use
/lib/arm-linux-gnueabihf/ld-linux.so.3 for armhf. That violates EABI,
maybe we'll get it updated someday to allow for two different runtime
linkers for armel and armhf to be installed at the same time (like
amd64's ld-linux-x86-64.so.2.
Actually tcc can do cross-compilation. The Makefile is planned to be able to
build ${arch}-tcc binaries for this purpose. Maybe one day I'll build a tcc-
cross package for that but that's quite far on my TODO list to be honest.
I'll
talk to upstream about selecting the ABI, I don't know how he will react to
this.
Ok; well IMHO the current cpuinfo checks in Makefile for ARM are bad;
this should be specified by the end-user entirely. It's fine to
autodetect the default though, but it's quite important for a C
compiler's optimization level to be well defined because one might be
building armel binaries on an ARMv7 buildd but running them on an ARMv5
machine, or one might be cross-compiling; also consider builds in a
QEMU linux-user chroot where cpuinfo relates to the build environment,
not the host one :-/ the QEMU case is a bit extreme though
I'm not sure how tcc bootstraps itself, maybe it's always built with
gcc or maybe it's building itself once with gcc each time the package
is built, and then a second time with a bootstrap tcc, or maybe it's
bootstrapped in other ways (e.g. manually). In any case, perhaps a
better source for the defaults is the toolchain used to build tcc, that
is if I build tcc with a gcc targetting ARMv5 + VFP and soft-float
calling convention, then maybe tcc should detect and use this as a
default configuration? That's the recommended practice for other
non-compiler packages so that one can just change the toolchain default
targets and rebuild the archive to get optimized binaries -- of course
that doesn't work across ABI changes.
It would be fine if tcc was only a normal compiler. Unfortunetely tcc also
support executing source code via -run switch. This would then be broken
since
it doesn't generate code in the correct ABI. Actually tcc would act as a
cross
compiler in this case and packaging it as tcc would be misleading. So I'll
add
armhf when this bug will be solved.
Makes sense; thanks!
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645588: Shouldn't recreate alias on upgrades
Package: logcheck
Version: 1.3.14
Severity: normal
Tags: patch
Hi
I don't want the logcheck email alias because I configure logcheck to
send email to a different address, but it keeps getting re-added on
upgrades.
I've prepared a patch to only add the alias on install, not on
upgrades, but I've noticed some small issues with the rest of the
postinst (tests which could be simplified and tabs with different size
expectations depending on the code block you're looking at), so I'm
attaching a series of patches on top of current git to fix these.
Thanks,
--
Loïc Minier
From 0bb0adbaa4e2a84ad16b1871efa729cfd90eff2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org
Date: Mon, 17 Oct 2011 09:22:36 +0200
Subject: [PATCH 1/4] Add logcheck alias on install not on upgrade
---
debian/logcheck.postinst | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/debian/logcheck.postinst b/debian/logcheck.postinst
index 849ad98..7032323 100644
--- a/debian/logcheck.postinst
+++ b/debian/logcheck.postinst
@@ -47,13 +47,15 @@ case $1 in
adduser --quiet logcheck adm || true
fi
- # add logcheck to /etc/aliases
- if [ -f /etc/aliases ] || [ -L /etc/aliases ]; then
-if ! grep -qi ^logcheck[[:space:]]*: /etc/aliases; then
- echo logcheck: root /etc/aliases
- test -x $(command -v newaliases) newaliases || :
+ # add logcheck to /etc/aliases on install; not on upgrade
+ if [ -z $2 ]; then
+if [ -f /etc/aliases ] || [ -L /etc/aliases ]; then
+ if ! grep -qi ^logcheck[[:space:]]*: /etc/aliases; then
+echo logcheck: root /etc/aliases
+test -x $(command -v newaliases) newaliases || :
+ fi
fi
- fi
+ fi
# give logcheck system user a real name unless it has one.
if [ -z $(getent passwd logcheck | cut -d: -f5) ]; then
--
1.7.5.4
From d2e57486d3197297388494ed210e90b68d8fe23b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org
Date: Mon, 17 Oct 2011 09:23:15 +0200
Subject: [PATCH 2/4] Use [ -z ... ] rather than [ ! -n ... ]
---
debian/logcheck.postinst |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/debian/logcheck.postinst b/debian/logcheck.postinst
index 7032323..d3dfbfc 100644
--- a/debian/logcheck.postinst
+++ b/debian/logcheck.postinst
@@ -63,7 +63,7 @@ case $1 in
fi
# Add logcheck mail header on install
-if [ ! -n $2 ] [ ! -f /etc/logcheck/header.txt ]; then
+if [ -z $2 ] [ ! -f /etc/logcheck/header.txt ]; then
cp -p /usr/share/logcheck/header.txt /etc/logcheck
fi
@@ -72,7 +72,7 @@ case $1 in
chgrp -R logcheck /etc/logcheck || true
# Set Permissions on install, not upgrade
- if [ ! -n $2 ]; then
+ if [ -z $2 ]; then
chmod 2750 /etc/logcheck/ignore.d.paranoid || true
chmod 2750 /etc/logcheck/ignore.d.workstation || true
chmod 2750 /etc/logcheck/ignore.d.server || true
--
1.7.5.4
From 11a96a81ec8bade1d4855495611452552cdfbe67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org
Date: Mon, 17 Oct 2011 09:28:49 +0200
Subject: [PATCH 3/4] Fix indentation and whitespaces in postinsts
Also, call : in empty case statements.
---
debian/logcheck-database.postinst | 60
debian/logcheck.postinst | 138 ++--
2 files changed, 99 insertions(+), 99 deletions(-)
diff --git a/debian/logcheck-database.postinst b/debian/logcheck-database.postinst
index 4ff4888..c8f5337 100644
--- a/debian/logcheck-database.postinst
+++ b/debian/logcheck-database.postinst
@@ -29,39 +29,39 @@ set -e
confdir=/etc/logcheck
case $1 in
-configure)
- # Remove old sarge mv logcheck-data configfiles if unchanged
- if [ -n $2 ] dpkg --compare-versions $2 lt 1.2.48; then
- proftpd_sum=$(sha1sum '/etc/logcheck/ignore.d.paranoid/proftpd' 2/dev/null \
- | awk '{print $1}')
- imap_sum=$(sha1sum '/etc/logcheck/ignore.d.paranoid/imap' 2/dev/null \
- | awk '{print $1}')
- anacron_sum=$(sha1sum '/etc/logcheck/ignore.d.workstation/anacron' 2/dev/null \
- | awk '{print $1}')
- if [ ${proftpd_sum} = da39a3ee5e6b4b0d3255bfef95601890afd80709 ]; then
- rm -rf /etc/logcheck/ignore.d.paranoid/proftpd
- fi
- if [ ${imap_sum} = 9d4e9db1bd0c5cdd5ea3ba8875e628bf50cf1f5f ]; then
- rm -rf /etc/logcheck/ignore.d.paranoid/imap
- fi
- if [ ${anacron_sum} = 78e753ffeff32474a805a7654aa99a07076b6975 ]; then
- rm -rf /etc/logcheck/ignore.d.workstation/anacron
- fi
- fi
+ configure)
+# Remove old sarge mv logcheck-data configfiles if unchanged
+if [ -n $2 ] dpkg --compare-versions $2 lt 1.2.48; then
+proftpd_sum=$(sha1sum '/etc/logcheck/ignore.d.paranoid/proftpd' 2/dev/null \
+| awk '{print $1}')
+imap_sum=$(sha1sum '/etc/logcheck/ignore.d.paranoid/imap' 2/dev/null \
+| awk '{print $1}')
+anacron_sum=$(sha1sum '/etc/logcheck/ignore.d.workstation
Bug#536237: Enable specific domain configuration in SquirrelMail
Hey
On Wed, Jul 08, 2009, Arthur Furlan wrote:
I usually have various domains in a same mailserver and I use to
have a webmail.domain-name.org DNS entry for each of them. I also
use to configure all these DNS entries in a same Apache's VirtualHost
(using ServerAlias) and then I can access the same instance of
SquirrelMail, under different server names (webmail.example1.org,
webmail.example2.org, etc.), but sharing the same configuration and
same VirtualHost in Apache.
In this scenario, I usually need to add specific domain
configurations in SquirrelMail like changing the $org_name,
$org_title, $org_logo, $plugins, etc. and to be able to do that I
needed to patch the default /etc/squirrelmail/config.php to load a
new configuration file, based on the PHP's variable
$_SERVER['SERVER_NAME']. This is a very useful feature for me and that
I think could be added in the SquirrelMail default package.
I've hit this case myself, and I think it's an elegant way to solve it
indeed. Apparently the Squirrelmail vlogin plugin is made for this
purpose:
http://squirrelmail.org/plugin_view.php?id=47
but it's not packaged. I've looked at the plugin, and it seemed very
rich in functionality, but I didn't really want to start messing with
this plugin and also add the compatibility plugin just for the sake
of pointing at a different system-wide config file for this or that
domain. Still, I wanted to mention this option in this bug; it might
be useful in other cases.
I do have a slightly different config fragment from yours:
--- config.php2009-07-08 09:38:07.0 -0300
+++ config-patched.php2009-07-08 09:39:46.0 -0300
@@ -219,3 +219,7 @@
$config_location_base = '';
@include SM_PATH . 'config/config_local.php';
+
+// specific domain configurations
+$config_domain = SM_PATH .
config/config_local-{$_SERVER['SERVER_NAME']}.php;
+@include $config_domain;
I do:
/* include VirtualHost specific config if present */
@include SM_PATH . config/config_{$_SERVER['HTTP_HOST']}.php;
and I have the config at /etc/squirrelmail/config_$host.php.
I suspect it would be a good idea to guard the include with some test
on the contents of SERVER_NAME / HTTP_HOST though.
Cheers,
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645629: [p-a-s] Drop usplash related entry (usplash was RM-ed)
Package: buildd.debian.org Severity: wishlist Tags: patch Hi While looking at armel-specific entries in P-a-s, I've noticed one related to usplash which was removed from Debian; the package itself doesn't seem to belong to Debian either (debian-edu-artwork-usplash). (Patch attached) Cheers, -- Loïc Minier From 895f3993022306da52c54994b9aa3add03ccb164 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org Date: Mon, 17 Oct 2011 15:32:33 +0200 Subject: [PATCH] Drop debian-edu-artwork-usplash; usplash was RMed --- Packages-arch-specific |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 9358f9c..240d954 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -49,7 +49,6 @@ crash: amd64 i386 ia64 alpha powerpc # not yet ported to other platform %digitools: i386 # [ANAIS] %drawterm: !hppa # No source support %drdsl: i386 amd64 # [ANAIS] -debian-edu-artwork-usplash: i386 amd64 powerpc sparc armel# needs usplash dosemu: i386 amd64# Hardcoded i386 assembler e3: i386 kfreebsd-i386 amd64 kfreebsd-amd64 # i386 assembly %eep24c: amd64 i386 kfreebsd-i386 kfreebsd-amd64 hurd-i386 # [?] ANAIS, sys/io.h -- 1.7.5.4
Bug#645631: [p-a-s] Please drop obsolete gnome-ppp entry
Package: buildd.debian.org Severity: wishlist Tags: patch Hi I grepped the gnome-ppp source and it doesn't mention getcontext(); also, it built fine on armhf (in debian-ports). (Patch attached) Thanks, -- Loïc Minier From ffa86f5a1138d42b36c752a00b969e4d2696cafe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org Date: Mon, 17 Oct 2011 15:51:26 +0200 Subject: [PATCH] Drop gnome-ppp; built on armhf, no getcontext use --- Packages-arch-specific |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 9358f9c..21d13c1 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -72,7 +72,6 @@ fdflush: alpha i386 # i386/alp %gmod: i386 # i386 specific %gpmudmon-applet: powerpc # PMUD is powerpc APM %gnome-mount: !linux-any # superseded on linux by gvfs/g-d-u (#591429) -%gnome-ppp: !armel # no working getcontext() %gnu-efi: amd64 i386 ia64 lpia kfreebsd-amd64 # EFI specific %gnumach: hurd-i386 i386 kfreebsd-i386 # hurd kernel %google-perftools: amd64 i386 ia64 powerpc # not yet ported to other archs -- 1.7.5.4
Bug#645639: [p-a-s] Please drop valgrind entry from P-a-s
Package: buildd.debian.org Severity: wishlist Tags: patch Hi P-a-s entry for valgrind is: %valgrind: i386 amd64 powerpc lpia armel # Needs ported (asm, arch knwldge) Package control file has: Architecture: i386 amd64 powerpc armel armhf armhf was added in archive but not to P-a-s, and P-a-s allows lpia, but that's not very useful anymore. Would you please just drop valgrind from P-a-s entirely? (Patch attached) It would seem Auto-not-for-us should be good enough here. Thanks, -- Loïc Minier From b17efeb4ea527e3e0f58d4eb57a38977a0ca6483 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org Date: Mon, 17 Oct 2011 16:23:47 +0200 Subject: [PATCH] Remove valgrind; Auto-not-for-us is enough --- Packages-arch-specific |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 9358f9c..fcdbb73 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -268,7 +268,6 @@ toshutils: i386 amd64 # x86 spec %user-mode-linux: i386 amd64 # [?] ANAIS %uswsusp: i386 amd64 powerpc v86d: amd64 i386 # x86 specific -%valgrind: i386 amd64 powerpc lpia armel # Needs ported (asm, arch knwldge) %vbetool: !hppa !ia64 !m68k !mips !mipsel !powerpc !sh4 !sparc # sys/io.h %vegastrike: !m68k # requested by Mike Furr mf...@debian.org, see 207578 vmelilo: m68k # m68k (VME) lilo -- 1.7.5.4
Bug#645642: Please add armhf to architecture list
Package: yforth Version: 0.1beta-21 Severity: wishlist Hi I see yforth lists armel armeb and arm in control, would you please also list armhf? It should work just as well as armel, the only difference being floating point calling conventions, and that's hidden by GCC AFAICT. Also, I checked Packages-arch-specific and it has: yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compiler while your control has: Architecture: alpha amd64 arm armeb armel hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 m68k powerpc ppc64 sparc what's puzzling is that you've listed 64-bits arches in control, but debian/changelog says: yforth (0.1beta-10) frozen unstable; urgency=low * update control file to account for yforth not working on 64 bit machines. Instead of 'any', specify i386/m68k/sparc/arm. I *think* all of those should work. Update documentation to include my best contact info for. the upstream author, and acknowledge that there is no longer an upstream. site for this package. Closes 32413. -- Bdale Garbee bd...@gag.com Tue, 26 Jan 1999 09:18:24 -0700 so maybe it's time to revert back to Architecture: any? Thanks, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645647: [p-a-s] Please drop lcd4linux; built on all architectures already
Package: buildd.debian.org Severity: wishlist Tags: patch Hi Please drop lcd4linux from P-a-s, it built on all Debian architectures already and lists any in control. (Patch attached) Thanks, -- Loïc Minier From f1ced2ced6c8f6f17c06112f5d28d48ea4b2c40f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org Date: Mon, 17 Oct 2011 17:20:23 +0200 Subject: [PATCH] Drop lcd4linux; built on all arches anyway --- Packages-arch-specific |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 9358f9c..63b6f08 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -103,7 +103,6 @@ kon2: i386# Hardcode %ia32-libs: amd64 ia64 # ia32 compat libs for amd64,ia64 %ia32-libs-gtk: amd64 ia64 # ia32 compat libs for amd64,ia64 %ia32-libs-core: ia64 # ia32 compat libs, ia64-only bundle -%lcd4linux: amd64 armel i386 # sys/io.h %lcdproc: !s390 !s390x # this hardware cannot be attached %ldc: !s390 !s390x # needs porting %libacpi: amd64 i386 ia64 lpia # acpi is i386/ia64 specific -- 1.7.5.4
Bug#645652: Please add armhf to Architecture list
Package: kexec-tools
Version: 2.0.2-3
Severity: wishlist
Tags: patch
Hi
Please add armhf to Architecture list per attached patch; kexec-tools
built on armhf for me with the patch applied.
Thanks,
--
Loïc Minier
diff -u kexec-tools-2.0.2/debian/control kexec-tools-2.0.2/debian/control
--- kexec-tools-2.0.2/debian/control
+++ kexec-tools-2.0.2/debian/control
@@ -7,7 +7,7 @@
Standards-Version: 3.9.2
Package: kexec-tools
-Architecture: i386 amd64 ppc64 powerpc ia64 s390 arm armel sh4
+Architecture: i386 amd64 ppc64 powerpc ia64 s390 arm armel armhf sh4
Depends: ${shlibs:Depends}, ${misc:Depends}, debconf
Description: tools to support fast kexec reboots
This package provides tools to load a kernel into memory and then
diff -u kexec-tools-2.0.2/debian/changelog kexec-tools-2.0.2/debian/changelog
--- kexec-tools-2.0.2/debian/changelog
+++ kexec-tools-2.0.2/debian/changelog
@@ -1,3 +1,9 @@
+kexec-tools (1:2.0.2-3.1) unstable; urgency=low
+
+ * Add armhf to Architecture list.
+
+ -- Loïc Minier loic.min...@linaro.org Mon, 17 Oct 2011 17:38:11 +0200
+
kexec-tools (1:2.0.2-3) unstable; urgency=low
* Added check for link_in_boot in kernel-img.conf and update kexec
Bug#645654: Please add armhf to Architecture list
Package: nictools-pci
Version: 1.3.8-1.2
Severity: wishlist
Tags: patch
Hi
After adding armhf to the Architecture list, this package built fine on
armhf; please apply the attached patch.
Thanks,
--
Loïc Minier
diff -u nictools-pci-1.3.8/debian/changelog nictools-pci-1.3.8/debian/changelog
--- nictools-pci-1.3.8/debian/changelog
+++ nictools-pci-1.3.8/debian/changelog
@@ -1,3 +1,9 @@
+nictools-pci (1.3.8-1.3) natty; urgency=low
+
+ * Add armhf to Architecture list.
+
+ -- Loïc Minier loic.min...@linaro.org Mon, 17 Oct 2011 17:44:19 +0200
+
nictools-pci (1.3.8-1.2) unstable; urgency=low
* Non-maintainer upload.
diff -u nictools-pci-1.3.8/debian/control nictools-pci-1.3.8/debian/control
--- nictools-pci-1.3.8/debian/control
+++ nictools-pci-1.3.8/debian/control
@@ -6,7 +6,7 @@
Build-Depends: debhelper (= 4.0)
Package: nictools-pci
-Architecture: i386 arm armeb armel alpha amd64
+Architecture: i386 arm armeb armel armhf alpha amd64
Depends: ${shlibs:Depends}
Suggests: nictools-nopci
Description: Diagnostic tools for many PCI ethernet cards
Bug#645664: Please add armhf to control
Package: nikwi
Version: 0.0.20060823-2
Severity: wishlist
Tags: patch
Hi
Your package builds fine on armhf; would you please apply the attached
patch?
Would you know why it doesn't build on some architectures?
(I'll request removal of the Packages-arch-specific entry since it
matches your control file.)
Thanks,
--
Loïc Minier
diff -u nikwi-0.0.20060823/debian/changelog nikwi-0.0.20060823/debian/changelog
--- nikwi-0.0.20060823/debian/changelog
+++ nikwi-0.0.20060823/debian/changelog
@@ -1,3 +1,9 @@
+nikwi (0.0.20060823-2.1) unstable; urgency=low
+
+ * Add armhf to Architecture list.
+
+ -- Loïc Minier loic.min...@linaro.org Mon, 17 Oct 2011 17:56:23 +0200
+
nikwi (0.0.20060823-2) unstable; urgency=low
[ Miriam Ruiz ]
diff -u nikwi-0.0.20060823/debian/control nikwi-0.0.20060823/debian/control
--- nikwi-0.0.20060823/debian/control
+++ nikwi-0.0.20060823/debian/control
@@ -10,7 +10,7 @@
Homepage: http://www.badsectoracula.com/games/nikwi/
Package: nikwi
-Architecture: i386 alpha amd64 arm armel kfreebsd-i386 kfreebsd-amd64
hurd-i386 ia64 mipsel
+Architecture: i386 alpha amd64 arm armel armhf kfreebsd-i386 kfreebsd-amd64
hurd-i386 ia64 mipsel
Depends: nikwi-data (= ${source:Version}), ${shlibs:Depends}, ${misc:Depends}
Description: platform game where your goal is to collect candies
You play the role of a 9 year old boy in his absolute dream: a world made
Bug#645669: Fails to build on armhf
Package: ocamlgsl Version: 0.6.0-7 Severity: wishlist Hi This is a tracking bug to note that ocamlgsl needs porting on armhf; it currently fails to build with: ocamlc -ccopt ' -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall ' -c mlgsl_ieee.c In file included from mlgsl_ieee.c:12:0: wrappers.h:13:2: error: #error Architectures with double-word alignment for doubles are not supported (attaching full build log) Cheers, -- Loïc Minier sbuild (Debian sbuild) 0.60.9 (14 Feb 2011) on dog ╔══╗ ║ ocamlgsl 0.6.0-7 (armhf) 17 oct. 2011 19:44 ║ ╚══╝ Package: ocamlgsl Version: 0.6.0-7 Source Version: 0.6.0-7 Architecture: armhf Ign http://mirror.dooz.org sid InRelease Hit http://mirror.dooz.org sid Release.gpg Hit http://mirror.dooz.org sid Release Ign http://mirror.dooz.org sid/main armel Packages/DiffIndex Hit http://mirror.dooz.org sid/main TranslationIndex Hit http://mirror.dooz.org sid/main armel Packages Ign http://ftp.debian-ports.org sid InRelease Ign http://ftp.debian-ports.org unreleased InRelease Hit http://ftp.debian-ports.org sid Release.gpg Hit http://ftp.debian-ports.org unreleased Release.gpg Hit http://ftp.debian-ports.org sid Release Hit http://ftp.debian-ports.org unreleased Release Hit http://ftp.debian-ports.org sid/main armhf Packages Ign http://ftp.debian-ports.org sid/main TranslationIndex Hit http://ftp.debian-ports.org unreleased/main armhf Packages Ign http://ftp.debian-ports.org unreleased/main TranslationIndex Ign http://ftp.debian-ports.org sid/main Translation-en Ign http://ftp.debian-ports.org unreleased/main Translation-en Reading package lists... Reading package lists... Building dependency tree... Reading state information... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. ┌──┐ │ Fetch source files │ └──┘ Local sources ─ ocamlgsl_0.6.0-7.dsc exists in .; copying to chroot Check arch ── ┌──┐ │ Install core build dependencies (internal resolver) │ └──┘ Build-Depends: build-essential, fakeroot Checking for already installed dependencies... build-essential: already installed (11.5) fakeroot: already installed (1.18.1-1) Checking for dependency conflicts... Installing positive dependencies: Reading package lists... Building dependency tree... Reading state information... The following packages were automatically installed and are no longer required: libppl9 libpwl5 libcloog-ppl0 libgmpxx4ldbl libppl-c4 Use 'apt-get autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Removing negative dependencies: Reading package lists... Building dependency tree... Reading state information... The following packages were automatically installed and are no longer required: libppl9 libpwl5 libcloog-ppl0 libgmpxx4ldbl libppl-c4 Use 'apt-get autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Checking correctness of dependencies... ┌──┐ │ Install ocamlgsl build dependencies (internal resolver) │ └──┘ Build-Depends: libc6-dev | libc-dev, gcc (= 4:4.4.3), g++ (= 4:4.4.3), make, dpkg-dev (= 1.13.5), cdbs (= 0.4.23-1.1), debhelper (= 5), dpatch, ocaml-nox (= 3.10.0-9), ocaml-findlib (= 1.1.2pl1-4), libgsl0-dev, chrpath, gawk, camlp4 (= 3.10.0), dh-ocaml (= 0.9.1) Checking for already installed dependencies... libc6-dev: already installed (2.13-21) gcc: already installed (4:4.6.1-3 = 4:4.4.3 is satisfied) g++: already installed (4:4.6.1-3 = 4:4.4.3 is satisfied) make: already installed (3.81-8.1) dpkg-dev: already installed (1.16.1.1 = 1.13.5 is satisfied) cdbs: missing Using default version 0.4.99 debhelper: missing Using default version 8.9.8 dpatch: missing ocaml-nox: missing Using default version 3.12.0-7 ocaml-findlib: missing Using default version 1.2.7+debian-1 libgsl0-dev: missing chrpath: missing gawk: missing camlp4: missing Using default version 3.12.0-7 dh-ocaml: missing Using default version 1.0.2 Checking for dependency conflicts... Installing positive dependencies: cdbs debhelper dpatch ocaml-nox ocaml-findlib libgsl0-dev chrpath gawk camlp4 dh-ocaml Reading package lists... Building dependency tree... Reading state information... The following packages
Bug#645670: Please list armhf in Architecture list
Package: qcontrol
Version: 0.4.2-6
Severity: wishlist
Tags: patch
Hi
Even if that's not the case right now, there might be devices where
qcontrol is useful in the future; I've prepared the attached patch to
add support for armhf, but if you'd rather not add it right now, just
close this bug!
(I'll request removal of the P-a-s entry since we have Auto-not-for-us
nowadays)
NB: I couldn't build the package, it fails with:
cc -Os -Wall -I /usr/include/lua5.1 -c -o evdev.o evdev.c
cc -llua5.1 -lpthread qcontrol.o ts209.o ts219.o ts409.o ts41x.o evdev.o -o
qcontrol
cc -lpthread -lm -ldl qcontrol.o ts209.o ts219.o ts409.o ts41x.o evdev.o
/usr/lib/liblua5.1.a -o qcontrol.udeb
cc: error: /usr/lib/liblua5.1.a: No such file or directory
which might be due to multiarch?
Thanks!
--
Loïc Minier
diff -u qcontrol-0.4.2/debian/control qcontrol-0.4.2/debian/control
--- qcontrol-0.4.2/debian/control
+++ qcontrol-0.4.2/debian/control
@@ -9,7 +9,7 @@
Homepage: http://qnap.nas-central.org/index.php/PIC_Control_Software
Package: qcontrol
-Architecture: armel
+Architecture: armel armhf
Depends: ${shlibs:Depends}, ${misc:Depends}, udev (= 0.141-2)
Description: hardware control for QNAP Turbo Station devices
Allows to send commands to the microcontroller of supported devices,
@@ -28,7 +28,7 @@
Package: qcontrol-udeb
Section: debian-installer
-Architecture: armel
+Architecture: armel armhf
Depends: ${shlibs:Depends}, ${misc:Depends}, udev-udeb (= 0.141-2),
event-modules
XC-Package-Type: udeb
Description: hardware control for QNAP Turbo Station devices
diff -u qcontrol-0.4.2/debian/changelog qcontrol-0.4.2/debian/changelog
--- qcontrol-0.4.2/debian/changelog
+++ qcontrol-0.4.2/debian/changelog
@@ -1,3 +1,9 @@
+qcontrol (0.4.2-6.1) unstable; urgency=low
+
+ * Add armhf to Architecture lists.
+
+ -- Loïc Minier loic.min...@linaro.org Mon, 17 Oct 2011 19:46:19 +0200
+
qcontrol (0.4.2-6) unstable; urgency=low
* qcontrol-udeb: depend on event-modules instead of input-modules.
Bug#645673: Please add support for armhf
Package: tcc
Version: 0.9.26~git20110616.330d2ee-4
Severity: wishlist
Tags: patch
Hey
The experimental version of your package built fine on armhf too; would
you mind adding support per the attached patch?
Thanks!
--
Loïc Minier
diff -Nru tcc-0.9.26~git20110616.330d2ee/debian/changelog
tcc-0.9.26~git20110616.330d2ee/debian/changelog
--- tcc-0.9.26~git20110616.330d2ee/debian/changelog 2011-08-03
17:53:43.0 +0200
+++ tcc-0.9.26~git20110616.330d2ee/debian/changelog 2011-10-17
20:23:18.0 +0200
@@ -1,3 +1,9 @@
+tcc (0.9.26~git20110616.330d2ee-4.1) experimental; urgency=low
+
+ * List armhf in Architecture lists.
+
+ -- Loïc Minier loic.min...@linaro.org Mon, 17 Oct 2011 20:23:01 +0200
+
tcc (0.9.26~git20110616.330d2ee-4) experimental; urgency=low
* Replace old patch fixing Hurd FTBFS by the one accepted upstream.
diff -Nru tcc-0.9.26~git20110616.330d2ee/debian/control
tcc-0.9.26~git20110616.330d2ee/debian/control
--- tcc-0.9.26~git20110616.330d2ee/debian/control 2011-08-03
17:53:43.0 +0200
+++ tcc-0.9.26~git20110616.330d2ee/debian/control 2011-10-17
20:22:54.0 +0200
@@ -11,7 +11,7 @@
Vcs-Git: git://anonscm.debian.org/collab-maint/tcc.git
Package: tcc
-Architecture: any-i386 any-amd64 armel
+Architecture: any-i386 any-amd64 armel armhf
Depends: ${shlibs:Depends}, ${misc:Depends}
Recommends: libc6-dev | libc-dev
Provides: c-compiler
@@ -30,7 +30,7 @@
Package: libtcc-dev
Section: libdevel
-Architecture: any-i386 any-amd64 armel
+Architecture: any-i386 any-amd64 armel armhf
Depends: ${misc:Depends}
Description: Fast library for dynamic code generation
Libtcc is a library that uses tcc, a compiler several times faster than
Bug#645675: [p-a-s] misc armhf updates
Package: buildd.debian.org Severity: wishlist Tags: patch Hey Please find attached misc updates to P-a-s for armhf; I've testbuilt the packages. Some of the changes are to drop the entry entirely when that seemed adequate. Cheers, -- Loïc Minier From df6264a0572c0dbda8c49625c274d261f52a0c8d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org Date: Mon, 17 Oct 2011 17:52:13 +0200 Subject: [PATCH 1/9] Remove kexec-tools; Auto-not-for-us is better here --- Packages-arch-specific |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 9358f9c..680ab2e 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -97,7 +97,6 @@ ikarus: i386 # i386 assembly %isight-firmware-tools: i386 amd64 # [ANAIS] %joystick: !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !s390 !s390x # Linux specific, analog joysticks %kbd-chooser: !s390 !s390x # s390 installs don't use a keyboard -kexec-tools: armel i386 powerpc amd64 ppc64 ia64 s390 lpia# [ANAIS] based on syscall availability kgb: !arm # alignment issues, no upstream support kon2: i386# Hardcoded i386 assembler %ia32-libs: amd64 ia64 # ia32 compat libs for amd64,ia64 -- 1.7.5.4 From 6515649acf66f27e6dc59a2ae03ee7d6f1833b77 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org Date: Mon, 17 Oct 2011 17:53:12 +0200 Subject: [PATCH 2/9] Remove nictools-pci; Auto-not-for-us better here --- Packages-arch-specific |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 680ab2e..0e123a2 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -176,7 +176,6 @@ ndisgtk: i386 amd64 lpia # depends %ndiswrapper: i386 amd64 lpia # Windows DLL loader %newlib: i386 powerpc ppc64 %nictools-nopci: i386 # [?] ISA nictools -%nictools-pci: i386 arm armel alpha # [ANAIS] nikwi: alpha amd64 arm armel kfreebsd-i386 kfreebsd-amd64 hurd-i386 ia64 mipsel # Only little endian support nvidia-xconfig: i386 amd64 ia64 # i386 specific, but match what's in the archive %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific -- 1.7.5.4 From 778ba403adfed498d5c434b7136e9837f28ed8da Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org Date: Mon, 17 Oct 2011 17:54:17 +0200 Subject: [PATCH 3/9] Add lcd4linux on armhf; built fine --- Packages-arch-specific |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 0e123a2..f9bbab8 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -102,7 +102,7 @@ kon2: i386# Hardcode %ia32-libs: amd64 ia64 # ia32 compat libs for amd64,ia64 %ia32-libs-gtk: amd64 ia64 # ia32 compat libs for amd64,ia64 %ia32-libs-core: ia64 # ia32 compat libs, ia64-only bundle -%lcd4linux: amd64 armel i386 # sys/io.h +%lcd4linux: amd64 armel armhf i386 # sys/io.h %lcdproc: !s390 !s390x # this hardware cannot be attached %ldc: !s390 !s390x # needs porting %libacpi: amd64 i386 ia64 lpia # acpi is i386/ia64 specific -- 1.7.5.4 From 3b0df39eae8ca6ae3564a48241aa26af5ab947bc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org Date: Mon, 17 Oct 2011 19:09:37 +0200 Subject: [PATCH 4/9] Remove nikwi; Auto-not-for-us better here --- Packages-arch-specific |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index f9bbab8..9fa593a 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -176,7 +176,6 @@ ndisgtk: i386 amd64 lpia # depends %ndiswrapper: i386 amd64 lpia # Windows DLL loader %newlib: i386 powerpc ppc64 %nictools-nopci: i386 # [?] ISA nictools -nikwi: alpha amd64 arm armel kfreebsd-i386 kfreebsd-amd64 hurd-i386 ia64 mipsel # Only little endian support nvidia-xconfig: i386 amd64 ia64 # i386 specific, but match what's in the archive %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific nspluginwrapper: amd64 # amd64 specific -- 1.7.5.4 From 9e053eff1961d89c5e80705028868f4a7bc18073 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org Date: Mon, 17 Oct 2011 19:10:56 +0200 Subject: [PATCH 5/9] Add linux-wlan-ng on armhf; built fine --- Packages-arch-specific |2 +- 1 files changed, 1
Bug#645692: Support for hard-float calling convention and flag to select the ARM ABI
Package: tcc Version: 0.9.26~git20110616.330d2ee-4 Severity: wishlist Hi It would be nice if TCC supported the hard-float ABI used on armhf (uses the FPU regs to pass floating point values). In fact, it would be nice if TCC allowed selection of the ARM ABI it's targetting, e.g. ARMv4...ARMv7, Thumb/ARM mode, OABI vs. EABI, soft VFP / hard VFP / no VFP. (Note that currently the supported ABI is the one of the buildd, which might be higher than the base requirement to run the Debian port.) Thanks! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644583: postfix smtpd_client_port_logging and smtpd_tls_wrappermode errors
Package: logcheck
Version: 1.3.14
Severity: wishlist
Tags: patch
Hi there
I use postfix with smtpd_client_port_logging = yes and I also
configured it to provide SMTPS/SSMTP with smtpd_tls_wrappermode=yes.
Concerning smtpd_client_port_logging, some regexps in logcheck have
optional port information while others don't.
Concerning smtpd_tls_wrappermode, this doesn't change anything except
that it's more common that postfix misses remote IP and port
information (and obviously reverse DNS) for clients, typically after a
port scan. Again, some log messages allow for unknown in the place
of the IP address but some miss this.
I recently got this:
Oct 7 03:11:43 host postfix/smtpd[27300]: setting up TLS connection from
unknown[unknown]:unknown
Oct 7 03:11:43 host postfix/smtpd[27300]: SSL_accept error from
unknown[unknown]:unknown: -1
Oct 7 03:11:43 host postfix/smtpd[27300]: lost connection after CONNECT from
unknown[unknown]:unknown
Attaching a patch which allows for an optional port and allows some IP
and ports to be unknown for the above messages.
Cheers,
--
Loïc Minier
From c4e0e7478bc3227aa2d05daf4bc7b86592380c40 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org
Date: Fri, 7 Oct 2011 09:19:44 +0200
Subject: [PATCH] postfix: more unknown IP and optional port
---
rulefiles/linux/ignore.d.server/postfix |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/rulefiles/linux/ignore.d.server/postfix b/rulefiles/linux/ignore.d.server/postfix
index ce72d11..d41ca4b 100644
--- a/rulefiles/linux/ignore.d.server/postfix
+++ b/rulefiles/linux/ignore.d.server/postfix
@@ -77,7 +77,7 @@
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: certificate verification failed for [^[:space:]]+: untrusted issuer /.+$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: initializing the server-side TLS engine$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: issuer=[[:space:]]*/O=.*$
-^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: setting up TLS connection (to|from) [._[:alnum:]-]+(\[[[:xdigit:].:]{3,39}\](:[[:digit:]]+)?)?$
+^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: setting up TLS connection (to|from) [._[:alnum:]-]+(\[(unknown|[[:xdigit:].:]{3,39})\](:(unknown|[[:digit:]]+))?)?$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: verify error:num=10:certificate has expired$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: verify error:num=18:self signed certificate$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: verify error:num=19:self signed certificate in certificate chain$
@@ -105,7 +105,7 @@
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: NOQUEUE: reject: [[:upper:]]+ from [^[:space:]]+: 554( [[:digit:]]\.[[:digit:]]\.[[:digit:]])? [^[:space:]]*: Client host rejected: Access denied;( from=[^[:space:]]* to=[^[:space:]]+)? proto=E?SMTP( helo=[^[:space:]]+)?$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: NOQUEUE: reject: [[:upper:]]+ from [^[:space:]]+\[[[:digit:].]{7,15}\]: 503 5\.5\.0 [^[:space:]]*: Client host rejected: Improper use of SMTP command pipelining; from=[^[:space:]]* to=[^[:space:]]+ proto=E?SMTP helo=[^[:space:]]+$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: OTP unavailable because can't read/write key database /etc/opiekeys: No such file or directory$
-^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: SSL_accept error from [._[:alnum:]-]+\[[[:xdigit:].:]{3,39}\]: -?[[:digit:]]+$
+^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: SSL_accept error from [._[:alnum:]-]+\[(unknown|[[:xdigit:].:]{3,39})\](:(unknown|[[:digit:]]+))?: -?[[:digit:]]+$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: [[:alnum:]]+: client=[._[:alnum:]-]+\[[[:xdigit:].:]{3,39}\]$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: [[:alnum:]]+: client=[^[:space:]]+, sasl_method=[-[:alnum:]]+, sasl_username=[-_.@[:alnum:]]+$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: [[:alnum:]]+: client=[^[:space:]]+, sasl_sender=.*$
@@ -119,7 +119,7 @@
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: [[:upper:][:digit:]]+: reject: RCPT from [^[:space:]]+\[[[:digit:].]{7,15}\]: [45][[:digit:]][[:digit:]] .+: User unknown in local recipient table; from=[^[:space:]]* to=[^[:space:]]+ proto=E?SMTP helo=[^[:space:]]+$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: [[:upper:][:digit:]]+: reject: [[:upper:]]+ from [^[:space:]]+\[[[:digit:].]{7,15}\]: 503 5\.5\.0 [[:upper:]]+: [[:alnum:]]+ command rejected: Improper use of SMTP command pipelining; from=[^[:space:]]* to=[^[:space:]]+ proto=E?SMTP helo=[^[:space:]]+$
^\w{3} [ :[:digit
Bug#644488: Ubuntu precise dist/series
Package: lintian Version: 2.5.3ubuntu1 Severity: wishlist Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch oneiric Hey The next Ubuntu dist/series will be named precise; attached debdiff adds support for it, would you mind merging it? Thanks! -- Loïc Minier diff -Nru lintian-2.5.3ubuntu1/checks/changes-file.desc lintian-2.5.3ubuntu2/checks/changes-file.desc --- lintian-2.5.3ubuntu1/checks/changes-file.desc 2011-09-08 22:16:46.0 +0200 +++ lintian-2.5.3ubuntu2/checks/changes-file.desc 2011-10-06 11:57:06.0 +0200 @@ -41,8 +41,8 @@ the ttdebian/changelog/tt file. . Your version string suggests this package is for Ubuntu, so your - distribution should be one of oneiric, natty, maverick, lucid, karmic, hardy, - or dapper. + distribution should be one of precise, oneiric, natty, maverick, lucid, + karmic, hardy, or dapper. Tag: multiple-distributions-in-changes-file Severity: important diff -Nru lintian-2.5.3ubuntu1/data/changelog-file/ubuntu-dists lintian-2.5.3ubuntu2/data/changelog-file/ubuntu-dists --- lintian-2.5.3ubuntu1/data/changelog-file/ubuntu-dists 2011-08-15 23:12:56.0 +0200 +++ lintian-2.5.3ubuntu2/data/changelog-file/ubuntu-dists 2011-10-06 11:57:17.0 +0200 @@ -8,3 +8,4 @@ maverick natty oneiric +precise diff -Nru lintian-2.5.3ubuntu1/debian/changelog lintian-2.5.3ubuntu2/debian/changelog --- lintian-2.5.3ubuntu1/debian/changelog 2011-09-13 21:47:08.0 +0200 +++ lintian-2.5.3ubuntu2/debian/changelog 2011-10-06 11:58:16.0 +0200 @@ -1,3 +1,10 @@ +lintian (2.5.3ubuntu2) oneiric; urgency=low + + * checks/changes-file.desc, data/changelog-file/ubuntu-dists: Add new +precise Ubuntu series. + + -- Loïc Minier loic.min...@ubuntu.com Thu, 06 Oct 2011 11:57:30 +0200 + lintian (2.5.3ubuntu1) oneiric; urgency=low * Merge from Debian unstable (LP: #846659). Remaining changes:
Bug#644489: Ubuntu precise dist/series
Package: vim
Version: 2:7.3.333-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch oneiric
Hi,
Please find attached a patch to list the next Ubuntu dist/series,
precise, in debchangelog and debsources.vim.
Thanks,
--
Loïc Minier
diff --git a/runtime/syntax/debchangelog.vim b/runtime/syntax/debchangelog.vim
index ae9c4b7..9657d3d 100644
--- a/runtime/syntax/debchangelog.vim
+++ b/runtime/syntax/debchangelog.vim
@@ -19,7 +19,7 @@ syn case ignore
Define some common expressions we can use later on
syn match debchangelogName contained ^[[:alnum:]][[:alnum:].+-]\+
syn match debchangelogUrgency contained ; urgency=\(low\|medium\|high\|critical\|emergency\)\( \S.*\)\=
-syn match debchangelogTarget contained \v %(frozen|unstable|%(testing|%(old)=stable)%(-proposed-updates|-security)=|experimental|%(lenny|squeeze)-%(backports%(-sloppy)=|volatile)|%(hardy|lucid|maverick|natty|oneiric)%(-%(security|proposed|updates|backports|commercial|partner))=)+
+syn match debchangelogTarget contained \v %(frozen|unstable|%(testing|%(old)=stable)%(-proposed-updates|-security)=|experimental|%(lenny|squeeze)-%(backports%(-sloppy)=|volatile)|%(hardy|lucid|maverick|natty|oneiric|precise)%(-%(security|proposed|updates|backports|commercial|partner))=)+
syn match debchangelogVersion contained (.\{-})
syn match debchangelogCloses contained closes:\_s*\(bug\)\=#\=\_s\=\d\+\(,\_s*\(bug\)\=#\=\_s\=\d\+\)*
syn match debchangelogLP contained \clp:\s\+#\d\+\(,\s*#\d\+\)*
diff --git a/runtime/syntax/debsources.vim b/runtime/syntax/debsources.vim
index 448beb7..0e953da 100644
--- a/runtime/syntax/debsources.vim
+++ b/runtime/syntax/debsources.vim
@@ -23,7 +23,7 @@ syn match debsourcesComment/#.*/ contains=@Spell
Match uri's
syn match debsourcesUri+\(http://\|ftp://\|[rs]sh://\|debtorrent://\|\(cdrom\|copy\|file\):\)[^' ]\++
-syn match debsourcesDistrKeyword +\([[:alnum:]_./]*\)\(lenny\|squeeze\|wheezy\|\(old\)\=stable\|testing\|unstable\|sid\|rc-buggy\|experimental\|hardy\|lucid\|maverick\|natty\|oneiric\)\([-[:alnum:]_./]*\)+
+syn match debsourcesDistrKeyword +\([[:alnum:]_./]*\)\(lenny\|squeeze\|wheezy\|\(old\)\=stable\|testing\|unstable\|sid\|rc-buggy\|experimental\|hardy\|lucid\|maverick\|natty\|oneiric\|precise\)\([-[:alnum:]_./]*\)+
Associate our matches and regions with pretty colours
hi def link debsourcesLineError
Bug#644154: Untrusted connections for opportunistic TLS
Package: logcheck
Version: 1.3.14
Severity: minor
Tags: patch
Hey
When I started doing opportunistic TLS, Postfix warned of connections
to site with self-signed certificates. I would think logcheck should
still warn about this by default, and hence I'm proposing the attached
patch which proposes an alternate logcheck entry but disabled by
default.
This is against current git at time of writing.
Cheers,
--
Loïc Minier
From 0d71fad7511ed2ac735b00c65700c4d0afd80022 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@debian.org
Date: Mon, 3 Oct 2011 13:37:18 +0200
Subject: [PATCH] i.d.s/postfix: opportunistic TLS alternate check
Unverified TLS connection should probably be raised by logcheck on
sites which want strict TLS behavior, but when configuring Postfix for
opportunistic TLS, these are frequent with sites using self-signed
certificates. Offer an alternate logcheck entry which allows Untrusted
connections, but comment it out by default.
---
rulefiles/linux/ignore.d.server/postfix |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/rulefiles/linux/ignore.d.server/postfix b/rulefiles/linux/ignore.d.server/postfix
index ce72d11..9f4b2e0 100644
--- a/rulefiles/linux/ignore.d.server/postfix
+++ b/rulefiles/linux/ignore.d.server/postfix
@@ -60,6 +60,9 @@
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtp\[[[:digit:]]+\]: warning: mailer loop: best MX for [^[:space:]]+ is local$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtp\[[[:digit:]]+\]: warning: no MX host for [^[:space:]]+ has a valid (A|address) record$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: ((Anonymous|Trusted|Verified) )?TLS connection established (to|from) [^[:space:]]+: (TLSv1|SSLv[23]) with cipher [^[:space:]]+ \([/[:digit:]]+ bits\)$
+# Uncomment this alternate version if you're using opportunistic TLS and want
+# to ignore Untrusted connections
+#^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: ((Anonymous|Trusted|Verified|Untrusted) )?TLS connection established (to|from) [^[:space:]]+: (TLSv1|SSLv[23]) with cipher [^[:space:]]+ \([/[:digit:]]+ bits\)$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: (Peer|Server) certificate could not be verified$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: Unverified: subject_CN=.*$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd?\[[[:digit:]]+\]: Verified: subject_CN=.*, issuer=.*$
--
1.7.5.4
Bug#643667: Broken symlinks on upgrade due to plain c_rehash call
Package: ca-certificates Version: 20110502+nmu1 Severity: serious Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu oneiric ubuntu-patch Hi See also: https://bugs.launchpad.net/ubuntu/oneiric/+source/ca-certificates/+bug/854927 ca-certificates.postinst runs: # Call c_rehash when upgrading from older versions to that we # have both the old and new style of symlink if [ ! -z $2 ]; then if dpkg --compare-versions $2 le 20090814+nmu3; then c_rehash fi fi but a plain c_rehash call is wrong because at this point there might be a /etc/ssl/certs/ca-certificates.crt file with all certificates that c_rehash picks up and links to. Instead, this file should be removed, then c_rehash should be called after clearing all other symlinks, then ca-certificates.crt should be regenerated. update-ca-certificates --fresh is meant to do that, but didn't move /etc/ssl/certs/ca-certificates.crt away. The attached patch moves /etc/ssl/certs/ca-certificates.crt away (credit to Steve Langasek for fixing this), and removes the c_rehash upgrade snippet in favor. NB: The patch needs to be updated with this bug number and the uploaded version (see XXXs in patch). Cheers, -- Loïc Minier diff -Nru ca-certificates-20110502+nmu1/debian/changelog ca-certificates-20110502+nmu2/debian/changelog --- ca-certificates-20110502+nmu1/debian/changelog 2011-08-31 04:02:49.0 +0200 +++ ca-certificates-20110502+nmu2/debian/changelog 2011-09-28 15:45:59.0 +0200 @@ -1,3 +1,18 @@ +ca-certificates (20110502+nmu2) UNRELEASED; urgency=low + + [ Steve Langasek ] + * sbin/update-ca-certificates: move the ca-certificates.crt bundle out of +the way before calling c_rehash, so that symlinks don't accidentally get +pointed here, breaking openssl certificate verification. LP: #854927. + + [ Loïc Minier ] + * Drop bogus c_rehash on upgrades, which caused issue when +ca-certificates.crt was still in place; instead, call +update-ca-certificates --fresh on upgrades to this version, and +the usual update-ca-certificates otherwise; closes: #XXX. + + -- Loïc Minier l...@debian.org Wed, 28 Sep 2011 15:44:05 +0200 + ca-certificates (20110502+nmu1) unstable; urgency=high * Non-maintainer upload by the Security Team. diff -Nru ca-certificates-20110502+nmu1/debian/postinst ca-certificates-20110502+nmu2/debian/postinst --- ca-certificates-20110502+nmu1/debian/postinst 2011-04-21 19:37:20.0 +0200 +++ ca-certificates-20110502+nmu2/debian/postinst 2011-09-28 15:42:28.0 +0200 @@ -137,13 +137,12 @@ -e 's/^[[:space:]]*1[[:space:]]*/!/' \ /etc/ca-certificates.conf fi - update-ca-certificates - # Call c_rehash when upgrading from older versions to that we - # have both the old and new style of symlink - if [ ! -z $2 ]; then - if dpkg --compare-versions $2 le 20090814+nmu3; then - c_rehash - fi + # fix bogus symlink to ca-certificates.crt on upgrades; see + # Debian #XXX; drop after wheezy + if dpkg --compare-versions $2 lt-nl 20110502+nmu2+XXX; then + update-ca-certificates --fresh + else + update-ca-certificates fi ;; diff -Nru ca-certificates-20110502+nmu1/sbin/update-ca-certificates ca-certificates-20110502+nmu2/sbin/update-ca-certificates --- ca-certificates-20110502+nmu1/sbin/update-ca-certificates 2009-07-08 23:23:12.0 +0200 +++ ca-certificates-20110502+nmu2/sbin/update-ca-certificates 2011-09-28 15:43:57.0 +0200 @@ -127,8 +127,7 @@ done fi -chmod 0644 $TEMPBUNDLE -mv -f $TEMPBUNDLE $CERTBUNDLE +rm -f $CERTBUNDLE ADDED_CNT=$(wc -l $ADDED) REMOVED_CNT=$(wc -l $REMOVED) @@ -144,6 +143,9 @@ fi fi +chmod 0644 $TEMPBUNDLE +mv -f $TEMPBUNDLE $CERTBUNDLE + echo $ADDED_CNT added, $REMOVED_CNT removed; done. HOOKSDIR=/etc/ca-certificates/update.d
Bug#643020: linux 3.0 + multiarch FTBFS
Package: postfix
Version: 2.8.4-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch oneiric
Hi
Attached debdiff fixes build for linux 3.x kernels + multiarch library
pathes; from Ubuntu.
I wonder whether upstream will take these; if not, I would think this
could be rewritten by running ld -o /dev/null -l$lib directly in the
loop rather than testing for filenames -- or something like that.
Cheers,
--
Loïc Minier
diff -u postfix-2.8.4/makedefs postfix-2.8.4/makedefs
--- postfix-2.8.4/makedefs
+++ postfix-2.8.4/makedefs
@@ -363,9 +363,16 @@
exit 1
fi
SYSLIBS=-ldb
+ SEARCHDIRS=$(${CC-gcc} -print-search-dirs 2/dev/null \
+ | grep libraries | cut -f2- -d= \
+ | sed -e's/\:/\n/g' | xargs -n1 readlink -f \
+ | grep -v 'gcc\|/[0-9.]\+$' | uniq)
+ if [ -z $SEARCHDIRS ]; then
+ SEARCHDIRS=/usr/lib64 /lib64 /usr/lib /lib
+ fi
for name in nsl resolv
do
- for lib in /usr/lib64 /lib64 /usr/lib /lib
+ for lib in $SEARCHDIRS
do
test -e $lib/lib$name.a -o -e $lib/lib$name.so {
SYSLIBS=$SYSLIBS -l$name
diff -u postfix-2.8.4/debian/changelog postfix-2.8.4/debian/changelog
--- postfix-2.8.4/debian/changelog
+++ postfix-2.8.4/debian/changelog
@@ -1,3 +1,10 @@
+postfix (2.8.4-1ubuntu2) oneiric; urgency=low
+
+ * makedefs: fix FTBFS for Linux 3.x + multiarch with same approach as in
+2.8.1-1ubuntu1 for the backported chunk added in 2.8.3-1ubuntu1.
+
+ -- Lo?c Minier loic.min...@ubuntu.com Mon, 26 Sep 2011 01:47:30 +0200
+
postfix (2.8.4-1ubuntu1) oneiric; urgency=low
* Add back in apport. Debian lacks it, so the package is now
Bug#643022: cpio output on startup
Package: postfix
Version: 2.8.4-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch oneiric
Hi
Since I've added:
smtp_tls_CApath = /etc/ssl/certs
to main.cf, I get this on startup:
# /etc/init.d/postfix start
* Starting Postfix Mail Transport Agent postfix
2072 blocs
[ OK ]
the 2072 blocks are from cpio; changing the cpio invocation to use
--quiet fixes it for me.
Thanks,
--
Loïc Minier
diff -u postfix-2.8.4/debian/changelog postfix-2.8.4/debian/changelog
--- postfix-2.8.4/debian/changelog
+++ postfix-2.8.4/debian/changelog
@@ -1,3 +1,9 @@
+postfix (2.8.4-2) UNRELEASED; urgency=low
+
+ * Pass --quiet to cpio in init script.
+
+ -- Loïc Minier loic.min...@ubuntu.com Mon, 26 Sep 2011 18:11:06 +0200
+
postfix (2.8.4-1) unstable; urgency=low
[Scott Kitterman]
diff -u postfix-2.8.4/debian/init.d postfix-2.8.4/debian/init.d
--- postfix-2.8.4/debian/init.d
+++ postfix-2.8.4/debian/init.d
@@ -103,7 +103,7 @@
else mkdir --parent ${dest_dir%/*}
fi
# handle files in subdirectories
- (cd $ca_path find . -name '*.pem' -print0 | cpio -0pdL $dest_dir) 2/dev/null
+ (cd $ca_path find . -name '*.pem' -print0 | cpio -0pdL --quiet $dest_dir) 2/dev/null
c_rehash $dest_dir /dev/null 21
if [ $new = 1 ]; then
# and replace the old directory
only in patch2:
unchanged:
--- postfix-2.8.4.orig/makedefs.tmp
+++ postfix-2.8.4/makedefs.tmp
@@ -0,0 +1 @@
+# Do not edit -- this file documents how Postfix was built for your machine.
Bug#642314: Bug#628780: Wrong hash link to cacert.org.pem and wron certificat hash handling at all
Just thought of another minor issue with the new c_rehash handling multiple certs in the same file: when a piece of software follows the hashed symlink, the certificate it's looking for might not be the first one. Is this verified to work with gnutls and openssl implementations? I wonder whether this could confuse some software in Debian that might be using the ssl API in a way that only the first certificate is tried. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642314: c_rehash changes in 1.0.0e-1 break parsing of certs using DOS-style line endings
Package: openssl Version: 1.0.0e-1 Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu oneiric Hi The c_rehash patch submitted in Debian #628780 seems to prevent parsing of certificates using CRLF line endings. This was originally reported in https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/855454 Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628780: Wrong hash link to cacert.org.pem and wron certificat hash handling at all
Hi The patch from Debian #628780 caused a regression with certificates using CRLF line-endings, which prompted me to take a look at the discussion here. (Debian #642314 is the regression.) Outside of CRLF line-endings, there seems to be potential for more regressions in this patch: a) link_hash_cert() only searches for BEGIN CERTIFICATE, not for BEGIN X509 CERTIFICATE or BEGIN TRUSTED CERTIFICATE which are allowed in other parts of the file b) this requires a tempdir with write permissions, which might be a problem for certain deployments calling c_rehash c) this causes a lot of writes (each certificate is written to a tempfile which gets deleted); again, this might be a problem if some deployments run c_rehash on a large number of certificates I'm particularly worried about c) because the whole point of c_rehash is to speed up lookup when there is a large number of certificates (e.g. client certificates). If there is a large number of certificates, then writing each of them to a tempfile is going to be time consuming. If there are many certificates, one can also imagine that certificates are added/removed frequently, requiring frequent runs of c_rehash. The root problem here is really that the openssl command-line doesn't support multiple certificates in a single file, so why not fix that instead? e.g. we could add a flag to x509 to output information about ALL certificates (it already has tons of other random options). This would allow -fingerprint and -hash or even -text to be useful on files with multiple certificates. Then ca-certificates would get updated to use this flag (which probably wouldn't be the default for backwards-compatibility reasons.) In my eyes, the drawbacks of the patch are quite bad; perhaps it would be a better idea to: * split cacert.org.crt in two files, one per certificate; this would also allow administrators to enable certificates selectively in /etc/ca-certificates.conf * document the limitation in openssl / ca-certificates that only the first certificate gets picked up * optionally, we could let ca-certificates or c_rehash fail (if some flag is set and) if multiple certificates are in a single file Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628780: Wrong hash link to cacert.org.pem and wron certificat hash handling at all
/ ca-certificates that only the first certificate gets picked up A bad choice. In the particular case of cacert the most used certificate is the second one. This ends in the fact that cacert is useless at all in debian. This is on top of the earlier change, most notably for sysadmins installing their own local certificates. * optionally, we could let ca-certificates or c_rehash fail (if some flag is set and) if multiple certificates are in a single file The same bad choice. (same reason) - Tune c_rehash the way that it fulfils the mentioned issues. (Should be easy) Doesn't hurt; it would be best for the result to be upstreamable so that c_rehash behaves the same upstream and in Debian and derivatives. - Have two c_rehash tools. One for the users that want only hash one certificate per file and one for apt. That might be a bad solution as the one would remove the links from the other. - Introduce a complete new tool that handle the hashes. (Maybe in combination with the submitted fix of x509.) This does feel a bit weak, but it might be less problematic than changing the c_rehash behavior. Alternatively, having a flag to c_rehash to do different things might be a way to keep a single code base and support the two use cases. update-ca-certificates would call c_rehash --multiple-certs-per-file or something like that. Well, and it should not gets into oblivion that there are two alternative method's to calculate the hash. (-subject_hash and -subject_hash_old) I think they must be created both. Yes; that one actually worried me because the compat links are created after the new style links, but it should be ok because in the case of conflicts the suffix gets incremented. Sorry that I do not see the relevance of your case 'c'. I really do not. I suspect you're thinking as c_rehash as a tool used only by ca-certificates, when it's actually a general purpose tool; one can point openssl or other software like postfix, apache etc. at a CApath c_rehash-ed directory. People doing this are precisely the ones with a lot of certificates there, which means they get updated frequently. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635696: pbuilder-satisfydepends ignores last line of the .dsc
On Tue, Aug 09, 2011, Ian Jackson wrote: I can't remember why I used -classic, I'm afraid. There was a reason... -classic used to be the default implementation; some time ago, it was forked into a -experimental implementation which wasn't experimental in nature but added support for mixing the experimental dist in your sources.list (cherry-picking build-deps from experimental as needed). For all functional purposes, the -experimental version should be better than the -classic one. Then came the -aptitude version which is faster and relies on aptitude; the drawbacks is that it requires an external tool to be working and that it requires installing aptitude and its deps in the chroot, which means that it's not as minimal as it could be. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627444: cross-building cpio
On Fri, May 20, 2011, Steve McIntyre wrote: -#ifndef __WIN32__ +#ifndef lstat int lstat (); +#endif +#ifndef stat int stat (); #endif This does have the effect of defining stat and lstat when __WIN32__ is defined, which might not be desired (perhaps it's preferred to fail the WIN32 build earlier if the code tries to use stat or lstat when it shouldn't). I guess only the upstream developers can tell their preference here though. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634890: klibc-utils: sh.shared segmentation fault (armhf)
Might be related to the hardware bug described in: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/739374 which has a workaround in linux, bionic and possibly glibc; I wouldn't be surprized if klibc needed similar care. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544184: Reopening #544184 - typo in change
unarchive #544184 reopen #544184 found #544184 1:4.1.4.2+svn3283-3 stop Hey there Assuming /etc/securetty is case sensitive, #544184 isn't fixed as ttyama0 through 3 were added instead of ttyAMA0 through 3 (note the capitals). I grepped a recent linux tree to see whether there was any mention of the lower cased ones, but there wasn't; also, the original report confirms that it's uppercase. I can confirm that the first serial port on an ARM vexpress as emulated by QEMU or on real hardware is ttyAMA0. Currently, securetty.linux is sorted by major char number and mentions Documentation/devices.txt; this documentation file isn't really kept up-to-date though and some devices listed in this section of securetty.linux aren't in Documentation/devices.txt (e.g. OMAP serial ports); I would suggest listing the ttyAMA[0-3] devices near the ttyAM[0-3] ones as both are related to AMBA ttys; see linux/drivers/tty/serial/amba-pl010.c for ttyAM UARTs and drivers/tty/serial/amba-pl011.c for ttyAMA UARTs. (You might want to drop the mention of QEMU as these ports are what the real hardware uses.) Thanks! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630799: Splitting tools out to help build-deps install time
Package: man-db Version: 2.6.0.2-1 Severity: wishlist Hey there I've seen this while installing build-deps in chroots for years: Building database of manual pages ... and that's likely because I am too lazy to set man-db/auto-update properly. Pbuilder offers an optin hook to do this, and I'm sure this could be done in other software, but it turns out most build software doesn't bother with this. I checked random buildd logs of qemu and qemu-linaro in Debian and Ubuntu and found: Setting up man-db (2.6.0.2-1) ... Building database of manual pages ... this is particularly common because debhelper depends on man-db (as dh_installman calls man it seems); lintian also depends on man-db, but this is likely less of an issue on buildds. In the interest of saving buildd time without anyone having to set man-db/auto-update, I propose that we split the tools and the trigger / database handling in separate packages so that debhelper/lintian just depend on the tools, not on the presence of a database. NB: this is particularly bad on ports architectures where it often takes minutes to generate the DB for some reason Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630799: Splitting tools out to help build-deps install time
On Fri, Jun 17, 2011, Colin Watson wrote: I really don't want to do this. I'd rather optimise mandb. Ok; just so that I understand, is this about avoid confusion of the users, or complexity or...? I guess we can repurpose this bug to man-db is too slow on armel/ppc or something, which are arches where I've witnessed this. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625000: seabios: FTBFS: out/../src/bregs.h:40:5: error: duplicate member 'di_hi'
tags 625000 + patch
stop
Hey
I didn't try to rebuild the Debian package with the fix, but this seems
fixed upstream in 88db9fd632bf3f650244ec69e2f4fd6b2aa5fd3d; this is a
new error raised by gcc-4.6. Attaching the upstream diff.
Cheers,
--
Loïc Minier
From 88db9fd632bf3f650244ec69e2f4fd6b2aa5fd3d Mon Sep 17 00:00:00 2001
From: Kevin O'Connor ke...@koconnor.net
Date: Sat, 7 May 2011 13:56:48 -0400
Subject: [PATCH] Fix struct bregs - it shouldn't have multiple members with
the same name.
This fixes a compile error on gcc 4.6.
---
src/bregs.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/bregs.h b/src/bregs.h
index 9a381d0..f026fa8 100644
--- a/src/bregs.h
+++ b/src/bregs.h
@@ -37,9 +37,9 @@
struct bregs {
u16 ds;
u16 es;
-UREG(edi, di, di_hi, di_lo);
-UREG(esi, si, si_hi, si_lo);
-UREG(ebp, bp, bp_hi, bp_lo);
+UREG(edi, di, di8u, di8l);
+UREG(esi, si, si8u, si8l);
+UREG(ebp, bp, bp8u, bp8l);
UREG(ebx, bx, bh, bl);
UREG(edx, dx, dh, dl);
UREG(ecx, cx, ch, cl);
--
1.7.5.1
Bug#625000: seabios: FTBFS: out/../src/bregs.h:40:5: error: duplicate member 'di_hi'
On Thu, May 19, 2011, Aurelien Jarno wrote: This patch indeed fixes the reported issue, but the package still FTBFS due to a binutils bug. I'll report the bug to binutils later this week. binutils bug is http://sourceware.org/bugzilla/show_bug.cgi?id=12726 I think the fix was uploaded to unstable some hours ago -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625828: libipc-sharelite-perl: FTBFS on armel: test failures
On Sat, May 14, 2011, Niko Tyni wrote: I can reproduce this on abel.debian.org with both squeeze (Perl 5.10) and sid (5.12), but not on agricola.debian.org at all. Either kernel or hardware specific? I see from the build log that arnold.debian.org (the buildd) is running Linux 2.6.32 armel (armv5tel) which matches abel. It also failed on ancina.d.o (Linux 2.6.31-rc9 armel (armv5tel)) and alwyn.d.o (Linux 2.6.32 armel (armv5tel)). Dominic uploaded a binary package built on agricola.d.o (2.6.26-2-iop32x), where it never fails. The code uses semaphore operations for locking shared memory, and the bug seems to be that attaching the same shared memory segment twice and then accessing the second copy breaks locking altogether. There were testsuite failures sounding similar to this one in Ubuntu with older kernels; upgrading them solved the problem: https://bugs.launchpad.net/ubuntu/+source/libipc-sharelite-perl/+bug/299847 I guess either this issue is back or the specific kernel change which fixed this issue should be bisected -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592614: current snapshot ok for armv7
On Wed, May 11, 2011, Pierre Habouzit wrote: https://buildd.debian.org/status/fetch.php?pkg=valgrindarch=armelver=1%3A3.6.1-2stamp=1305095779 configure.in tests whether host_cpu matches armv7*; I think this is incorrect to start with as it should be fine to configure valgrind with --host=arm-linux-gnueabi (BTW debian/rules doesn't pass --build/--host ATM). A quick workaround would be to pass --host=armv7-linux-gnueabi to configure on armel, but the real fix is probably to change the upstream configure.in to build a C program with just asm(dmb) to see whether ARMv7 is available. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592614: current snapshot ok for armv7
On Wed, May 11, 2011, Pierre Habouzit wrote:
Looks like the easiest road is:
- armv7*)
+ arm*)
In the configure case ${host} in. I'll upload a -3 with that patch and
we'll see how far it goes
Yep, but upstream specifically want to test for arm = v7 as to fail
the build on = 6 which isn't supported, so that change wouldn't be
upstreamable :-/
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592614: current snapshot ok for armv7
On Tue, May 10, 2011, Pierre Habouzit wrote:
What should be done for that, s/arm/armel/ and add -marmv7a to the
CFLAGS at configure time, that's it?
Yup; ideally, you would test whether the toolchain config supports
ARMv7, and if it doesn't you add -march=armv7-a to the CFLAGS. This
means that no flags is added to e.g. Debian armhf or to Ubuntu's armel
or any Debian derivative which already turns on armv7-a (or higher).
Something like this rules snippet would work I guess:
CROSS :=
ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
CROSS := $(DEB_HOST_GNU_TYPE)-
endif
# this outputs 0 or 1 depending on whether a piece of assembly can be compiled
# with the *default* gcc flags; this is used to test the toolchain *default*
# configuration
check_asm = $(shell echo 'void foo(void) { __asm__ volatile($(1)); }' |
$(CROSS)gcc -x c -c - -o /dev/null 2/dev/null echo 1 || echo 0)
ifeq ($(DEB_HOST_ARCH_CPU),arm)
# whether the toolchain *default* configuration enables ARMv7
v7_asm := dmb
has_v7 := $(call check_asm, $(v7_asm))
ifneq ($(has_v7),1)
CFLAGS += -march=armv7-a
endif
endif
I'm mostly clueless about which arm CPU versions Debian is supposed to
support, should I wrap valgrind in some shell script that checks if the
CPU is recent enough to run valgrind and fail gracefully if not? and if
thats a good idea, how can I know which arm version the CPU supports?
That's a good idea idea; you could catch SIGILL or you could look at
/proc/cpuid or cpuinfo. This might also be known to eglibc, but I
don't know whether you can get this information via some API. I am not
sure you can rely on uname -m. Would someone have precise information
for this?
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576957: testrepository lacking dep on subunit
reopen #576957 found #576957 0.0.5-1 severity #576957 serious stop Hey After getting testrepository 0.0.5-1 I got on testr init: Traceback (most recent call last): File /usr/bin/testr, line 23, in module from testrepository.commands import run_argv File /usr/lib/python2.7/dist-packages/testrepository/commands/__init__.py, line 38, in module import subunit ImportError: No module named subunit This had been fixed in Ubuntu a while ago in: https://launchpad.net/ubuntu/+source/testrepository/0.0.3-1ubuntu1 then in Debian: http://packages.qa.debian.org/t/testrepository/news/20101021T210404Z.html then 0.0.4-1.1 got copied into Ubuntu but 0.0.5-1 didn't include the NMU changes, then propagated to Ubuntu. Reopening the Debian bug and reuploading the fix to Ubuntu. Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621420: Misbuilds busybox on ARM
On Sat, Apr 23, 2011, Matthias Klose wrote: On 04/09/2011 12:46 AM, Loïc Minier wrote: I'm attaching the corresponding gcc-linaro backport from bzr r99440. Linaro should forward this upstream. will pick it up from there. Sure; Ramana offered to do so, but didn't have time before his leave: http://lists.linaro.org/pipermail/linaro-toolchain/2011-April/001084.html I'll try to update this bug as this makes progress towards upstream. Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618616: arm build failure with latest binutils - usr/klibc/syscalls/_exit.S:29: Error: .size expression does not evaluate to a constant
On Thu, Apr 14, 2011, maximilian attems wrote: BTW, do you have any idea why the build process forces such odd and very old toolchain flags instead of just using the defaults? (it forces -march=armv4 -mtune=strongarm) what do you expect currently? I'd like if klibc would just build with the toolchain defaults, unless there is a reason to diverge; this would provide optimized binaries with exactly the optimization level selected in the toolchain. For instance in Debian armhf and Ubuntu armel, the defaults are armv7-a + thumb-2 which is faster and smaller code. It might also reveal build failures of klibc with these options and call for porting (of course the porters might force the flags to workaround the FTBFS temporarily). Finally, new versions of the ARM architecture have different ways to express certain assembly operations; for instance swp goes away and is replaced by things like strex and ldrex. This might be important in SMP contexts. Another issue with -march=armv4 is that the toolchain is getting worse over time for older CPUs; ARMv4 is getting really old, and I saw some toolchain regressions affecting older CPUs recently, simply because these aren't tested as much. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621420: Misbuilds busybox on ARM
Hey I don't know whether a new bug should be opened in the GCC bugzilla or not for the 4.5 branch, but this is the 4.6 bugfix: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44768#c9 (this comment links it to our problem) Mageia has a backported patch: http://svnweb.mageia.org/packages/cauldron/gcc/current/SOURCES/gcc_pr44768.patch (Thanks to Arnaud Patard for the above links!) Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621420: Misbuilds busybox on ARM
I'm attaching the corresponding gcc-linaro backport from bzr r99440.
--
Loïc Minier
=== modified file 'ChangeLog.linaro'
--- ChangeLog.linaro 2010-11-27 15:24:12 +
+++ ChangeLog.linaro 2010-11-27 15:30:38 +
@@ -1,3 +1,15 @@
+2010-11-24 Chung-Lin Tang clt...@codesourcery.com
+
+ 2010-07-08 Ramana Radhakrishnan ramana.radhakrish...@arm.com
+
+ PR bootstrap/44768
+
+ * cfgexpand.c (estimated_stack_frame_size): Make self-contained
+ with respect to current_function_decl. Pass decl of the function.
+ * tree-inline.h (estimated_stack_frame_size): Adjust prototype.
+ * ipa-inline.c (compute_inline_parameters): Pass decl to
+ estimated_stack_frame_size.
+
2010-11-16 Chung-Lin Tang clt...@codesourcery.com
2010-07-21 Richard Henderson r...@redhat.com
=== modified file 'gcc/cfgexpand.c'
--- gcc/cfgexpand.c 2010-10-04 00:50:43 +
+++ gcc/cfgexpand.c 2010-11-24 08:43:48 +
@@ -1248,8 +1248,8 @@
stack_vars_alloc = stack_vars_num = 0;
}
-/* Make a fair guess for the size of the stack frame of the current
- function. This doesn't have to be exact, the result is only used
+/* Make a fair guess for the size of the stack frame of the decl
+ passed. This doesn't have to be exact, the result is only used
in the inline heuristics. So we don't want to run the full stack
var packing algorithm (which is quadratic in the number of stack
vars). Instead, we calculate the total size of all stack vars.
@@ -1257,11 +1257,14 @@
vars doesn't happen very often. */
HOST_WIDE_INT
-estimated_stack_frame_size (void)
+estimated_stack_frame_size (tree decl)
{
HOST_WIDE_INT size = 0;
size_t i;
tree t, outer_block = DECL_INITIAL (current_function_decl);
+ tree old_cur_fun_decl = current_function_decl;
+ current_function_decl = decl;
+ push_cfun (DECL_STRUCT_FUNCTION (decl));
init_vars_expansion ();
@@ -1284,7 +1287,8 @@
size += account_stack_vars ();
fini_vars_expansion ();
}
-
+ pop_cfun ();
+ current_function_decl = old_cur_fun_decl;
return size;
}
=== modified file 'gcc/ipa-inline.c'
--- gcc/ipa-inline.c 2010-06-30 21:30:12 +
+++ gcc/ipa-inline.c 2010-11-24 08:43:48 +
@@ -1967,7 +1967,7 @@
/* Estimate the stack size for the function. But not at -O0
because estimated_stack_frame_size is a quadratic problem. */
- self_stack_size = optimize ? estimated_stack_frame_size () : 0;
+ self_stack_size = optimize ? estimated_stack_frame_size (node-decl) : 0;
inline_summary (node)-estimated_self_stack_size = self_stack_size;
node-global.estimated_stack_size = self_stack_size;
node-global.stack_frame_offset = 0;
=== modified file 'gcc/tree-inline.h'
--- gcc/tree-inline.h 2009-09-14 18:18:58 +
+++ gcc/tree-inline.h 2010-11-24 08:43:48 +
@@ -187,6 +187,6 @@
extern tree remap_type (tree type, copy_body_data *id);
extern gimple_seq copy_gimple_seq_and_replace_locals (gimple_seq seq);
-extern HOST_WIDE_INT estimated_stack_frame_size (void);
+extern HOST_WIDE_INT estimated_stack_frame_size (tree);
#endif /* GCC_TREE_INLINE_H */
Bug#621701: Doesn't guess compression type from ../*.orig.tar.*
Package: git-buildpackage Version: 0.5.20 Severity: wishlist Hi When using git-buildpackage against busybox.git, it failed to pick up the .orig.tar.bz2 from the parent dir. It worked with: --git-compression=bzip2 (BTW: I first tried passing --git-compression=bz2 -- perhaps you want to add an alias?) It seems compression will be guessed with pristine-tar branches, but not for .orig.tar upstream tarballs; that would be nice though! :-) Thanks for considering, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621137: Random exec failures on ARM; breaks boot -- /init: exec: line 306: run-init: Unknown error 2372692
On Thu, Apr 07, 2011, Joey Hess wrote: I've applied Loïc's patch to busybox git, but when I try to build a package to release, bits of the patch show up in debian/patches/debian-changes-1:1.18.4-1.1 Can someone who understands the byzantine complexity of this IMNSHO unncessesary path system make the upload? Perhaps you might also want to either add a HACKING file, like a few other parts of d-i that cannot simply be checked out of git and built have. Ah I should have submitted the changes in a branch of busybox.git; didn't spot the git repo -- my bad. Indeed the layout isn't too conventional: no pristine-tar branch, no upstream files in the repo, no upstream branch with e.g. imported tarballs or upstream history. Putting busybox_1.18.4-1.dsc from the archive into ../ and running git-buildpackage -S would fail as it couldn't find the upstream tarball with .orig.tar.gz. With --git-compression=bzip2 this worked. It seems gbp only autodetects the compression from pristine-tar branches; I've now filed a bug about this. debdiff on the resulting .dsc shows something close to my original debdiff -- no debian-changes patch -- so seems good to use. This can be set in debian/gbp.conf, which looked unintrusive enough that I've now pushed this; this can be dropped when gbp autodetects this as well, or if the package moves to a pristine-tar branch. I had a stab at documenting git-buildpackage and non-gbp use in a README.source; in the process I've noticed that my patch missed a call spot of tryexec (this is what happens when you redo a patch locally before sending it!) and fixed that; let me know if that's ok. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621137: Random exec failures on ARM; breaks boot -- /init: exec: line 306: run-init: Unknown error 2372692
On Fri, Apr 08, 2011, Loïc Minier wrote: It seems gbp only autodetects the compression from pristine-tar branches; I've now filed a bug about this. Debian #621701, with patch(es) now -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621701: Doesn't guess compression type from ../*.orig.tar.*
tags 621701 + patch stop Hi Attached is a patch series which adds some tests and adds support for this autodetection; tested in these cases: - one .bz2 tarball -- gets autodetected - two tarballs -- generates an error - two tarballs and debian/gbp.conf sets compression -- works - no tarball -- same error as before Thanks! -- Loïc Minier detect-compression-from-orig.tgz Description: application/gtar-compressed
Bug#618616: arm build failure with latest binutils - usr/klibc/syscalls/_exit.S:29: Error: .size expression does not evaluate to a constant
severity #618616 serious stop From a manual build of 1.5.21-1 today in sid: [...] TYPE uintptr_t: size 4, sign 0 TYPE unsigned int: size 4, sign 0 TYPE unsigned long: size 4, sign 0 TYPE void *: size 4, sign 0 gcc -Wp,-MD,usr/klibc/syscalls/._exit.o.d -D__ASSEMBLY__ -nostdinc -iwithprefix include -I/home/lool/klibc-1.5.21/usr/include/arch/arm -Iusr/include/arch/arm -I/home/lool/klibc-1.5.21/usr/include/bits32 -Iusr/include/bits32 -I/home/lool/klibc-1.5.21/usr/klibc/../include -Iusr/klibc/../include -I/home/lool/klibc-1.5.21/usr/include -Iusr/include -I/home/lool/klibc-1.5.21/linux/include -Ilinux/include -I/home/lool/klibc-1.5.21/linux/arch/arm/include -Ilinux/arch/arm/include -D__KLIBC__=1 -D__KLIBC_MINOR__=5 -D_BITSIZE=32 -fno-stack-protector -fwrapv -fno-exceptions -mabi=aapcs-linux -mno-thumb-interwork -Os -march=armv4 -mtune=strongarm -W -Wall -Wno-sign-compare -Wno-unused-parameter -D__ASSEMBLY__ -nostdinc -iwithprefix include -I/home/lool/klibc-1.5.21/usr/include/arch/arm -Iusr/include/arch/arm -I/home/lool/klibc-1.5.21/usr/include/bits32 -Iusr/include/bits32 -I/home/lool/klibc-1.5.21/usr/klibc/../include -Iusr/klibc/../include -I/home/lool/klibc-1.5.21/usr/include -Iusr/include -I/home/lool/klibc-1.5.21/linux/include -Ilinux/include -I/home/lool/klibc-1.5.21/linux/arch/arm/include -Ilinux/arch/arm/include -D__KLIBC__=1 -D__KLIBC_MINOR__=5 -D_BITSIZE=32 -fno-stack-protector -fwrapv -fno-exceptions -mabi=aapcs-linux -mno-thumb-interwork -Os -march=armv4 -mtune=strongarm -W -Wall -Wno-sign-compare -Wno-unused-parameter -D__ASSEMBLY__ -nostdinc -iwithprefix include -I/home/lool/klibc-1.5.21/usr/include/arch/arm -Iusr/include/arch/arm -I/home/lool/klibc-1.5.21/usr/include/bits32 -Iusr/include/bits32 -I/home/lool/klibc-1.5.21/usr/klibc/../include -Iusr/klibc/../include -I/home/lool/klibc-1.5.21/usr/include -Iusr/include -I/home/lool/klibc-1.5.21/linux/include -Ilinux/include -I/home/lool/klibc-1.5.21/linux/arch/arm/include -Ilinux/arch/arm/include -D__KLIBC__=1 -D__KLIBC_MINOR__=5 -D_BITSIZE=32 -fno-stack-protector -fwrapv -fno-exceptions -mabi=aapcs-linux -mno-thumb-interwork -Os -march=armv4 -mtune=strongarm -W -Wall -Wno-sign-compare -Wno-unused-parameter -c -o usr/klibc/syscalls/_exit.o usr/klibc/syscalls/_exit.S usr/klibc/syscalls/_exit.S: Assembler messages: usr/klibc/syscalls/_exit.S:29: Error: .size expression for __syscall does not evaluate to a constant make[5]: *** [usr/klibc/syscalls/_exit.o] Error 1 make[4]: *** [usr/klibc/syscalls] Error 2 -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621137: Random exec failures on ARM; breaks boot -- /init: exec: line 306: run-init: Unknown error 2372692
Package: busybox Version: 1:1.18.4-1 Severity: serious Hi Short version: debian/patches/applets-fallback.patch causes a regression on ARM in Debian 1.18 packages. Multiple users reported issues when upgrading their ARM device (specifically NSLU2 hardware -- slugs) to sid; they couldn't boot anymore; the serial console would show something like: [7.779891] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. /init: exec: line 306: run-init: Unknown error 2372692 [8.450448] Kernel panic - not syncing: Attempted to kill init! [8.452811] [c003d100] (unwind_backtrace+0x0/0xe0) from [c03e93c0] (panic+0x50/0x16c) [8.453186] [c03e93c0] (panic+0x50/0x16c) from [c0054050] (forget_original_parent+0xb4/0x1e4) Arnaud Patard and myself could reproduce in QEMU, with both versatile (ARMv5) and Versatile Express (ARMv7A) kernels. We considered that it could be a run-init issue in klibc, but it turns out that the error is from the initrd's /init interpreter, /bin/sh in the initrd, which comes from busybox (hence the output with line number information, this is the line of /init where run-init gets exec-ed). As this looked like either a toolchain issue or a busybox issue, we tried rebuilding busybox in multiple ways; this is the table of results I have: current package: Debian sid gcc (4.5) + Debian sid busybox (1.18) = fail rebuild: Debian sid gcc (4.5) + Debian sid busybox (1.18) = fail Debian sid gcc-4.4 + Debian sid busybox (1.18) = fail Emdebian squeeze cross (4.4) + Ubuntu natty busybox (1.17) = pass Ubuntu natty cross (4.5 + linaro) + Ubuntu natty busybox (1.17) = pass Debian squeeze busybox (1.17) = pass Debian stable busybox (1.17) = pass Debian-ports sid gcc (4.5) + Debian sid busybox (1.18) = pass (not same ABI!) Debian sid gcc 4.4 + Debian sid busybox (1.18) = fail Ubuntu natty cross (4.5 + linaro) + Busybox git tip = pass Ubuntu natty cross (4.5 + linaro) + Busybox git 1_18_4 = pass However I once got it to boot, with no changes, so it seems there are conditions where exec does not fail. I managed to boot multiple times by running exec a first time from an interactive shell and then exec-ing run-init. Upstream busybox would never be affected and 1.17 would never be affected, but Debian 1.18 would almost always be affected. I rebuilt the Debian source package verbatim, and it was still failing consistently; I rebuilt the Debian source package without debian/patches/applets-fallback.patch and it booted. This patch was refreshed in the latest upload: - either some issues were introduced during refresh - or the patch was always broken I didn't look at why the patch breaks (yet) and I don't have a smaller test case than the above, which is quite painful. Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
