Bug#397426: sasldbconverter2 does not work
Package: sasl2-bin Version: 2.1.19.dfsg1-0sarge2 Severity: important I am upgrading a system from woody to sarge. sasldbconverter2 provided with sasl2-bin on sarge cannot convert /etc/sasldb from my stock woody system. It seems that Debian is providing no upgrade path from woody to sarge for SASL. Rationale for severity: users upgrading from woody to sarge cannot do so. The woody system used /etc/sasldb, managed by sasl-bin 1.5.27-3.1woody5. saslpasswd on the woody system depends on libsasl.so.7, libdb2.so.2 (and others). file reports /etc/sasldb as Berkeley DB (Hash, version 5, native byte-order). sasldbconverter2 on sarge rejects my old /etc/sasldb file with Error opening password file sasldb. strace shows me: open(/etc/sasldb, O_RDWR|O_LARGEFILE) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 read(3, \0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\5\0\0\0\0\20\0\0\2\0\0..., 512) = 512 close(3)= 0 write(2, Error opening password file /etc..., 40Error opening password file /etc/sasldb sasldbconverter2 on sarge depends on libsasl2.so.2, libdb-4.2.so and others. file on sarge says that /etc/sasldb2 (as provided by the package) is Berkeley DB (Hash, version 8, native byte-order). I believe this is the same issue as archived bug 170740. Nicholas Riley was unable to convert his database even after he had built dbconverter-2 himself. That bug was closed presumably when dbconverter-2 (renamed to sasldbconverter-2) was added, but the converter cannot convert files generated on a woody system. sasldbconverter2(8) says under KNOWN BUGS: This only works for sasldb files that use the gdbm library. Does this mean that there is no converter for /etc/sasldb from my woody system? If so and this cannot be fixed, please note this in README.Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423820: No attempt to partition second disk when preseeding with partman-auto/disk
Package: partman-auto
Severity: normal
Version: not sure! It's the version I got by downloading:
ftp://ftp.uk.debian.org/debian/dists/etch/main/installer-i386/20070308/images/netboot/netboot.tar.gz
I have two disks specified in partman-auto/disk, but only the first disk
gets partitioned. Subsequently the attempt to set up RAID fails with:
An unexpected error occurred while setting up a preseeded RAID
configuration.
The error is:
partman-auto-raid: mdadm: Cannot open /dev/discs/disc1/part1: No such
file or directory
Examining the system at this point, I see that it has automatically
partitioned /dev/discs/disc0/disc but not partitioned
/dev/discs/disc1/disc at all. I have checked and fdisk is happy to fdisk
both /dev/discs/disc0/disc and /dev/discs/disc1/disc manually.
My preseeding is as follows (identical to the manual):
d-i partman-auto/method string raid
d-i partman-auto/disk string /dev/discs/disc0/disc /dev/discs/disk1/disc
d-i partman-auto/expert_recipe string \
multiraid :: \
1000 5000 4000 raid \
$primary{ } method{ raid } \
. \
64 512 300% raid \
method{ raid } \
. \
500 1 10 raid \
method{ raid } \
.
d-i partman-auto-raid/recipe string \
1 2 0 ext3 / \
/dev/discs/disc0/part1#/dev/discs/disc1/part1 \
. \
1 2 0 swap - \
/dev/discs/disc0/part5#/dev/discs/disc1/part5 \
. \
0 2 0 ext3 /home \
/dev/discs/disc0/part6#/dev/discs/disc1/part6
d-i partman-md/confirm boolean true
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition \
select Finish partitioning and write changes to disk
d-i partman/confirm boolean true
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423970: GSSAPI support missing from build
Package: cyrus-imapd-2.2 Version: 2.2.13-10 Severity: normal Please add a build dependency on heimdal-dev. This fixes the problem. I am trying to use Kerberos 5 with admin principals. This means, for example, that the user foo/admin should be able to authenticate to get admin access. This does not work unless I rebuild the source package with heimdal-dev installed. Thus, I believe that adding a build dependency on heimdal-dev would fix the problem. Without heimdal-dev or libkrb5-dev installed, running debian/rules configure-stamp gives me: checking gssapi.h usability... no checking gssapi.h presence... no checking for gssapi.h... no checking gssapi/gssapi.h usability... no checking gssapi/gssapi.h presence... no checking for gssapi/gssapi.h... no configure: WARNING: Disabling GSSAPI - no include files found checking GSSAPI... disabled With heimdal-dev installed, running debian/rules configure-stamp gives me: checking gssapi.h usability... yes checking gssapi.h presence... yes checking for gssapi.h... yes checking for res_search in -lresolv... (cached) yes checking for gss_unwrap in -lgssapi... yes checking GSSAPI... with implementation heimdal With libkrb5-dev installed, running debian/rules configure-stamp gives me: checking gssapi.h usability... no checking gssapi.h presence... no checking for gssapi.h... no checking gssapi/gssapi.h usability... yes checking gssapi/gssapi.h presence... yes checking for gssapi/gssapi.h... yes checking for res_search in -lresolv... (cached) yes checking for gss_unwrap in -lgssapi... no checking for krb5int_getspecific in -lkrb5support... yes checking for gss_unwrap in -lgssapi_krb5... yes checking GSSAPI... with implementation mit ...however, with libkrb5-dev: # grep HAVE_GSSAPI_H config.h /* #undef HAVE_GSSAPI_H */ It seems that there is a regression somewhere that broke the build with MIT Kerberos. Heimdal Kerberos still works. This seems related: http://www.irbs.net/internet/info-cyrus/0610/0321.html In any case, there is currently no build dependency on any Kerberos library. Adding one is the only change needed to the package to fix this. Once done, I can add auth_mech: krb5 to /etc/imapd.conf and it works. Thanks, Robie -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages cyrus-imapd-2.2 depends on: ii cyrus-common-2.2 2.2.13-10 Cyrus mail system (common files) ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libdb4.2 4.2.52+dfsg-2 Berkeley v4.2 Database Libraries [ ii libsasl2-22.1.22.dfsg1-8 Authentication abstraction library ii libssl0.9.8 0.9.8c-4 SSL shared libraries ii libwrap0 7.6.dbs-13 Wietse Venema's TCP wrappers libra cyrus-imapd-2.2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425844: cyrmaster dies on force-reload
Subject: cyrus-imapd-2.2: cyrmaster dies on force-reload Package: cyrus-imapd-2.2 Version: 2.2.13-10 Severity: important Running /etc/init.d/cyrus2.2 force-reload kills cyrmaster. It leaves behind a notifyd child which has to be killed manually. All I see is a cyrus/master[]: got SIGHUP log message. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages cyrus-imapd-2.2 depends on: ii cyrus-common-2.2 2.2.13-10 Cyrus mail system (common files) ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libdb4.2 4.2.52+dfsg-2 Berkeley v4.2 Database Libraries [ ii libsasl2-22.1.22.dfsg1-8 Authentication abstraction library ii libssl0.9.8 0.9.8c-4 SSL shared libraries ii libwrap0 7.6.dbs-13 Wietse Venema's TCP wrappers libra cyrus-imapd-2.2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368887: Cannot escape hex literal with setfattr
Nathan Scott wrote: Hmm, to my mind its pretty straightforward and doesn't really warrant special mention in the man pages, but I guess its confusing to some. Without a mention, it can break scripts. I happened across it, but for example, I have a script that retrieves an attribute, modifies it and writes it back. Simplifying this down, I'm expecting the following to work: setfattr -n user.DOSATTRIB -v $(getfattr --only-values -n user.DOSATTRIB foo) foo According to the manpage as it is, this should work in all cases. However, it breaks if the existing value starts 0x. This may not happen during testing (though it did in this case when used for samba). Do you see what I mean? I think that setfattr really needs a --no-escape option or something. Otherwise my script has to pass everything it gets out of getfattr through sed before going to setfattr, which is ugly. setfattr should really be able to take exactly what getfattr returns. An admin would at least try the obvious way above, surely...? I tried a few combinations, but didn't get any joy. I even dug through the source and couldn't see a way of escaping it. Guess not - can you suggest some suitable words that I could add to the man page to explain this? thanks. Is there anything else that is parsed, for example octal? I'm not sure how accurate the following is, as I don't know the logic that setfattr is following: -v value, --value=value Specifies the new value for the extended attribute. If _value_ begins with 0x, then it is taken to be in hexadecimal encoding. To insert a literal value of this form, escape it by surrounding it with double quotes (you may need your shell to escape this). Thanks, Robie. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380103: Typo in init script: force_reload
Package: racoon Version: 0.6.6-3 Tags: patch Severity: important racoon violates Debian policy 9.3.2 (hence marked important): /etc/init.d/racoon should take a parameter force-reload, but it is force_reload instead. The usage message is correct, but the behaviour isn't: # /etc/init.d/racoon force-reload Usage: /etc/init.d/racoon (start|stop|reload|force-reload|restart) This just bit me. Patch below: --- ipsec-tools-0.6.6.orig/debian/racoon.init 2006-07-27 16:22:35.546168000 +0100 +++ ipsec-tools-0.6.6/debian/racoon.init2006-07-27 16:23:29.117168574 +0100 @@ -74,7 +74,7 @@ echo . ;; - reload|force_reload|restart) + reload|force-reload|restart) $0 stop $0 start ;; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368887: Cannot escape hex literal with setfattr
Package: attr Version: 2.4.16-1 I am trying to set an extended attribute value of the form 0x20 (literally ASCII letters zero, x, two, zero) but setfattr presumes that I want a literal space (ASCII 0x20 or 32 decimal) instead. setfattr seemingly has no option to override this, and its behaviour in automatically converting my input isn't documented. For example: $ cd /tmp $ foo $ setfattr -n user.DOSATTRIB -v 0x20 foo $ getfattr -n user.DOSATTRIB foo # file: foo user.DOSATTRIB= $ What I want to see is: user.DOSATTRIB=0x20 This is the form samba saves this particular attribute in. Seemingly the only way to work around this is to convert the entire thing into hexadecimal coded ASCII: $ setfattr -n user.DOSATTRIB -v 0x30783230 foo $ getfattr -n user.DOSATTRIB foo # file: foo user.DOSATTRIB=0x20 $ This is crazy, however, for a tool that an admin is supposed to use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#548691: getcwd fails to return proper path for relatively-specified roots
tags 548691 patch
thanks
I've just come across this. The problem is that the narrow_chroot_path
macro that applies the chroot to a particular path uses a substring
match and so misses the path if it contains extra /./ type components.
Patch below. It seems to work. I haven't touched the test suite.
Robie.
diff --git a/src/libfakechroot.c b/src/libfakechroot.c
index e92ff1d..b319100 100644
--- a/src/libfakechroot.c
+++ b/src/libfakechroot.c
@@ -1212,6 +1212,18 @@ int chroot (const char *path)
}
}
+ptr = tmp = dir;
+for(ptr=tmp=dir; *ptr; ptr++) {
+ if (*ptr == '/'
+ *(ptr+1) *(ptr+1) == '.'
+ (!*(ptr+2) || (*(ptr+2) == '/'))) {
+ ptr++;
+ } else {
+ *(tmp++) = *ptr;
+ }
+}
+*tmp = 0;
+
#if defined(HAVE_SETENV)
setenv(FAKECHROOT_BASE, dir, 1);
#else
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566026: fakechroot-ng chmod failure
tags 566026 patch thanks I've just hit this problem. It seems that something changed in Linux x86_64 newfstatat/fstatat64 syscall at some point. I'm not clear on the details, but this patch seems to fix it. (before, chmod was calling fstatat which called newfstatat which failed; now the fstatat hook calls fstatat64 instead) If this is correct, then the bug would have affected x86_64 only. The patch should apply and work against both 0.16 and 0.17. diff -urN fakeroot-ng-0.17.orig/arch/linux/x86_64/platform_specific.h fakeroot-ng-0.17/arch/linux/x86_64/platform_specific.h --- fakeroot-ng-0.17.orig/arch/linux/x86_64/platform_specific.h 2009-05-19 03:45:43.0 +0100 +++ fakeroot-ng-0.17/arch/linux/x86_64/platform_specific.h 2010-03-31 20:23:11.0 +0100 @@ -117,7 +117,7 @@ #define PREF_STAT SYS_stat #define PREF_LSTAT SYS_lstat #define PREF_FSTAT SYS_fstat -#define PREF_FSTATAT SYS_newfstatat +#define PREF_FSTATAT SYS_fstatat64 #define PREF_NOP SYS_getuid #define PREF_MMAP SYS_mmap -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509867: [PATCH] Use name and email from git by default
Package: git-buildpackage
Version: 0.4.43
Severity: wishlist
Tags: patch
For users who use different email addresses for different packages (for
example: for personal and work use), use the details as specified by
git's user.name and user.email by default if they are available.
The maintainer creating the release can be expected to have git
configured correctly for commits.
This applies to the trailer only so that multimaint continues to work
for changelog entries from commits as expected.
---
gbp/git_utils.py |6 ++
git-dch | 12 +---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/gbp/git_utils.py b/gbp/git_utils.py
index da8884e..ce4ebed 100644
--- a/gbp/git_utils.py
+++ b/gbp/git_utils.py
@@ -153,6 +153,12 @@ class GitRepository(object):
GitRm(verbose=verbose)(files)
return not self.is_clean()[0]
+def get_config(self, name):
+Gets the config value associated with name
+self.__check_path()
+value, ret = self.__git_getoutput('config', [ name ])
+if ret: raise KeyError
+return value[0][:-1] # first line with \n ending removed
def create_repo(path):
create a repository at path
diff --git a/git-dch b/git-dch
index d356422..acf1c52 100755
--- a/git-dch
+++ b/git-dch
@@ -82,11 +82,17 @@ def add_changelog_section(msg, distribution, author=None,
email=None, version=No
spawn_dch(msg=msg, newversion= True, version=version, author=author,
email=email, distribution=distribution)
-def fixup_trailer():
+def fixup_trailer(repo):
fixup the changelog trailer's comitter and email address - it might
otherwise point to the last git committer instead of the person creating
the changelog
-spawn_dch(msg='')
+try: author = repo.get_config('user.name')
+except KeyError: author = None
+
+try: email = repo.get_config('user.email')
+except KeyError: email = None
+
+spawn_dch(msg='', author=author, email=email)
def head_commit():
@@ -355,7 +361,7 @@ def main(argv):
if commits:
shortlog_to_dch(repo, commits, options)
-fixup_trailer()
+fixup_trailer(repo)
elif not first_commit:
print No changes detected from %s to %s. % (since, until)
--
1.5.6.3
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509867: [PATCH] Use name and email from git by default
Guido, On Sun, Dec 28, 2008 at 11:13:04PM +0100, Guido Günther wrote: For users who use different email addresses for different packages (for example: for personal and work use), use the details as specified by git's user.name and user.email by default if they are available. I like the idea and the patch looks fine, but what if somebody wants to use a different address for git commmits than for the Debian changelog. As soon as he sets the user.email/user.name via git config this isn't overridable anymore. Currently we use whatever dch picks up as user name/email address. I understand - with my current patch a user wouldn't be able to override git's config setting so the commit email address will be forced to match. Would a further override in gbp.conf suffice? This would mean that: 1) For most maintainers, no action is required. 2) For maintainers who need different addresses based on package, one change to git's repository config is all that is needed. 3) For maintainers who further need a different git commit address from the changelog trailer, a further gbp.conf override is needed. Would this be acceptable? Robie. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509867: [PATCH] Use name and email from git by default
Guido,
On Mon, Dec 29, 2008 at 02:53:47PM +0100, Guido Günther wrote:
I was thinking of adding a simple:
# use author information from git:
git-author=True/False
to gbp.conf and corresponding --git-author/--no-git-author commandline
options to git-dch. Making git-author default to False would keep
existing behaviour.
This would be great. I have just added git-author=True to my ~/.gbp.conf
and so I get the behaviour I need, and nothing can break for anyone
else.
I've implemented this in the same way as --sign-tags as you suggested.
Updated patch below.
---
docs/manpages/git-dch.sgml |8
gbp/config.py |3 +++
gbp/git_utils.py |6 ++
git-dch| 15 ---
4 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/docs/manpages/git-dch.sgml b/docs/manpages/git-dch.sgml
index be23906..91a97b6 100644
--- a/docs/manpages/git-dch.sgml
+++ b/docs/manpages/git-dch.sgml
@@ -33,6 +33,7 @@
argoption--meta-closes=bug-close-tags/option/arg
argoption--snapshot-number=/optionreplaceableexpression/replaceable/arg
argoption--git-log=/optionreplaceablegit-log-options/replaceable/arg
+ argoption--git-author/option/arg
arg choice=plainreplaceable[path1 path2]/replaceable/arg
/cmdsynopsis
/refsynopsisdiv
@@ -178,6 +179,13 @@
all./para
/listitem
/varlistentry
+ varlistentry
+termoption--git-author/option
+/term
+listitem
+ paraUse user.name and user.email from
applicationgit-config/application(1) for changelog trailer/para
+/listitem
+ /varlistentry
/variablelist
/refsect1
refsect1
diff --git a/gbp/config.py b/gbp/config.py
index 20bb4a9..2787bf5 100644
--- a/gbp/config.py
+++ b/gbp/config.py
@@ -46,6 +46,7 @@ class GbpOptionParser(OptionParser):
'meta-closes' : 'Closes|LP',
'id-length' : '0',
'no-dch' : 'False',
+ 'git-author' : 'False',
}
help = {
'debian-branch':
@@ -64,6 +65,8 @@ class GbpOptionParser(OptionParser):
use pristine-tar to create .orig.tar.gz, default is
'%(pristine-tar)s',
'filter':
files to filter out during import (can be given multiple
times),
+ 'git-author':
+ use name and email from git-config for changelog trailer,
default is '%(git-author)s'
}
config_files = [ '/etc/git-buildpackage/gbp.conf',
os.path.expanduser('~/.gbp.conf'),
diff --git a/gbp/git_utils.py b/gbp/git_utils.py
index da8884e..ce4ebed 100644
--- a/gbp/git_utils.py
+++ b/gbp/git_utils.py
@@ -153,6 +153,12 @@ class GitRepository(object):
GitRm(verbose=verbose)(files)
return not self.is_clean()[0]
+def get_config(self, name):
+Gets the config value associated with name
+self.__check_path()
+value, ret = self.__git_getoutput('config', [ name ])
+if ret: raise KeyError
+return value[0][:-1] # first line with \n ending removed
def create_repo(path):
create a repository at path
diff --git a/git-dch b/git-dch
index d356422..aee717f 100755
--- a/git-dch
+++ b/git-dch
@@ -82,11 +82,19 @@ def add_changelog_section(msg, distribution, author=None,
email=None, version=No
spawn_dch(msg=msg, newversion= True, version=version, author=author,
email=email, distribution=distribution)
-def fixup_trailer():
+def fixup_trailer(repo, git_author=False):
fixup the changelog trailer's comitter and email address - it might
otherwise point to the last git committer instead of the person creating
the changelog
-spawn_dch(msg='')
+author = email = None
+if git_author:
+try: author = repo.get_config('user.name')
+except KeyError: pass
+
+try: email = repo.get_config('user.email')
+except KeyError: pass
+
+spawn_dch(msg='', author=author, email=email)
def head_commit():
@@ -279,6 +287,7 @@ def main(argv):
help=mark as snapshot build)
version_group.add_option(-N, --new-version, dest=new_version,
help=use this as base for the new version number)
+version_group.add_config_file_option(option_name=git-author,
dest=git_author, action=store_true)
commit_group.add_config_file_option(option_name=meta, dest=meta,
help=parse meta tags in commit messages, default is
'%(meta)s', action=store_true)
commit_group.add_config_file_option(option_name=meta-closes,
dest=meta_closes,
@@ -355,7 +364,7 @@ def main(argv):
if commits:
shortlog_to_dch(repo, commits, options)
-fixup_trailer()
+fixup_trailer(repo, git_author=options.git_author)
elif not first_commit:
print No changes detected from %s to %s. % (since,
Bug#675353: Case inconsistency in machine field definitions
Package: flash-kernel Version: 3.0~rc.4 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu quantal The README refers to Required-packages. However, debian/flash-kernel-installer.postinst uses Required-Packages and get_machine_field is case sensitive. This causes packages that developers specify as required actually ending up being ignored. Further, the existing database appears to have many entries listed with this error. But Bootloader-sets-root appears to be used with this capitalisation, which is inconsistent. Can I suggest a review of the capitalisation of these fields to make them consistent across themselves, the documentation, the code and the existing database? At a minimum, the existing fields in the database should be fixed so that debian/flash-kernel-installer.postinst can see them, and the README should be fixed so that developers won't insert new entries into the database in error. Thanks! signature.asc Description: Digital signature
Bug#644963: samba postrm depends on packages not guaranteed to be configured
Package: samba Version: 2:3.5.11~dfsg-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu oneiric debian/samba.postrm calls update-inetd. If is called with upgrade, then update-inetd may be called even if it is not present. If it is called with upgrade, then although its presence is tested it may still not be configured This is causing upgrade errors going from Ubuntu Natty to Oneiric such as the following: Unpacking replacement samba ... [...] Can't locate File/Temp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/share/perl5/DebianNet.pm line 18. BEGIN failed--compilation aborted at /usr/share/perl5/DebianNet.pm line 18. Compilation failed in require at /usr/sbin/update-inetd line 23. dpkg: warning: subprocess old post-removal script returned error exit status 2 This can be reproduced by installing samba, manually removing (dpkg -r) update-inetd and its dependencies, unpacking update-inetd (dpkg --unpack) and then trying to purge samba. From policy: The package whose postrm is being called may have previously been deconfigured and only be unpacked, at which point subsequent package changes do not consider its dependencies. Therefore, all postrm actions may only rely on essential packages and must gracefully skip any actions that require the package's dependencies if those dependencies are unavailable. Launchpad bug here: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/862129 Some more discussion here: https://code.launchpad.net/~racb/ubuntu/oneiric/samba/862129/+merge/78862 The general recommendation seems to be that update-inetd should not be in postrm, but moved to prerm, at which point update-inetd should still be configured. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648969: Please update to latest upstream version
Package: openmpi Version: 1.4.3-2.1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu precise Upstream series 1.5 is available; the current version is 1.5.4. 1.5.2 added ARM support. An update would be useful for use on ARM servers which are expected to start shipping soon. signature.asc Description: Digital signature
Bug#688677: bridge-utils should depend on net-tools
Package: bridge-utils Version: 1.5-4 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu bridge-utils calls ifconfig in /etc/network/if-pre-up.d/bridge and /etc/network/if-post-down.d/bridge but does not depend on net-tools which supplies ifconfig. net-tools is Priority: important and not Priority: essential, so I think that dependencies must be explicitly declared here. I've looked at policy section 3.5 to determine this - it states that packages need not depend on essential packages, but there is nothing about important packages there, so it is implied that it does. If you concur then please add net-tools as a dependency. Thanks, Robie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660214: libblacs-openmpi.so.1.1 is not built with correct dependency information
Package: blacs-mpi Version: 1.1-31 Tags: patch User: peter.fritzs...@gmx.de Usertags: unresolved-symbols-so debian/rules calls gcc with parameters in the incorrect order. When the Debian linker's defaults are changed, this will break the library such that packages that depend on it won't build correctly. This does not affect Debian yet, but affects Ubuntu already. I've attached the patch applied to Ubuntu. If you apply this now, this package won't be affected by the future change in Debian. For more details: http://wiki.debian.org/ToolChain/DSOLinking Thanks, Robie diff -u blacs-mpi-1.1/debian/changelog blacs-mpi-1.1/debian/changelog --- blacs-mpi-1.1/debian/changelog +++ blacs-mpi-1.1/debian/changelog @@ -1,3 +1,9 @@ +blacs-mpi (1.1-32) unstable; urgency=low + + * debian/rules: declare library dependencies correctly (LP: #934138). + + -- Robie Basak robie.ba...@ubuntu.com Fri, 17 Feb 2012 12:06:41 + + blacs-mpi (1.1-31) unstable; urgency=low * Rebuilding with mpi-default-dev =1.0 (Closes: #652312) diff -u blacs-mpi-1.1/debian/rules blacs-mpi-1.1/debian/rules --- blacs-mpi-1.1/debian/rules +++ blacs-mpi-1.1/debian/rules @@ -51,7 +51,7 @@ done;\ cd .. ;\ gcc -shared -Wl,-soname=lib$$i-openmpi.so.1 -o lib$$i-openmpi.so.1.1 \ - -L/usr/lib/openmpi/lib/ -lmpi -lmpi_f77 $$(find tmp -name *.o);\ + -L/usr/lib/openmpi/lib/ $$(find tmp -name *.o) -lmpi -lmpi_f77; \ ln -fs lib$$i-openmpi.so.1.1 lib$$i-openmpi.so.1 ;\ ln -fs lib$$i-openmpi.so.1 lib$$i-openmpi.so ;\ rm -f tmp/tmp/* ; rmdir tmp/tmp ; rm tmp/* ;\ signature.asc Description: Digital signature
Bug#659134: openmpi experimental debian/rules clean target fails
Package: openmpi Version: 1.5.4-2~exp1 In a sid amd64 chroot, I am satisfying build dependencies, then running debian/rules build, then running debian/rules clean. The clean target fails. I've pasted the bottom part of the output below. This was causing me tool breakage, but I found a workaround (--no-clean-after in xdeb). So this is a low priority for me, and I probably won't get round to fixing it myself unless it blocks me further down the road. Thanks, Robie rm -f *.tab.c test -z || rm -f test . = . || test -z || rm -f rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags rm -rf ./.deps rm -f Makefile make[3]: Leaving directory `/root/openmpi-1.5.4/opal/mca/paffinity/test' Making distclean in mca/paffinity/hwloc make[3]: Entering directory `/root/openmpi-1.5.4/opal/mca/paffinity/hwloc' Making distclean in hwloc make[4]: Entering directory `/root/openmpi-1.5.4/opal/mca/paffinity/hwloc/hwloc' make[4]: *** No rule to make target `distclean'. Stop. make[4]: Leaving directory `/root/openmpi-1.5.4/opal/mca/paffinity/hwloc/hwloc' make[3]: *** [distclean-recursive] Error 1 make[3]: Leaving directory `/root/openmpi-1.5.4/opal/mca/paffinity/hwloc' make[2]: *** [distclean-recursive] Error 1 make[2]: Leaving directory `/root/openmpi-1.5.4/opal' make[1]: *** [distclean-recursive] Error 1 make[1]: Leaving directory `/root/openmpi-1.5.4' dh_auto_clean: make -j1 distclean returned exit code 2 make: *** [clean] Error 29 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657625: FTBFS openmpi 1.5 (experimental) on armel
Package: openmpi Version: 1.5.4-2~exp1 openmpi 1.5 fails to build on Debian armel: /bin/bash ../../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../opal/include -I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/hwloc/hwloc/include/private/autogen -I../../opal/mca/paffinity/hwloc/hwloc/include/hwloc/autogen -I../.. -I/usr/include/infiniband -I/usr/include/infiniband -DNDEBUG -g -O2 -finline-functions -fno-strict-aliasing -c -o atomic-asm.lo atomic-asm.S atomic-asm.S: Assembler messages: atomic-asm.S:7: Error: selected processor does not support ARM mode `dmb' atomic-asm.S:15: Error: selected processor does not support ARM mode `dmb' atomic-asm.S:23: Error: selected processor does not support ARM mode `dmb' atomic-asm.S:32: Error: selected processor does not support ARM mode `ldrex r3,[r0]' atomic-asm.S:35: Error: selected processor does not support ARM mode `strex r12,r2,[r0]' [etc] The rest of this report is my understanding of the issue, in the hope that this will help. I may be wrong, especially in my understanding of Debian's side. I've reproduced the FTBFS in a sid chroot, but I get a successful build on Ubuntu precise, both armel and armhf. So it seems that this is a toolchain issue - something to do with where the Debian and Ubuntu toolchains differ. I regret that I don't have as much low level knowledge as I'd like to have, but I've been doing some research. From what I can find, the dmb/ldrex/strex etc. instructions only exist in armv7[1]. And Debian appears to target armv4t. I think an -march=armv7-a would fix it, and there also might be an assembly directive to do this at source level rather than changing the build. But on Debian that would break compability of this package for older architectures, so I'm not sure if this would be acceptable for you. I've also found that Debian targets armhf at armv7-a[2] so if I'm right so far, perhaps an acceptable solution might be to drop armel support for openmpi in Debian? As upstream are using armv7 instructions, I think this would be reasonable. I've been told that upstream have switched from gcc builtins to dedicated armv7 code. So another option would be to conditionally use gcc builtins again if armv7. So I think Debian's options are: 1) Extend upstream's armv7 support down to armv4t, perhaps by using gcc builtins. 1b) Speak to upstream about (1). Perhaps this was unintentional and they would be happy to use gcc builtins across the board? 2) Build this package for armv7-only somehow. I'm not sure if there's a place for this sort of thing to go, or what Debian policy has to say about this, since someone running armel on armv4t won't be able to use openmpi then. 3) Drop armel support. I don't think this is such a bad option, since AIUI openmpi users would generally be running servers on armhf (with armv7 or higher) anyway. [1]: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489c/CIHGHHIE.html [2]: http://wiki.debian.org/ArmHardFloatPort -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708621: Regression in default cipher suite selection
On Fri, May 17, 2013 at 11:00:33AM +0100, Robie Basak wrote: Thanks for grabbing our delta in Ubuntu for the latest upstream release. We've now synced your package, so if you could cherry-pick this then we can auto-sync and won't need to re-introduce a delta. I've reintroduced a delta for now, so we don't have another release with this regression, but I hope we can sync again soon. Robie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719245: dep8 test for apache2 passphrase prompting
Package: apache2
Version: 2.4.6-2
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy ubuntu-patch
Tags: patch
Severity: wishlist
I've added a dep8[1] test to the Ubuntu apache2 package which verifies
basic functionality as well as checks that SSL is working and passphrase
prompting on service startup works correctly. An error in an Ubuntu diff
for passphrase entry prompted me to do this, but I wrote the test to
work correctly with the Debian package as well. Please consider adding
this test to the Debian packaging. Patch attached. Thanks!
[1]: http://dep.debian.net/deps/dep8/
diff --git a/debian/ask-for-passphrase b/debian/ask-for-passphrase
old mode 100644
new mode 100755
diff --git a/debian/control b/debian/control
index a36428d..60906c2 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,7 @@ Standards-Version: 3.9.4
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git
Vcs-Git: git://anonscm.debian.org/pkg-apache/apache2.git
Homepage: http://httpd.apache.org/
+XS-Testsuite: autopkgtest
Package: apache2
Architecture: any
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..26b0b80
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,3 @@
+Tests: ssl-passphrase
+Restrictions: needs-root allow-stderr
+Depends: apache2, curl, expect, ssl-cert
diff --git a/debian/tests/ssl-passphrase b/debian/tests/ssl-passphrase
new file mode 100644
index 000..c509677
--- /dev/null
+++ b/debian/tests/ssl-passphrase
@@ -0,0 +1,49 @@
+#!/bin/sh
+set -ex
+
+# Check that the init script correctly prompts for the passphrase on startup,
+# then starts and responds correctly to https queries.
+#
+# Author: Robie Basak robie.ba...@ubuntu.com
+
+cd /etc/ssl/private
+[ -f ssl-cert-snakeoil.key.nopassphrase ] || mv ssl-cert-snakeoil.key ssl-cert-snakeoil.key.nopassphrase
+openssl rsa -des3 -in ssl-cert-snakeoil.key.nopassphrase -out ssl-cert-snakeoil.key -passout pass:test
+a2enmod ssl
+a2ensite default-ssl
+
+expect EOT
+spawn service apache2 restart
+set timeout 600
+expect {
+ # Debian
+ ass phrase: {send test\r}
+
+ # Ubuntu
+ assphrase: {send test\r}
+
+ # Failure cases
+ failed {exit 1}
+ eof {exit 1}
+}
+
+# wait for eof and return exit code from spawned process back to the caller
+expect eof
+catch wait result
+exit [lindex \$result 3]
+EOT
+
+echo Hello, world! /var/www/hello.txt
+
+# Use curl here. wget doesn't work on Debian, even with --no-check-certificate
+# wget on Debian gives me:
+#GnuTLS: A TLS warning alert has been received.
+#Unable to establish SSL connection.
+# Presumably this is due to the self-signed certificate, but I'm not sure how
+# to skip the warning with wget. curl will do for now.
+result=`curl -k https://localhost/hello.txt`
+
+if [ $result != Hello, world! ]; then
+echo Unexpected result from wget 2
+exit 1
+fi
Bug#712004: libapache2-svn and Apache 2.4 transition bug not really fixed
reopen 712004 thanks AIUI, a workaround to unblock the Apache 2.4 transition was to disable building of libapache2-svn in 1.6.17dfsg-4.1, which isn't really a fix for this particular bug but did close it. I'm not sure whether you'd prefer a separate bug for the fact that we no longer have a Subversion apache module - feel free to rearrange things. But I can't find any open bug to track this issue, so reopening this bug seemed like the best option for now until you decide how you want to track this. The downstream Ubuntu bug is: https:/launchpad.net/bugs/1209493 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712730: Source package is not DFSG compliant
Package: mysql-5.5 Version: 5.5.31+dfsg-1 Severity: serious User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy See: https://blog.mariadb.org/mysql-man-pages-silently-relicensed-away-from-gpl/ It seems that Oracle silently changed the licensing in the documentation; at least the manpages, in 5.5.30-5.5.31). The manpages shipped by the source package now contain copyright wording that is clearly not DFSG compliant, since modifications are prohibited and there is no explicit exception to permit distribution of patches. So debian/copyright is also now wrong, since it lists man/* (implictly through *) as GPL-2. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713023: dir2ogg exits with success on failure
Package: dir2ogg
Version: 0.11.8-1
If the decoder returns failure, then dir2ogg prints a warning, but
exits with success anyway. This is contrary to convention; the expected
exit status on failure is non-zero.
This is a problem because corrupt or problem files cannot easily be
noticed when converting a large number of files (which is the package's
purpose).
You can see this in lines 48-51 of /usr/bin/dir2ogg:
if not success:
warn('Decoding of %s with %s failed.' % (self.song, self.decoder))
return
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708621: Regression in default cipher suite selection
Package: ipmitool Version: 1.8.12-1 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy ubuntu-patch Upstream bug: http://sourceforge.net/tracker/index.php?func=detailaid=3571371group_id=95200atid=610550 Downstream bug: https://launchpad.net/bugs/1176202 There was a regression in the default cipher suite used upstream, causing users to often have to specify -C3 when they didn't before. Upstream decided to revert the default back. Please could you cherry-pick this patch until the next upstream release? http://ipmitool.cvs.sourceforge.net/viewvc/ipmitool/ipmitool/lib/ipmi_main.c?r1=1.38r2=1.39 Thanks for grabbing our delta in Ubuntu for the latest upstream release. We've now synced your package, so if you could cherry-pick this then we can auto-sync and won't need to re-introduce a delta. Thanks! Robie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709163: init script's status method doesn't handle instances correctly
Package: memcached Version: 1.4.13-0.2 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy ubuntu-patch Downstream bug: https://bugs.launchpad.net/ubuntu/+source/memcached/+bug/1177398 /etc/init.d/memcached supports the status action, but this does not work correctly with the multiple instance support patched in elsewhere in the script by the packaging. A proposed patch is in the Ubuntu bug linked above - though I haven't studied it carefully. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693845: ruby-hiera shouldn't recommend mcollective or puppet
With no activity here, I've fixed this in Ubuntu in version 1.0.0~rc3-1ubuntu1 by dropping the Recommends line entirely. I hope to resync once Debian applies the same change. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670138: libical FTBFS on ARM
Package: libical
Version: 0.48-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise
Tags: patch
We are now carrying this in Ubuntu. The fix is committed upstream; you
may want to carry this until an upstream update.
debian/patches/fix_arm_ftbfs.patch:
From: Robie Basak robie.ba...@canonical.com
Subject: Fix libicalss parser for non-Intel architectures
The test suite fails on ARM and PowerPC because the libicalss lexer
performs unput(EOF) which is not permitted. On these architectures, this
gets interpreted as unput(255), creating an extra token which then
causes the parser to return a syntax error.
Instead, the lexer should just ignore EOF and not attempt to unput it.
The input stream will remain at EOF and the lexer will return an EOF as
the next token as needed.
Forwarded:
https://sourceforge.net/tracker/?func=detailaid=3517199group_id=16077atid=316077
Bug-Ubuntu: https://bugs.launchpad.net/bugs/979846
Last-Update: 2012-04-12
--- a/src/libicalss/icalsslexer.c
+++ b/src/libicalss/icalsslexer.c
@@ -936,7 +936,9 @@
YY_RULE_SETUP
{
int c = input();
- unput(c);
+ if (c != EOF) {
+ unput(c);
+ }
if(c!='\''){
sslval.v_string= icalmemory_tmp_copy(sstext);
return STRING;
--- a/src/libicalss/icalsslexer.l
+++ b/src/libicalss/icalsslexer.l
@@ -111,7 +111,9 @@
\'[\@\*A-Za-z0-9\-\.\:\ ]+\' {
int c = input();
- unput(c);
+ if (c != EOF) {
+ unput(c);
+ }
if(c!='\''){
sslval.v_string= icalmemory_tmp_copy(yytext);
return STRING;
signature.asc
Description: Digital signature
Bug#670139: FTBFS with parallel builds
Package: libical
Version: 0.48-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise
Tags: patch
We are now carrying this in Ubuntu. The fix is committed upstream; you
may want to carry this until an upstream update.
debian/patches/fix_ftbfs_dependencies.patch:
Subject: Fix dependency declarations to fix concurrent builds
Author: Robie Basak robie.ba...@canonical.com
Bug-Ubuntu: https://bugs.launchpad.net/bugs/978862
Forwarded:
https://sourceforge.net/tracker/?func=detailaid=3516878group_id=16077atid=316077
Last-Update: 2012-04-11
--- a/src/libicalvcal/CMakeLists.txt
+++ b/src/libicalvcal/CMakeLists.txt
@@ -30,6 +30,9 @@
add_library(icalvcal ${LIBRARY_TYPE} ${icalvcal_LIB_SRCS})
add_library(icalvcal-static STATIC ${icalvcal_LIB_SRCS})
+add_dependencies(icalvcal ical-header)
+add_dependencies(icalvcal-static ical-header)
+
target_link_libraries(icalvcal ical)
if(MSVC)
--- a/src/libicalss/CMakeLists.txt
+++ b/src/libicalss/CMakeLists.txt
@@ -23,9 +23,7 @@
-DICAL_FILE_H_FILE:FILEPATH=${CMAKE_BINARY_DIR}/src/libicalss/icalss.h
-P ${CMAKE_CURRENT_SOURCE_DIR}/icalss_file.cmake
DEPENDS
- ${CMAKE_BINARY_DIR}/src/libical/icalderivedproperty.h
- ${CMAKE_BINARY_DIR}/src/libical/icalderivedparameter.h
- ${CMAKE_BINARY_DIR}/src/libical/icalderivedvalue.h
+ ical-header
)
add_custom_target(icalss-header DEPENDS
@@ -73,6 +71,7 @@
add_library(icalss-static STATIC ${icalss_LIB_SRCS})
add_dependencies(icalss icalss-header)
+add_dependencies(icalss-static icalss-header)
target_link_libraries(icalss ical)
signature.asc
Description: Digital signature
Bug#670140: Heap corruption bug
Package: libical Version: 0.48-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu precise Tags: patch There is some upstream discussion which acknowledges the problem but I don't think they have committed a fix yet. This was causing crashes on my system, so I have applied this workaround for Ubuntu. You may wish to do the same. debian/patches/fix_timezone_crash.patch: Description: work around heap corruption bug Author: Robie Basak robie.ba...@canonical.com Last-Update: 2012-04-04 Forwarded: http://sourceforge.net/mailarchive/message.php?msg_id=29084189 Bug-Ubuntu: https://bugs.launchpad.net/bugs/956843 Bug: https://sourceforge.net/tracker/?func=detailaid=3514871group_id=16077atid=116077 Index: libical-0.48/src/libical/icaltimezone.c === --- libical-0.48.orig/src/libical/icaltimezone.c2011-12-13 17:08:18.0 + +++ libical-0.48/src/libical/icaltimezone.c 2012-04-01 12:15:00.836064296 + @@ -1656,7 +1656,7 @@ icalerror_assert (builtin_timezones == NULL, Parsing zones.tab file multiple times); -builtin_timezones = icalarray_new (sizeof (icaltimezone), 32); +builtin_timezones = icalarray_new (sizeof (icaltimezone), 1024); #ifndef USE_BUILTIN_TZDATA filename_len = strlen ((char *) icaltzutil_get_zone_directory()) + strlen (ZONES_TAB_SYSTEM_FILENAME) signature.asc Description: Digital signature
Bug#704548: ITP: pifacedigitalio -- control a Pi-Face interface on your Raspberry Pi
Package: wnpp Severity: wishlist Owner: Robie Basak ro...@justgohome.co.uk * Package name: pifacedigitalio Version : 1.1 Upstream Author : Thomas Preston thomasmarkpres...@gmail.com * URL : https://github.com/piface/pifacedigitalio * License : GPL-3+ Programming Lang: Python Description : Python library to control a Pi-Face interface on a Raspberry Pi A Python interface to Pi-Face Digital. Pi-Face Digital is the first of a range of interfaces to allow the Raspberry Pi to control and manipulate the real world. It allows the Raspberry Pi to read switches connected to it – a door sensor or pressure pad perhaps, a microswitch or reed switch, or a hand held button. With appropriate easy to write code, the Raspberry Pi then drives outputs, powering motors, actuator, LEDs, light bulbs or anything you can imagine to respond to the inputs. Also see: http://pi.cs.man.ac.uk/interface.htm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704624: Build fails to use -ffreestanding
Package: openhackware Version: 0.4.1-6 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring ubuntu-patch In Ubuntu, we're getting a build failure like this: /build/buildd/openhackware-0.4.1/src/bootinfos.c:282: undefined reference to `__stack_chk_fail' The fix is to build with -ffreestanding to tell the compiler that this will be standalone object code. I can't easily test on Debian since it doesn't have a cross-compiler package for powerpc, but if you can use -ffreestanding I think it may make sense to do so. Thank you for your consideration. Patch (you might want to integrate into 001_build.patch): ---8--- Author: Robie Basak robie.ba...@canonical.com Last-Update: 2013-04-03 Description: build with -ffreestanding The target is independent of system libraries, so tell the compiler to not assume that standard support libraries are available. This fixes a link failure on __stack_chk_fail causing an FTBFS. Index: openhackware-0.4.1/Makefile === --- openhackware-0.4.1.orig/Makefile2013-04-03 16:53:39.0 + +++ openhackware-0.4.1/Makefile 2013-04-03 17:11:18.919446792 + @@ -45,7 +45,7 @@ CC_BASE:= $(shell $(CC) -print-search-dirs | grep install | sed -e 's/.*\ //') CFLAGS= -Wall -W -Werror -O2 -g -DEF_CFLAGS= $(CFLAGS) -fno-builtin -fno-common -nostdinc -mregnames +DEF_CFLAGS= $(CFLAGS) -fno-builtin -fno-common -nostdinc -mregnames -ffreestanding DEF_CFLAGS+= -DBUILD_DATE=$(BUILD_DATE) -DBUILD_TIME=$(BUILD_TIME) DEF_CFLAGS+= -I$(SRCDIR)/ -I$(SRCDIR)/libc/include -I$(CC_BASE)/include DEF_CFLAGS+= -I$(SRCDIR)/dev -I$(SRCDIR)/dev/block -I$(SRCDIR)/dev/char -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704691: Embedded virtualenv does not support multiarch python
Package: enigmail
Version: 2:1.5.1+id17-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu raring ubuntu-patch
The packaging appears to include a virtualenv_embedded/site.py that does
not support multiarch Python. This causes a FTBFS in Ubuntu, and
presumably will cause issues in Debian when Debian's Python moves to
multiarch.
Patch attached. This applies to the Ubuntu package which is on a
slightly different version, so you may need to tweak it a little. Note
that changes to virtualenv_embedded/site.py need to be encoded
(.encode('zlib').encode('base64')) and then embedded into virtualenv.py.
I cherry-picked this from
https://github.com/pypa/virtualenv/commit/38d56d9b83b9902c942412482b401fd72c2320bd
Also see https://bugzilla.mozilla.org/show_bug.cgi?id=837631
Updating to the latest virtualenv (1.8.5 based on the above link, or
trunk if it's not released yet) should also do the trick.
Thanks
--- a/python/virtualenv/virtualenv_embedded/site.py
+++ b/python/virtualenv/virtualenv_embedded/site.py
@@ -578,9 +578,19 @@
lib64_path = os.path.join(sys.real_prefix, 'lib64',
'python'+sys.version[:3])
if os.path.exists(lib64_path):
paths.append(lib64_path)
-# This is hardcoded in the Python executable, but relative to
sys.prefix:
-plat_path = os.path.join(sys.real_prefix, 'lib',
'python'+sys.version[:3],
- 'plat-%s' % sys.platform)
+# This is hardcoded in the Python executable, but relative to
+# sys.prefix. Debian change: we need to add the multiarch triplet
+# here, which is where the real stuff lives. As per PEP 421, in
+# Python 3.3+, this lives in sys.implementation, while in Python 2.7
+# it lives in sys.
+try:
+arch = getattr(sys, 'implementation', sys)._multiarch
+except AttributeError:
+# This is a non-multiarch aware Python. Fallback to the old way.
+arch = sys.platform
+plat_path = os.path.join(sys.real_prefix, 'lib',
+ 'python'+sys.version[:3],
+ 'plat-%s' % arch)
if os.path.exists(plat_path):
paths.append(plat_path)
# This is hardcoded in the Python executable, but
--- a/python/virtualenv/virtualenv.py
+++ b/python/virtualenv/virtualenv.py
@@ -1786,142 +1786,145 @@
##file site.py
SITE_PY = convert(
-eJzFPf1z2zaWv/OvwMqTIZXKdD66nR2n7o2TOK333MTbpLO5dT1aSoIs1hTJEqRl7c3d337vAwAB
-kvLHpp3TdGKJBB4eHt43HtDRaHRcljJfiHWxaDIplEyq+UqUSb1SYllUol6l1WK/TKp6C0/n18mV
-VKIuhNqqGFvFQfD0Cz/BU/FplSqDAnxLmrpYJ3U6T7JsK9J1WVS1XIhFU6X5lUjztE6TLP0XtCjy
-WDz9cgyC01zAzLNUVuJGVgrgKlEsxfm2XhW5iJoS5/w8/nPycjwRal6lZQ0NKo0zUGSV1EEu5QLQ
-hJaNAlKmtdxXpZyny3RuG26KJluIMkvmUvzznzw1ahqGgSrWcrOSlRQ5IAMwJcAqEQ/4mlZiXixk
-LMRrOU9wAH7eEitgaBNcM4VkzAuRFfkVzCmXc6lUUm1FNGtqAkQoi0UBOKWAQZ1mWbApqms1hiWl
-9djAI5Ewe/iTYfaAeeL4fc4BHD/kwc95ejth2MA9CK5eMdtUcpneigTBwk95K+dT/SxKl2KRLpdA
-g7weY5OAEVAiS2cHJS3Ht3qFvjsgrCxXJjCGRJS5Mb+kHnFwWoskU8C2TYk0UoT5WzlLkxyokd/A
-cAARSBoMjbNIVW3HodmJAgBUuI41SMlaiWidpDkw64/JnND+e5ovio0aEwVgtZT4tVG1O/9ogADQ
-2iHAJMDFMqvZ5Fl6LbPtGBD4BNhXUjVZjQKxSCs5r4sqlYoAAGpbIW8B6YlIKqlJyJxp5HZC9Cea
-pDkuLAoYCjy+RJIs06umIgkTyxQ4F7ji3YefxNuT16fH7zWPGWAss1drwBmg0EI7OMEA4qBR1UFW
-gEDHwRn+EcligUJ2heMDXm2Dg3tXOohg7mXc7eMsOJBdL64eBuZYgzKhsQLq99/QZaJWQJ//uWe9
-g+B4F1Vo4vxtsypAJvNkLcUqYf5Czgi+1XC+i8t69Qq4QSGcGkilcHEQwRThAUlcmkVFLkUJLJal
-uRwHQKEZtfVXEVjhfZHv01p3OAEgVEEOL51nYxoxlzDRPqxXqC9M4y3NTDcJ7Dqvi4oUB/B/Pidd
-lCX5NeGoiKH420xepXmOCCEvBOFeSAOr6xQ4cRGLM2pFesE0EiFrL26JItEALyHTAU/K22RdZnLC
-4ou69W41QoPJWpi1zpjjoGVN6pVWrZ3qIO+9iD93uI7QrFeVBODNzBO6ZVFMxAx0NmFTJmsWr3pT
-EOcEA/JEnZAnqCX0xe9A0WOlmrW0L5FXQLMQQwXLIsuKDZDsMAiE2MNGxij7zAlv4R38C3Dx30zW
-81UQOCNZwBoUIr8LFAIBkyBzzdUaCY/bNCt3lUyas6YoqoWsaKiHEfuAEX9gY5xr8L6otVHj6eIq
-F+u0RpU00yYzZYuXhzXrx1c8b5gGWG5FNDNNWzqtcXpZuUpm0rgkM7lESdCL9MouO4wZDIxJtrgW
-a7Yy8A7IIlO2IMOKBZXOspbkBAAMFr4kT8smo0YKGUwkMNC6JPjrBE16oZ0lYG82ywEqJDbfc7A/
-gNu/QIw2qxToMwcIoGFQS8HyzdK6Qgeh1UeBb/RNfx4fOPV0qW0TD7lM0kxb+SQPTunhSVWR+M5l
-ib0mmhgKZpjX6Npd5UBHFPPRaBQExh3aKvO1UEFdbQ+BFYQZZzqdNSkavukUTb3+oQIeRTgDe91s
-OwsPNITp9B6o5HRZVsUaX9u5fQRlAmNhj2BPnJOWkewge5z4CsnnqvTSNEXb7bCzQD0UnP908u70
-88lHcSQuWpU26eqzSxjzJE+ArckiAFN1hm11GbRExZei7hPvwLwTU4A9o94kvjKpG+BdQP1T1dBr
-mMbcexmcvD9+fXYy/fnjyU/Tj6efTgBBsDMy2KMpo3lswGFUMQgHcOVCxdq+Br0e9OD18Uf7IJim
-alpuyy08AEMJLFxFMN+JCPHhVNvgaZovi3BMjX9lJ/yI1Yr2uC4Ov74UR0ci/DW5ScIAvJ62KS/i
-jyQAn7alhK41/IkKNQ6ChVyCsFxLFKnoKXmyY+4ARISWhbasvxZpbt4zH7lDkMRH1ANwmE7nWaIU
-Np5OQyAtdRj4QIeY3WGUkwg6llu361ijgp9KwlLk2GWC/wygmMyoH6LBKLpdTCMQsPU8UZJb0fSh
-33SKWmY6jfSAIH7E4+AiseIIhWmCWqZKwRMlXkGtM1NFhj8RPsotiQwGQ6jXcJF0sBPfJFkjVeRM
-CogYRR0yompMFXEQOBUR2M526cbjLjUNz0AzIF9WgN6rOpTDzx54KKBgTNiFoRlHS0wzxPSvHBsQ
-DuAkhqiglepAYX0mzk/OxctnL/bRAYEocWGp4zVHm5rmjbQPl7BaV7J2EOZe4YSEYezSZYmaEZ8e
-3g1zHduV6bPCUi9xJdfFjVwAtsjAziqLn+gNxNIwj3kCqwiamCw4Kz3j6SUYOfLsQVrQ2gP11gTF
Bug#705053: jack-rack does not link with -lm
Package: jack-rack Version: 1.4.8~rc1-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring ubuntu-patch jack-rack FTBFS in Ubuntu because it does not explicitly link with -lm. There's a patch for this already, but it doesn't include -lm even though the upstream bug does include it. So I updated the patch (below). This succeeds in Debian right now because the linker isn't as pedantic as Ubuntu's, but you might want to update this for the future. Thanks diff -Nru jack-rack-1.4.8~rc1/debian/patches/02-gcc45_binutils_gold.patch jack-rack-1.4.8~rc1/debian/patches/02-gcc45_binutils_gold.patch --- jack-rack-1.4.8~rc1/debian/patches/02-gcc45_binutils_gold.patch 2011-05-29 09:11:30.0 + +++ jack-rack-1.4.8~rc1/debian/patches/02-gcc45_binutils_gold.patch 2013-04-09 14:18:14.0 + @@ -1,21 +1,25 @@ Description: Fix FTBFS with newest GCC4.5 and linker. + Updated 2013-04-09 by Robie Basak robie.ba...@canonical.com: + * Added -lm; this is already in the upstream bug. Author: Alessio Treglia ales...@debian.org Forwarded: https://sourceforge.net/apps/trac/jack-rack/ticket/1 Also forwarded to torb...@gmx.de, leslie.pol...@gmx.net, adamsamp...@users.sourceforge.net +Last-Update: 2013-04-09 --- src/Makefile.am |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) jack-rack.orig/src/Makefile.am -+++ jack-rack/src/Makefile.am -@@ -61,7 +61,8 @@ jack_rack_CFLAGS = \ +--- a/src/Makefile.am b/src/Makefile.am +@@ -61,7 +61,9 @@ -DGNOME_DISABLE_DEPRECATED=1 -jack_rack_LDFLAGS = \ +LIBS = \ + -ldl \ ++ -lm \ $(JACK_LIBS) \ $(GTK_LIBS) \ $(GNOMEUI_LIBS) \ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698446: Automatic restart of amavisd from spamassassin broken in some cases
Package: amavisd-new Version: 1:2.7.1-2 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring amavisd-new 1:2.6.4-3 (squeeze) installs etc/spamassassin/sa-update-hooks.d/amavisd-new, but this file is not marked executable. This was fixed in 1:2.7.0-1 (wheezy and sid are on 1:2.7.1-2) with an extra line in debian/rules that marks etc/spamassassin/sa-update-hooks.d/amavisd-new executable. But since this is a conffile, an existing file isn't being fixed on upgrade from existing installations. Anybody starting from squeeze (or presumably earlier) is affected. Therefore: On squeeze, spamassassin silently fails to restart amavisd on update. On wheezy and sid, fresh installations work correctly, but upgrades on systems originally on squeeze do not work. Please could you add logic to check and correct for this in amavisd-new.postinst? Downstream bug: https://launchpad.net/bugs/1101160 Workaround: sudo chmod 755 /etc/mail/spamassassin/sa-update-hooks.d/amavisd-new Thanks, Robie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703970: winbind_krb5_locator.so missing from binary packages
Package: samba Version: 2:3.6.13-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring winbind_krb5_locator.so is built but does not appear in any binary package, making it unavailable to users. The manpage, however, is installed. From the manpage: The winbind_krb5_locator.so file needs to be manually copied to the plugin directory of the system Kerberos library. For MIT Kerberos this is often: /usr/lib/krb5/plugins/libkrb5/. For Heimdal Kerberos this is often: /usr/lib/plugin/krb5/. Please check your local Kerberos installation for the correct paths. No modification in /etc/krb5.conf is required to enable the use of this plugin. After copying the locator plugin to the appropriate plugin directory it should immediately be available for use. Users should be able to kinit into their kerberized Windows environment without any modification or servers being put manually into /etc/krb5.conf. Ideally this would Just Work when used with either MIT or Heimdal Kerberos, but even if for now it would need manual intervention, it would be nice to at least have this binary available somewhere. Downstream bug: https://launchpad.net/bugs/1159715 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702797: DEB_BUILD_OPTIONS' parallel flag is not parsed correctly
Package: mongodb Version: 1:2.2.2-1 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring ubuntu-patch If I use DEB_BUILD_OPTIONS=nocheck parallel=3 then DEB_SCONS_OPTIONS ends up getting set to -jnocheck (or something like that) and the build fails. This violates Debian Policy (section 4.9.1). The fix is trivial. Patch below. I've taken the parsing of the parallel flag directly from the example in policy. Thanks --- debian/rules.orig 2013-03-11 15:41:39.282043551 + +++ debian/rules2013-03-11 15:42:10.834051515 + @@ -14,7 +14,7 @@ DEB_SCONS_OPTIONS := --d=DEBUGBUILD endif ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS))) - PROCS=$(subst parallel=,,$(DEB_BUILD_OPTIONS)) + PROCS=$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) DEB_SCONS_OPTIONS += -j$(PROCS) endif -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699450: mib2c manpage missing
Package: libsnmp-dev Version: 5.4.3~dfsg-2.7 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring Downstream bug: https://launchpad.net/bugs/381 mib2c.1 is symlinked to mib2c-update.1 even though upstream provides mib2c.1. This means that the binary package fails to deliver a correct mib2c.1. I've investigated this and found that it is being mangled in debian/fixman. When I enabled the debugging comment: echo $f2 commands = $commands I got: mib2c-update commands = mib2c It looks like the sed on line 23 is erroneously dropping the '-'. Thanks, Robie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695264: managed-keys-directory issue causes 100% CPU usage
Package: bind9 Version: 1:9.8.4.dfsg-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring Downstream report: https://launchpad.net/bugs/1038199 If /var/cache/bind cannot be written to due to bug 316241 in an otherwise default installation, or (I haven't tried this) apparently if managed-keys-directory is not specified in the configuration, then named consumes 100% CPU. Filing this to help tracking of bug 316241. I presume it is also an upstream bug though I haven't tested this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#316241: Steps to reproduce
tags 316241 - unreproducible retitle 316241 maintainer scripts mishandle /var/cache/bind permissions thanks Downstream bug: https://launchpad.net/bugs/1086775 The problem is that the postinst only sets permissions on /var/cache/bind on a fresh install. When the bind9 package is removed but not purged, /var/cache/bind is removed, but /etc/bind is left alone (as expected). When the bind9 package is reinstalled from this state, the postinst fails to correct the default 755 permissions on /var/cache/bind. This is particularly a problem for users upgrading to wheezy, since this situation causes 100% CPU usage due to bug 695264. Steps to reproduce: 1. Start with a squeeze system 2. apt-get install bind9 3. apt-get remove bind9 4. apt-get install bind9 Note broken permissions in /var/cache/bind. This isn't directly reproducible in wheezy or sid because files are now left behind in /var/cache/bind causing /var/cache/bind to not be removed when the package is removed (is this a separate bug?) However, if from squeeze you then do: 5. sed -i s/squeeze/wheezy/g /etc/apt/sources.list 6. apt-get dist-upgrade Then the problem propogates to wheezy, and you'll see bug 695264. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715013: Tests not automatically run on package build
Package: ruby-indentation Version: 0.0.7-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy ubuntu-patch Downstream bug: https://launchpad.net/bugs/1197894 ruby-indentation upstream provides test in spec/indentation_spec.rb, but these are not automatically run by dh_ruby --test as part of the package build. The problem seems to be that although debian/ruby-test-files.yaml lists spec/indentation_spec.rb, running spec/indentation_spec.rb itself does not actually run the tests. So I think the problem here is that the packaging makes assumptions about the tests provided by upstream, which don't hold, so dh_ruby --test does not test anything. Adding: require 'rspec/autorun' below the rspec require line in spec/spec_helper.rb fixes the problem, as does adding an override_dh_auto_test of rspec. I'm not a Ruby specialist, so I don't know what the best practice fix for this would be. It looks like using rspec/autotest is optional as far as rspec upstream are concerned, so if upstream don't want to use it, then perhaps the Debian packaging should use a different test specification to dh_ruby, or override dh_auto_test as above. I've applied the following fix in Ubuntu for now: diff -Nru ruby-indentation-0.0.7/debian/rules ruby-indentation-0.0.7/debian/rules --- ruby-indentation-0.0.7/debian/rules 2013-05-06 02:39:32.0 + +++ ruby-indentation-0.0.7/debian/rules 2013-07-05 12:38:30.0 + @@ -13,3 +13,8 @@ %: dh $@ --buildsystem=ruby --with ruby + +override_dh_auto_test: +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) + rspec +endif -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715399: Please add dep8 smoke test
Package: libapache2-mod-python Version: 3.3.1-11 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy ubuntu-patch Hi, Please consider adding the following basic dep8 test so that we can automatically test that the package is hooking up to apache2 correctly. Thanks! diff -Nru libapache2-mod-python-3.3.1/debian/control libapache2-mod-python-3.3.1/debian/control --- libapache2-mod-python-3.3.1/debian/control 2013-05-26 21:09:52.0 + +++ libapache2-mod-python-3.3.1/debian/control 2013-07-08 19:18:35.0 + @@ -10,6 +10,7 @@ Vcs-Browser: http://anonscm.debian.org/viewvc/python-modules/packages/libapache2-mod-python/trunk/ Homepage: http://www.modpython.org/ Standards-Version: 3.9.4 +XS-Testsuite: autopkgtest Package: libapache2-mod-python Architecture: any diff -Nru libapache2-mod-python-3.3.1/debian/tests/control libapache2-mod-python-3.3.1/debian/tests/control --- libapache2-mod-python-3.3.1/debian/tests/control1970-01-01 00:00:00.0 + +++ libapache2-mod-python-3.3.1/debian/tests/control2013-07-08 18:56:04.0 + @@ -0,0 +1,3 @@ +Tests: smoke +Restrictions: needs-root +Depends: libapache2-mod-python, wget, apache2 diff -Nru libapache2-mod-python-3.3.1/debian/tests/smoke libapache2-mod-python-3.3.1/debian/tests/smoke --- libapache2-mod-python-3.3.1/debian/tests/smoke 1970-01-01 00:00:00.0 + +++ libapache2-mod-python-3.3.1/debian/tests/smoke 2013-07-08 13:42:39.0 + @@ -0,0 +1,23 @@ +#!/bin/sh +set -e + +cat /etc/apache2/apache2.conf EOT +Directory /var/www/python/ + SetHandler mod_python + PythonHandler mod_python.publisher +/Directory +EOT + +mkdir /var/www/python +cat /var/www/python/hello.py EOT +#!/usr/bin/python + +def index(): +return Hello, world!\n +EOT + +a2enmod python +service apache2 reload + +output=`wget -O- http://localhost/python/hello.py 2/dev/null` +test $output = Hello, world! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717172: Stripping golang binaries causes crashes
Package: golang
Version: 2:1.1.1-3
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy ubuntu-patch
Downstream bug: https://launchpad.net/bugs/1200255
golang binaries crash on some architectures if they are stripped during
packaging. Upstream are aware of this, but do not currently support the
stripping of binaries.
Dave Cheney says:
* not supported, as in, we don't support it, and recommend against
it when asked
* not tested, we don't test stripped binaries as part of the build
CI process
* is often broken, stripping a go binary will produce anywhere
from no, to subtle, to outright execution failure, see above
* doesn't do what you want, we have a flag called -g, but the
information it stores in the elf sections is a superset of what
strip thinks it is removing, in short, strip does not strip out
the debug data, we hide it too well.
To clarify my previous statements.
* I do not disagree with the debian policy, it is there for a good
reason
* Having said that, it stripping Go binaries doesn't work, and
nobody is looking at making it work, so there is that.
Thanks for patching the build formula.
Debian policy says that binaries should be stripped, not must be
stripped, so I assumed that policy permits this, and that applying the
following patch would be the pragmatic thing to do for Ubuntu. I think
that doing anything else would be considerable effort. Please consider
the same for Debian.
diff -Nru golang-1.1.1/debian/rules golang-1.1.1/debian/rules
--- golang-1.1.1/debian/rules 2013-07-11 14:13:41.0 -0400
+++ golang-1.1.1/debian/rules 2013-07-16 08:19:46.0 -0400
@@ -95,7 +95,8 @@
find $(CURDIR)/debian/golang-go/usr/lib/go/pkg -exec touch -r
$(CURDIR)/debian/golang-go/usr/lib/go/pkg {} \;
override_dh_strip:
- dh_strip -X.a -Xgoinstall -Xgodoc -Xgoyacc -Xbin/cgo -Xebnflint
-Xgofix -Xgofmt -Xgovet -Xgotest --dbg-package=$(PACKAGE)-dbg
+ # strip disabled as golang upstream doesn't support it and it makes go
+ # crash. See https://launchpad.net/bugs/1200255.
override_dh_prep:
dh_prep
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717343: Wrong Apache version
notfound 717343 2.4.4-6ubuntu5 found 717343 2.4.4-6 thanks Oops - I reported the Ubuntu package version I tested, not the Debian version. I did test both - just had two windows open at once, and used the wrong one to grab the version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727622: ServerKeyBits should use upstream default of 1024
Package: openssh-server Version: 1:6.2p2-6 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu trusty Upstream now uses a default of 1024 for ServerKeyBits, as documented in sshd_config(1). However, openssh-server.postinst hardcodes Debian's default to 768 in create_sshdconfig. Can this be switched to 1024 to match upstream, at least for new installations? Downstream bug: https://launchpad.net/bugs/1244272 Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730762: dep8 test for basic parameterised class use
Package: puppet
Version: 3.3.1-1
Severity: wishlist
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch
Please add the following dep8 test, which was useful for picking up and
verifying the missing ruby-hiera dependency problem in:
http://anonscm.debian.org/gitweb/?p=pkg-puppet/puppet.git;a=commitdiff;h=11a376f8348dfa2c254b19f7b29aec13940aeb92
https://launchpad.net/bugs/1242363
This test is also a useful smoke test for puppet's standalone mode.
---8---
diff -Nru puppet-3.2.4/debian/tests/control puppet-3.2.4/debian/tests/control
--- puppet-3.2.4/debian/tests/control 2013-09-03 20:39:18.0 +
+++ puppet-3.2.4/debian/tests/control 2013-11-29 10:14:25.0 +
@@ -5,3 +5,8 @@
Tests: puppetmaster-passenger
Depends: puppetmaster-passenger
Restrictions: needs-root
+
+Tests: parameterised-class
+Depends: puppet
+Features: no-build-needed
+Restrictions: allow-stderr
diff -Nru puppet-3.2.4/debian/tests/parameterised-class
puppet-3.2.4/debian/tests/parameterised-class
--- puppet-3.2.4/debian/tests/parameterised-class 1970-01-01
00:00:00.0 +
+++ puppet-3.2.4/debian/tests/parameterised-class 2013-11-29
10:07:12.0 +
@@ -0,0 +1,19 @@
+#!/bin/sh
+set -ex
+
+# This test was written in response to: https://launchpad.net/bugs/1242363
+# Author: Robie Basak robie.ba...@ubuntu.com
+
+cat $ADTTMP/test.pp EOT
+class foo(\$content=abc\\n) {
+file { '$ADTTMP/test-result': content = \$content; }
+}
+
+class {foo:}
+EOT
+
+rm -f $ADTTMP/test-result
+puppet apply $ADTTMP/test.pp
+result=`cat $ADTTMP/test-result`
+
+test $result = abc
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730771: Regression in system fallback for date_default_timezone_get()
Package: php5-cli Version: 5.5.6+dfsg-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu trusty Steps to reproduce: 1. Set a timezone other than UTC using dpkg-reconfigure tzdata. 2. $ php -r 'echo date_default_timezone_get().\n;' Expected results: system timezone (eg. Europe/London) Actual results: PHP Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in Command line code on line 1 UTC This is a regression from wheezy. Some background: Justification for patching in system timezone: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618462#10 Previous regression in Ubuntu (merged in the window when Debian was regressed in unstable, but never released): https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1069529 Current regression in Ubuntu, which also applies to Debian sid: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1244343 I guess the previous patch needs to be ported forward to 5.5? Thanks, Robie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730771: Regression in system fallback for date_default_timezone_get()
I should add that I verified that this bug also affects Debian by verifying a success case in a wheezy lxc container, and verifying the failure case in a sid lxc container. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731352: ntpdate-debian ignores DHCP ntp-servers option by default
Package: ntpdate Version: 1:4.2.6.p5+dfsg-3 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu trusty Downstream bug: https://bugs.launchpad.net/maas/+bug/1257082 It's not clear if this is a bug or intended behaviour. I'd appreciate your consideration. We are using machines which don't have persistent RTCs, and so want to use the DHCP-supplied NTP server on boot to set the clock correctly. Doing this with ntpdate through /etc/dhcp/dhclient-exit-hooks.d/ntpdate seems appropriate. Most of the code needed already exists, and it seems to me that the intention is that the ntpdate package will arrange this automatically and by default. However, the logic in /usr/sbin/ntpdate-debian does not use or examine /var/lib/ntpdate/default.dhcp if NTPDATE_USE_NTP_CONF is set to yes, which is the default, even when the ntp package is not installed and /etc/ntp.conf does not exist. It seems to me that the setting of NTPDATE_USE_NTP_CONF=yes is nonsensical if there is no /etc/ntp.conf, and so should be treated as if it says no in this case. Alternatively, should /var/lib/ntpdate/default.dhcp be added to the search list for the NTPDATE_USE_NTP_CONF=yes case, after /etc/ntp.conf? Thanks, Robie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678252: Please drop gcc-4.4 build dependency now
It has been almost a year since the last comment on this bug. Upstream still don't appear to support building the embedded ssl library on the current gcc in a way that works. Can the decision to build with gcc 4.4 instead of disabling the i386 assembly optimisations now be reconsidered? Perhaps with a view to making this change when jessie opens? Note that AFAICT the optimisations are only enabled when __i386__ is defined, so amd64 has been relying on gcc's optimisation for the portable C equivalent anyway. I think it's also reasonable to doubt the usefulness of the assembly that's being used, since it was clearly designed and compared against an older version of gcc, and using a newer gcc invalidates any assumptions that the assembly optimisations provide any performance benefit anyway. There is a regression risk, but only if the underlying code is broken. Since the test suite detected the original problem, I think it's reasonable to consider it to have adequate coverage to manage the risk. So can we now define TAOCRYPT_DISABLE_X86ASM and drop the use of gcc-4.4 please? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721095: Updated patch
I found three errors in the previous patch (shebang, heredoc and test stderr output). Updated patch attached. Details of what I fixed are in the Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1217474 Thanks. diff -u crash-6.1.6/debian/control crash-6.1.6/debian/control --- crash-6.1.6/debian/control +++ crash-6.1.6/debian/control @@ -6,6 +6,7 @@ Uploaders: Build-Depends: debhelper (= 9), dpkg-dev (= 1.16.1), quilt (= 0.47), binutils, binutils-dev, zlib1g-dev, libncurses5-dev Standards-Version: 3.9.3.1 +XS-Testsuite: autopkgtest Package: crash Architecture: i386 ia64 alpha powerpc amd64 armhf diff -u crash-6.1.6/debian/changelog crash-6.1.6/debian/changelog --- crash-6.1.6/debian/changelog +++ crash-6.1.6/debian/changelog @@ -1,3 +1,9 @@ +crash (6.1.6-1ubuntu2) saucy; urgency=low + + * Add a live autopkgtest to run crash on running kernel. + + -- Chris J Arges chris.j.ar...@canonical.com Tue, 27 Aug 2013 12:37:03 -0500 + crash (6.1.6-1ubuntu1) saucy; urgency=low * Merge from Debian unstable. Remaining changes: only in patch2: unchanged: --- crash-6.1.6.orig/debian/tests/control +++ crash-6.1.6/debian/tests/control @@ -0,0 +1,3 @@ +Tests: live +Restrictions: needs-root allow-stderr +Depends: @, lsb-release only in patch2: unchanged: --- crash-6.1.6.orig/debian/tests/live +++ crash-6.1.6/debian/tests/live @@ -0,0 +1,20 @@ +#!/bin/sh -x +set -e + +echo Adding linux-image debug symbols. +if [ $(lsb_release -is) = Debian ]; then +sudo apt-get install linux-image-$(uname -r)-dbg +elif [ $(lsb_release -is) = Ubuntu ]; then +sudo tee /etc/apt/sources.list.d/ddebs.list EOF +deb http://ddebs.ubuntu.com/ $(lsb_release -cs) main restricted universe multiverse +deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-security main restricted universe multiverse +deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-updates main restricted universe multiverse +deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-proposed main restricted universe multiverse +EOF +sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ECDCAD72428D7C01 +sudo apt-get update +sudo apt-get install linux-image-$(uname -r)-dbgsym +fi + +echo Testing crash on live kernel +sudo crash -st /usr/lib/debug/boot/vmlinux-$(uname -r)
Bug#730771: [php-maint] Bug#730771: Regression in system fallback for date_default_timezone_get()
user ubuntu-de...@lists.ubuntu.com
usertag 730771 + ubuntu-patch
tag 730771 + patch
thanks
On Thu, Dec 12, 2013 at 11:36:03AM +0100, Ondřej Surý wrote:
On Fri, Nov 29, 2013, at 13:30, Robie Basak wrote:
I guess the previous patch needs to be ported forward to 5.5?
Any volunteers on Canonical side?
I chased this down as I was merging 5.5.8+dfsg-2 in Ubuntu.
Patch attached. It looks like the patch to ext/date/php_date.c was
inadvertently dropped at some point; restoring it fixes the regressed
functionality.
I will simultaneously upload this fix with my merge in Ubuntu.
Subject: Use system timezone
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730771
Bug-Ubuntu: https://launchpad.net/bugs/1244343
Forwarded: not-needed
Acked-By: Robie Basak robie.ba...@ubuntu.com
Last-Update: 2014-01-21
Upstream don't want this patch. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730771 for a summary.
This delta is recovered from previous versions of the system timezone patch in
Debian, and appears to have inadvertently been dropped. Author unknown.
To be used in tandem with use_embedded_timezonedb.patch and use_embedded_timezonedb_fixes.patch.
---
--- a/ext/date/php_date.c
+++ b/ext/date/php_date.c
@@ -969,6 +969,23 @@
DATEG(timezone_valid) = 1;
return DATEG(default_timezone);
}
+ /* Try to guess timezone from system information */
+ {
+ struct tm *ta, tmbuf;
+ time_t the_time;
+ char *tzid = NULL;
+
+ the_time = time(NULL);
+ ta = php_localtime_r(the_time, tmbuf);
+ if (ta) {
+ tzid = timelib_timezone_id_from_abbr(ta-tm_zone, ta-tm_gmtoff, ta-tm_isdst);
+ }
+ if (! tzid) {
+ tzid = UTC;
+ }
+
+ return tzid;
+ }
/* Fallback to UTC */
php_error_docref(NULL TSRMLS_CC, E_WARNING, DATE_TZ_ERRMSG We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.);
return UTC;
Bug#736087: [debian-mysql] Bug#736087: mysql-5.5: Please install AppArmor profile on Debian too
I've just submitted a patch for this: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-February/006409.html I'd like to counter some of your points, as I think it does make sense for Debian to cover this. I do have an ulterior motive here, though, which is that carrying this in Debian will reduce the size of the Ubuntu delta, and thus cause less work for me. Summary: most of your arguments are true for AppArmor generally, rather than specifically for MySQL packaging. Since AppArmor is optional in Debian, users who choose to use AppArmor accept these things by choosing to use AppArmor in the first place. Thus, it doesn't make sense to hold back from adding AppArmor profiles in the first place, since users are opting in already. On Tue, Jan 21, 2014 at 10:18:05AM +0100, Kristian Nielsen wrote: For a long time on Ubuntu, the MariaDB apparmor package was installed by default, and of course on Ubuntu apparmor is activated by default. This caused a lot of problems for our users, who would come to our IRC or mailing list with strange failures that they did not understand. And probably for each one who came, there were 10 who just gave up silently. With MySQL, it is very common to have to access files in various non-standard places. Eg. to move the data directory (or part of it) to different volumes for space. Such updates break mysteriously when the user is not aware of the need to simultaneously update the apparmor profile. Agreed. I often get bitten by AppArmor in this way too, by forgetting to check dmesg. But this is a consequence of using AppArmor on a server system generally and isn't specific to MySQL. You certainly will need to prevent the installation of a default apparmor profile when there is an existing /etc/mysql/my.cnf installed by the user. Otherwise things will certainly break if any stuff has moved to different directories. I think it is acceptable to expect the user to modify the shipped AppArmor profile if he chooses to alter the paths of things on his system; this is an accepted consequence of choosing to use AppArmor in the first place. The problem is made worse since the user can test permissions outside of the mysqld binary and everything will look perfect - only when actually running the mysqld binary does the error appear. Assuming the user is even capable of reading the server error logs to see the permission denied error in the first place, many are not. This is also a general consequence of using AppArmor. The fact that apparmor restricts the binary, not the process, just makes the problem much worse. The permissions really need to be attached to the _process_, attaching to /usr/sbin/mysqld is just wrong. It is perfectly possible and sensible to run multiple instances of mysqld at the same time, and then it makes no sense to have the same permissions for both. AppArmor can do this - using aa-exec(1) and non-attaching profiles, you can start multiple instances of mysqld contrained by different profiles. Heck, it is not even possible as a normal user to run the mysql testsuite with an apparmor profile installed! (As this needs to run lots of /usr/sbin/mysqld instances in a local directory as a non-root user). Good point. Perhaps this one should be special cased with a wrapper, as you describe elsewhere. I think things got a milion time better for our users when we finally gave in and stopped installing the apparmor profile by default in our packages. Lots of problems solve for the users, and I really do not see any practical security lost by it (remember that by default we ship with socket listening only on 127.0.0.1 and running as a separate unprivileged mysql user). Of course, in the end it is up to people more involved in the distros to decide (For myself, I've long since learned to just disable apparmor :-) You make good arguments as to whether AppArmor should be installed by default. But I think that all your points are covered by Debian not installing AppArmor by default today. I don't think it should be for individual packages to override the user's choice of installing AppArmor by then not shipping profiles. By installing AppArmor, he already makes the choice, and it is acceptable for packages to then honor that choice by shipping profiles. Robie signature.asc Description: Digital signature
Bug#738984: dpkg-buildflags overrides CFLAGS amendments
Source: php5 Version: 5.5.9+dfsg-1 Severity: important Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu trusty ubuntu-patch Downstream bug: https://launchpad.net/bugs/1280044 Currently, debian/rules makes some additions to CFLAGS, including the use of `getconf LFS_CFLAGS` for large file support on i386. However, it then includes /usr/share/dpkg/buildflags.mk, which wipes out these changes. This causes all previous CFLAGS changes to be wiped out, including large file support. I can see the consequence of this in the build log when I build i386, where CFLAGS is missing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. If I understand your intent correctly, simply moving the buildflags.mk include to the top fixes this. Proposed patch: diff -Nru php5-5.5.9+dfsg/debian/rules php5-5.5.9+dfsg/debian/rules --- php5-5.5.9+dfsg/debian/rules2014-01-11 22:49:54.0 + +++ php5-5.5.9+dfsg/debian/rules2014-02-14 14:26:44.0 + @@ -16,6 +16,10 @@ # compatibility to upstream PHP5_COMPAT=no +# enable dpkg build flags +DPKG_EXPORT_BUILDFLAGS = 1 +include /usr/share/dpkg/buildflags.mk + DEB_HOST_GNU_TYPE?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) DEB_HOST_ARCH?= $(shell dpkg-architecture -qDEB_HOST_ARCH) @@ -109,10 +113,6 @@ MAKEFLAGS += -j$(NUMJOBS) endif -# enable dpkg build flags -DPKG_EXPORT_BUILDFLAGS = 1 -include /usr/share/dpkg/buildflags.mk - COMMON_CONFIG=--build=$(DEB_BUILD_GNU_TYPE) \ --host=$(DEB_HOST_GNU_TYPE) \ --sysconfdir=/etc \ signature.asc Description: Digital signature
Bug#736087: [debian-mysql] Bug#736087: mysql-5.5: Please install AppArmor profile on Debian too
reopen 736087 thanks On Thu, Feb 20, 2014 at 02:39:16PM +0100, Felix Geyer wrote: dh_apparmor is still only called on Ubuntu: if [ $(DISTRIBUTION) = Ubuntu ]; then \ dh_apparmor -pmysql-server-5.5 --profile-name=usr.sbin.mysqld; \ fi That means all the postinst magic is missing to create /etc/apparmor.d/local/usr.sbin.mysqld and load the profile. Ah, sorry. This is my fault. signature.asc Description: Digital signature
Bug#734634: Some work in Ubuntu
Hi, I looked at bringing this into Ubuntu ahead of Debian (and submit my work here), though it looks like I need to defer this for now. I hope some of my investigation is useful to anybody else who takes this up. Sergei's branch was very helpful to me - thank you! I intended to pull in your commits to Ubuntu had I finished this, but I didn't get that far. I also noticed that from current git HEAD I had to change override_dh_fixperms to override_dh_fixperms-indep, since etc/freeipmi/freeipmi.conf is only available when building arch-dependent packages. Otherwise the build breaks when not building indeps (eg. on other arches). Full notes at: https://launchpad.net/bugs/1303692 signature.asc Description: Digital signature
Bug#742851: ITP: mod-authnz-persona -- Apache module implementing Persona authentication
Package: wnpp Severity: wishlist Owner: Robie Basak ro...@justgohome.co.uk * Package name: mod-authnz-persona Version : 0.8.1 Upstream Author : Dirkjan Ochtman dirk...@ochtman.nl * URL : https://github.com/mozilla/mod_authnz_persona * License : Apache-2.0 Programming Lang: C Description : Apache module implementing Persona authentication Mozilla Persona allows users to sign in to sites using any of their existing email addresses. It is built on the BrowserID protocol, a decentralized authentication technology based on verified email addresses. This module provides Persona authentication for Apache. signature.asc Description: Digital signature
Bug#742851: ITP: mod-authnz-persona -- Apache module implementing Persona authentication
Ready for review: http://mentors.debian.net/package/mod-authnz-persona There are a few DDs I know whom I can ask for sponsorship; I'll ask them first. signature.asc Description: Digital signature
Bug#745812: apache2.preinst depends on a2query, which may not exist
Package: apache2 Version: 2.4.9-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu utopic Downstream bug: https://launchpad.net/bugs/1312533 apache2.preinst calls a2query if /etc/apache2/ exists, but a2query is supplied by apache2 itself, so is not necessarily available at the time the preinst is called. This happens on upgrade from 2.4.7-1~ if the package was previously installed but removed and not purged. I'm not exactly sure how to fix this - I don't quite follow the existing logic. I verified this on Debian as follows: echo deb http://snapshot.debian.org/archive/debian/20130813T130820Z/ sid main /etc/apt/sources.list apt-get -o Acquire::Check-Valid-Until=false update apt-get install -y apache2 # this installs 2.4.6-3 dpkg -r apache2 echo deb http://cdn.debian.net/debian sid main /etc/apt/sources.list apt-get update apt-get install apache2 # install 2.4.9-1 This blows up as follows: Preparing to unpack .../apache2_2.4.9-1_amd64.deb ... /var/lib/dpkg/tmp.ci/preinst: line 118: a2query: command not found dpkg: error processing archive /var/cache/apt/archives/apache2_2.4.9-1_amd64.deb (--unpack): subprocess new pre-installation script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/apache2_2.4.9-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) signature.asc Description: Digital signature
Bug#745834: dh-apache2 causes a postinst failure when a package depends on an apache2-bin provided module
Package: apache2 Version: 2.4.9-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu utopic If I install apache2 at the same time as libapache2-mod-svn, then it is possible that both packages are unpacked, but libapache2-mod-svn is configured first. In this case, /usr/share/apache2/apache2-maintscript-helper exists, so the dh-apache2 -inserted snippet in libapache2-mod-svn tries to enable the dav_svn module. This depends on the dav module, and the call to a2enmod -m -q dav_svn subsequently fails, causing libapache2-mod-svn to fail silently. During debugging I found that the error message was: ERROR: Module dav does not exist! ERROR: Could not enable dependency dav for dav_svn, aborting At this point, I see that /etc/apache2/mods-available/dav.load does not exist (but /etc/apache2/mods-available/dav.load.dpkg-new does exist). It seems that this is provided by the apache2 binary package, which has yet to be configured. I presume that this causes a2enmod to fail to see it. Steps to reproduce. As root on a fresh amd64 sid machine: apt-get clean apt-get install -y --download-only libapache2-mod-svn apache2 mkdir 1 2 mv /var/cache/apt/archives/*.deb 1/ mv 1/apache2_2.4.9-1_amd64.deb 1/libapache2-mod-svn_1.8.8-2_amd64.deb 2/ dpkg -i 1/* dpkg --unpack 2/* dpkg --configure libapache2-mod-svn This fails with: Setting up libapache2-mod-svn (1.8.8-2) ... dpkg: error processing package libapache2-mod-svn (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: libapache2-mod-svn I'm not sure how best to approach this problem. Given that I am installing the packages together, I do expect dav_svn to be enabled when it is done, so simply not doing so in this case wouldn't really work. Having a2enmod special-case .dpkg-new files seems bad to me too. We can't depend on apache2 since the module providing package should be able to be installed independently. The only thing I can think of is to notice that apache2 isn't configured, and note what needs to be done later somehow, but this wouldn't be as trivial as I would like it. In Ubuntu, this is causing our subversion dep8 test to fail, since it installs libapache2-mod-svn and apache2 together. I presume this will affect Debian also. I suppose a workaround for now is to have the test install apache2 first. signature.asc Description: Digital signature
Bug#745834: Acknowledgement (dh-apache2 causes a postinst failure when a package depends on an apache2-bin provided module)
Downstream bug filed: https://launchpad.net/bugs/1312854 signature.asc Description: Digital signature
Bug#746480: Please add dep8 test
Package: src:vsftpd Version: 3.0.2-14 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu utopic ubuntu-patch Hi, I've written the attached dep8 test for Ubuntu. This should be useful for Debian as well to help prevent regressions in the vsftpd package. HTH, Robie From 3381547f4371c972db5758a04639b9f0fbe7ee41 Mon Sep 17 00:00:00 2001 From: Robie Basak robie.ba...@canonical.com Date: Tue, 29 Apr 2014 11:07:32 + Subject: [PATCH] * Add dep8 test. --- debian/control | 1 + debian/tests/control | 6 ++ debian/tests/smoke | 45 + 3 files changed, 52 insertions(+) create mode 100644 debian/tests/control create mode 100644 debian/tests/smoke diff --git a/debian/control b/debian/control index d192462..fec25ad 100644 --- a/debian/control +++ b/debian/control @@ -14,6 +14,7 @@ Standards-Version: 3.9.5 Homepage: http://vsftpd.beasts.org/ Vcs-Browser: http://daniel-baumann.ch/gitweb/?p=debian/packages/vsftpd.git Vcs-Git: git://daniel-baumann.ch/git/debian/packages/vsftpd.git +XS-Testsuite: autopkgtest Package: vsftpd Architecture: any diff --git a/debian/tests/control b/debian/tests/control new file mode 100644 index 000..0245c2a --- /dev/null +++ b/debian/tests/control @@ -0,0 +1,6 @@ +# Ideally, this test should be run in both LXC and qemu environments, since +# behaviour was shown to fail in only one environment in LP: #1219857. But we +# do not have the ability to request this yet. +Tests: smoke +Depends: vsftpd +Restrictions: needs-root allow-stderr breaks-testbed diff --git a/debian/tests/smoke b/debian/tests/smoke new file mode 100644 index 000..1bee1c0 --- /dev/null +++ b/debian/tests/smoke @@ -0,0 +1,45 @@ +#!/bin/sh +set -ex + +# Simple smoke test for vsftpd. Tests get and put functionality. +# Author: Robie Basak robie.ba...@canonical.com +# dep8 restrictions: breaks-bestbed needs-root allow-stderr + +# Written in response to https://launchpad.net/bugs/1219857 +# This passed on LXC, affecting qemu only. So it is advisable to test both. + +# Enable writes, to test both get and put +sed -i 's/^#\(write_enable=YES\)$/\1/' /etc/vsftpd.conf +service vsftpd reload + +# Create test user +adduser --disabled-password --gecos '' ftptest +echo ftptest:dep8|chpasswd ftptest + +# Set up .netrc so that the ftp client can login in automatically + ~ftptest/.netrc +chown ftptest: ~ftptest/.netrc +chmod 600 ~ftptest/.netrc +cat ~ftptest/.netrc EOT +machine localhost +login ftptest +password dep8 +EOT + +# Test get and put + +mkdir ~ftptest/local ~ftptest/remote +echo Hello, world! 1. ~ftptest/local/put +echo Hello, world! 2. ~ftptest/remote/get +chown -R ftptest: ~ftptest/local ~ftptest/remote + +su -c 'ftp localhost' - ftptest EOT +lcd local +cd remote +get get +put put +quit +EOT + +cmp ~ftptest/local/put ~ftptest/remote/put +cmp ~ftptest/local/get ~ftptest/remote/get -- 1.9.1 signature.asc Description: Digital signature
Bug#746481: Missing watch file
Package: src:vsftpd Version: 3.0.2-14 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu utopic ubuntu-patch Hi, In Ubuntu, we appear to have a delta against you for a debian/watch file. This should be useful for you to carry too. HTH, Robie From ecfb7ae6d3617403cbb07ff47353ee3184e48f78 Mon Sep 17 00:00:00 2001 From: Robie Basak robie.ba...@canonical.com Date: Tue, 29 Apr 2014 09:25:13 + Subject: [PATCH] - Add debian/watch file. --- debian/watch | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 debian/watch diff --git a/debian/watch b/debian/watch new file mode 100644 index 000..cfe8758 --- /dev/null +++ b/debian/watch @@ -0,0 +1,2 @@ +version=3 +ftp://vsftpd.beasts.org/users/cevans/vsftpd-(\d.*).tar.gz -- 1.9.1 signature.asc Description: Digital signature
Bug#704624: Build fails to use -ffreestanding
On Fri, Aug 15, 2014 at 02:35:24AM +0200, Aurelien Jarno wrote: I have not been able to reproduce the issue, neither with 0.4.1-6 nor with version 0.4.1+git-20140423.c559da7c-1 I have just uploaded. Are you sure it is not related to your cross-compiler? I think it is related to Ubuntu's build environment. But I believe it is a bug to build without the -ffreestanding flag in this case, will cause no harm to do so, and not doing so does cause cross-compiling issues. Otherwise you're making the implicit assumption that the build system is the target system, when the nature of the package means that there is no need to do so. The definition from my manpage: -ffreestanding Assert that compilation targets a freestanding environment. This implies -fno-builtin. A freestanding environment is one in which the standard library may not exist, and program startup may not necessarily be at main. The most obvious example is an OS kernel. This is equivalent to -fno-hosted. It seems to me that the correct thing to do is to use this flag in this case, even if it happens to not cause a build failure in your particular build environment. Note: I have not checked applicability for your latest upload (0.4.1+git-20140423.c559da7c-1). I assume for now that the code in this area hasn't changed. signature.asc Description: Digital signature
Bug#758241: No dep8 smoke test
Source: nginx Version: 1.6.1-1 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu utopic ubuntu-patch I've added the following quick dep8 smoke test to Ubuntu, so that I can quickly validate merges. I believe this is also applicable to Debian. Please consider adding it. One minor change I've made to the patch from Debian is to s/nginx-core/nginx-light/, as you don't have a nginx-core binary package. Thanks! --- debian/control | 1 + debian/tests/control | 3 +++ debian/tests/smoke | 4 3 files changed, 8 insertions(+) create mode 100644 debian/tests/control create mode 100644 debian/tests/smoke diff --git a/debian/control b/debian/control index 1883c86..2194932 100644 --- a/debian/control +++ b/debian/control @@ -28,6 +28,7 @@ Standards-Version: 3.9.5 Homepage: http://nginx.net Vcs-Git: git://anonscm.debian.org/collab-maint/nginx.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/nginx.git;a=summary +XS-Testsuite: autopkgtest Package: nginx Architecture: all diff --git a/debian/tests/control b/debian/tests/control new file mode 100644 index 000..6f2b5d4 --- /dev/null +++ b/debian/tests/control @@ -0,0 +1,3 @@ +Tests: smoke +Depends: nginx-light, curl +Restrictions: allow-stderr isolation-container diff --git a/debian/tests/smoke b/debian/tests/smoke new file mode 100644 index 000..f85dc7a --- /dev/null +++ b/debian/tests/smoke @@ -0,0 +1,4 @@ +#!/bin/sh +set -ex + +curl -sf http://localhost -- 1.9.rc1 signature.asc Description: Digital signature
Bug#749504: [chdist] bin2src fails with chdist: bad apt-cache : 13
Package: devscripts Version: 2.14.1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu utopic Steps to reproduce: chdist create sid http://ftp.debian.org/debian/ unstable main contrib non-free chdist apt-get sid update chdist bin2src sid apache2-bin Expected output: apache2 (exit status 0) Actual output: chdist: bad apt-cache : 13 (exit status 1) This has affected me on Ubuntu for a while. I have just tested on a fresh Debian sid LXC container, and got the same result, so I think this issue originates on Debian. signature.asc Description: Digital signature
Bug#708132: bcache-tools ITP
Gabriel, David, I'd like to help with getting this package into Debian. What is this waiting on right now, please, and how can I help speed things up? I'd also like to see bcache-tools in Ubuntu, and I see that Gabriel is already maintaining a PPA on Launchpad. I am not a DD (but can poke several), but I can sponsor packages into Ubuntu. I can upload to Ubuntu ahead of a Debian upload if things are held up at the Debian end, but I'd prefer to see the package going in via Debian. I see a recent upload to mentors by David. Is this currently a candidate for upload, or there more work to be done? Do you need a sponsor, or do you have someone looking it already? On a separate (not-really-Debian) note, it'd be great to see somebody maintaining bcache-tools stable releases in Ubuntu for bugfixes and so on. Gabriel (or anyone else), if you're interested, I'd be happy to sponsor these or otherwise coordinate against your PPA with you, rather than step on your toes. Robie signature.asc Description: Digital signature
Bug#708132: bcache-tools ITP
David, I've got some time to look at this again. I'd like to get this landed in the next Ubuntu release. I can send pull requests, we can push to mentors and I can try and get a sponsor first, but failing that I'll upload to Ubuntu ahead of Debian if needed to make this goal. Did you hear back from upstream on the copyright/licensing issue I identified on mentors? If not, shall I file an issue and try and get this resolved? This issue blocks me from getting things done, as it'll get rejected out of the NEW queue otherwise. So I'd like to get this fixed first. Robie signature.asc Description: Digital signature
Bug#574737: Already fixed?
It looks like this is already fixed, since the commit Ian referenced was included in 1.1.0, and urwid is now on 1.2.0-1. Can this bug now be closed? signature.asc Description: Digital signature
Bug#741606: Test suite missing and not run during the package build
Source: websocket-client Version: 0.12.0-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu trusty Upstream bug: https://github.com/liris/websocket-client/issues/65 Downstream bug: https://bugs.launchpad.net/ubuntu/+source/websocket-client/+bug/1292511 Hi, I'm doing some QA on this package in preparation for main inclusion in Ubuntu. I found that upstream has a test suite, but does not ship it in the PyPI tarball, and thus it is not being run as part of the package build. It would be nice if we could do this. I've filed a bug upstream to have it included, and I'd like this bug to track that the tests are being not being run in Debian. In Ubuntu I may end up cherry-picking the entire test suite as a patch and running it to fulfill our requirements, but I presume it would be better for Debian to fix this when upstream can ship the test suite directly. Thanks, Robie signature.asc Description: Digital signature
Bug#741606: Test suite missing and not run during the package build
Note that I also had an issue with some upstream tests requiring an Internet connection. I filed https://github.com/liris/websocket-client/pull/66 with a workaround I applied to Ubuntu and to track this. signature.asc Description: Digital signature
Bug#756391: No dep8 tests
Source: nginx Version: 1.6.0-1 Severity: wishlist Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu utopic ubuntu-patch Smoke dep8 test for nginx attached (http://dep.debian.net/deps/dep8/). This helps me quickly check that nothing is fundamentally broken in nginx packaging in Ubuntu. It should be useful for Debian as well. Since Debian doesn't currently have the nginx-core package, you probably want to s/nginx-core/nginx-full/ in debian/tests/control before applying this. From 8d0337fda6dcc9946ca0280a63634368cac6b007 Mon Sep 17 00:00:00 2001 From: Robie Basak robie.ba...@canonical.com Date: Tue, 29 Jul 2014 12:13:42 + Subject: [PATCH 4/8] * Add dep8 smoke test --- debian/control | 1 + debian/tests/control | 3 +++ debian/tests/smoke | 4 3 files changed, 8 insertions(+) create mode 100644 debian/tests/control create mode 100644 debian/tests/smoke diff --git a/debian/control b/debian/control index 1883c86..2194932 100644 --- a/debian/control +++ b/debian/control @@ -28,6 +28,7 @@ Standards-Version: 3.9.5 Homepage: http://nginx.net Vcs-Git: git://anonscm.debian.org/collab-maint/nginx.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/nginx.git;a=summary +XS-Testsuite: autopkgtest Package: nginx Architecture: all diff --git a/debian/tests/control b/debian/tests/control new file mode 100644 index 000..d662282 --- /dev/null +++ b/debian/tests/control @@ -0,0 +1,3 @@ +Tests: smoke +Depends: nginx-core, curl +Restrictions: allow-stderr breaks-testbed isolation-container diff --git a/debian/tests/smoke b/debian/tests/smoke new file mode 100644 index 000..f85dc7a --- /dev/null +++ b/debian/tests/smoke @@ -0,0 +1,4 @@ +#!/bin/sh +set -ex + +curl -sf http://localhost -- 1.9.rc1 signature.asc Description: Digital signature
Bug#708132: bcache-tools ITP
I have some progress to report. I also think that this is ready to upload, though we should sort out a couple of things first. I've added the bcache list (this is the Debian packaging bug) since there is a question about some of these commits that seem to be relevant to upstream but aren't in the upstream branch. I've done some (functional only) testing of bcache itself with a colleague, and we haven't seen any major issues. I think the packaging is good to go, though I've added a removal of one extraneous file and updated debian/copyright. This is in github.com/basak/bcache-tools. I haven't submitted any pull requests to avoid confusion (see below). A colleague (James Page) is a DD and is prepared to upload, provided that we all agree on who will maintain the package first. I'm happy to step up. Who else does? I found following all the various git trees confusing, and think we should resolve this soon after upload. There are three git trees I'm aware of, and I've added a fourth: 1) http://evilpiepirate.org/git/bcache-tools.git 2) git://github.com/g2p/bcache-tools.git 3) git://github.com/squisher/bcache-tools.git 4) git://github.com/basak/bcache-tools.git Vcs-Git points to 2 (g2p). I also noted that the github branches seem to contain commits to the upstream source, too, that aren't present in the upstream repository (1). Can we define which the canonical upstream source tree is, please, and where the canonical Debian packaging branch should be? Then we can work on pushing the changes back to the right places, rather than having scattered branches all over the place. I noticed some changes to the upstream source that don't appear to be in branch 1, for example. I think it would be easiest to upload, since I think it's good to go and this will at least result in a definitive packaging state that we can work from. In the meantime, I think branch 3 contained everything, so I cloned that one to add my two commits. To keep Vcs-Git correct g2p should pull my commits, or else we can change Vcs-Git. So in summary: 1) Define and agree maintainers. 2) g2p to pull my commits, or we agree to change Vcs-Git, or we drop Vcs-Git for now. 3) Upload. Either my colleague (James Page) can do it as he's already reviewed the packaging itself, or someone else. Let me know if there are any objections to James uploading. 4) Sort out which trees are canonical upstream and packaging branches, and push all commits to those places. In the meantime, I'll upload to Ubuntu as I can do that straight away and we're quite close to release now. I hope that we can get Debian straightened out soon. Robie signature.asc Description: Digital signature
Bug#708132: Jessie Freeze
On Sat, Oct 25, 2014 at 09:28:00PM +0300, Jaakko Niemi wrote: I don't see the package in unstable yet, and Jessie release freeze is coming soon. Is there something needed? Thanks for the reminder. I was hoping that Gabriel would appear, pull my commits, and we'd leave Vcs-Git pointing to his Github repo. But as he seems to be away, I've followed up today and got bcache-tools uploaded to NEW. So this should appear as soon as the ftpmasters have reviewed it. Hopefully that will be in enough time to land in testing in time for freeze. Robie signature.asc Description: Digital signature
Bug#764484: dwarves-dfsg: FTBFS with newer elfutils
Package: dwarves-dfsg
Version: 1.10-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu utopic ubuntu-patch
In Ubuntu, the attached patch was applied to achieve the following:
* d/p/DW_TAG_mutable_type: fix FTBFS due to newer elfutils
(LP: #1378841).
You don't need this in Debian until Debian has a newer elfutils, but
presumably this will inevitably happen, so I hope that having this here
is useful.
Thanks for considering the patch.
diff -Nru dwarves-dfsg-1.10/debian/changelog dwarves-dfsg-1.10/debian/changelog
diff -Nru dwarves-dfsg-1.10/debian/patches/DW_TAG_mutable_type
dwarves-dfsg-1.10/debian/patches/DW_TAG_mutable_type
--- dwarves-dfsg-1.10/debian/patches/DW_TAG_mutable_type1970-01-01
01:00:00.0 +0100
+++ dwarves-dfsg-1.10/debian/patches/DW_TAG_mutable_type2014-10-08
15:03:04.0 +0100
@@ -0,0 +1,31 @@
+From: Mark Wielaard m...@redhat.com
+Date: Wed, 18 Jun 2014 11:14:07 +0200
+Subject: dwarves_fprintf: DW_TAG_mutable_type doesn't exist.
+
+DW_TAG_mutable_type was a mistake in an early DWARFv3 draft and was
+removed in the final version.
+
+http://dwarfstd.org/ShowIssue.php?issue=050223.1
+
+Signed-off-by: Mark Wielaard m...@redhat.com
+Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
+
+Origin: upstream,
http://git.kernel.org/cgit/devel/pahole/pahole.git/commit/?id=943a0de0679a34b5e630f85cd01cca35c0d0e544
+Bug-Ubuntu: https://launchpad.net/bugs/1378841
+Last-Update: 2014-10-08
+
+diff --git a/dwarves_fprintf.c b/dwarves_fprintf.c
+index 4d8e0f4..b746864 100644
+--- a/dwarves_fprintf.c
b/dwarves_fprintf.c
+@@ -75,7 +75,6 @@ static const char *dwarf_tag_names[] = {
+ [DW_TAG_unspecified_type] = unspecified_type,
+ [DW_TAG_partial_unit] = partial_unit,
+ [DW_TAG_imported_unit]= imported_unit,
+- [DW_TAG_mutable_type] = mutable_type,
+ [DW_TAG_condition]= condition,
+ [DW_TAG_shared_type] = shared_type,
+ #ifdef STB_GNU_UNIQUE
+--
+cgit v0.10.1
+
diff -Nru dwarves-dfsg-1.10/debian/patches/series
dwarves-dfsg-1.10/debian/patches/series
--- dwarves-dfsg-1.10/debian/patches/series 2012-06-16 10:00:14.0
+0100
+++ dwarves-dfsg-1.10/debian/patches/series 2014-10-08 15:03:16.0
+0100
@@ -1 +1,2 @@
no_shared_no_ebl.diff
+DW_TAG_mutable_type
-- System Information:
Debian Release: jessie/sid
APT prefers trusty-updates
APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13.0-35-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
signature.asc
Description: Digital signature
Bug#763589: Race condition can cause saved time to go backwards
Package: fake-hwclock Version: 0.5 I've observed a system with a correctly working fake-hwclock (originally initalised by NTP) set its time back to shortly after the epoch, including in /etc/fake-hwclock.data. I believe this happened because fake-hwclock save was called after boot before fake-hwclock load was called. I think this happens in the case of a very early shutdown event that calls /etc/init.d/rc 0 before /etc/init.d/rcS has completed. In my case, I have a Raspberry Pi rigged with an external shutdown signal hooked up via udev. If the signal is high at boot time, then the Pi shuts down without fully booting up. I'm not entirely sure that this is the cause, but the race is there. Can we have fake-hwclock save have the same protection as fake-hwclock load? That is, do not write a time that causes /etc/fake-hwclock.data to go backwards, unless forced. Thanks, Robie signature.asc Description: Digital signature
Bug#708132: Jessie Freeze
On Wed, Nov 12, 2014 at 09:00:15AM +, Filippo Giunchedi wrote: doesn't look like the package made in time for the freeze? https://qa.debian.org/excuses.php?package=bcache-tools I'm happy to try and request an unblock if not done already. I think somebody asked informally on IRC in #debian-release and was told no. I'm not as familiar with the Debian release process as I'd like. If you want to ask formally, go right ahead - I don't think anybody else is. Robie signature.asc Description: Digital signature
Bug#778680: mysql-ocaml: Build-Depends on libmysqlclient15-dev which will no longer exist soon
Package: mysql-ocaml Version: 1.1.2-3 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu vivid ubuntu-patch *** /tmp/tmphq3TA_/bug_body In Ubuntu, the attached patch was applied to achieve the following: This will only affect you post-jessie, when we move Debian to MySQL 5.6 also. * Build-Depend on libmysqlclient-dev instead of libmysqlclient15-dev specifically, since that was replaced by libmysqlclient18 in the transition to MySQL 5.5 and is no longer provided by MySQL 5.6. Thanks for considering the patch. *** /tmp/tmphq3TA_/mysql-ocaml_1.1.2-3ubuntu1.debdiff diff -Nru mysql-ocaml-1.1.2/debian/changelog mysql-ocaml-1.1.2/debian/changelog diff -Nru mysql-ocaml-1.1.2/debian/control mysql-ocaml-1.1.2/debian/control --- mysql-ocaml-1.1.2/debian/control2013-12-08 14:03:54.0 + +++ mysql-ocaml-1.1.2/debian/control2015-02-18 12:29:51.0 + @@ -7,7 +7,7 @@ Mehdi Dogguy me...@debian.org Build-Depends: debhelper (= 7.0.50~), - libmysqlclient15-dev, + libmysqlclient-dev, dh-ocaml (= 0.9), ocaml-nox (= 3.11), camlp4 (= 3.11), HTH, Robie signature.asc Description: Digital signature
Bug#778680: mysql-ocaml: Build-Depends on libmysqlclient15-dev which will no longer exist soon
On Wed, Feb 18, 2015 at 12:35:50PM +, Robie Basak wrote: diff -Nru mysql-ocaml-1.1.2/debian/changelog mysql-ocaml-1.1.2/debian/changelog diff -Nru mysql-ocaml-1.1.2/debian/control mysql-ocaml-1.1.2/debian/control --- mysql-ocaml-1.1.2/debian/control 2013-12-08 14:03:54.0 + +++ mysql-ocaml-1.1.2/debian/control 2015-02-18 12:29:51.0 + @@ -7,7 +7,7 @@ Mehdi Dogguy me...@debian.org Build-Depends: debhelper (= 7.0.50~), - libmysqlclient15-dev, + libmysqlclient-dev, dh-ocaml (= 0.9), ocaml-nox (= 3.11), camlp4 (= 3.11), Please note that the binary package dependency needed to be changed too; I omitted this in my original patch. Thanks, Robie signature.asc Description: Digital signature
Bug#778947: Program calls home to check for updates
Package: sweethome3d Version: 4.3+dfsg-2 Severity: serious I've only tested 4.3+dfsg-2 (through Ubuntu 14.04), but I see nothing in changelogs to suggest that this behaviour has changed more recently. By default, sweethome3d calls home by making an HTTP request to http://www.sweethome3d.com/SweetHome3DUpdates.xml. This is a privacy leak. It is configurable once the program is started, however. Expected behaviour: in Debian, this should be patched to be turned off by default. Serious severity justification: I cannot find a reference, but I believe that this is frowned upon enough in Debian to make the package unfit for release. If I'm wrong, I'm happy to be corrected. Thanks, Robie signature.asc Description: Digital signature
Bug#782552: recordfail false positive causes headless servers to hang on boot
Package: grub-common
Version: 2.02~beta2-22
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu vivid ubuntu-patch
Downstream report: https://launchpad.net/bugs/1443735
A headless system will hang indefinitely waiting on user interaction
after a well timed double power failure. This patch changes the default
GRUB_RECORDFAIL_TIMEOUT to 30, so interactive users still get the
opporunity to intervene after a real boot failure, but headless users
will not end up stuck after boot failures that were really power
failures.
diff -Nru grub2-2.02~beta2/debian/patches/quick_boot.patch
grub2-2.02~beta2/debian/patches/quick_boot.patch
--- grub2-2.02~beta2/debian/patches/quick_boot.patch2015-02-11
19:53:36.0 +
+++ grub2-2.02~beta2/debian/patches/quick_boot.patch2015-04-14
02:00:20.0 +0100
@@ -18,7 +18,7 @@
Author: Richard Laager rlaa...@wiktel.com
Forwarded: no
-Last-Update: 2014-01-17
+Last-Update: 2015-04-14
Patch-Name: quick_boot.patch
---
@@ -31,10 +31,10 @@
util/grub.d/30_os-prober.in | 21
7 files changed, 117 insertions(+), 13 deletions(-)
-diff --git a/configure.ac b/configure.ac
-index 7c8d0af..2a7e410 100644
a/configure.ac
-+++ b/configure.ac
+Index: grub2-2.02~beta2/configure.ac
+===
+--- grub2-2.02~beta2.orig/configure.ac
grub2-2.02~beta2/configure.ac
@@ -1594,6 +1594,17 @@ else
fi
AC_SUBST([QUIET_BOOT])
@@ -53,18 +53,23 @@
LIBS=
AC_SUBST([FONT_SOURCE])
-diff --git a/docs/grub.texi b/docs/grub.texi
-index 46b9e7f..28743d5 100644
a/docs/grub.texi
-+++ b/docs/grub.texi
-@@ -1490,6 +1490,15 @@ This option may be set to a list of GRUB module names
separated by spaces.
+Index: grub2-2.02~beta2/docs/grub.texi
+===
+--- grub2-2.02~beta2.orig/docs/grub.texi
grub2-2.02~beta2/docs/grub.texi
+@@ -1490,6 +1490,20 @@ This option may be set to a list of GRUB
Each module will be loaded as early as possible, at the start of
@file{grub.cfg}.
+@item GRUB_RECORDFAIL_TIMEOUT
-+If this option is set, it overrides the default recordfail setting. The
-+default setting is -1, which causes GRUB to wait for user input. This option
-+should be set on headless and appliance systems where access to a console is
++If this option is set, it overrides the default recordfail setting. A setting
++of -1 causes GRUB to wait for user input indefinitely. However, a false
++positive in the recordfail mechanism may occur if power is lost during boot
++before boot success is recorded in userspace. The default setting is 30, which
++causes GRUB to wait for user input for thirty seconds before continuing. This
++default allows interactive users the opportunity to switch to a different,
++working kernel, while avoiding a false positive causing the boot to block
++indefinitely on headless and appliance systems where access to a console is
+restricted or limited.
+
+This option is only effective when GRUB was configured with the
@@ -73,11 +78,11 @@
@end table
The following options are still accepted for compatibility with existing
-diff --git a/grub-core/normal/menu.c b/grub-core/normal/menu.c
-index 7b55c27..a968e0f 100644
a/grub-core/normal/menu.c
-+++ b/grub-core/normal/menu.c
-@@ -604,6 +604,30 @@ run_menu (grub_menu_t menu, int nested, int *auto_boot)
+Index: grub2-2.02~beta2/grub-core/normal/menu.c
+===
+--- grub2-2.02~beta2.orig/grub-core/normal/menu.c
grub2-2.02~beta2/grub-core/normal/menu.c
+@@ -604,6 +604,30 @@ run_menu (grub_menu_t menu, int nested,
static struct grub_term_coordinate *pos;
int entry = -1;
@@ -108,10 +113,10 @@
if (timeout_style == TIMEOUT_STYLE_COUNTDOWN timeout)
{
pos = grub_term_save_pos ();
-diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
-index 62780bf..17350d4 100644
a/util/grub-mkconfig.in
-+++ b/util/grub-mkconfig.in
+Index: grub2-2.02~beta2/util/grub-mkconfig.in
+===
+--- grub2-2.02~beta2.orig/util/grub-mkconfig.in
grub2-2.02~beta2/util/grub-mkconfig.in
@@ -236,7 +236,8 @@ export GRUB_DEFAULT \
GRUB_ENABLE_CRYPTODISK \
GRUB_BADRAM \
@@ -122,10 +127,10 @@
if test x${grub_cfg} != x; then
rm -f ${grub_cfg}.new
-diff --git a/util/grub.d/00_header.in b/util/grub.d/00_header.in
-index 0c82f23..8dc5592 100644
a/util/grub.d/00_header.in
-+++ b/util/grub.d/00_header.in
+Index: grub2-2.02~beta2/util/grub.d/00_header.in
+===
+--- grub2-2.02~beta2.orig/util/grub.d/00_header.in
grub2-2.02~beta2/util/grub.d/00_header.in
@@ -21,6 +21,8 @@ prefix=@prefix@
exec_prefix=@exec_prefix@
datarootdir=@datarootdir@
@@ -135,7 +140,7 @@
export TEXTDOMAIN=@PACKAGE@
export
Bug#783105: pam_limits sets dangerous limit when reading /proc/1/limits from systemd
Package: pam
Version: 1.1.8-3.1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu vivid ubuntu-patch
In Ubuntu, the attached patch was applied to achieve the following:
* d/applied-patches/pam-limits-nofile-fd-setsize-cap: cap the default
soft nofile limit read from pid 1 to FD_SETSIZE.
Debian should probably follow along, unless it wants to risk increasing
the default nofile soft limit beyond FD_SETSIZE. Explanation in the
patch description below.
Thanks for considering the patch.
diff -u pam-1.1.8/debian/patches-applied/series
pam-1.1.8/debian/patches-applied/series
--- pam-1.1.8/debian/patches-applied/series
+++ pam-1.1.8/debian/patches-applied/series
@@ -31 +31 @@
-
+pam-limits-nofile-fd-setsize-cap
only in patch2:
unchanged:
--- pam-1.1.8.orig/debian/patches-applied/pam-limits-nofile-fd-setsize-cap
+++ pam-1.1.8/debian/patches-applied/pam-limits-nofile-fd-setsize-cap
@@ -0,0 +1,58 @@
+From: Robie Basak robie.ba...@ubuntu.com
+Subject: pam_limits: cap the default soft nofile limit read from pid 1 to
FD_SETSIZE
+
+Cap the default soft nofile limit read from pid 1 to FD_SETSIZE since
+larger values can cause problems with fd_set overflow and systemd sets
+itself higher.
+
+See:
+https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031446.html
+http://www.outflux.net/blog/archives/2014/06/13/5-year-old-glibc-select-weakness-fixed/
+https://sourceware.org/bugzilla/show_bug.cgi?id=10352
+https://github.com/systemd/systemd/commit/4096d6f5879aef73e20dd7b62a01f447629945b0
+
+pam_limits reads the default limits from /proc/1/limits. Previously,
+using upstart, this resulted in a 1024 nofile soft limit on Ubuntu
+systems by default. Using systemd, this results in a limit of 65536
+instead. This is not the intention of systemd upstream. See systemd
+commit 4096d6f for an explanation of systemd's behaviour.
+
+If we want to make such a change to the default distribution soft limit
+in PAM, we should do it deliberately and carefully, not accidentally. A
+change should consider what uses select(2) and might inadvertently (and
+incorrectly) assume that file descriptors will always fit into an
+fd_set, what vulnerabilities or crashes the change could consequently
+create, and whether the protection now present with FORTIFY_SOURCE is
+suitably enabled in all relevant builds.
+
+So this keeps the soft limit at 1024 for now. The hard limit will rise
+to 65536 along with systemd. Anything that knows that it will not be
+buggy with respect to fd_set and FD_SETSIZE, such as by using poll(2) or
+epoll(7) instead of select(2), can always raise the soft limit itself
+without issue.
+
+20:54 rbasak slangasek: [...] I'm also not sure how to go about
+upstreaming this as pam_limits seems to be heavily patched already.
+
+Forwarded: no
+Reviewed-by: Adam Conrad adcon...@ubuntu.com
+Reviewed-by: Martin Pitt martin.p...@ubuntu.com
+Last-Update: 2015-04-22
+
+--- a/modules/pam_limits/pam_limits.c
b/modules/pam_limits/pam_limits.c
+@@ -439,6 +439,14 @@ static void parse_kernel_limits(pam_hand
+ pl-limits[i].src_hard = LIMITS_DEF_KERNEL;
+ }
+ fclose(limitsfile);
++
++/* Cap the default soft nofile limit read from pid 1 to FD_SETSIZE
++ * since larger values can cause problems with fd_set overflow and
++ * systemd sets itself higher. */
++if (pl-limits[RLIMIT_NOFILE].src_soft == LIMITS_DEF_KERNEL
++pl-limits[RLIMIT_NOFILE].limit.rlim_cur FD_SETSIZE) {
++ pl-limits[RLIMIT_NOFILE].limit.rlim_cur = FD_SETSIZE;
++}
+ }
+
+ static int init_limits(pam_handle_t *pamh, struct pam_limit_s *pl, int ctrl)
-- System Information:
Debian Release: jessie/sid
APT prefers vivid-updates
APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.19.0-12-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
signature.asc
Description: Digital signature
Bug#785093: No support for non-golang architectures
Package: docker.io
Version: 1.6.0+dfsg1-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu wily ubuntu-patch
Hi,
In Ubuntu we're building successfully for arm64, ppc64el and powerpc
using gccgo since golang-go doesn't support these architectures. This
constitutes almost the entire Ubuntu delta now; the only other remaining
part is already tracked in bug 764405. I think all the relevant parts
have been accepted upstream now, too. Please consider the following
patch. Note that you probably want to tweak the build-depends change to
golang in debian/control; I'm not sure why you have such a complex build
dependency for it but presumably there's a reason (backports?). The bump
in golang-pty-dev version is for wider architecture support, and the
build target needs to be selected correctly in debian/rules. The rest
should be self-explanatory.
I note that go-md2man isn't currently built on the other architectures
in Debian, though it is in Ubuntu; but if that is fixed to use gccgo
separately also as Ubuntu have done, then Debian should be set.
diff -Nru docker.io-1.6.0+dfsg1/debian/control
docker.io-1.6.0+dfsg1/debian/control
--- docker.io-1.6.0+dfsg1/debian/control2015-05-05 07:42:51.0
+
+++ docker.io-1.6.0+dfsg1/debian/control2015-05-07 03:31:25.0
+
@@ -10,7 +11,8 @@
debhelper (=9),
dh-systemd,
go-md2man,
- golang (= 2:1.3-4~) | golang (= 2:1.3-1) | golang ( 2:1.3~),
+ golang [!arm64 !ppc64el !powerpc],
+ gccgo [arm64 ppc64el powerpc],
golang-context-dev (= 0.0~git20140604~),
golang-dbus-dev (= 2~),
golang-fsnotify-dev (= 1.0.4~),
@@ -21,7 +23,7 @@
golang-gosqlite-dev (= 0.0~hg20130530~),
golang-logrus-dev (= 0.7.1~),
golang-mux-dev (= 0.0~git20140505~),
- golang-pty-dev (= 0.0~git20141217~),
+ golang-pty-dev (= 0.0~git20150218~),
libapparmor-dev,
libdevmapper-dev
Standards-Version: 3.9.6
diff -Nru docker.io-1.6.0+dfsg1/debian/patches/arm-syscall-fix.patch
docker.io-1.6.0+dfsg1/debian/patches/arm-syscall-fix.patch
--- docker.io-1.6.0+dfsg1/debian/patches/arm-syscall-fix.patch 1970-01-01
00:00:00.0 +
+++ docker.io-1.6.0+dfsg1/debian/patches/arm-syscall-fix.patch 2015-05-07
03:21:30.0 +
@@ -0,0 +1,25 @@
+commit 2af35822ac0f910a99720a5072de776a785e2b3e
+Author: Adam Conrad adcon...@0c3.net
+Date: Thu Apr 9 07:31:48 2015 -0600
+
+Fix setns syscall number for ARM, this has been wrong all along.
+
+See:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=571503e10045c89af951962ea0bb783482663aad
+
+Forwarded: https://github.com/docker/libcontainer/pull/524
+Origin: upstream,
https://github.com/docker/libcontainer/commit/0e3181a0b0ab36c750708324599a368f69bab601
+Last-Update: 2015-05-07
+
+diff --git a/libcontainer/system/setns_linux.go b/system/setns_linux.go
+index beffd8d..c4f 100644
+--- a/libcontainer/system/setns_linux.go
b/libcontainer/system/setns_linux.go
+@@ -14,7 +14,7 @@ var setNsMap = map[string]uintptr{
+ linux/386: 346,
+ linux/arm64: 268,
+ linux/amd64: 308,
+- linux/arm: 374,
++ linux/arm: 375,
+ linux/ppc64: 350,
+ linux/ppc64le: 350,
+ linux/s390x: 339,
diff -Nru docker.io-1.6.0+dfsg1/debian/patches/arm64-support.patch
docker.io-1.6.0+dfsg1/debian/patches/arm64-support.patch
--- docker.io-1.6.0+dfsg1/debian/patches/arm64-support.patch1970-01-01
00:00:00.0 +
+++ docker.io-1.6.0+dfsg1/debian/patches/arm64-support.patch2015-05-07
03:17:15.0 +
@@ -0,0 +1,24 @@
+Description: Trivial patch to port to arm64
+Author: Adam Conrad adcon...@ubuntu.com
+Origin: upstream,
https://github.com/docker/libcontainer/commit/34dba2f7e76f3fde58eaf623afb57ab18cb7caad
+Forwarded: https://github.com/docker/libcontainer/pull/524
+Last-Update: 2015-05-07
+
+--- a/libcontainer/system/setns_linux.go
b/libcontainer/system/setns_linux.go
+@@ -12,6 +12,7 @@
+ // We are declaring the macro here because the SETNS syscall does not exist
in th stdlib
+ var setNsMap = map[string]uintptr{
+ linux/386: 346,
++ linux/arm64: 268,
+ linux/amd64: 308,
+ linux/arm: 374,
+ linux/ppc64: 350,
+--- a/libcontainer/system/syscall_linux_64.go
b/libcontainer/system/syscall_linux_64.go
+@@ -1,4 +1,4 @@
+-// +build linux,amd64 linux,ppc64 linux,ppc64le linux,s390x
++// +build linux,arm64 linux,amd64 linux,ppc64 linux,ppc64le linux,s390x
+
+ package system
+
diff -Nru docker.io-1.6.0+dfsg1/debian/patches/powerpc-support.patch
docker.io-1.6.0+dfsg1/debian/patches/powerpc-support.patch
--- docker.io-1.6.0+dfsg1/debian/patches/powerpc-support.patch 1970-01-01
00:00:00.0 +
+++
Bug#782768: Tests fail against MySQL 5.6
Source: ruby-mysql2 Version: 0.3.16-2 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu vivid Hi, I'm wearing both my Ubuntu developer hat and my Debian MySQL packaging team hat for this report. This bug will impact Debian when we update to MySQL 5.6 in stretch. In the transition for MySQL 5.6 in Ubuntu, I found that the ruby-mysql2 package failed to build due to failing tests. This seems to be because debian/start_mysqld_and_auto_install.sh attempts to create a database called test, except that the previous call to mysql_install_db already created it. In 5.6, we are no longer patching mysql_install_db to not create the test database, since we aren't using this path to create the default database. Downstream bug: https://launchpad.net/bugs/1423026 The workaround I applied was just to comment out the CREATE DATABASE line: http://launchpadlibrarian.net/197980584/ruby-mysql2_0.3.16-2_0.3.16-2ubuntu1.diff.gz Norvald's suggestion to use IF NOT EXISTS seems to be the best one to me, since I don't particularly want to continue patching mysql_install_db. Robie signature.asc Description: Digital signature
Bug#748618: syslinux-themes-debian: Fails to uninstall: extlinux-update: not found
tags 748618 patch
user ubuntu-de...@lists.ubuntu.com
usertag 748618 ubuntu-patch vivid
thanks
Patch below. I've applied this to Ubuntu. An identical patch also makes
sense for Debian.
diff -Nru syslinux-themes-debian-12/debian/changelog
syslinux-themes-debian-12/debian/changelog
--- syslinux-themes-debian-12/debian/changelog 2014-01-12 22:57:35.0
+
+++ syslinux-themes-debian-12/debian/changelog 2015-04-09 11:44:42.0
+0100
@@ -1,3 +1,10 @@
+syslinux-themes-debian (12-4) unstable; urgency=medium
+
+ * Check that extlinux-update exists before trying to run it in the postrm
+since it may already have been removed (Closes: #748618, LP: #1042511).
+
+ -- Robie Basak robie.ba...@ubuntu.com Thu, 09 Apr 2015 11:44:25 +0100
+
syslinux-themes-debian (12-3) unstable; urgency=low
* QA upload.
diff -Nru
syslinux-themes-debian-12/debian/syslinux-themes-debian-squeeze.postrm
syslinux-themes-debian-12/debian/syslinux-themes-debian-squeeze.postrm
--- syslinux-themes-debian-12/debian/syslinux-themes-debian-squeeze.postrm
2013-05-20 09:19:09.0 +0100
+++ syslinux-themes-debian-12/debian/syslinux-themes-debian-squeeze.postrm
2015-04-09 11:15:50.0 +0100
@@ -4,7 +4,7 @@
case ${1} in
remove)
- if [ -e /etc/default/extlinux ]
+ if [ -x /usr/sbin/extlinux-update -a -e /etc/default/extlinux ]
then
. /etc/default/extlinux
diff -Nru syslinux-themes-debian-12/debian/syslinux-themes-debian-wheezy.postrm
syslinux-themes-debian-12/debian/syslinux-themes-debian-wheezy.postrm
--- syslinux-themes-debian-12/debian/syslinux-themes-debian-wheezy.postrm
2013-05-20 09:19:09.0 +0100
+++ syslinux-themes-debian-12/debian/syslinux-themes-debian-wheezy.postrm
2015-04-09 11:16:09.0 +0100
@@ -4,7 +4,7 @@
case ${1} in
remove)
- if [ -e /etc/default/extlinux ]
+ if [ -x /usr/sbin/extlinux-update -a -e /etc/default/extlinux ]
then
. /etc/default/extlinux
diff -Nru syslinux-themes-debian-12/debian/syslinux-themes-debian.postrm
syslinux-themes-debian-12/debian/syslinux-themes-debian.postrm
--- syslinux-themes-debian-12/debian/syslinux-themes-debian.postrm
2013-05-20 09:19:09.0 +0100
+++ syslinux-themes-debian-12/debian/syslinux-themes-debian.postrm
2015-04-09 11:16:15.0 +0100
@@ -4,7 +4,7 @@
case ${1} in
remove)
- if [ -e /etc/default/extlinux ]
+ if [ -x /usr/sbin/extlinux-update -a -e /etc/default/extlinux ]
then
. /etc/default/extlinux
signature.asc
Description: Digital signature
Bug#790054: Please add Robie Basak as a Debian Maintainer
Package: debian-maintainers Tags: patch Please add me as a Debian Maintainer. jetring changeset attached. Thanks. Comment: Add Robie Basak ro...@justgohome.co.uk as a Debian Maintainer Recommended-By: James Page jamesp...@debian.org Agreement: https://lists.debian.org/debian-newmaint/2015/06/msg00020.html Advocates: https://lists.debian.org/debian-newmaint/2015/06/msg00021.html Date: Fri, 26 Jun 2015 17:47:42 +0100 Action: import Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQINBE6USK4BEADO6I2zh4iDw+eRt5N1k2qL5MG8tBbaM6x12aJ2Y0EoXMtRzDFZ s5BFeHxxPTDsRiAtfLM+u6UMbb85SH11xS02gUTwNLwfmt0tQBWRAvN080GJH4hw lkV3uhJXltn/j690oRZrrNksHEXzRK1So0dMvJqeCXNdMPGqNNKVpwXJf/YazFem nmk1hyZSeF7D+3CRaJb44kagM0Xn7V96QoHJ9y3bZwBzY8H2Z58s8U3FUIhab0qI FJ5iWe04tJtO9nw/HNFQeu3iND01lDd4nr/7qcGnleyP4YPAO25BGypW4sCHegt/ wK3kJk/EF1uHxlrJG9RFWYRObMiWi68s+SuxErP6y13C+Zv/o5ubMdVAp1/obNXq AfRfXwp8GM3pSIX5irnM7M+yxTVVqVnd2t/gEoDgmc+cZ76yUEOrGpOHfizL6Iw4 RjAoY0/KiL+8OQioaeFwJYfg2WdDoLBZ5BtKb3+TTdrm3mq+aMcmuF1odntNwACM YebiyAIlSPGc2U6i90xj9kU4uZ1h3Ilb9ehlxuVRYW/h89iDFZ6f7owUh9ltY1pG TZLDNZPVy7RJ5Dykub56SVTiwqiVAb/mkOlVlkg337sxpdt9gQV8tiWLkH6B8zO8 E61mQinHl5YwipyKBBEsUgcHJKLTsYhYD7Qg6Ogsy6AhLitYTS64CUhfnwARAQAB tCRSb2JpZSBCYXNhayA8cm9iaWVAanVzdGdvaG9tZS5jby51az6JAjoEEwEKACQC GwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFAk6UTEICGQEACgkQ5WS5wnW91S7m 2hAAkwIZGS9t6nV3BNOqrX7oB8J2ITtPrPAiO9I/Bp1iE0QLBz+RxCs3Uf/+e9LJ KsbY47F1EBEh66V8YS6s6W3KWQAXkaIScweo6sUKLBPo+iKoWfGeO0JQ1smh0/at 1nuDgblNx70u+SeX+goVcrjqpOKngCGCmWILQYqpyz3mb0PI8wHKoxQpkGiAa4WL 4ZYG1DxCugmypnq6qKRR1Eb0PwbkzqBYWSmvCDeBrooWOicvspS5bTUMFqPpLQK1 cRQ2KT0ryoSDYFuLV4bDVGJuI2HYkq9sjA7er1uNVUmFC15et7ns2l5ewpkoe0z6 N6xHvWGlHcqC59E0KpHmd7GWGqpZhBvmwgzvLs24nT9r/30rKY09uBwQetb3973f PouI47K8mSOiEXV+xzOcss/Zmaege8E2NxqWcwyiuaZZFcST7EUnHF2w74iu8zKh TSgdxGAZuTtE1BHVL/H+XEzjiakI+sfBbbWmS4TuKrzSIB8jGdkxrVZ2hxHfG2rl aBD79uUbisxsUDocaIwtPt9OLNpb0hjT4RzWDnqCkoD+deYNM8l2wc3Kd2zKmETX 1tOAYWiZ+3j+wRLqeQpqYUGrl+uf4Ayuce4N5cToMVzoe3lcZPVcvfSSnO9o3q7r 8oZlTMG1BfB+Jjp9TjL55VHntGcv3H5ob42GgmuzWIGLsUCIRgQQEQoABgUCTpRL rQAKCRCI7QKDwSo7DQceAJwP0GWCCWOYlHWFqV8wBhphF//vtgCg0Y0i0xrvX/RC DUtXr9Ym5v6yv4eJAhwEEAECAAYFAk6UbEkACgkQ6Gdd7svuzqPqLg/+MSC+Bngn +Q8piUSg/UGaJqWsk4HCUWZoiXNNkzxe0nCcv86rGtgsT54KO93n9KYb5s9bBJOF 5u3ngyNUH5ZIKWei+9996lUhOlDwh5YdBz/6/KmuQeTyI87X8RO6NAWq+EBTwsx/ 8kAWjy+c3W+yJc5te+URemuBVlo9Keriu+7A4dYE9OZzdUA1PnESOT3hLmy61a8H GPtHPwqCULV9FhYcrleLlNu7s6cMQGDh7GXPot1lSwvxbv3q+qYBCD7kSFJiNLoO p8q5vBnDIAcGaxV4Qz+5rJtyctcOPaEysAnuS2a60D/oHHBoNbjUkGInIKZnvxVg 4pUYNlE2CGA8wj3zmiVshBgIZhITerMPUsKsEv8Kc7R0fxNk0sJqZec7B9iiiF8I cxj6GldAdDirOu/Ch4TaZ17ry3kIbssiBCEmRr8/Dizgc5fVO2Eg/+5oJLzz8qpx paredBnJ++sDla1nO1ntFQIfdpwqd1iwWqFQEw1uqFFMO53AlDyxo1x1OAVtSNKW hdvfw71BBNNNY5gqXZPkVi5Y0Z9VwRptEg5Lem3GmFdT+HpuQOdX7upq8wGSJD+e 5q2yd03/6uDk0ucYckOHB2UgfZaZ4tnyxx6aAcqUC8i2eIQY4Zs7xmZSYKbrkaYT 93i0Fyi1eyelrPRuT+TKqToaXDf7RzT5PFyJAhwEEAECAAYFAk6UcksACgkQPXbI RfoUR8r4yQ//fMQHCMcJ4IImHfi9BIvZVU479YrhQAzSPX5Qfq4VxS0LHfBFGL7f qElGdNnBX9rcvUM2khmcNb0PMTypD6fMAbDcUlIQGrKaXne6+YbA3BjaeWZzuddl s2qM5UNHMmAzQGDl6oaj/Pc3csib6LsMcx14nTcQ3euVHGqZkP3zBUBvvoYRKNnr BZXeP12BqQkjJGvVE03/bF4VAvnebpXYMc8j9a8lMDpZDL2tCES+T9ye4ODeBw7h JSQkNzLjL3g3aTMlvicnewQY7xzSPJ+/Bpa1Gfkh3UWLthWzZ5+zR0gtwyuyDjmV Sfn8oImuXgwOSJUv2ymasirYFiWZ2baCI1uMiQUZ0mCtUlOoijwUa0E9xPptSjgH L3s9HWAvlh2idshlE6A2KlwHe6CfSaFwwQKt6a9g4dFlyREdos0dFFCCsBevspfs 7yIk9h0XAG8U7wyZ3EYi+sC5zrAmXlDS6lLhrkd23dRNcjZRuqXPFaZSxRCrHR+M n1+H+dUB2/pZfe/1jys4x8idGzGfH+tTyqfLOkeZJTmC/kHkr580shEYnZFDS0zR pEeUA4hy4Mw2mif2Rw0ZJ/HiPgR711mb5+x/7eoWsysqBns8Q3EDmfqq18c1VcXc H+O9MICfsgUYF92+bsTplQ1xdRUIzF5ydu2KeQItt0h9/4VhSGRuyj2JAhwEEAEC AAYFAk6UcSUACgkQT/vk6S796nJzsQ/+OWGWMgGbqTCA3lSqjRlv1lpJRwr7mCXk BFlGe/9WMxcm3pnEermByaTvKuTUHA9AjdoHpktrpaxKs4gtICIDkm4XrEA8m8Zt a3mWRptpmqzq2X8qKTnSjQT1D6jxlqq8vsJ7PgIBb/zl+nGhcLJtqyv9CZgUiZpw czKoZbAfSKx36W0kP1tRRFCbwUET0C6sR4L3DglF4s9rHSeTFs58a5KaDXUJPugG hg73O+OukG1IN1e6kbDkti9mcZT/hJ3vXjYU4oeBZe27V2gb7+4GQriioG0wevJL d8ZeAj/sognI1xuihKcfSNNYXBzBT/iPwWRj4g19zRTEX/45B3A1o/BlC2FPPsaM 4I1Z/llP7H+QfL2zlATo+AJCAuNp19+dbxNw/3RZHPxFjhIo69oswytMbIJAhC8s HJU5vrhdJc+P8CDZ9iEYQEUpFxew3CFZYDoz3uoEDjUP9c5HGlRzKA59vL4ecGQt 0ZQVpUb2fNoI0xjeyZ59EXAiZZ3eUBJhGhk1U4QOzxDGJHTPhPeYlTPhXtReL8aN 7y8V8NXOcdIW4UqbthgY4VUfrXBSJOBfD/i7LNvPToQmLQ0XGads1aoRvEm5V8z3 9zZzBgLbOpoeJrpGbvXvsNywoiBrFfcINqLPlSbOHuzpXYQ4SMnrzEr6VZf3kfAx aCGKUDshjjSIXgQQEQgABgUCTpR4GQAKCRBU/EFB91gBi/NlAP9X1jAj+KMdUi9+ Few35Q5B9yEOa4pj9MKzfrXGnQHdGAD9EvXYtlyrihQpUzcuNsNvFYWcCfTP0FtG M9vtLZKIujmJAhwEEAECAAYFAk6zOksACgkQspT/bvpcfSktAA//bGGcivNhVKbD 71JInMHMzgKxGoRfAntm9acrwV6IZXjGFoyhCpWxNjVFk2jtneJs+eb17kXIgSfu vw0P6ZyBpq2vcKfxi6PkF7qdshTFTRDSoAdKYT2zWRb3e1lP3R6TSpDtzeZ49GS2 X9D335sjpPotanIr6UNfEUKJU4bKbrTQBjmorUy6QlDLKdXKiVFnSpUMFADZcmkw Nx8Hr/lhd3jHv66kvgkTqHS17SDssIJv4OopSeI/Qb1RgNsL2CM4NEIlrpZt4Vbu 1L2GXU1j9yGWvMDBnxVzbFh/x78cbXxK7T2ac4Tx8dQuZXh2v5w0aLEyXIop0
Bug#787533: [debian-mysql] Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf
On Sun, Jun 14, 2015 at 02:47:00AM +0300, Otto Kekäläinen wrote: ..so at the moment the only thing I can do is to revert all mysql-5.6 compatibility in MariaDB, which would be a huge waste of everybody's time. Can't we make an exception from the policy here as clearly the point of the policy is to make the packages as clean as possible, not impossible? I'm sorry, I had failed to realise that mariadb was affected by my delay in uploading mysql-5.6 in this way. I am working on an upload of mysql-5.6 to fix mysql-common. The new mysql-common replaces the /etc/mysql/my.cnf conffile with a non-conffile maintainer-script-manager symlink (via update-alternatives). It is in VCS, though I want to fix a separate bug before I upload to minimise the impact on users of unstable and testing who will transition from 5.5 to 5.6 as soon as I upload. Maybe this bug can be reassigned to mysql-common, or its severity in mariadb reduced? It doesn't make sense to remove mariadb from testing. Robie signature.asc Description: Digital signature
Bug#787103: Deferring postinst actions fails when triggers are in use
Package: apache2
Version: 2.4.12-2
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu wily ubuntu-patch
This is related to Debian bug 745834. The fix there failed to work on
Ubuntu because our ufw delta introduces the use of triggers, which the
logic that tests if apache2 is configured fails to detect. I believe the
bug also exists in Debian even though it isn't triggered (pun not intended)
right now.
Colin Watson fixed this in an Ubuntu upload in the following patch. His
explanation is in
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1393832/comments/2.
apache2 (2.4.10-8ubuntu2) vivid; urgency=medium
* Allow triggers-awaited and triggers-pending states in addition to
installed when determining whether to defer actions or process
deferred actions (LP: #1393832).
-- Colin Watson cjwat...@ubuntu.com Wed, 26 Nov 2014 11:31:44 +
Please also apply this in Debian.
diff -Nru apache2-2.4.12/debian/apache2.postinst
apache2-2.4.12/debian/apache2.postinst
--- apache2-2.4.12/debian/apache2.postinst 2015-05-10 20:51:59.0
+
+++ apache2-2.4.12/debian/apache2.postinst 2015-05-28 13:40:53.0
+
@@ -419,7 +419,7 @@
cat /var/lib/apache2/deferred_actions |
while read PACKAGE FUNCTION ARG1 ARG2 ARG3
do
- if ! dpkg-query -f '${Status}' -W $PACKAGE|grep -q installed
; then
+ if ! dpkg-query -f '${Status}' -W $PACKAGE|egrep -q
'installed|triggers-awaited|triggers-pending' ; then
# If the package has been removed again, skip the
actions
continue
fi
diff -Nru apache2-2.4.12/debian/debhelper/apache2-maintscript-helper
apache2-2.4.12/debian/debhelper/apache2-maintscript-helper
--- apache2-2.4.12/debian/debhelper/apache2-maintscript-helper 2015-04-28
20:09:06.0 +
+++ apache2-2.4.12/debian/debhelper/apache2-maintscript-helper 2015-05-28
13:40:53.0 +
@@ -76,7 +76,7 @@
fi
APACHE2_MAINTSCRIPT_DEFER=
- if ! dpkg-query -f '${Status}' -W apache2|grep -q installed; then
+ if ! dpkg-query -f '${Status}' -W apache2|egrep -q
'installed|triggers-awaited|triggers-pending'; then
echo Package apache2 is not configured yet. Will defer actions
by package $DPKG_MAINTSCRIPT_PACKAGE.
APACHE2_MAINTSCRIPT_DEFER=/var/lib/apache2/deferred_actions
fi
signature.asc
Description: Digital signature
Bug#739846: [debian-mysql] Bug#739846: invoke-rc.d: initscript mysql, action start failed.
tags 739846 + pending thanks OK, I've pushed commit 6bc2c1a which adds an exit 0 to the end of the script. Please send a patch if I've misunderstood your fix; otherwise this will arrive on our next upload. Thanks, Robie signature.asc Description: Digital signature
Bug#790640: FTBFS: hash.h: No such file or directory
On Tue, Jun 30, 2015 at 05:55:04PM +0200, Mateusz Kijowski wrote: http://bugs.mysql.com/bug.php?id=70672 seems to be the reason. Perhaps we can hack the mysql package to include it? If it's not part of the public API, then I don't think it's appropriate for the package to include it. We'd effectively be forking the MySQL ABI, breaking compatibility with the rest of the ecosystem and generally causing future pain and confusion. This confusion is what I believe upstream are busy trying to fix by better clearly defining the available API to avoid future compatibility problems. It seems like you've fallen on the wrong side of this. Can you work with upstream to get the functionality you need included as part of the public API? signature.asc Description: Digital signature
Bug#790875: logger exits when it cannot log
Package: bsdutils Version: 1:2.26.2-6 Not affected: 1:2.25.2-6 This is a regression from jessie, present in sid. Steps to reproduce: 0. Ensure a syslog daemon is not running. 1. Run logger. Expected behaviour: block on stdin Actual behaviour: exit with status 0 I can easily reproduce this using schroot against jessie vs. sid. Note that if systemd is present then the problem does not occur - I presume because systemd-journald is listening on /dev/log. So this affects chroots and sysvinit-core only. This is a problem because a utility that has its status or error output piped to logger fails due to a broken pipe when it tries to write status to stdout when logger exits. My expectation is that this is a common use case of logger on stdin and I can't think of any other easy way to arrange things such that logger still effectively no-ops in a minimal environment with no running syslog daemon. This causes mysql-server-5.6 to fail piuparts right now (bug 787864) since in piuparts' chroot there is no running syslog daemon. Alternatively, should we be doing something else to log output instead such that it doesn't fall over when syslog is unavailable? Thanks, Robie signature.asc Description: Digital signature
Bug#787864: mysql-server-5.5: fails to start in piuparts test environment
On Fri, Jun 05, 2015 at 09:54:04PM +0200, Andreas Beckmann wrote: during a test with piuparts I noticed your package now fails to start the server in a piuparts test environment, i.e. a a minimal sid or stretch chroot (while jessie works fine). This is most likely a regression introduced by another package since the versions in jessie and sid are the same ... I've pinned this down to a change in the behaviour of logger(1) as used by the postinst and filed bug 790875 against bsdutils. We can always stop using logger or wrap calls to it somehow as a workaround. This bug does not affect anyone running a syslog daemon or systemd, so I think it only affects piuparts testing and the non-default case. On this basis would it be reasonable to drop the severity and stop blocking this package from entering stretch? Robie signature.asc Description: Digital signature
Bug#790257: libmysqlclient-dev no longer provides libmysqlclient15-dev
Hi Martin, On Sat, Jun 27, 2015 at 02:40:19PM -0400, Martin Michlmayr wrote: I've filed this as serious since it breaks other packages, but let me know if the change was intentional and I'll file bugs on the 11 packages instead and close this one. Given that libmysqlclient15-dev hasn't been around for quite a while, I don't think dropping the Provides is unreasonable. The change is intentional (IIRC). We're providing libmysqlclient18 only now, so libmysqlclient15-dev no longer makes sense and packages should build-depend on libmysqlclient-dev if required. Please go ahead and rearrange the bugs. Thanks, Robie signature.asc Description: Digital signature
Bug#790406: mysql-server-core-5.6 and mysql-client-5.5: error when trying to install together
tags 790406 + pending thanks Hi Ralf, On Mon, Jun 29, 2015 at 08:35:28AM +0200, Ralf Treinen wrote: dpkg: error processing archive /var/cache/apt/archives/mysql-server-core-5.6_5.6.25-2_amd64.deb (--unpack): trying to overwrite '/usr/bin/innochecksum', which is also in package mysql-client-5.5 5.5.43-0+deb8u1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for man-db (2.7.0.2-5) ... Errors were encountered while processing: /var/cache/apt/archives/mysql-server-core-5.6_5.6.25-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) innochecksum moved to the server-core package but I had failed to mark a conflict against the previous 5.5 package, as we're replacing 5.5 entirely with 5.6. But it did need a separate conflicts/replaces for the upgrade path and I've now added that in VCS - thanks. Robie signature.asc Description: Digital signature
Bug#739846: [debian-mysql] Bug#739846: invoke-rc.d: initscript mysql, action start failed.
On Tue, Jun 30, 2015 at 02:35:42AM -0600, Bob Proulx wrote: If /etc/mysql/debian-start outputs something, anything, then the test for -n $output is true and then log_action_msg logs it and also returns 0. But if /etc/mysql/debian-start emits nothing then output is empty and -n is non-zero. At that point things fall through to the bottom of the script and exits with the last exit code which means the script exits non-zero as well. Because the action exits non-zero the postinst script fails and dpkg --configure fails. Would it be possible to put an exit 0 at the bottom of the script? It would be good programming. I think it is definitely unintended to exit non-zero when /etc/mysql/debian-start doesn't print anything. Note that the /etc/init.d/skeleton previously included a : at the bottom to essentially do the same thing in a different way. I think ending with a : to be more obscure than the more explicit exit 0 and therefore prefer the latter. But either would be the same. All of the error handling in the script explicitly exits with a non-zero error upon detecting an error. What if /etc/mysql/debian-start fails? Should we be checking the result code of this and exiting with the same status? Or should we be ignoring the result of /etc/mysql/debian-start (as I think we are now) and returning 0 in all cases, as the daemon itself has started? Although if we fail when /etc/mysql/debian-start fails, the daemon would already have been started even though we're returning failure which could be confusing. signature.asc Description: Digital signature
Bug#790875: logger exits when it cannot log
Hi Sami, Andreas,
On Mon, Jul 06, 2015 at 09:29:44AM +0200, Andreas Henriksson wrote:
Robie Basak, could you please try if Samis patch resolves the issue
you where experiencing? See attachement.
Thank you for working on this.
I get an error with this patch: logger: close failed: Bad file
descriptor and a subsequent non-zero exit status which then causes the
postinst to fail. Looking at the code, I think the reason is that
ctl-fd ends up with a file descriptor that failed to connect and thus
has been closed, and then logger_close() tries to close it again.
I fixed up the patch by expicitly returning an fd of -1 on logger_open()
failure (as well as setting ctl-noact to 1) so that ctl-fd ends up
being -1, and then checking for -1 in logger_close().
This now works. I reproduced the original failure and have observed that
it is solved with my amended patch. piuparts succeeds past the stage
that logger was causing it to fail before when I use my locally built
deb of the patched util-linux source.
Please review my amendments and apply.
Thanks,
Robie
--- a/misc-utils/logger.c
+++ b/misc-utils/logger.c
@@ -242,9 +242,10 @@ static int unix_socket(struct logger_ctl
if (ctl-unix_socket_errors)
err(EXIT_FAILURE, _(socket %s), path);
else
- /* See --socket-errors manual page entry for
- * explanation of this strange exit. */
- exit(EXIT_SUCCESS);
+ /* openlog(3) compatibility, socket errors are
+ * not reported, but ignored silently */
+ ctl-noact = 1;
+ return -1;
}
return fd;
}
@@ -685,7 +686,7 @@ static void logger_stdin(struct logger_c
static void logger_close(const struct logger_ctl *ctl)
{
- if (close(ctl-fd) != 0)
+ if (ctl-fd != -1 close(ctl-fd) != 0)
err(EXIT_FAILURE, _(close failed));
free(ctl-hdr);
}
signature.asc
Description: Digital signature
Bug#772823: Review of 1.5.0-1 from mentors.debian.net
Hi, I've reviewed 1.5.0-1 from mentors.debian.net. Note that I am a DM and not a DD so cannot upload this directly to Debian. My review was with my Ubuntu core dev hat as I can upload to Ubuntu directly and would like to do this by Ubuntu's feature freeze on Thursday, hopefully with a concurrent request for sponsorship for a Debian upload. I've only looked at the source and binary packages wrt. interactions with other packages and potential upgrade path issues. I've not actually tested the package - I assume it works. Review notes (blockers): Blocker for upload as there might be upgrade path issues later otherwise: ln -sf /usr/share/doc/kimchi/examples/kimchi.sub.nginx /etc/nginx/sites-available/kimchi (from postinst) will break policy https://www.debian.org/doc/debian-policy/ch-docs.html#s12.3 Packages must not require the existence of any files in /usr/share/doc/ in order to function and also the user expectation that a file in /etc can just be modified and normally conffile handling will occur. I suggest that you just install (duplicate the example in /usr/share/doc/kimchi/examples if you wish) to /etc as a regular conffile (so putting it in kimchi.install will do) instead. With just this fixed I will be happy to upload the package to Ubuntu and recommend to a DD that it is suitable for Debian (though it will still need the DD to review). Review notes (minor): The remaining issues I don't think need to be blockers for upload. These are just observations as I went through; I haven't thought about them in detail and for some of them the resolution may be that no action is required: package-contains-broken-symlink might be worth a lintian override as the symlink gets resolved when dependencies are fulfilled so is a false positive. I don't think the pedantic lintian warnings are an issue - if upstream don't sign releases then you can't verify them and you're already dealing with minified JS by minifying in the build and/or depending on the jquery package as appropriate. It might be worth writing a note for the Debian ftpmaster and/or Ubuntu archive admin explaining it though, perhaps in README.source? The postinst and postrm restart kimchid and nginx daemons. Does this intefere with dh_installinit #DEBHELPER# snippets at all? I see in the binary deb after build that it looks like it'll cause kimchi to be restarted twice on future upgrade, for example. I'm not sure how this could be improved though due to the need to restart nginx from kimchi's postinst. Maybe systemd might have some capability in this area? override_dh_auto_test is used to skip tests. It would be nice to be able to run any upstream tests at package build time, and/or have dep8 tests that can run upstream tests, but I appreciate that this may be difficult due to virt requirements. Upstream currently generate custom DH parameters at build time. This will not help with uniqueness in binary distributions like Debian and Ubuntu and also break reproducible builds. Instead this could be done at install time in the postinst, though that might result in entropy issues, or we could ship well-known parameters instead, or by some kind of user choice between the two. But I am advised by a colleague in Ubuntu security team that this isn't an immediate security issue as-is. I see debian/kimchid.init but this doesn't appear in the built binary. Should this be fixed or removed? Shipping just a systemd unit file is fine for Ubuntu; AIUI in Debian it's friendly to maintain it for users who choose a different init system. Maybe remove /usr/share/kimchi/doc/kimchid.8 as it is shipped in /usr/share/man/man8/kimchid.8.gz? Should /usr/lib/python2.7/dist-packages/kimchi/API.json be in /usr/share/kimchi instead? I'm not really sure about this one. It does seem unusual to have it where it is though. signature.asc Description: Digital signature
Bug#792080: mysql-common: needs to handle upgrades from mariadb-common that creates my.cnf - mariadb.cnf symlink
Hi Andreas, As always, thank you for looking into this! On Wed, Jul 22, 2015 at 12:48:49PM +0200, Andreas Beckmann wrote: move innochecksum manpage to mysql-server-core-5.6, too Please note that these may need to be coordinated with mariadb and percona packaging. Otherwise we could end up with files conflicting (without Breaks/Replaces). Robie signature.asc Description: Digital signature
Bug#793316: transition: mysql-5.6
On Thu, Jul 23, 2015 at 10:59:15AM +0200, Emilio Pozuelo Monfort wrote: Didn't we agree that we would release Stretch with only mariadb? When do you plan to start working on that so we can drop mysql-* from testing? No, that was never agreed. I'm looking after the mysql-* packaging at the moment (with help from Andreas - thanks!), and have no plans to drop mysql-* from testing (only mysql-5.5, to be replaced by mysql-5.6). signature.asc Description: Digital signature
Bug#792080: mysql-common: needs to handle upgrades from mariadb-common that creates my.cnf - mariadb.cnf symlink
Hi Andreas,
On Sat, Jul 11, 2015 at 03:29:02AM +0200, Andreas Beckmann wrote:
Since the issue is hard to describe in detail and with all pitfalls
without digging into it and testing it, I rather developed patches
that I tested in sid and stretch, to ensure sane upgrade paths.
The commit messages should explain all the problems involved ...
if you have more questions, just ask.
Thank you for looking at this! I hadn't quite got round to it since I
ended up focusing on the piuparts logger thing on my last pass over the
MySQL packaging.
Andreas Beckmann (6):
mysql-common.postinst: install my.cnf.fallback alternative after
rm_conffile my.cnf
mysql-common.preinst: revert mariadb-common my.cnf fallback symlink
mysql-common.preinst: recover from unmodfied mariadb.cnf as
my.cnf.migrated
mysql-common.postrm: delete my.cnf.{migrated,old} on purge
mysql-common.postrm: only remove alternatives created by our postinst
mysql-common: add Breaks: mariadb-common ( 10.0.20-3~)
These all look fine to me, but I presume depend on mariadb uploading a
10.0.20-3 with corresponding changes? I'm happy to commit this to git
and get an upload (I'm DM now but I don't think I'm in the keyring yet)
but I guess we should coordinate with Otto for a corresponding mariadb
upload?
Robie
signature.asc
Description: Digital signature
