Bug#795911: jessie-pu: package gtk+3.0/3.14.5-1+deb8u1
The BTS metadata for #748469 and #773135 indicates that they are not yet fixed in unstable. If that's correct, then they need to be resolved there before we can look at fixing them in stable; if not, then the metadata needs to be updated to correctly reflect when (i.e. in which version(s)) the bugs were fixed. Thanks for a very quick response. I have confirmed that the bugs are fixed in unstable. I've both tried to provoke the bug to make it appear, and I've checked the source code to see that the implementation of the bugfix is exactly the same in unstable as here. I will try to quickly look up exactly which version fixed it and add it appropriately to the bug request. Then I will notify you. Thanks. Cheers, Ruben signature.asc Description: Digital signature
Bug#795913: libmail-thread-perl: [PATCH] avoid failing grouping by subject with missing references
Package: libmail-thread-perl
Version: 2.55-1
Severity: normal
Tags: upstream patch
Dear Maintainer,
With incomplete threads, It is possible to for the topmost subroutine to
return undef, so do not blindy assume the simple_subject call will be
made on a Mail::Thread::Container object.
Attached is a patch which avoids the issue by skipping as if the
subject were empty.
Note: upstream hasn't been responsive in years, but Cc-ing the RT
address at CPAN just in case.
-- System Information:
Debian Release: 7.8
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
-- no debconf information
From 9d1837f2118efa614d1acddd09ea7f53aba15ba4 Mon Sep 17 00:00:00 2001
From: Eric Wong e...@80x24.org
Date: Mon, 17 Aug 2015 21:16:25 +
Subject: [PATCH] avoid failing grouping by subject with missing references
It is possible to for the topmost subroutine to return
undef, so do not blindy assume the simple_subject call
will be made on a Mail::Thread::Container object.
---
Thread.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Thread.pm b/Thread.pm
index c6f3230..941ae31 100644
--- a/Thread.pm
+++ b/Thread.pm
@@ -70,7 +70,8 @@ sub _group_set_bysubject {
my %subject;
for (my $walk = $root-child; $walk; $walk = $walk-next) {
-my $sub = $walk-topmost-simple_subject or next;
+my $topmost = $walk-topmost or next;
+my $sub = $topmost-simple_subject or next;
# Add this container to the hash if:
# - There is no container in the hash with this subject, or
# - This one is a dummy container and the old one is not: the dummy
@@ -97,7 +98,8 @@ sub _group_set_bysubject {
for ($walk = $root-child, $rest = eval{ $walk-next };
$walk;
$prev = $walk, $walk = $rest, $rest = eval { $rest-next }) {
-my $subj = $walk-topmost-simple_subject or next;
+my $topmost = $walk-topmost or next;
+my $subj = $topmost-simple_subject or next;
my $old = $subject{$subj};
next if $old == $walk;
--
EW
Bug#795911: jessie-pu: package gtk+3.0/3.14.5-1+deb8u1
On Mon, 17 Aug 2015 23:35:29 +0200 Ruben Undheim ruben.undh...@gmail.com wrote: The BTS metadata for #748469 and #773135 indicates that they are not yet fixed in unstable. If that's correct, then they need to be resolved there before we can look at fixing them in stable; if not, then the metadata needs to be updated to correctly reflect when (i.e. in which version(s)) the bugs were fixed. Thanks for a very quick response. I have confirmed that the bugs are fixed in unstable. I've both tried to provoke the bug to make it appear, and I've checked the source code to see that the implementation of the bugfix is exactly the same in unstable as here. I will try to quickly look up exactly which version fixed it and add it appropriately to the bug request. Then I will notify you. It looks like #748469 was fixed in upstream 3.16.5: http://ftp.gnome.org/pub/gnome/sources/gtk+/3.16/gtk+-3.16.5.changes and #773135 was fixed in 3.15.4 : http://ftp.acc.umu.se/pub/gnome/sources/gtk+/3.15/gtk+-3.15.4.changes
Bug#795914: ITP: cpustat -- lightweight cpu utilization monitoring
Package: wnpp Severity: wishlist Owner: Colin Ian King colin.k...@canonical.com * Package name: cpustat Version : V0.01.21 Upstream Author : Colin Ian King colin.k...@canonical.com * URL : http://kernel.ubuntu.com/~cking/cpustat * License : GPL-2+ Programming Lang: C Description : lightweight cpu utilization monitoring cpustat periodically dumps out the current CPU utilisation statistics of running processes. cpustat has been optimised to have a minimal CPU overhead and typically uses about 35% of the CPU compared to top. cpustat also includes some statistical analysis options that can help characterise the way CPUs are being loaded.
Bug#759604: auditd: Please make auditd log readable by the adm group
Le Mon, 17 Aug 2015 10:37:00 +0200, intrigeri intrig...@debian.org a écrit : Hi, Hey, Sorry for not replying earlier. intrig...@debian.org wrote (28 Aug 2014 21:37:36 GMT) : currently, by default /var/log/audit is root:root / 0750, and /var/log/audit/audit.log is root:root / 0600. The convention for many log files in Debian is to make them readable by members of the adm group. Any reason not to do that for audit.log as well? This would unbreak apparmor-notify when auditd is running in its default configuration. I looked into it a bit closer, and the problem has two aspects. 1. There's a log_group directive in /etc/audit/auditd.conf, and I've verified that it's enough to make audit.log group-readable, with permissions 0640. On this side, the question then becomes: what would be the problem with setting `log_group = adm' by default? 2. For the parent directory (/var/log/audit), it's currently shipped as part of the package, so here we could simply ship it with 0710 permissions, owned by root:adm. I guess that #2 is no big issue: giving members of the adm group x permission on that directory should not be a problem in itself, would it? Addressing this only would not solve 100% of the problem I've reported initially, but at least it would allow one to fix it by simply modifying a conffile, as opposed to having to use dpkg-statoverride, which arguably requires a bit more expertise. Thoughts, anyone? The problem might be IIRC that the auditd daemon itself check the mode/owner/group of the files on disk before starting. I do not remembrer all the details though. We need the check that by changing this we are not loosing some kind of US gouvernement certifications if we really care about this (auditd daemon follows some gouvernement recommendations/certification). Maybe you could ask on the linux-au...@redhat.com mailing list? Cheers, Laurent Bigonville
Bug#795827: apt: edsp interface: please add version of package to be installed when supplied on the command line
Package: apt Version: 1.0.9.10 Severity: normal Hi, when I ask apt to install a package with a precise version, then the edsp sent to apt-cudf does not contain the version specification: apt-get -s --solver dump install mccs=1:1.1-3+b1 % head -5 /tmp/dump.edsp Request: EDSP 0.5 Architecture: amd64 Architectures: amd64 Install: mccs:amd64 Please add the requested version to the Install line. In the example, it should be: Install: mccs:amd64 (= 1:1.1-3+b1) Thanks -Ralf. -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-headers-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^gnumach-image-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-modules-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-kernel-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-4\.1\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-tools-4\.1\.0-1-amd64$; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Update ; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: /usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service /usr/bin/test -S /var/run/dbus/system_bus_socket /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update /dev/null; /bin/echo /dev/null; APT::Architectures ; APT::Architectures:: amd64; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma; APT::Compressor::lzma::Binary xz; APT::Compressor::lzma::Cost 5; APT::Compressor::lzma::CompressArg ; APT::Compressor::lzma::CompressArg:: --format=lzma; APT::Compressor::lzma::CompressArg::
Bug#733039: [bug #45777] possibility to enable NORMAL:%COMPAT GNUTLS priority strings
URL: http://savannah.gnu.org/bugs/?45777 Summary: possibility to enable NORMAL:%COMPAT GNUTLS priority strings Project: GNU Wget Submitted by: nok Submitted on: Mo 17 Aug 2015 11:13:12 CEST Category: Feature Request Severity: 3 - Normal Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Release: None Operating System: None Reproducibility: None Fixed Release: None Planned Release: None Regression: None Work Required: None Patch Included: None ___ Details: Hello, a user requested some years ago the possibility to set the gnutls priority strings http://gnutls.org/manual/html_node/Priority-Strings.html in wget. Tim extended the option --secure-protocol= https://lists.gnu.org/archive/html/bug-wget/2013-08/msg00075.html but it is not possible to set all described strings. We could later write a wrapper to map GnuTLS priority syntax to OpenSSL API calls. https://lists.gnu.org/archive/html/bug-wget/2013-08/msg00053.html Please add the possibilty to set the GNUTLS priority strings. https://bugs.debian.org/733039 Thanks you. Regards Noël ___ Reply to this item at: http://savannah.gnu.org/bugs/?45777 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/
Bug#795826: epydoc: Please hide memory references in the output
Source: epydoc Version: 3.0.1+dfsg-11 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi! While working on the “reproducible builds” effort [1], we have noticed that epydoc uses repr() on objects that don't always override the default one. As a consequence, the documentation shows memory references on the build system, eg. module.Foo instance at 0x7f3aff4299e0 The attached patch detects objects with no overriding of __repr__ and provides a fallback that does not show the reference. Once applied, more packages using epydoc will be buildable reproducibly in our current experimental framework. [1]: https://wiki.debian.org/ReproducibleBuilds Regards, Val diff -u -r epydoc-3.0.1+dfsg.old/epydoc/markup/pyval_repr.py epydoc-3.0.1+dfsg/epydoc/markup/pyval_repr.py --- epydoc-3.0.1+dfsg.old/epydoc/markup/pyval_repr.py 2015-08-16 18:57:38.152484836 + +++ epydoc-3.0.1+dfsg/epydoc/markup/pyval_repr.py 2015-08-16 21:11:09.520790145 + @@ -207,9 +207,17 @@ self._colorize_re(pyval, state) else: try: -pyval_repr = repr(pyval) -if not isinstance(pyval_repr, (str, unicode)): -pyval_repr = unicode(pyval_repr) +pyval_class = pyval.__class__ +if hasattr(pyval, '__repr__') and \ +pyval_class.__repr__ is not object.__repr__: +pyval_repr = repr(pyval) +if not isinstance(pyval_repr, (str, unicode)): +pyval_repr = unicode(pyval_repr) +else: +# pyval has a default repr(), which would leak +# a reference to the object +pyval_repr = '%s.%s object' % ( +pyval_class.__module__, pyval_class.__name__) pyval_repr_ok = True except KeyboardInterrupt: raise signature.asc Description: OpenPGP digital signature
Bug#791250: Do you need any help for pugixml
Quoting Andreas Tille (2015-08-17 10:23:19) On Mon, Aug 17, 2015 at 12:30:23PM +0530, Vasudev Kamath wrote: DEB_MAINTAINER_MODE=1 fakeroot debian/rules debian/control Very halpful - so I added this to README.source and uploaded a fixed package. Your change to README.source is not helpful in my opinion, so I have reverted that. You uploaded to unstable, but I believe this should go to experimental first. I am now building a non-NMU targeted experimental. Thanks for your help, Andreas - but please cancel the NMU. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#793055: libpipeline: mark check build-dependency with nocheck profile
On Tue, Jul 21, 2015 at 07:12:40AM +0200, Helmut Grohne wrote: On Mon, Jul 20, 2015 at 11:36:05PM +0100, Colin Watson wrote: I approve of this patch in general. I want to hold off a little before applying it, though, because I know that some infrastructure is still a bit ... recent where it comes to build profiles. (In particular, since my day job is as a Launchpad developer, I'd rather like to get Launchpad to support this first so that I don't make problems for myself at work.) But I think we can probably do this fairly soon. I talked to William Grant again and made him aware of the progress on the Debian side. It seems like much of the infrastructure is still running precise while the tool support landed mostly in vivid. William said that he'd look into this. Since there are backport patches implementing just the syntax and Ubuntu has experience with backporting stuff in apt and dpkg, I expect little problems. Right, William and I are colleagues. I ended up fixing most of this a week or two ago, so things should be unblocked now. I'll apply your latest patch in my next upload. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#795831: initramfs-tools: ensure error output from switch_root/run-init are on the console
Package: initramfs-tools
Version: 0.120
Severity: normal
When switching into the real root partition using switch_root/run-init
we do not specifically direct the error output, as a result it may not
end up visible to the user. Send it with the primary output to the
console.
-apw
From 223559b93fc219987fd8cbe50efdd9e73f220f81 Mon Sep 17 00:00:00 2001
From: Andy Whitcroft a...@canonical.com
Date: Mon, 25 Jun 2012 11:35:30 +0100
Subject: [PATCH] Add 21 to the run-init line.
Signed-off-by: Andy Whitcroft a...@ubuntu.com
---
init | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/init b/init
index abf7f25..7a8dfce 100755
--- a/init
+++ b/init
@@ -332,9 +332,9 @@ mount -n -o move /proc ${rootmnt}/proc
# Chain to real filesystem
if [ -z $drop_caps ] command -v switch_root /dev/null 21; then
- exec switch_root ${rootmnt} ${init} $@ ${rootmnt}/dev/console ${rootmnt}/dev/console
+ exec switch_root ${rootmnt} ${init} $@ ${rootmnt}/dev/console ${rootmnt}/dev/console 21
elif command -v run-init /dev/null 21; then
- exec run-init ${drop_caps} ${rootmnt} ${init} $@ ${rootmnt}/dev/console ${rootmnt}/dev/console
+ exec run-init ${drop_caps} ${rootmnt} ${init} $@ ${rootmnt}/dev/console ${rootmnt}/dev/console 21
fi
echo Something went badly wrong in the initramfs.
panic Please file a bug on initramfs-tools.
--
2.5.0
Bug#795833: initramfs-tools: add mountroot failure support to allow meaningful messages and recovery attempts
Package: initramfs-tools
Version: 0.120
Severity: normal
Allow hooks to supply specific root mount failure handlers. These can
both report more specific failure reasons, and in some cases may even be
able to attempt recovery. This is useful for more complex scenarios
such as LVM and mdadm setups.
We use this in Ubuntu to allow augmented lvm2 and mdadm hooks to recover
failed raids and the like.
NOTE: that the splash handling here may well be Ubuntu specific.
-apw
From 2f96b329734edeb03d769da83cce1dc06e6c81bb Mon Sep 17 00:00:00 2001
From: Andy Whitcroft a...@canonical.com
Date: Mon, 25 Jun 2012 12:13:07 +0100
Subject: [PATCH] Add mountroot failure support, to allow meaningful messages
when no root device can be found.
Signed-off-by: Andy Whitcroft a...@ubuntu.com
---
docs/example_script | 13 +
initramfs-tools.8 | 14 ++
scripts/functions | 36
3 files changed, 63 insertions(+)
diff --git a/docs/example_script b/docs/example_script
index 5e9153b..93d1135 100644
--- a/docs/example_script
+++ b/docs/example_script
@@ -26,10 +26,23 @@ prereqs)
prereqs
exit 0
;;
+mountfail) # Called if the script has previously registered a mountroot
+ # failure.
+ # Check status, and display any relevant information about the
+ # failure if there is a problem, then exit with a status of 1.
+ ;;
esac
# Do the work here.
+# If this script is to be placed in either init-premount, or local-top,
+# register a mountroot failure hook, so that further information can be given
+# to the user, in the event that the root device cannot be found.
+
+. /scripts/functions
+
+add_mountroot_fail_hook
+
echo Got here!
exit 0
diff --git a/initramfs-tools.8 b/initramfs-tools.8
index ea8c098..4f873b1 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -387,6 +387,20 @@ user to investigate the situation.
.PP
.B Example:
panic Frobnication failed
+.fi
+.RE
+.RE
+
+.TP
+\fB\fI
+add_mountroot_fail_hook
+Registers the script as able to provide possible further information, in the
+event that the root device cannot be found. See the example script in the
+initramfs-tools examples directory for more information.
+.RS
+.PP
+.B Example:
+add_mountroot_fail_hook
.RE
.SS Subdirectories
diff --git a/scripts/functions b/scripts/functions
index 073fcb3..74083ed 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -31,6 +31,42 @@ log_end_msg()
_log_msg done.\n
}
+# Add failure hook
+add_mountroot_fail_hook()
+{
+ mkdir -p /tmp/mountroot-fail-hooks.d
+ ln -s $0 /tmp/mountroot-fail-hooks.d/$1
+}
+
+# Run failure hooks.
+# When a failure hook exits 1, it has not done anything to correct the
+# system. Exiting 0 means that something has been attempted to resolve
+# the lack of a root filesystem.
+# Hooks are run in lexigraphical order, and are responsible for removing
+# themselves if they should not re-run in a later cycle. When one exits
+# 0, the stack is stopped, so the caller can return to the main rootfs
+# wait loop.
+try_failure_hooks()
+{
+ local hook
+
+ # Disable usplash so text from hooks can be seen
+ if [ -x /sbin/usplash_write ]; then
+ /sbin/usplash_write QUIT
+ fi
+ chvt 1
+ if [ -x /bin/plymouth ] plymouth --ping; then
+ /bin/plymouth hide-splash /dev/null 21
+ fi
+
+ for hook in /tmp/mountroot-fail-hooks.d/*; do
+ if [ -x ${hook} ] ${hook} mountfail; then
+ return 0
+ fi
+ done
+ return 1
+}
+
panic()
{
if command -v chvt /dev/null 21; then
--
2.5.0
Bug#788250: digikam: plasma5
Package: digikam Version: 4:4.4.0-1.1+b2 Followup-For: Bug #788250 Dear Maintainer, I am running it on plasma 5. Confirm pto2mk is missing. Is there an alternative way to get it. Luc - System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages digikam depends on: ii digikam-data 4:4.4.0-1.1 ii digikam-private-libs 4:4.4.0-1.1+b2 ii kde-runtime 4:4.14.2-2 ii libc6 2.19-19 ii libgcc1 1:5.1.1-14 ii libgphoto2-6 2.5.8-1 ii libgphoto2-port12 2.5.8-1 ii libkdcraw23 4:15.04.3-1 ii libkdecore5 4:4.14.2-5 ii libkdeui5 4:4.14.2-5 ii libkexiv2-11 4:4.14.2-1 ii libkhtml5 4:4.14.2-5 ii libkio5 4:4.14.2-5 ii libkipi11 4:4.13.3-1 ii libknotifyconfig4 4:4.14.2-5 ii libkparts44:4.14.2-5 ii libopencv-core2.4 2.4.9.1+dfsg-1.1+b1 ii libopencv-imgproc2.4 2.4.9.1+dfsg-1.1+b1 ii libphonon44:4.8.3-1 ii libqt4-dbus 4:4.8.7+dfsg-1 ii libqt4-sql4:4.8.7+dfsg-1 ii libqt4-sql-sqlite 4:4.8.7+dfsg-1 ii libqt4-xml4:4.8.7+dfsg-1 ii libqtcore44:4.8.7+dfsg-1 ii libqtgui4 4:4.8.7+dfsg-1 ii libsolid4 4:4.14.2-5 ii libstdc++65.1.1-14 ii libthreadweaver4 4:4.14.2-5 ii perl 5.20.2-6 ii phonon4:4.8.3-1 Versions of packages digikam recommends: ii iceweasel [www-browser] 38.2.0esr-1~stretch ii kipi-plugins 4:4.4.0-1.1+b2 ii konqueror [www-browser] 4:15.04.3-1 ii mplayerthumbs4:4.14.0-1 ii w3m [www-browser]0.5.3-24 Versions of packages digikam suggests: pn digikam-doc none ii systemsettings 4:5.3.2-2 -- no debconf information
Bug#795344: [Debian-med-packaging] Bug#795344: libmems-1.6-1: not properly linked to its dependencies
all changes pushed. The new boost.m4 solved my problem, but adding the libraries in the link dependencies was still needed. The package builds and the boost libraries are also linked. BTW it was _LIBS not _LIB, so no AC_SUBST needed. However, building a package I got another error devlibs error: There is no package matching [libGenome-1.3-0-dev] and noone provides it, please report bug to d-shlibs maintainer devlibs error: There is no package matching [libMUSCLE-3.7-1-dev] and noone provides it, please report bug to d-shlibs maintainer never seen this one before. t seems this d_shlibs expects the soversion in the dev-package name. I left another patch in the git history that deals with a conflict between boost::make_tuple and std::make_tuple of c++11. I would have left it in the build, but somehow I didn't get the patch to have the right line endings. Since C++11 is not enabled by default, this is currently not a problem. Best, Gert
Bug#795840: udisks2: No man manpage (an no other documentation)
Package: udisks2 Version: 2.1.3-5 Severity: important Dear Maintainer, * What led up to the situation? I want to configure udisks2 so that it will work, so I needed a man page. But there is no man page. I understand that this, also, violates Debian packaging rules There is an effectively empty readme, and a man page for umount.udisks2 which is a helper for umount (to clean out udisks2 files) * What exactly did you do (or not do) that was effective (or ineffective)? Nothing * What was the outcome of this action? I cannot use udisks2 * What outcome did you expect instead? That there would be a man page, and that I would be able to use udisks2 -- System Information: Debian Release: stretch/sid Architecture: i386 (i686) Kernel: Linux 4.0.0-2-rt-686-pae (SMP w/1 CPU core; PREEMPT) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#795458: dahdi-linux: have a debian/README.source
On Sun, Aug 16, 2015 at 10:55:44PM +0300, Tzafrir Cohen wrote: On Fri, Aug 14, 2015 at 09:50:53AM +0200, Geert Stappers wrote: Please provide a debian/README.source that tells how to build the dahdi-linux package Quoting the top of README.Debian from dahdi-linux / dahdi-source: Building kernel modules --- First, install dahdi-source package if you have not yet done so. You can build and install the modules package (as root) with the following command: # module-assistant a-i dahdi Benefits of knowning to build dahdi packages from Debian version control system: * Avoiding installing build dependencies on computer(s) with the DAHDI hardware * Building on faster computer * Having the workflow documented, making Aloith pkg-voip team stronger Cheers Geert Stappers
Bug#795841: protobuf: Please package version 3.0.0a3 of protobuf and add python3-protobuf
Source: protobuf Severity: wishlist Dear Maintainer, Since protobuf = 3.0.0 is a dependency for one of the packages I want to package, I would like to see it added. Additionally, since new packages should have a Python 3 package, there is a need for python3-protobuf as well. (if I am going to be able to upload the package I'm working on) Regards, Ruben -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armel Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: Digital signature
Bug#795846: mutt-patched: Wrong handling of maildir folders with NEW messages
Package: mutt-patched Version: 1.5.23-3.1 Severity: normal I noticed a problem with how mutt-patched deals with folders containing new email messages. The behavior is somewhat different from the correct one of unpatched mutt. My muttrc configuration file contains the following: set mail_check_recent unset mark_old This is how regular mutt behaves: when I open mutt for the first time I see all new messages in all folders. Once I visit a folder containing new messages and I don't read them, but leave them still flagged as New, the folder does not appear in the buffy-list anymore, nor gets accessed with the command next-unread-mailbox. Let's say I have these folders in this order, which are all local maildirs: folder-A folder-B folder-C folder-D Suppose folder-C has new email, I open it but don't read the new messages, they stay flagged New, but get otherwise ignored. The first difference here is that unpatched mutt does not show folder-C in the buffy-list anymore, while mutt-patched does. Still I don't reach folder-C with the function next-unread-mailbox. Now if folder-A or folder-B get new messages then all stays the same: next-unread-mailbox switches to them only, folder-C gets correctly ignored. Instead, and here is the error, if folder-D (or any other folder that in the mailboxes list comes after folder-C) gets new messages then next-unread-mailbox visits folder-C before going to folder-D, even if folder-C does not have any new recent messages. I think the right behavior is the one of regular unpatched mutt. When you have mail_check_recent set mutt should only notify you about new mail that has been received since the last time you opened the mailbox. In any case visiting or not visiting unread mailboxes should not depend on the order of other mailboxes with new messages. Thanks for your work on this package. Best regards. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mutt-patched depends on: ii libassuan0 2.2.1-1 ii libc6 2.19-19 ii libcomerr2 1.42.13-1 ii libgnutls-deb0-28 3.3.17-1 ii libgpg-error0 1.19-2 ii libgpgme11 1.5.5-3 ii libgssapi-krb5-2 1.13.2+dfsg-2 ii libidn11 1.32-1 ii libk5crypto3 1.13.2+dfsg-2 ii libkrb5-3 1.13.2+dfsg-2 ii libncursesw5 5.9+20150516-2 ii libsasl2-2 2.1.26.dfsg1-13 ii libtinfo5 5.9+20150516-2 ii libtokyocabinet9 1.4.48-3 ii mutt 1.5.23-3.1 mutt-patched recommends no packages. mutt-patched suggests no packages. -- no debconf information
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
Don == Don Armstrong d...@debian.org writes: Don On Sun, 16 Aug 2015, Didier 'OdyX' Raboud wrote: What about just adding Keith's proposal to the ballot, and let the Condorcet magic act? Don This has sort of been my plan; I just have not had enough spare Don cycles in the past few weeks (grant deadlines) to have the time Don necessary to work through Keith's plan and shift it into a Don specific patch to policy. If you add Keith's proposal as well as an explanation of our technical objection to what debian-policy came up with it, I might even vote for it. If you were to add a recommendation to ballot option B that under 6.1.5 we ask debian-policy to consider Keith's proposal, I'd prefer that to the current text. If you simply add a ballot option for Keith's proposal without text in the decision explaining our technical objection to option A/B, I'll disagree with it as strongly as I can. (Read, I'd probably feel strongly enough to fight the issue in other fora if I was in the rough here). While we're not overturning anything in the sense of an override here, I think we owe an explanation for our actions, and I feel really strongly about that.
Bug#781812: pending
Control: affects -1 - src:minidlna Just to clarify things. MKV support has been fixed upstream in ffmpeg: https://trac.ffmpeg.org/ticket/4423#comment:8 Now that switch to ffmpeg is ongoing: https://wiki.debian.org/Debate/libav-provider/ffmpeg this should be automatically fixed after proper binNMU in minidlna. 2cts
Bug#793171: RFS: git-lfs/0.5.2-1 [ITP]
Hi Stephen, Here are some remaining problems I'd like to see solved before sponsoring the package. (1) debian/control: --- - Concerning git (= 1.8.0): The version in jessie-backports is 2.1, so anyway this condition will be verified in case of a backport to stable. This condition would also be verified in case of a backport to oldstable since the version in wheezy-backports is 1.9.1. - Concerning golang-go (= 1.3.0): The version in jessie is 1.3.3, so anyway this condition will be verified in case of a backport to stable. This condition would also be verified in case of a backport to oldstable since the version in wheezy-backports is 1.3.3. FYI, the Release Team doesn't always accepts backports to stable. However, if the backport of your package is accepted, it will go to the jessie-backports archive[0]. (2) debian/changelog: - - Why have you increased the debian revision number ? This package is the first debian release, so the complete package version number should be 0.5.4-1. - Why have you made three changelog entries ? This package haven't been uploaded to the Debian archive so, only one entry is allowed. - Usually, the changelog entry for an initial release looks like: * Initial release. (Closes: ITPBUG) (3) debian/copyright: - - Please, specify an e-mail adress after your name in the Copyright field of d/copyright, like so: Files: debian/* Copyright: 2015 Stephen Gelman ssg...@gmail.com License: Expat Thanks ! Regards, Hugo [0] http://backports.debian.org/Contribute/ -- Hugo Lefeuvre (hugo6390)|www.hugo6390.org 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E signature.asc Description: Digital signature
Bug#791313: xmlrpc-c: diff for NMU version 1.33.14-0.3
retitle 791313 transition: xmlrpc-c (g++-5) reassign 791313 release.debian.org severity 791313 normal user release.debian@packages.debian.org usertags 791313 + transition forwarded 791313 https://release.debian.org/transitions/html/auto-xmlrpc-c.html thanks On Tue, 11 Aug 2015 at 22:40:48 +0100, Jonathan Wiltshire wrote: I've prepared an NMU for xmlrpc-c (versioned as 1.33.14-0.3) This is now in unstable and has built everywhere. S
Bug#795825: asterisk: FTBFS on amd64 arm64 ppc64el: /usr/bin/ld: cannot find -lSDL2 (and others)
reassign 795825 libpjproject-dev thanks On Mon, Aug 17, 2015 at 10:08:18AM +0100, Simon McVittie wrote: Source: asterisk Version: 1:13.1.0~dfsg-1.1 Severity: serious Justification: fails to build from source (but built successfully in the past) When asterisk was binNMU'd for the libvpb1 transition, it failed to build from source on amd64, arm64 and ppc64el: https://buildd.debian.org/status/package.php?p=asterisk /«PKGBUILDDIR»/build_tools/make_linker_version_script chan_pjsip /«PKGBUILDDIR» x86_64-linux-gnu-gcc -o chan_pjsip.so -pthread -fPIE -pie -Wl,-z,relro -Wl,-z,now-shared -Wl,--version-script,chan_pjsip.exports,--warn-common chan_pjsip.o pjsip/dialplan_functions.o -lpjsua2 -lstdc++ -lpjsua -lpjsip-ua -lpjsip-simple -lpjsip -lpjmedia-codec -lpjmedia -lpjmedia-videodev -lpjmedia-audiodev -lpjmedia -lpjnath -lpjlib-util -lsrtp -lpj -lm -lrt -lpthread -lSDL2 -lavformat-ffmpeg -lavcodec-ffmpeg -lswscale-ffmpeg -lavutil-ffmpeg -lv4l2 -lopencore-amrnb -lopencore-amrwb /usr/bin/ld: cannot find -lSDL2 /usr/bin/ld: cannot find -lavformat-ffmpeg /usr/bin/ld: cannot find -lavcodec-ffmpeg /usr/bin/ld: cannot find -lswscale-ffmpeg /usr/bin/ld: cannot find -lavutil-ffmpeg /usr/bin/ld: cannot find -lv4l2 /usr/bin/ld: cannot find -lopencore-amrnb /usr/bin/ld: cannot find -lopencore-amrwb collect2: error: ld returned 1 exit status I don't know what's different about those three architectures. They're all 64-bit, but so is s390x, which built successfully. Those dependencies should be set by libpjproject-dev. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#795838: RM: dvswitch -- ROM; FTBFS, unlikely to be fixed
Package: ftp.debian.org Severity: normal dvswitch has been FTBFS in unstable for over 2 years. While that bug is fixed in experimental, it fails at run-time with current libav and I think it also FTBFS now. Neither I nor Wouter have time to work on it. Ben.
Bug#795814: FTBFS: boost/math/tools/test.hpp: No such file or directory
Control: tags -1 + pending 2015-08-17 8:34 GMT+01:00 Simon McVittie s...@debian.org: Source: k3d Version: 0.8.0.3-7 Severity: serious Justification: fails to build from source (but built successfully in the past) When rebuilt for libsigc++-2.0-0v5, k3d fails to build from source https://buildd.debian.org/status/package.php?p=k3d: In file included from /«PKGBUILDDIR»/k3dsdk/inode.h:28:0, from /«PKGBUILDDIR»/k3dsdk/data.h:28, from /«PKGBUILDDIR»/k3dsdk/plugins_detail.h:27, from /«PKGBUILDDIR»/k3dsdk/plugin.h:27, from /«PKGBUILDDIR»/k3dsdk/application_detail.cpp:25: /«PKGBUILDDIR»/k3dsdk/difference.h:34:37: fatal error: boost/math/tools/test.hpp: No such file or directory I suspect this is a result of the update from Boost 1.55 to Boost 1.58. Thanks for taking a look. Yes, it is a problem due the changes in boost, and I have a fix for this but it didn't compile in a clean pbuilder when I tried ~5 days ago, because of dependencies not being ready: /tmp/buildd/k3d-0.8.0.3/modules/imagemagick_io/bitmap_importer.cpp:62: undefined reference to `Magick::Image::read(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status Today it cannot even start to compile because of conflics of deps to install: The following packages have unmet dependencies: libopenexr6v5 : Conflicts: libopenexr6 but 1.6.1-8 is to be installed. libilmbase6v5 : Conflicts: libilmbase6 but 1.0.1-6.1 is to be installed. libcairomm-1.0-1v5 : Conflicts: libcairomm-1.0-1 but 1.10.0-1.1+b1 is to be installed. I'm keeping an eye on this, and I will fix it as soon as it is possible to do it. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
Bug#795641: use function currying
I realized in the middle of the night that I can make this a bit more elegant by using currying, here is the patch with the minor change. 0001-fix-common-lic.-false-pos.-in-new-style-copyright.patch Description: Binary data
Bug#795842: dbtoepub: epubcheck report lots of errors from epub generated by dbtoepub
Package: dbtoepub Version: 0+svn9150-2 When using dbtoepub to generate a epub version of the Free Culture book, the output from epubcheck report many problems with the resulting file. The docbook source for the book can be found via URL: https://github.com/petterreinholdtsen/free-culture-lessig/ Here are some examples from the epubcheck output: Validating against EPUB version 2.0 - custom validation Validating using EPUB version 2.0 rules. ERROR(RSC-005): freeculture.epub/OEBPS/pt01.html(13,43): Error while parsing file 'element a not allowed here; expected the element end-tag or element address, blockquote, del, div, dl, h1, h2, h3, h4, h5, h6, hr, ins, noscript, ns:svg, ol, p, pre, script, table or ul (with xmlns:ns=http://www.w3.org/2000/svg;)'. ERROR(RSC-005): freeculture.epub/OEBPS/ch03.html(325,43): Error while parsing file 'element a not allowed here; expected the element end-tag or element address, blockquote, del, div, dl, h1, h2, h3, h4, h5, h6, hr, ins, noscript, ns:svg, ol, p, pre, script, table or ul (with xmlns:ns=http://www.w3.org/2000/svg;)'. [...] ERROR(RSC-005): freeculture.epub/OEBPS/images/1331.svg(19,32): Error while parsing file 'attribute inkscape:version not allowed here; expected attribute alignment-baseline, baseProfile, baseline-shift, class, clip, clip-path, clip-rule, color, color-interpolation, color-interpolation-filters, color-profile, color-rendering, contentScriptType, contentStyleType, cursor, direction, display, dominant-baseline, enable-background, externalResourcesRequired, fill, fill-opacity, fill-rule, filter, flood-color, flood-opacity, font-family, font-size, font-size-adjust, font-stretch, font-style, font-variant, font-weight, glyph-orientation-horizontal, glyph-orientation-vertical, image-rendering, kerning, letter-spacing, lighting-color, marker-end, marker-mid, marker-start, mask, onabort, onactivate, onclick, onerror, onfocusin, onfocusout, onload, onmousedown, onmousemove, onmouseout, onmouseover, onmouseup, onresize, onscroll, onunload, onzoom, opacity, overflow, pointer-events, preserveAspectRatio, requiredExtensions, requiredFeatures, shape-rendering, stop-color, stop-opacity, stroke, stroke-dasharray, stroke-dashoffset, stroke-linecap, stroke-linejoin, stroke-miterlimit, stroke-opacity, stroke-width, style, systemLanguage, text-anchor, text-decoration, text-rendering, unicode-bidi, viewBox, visibility, word-spacing, writing-mode, x, xml:base, xml:lang, xml:space, y or zoomAndPan'. [...] ERROR(RSC-012): freeculture.epub/OEBPS/ix01.html(3,6643): Fragment identifier is not defined. [...] Why do dbtoepub and epubcheck not agree on what a epub file should look like? I tested using dbtoepub version 0+svn9904-1 and this too causes epubcheck to report lots of errors. -- Happy hacking Petter Reinholdtsen
Bug#787698: supertux: FTBFS on big-endian archs
Control: tags -1 + patch Am Montag, den 08.06.2015, 09:07 +0200 schrieb Fabian Greffrath: *((char *)buffer) = tmp; Correction: You'll also need to dereference the tmp pointer, i.e.: --- supertux-0.3.5a.orig/src/audio/wav_sound_file.cpp +++ supertux-0.3.5a/src/audio/wav_sound_file.cpp @@ -159,7 +159,7 @@ WavSoundFile::read(void* buffer, size_t tmp[2*i+1] = c; } - *buffer = tmp; + *(char *)buffer = *tmp; #endif return readsize; Cheers, Fabian signature.asc Description: This is a digitally signed message part
Bug#787419: Serious bug
On 17-08-2015 10:28, Ruben Undheim wrote: Are there any others that may cause data-loss for users, that are fixed in sid and have patches available like #787419 and #748469? There is also #788002
Bug#795813: kodi: FTBFS with g++-5: multiple definitions of argument-parsing stuff
Hi Simon,
2015-08-17 9:31 GMT+02:00 Simon McVittie s...@debian.org:
Source: kodi
Version: 14.2+dfsg1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: patch
kodi fails to build from source when binNMU'd for the libstdc++ transitions:
https://buildd.debian.org/status/package.php?p=kodi
There are lots of errors like this:
../../lib/libmisc.a(argp-parse.o): In function `argp_usage':
/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:568:
multiple definition of `argp_usage'
../../lib/libmisc.a(argp-help.o):/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:568:
first defined here
../../lib/libmisc.a(argp-parse.o): In function `_option_is_short':
/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:574:
multiple definition of `_option_is_short'
../../lib/libmisc.a(argp-help.o):/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:574:
first defined here
I believe this is because g++-5 changed the default interpretation of
inline T foo() { ... } from historical GNU behaviour to Standard C++.
https://gcc.gnu.org/gcc-5/changes.html
In Ubuntu, Matthias Klose patched kodi to use historical GNU inline
semantics http://patches.ubuntu.com/k/kodi/kodi_14.2+dfsg1-2ubuntu1.patch:
diff -pruN 14.2+dfsg1-2/debian/rules 14.2+dfsg1-2ubuntu1/debian/rules
--- 14.2+dfsg1-2/debian/rules 2015-06-04 08:33:30.0 +
+++ 14.2+dfsg1-2ubuntu1/debian/rules2015-08-10 19:42:58.0 +
@@ -37,6 +37,7 @@ DEB_CFLAGS ?= $(shell dpkg-buildflags -
DEB_CXXFLAGS ?= $(shell dpkg-buildflags --get CPPFLAGS) \
$(filter-out -g -O2, $(shell dpkg-buildflags --get CXXFLAGS))
DEB_LDFLAGS ?= $(shell dpkg-buildflags --get LDFLAGS) $(shell pkg-config
--libs ftgl)
+DEB_CFLAGS += -fgnu89-inline
ENV_OPTIONS = CFLAGS=$(DEB_CFLAGS) CXXFLAGS=$(DEB_CXXFLAGS) \
LDFLAGS=$(DEB_LDFLAGS)
This is probably an appropriate change for kodi in Debian too.
Thank you for the bug report and also for the patch.
I'm packaging Kodi 15 right now and it FTBFS-s multiple ways and some
of them are due to the embedded outdated gnulib files.
Instead of passing the cflag I plan removing the gnulib usage in the
next upload but for this particular problem the proposed patch would
be a solution indeed.
Cheers,
Balint
Bug#501289: still relevant?
Hello, can you try to reproduce the bug with csync2 2.0+73d3293-2 and fresh certificates? If nobody can, I am going to close the report. Best regards, Alexander Sosna
Bug#795832: initramfs-tools: allow the specificication of multiple break points using a comma delimiter
Package: initramfs-tools
Version: 0.120
Severity: normal
When debugging an initramfs you may wish to stop at more than one break
point in the same run. Allow specification of multiple break points on
the command line using break=a,b syntax.
-apw
From 037406f31a564ace91389d952f71202ab7745532 Mon Sep 17 00:00:00 2001
From: Andy Whitcroft a...@canonical.com
Date: Mon, 25 Jun 2012 11:17:57 +0100
Subject: [PATCH] Allow specifying multiple break points using a comma
delimiter.
Signed-off-by: Andy Whitcroft a...@ubuntu.com
---
scripts/functions | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/functions b/scripts/functions
index 8c1bb1f..073fcb3 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -58,7 +58,7 @@ panic()
maybe_break()
{
- if [ ${break:-} = $1 ]; then
+ if echo ${break:-} | egrep -q (,|^)$1(,|$); then
panic Spawning shell within the initramfs
fi
}
--
2.5.0
Bug#795834: erlang: please make the output of erlc reproducible
Source: erlang
Version: 1:18.0-dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi,
While working on the reproducible builds effort [1], we have noticed
that erlc generates .beam files that include the current timestamp:
$ echo '-module(test).' test.erl
$ while sleep 1; do erlc test.erl sha1sum test.beam; done
c82bb744a4665e34bb5cdc320bcc584ed25740b4 test.beam
7214b49ebc395c5c14df6fc59ac124fa0098fb5e test.beam
7353ca62788e505ba5565d4d90daceda1883cc84 test.beam
^C
The attached patch modifies erlc to optionally use the
SOURCE_DATE_EPOCH environment variable (which we set to the latest entry
from debian/changelog). If the variable is not set or is invalid we
fall back to the original behaviour of using the current UNIX timestamp:
$ export SOURCE_DATE_EPOCH=1234
$ while sleep 1; do erlc test.erl sha1sum test.beam; done
23da6b9ffae248392455dfa629ab5f3a12846fd0 test.beam
23da6b9ffae248392455dfa629ab5f3a12846fd0 test.beam
23da6b9ffae248392455dfa629ab5f3a12846fd0 test.beam
^C
$ export SOURCE_DATE_EPOCH=1234_WHOOPS_BROKEN
$ while sleep 1; do erlc test.erl sha1sum test.beam; done
58f9aec98a3ae9827743ce8ff0785337e4369cf7 test.beam
11f20e425e546b184fc545961c7d791a218d4df9 test.beam
63577de11becbcd048a6cd5954e9294b7a3bdaf7 test.beam
^C
The patch is based on an original version by Chris West (Faux).
Once applied, erlang packages that ship .beam files can be built
reproducibly in our reproducible toolchain.
[1]: https://wiki.debian.org/ReproducibleBuilds
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/lib/compiler/src/beam_asm.erl b/lib/compiler/src/beam_asm.erl
index a3201b0..bbcac90 100644
--- a/lib/compiler/src/beam_asm.erl
+++ b/lib/compiler/src/beam_asm.erl
@@ -226,7 +226,11 @@ flatten_imports(Imps) -
build_attributes(Opts, SourceFile, Attr, MD5) -
Misc = case member(slim, Opts) of
false -
- {{Y,Mo,D},{H,Mi,S}} = erlang:universaltime(),
+ {{Y,Mo,D},{H,Mi,S}} = case
string:to_integer(os:getenv(SOURCE_DATE_EPOCH)) of
+ {N,[]} -calendar:gregorian_seconds_to_datetime(N +
+
calendar:datetime_to_gregorian_seconds({{1970,1,1},{0,0,0}}));
+ {_,_} - erlang:universaltime()
+ end,
[{time,{Y,Mo,D,H,Mi,S}},{source,SourceFile}];
true - []
end,
Bug#794768: kde-window-manager: the scren freeze after a while and everything freeze
I just had the same problem and noticed that running the activitymanager would also freeze plasmashell. Then I removed .cache and removed all information about Activities in the various config files (in .local, .config, .kde -- I'm not sure which one is the current) now it seems to work again. the problem in my case occurred shortly after installing AndroidStudio, which at some point ran out of disk space. It might be the culprit... On Thu, 06 Aug 2015 15:02:08 +0200 merlin wrote: Package: kde-window-manager Version: 4:5.3.2-3 Severity: normal Dear Maintainer, *** after a while all the windows on screen freeze, you can move the cursor of the mouse but you can't select anything. You can open a new session by ctrl+alt+F2 and see that the cpu is not occupied generally 25% if a window of Firefox was freezen on the first session if you kill the process of firefox nothing change on the screen frozen. I search by google and i found an discussion on forum.kde.org name Plasmashell freezes after a while and then everything freeze of January 2015 who seems its near my problem i also read bug 341963 of bugs.kde.org who give an advice to remove ./cache with no success its continue to freeze -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages kde-window-manager depends on: ii kwin-x11 4:5.3.2-3 kde-window-manager recommends no packages. kde-window-manager suggests no packages. -- no debconf information
Bug#795837: initramfs-tools: calls dpkg with obsolete relation operator ''
Package: initramfs-tools
Version: 0.120
Severity: minor
It seems that with newer dpkg we get warnings about the use of obsolete
relation operator '' during builds of the initramfs. We are using the
attached patch for this in Ubuntu.
-apw
From e8454859aa8171c0b17c85ad2cca5cf6710fefa1 Mon Sep 17 00:00:00 2001
From: Andy Whitcroft a...@canonical.com
Date: Wed, 5 Aug 2015 15:27:08 +0100
Subject: [PATCH] update-initramfs: switch dpkg --compare-versions from to =
to avoid warnings from dpkg. (LP: #1480340)
Signed-off-by: Andy Whitcroft a...@ubuntu.com
---
update-initramfs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/update-initramfs b/update-initramfs
index ea301ba..5aa2186 100755
--- a/update-initramfs
+++ b/update-initramfs
@@ -237,7 +237,7 @@ get_sorted_versions()
fi
worklist=
for gsv_i in $version_list; do
- if dpkg --compare-versions ${gsv_x} '' ${gsv_i} 2/dev/null; then
+ if dpkg --compare-versions ${gsv_x} '=' ${gsv_i} 2/dev/null; then
worklist=${worklist} ${gsv_x} ${gsv_i}
gsv_x=
else
--
2.5.0
Bug#795836: qpsmtpd: Net::DNS::Header::nextid undefined at /usr/bin/qpsmtpd-forkserver
Package: qpsmtpd Version: 0.84-11 Severity: important Dear Maintainer, The versions of libnet-dns-perl ( 0.81-2 ) and qpsmtpd ( 0.84-11 ) seem to be incompatible. I see the following message in the qpsmtpd logs: method Net::DNS::Header::nextid undefined at /usr/bin/qpsmtpd-forkserver line 287. 42166 cleaning up after 8265 You can find the same bug reported e.g. here: http://permalink.gmane.org/gmane.mail.qpsmtpd/8398 http://bugs.contribs.org/show_bug.cgi?id=7561 With the latter containg a patch, which matches the upstream patch: https://github.com/smtpd/qpsmtpd/commit/6a0fa13ee1d559a10524f7b0e916945c5ee77488 The method: Net::DNS::Header::nextid has been removed from libnet-perl-dns . -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable'), (800, 'testing'), (700, 'unstable'), (600, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages qpsmtpd depends on: ii adduser 3.113+nmu3 ii debconf 1.5.56 ii libclamav-client-perl 0.11-2 ii libdigest-hmac-perl 1.03+dfsg-1 ii libio-socket-inet6-perl 2.72-1 ii libipc-shareable-perl 0.61-1 ii libmail-spf-perl2.9.0-3 ii libmailtools-perl 2.13-1 ii libnet-dns-perl 0.81-2 ii libsocket6-perl 0.25-1+b1 ii perl5.20.2-3+deb8u1 ii perl-modules [libnet-perl] 5.20.2-3+deb8u1 qpsmtpd recommends no packages. Versions of packages qpsmtpd suggests: pn clamav-daemon none pn spamassassin none pn tinycdbnone -- Configuration Files: /etc/qpsmtpd/logging changed [not included] /etc/qpsmtpd/plugins changed [not included] /etc/qpsmtpd/relayclients changed [not included] /etc/qpsmtpd/spool_dir changed [not included] -- debconf information: qpsmtpd/server_type: forkserver qpsmtpd/listen_interfaces: unset qpsmtpd/rcpthosts: unset qpsmtpd/queue_plugin: qpsmtpd/queue_none_confirm: qpsmtpd/queue_smtp_proxy_destination: localhost qpsmtpd/startup_enabled: false qpsmtpd/queue_maildir_destination: /var/spool/qpsmtpd/Maildir
Bug#795845: libjpeg-turbo: FTBFS on mips/mipsel - jsimd_mips_dspr2.S:2845: Error: float register should be even, was 1
Source: libjpeg-turbo
Version: 1:1.4.1-1
Severity: serious
Tags: patch upstream
Forwarded: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/11
Control: found -1 1:1.4.80-115-gfb907b2-1
X-Debbugs-CC: debian-m...@lists.debian.org, m...@glandium.org
User: debian-m...@lists.debian.org
Usertags: mips-patch
Hi,
libjpeg-turbo FTBFS with GCC 5 on mips/mipsel with the following error
(full build log attached):
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -D_FORTIFY_SOURCE=2 -g
-O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic
-ffloat-store -c jsimd_mips_dspr2.S -fPIC -DPIC -o .libs/jsimd_mips_dspr2.o
jsimd_mips_dspr2.S: Assembler messages:
jsimd_mips_dspr2.S:2845: Error: float register should be even, was 1
jsimd_mips_dspr2.S:2846: Error: float register should be even, was 5
jsimd_mips_dspr2.S:2849: Error: float register should be even, was 3
jsimd_mips_dspr2.S:2850: Error: float register should be even, was 7
jsimd_mips_dspr2.S:2853: Error: float register should be even, was 1
jsimd_mips_dspr2.S:2853: Error: float register should be even, was 1
jsimd_mips_dspr2.S:2853: Error: float register should be even, was 5
[...]
This has happened because in GCC 5 the MIPS ABI was altered very
slightly by enabling the -mfpxx GCC option by default. When this option
is enabled, the use of odd numbered floating point registers is not
allowed.
I'm afraid I did actually notice this issue with libjpeg-turbo some
months ago but filing a bug must have slipped my mind, so sorry about
that.
I've attached a patch (and forwarded it) which fixes this by changing
all the FP registers so that only even ones are used. Thankfully there
are enough FP registers in MIPS to do this quite easily.
Thanks,
James dpkg-buildpackage -rfakeroot -D -us -uc -B
dpkg-buildpackage: source package libjpeg-turbo
dpkg-buildpackage: source version 1:1.4.1-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Ondřej Surý ond...@debian.org
dpkg-source --before-build libjpeg-turbo-1.4.1
dpkg-buildpackage: host architecture mipsel
fakeroot debian/rules clean
dh clean --parallel --with autoreconf
dh_testdir
debian/rules override_dh_auto_clean
make[1]: Entering directory
'/media/sdcard/james/libjpeg-turbo-debian/libjpeg-turbo-1.4.1'
/usr/bin/make -C debian/extra clean
make[2]: Entering directory
'/media/sdcard/james/libjpeg-turbo-debian/libjpeg-turbo-1.4.1/debian/extra'
rm -f jpegexiforient
make[2]: Leaving directory
'/media/sdcard/james/libjpeg-turbo-debian/libjpeg-turbo-1.4.1/debian/extra'
if [ -e Makefile ]; then /usr/bin/make testclean; fi
dh_auto_clean
rm -f simd/jsimdcfg.inc
make[1]: Leaving directory
'/media/sdcard/james/libjpeg-turbo-debian/libjpeg-turbo-1.4.1'
dh_autoreconf_clean
dh_clean
debian/rules build-arch
dh build-arch --parallel --with autoreconf
dh_testdir -a -O--parallel
dh_autoreconf -a -O--parallel
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:18: installing './ar-lib'
configure.ac:16: installing './compile'
configure.ac:22: installing './config.guess'
configure.ac:22: installing './config.sub'
configure.ac:8: installing './install-sh'
configure.ac:8: installing './missing'
Makefile.am: installing './depcomp'
dh_auto_configure -a -O--parallel
./configure --build=mipsel-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=\${prefix}/lib/mipsel-linux-gnu
--libexecdir=\${prefix}/lib/mipsel-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
Bug#795841: protobuf: Please package version 3.0.0a3 of protobuf and add python3-protobuf
I am happy with it going into experimental (since it is an alpha release). :) Ruben signature.asc Description: Digital signature
Bug#795844: armel and armhf images missing kernel and initramfs
Package: cdimage.debian.org Severity: serious Tags: d-i As mentioned by bwh: existing armel and armhf installer CDs are currently missing vmlinuz and the initramfs... -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (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)
Bug#719321: reassigning to debian-cd
Control: reassign -1 debian-cd Some debian CDs in the past used to have working auto-detect on the multi-arch images, but that broke a while back. Odyx has been working on this again and we should have them again soon. In the meantime, there should be a your system won't boot this message prinmted by the kernel. Could you try a more recent image and see if that works for you please? -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#620979: texlive-xetex should depend on poppler-data to make the manual displayable
* Frank Küster fr...@debian.org, 2011-04-05, 21:42: Error: Missing language pack for 'Adobe-Japan1' mapping many times. I believe the fonts that trigger this problem are: Hiragino Maru Gothic Pro W4 Hiragino Maru Gothic Pro Hiragino Mincho Pro Are these fonts free? At least I can't find them packaged in Debian... -- Jakub Wilk
Bug#780700: /usr/bin/apt: provide a source command
Control: tag -1 wontfix On Tue, Mar 17, 2015 at 04:21:56PM -0700, Josh Triplett wrote: Package: apt Version: 1.0.9.7 Severity: wishlist File: /usr/bin/apt The new apt command should have a subcommand to download sources, similar to apt-get source. The 'apt' tool is not meant to replace the other tools, only to provide an easier to use frontend for average users. I don't think a source command fits that target audience. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 Netiquette. - If you don't I might ignore you.
Bug#795825: asterisk: FTBFS on amd64 arm64 ppc64el: /usr/bin/ld: cannot find -lSDL2 (and others)
Source: asterisk Version: 1:13.1.0~dfsg-1.1 Severity: serious Justification: fails to build from source (but built successfully in the past) When asterisk was binNMU'd for the libvpb1 transition, it failed to build from source on amd64, arm64 and ppc64el: https://buildd.debian.org/status/package.php?p=asterisk /«PKGBUILDDIR»/build_tools/make_linker_version_script chan_pjsip /«PKGBUILDDIR» x86_64-linux-gnu-gcc -o chan_pjsip.so -pthread -fPIE -pie -Wl,-z,relro -Wl,-z,now-shared -Wl,--version-script,chan_pjsip.exports,--warn-common chan_pjsip.o pjsip/dialplan_functions.o -lpjsua2 -lstdc++ -lpjsua -lpjsip-ua -lpjsip-simple -lpjsip -lpjmedia-codec -lpjmedia -lpjmedia-videodev -lpjmedia-audiodev -lpjmedia -lpjnath -lpjlib-util -lsrtp -lpj -lm -lrt -lpthread -lSDL2 -lavformat-ffmpeg -lavcodec-ffmpeg -lswscale-ffmpeg -lavutil-ffmpeg -lv4l2 -lopencore-amrnb -lopencore-amrwb /usr/bin/ld: cannot find -lSDL2 /usr/bin/ld: cannot find -lavformat-ffmpeg /usr/bin/ld: cannot find -lavcodec-ffmpeg /usr/bin/ld: cannot find -lswscale-ffmpeg /usr/bin/ld: cannot find -lavutil-ffmpeg /usr/bin/ld: cannot find -lv4l2 /usr/bin/ld: cannot find -lopencore-amrnb /usr/bin/ld: cannot find -lopencore-amrwb collect2: error: ld returned 1 exit status I don't know what's different about those three architectures. They're all 64-bit, but so is s390x, which built successfully. S
Bug#795830: gnupg-agent: please document backwards-incompatible changes in NEWS.Debian
Package: gnupg-agent Version: 2.1.7-2 gpg-agent --daemon no longer prints shell snippets on stdout, and the --write-env-file option is a no-op. These are backwards-incompatible changes (which broke my scripts that were ensuring that gnupg-agent is always running). I think they warrant a NEWS.Debian entry. -- Jakub Wilk
Bug#792758: bwidget vs. fsl incompatibility
Hi, thanks for the report and sorry for the delay. I can reproduce it, as soon as I install bwidget -- which is not a dependency of FSL. I'll look into it. Michael
Bug#791112: #791112: libcrypto++: library transition may be needed when GCC 5 is the default
On Mon, 2015-08-17 at 11:16 +0200, Christian Hofstaedtler wrote: Hi, I've noticed a new libcrypto++ has entered sid, but the transition tracker[1] doesn't seem to agree on the library names, or something (it still shows libcrypto++ as bad). What's going on there? [1] https://release.debian.org/transitions/html/auto-libcrypto++.html libcrypto9-dbg depends on libcrypto9. Until the transition's at a point where those packages can be decrufted from unstable, the tracker will see a package being built from src:libcrypto++ that depends on libcrypto9, and flag it as bad. Regards, Adam
Bug#795826: [Reproducible-builds] Bug#795826: epydoc: Please hide memory references in the output
Updated patch, which also takes care of not calling default __repr__ on functions. diff -u -r epydoc-3.0.1+dfsg.old/epydoc/markup/pyval_repr.py epydoc-3.0.1+dfsg/epydoc/markup/pyval_repr.py --- epydoc-3.0.1+dfsg.old/epydoc/markup/pyval_repr.py 2015-08-16 18:57:38.152484836 + +++ epydoc-3.0.1+dfsg/epydoc/markup/pyval_repr.py 2015-08-17 09:31:08.384223756 + @@ -207,9 +207,18 @@ self._colorize_re(pyval, state) else: try: -pyval_repr = repr(pyval) -if not isinstance(pyval_repr, (str, unicode)): -pyval_repr = unicode(pyval_repr) +pyval_class = pyval.__class__ +if hasattr(pyval, '__repr__') and \ +pyval_class.__repr__ is not object.__repr__ and \ +pyval_class.__repr__ is not types.FunctionType.__repr__: +pyval_repr = repr(pyval) +if not isinstance(pyval_repr, (str, unicode)): +pyval_repr = unicode(pyval_repr) +else: +# pyval has a default repr(), which would leak +# a reference to the object +pyval_repr = '%s.%s object' % ( +pyval_class.__module__, pyval_class.__name__) pyval_repr_ok = True except KeyboardInterrupt: raise signature.asc Description: OpenPGP digital signature
Bug#791305: transition: ucommon (libucommon7v5)
Quoting Simon McVittie (2015-08-17 10:44:47) reopen 791305 retitle 791305 transition: ucommon (libucommon7v5) reassign 791305 release.debian.org severity 791305 normal user release.debian@packages.debian.org usertags 791305 + transition forwarded 791305 https://release.debian.org/transitions/html/auto-ucommon.html thanks On Fri, 03 Jul 2015 at 13:14:43 +, Matthias Klose wrote: Then reassign the issue to release.debian.org and properly tag it as a transition issue, by sending an email to cont...@bugs.debian.org Reopening to do this. This issue is not fully resolved until libucommon7v5 has reached testing. Jonas, I believe the current RT policy is that transitioning packages can be uploaded to unstable as soon as their build-dependencies have transitioned. In the case of ucommon, I think that means you can upload to unstable now. Thanks for enlightening me. Preparing a build for unstable now... - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#791250: Do you need any help for pugixml
Quoting Jonas Smedegaard (2015-08-17 11:24:42) You uploaded to unstable, but I believe this should go to experimental first. I just learned (in bug#791305) that upload directly to unstable was perfectly fine. Sorry - no need for you to cancel that anyway. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#790987: #790987: botan1.10: library transition may be needed when GCC 5 is the default
Hi, could we please have a transition tracker for botan1.10, as apparently there's a conflict with libcrypto++, namely the pdns package which uses both libs. (And libcrypto++ has already started...) Thanks, -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgpCgmSGHFcbU.pgp Description: PGP signature
Bug#795835: epydoc: Please use (deterministic) sorting for module and class trees
Source: epydoc
Version: 3.0.1+dfsg-11
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi!
While working on the “reproducible builds” effort [1], we have noticed
that class trees written by epydoc list classes in an order that varies
across builds.
The attached patch uses a total order on classes (orders on class name,
then module, then package, then parent package, etc.) instead of a
partial one (only class name).
It also added ordering for modules.
Once applied, more packages using epydoc can be built reproducibly in
our current experimental framework.
[1]: https://wiki.debian.org/ReproducibleBuilds
Regards,
Val
diff -u -r epydoc-3.0.1+dfsg.old/epydoc/docwriter/html.py epydoc-3.0.1+dfsg/epydoc/docwriter/html.py
--- epydoc-3.0.1+dfsg.old/epydoc/docwriter/html.py 2015-08-16 18:57:38.152484836 +
+++ epydoc-3.0.1+dfsg/epydoc/docwriter/html.py 2015-08-17 09:59:14.756288022 +
@@ -404,6 +404,7 @@
imports=False, packages=False, bases=False, submodules=False,
subclasses=False, private=self._show_private))
self.module_list = [d for d in valdocs if isinstance(d, ModuleDoc)]
+self.module_list.sort(key=lambda x:(x.filename, x.path))
The list of L{ModuleDoc}s for the documented modules.
self.module_set = set(self.module_list)
The set of L{ModuleDoc}s for the documented modules.
@@ -1012,7 +1013,8 @@
#class_set.add(base)
out('ul class=nomargin-top\n')
-for doc in sorted(class_set, key=lambda c:c.canonical_name[-1]):
+sort_key = lambda c:tuple(reversed(c.canonical_name))
+for doc in sorted(class_set, key=sort_key):
if doc.bases != UNKNOWN and len(doc.bases)==0:
self.write_class_tree_item(out, doc, class_set)
out('/ul\n')
@@ -2817,7 +2819,8 @@
# endif
if doc.subclasses:
ul
- for subclass in sorted(set(doc.subclasses), key=lambda c:c.canonical_name[-1]):
+ sort_key = lambda c:tuple(reversed(c.canonical_name))
+ for subclass in sorted(set(doc.subclasses), key=sort_key):
if subclass in class_set:
self.write_class_tree_item(out, subclass, class_set)
#endif
signature.asc
Description: OpenPGP digital signature
Bug#795850: pdfgrep: FTBFS: pdfgrep.cc:429: undefined reference to `poppler::version_string[abi:cxx11]()'
Source: pdfgrep Version: 1.4.0-2 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, pdfgrep fails to build from source on unstable/amd64: [..] dh_auto_build make -j1 make[1]: Entering directory '/tmp/buildd/pdfgrep-1.4.0' make all-recursive make[2]: Entering directory '/tmp/buildd/pdfgrep-1.4.0' Making all in src make[3]: Entering directory '/tmp/buildd/pdfgrep-1.4.0/src' g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/poppler/cpp -I/usr/include/poppler-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o pdfgrep.o pdfgrep.cc pdfgrep.cc: In function 'int search_in_document(poppler::document*, const string, Regengine)': pdfgrep.cc:185:8: warning: 'templateclass class std::auto_ptr' is deprecated [-Wdeprecated-declarations] std::auto_ptrpoppler::page doc_page(doc-create_page(i - 1)); ^ In file included from /usr/include/c++/5/memory:81:0, from pdfgrep.cc:54: /usr/include/c++/5/bits/unique_ptr.h:49:28: note: declared here templatetypename class auto_ptr; ^ g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/poppler/cpp -I/usr/include/poppler-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o output.o output.cc g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/poppler/cpp -I/usr/include/poppler-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o exclude.o exclude.cc g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/poppler/cpp -I/usr/include/poppler-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o regengine.o regengine.cc g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -Wl,-z,relro -o pdfgrep pdfgrep.o output.o exclude.o regengine.o -lpoppler-cpp -lpcre pdfgrep.o: In function `print_version()': /tmp/buildd/pdfgrep-1.4.0/src/pdfgrep.cc:429: undefined reference to `poppler::version_string[abi:cxx11]()' pdfgrep.o: In function `do_search_in_document(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const, Regengine, bool)': /tmp/buildd/pdfgrep-1.4.0/src/pdfgrep.cc:463: undefined reference to `poppler::document::load_from_file(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status Makefile:276: recipe for target 'pdfgrep' failed make[3]: *** [pdfgrep] Error 1 make[3]: Leaving directory '/tmp/buildd/pdfgrep-1.4.0/src' Makefile:296: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/tmp/buildd/pdfgrep-1.4.0' Makefile:236: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/tmp/buildd/pdfgrep-1.4.0' dh_auto_build: make -j1 returned exit code 2 debian/rules:4: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 [..] The full build log is attached or can be viewed here: https://reproducible.debian.net/logs/unstable/amd64/pdfgrep_1.4.0-2.build1.log.gz Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- I: using fakeroot in build. I: pbuilder: network access will be disabled during build I: Current time: Fri Aug 14 13:03:23 GMT+12 2015 I: pbuilder-time-stamp: 1439600603 I: Building the build Environment I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz] I: creating local configuration I: copying local configuration I: mounting /proc filesystem I: mounting /run/shm filesystem I: mounting /dev/pts filesystem I: Mounting /dev/shm I: Mounting /sys I: policy-rc.d already exists I: Installing the build-deps - Attempting to satisfy build-dependencies - Creating pbuilder-satisfydepends-dummy package Package: pbuilder-satisfydepends-dummy Version: 0.invalid.0 Architecture: amd64 Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org Description: Dummy package to satisfy dependencies with aptitude - created by pbuilder This package was created automatically by pbuilder to satisfy the build-dependencies of the package being currently built. Depends: debhelper (= 9~), automake, libpoppler-cpp-dev, pkg-config, libpcre3-dev dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in
Bug#767754: [lintian] new check: file-in-root-and-usr
Hi! On Wed, 2015-08-05 at 13:35:08 +0200, Bastien ROUCARIES wrote: Guillem could you get a glimspe a this bug? Be warned, I've only spent few minutes thinking about it, so I've probably missed several things. On Wed, Aug 5, 2015 at 12:13 PM, Marco d'Itri m...@linux.it wrote: On Aug 05, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: And this link should removed a deinstall time and you do not give example for migration and check for dpkg-divert ... So your description is not complete... Could you give exact script snippet to use ? Better could you in parallel create a dpkg-maintscript-helper in order to avoid common error ? The Do you really think that this is needed, considering that I have already opened bugs with patches for all the affected packages? (Only zsh uses dpkg-divert, and I do not know how to handle this case.) Yes I think it is needed, but maybe guillem come with another ideas. Do you have an usertag for tracking bug you have already openned ? I don't think the operation is generic enough (i.e. not encoding policy, like paths) to fit in dpkg-maintscript-helper. Although if you can come up with a generic implementation, I'd consider adding it. For dpkg-divert I do not know how to handle I could be different depending the cases. Yeah, I guess it depends on the purpose. The problem is that diversions operate on files that are shipped by packages, and do not allow stacking so… Bailing out in preinst (or similar) might avoid possible breakage, but it seems rather harsh. Moreover for library why do we need to create the symlink ? I think one library shadow another and is still a bug. In this case you should duplicate the tag and create a new tag for library. I do not understand your comment. I means that binaries under s?bin and libraries are different beast. I think the solution for library is to not use symlink (and delete one of copy) because LD_PATH is always used whereas for bin you could call it directly. Right. In addition, from what I've seen from the submitted patches, I'd probably check for the ownership of the pathname being symlinked to or removed, and if it is owned by another package bail out. Because dpkg will not be performing such checks at unpack time. Thanks, Guillem
Bug#791112: #791112: libcrypto++: library transition may be needed when GCC 5 is the default
Hi, I've noticed a new libcrypto++ has entered sid, but the transition tracker[1] doesn't seem to agree on the library names, or something (it still shows libcrypto++ as bad). What's going on there? [1] https://release.debian.org/transitions/html/auto-libcrypto++.html Thanks, -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgphViDLawVVB.pgp Description: PGP signature
Bug#795828: libspock-java: New version for Spock available. Version 1.0 was released on 2015-03-02.
Package: libspock-java Version: 0.6-groovy-1.8-3 Severity: normal Dear Maintainer, can you update the libspock-java package to use the actual 1.0 version of Spock? cheers, Michael -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64)
Bug#794068: AW: Bug#794068: libpam-ldapd: unable to login when ldap-server sends password expiration warning
Thank you for the upstream fix. While I realize that you prefer to get a whole new upstream release into jessie, I wonder if there's any reason not to backport the relevant changes [1-3] to the nss-pam-ldapd_0.9.4-3 source? I rebuilt the package with these patches applied on my test system and it seems to work just fine. best regards, Joerg Uibel [1] http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=4302901a2708d55b24880b77437e3d782b0de1cb [2] http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=263a44340badb1e553c997f2dfb4986fb2f4c28b [3] http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=309f127416cd38f972d28b29f59e784ea5403785
Bug#790990: transition: cairomm (libcairomm-1.0-1v5)
Control: forwarded 790990 https://release.debian.org/transitions/html/auto-cairomm.html On 14/08/15 10:05, Simon McVittie wrote: I have NMU'd a renamed library to DELAYED/2 Now in unstable and built everywhere. S
Bug#776696: please update GTK+3 in Jessie to the latest 3.14.x bugfix release
Hi Vlad, I'm considering filing a jessie-pu bug on release.debian.org with patches for the serious bugs you mention in this thread. I think it will be much easier to get acceptance from the Stable Release team for that than to actually get the complete 3.14.x bugfix release in. Then we can paste the entire readable debdiff in the bug report for them to review it. Let me know what you think about it. I've started working on it here: https://github.com/rubund/gtk-bugfix/tree/master I'm not a maintainer of GTK, just a guy like you wanting to get some very important bug fixes into jessie. We need a few people to extensively test the package before filing the jessie-pu bug. Best regards Ruben
Bug#791036: flowcanvas: library transition to libflowcanvas5v5
Control: tags 791036 + confirmed Control: retitle 791036 flowcanvas: library transition to libflowcanvas5v5 On Fri, 03 Jul 2015 at 13:09:54 +, Matthias Klose wrote: - Decide if the symbols matching __cxx11 or B5cxx11 are part of the library API, and are used by the reverse dependencies of the library. Yes they are: this constructor 00067dea gDF .text 05fd Base FlowCanvas::Module::Module(boost::shared_ptrFlowCanvas::Canvas, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const, double, double, bool, bool) is called by ladish: http://anonscm.debian.org/cgit/pkg-multimedia/ladish.git/tree/gui/canvas.cpp#n102 So flowcanvas does need a rename to libflowcanvas5v5. This will have to wait until libgnomecanvasmm has been rebuilt for the cairomm transition. After that, the updated flowcanvas can be uploaded to unstable. This will be a small transition: ladish appears to be the only reverse dependency. Please do not close this bug with the upload of libflowcanvas5v5. Instead, please convert it into a transition tracker as requested in the initial mass bug filing, so that the rebuild of ladish can be scheduled. S
Bug#795829: qbs-doc: wrong installation path of .qch file
Package: qbs-doc Version: 1.4.1+dfsg-8 qbs.qch is installed to /usr/share/doc/qbs. Please, install it to `qmake -query QT_INSTALL_DOCS`.
Bug#770283: xfburn: No longer found in Stretch
retitle 770283 xfburn crashes when adding Data Composition files on ppc (32bit) severity 770283 normal tags 770283 + wontfix jessie thanks Hi Dan, thanks for the report! My guess is that gtk fixed something, but we'll probably never find out... great to hear that the situation has improved for you though! ~David On 2015-08-17 01:07, Dan DeVoto wrote: Package: xfburn Followup-For: Bug #770283 Dear Maintainer, I no longer experience this bug in 0.5.4-1 in Debian Stretch. Everything seems fine now. Regards, Dan -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 4.1.0-1-powerpc Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfburn depends on: ii libburn41.3.2-1.1 ii libc6 2.19-19 ii libexo-1-0 0.10.6-1 ii libgdk-pixbuf2.0-0 2.31.5-1 ii libglib2.0-02.44.1-1.1 ii libgstreamer-plugins-base1.0-0 1.4.5-2 ii libgstreamer1.0-0 1.4.5-2 ii libgtk2.0-0 2.24.28-1 ii libgudev-1.0-0 230-2 ii libisofs6 1.3.2-1.1 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util7 4.12.1-2 xfburn recommends no packages. xfburn suggests no packages. -- no debconf information
Bug#795839: initramfs-tools: When adding i8042 also add psmouse as some keyboards are behind the mouse
Package: initramfs-tools Version: 0.120 Severity: normal hook-functions/auto_add_modules: include psmouse as some keyboards are connected to the pass-thru port on the PS2 mouse port (because that is such a good idea). -apw From 7d8426c44a92c8d58bf5e60611582302fb14c1e8 Mon Sep 17 00:00:00 2001 From: Andy Whitcroft a...@canonical.com Date: Tue, 13 May 2014 18:32:00 +0100 Subject: [PATCH] When adding i8042 also add psmouse as some keyboards are behind the mouse. LP: #1314764 * hook-functions/auto_add_modules: include psmouse as some keyboards are connected to the pass-thru port on the PS2 mouse port because that is such a good idea). (LP: #1314764) Signed-off-by: Andy Whitcroft a...@canonical.com --- hook-functions | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hook-functions b/hook-functions index ee1c205..3eb781d 100644 --- a/hook-functions +++ b/hook-functions @@ -524,7 +524,7 @@ auto_add_modules() modules=$modules btrfs ext2 ext3 ext4 ext4dev modules=$modules isofs jfs reiserfs udf xfs modules=$modules nfs nfsv2 nfsv3 nfsv4 - modules=$modules af_packet atkbd i8042 + modules=$modules af_packet atkbd i8042 psmouse modules=$modules virtio_pci virtio_mmio # Include all HID drivers unless we're sure they -- 2.5.0
Bug#795608: krdc: Package uninstallable?
On Sunday 16 August 2015 09:16:54 Christian PERRIER wrote: That is likely the cause. I wouldn't be surprised if it would work if you also had the testing repos in your /etc/apt/sources.list Sadly, no. It may still be possible, but then you would probably have to downgrade a whole bunch of packages to their testing versions, including libstdc++6 which will bring lots of packages to their pre-gcc-5-transition versions. I've guided some ppl to do just that, but it was a lengthy (1 hour) exercise with direct communication on IRC (#debian-kde). Not sure it would be doable or the appropriate place on a bug report. And you may not want to do that for a single package. signature.asc Description: This is a digitally signed message part.
Bug#787836: [request-tracker-maintainers] Bug#787836: request-tracker4: unowned directories in /usr/local after purge (policy 6.8 and 9.1.2): /usr/local/share/request-tracker4/
Control: tags -1 + unreproducible On Fri, Jun 05, 2015 at 03:51:17PM +0200, Andreas Beckmann wrote: Package: request-tracker4 Version: 4.2.11-1 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails From the attached log (scroll to the bottom...): 2m47.7s ERROR: FAIL: Package purging left files on system: /usr/local/share/request-tracker4/ not owned Leaving directories in /usr/local after purge is also a violation of a should-directive in https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2 Hi, I couldn't reproduce this manually on a system; the prerm contains the correct snippets from dh_usrlocal which correctly remove the empty directories in /usr/local/share/request-tracker4. https://piuparts.debian.org/sid/maintainer/d/d...@earth.li.html also doesn't show this up. Could you let me know if you've still able to reproduce this, and if so how? Cheers, Dominic.
Bug#795848: foolscap: FTBFS: Ran 470 tests in 136.579s FAILED (skips=4, failures=1, errors=7, successes=462)
Source: foolscap Version: 0.8.0-1 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, foolscap fails to build from source on unstable/amd64: [..] test_simple ... [OK] test_two ... [OK] test_two_failure ... [OK] Base32 test_is_base32 ... [OK] Time test_format ... [OK] === [SKIPPED] new-style classes still broken foolscap.test.test_banana.ThereAndBackAgain.test_boundMethod_newstyle foolscap.test.test_banana.ThereAndBackAgain.test_classMethod_newstyle foolscap.test.test_banana.ThereAndBackAgain.test_class_newstyle foolscap.test.test_banana.ThereAndBackAgain.test_instance_newstyle === [FAIL] Traceback (most recent call last): File /tmp/buildd/foolscap-0.8.0/foolscap/test/test_logging.py, line 554, in _check_observer self.failUnlessEqual(len(msgs), 8) File /usr/lib/python2.7/dist-packages/twisted/trial/_synctest.py, line 437, in assertEqual super(_Assertions, self).assertEqual(first, second, msg) File /usr/lib/python2.7/unittest/case.py, line 513, in assertEqual assertion_func(first, second, msg=msg) File /usr/lib/python2.7/unittest/case.py, line 506, in _baseAssertEqual raise self.failureException(msg) twisted.trial.unittest.FailTest: 3 != 8 foolscap.test.test_logging.Publish.test_logpublisher === [ERROR] Traceback (most recent call last): File /tmp/buildd/foolscap-0.8.0/foolscap/test/test_logging.py, line 2185, in _check self.failUnlessEqual(fl_out[0][message], one) exceptions.KeyError: 'message' foolscap.test.test_logging.Bridge.test_no_loops === [ERROR] Traceback (most recent call last): File /tmp/buildd/foolscap-0.8.0/foolscap/test/test_logging.py, line 2156, in _check self.failUnlessEqual(fl_out[0][message], one) exceptions.KeyError: 'message' foolscap.test.test_logging.Bridge.test_twisted_to_foolscap === [ERROR] Traceback (most recent call last): File /tmp/buildd/foolscap-0.8.0/foolscap/banana.py, line 215, in produce slicer = self.newSlicerFor(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/banana.py, line 314, in newSlicerFor return topSlicer.slicerForObject(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/slicer.py, line 48, in slicerForObject return self.parent.slicerForObject(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/slicer.py, line 126, in slicerForObject return self.parent.slicerForObject(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/slicer.py, line 126, in slicerForObject return self.parent.slicerForObject(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/slicers/root.py, line 66, in slicerForObject raise Violation(cannot serialize %s (%s) % (obj, name)) foolscap.tokens.Violation: Violation (RootSlicer.call-0-1-msg.arg[0]-of-msg.??): (cannot serialize message 2 here (class 'twisted.logger._stdlib.StringifiableFromEvent'),) foolscap.test.test_logging.Publish.test_logpublisher_catchup === [ERROR] Traceback (most recent call last): File /tmp/buildd/foolscap-0.8.0/foolscap/banana.py, line 215, in produce slicer = self.newSlicerFor(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/banana.py, line 314, in newSlicerFor return topSlicer.slicerForObject(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/slicer.py, line 48, in slicerForObject return self.parent.slicerForObject(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/slicer.py, line 126, in slicerForObject return self.parent.slicerForObject(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/slicer.py, line 126, in slicerForObject return self.parent.slicerForObject(obj) File /tmp/buildd/foolscap-0.8.0/foolscap/slicers/root.py, line 66, in slicerForObject raise Violation(cannot serialize %s (%s) % (obj, name)) foolscap.tokens.Violation: Violation (RootSlicer.call-0-1-msg.arg[0]-of-msg.??): (cannot serialize message 3 here (class 'twisted.logger._stdlib.StringifiableFromEvent'),)
Bug#713313: drift: FTBFS: GenUtil.hs:290:14: Not in scope: `catch'
On Sun, Aug 16, 2015 at 10:46:06PM +0200, Uwe Kleine-König wrote: I'm currently in NM trying to become DD. As part of the process I prepared an NMU for this with the following debdiff. It's that big because I converted the package from dpatch to 3.0 (quilt). I assume the that Thijs will upload this nmu to a delayed queue (assuming he is happy with it). I suggest NMUing the latest upstream version as it will be less painful both long-term nd short-term.
Bug#767754: [lintian] new check: file-in-root-and-usr
On Mon, Aug 17, 2015 at 11:03 AM, Guillem Jover guil...@debian.org wrote: Hi! On Wed, 2015-08-05 at 13:35:08 +0200, Bastien ROUCARIES wrote: Guillem could you get a glimspe a this bug? Be warned, I've only spent few minutes thinking about it, so I've probably missed several things. Thanks guillem On Wed, Aug 5, 2015 at 12:13 PM, Marco d'Itri m...@linux.it wrote: On Aug 05, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: And this link should removed a deinstall time and you do not give example for migration and check for dpkg-divert ... So your description is not complete... Could you give exact script snippet to use ? Better could you in parallel create a dpkg-maintscript-helper in order to avoid common error ? The Do you really think that this is needed, considering that I have already opened bugs with patches for all the affected packages? (Only zsh uses dpkg-divert, and I do not know how to handle this case.) Yes I think it is needed, but maybe guillem come with another ideas. Do you have an usertag for tracking bug you have already openned ? I don't think the operation is generic enough (i.e. not encoding policy, like paths) to fit in dpkg-maintscript-helper. Although if you can come up with a generic implementation, I'd consider adding it. I perfectly understand what you means about dpkg-maintscript-helper. The first step is to create code snippet that work and are robust. For (/usr)./bin the code is not robust so marco could you go to teh blackboard ? Lintian would rather not suggest something that is error prone and fragile. For dpkg-divert I do not know how to handle I could be different depending the cases. Yeah, I guess it depends on the purpose. The problem is that diversions operate on files that are shipped by packages, and do not allow stacking so… Bailing out in preinst (or similar) might avoid possible breakage, but it seems rather harsh. Yes seems the safest path. And could be upgradable if needed. Moreover for library why do we need to create the symlink ? I think one library shadow another and is still a bug. In this case you should duplicate the tag and create a new tag for library. I do not understand your comment. I means that binaries under s?bin and libraries are different beast. I think the solution for library is to not use symlink (and delete one of copy) because LD_PATH is always used whereas for bin you could call it directly. Right. This part is non contreversal. So marco could you cook a patch detecting duplication between /lib and /usr/lib (including directory) and raising an error. This is a plain bug. It will serve as a basis for further test for /bin cases. In addition, from what I've seen from the submitted patches, I'd probably check for the ownership of the pathname being symlinked to or removed, and if it is owned by another package bail out. Because dpkg will not be performing such checks at unpack time. Marco it is up to you for this part. However I could help if needed. Thanks guillem for your quick review Bastien Thanks, Guillem
Bug#795843: zeal: Fix dpkg-buildflags-missing CPPFLAGS
Package: zeal Version: 1:0.1.1-2 Severity: normal Tags: newcomer The current CPPFLAGS is not appended to CFLAGS and CXXFLAGS and it causes dpkg-buildflags-missing warning in blhc. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages zeal depends on: ii libarchive13 3.1.2-11+b1 ii libc6 2.19-19 ii libgcc11:5.2.1-15 ii libqt5core5a 5.4.2+dfsg-8 ii libqt5gui5 5.4.2+dfsg-8 ii libqt5network5 5.4.2+dfsg-8 ii libqt5sql5 5.4.2+dfsg-8 ii libqt5sql5-sqlite 5.4.2+dfsg-8 ii libqt5webkit5 5.4.2+dfsg-3 ii libqt5widgets5 5.4.2+dfsg-8 ii libstdc++6 5.2.1-15 ii libx11-6 2:1.6.3-1 zeal recommends no packages. zeal suggests no packages. -- no debconf information -- ChangZhuo Chen (陳昌倬) czc...@gmail.com http://czchen.info/ Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: Digital signature
Bug#795847: jellyfish: FTBFS: error: 'struct std::__cxx11::basic_stringbuf_CharT, _Traits, _Alloc::__xfer_bufptrs' redeclared with different access
Source: jellyfish
Version: 2.2.3-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Dear Maintainer,
jellyfish fails to build from source on unstable/amd64:
[..]
g++ -DHAVE_CONFIG_H -I. -Dprotected=public -Dprivate=public
-DJSON_IS_AMALGAMATION=1 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++0x -g
-O3 -Werror -I./unit_tests/gtest/include -I./unit_tests -I./include
-std=c++0x -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -c -o unit_tests/bin_test_all-test_main.o
`test -f 'unit_tests/test_main.cc' || echo
'./'`unit_tests/test_main.cc
In file included from ./unit_tests/gtest/gtest.h:308:0,
from unit_tests/test_main.cc:20:
/usr/include/c++/5/sstream:300:7: error: 'struct
std::__cxx11::basic_stringbuf_CharT, _Traits,
_Alloc::__xfer_bufptrs' redeclared with different access
struct __xfer_bufptrs
^
Makefile:1369: recipe for target 'unit_tests/bin_test_all-test_main.o'
failed
make[4]: *** [unit_tests/bin_test_all-test_main.o] Error 1
make[4]: Leaving directory '/tmp/buildd/jellyfish-2.2.3'
Makefile:2319: recipe for target 'check-am' failed
make[3]: *** [check-am] Error 2
make[3]: Leaving directory '/tmp/buildd/jellyfish-2.2.3'
Makefile:1875: recipe for target 'check-recursive' failed
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory '/tmp/buildd/jellyfish-2.2.3'
Makefile:2322: recipe for target 'check' failed
make[1]: *** [check] Error 2
make[1]: Leaving directory '/tmp/buildd/jellyfish-2.2.3'
dh_auto_test: make -j1 check returned exit code 2
debian/rules:8: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
[..]
The full build log is attached or can be viewed here:
https://reproducible.debian.net/logs/unstable/amd64/jellyfish_2.2.3-1.build1.log.gz
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Mon Aug 10 14:59:19 GMT+12 2015
I: pbuilder-time-stamp: 1439261959
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: Mounting /sys
I: policy-rc.d already exists
I: Installing the build-deps
- Attempting to satisfy build-dependencies
- Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (= 9), dh-autoreconf, d-shlibs, yaggo, pkg-config, bc,
time, procps, valgrind
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20247 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring
anyway as you requested:
pbuilder-satisfydepends-dummy depends on dh-autoreconf; however:
Package dh-autoreconf is not installed.
pbuilder-satisfydepends-dummy depends on d-shlibs; however:
Package d-shlibs is not installed.
pbuilder-satisfydepends-dummy depends on yaggo; however:
Package yaggo is not installed.
pbuilder-satisfydepends-dummy depends on pkg-config; however:
Package pkg-config is not installed.
pbuilder-satisfydepends-dummy depends on bc; however:
Package bc is not installed.
pbuilder-satisfydepends-dummy depends on time; however:
Package time is not installed.
pbuilder-satisfydepends-dummy depends on valgrind; however:
Package valgrind is not installed.
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
Building tag database...
The following NEW packages will be installed:
autoconf{a} automake{a} autopoint{a} autotools-dev{a} bc{a}
ca-certificates{a} d-shlibs{a} dh-autoreconf{a} libc6-dbg{a}
libruby2.1{a} libsigsegv2{a} libssl1.0.0{a} libtool{a} libyaml-0-2{a}
m4{a} openssl{a} pkg-config{a} ruby{a} ruby2.1{a} rubygems-integration{a}
time{a} valgrind{a} yaggo{a}
0
Bug#759604: auditd: Please make auditd log readable by the adm group
Hi, Laurent Bigonville wrote (17 Aug 2015 08:58:52 GMT) : Le Mon, 17 Aug 2015 10:37:00 +0200, intrigeri intrig...@debian.org a écrit : Sorry for not replying earlier. No problem, thanks for replying. The problem might be IIRC that the auditd daemon itself check the mode/owner/group of the files on disk before starting. I do not remembrer all the details though. Sorry, I should have been clearer. I've tested that this combination works just fine on current sid: * log_group = adm * dpkg-statoverride --update --add root adm 750 audit We need the check that by changing this we are not loosing some kind of US gouvernement certifications if we really care about this (auditd daemon follows some gouvernement recommendations/certification). Is there any practical value in complying to such recommendations in a single package, as long as the underlying base OS does not? (I suspect not, but that's a genuine question, not a rhetorical one: I have actually no idea how these things work, nor whether we have any Debian users who care about that.) Maybe you could ask on the linux-au...@redhat.com mailing list? Yes, I can do that if needed, once we've clarified whether that's a goal worth pursuing (otherwise there's no point). Cheers, -- intrigeri
Bug#795410: postgresql-common: pg_createcluster fails on clean install of postgresql
Hi Christoph, Thanks for looking into this. I've managed to bash the original container into installing the cluster, so it can't be used to properly debug this. I've just setup a new one, as described in the original bug report, so I can show you my findings. In the clean install, apt-get install postgresql exhibits the error described in the bug. From here: root@debian-db:~# su - postgres postgres@debian-db:~$ /bin/sh $ exit postgres@debian-db:~$ cat /etc/postgresql/9.4/main/postgresql.conf cat: /etc/postgresql/9.4/main/postgresql.conf: Permission denied postgres@debian-db:~$ ls -lah /etc/ | grep postgresql drwxr-x---+ 3 root root 4.0K Aug 17 08:49 postgresql drwxr-xr-x+ 3 root root 4.0K Aug 17 08:47 postgresql-common postgres@debian-db:~$ exit So, postgres seems able to execute /bin/sh just fine, but can't read the postgresql.conf file, in line with the file permissions. root@debian-db:~# pg_dropcluster 9.4 main root@debian-db:~# chown postgres /etc/postgresql root@debian-db:~# cd /tmp pg_createcluster 9.4 main Creating new cluster 9.4/main ... config /etc/postgresql/9.4/main data /var/lib/postgresql/9.4/main locale en_US.UTF-8 Flags of /var/lib/postgresql/9.4/main set as -e-C Warning: The socket directory for owners other than 'postgres' defaults to /tmp. You might want to change the unix_socket_directories parameter in postgresql.conf to a more secure directory. Error: could not open /etc/postgresql/9.4/main/postgresql.conf for reading at /usr/share/perl5/PgCommon.pm line 194. Can't exec /bin/sh: Permission denied at /usr/bin/pg_createcluster line 590. Same error. Strangely, now: root@debian-db:/tmp# su - postgres postgres@debian-db:~$ cat /etc/postgresql/9.4/main/postgresql.conf [postgresql.conf content here] So, the only option is a wrong error message. If I edit the relevant section in /usr/bin/pg_createcluster, I can get it to work. On line 417, there's this content: set_cluster_socketdir $version, $cluster, $socketdir if $socketdir; $ = $orig_euid; $) = $orig_egid; Change it to: $ = $orig_euid; $) = $orig_egid; set_cluster_socketdir $version, $cluster, $socketdir if $socketdir; (i.e. Run the config change as root, not as postgres, which is consistent with the rest of the script). I think the error reported by PgCommon.pm is wrong. It can't *write* the conf file, not *read*. After the change, pg_createcluster 9.4 main runs just fine. Now, for the cherry on top. The cluster won't start: root@debian-db:/tmp# systemctl start postgresql@9.4-main.service Job for postgresql@9.4-main.service failed because the control process exited with error code. See systemctl status postgresql@9.4-main.service and journalctl -xe for details. systemctl status doesn't give any interesting info: root@debian-db:/tmp# systemctl status postgresql@9.4-main.service ● postgresql@9.4-main.service - PostgreSQL Cluster 9.4-main Loaded: loaded (/lib/systemd/system/postgresql@.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2015-08-17 09:09:28 UTC; 35s ago Process: 3198 ExecStart=postgresql@%i %i start (code=exited, status=1/FAILURE) Aug 17 09:08:57 debian-db systemd[1]: Starting PostgreSQL Cluster 9.4-main... Aug 17 09:09:28 debian-db postgresql@9.4-main[3198]: The PostgreSQL server failed to start. Please check the log output. Aug 17 09:09:28 debian-db systemd[1]: postgresql@9.4-main.service: Control process exited, code=exited status=1 Aug 17 09:09:28 debian-db systemd[1]: Failed to start PostgreSQL Cluster 9.4-main. Aug 17 09:09:28 debian-db systemd[1]: postgresql@9.4-main.service: Unit entered failed state. Aug 17 09:09:28 debian-db systemd[1]: postgresql@9.4-main.service: Failed with result 'exit-code'. But it is again a question of permissions. /var/log/postgresql is owned by root:postgres with permissions rwxrwxr-t. Within, postgresql-9.4-main.log is owned by postgres:adm with permissions rw-r-. It should work, but postgresql complains it can't write to its log. I suppose the temporary flag in the log directory may cause strange behaviour when the log file is accessed by a different user/group pair (postgres:postgres vs postgres:adm). root@debian-db:/tmp# rm -Rf /var/log/postgresql/; mkdir /var/log/postgresql/; chown postgres:postgres /var/log/postgresql/ root@debian-db:/tmp# systemctl start postgresql@9.4-main.service root@debian-db:/tmp# echo $? 0 Sorry for the long mail. It was inevitable. It seems pg_createcluster is actually wrong, the configuration change should be done as root (from what I infer from the rest of the script). However, something in debian triggered this, as it didn't use to happen (I last did this operation over a year ago, so my the bisection is not much use, really). If you need to play around with this install, I can try and get this container online and accessible to you. Tell me if you need me to. Cheers, -- Sérgio Carvalho On Fri, Aug 14, 2015 at 6:34 PM, Christoph Berg m...@debian.org wrote:
Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Hey, OK looking at this bug, if I understood the issue properly, I think I found what the problem is. With libpam-systemd installed, UsePAM set to yes, the ssh process with lower privileges is assign to the user session, when shutting down, systemd is going through all the user sessions and kill them one by one properly. Without libpam-systemd (or UsePAM set to no), the low privileged process stays in the sshd cgroup. As the ssh.service file explicitly contains KillMode=process, only the main (privileged) process is killed. At the end of the shutdown procedure, systemd is going into a killing spree and SIGKILL all the remaining processes. The correct solution is IMVHO is to use libpam-systemd with UsePAM set to yes. On other solution is to change the KillMode, but doing so, you'll probably loose the connection if the ssh service is restarted. my 2¢ Laurent Bigonville
Bug#795840: [Pkg-utopia-maintainers] Bug#795840: udisks2: No man manpage (an no other documentation)
Control: tags -1 moreinfo Am 17.08.2015 um 12:46 schrieb Stephen McGregor: Package: udisks2 Version: 2.1.3-5 Severity: important Dear Maintainer, * What led up to the situation? I want to configure udisks2 so that it will work, so I needed a man page. But there is no man page. I understand that this, also, violates Debian packaging rules There is an effectively empty readme, and a man page for umount.udisks2 which is a helper for umount (to clean out udisks2 files) * What exactly did you do (or not do) that was effective (or ineffective)? Nothing * What was the outcome of this action? I cannot use udisks2 * What outcome did you expect instead? That there would be a man page, and that I would be able to use udisks2 # dpkg -L udisks2 | grep man.*gz /usr/share/man/man1/udisksctl.1.gz /usr/share/man/man8/udisksd.8.gz /usr/share/man/man8/udisks.8.gz /usr/share/man/man8/umount.udisks2.8.gz What information exactly are you missing? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#795849: biojava4-live: FTBFS: DemoOrientBioAssembly.java:60: error: unmappable character for encoding ASCII
Source: biojava4-live Version: 4.1.0+dfsg-1 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, Thanks for looking at #795685 so quickly. However, biojava4-live still fails to build from source on unstable/amd64 with a different issue: [..] compile: [mkdir] Created dir: /tmp/buildd/biojava4-live-4.1.0+dfsg/build/biojava4-structure-gui/classes [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/build.xml:76: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 130 source files to /tmp/buildd/biojava4-live-4.1.0+dfsg/build/biojava4-structure-gui/classes [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:60: error: unmappable character for encoding ASCII [javac] 4F88 ??? local C8 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:60: error: unmappable character for encoding ASCII [javac] 4F88 ??? local C8 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:60: error: unmappable character for encoding ASCII [javac] 4F88 ??? local C8 [javac]^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:61: error: unmappable character for encoding ASCII [javac] 1LTI ??? local C5 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:61: error: unmappable character for encoding ASCII [javac] 1LTI ??? local C5 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:61: error: unmappable character for encoding ASCII [javac] 1LTI ??? local C5 [javac]^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:62: error: unmappable character for encoding ASCII [javac] 2W6E ??? local C3 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:62: error: unmappable character for encoding ASCII [javac] 2W6E ??? local C3 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:62: error: unmappable character for encoding ASCII [javac] 2W6E ??? local C3 [javac]^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:63: error: unmappable character for encoding ASCII [javac] 2LXC ??? local C2 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:63: error: unmappable character for encoding ASCII [javac] 2LXC ??? local C2 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:63: error: unmappable character for encoding ASCII [javac] 2LXC ??? local C2 [javac]^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:64: error: unmappable character for encoding ASCII [javac] 3OE7 ??? local C3 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:64: error: unmappable character for encoding ASCII [javac] 3OE7 ??? local C3 [javac] ^ [javac] /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:64: error:
Bug#795877: missing os import
Hi Jamie, On Monday 17 August 2015 16:14:30 Jamie Heilman wrote: This is something of a show stopper: Sorry about that. This is a reminder to me to never ever upload Xpra without comprehensive testing due to frequent regressions even in minor bugfix releases... :( Trivial to fix though, xpra/client/window_backing_base.py just needs to import os. Thank you. I'll upload ASAP... -- Best wishes, Dmitry Smirnov. --- Good luck happens when preparedness meets opportunity. signature.asc Description: This is a digitally signed message part.
Bug#795926: openafs: Please verify that 'Restore support for using regexes ... OPENAFS-SA-2015-006' is part of Jessie (and Wheezy) OpenAFS
Package: openafs-modules-dkms Version: 1.6.9-2+deb8u3 Severity: important File: openafs Hello, I see that openafs version 1.6.14-1 has a changelog item Restore support for using regexes for volume names to backup, accidentally disabled as part of the fix for OPENAFS-SA-2015-006, but the most recent Jessie openafs version that I find (1.6.9-2+deb8u3) does not have this in the changelog. The Wheezy version (1.6.1-3+deb7u4) also appears not have the updated fix for OPENAFS-SA-2015-006. Thanks for checking! C. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openafs-modules-dkms depends on: ii dkms 2.2.0.3-2 ii libc6-dev 2.19-18 ii perl 5.20.2-3+deb8u1 Versions of packages openafs-modules-dkms recommends: ii openafs-client 1.6.9-2+deb8u3 openafs-modules-dkms suggests no packages. -- no debconf information
Bug#795926: openafs: Please verify that 'Restore support for using regexes ... OPENAFS-SA-2015-006' is part of Jessie (and Wheezy) OpenAFS
tags 795926 +moreinfo thanks On Mon, 17 Aug 2015, Chad W Seys wrote: Package: openafs-modules-dkms Version: 1.6.9-2+deb8u3 Severity: important File: openafs Hello, I see that openafs version 1.6.14-1 has a changelog item Restore support for using regexes for volume names to backup, accidentally disabled as part of the fix for OPENAFS-SA-2015-006, but the most recent Jessie openafs version that I find (1.6.9-2+deb8u3) does not have this in the changelog. The Wheezy version (1.6.1-3+deb7u4) also appears not have the updated fix for OPENAFS-SA-2015-006. Thanks for checking! The current openafs versions in wheezy and jessie do not support the use of regexps for volume names. (That is, they do not include the change you see mentioned in the 1.6.14-1 changelog.) Are you encountering issues on a wheezy and/or jessie system while attempting to use this functionality? I am somewhat reluctant to put in the time to push through the necessary stable-proposed-updates if there is not actually anyone who will benefit from the changes. (My understanding is that most sites who use the OpenAFS backup system do so with the TSM support, which is not enabled in the Debian packages and must be done via a custom build.) -Ben
Bug#795918: libatkmm-1.6-1: transition potentially needed for g++-5 ABI
Package: libatkmm-1.6-1
Version: 2.22.7-2.1+b1
Severity: important
Tags: patch
atkmm1.6 potentially needs a transition to the g++-5 ABI.
See the similar glibmm bug for all the tedious details.
This was blocked by starting both the cairomm and glibmm phases of the
transition, but that has now been done.
Matthias' build logs do not mention any cxx11 symbols, so it is possible
that atkmm1.6 and pangomm do not strictly need to transition,
but Matthias' recent mail to debian-devel mentions some concerns about
ABI breaks that are not automatically detected, and nothing seems to
build-depend on atkmm1.6 or pangomm without also depending on either gtkmm2.4
or gtkmm3.0 anyway; so everything that would be binNMU'd for an atk1.6 or
pangomm transition is going to have to be binNMU'd for a gtkmm2.4 or
gtkmm3.0 transition in any case, and those two are definitely required.
So we might as well do them all at once?
I have staged this in pkg-gnome svn, but not yet tested it (I want to work
my way far enough up the dependency stack to run an actual application).
S
diffstat for atkmm1.6-2.22.7 atkmm1.6-2.22.7
changelog| 16
control | 19 +--
control.in | 18 +-
libatkmm-1.6-1.install |1 -
libatkmm-1.6-1v5.install |1 +
5 files changed, 35 insertions(+), 20 deletions(-)
diff -Nru atkmm1.6-2.22.7/debian/changelog atkmm1.6-2.22.7/debian/changelog
--- atkmm1.6-2.22.7/debian/changelog 2014-08-28 19:50:44.0 +0100
+++ atkmm1.6-2.22.7/debian/changelog 2015-08-17 22:52:51.0 +0100
@@ -1,3 +1,19 @@
+atkmm1.6 (2.22.7-3) unstable; urgency=medium
+
+ * Team upload.
+
+ [ Michael Biebl ]
+ * Bump Build-Depends on cdbs for multiarch support
+
+ [ Jeremy Bicha ]
+ * Use canonical Vcs-* fields
+
+ [ Simon McVittie ]
+ * Rename libatkmm-1.6-1 to libatkmm-1.6-1v5 for the libstdc++ transition.
+Based on a patch by Matthias Klose.
+
+ -- Simon McVittie s...@debian.org Mon, 17 Aug 2015 22:52:45 +0100
+
atkmm1.6 (2.22.7-2.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru atkmm1.6-2.22.7/debian/control atkmm1.6-2.22.7/debian/control
--- atkmm1.6-2.22.7/debian/control 2014-08-28 19:51:54.0 +0100
+++ atkmm1.6-2.22.7/debian/control 2015-08-17 22:52:54.0 +0100
@@ -2,20 +2,19 @@
#
# Modifications should be made to debian/control.in instead.
# This file is regenerated automatically in the clean target.
-
Source: atkmm1.6
Section: libs
Priority: optional
Maintainer: Krzysztof Klimonda kklimo...@syntaxhighlighted.com
Uploaders: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org, Deng Xiyue manphiz-gu...@users.alioth.debian.org, Michael Biebl bi...@debian.org
Homepage: http://www.gtkmm.org/
-Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/atkmm1.6
-Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/atkmm1.6
-Build-Depends: cdbs (= 0.4.51),
+Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/atkmm1.6/
+Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/atkmm1.6/
+Build-Depends: cdbs (= 0.4.93),
debhelper (= 9),
dh-autoreconf,
gnome-pkg-tools (= 0.11),
- libglibmm-2.4-dev (= 2.36.0),
+ libglibmm-2.4-dev (= 2.44.0-2~),
libatk1.0-dev (= 1.12.0),
mm-common (= 0.9.3)
Standards-Version: 3.9.4
@@ -26,7 +25,7 @@
Multi-Arch: same
Depends: ${misc:Depends},
${shlibs:Depends},
- libatkmm-1.6-1 (= ${binary:Version}),
+ libatkmm-1.6-1v5 (= ${binary:Version}),
libglibmm-2.4-dev (= 2.36.0),
libatk1.0-dev (= 1.12.0),
Suggests: libatkmm-1.6-doc
@@ -39,14 +38,14 @@
.
This package contains development files.
-Package: libatkmm-1.6-1
+Package: libatkmm-1.6-1v5
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends},
${shlibs:Depends}
-Breaks: libgtkmm-2.4-1c2a ( 1:2.22.0)
-Replaces: libgtkmm-2.4-1c2a ( 1:2.22.0)
+Breaks: libgtkmm-2.4-1c2a ( 1:2.22.0), libatkmm-1.6-1
+Replaces: libgtkmm-2.4-1c2a ( 1:2.22.0), libatkmm-1.6-1
Description: C++ wrappers for ATK accessibility toolkit (shared libraries)
Atkmm is a C++ interface for ATK, accessibility toolkit used by Gtk+ library.
It provides a familiar interface for C++ programmers to add accessibility
@@ -61,7 +60,7 @@
Multi-Arch: same
Depends: ${misc:Depends},
${shlibs:Depends},
- libatkmm-1.6-1 (= ${binary:Version})
+ libatkmm-1.6-1v5 (= ${binary:Version})
Breaks: libgtkmm-2.4-dbg ( 1:2.22.0)
Replaces: libgtkmm-2.4-dbg ( 1:2.22.0)
Description: C++ wrappers for ATK accessibility toolkit (debug symbols)
diff -Nru atkmm1.6-2.22.7/debian/control.in atkmm1.6-2.22.7/debian/control.in
--- atkmm1.6-2.22.7/debian/control.in 2014-08-28 19:49:58.0 +0100
+++ atkmm1.6-2.22.7/debian/control.in 2015-08-17
Bug#795919: libpangomm-1.4-1: transition potentially needed for g++-5 ABI
Package: libpangomm-1.4-1
Version: 2.36.0-1+b1
Severity: important
Tags: patch
pangomm potentially needs a transition to the g++-5 ABI.
See the similar glibmm bug for all the tedious details.
This was blocked by starting both the cairomm and glibmm phases of the
transition, but that has now been done.
Matthias' build logs do not mention any cxx11 symbols, so it is possible
that atkmm1.6 and pangomm do not strictly need to transition,
but Matthias' recent mail to debian-devel mentions some concerns about
ABI breaks that are not automatically detected, and nothing seems to
build-depend on atkmm1.6 or pangomm without also depending on either gtkmm2.4
or gtkmm3.0 anyway; so everything that would be binNMU'd for an atk1.6 or
pangomm transition is going to have to be binNMU'd for a gtkmm2.4 or
gtkmm3.0 transition in any case, and those two are definitely required.
So we might as well do them all at once?
I have staged this in pkg-gnome svn, but not yet tested it (I want to work
my way far enough up the dependency stack to run an actual application).
S
diffstat for pangomm-2.36.0 pangomm-2.36.0
changelog |9 +
control| 12 +++-
control.in | 12 +++-
libpangomm-1.4-1.install |1 -
libpangomm-1.4-1v5.install |1 +
5 files changed, 24 insertions(+), 11 deletions(-)
diff -Nru pangomm-2.36.0/debian/changelog pangomm-2.36.0/debian/changelog
--- pangomm-2.36.0/debian/changelog 2015-05-11 01:44:02.0 +0100
+++ pangomm-2.36.0/debian/changelog 2015-08-17 22:04:59.0 +0100
@@ -1,3 +1,12 @@
+pangomm (2.36.0-2) unstable; urgency=medium
+
+ * Team upload.
+ * Rename library package to libpangomm-1.4-1v5 for libstdc++ ABI
+transition. Based on changes made in Ubuntu by Sebastien Bacher.
+- Bump Build-Depends on glibmm and cairomm to g++-5-built versions
+
+ -- Simon McVittie s...@debian.org Mon, 17 Aug 2015 22:04:57 +0100
+
pangomm (2.36.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru pangomm-2.36.0/debian/control pangomm-2.36.0/debian/control
--- pangomm-2.36.0/debian/control 2015-05-11 01:47:36.0 +0100
+++ pangomm-2.36.0/debian/control 2015-08-17 22:05:07.0 +0100
@@ -13,19 +13,21 @@
debhelper (= 9),
dh-autoreconf,
gnome-pkg-tools (= 0.11),
- libcairomm-1.0-dev (= 1.2.2),
- libglibmm-2.4-dev (= 2.36.0),
+ libcairomm-1.0-dev (= 1.10.0-1.2~),
+ libglibmm-2.4-dev (= 2.44.0-2~),
libpango1.0-dev (= 1.36.0),
mm-common (= 0.9.5)
Standards-Version: 3.9.6
Homepage: http://gtkmm.org
-Package: libpangomm-1.4-1
+Package: libpangomm-1.4-1v5
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends},
${misc:Depends}
+Conflicts: libpangomm-1.4-1
+Replaces: libpangomm-1.4-1
Description: C++ Wrapper for pango (shared libraries)
Pangomm is a C++ wrapper for the pango library. Originally part of
gtkmm, pangomm provides convenient C++ interfaces for handling both
@@ -39,7 +41,7 @@
Section: libdevel
Depends: ${shlibs:Depends},
${misc:Depends},
- libpangomm-1.4-1 (= ${binary:Version}),
+ libpangomm-1.4-1v5 (= ${binary:Version}),
libcairomm-1.0-dev (= 1.2.2),
libglibmm-2.4-dev (= 2.36.0),
libpango1.0-dev (= 1.36.0)
@@ -73,7 +75,7 @@
Priority: extra
Depends: ${shlibs:Depends},
${misc:Depends},
- libpangomm-1.4-1 (= ${binary:Version})
+ libpangomm-1.4-1v5 (= ${binary:Version})
Description: C++ Wrapper for pango (debugging symbols)
Pangomm is a C++ wrapper for the pango library. Originally part of
gtkmm, pangomm provides convenient C++ interfaces for handling both
diff -Nru pangomm-2.36.0/debian/control.in pangomm-2.36.0/debian/control.in
--- pangomm-2.36.0/debian/control.in 2015-05-11 01:43:24.0 +0100
+++ pangomm-2.36.0/debian/control.in 2015-08-17 21:43:23.0 +0100
@@ -9,19 +9,21 @@
debhelper (= 9),
dh-autoreconf,
gnome-pkg-tools (= 0.11),
- libcairomm-1.0-dev (= 1.2.2),
- libglibmm-2.4-dev (= 2.36.0),
+ libcairomm-1.0-dev (= 1.10.0-1.2~),
+ libglibmm-2.4-dev (= 2.44.0-2~),
libpango1.0-dev (= 1.36.0),
mm-common (= 0.9.5)
Standards-Version: 3.9.6
Homepage: http://gtkmm.org
-Package: libpangomm-1.4-1
+Package: libpangomm-1.4-1v5
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends},
${misc:Depends}
+Conflicts: libpangomm-1.4-1
+Replaces: libpangomm-1.4-1
Description: C++ Wrapper for pango (shared libraries)
Pangomm is a C++ wrapper for the pango library. Originally part of
gtkmm, pangomm provides convenient C++ interfaces for handling both
@@ -35,7 +37,7 @@
Section: libdevel
Depends:
Bug#764780: mirror submission for mirrors.200p-sf.sonic.net
Control: tag -1 +moreinfo Hello, Your submission indicates that you will offer debian and debian-backports, however there is not backports directory found. Is this in error? On Fri, 10 Oct 2014 23:16:00 + Sonic.net, Inc. s...@sonic.net wrote: Package: mirrors Severity: wishlist Submission-Type: new Site: mirrors.200p-sf.sonic.net Type: leaf Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc Archive-ftp: /debian/ Archive-http: /debian/ Backports-ftp: /debian/ Backports-http: /debian/ IPv6: no Archive-upstream: carroll.cac.psu.edu Backports-upstream: carroll.cac.psu.edu Updates: once Maintainer: Sonic.net, Inc. s...@sonic.net Country: US United States Location: San Francisco, CA Sponsor: Sonic.net, Inc. http://www.sonic.net/ Best regards, Donald Norwood signature.asc Description: OpenPGP digital signature
Bug#794222: Missing patch
On Mon, Aug 17, 2015 at 4:34 PM, Aurelien Jarno aurel...@aurel32.net wrote: So this is IMO, the wrong thing to do. You should push the patch into upstream 2.19 stable and rebase instead of keeping the patch in debian svn. Given the patch is already in upstream master it is OK to commit to 2.19 stable, and post to libc-stable stating you checked in this fix. That way debian gets broader testing of the patches we are using instead of the narrower just debian users. If it is fine to push this kind of patch in this branch, I would certainly do that. I also backported for debian patch b0a3c164. Would it be possible to also push it to the branch? If the patch doesn't change API/ABI, and it was accepted for master, then it's perfectly acceptable to push to 2.19 stable branch. You post your commit email to libc-stable so other maintainers know why you're pushing the patch. You'd post a Subject:[COMMITTED] 2.19: Fix blah blah blah, Body: Cherry picked fix for the ppc64le bug X into 2.19. Following the usual cherry pick process: https://sourceware.org/glibc/wiki/GlibcGit#Cherry_Pick_Changes_From_Another_Branch Then you're done. The 2.19 branch is a rolling stable release from which you can rebase your own distro branches, either external (on sourceware) or internal (in your own repos in the distro). Cheers, Carlos.
Bug#794222: Missing patch
On Mon, Aug 17, 2015 at 7:06 PM, Carlos O'Donell car...@systemhalted.org wrote: On Mon, Aug 17, 2015 at 4:34 PM, Aurelien Jarno aurel...@aurel32.net wrote: So this is IMO, the wrong thing to do. You should push the patch into upstream 2.19 stable and rebase instead of keeping the patch in debian svn. Given the patch is already in upstream master it is OK to commit to 2.19 stable, and post to libc-stable stating you checked in this fix. That way debian gets broader testing of the patches we are using instead of the narrower just debian users. If it is fine to push this kind of patch in this branch, I would certainly do that. I also backported for debian patch b0a3c164. Would it be possible to also push it to the branch? If the patch doesn't change API/ABI, and it was accepted for master, then it's perfectly acceptable to push to 2.19 stable branch. You post your commit email to libc-stable so other maintainers know why you're pushing the patch. You'd post a Subject:[COMMITTED] 2.19: Fix blah blah blah, Body: Cherry picked fix for the ppc64le bug X into 2.19. Following the usual cherry pick process: https://sourceware.org/glibc/wiki/GlibcGit#Cherry_Pick_Changes_From_Another_Branch Then you're done. The 2.19 branch is a rolling stable release from which you can rebase your own distro branches, either external (on sourceware) or internal (in your own repos in the distro). Please make sure to merge the ChangeLog and NEWS though, and start a new 2.19.1 NEWS section if it isn't started. That way if someone wants to cut a release they can. Though the intent is never to cut a release and always roll the branches and let distros rebase. c.
Bug#795923: klipper: Missing transitional package for KDE5 transition
Package: klipper
Severity: minor
Dear Maintainer,
I recently upgraded from jessie to testing and had to do a little manual
intervention.
The KDE4 `klipper` package's contents are now included in the
`plasma-workspace` package.
In order to ensure a correct upgrade experience, an empty binary `klipper`
package should exist containing just `Depends: plasma-workspace` and
the `plasma-workspace` package should add all three of:
`Conflicts: klipper` (to ensure both can't be installed at the same time),
`Replaces: klipper` (to ensure the upgraded package can be installed),
and `Provides: klipper` (to ensure that any packages with `Depends: klipper`
still work).
These transitional measures can be removed in `buster` since it is only
supported to upgrade one release at a time.
I also noticed `kde-workspace{,-bin,-data}` only exists in KDE4 but did
not figure out where exactly its contents moved. Likely there are more
packages: I don't have a full KDE install, and sometimes the package
manager is smart enough to find a way to install the new package even
if the control fields are wrong.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (600, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, arm64, armhf
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages klipper depends on:
ii kde-runtime 4:4.14.2-2
ii libc62.19-19
ii libkdecore5 4:4.14.2-5
ii libkdeui54:4.14.2-5
ii libprison0 1.1.1-1
ii libqt4-dbus 4:4.8.7+dfsg-1
ii libqtcore4 4:4.8.7+dfsg-1
ii libqtgui44:4.8.7+dfsg-1
ii libstdc++6 5.1.1-14
ii libx11-6 2:1.6.3-1
ii zlib1g 1:1.2.8.dfsg-2+b1
klipper recommends no packages.
klipper suggests no packages.
Bug#763697: mirror submission for ftp.slingshot.co.nz
Control: tag -1 +moreinfo Hello, Can you provide the available amount of bandwidth for this mirror? On Thu, 2 Oct 2014 22:16:49 +0200 Simon Paillard spaill...@debian.org wrote: Hi, On Wed, Oct 01, 2014 at 09:37:00PM +, CallPlus Network Operations wrote: Package: mirrors Severity: wishlist Submission-Type: new Site: ftp.slingshot.co.nz Thanks for mirroring Debian using the recommended tool. Type: leaf Archive-architecture: amd64 i386 Archive-ftp: /debian/ Archive-http: /debian/ IPv6: no Archive-upstream: ftp.citylink.co.nz Updates: four Country: NZ New Zealand Location: Auckland Sponsor: CallPlus http://www.callplus.co.nz/ How much bandwidth is available ? -- Simon Paillard Best regards, Donald Norwood signature.asc Description: OpenPGP digital signature
Bug#795924: ITP: r-cran-matrixmodels -- GNU R package for sparse and dense matrix models
Package: wnpp Owner: Dirk Eddelbuettel e...@debian.org Severity: wishlist * Package name: r-cran-matrixmodels Version : 0.4-0 Upstream Author : Douglas Bates and Martin Maechler * URL or Web page : https://cran.rstudio.com/web/packages/MatrixModels/index.html * License : GPL (= 2) Description : GNU R package for sparse and dense matrix models This package is now a dependency on the existing package r-cran-quantreg. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#795913: [rt.cpan.org #106498] Example workaround for existing apps
For reference to other users who may encounter this bug but cannot patch Mail::Thread itself, this is how I workaround the bug in the public-inbox project using monkey patching: http://public-inbox.org/meta/m/20150818-CPANRTBug106498-workaround%40v1.txt
Bug#795826: Bug#795835: epydoc: Please use (deterministic) sorting for module and class trees
On Mon, Aug 17, 2015 at 5:11 PM, Kenneth Pronovici prono...@ieee.org wrote: I'll apply both of these patches and upload sometime soon, hopefully within the next few days. I have both patches applied in my revision control, and I'll upload shortly. I've tested that nothing appears broken (i.e. my autopkgtest stuff still passes, and epydoc docs for my own software looks reasonable), but I'm not 100% sure how to test your changes. So, I'm assuming you'll tell me if something isn't working like you expect. Thanks, KEN -- Kenneth J. Pronovici prono...@debian.org
Bug#795927: ldapscripts: Please upload Debian package for 2.0.6 release
Package: ldapscripts Version: 2.0.5-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, Upstream author released a newer version (2.0.6) of the package with two important fixes necessary for FreedomBox use case. Please consider uploading the Debian package for 2.0.6. Thank you, - -- Sunil - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ldapscripts depends on: ii ldap-utils 2.4.40+dfsg-2 Versions of packages ldapscripts recommends: ii pwgen 2.07-1 ii sharutils 1:4.15.1-1 Versions of packages ldapscripts suggests: pn nslcd none - -- Configuration Files: /etc/ldapscripts/ldapscripts.passwd [Errno 13] Permission denied: u'/etc/ldapscripts/ldapscripts.passwd' - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJV0pwEAAoJEDbDYUQMm8lxkDYP/iJaPGWGBYBvzPxkxAkxFrrw EUOLsC6bqP/FLyDWo++gsVbIkjDCQINJtTai5pi1wrGTUFa17JgtmHK0AwxcNKZl uMX4V+xNSvhg49lLuLrSvIYU3vliq9jiQfa7gAC+JY3LtSkIkU2g/lQajgOhd1nJ 72myt/MvhTYiPqBl1upBWN9HYrVNGdEFIomlhRrzh29SeF/vTwXh5GEuwpdSCszm z0qIsLVsnKhqdu8kZArp0d/ZrmEyIZQ+a2FpPoQfJM46p8s5p1TTr6DPj21n4gun MNrf/Cw0JZ8jGP3QZGMPvBpVGysBpOZvm01l3Q9Ia5fviqoq/ABU6RcLKV9UA1cs 4x3iunpB4IO2r7E25qscHAuJAdMARZNutNdst5PjydiEg019x9z/IH9eiSzmsses hht96wjo5PkVvZtMYqaTca2MFGFNBUYtx8shjXJYAXGeHONiZADnsBtknk1XUoGO lNzC8ChMrkWEkv3t2G46sCfAtIgFTyB96jezpOBhY/txOCDSz1ppltrLDv/378Uw aQlKyuZrHWkKK6hc7lBUF63H/c+BxFVOwPpE6Fr9n7lS8855tMwd0ha3F1yyE2f2 Xjwrw6LW6xsmHRFnNtKTCEB4ZBL1cvDkVjVTwg4bEirBD3Pi6wg9qxCKJaZyqgI3 SY0ybIQf8rxTs72oHiqx =k08v -END PGP SIGNATURE-
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
Hi Charles, and thanks for your feedback, Le lundi, 17 août 2015, 21.25:59 Charles Plessy a écrit : I think that option D has two fundamental flaws and I would like to recommend the TC against voting for it. * First, if it is voted, nothing will happen. If the TC adopts option D, and if the maintainer (no plural) of the 'menu' package decides to not follow point 3's recommendation, what will be the practical difference between option D and option Z ? I disagree with this, because of the last sentence of D1, put in force using §6.1.1 (decide on any matter of technical policy): Applications providing a .desktop file should not provide a Debian menu file. This will allow maintainers that _do_ provide .desktop files to stop providing .menu files as well. I voiced this concern in 2014 (741573#450), but got no answer. Who do you expect to do the work ? Either the 'menu' maintainer and/or anyone sufficiently interested in keeping said system relevant. With D1 in place, I expect .menu files to start disappearing from the archive at a good pace; it will become somewhat urgent for those relying on the menu system to work towards having this .desktop-to-menu translation infrastructure in place. The reason I ask is that option D carries nothing new. In 2008, we already had a discussion which outcome was very similar to what is proposed in option D. https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries I think it is quite reasonable to assume that Keith's proposal is a derivative of that proposal. * Second, it does not solve the problem that I sumbitted to the TC. The TC is currently trying to decide whether to decide on the conflict (AB vs C) or to decide on the 'menu' matter of technical policy (D). I honestly think all 4 options would resolve the unresolvable conflict that you referred to the TC. See in particular Josselin's objection in 741573#405 and Keith's answer: One of the problems I have with your proposal, compared to Charles’ original patch, is that it encourages maintainers of hundreds of (IMHO useless) menu files to port them to the desktop format. I agree that the current proposition doesn't address this problem in D1, in that it says: packages for which the Debian menu system currently applies should provide a .desktop file One key word is currently in there. I think it is reasonable to read this as run 's/register a menu entry/provide a FreeDesktop .desktop file/g' over Policy §9.6. It would certainly not prevent further changes to §9.6 as long as the TC decision is respected. From what I understand of your opposition, you're afraid that further discussions around softening the all packages that provide applications that need not be passed any special command line arguments for normal operation should provide a FreeDesktop .desktop file entry for those application part would be met with unresolvable opposition from Bill, right? What about the following formulation then (not yet entirely convinced, but I hope that's a step forward)? 1. The Technical Committee resolves that applications providing a .desktop file should not provide a Debian menu file. This would delegate the decision on which applications are supposed to provide a .desktop file to (arguably yet another) the Debian Policy process. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#795917: libgtkmm-2.4-1c2a: transition needed for g++-5 ABI
Package: libgtkmm-2.4-1c2a
Version: 2.24.4-1.1
Severity: important
Tags: patch
gtkmm2.4 is yet another C++ package that needs a transition to the g++-5 ABI.
See the similar glibmm bug for all the tedious details.
Matthias' build logs mention, for instance,
00032ef0 gDF .text 0076 Base
Gdk::Pixbuf::save(std::__cxx11::basic_stringchar, std::char_traitschar,
std::allocatorchar const, Glib::ustring const)
This was blocked by starting both the cairomm and glibmm phases of the
transition, but that has now been done.
I have staged this in pkg-gnome svn, but not yet tested it (I need to get
far enough up the library stack to run gnome-system-monitor or something).
It is possible that atkmm1.6 and pangomm do not strictly need to transition,
but Matthias' recent mail to debian-devel mentions some concerns about
ABI breaks that are not automatically detected, and nothing seems to
build-depend on atkmm1.6 or pangomm without also depending on either gtkmm2.4
or gtkmm3.0 anyway; so everything that would be binNMU'd for an atk1.6 or
pangomm transition is going to have to be binNMU'd for a gtkmm2.4 or
gtkmm3.0 transition in any case. So we might as well do them all at once.
S
diffstat for gtkmm2.4-2.24.4 gtkmm2.4-2.24.4
changelog |8
control | 11 ++-
control.in|8 +---
libgtkmm-2.4-1c2a.install |1 -
libgtkmm-2.4-1v5.install |1 +
5 files changed, 20 insertions(+), 9 deletions(-)
diff -Nru gtkmm2.4-2.24.4/debian/changelog gtkmm2.4-2.24.4/debian/changelog
--- gtkmm2.4-2.24.4/debian/changelog 2014-08-28 20:31:21.0 +0100
+++ gtkmm2.4-2.24.4/debian/changelog 2015-08-17 22:26:36.0 +0100
@@ -1,3 +1,11 @@
+gtkmm2.4 (1:2.24.4-2) unstable; urgency=medium
+
+ * Team upload.
+ * Rename libgtkmm-2.4-1c2a to libgtkmm-2.4-1v5, for the
+libstdc++6 ABI transition. Based on a patch from Matthias Klose.
+
+ -- Simon McVittie s...@debian.org Mon, 17 Aug 2015 22:26:27 +0100
+
gtkmm2.4 (1:2.24.4-1.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru gtkmm2.4-2.24.4/debian/control gtkmm2.4-2.24.4/debian/control
--- gtkmm2.4-2.24.4/debian/control 2014-08-28 20:33:40.0 +0100
+++ gtkmm2.4-2.24.4/debian/control 2015-08-17 22:30:46.0 +0100
@@ -2,12 +2,11 @@
#
# Modifications should be made to debian/control.in instead.
# This file is regenerated automatically in the clean target.
-
Source: gtkmm2.4
Section: libs
Priority: optional
Maintainer: Deng Xiyue manphiz-gu...@users.alioth.debian.org
-Uploaders: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org, Emilio Pozuelo Monfort po...@debian.org, Mario Lang ml...@debian.org, Michael Biebl bi...@debian.org, Sebastian Dröge sl...@debian.org
+Uploaders: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org, Emilio Pozuelo Monfort po...@debian.org, Michael Biebl bi...@debian.org, Sebastian Dröge sl...@debian.org
Homepage: http://www.gtkmm.org/
Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/packages/unstable/gtkmm2.4
Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/packages/unstable/gtkmm2.4
@@ -28,7 +27,7 @@
Multi-Arch: same
Depends: ${misc:Depends},
${shlibs:Depends},
- libgtkmm-2.4-1c2a (= ${binary:Version}),
+ libgtkmm-2.4-1v5 (= ${binary:Version}),
libgtk2.0-dev (= 2.24.0),
libglibmm-2.4-dev (= 2.27.93),
libpangomm-1.4-dev (= 2.27.1),
@@ -44,13 +43,15 @@
This package contains development files and examples, as well as a gtkmm-demo
program.
-Package: libgtkmm-2.4-1c2a
+Package: libgtkmm-2.4-1v5
Section: libs
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends},
${shlibs:Depends}
+Breaks: libgtkmm-2.4-1c2a
+Replaces: libgtkmm-2.4-1c2a
Description: C++ wrappers for GTK+ (shared libraries)
Gtkmm is a C++ interface for the popular GUI library GTK+, with API version
2.4. Gtkmm provides a convenient interface for C++ programmers to create
@@ -67,7 +68,7 @@
Multi-Arch: same
Depends: ${misc:Depends},
${shlibs:Depends},
- libgtkmm-2.4-1c2a (= ${binary:Version})
+ libgtkmm-2.4-1v5 (= ${binary:Version})
Description: C++ wrappers for GTK+ (debug symbols)
Gtkmm is a C++ interface for the popular GUI library GTK+, with API version
2.4. Gtkmm provides a convenient interface for C++ programmers to create
diff -Nru gtkmm2.4-2.24.4/debian/control.in gtkmm2.4-2.24.4/debian/control.in
--- gtkmm2.4-2.24.4/debian/control.in 2014-08-28 20:32:01.0 +0100
+++ gtkmm2.4-2.24.4/debian/control.in 2015-08-17 22:26:16.0 +0100
@@ -23,7 +23,7 @@
Multi-Arch: same
Depends: ${misc:Depends},
${shlibs:Depends},
- libgtkmm-2.4-1c2a (= ${binary:Version}),
+ libgtkmm-2.4-1v5 (= ${binary:Version}),
libgtk2.0-dev (= 2.24.0),
libglibmm-2.4-dev (= 2.27.93),
libpangomm-1.4-dev
Bug#795922: libgstreamermm-1.0-0: transition needed for g++-5 ABI
Package: libgstreamermm-1.0-0 Version: 1.4.3+dfsg-3 Severity: important This is yet another C++ package that needs a transition to the g++-5 ABI. See the similar glibmm bug for full details. Matthias' build logs mention, for instance, 000e28d0 gDF .text 005c Base Gst::MessageError::create(Glib::RefPtrGst::Object const, Glib::Error, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const) Starting this was blocked by starting the libglibmm-2.4-1v5 transition, but that has now been done, so it can probably go ahead whenever. subtitleeditor appears to be the only reverse dependency. S
Bug#795925: gphoto2: Error (-7: 'I/O problem')
Package: gphoto2
Version: 2.5.8-2
Severity: important
Dear Maintainer,
This problem has only started resently, I was last able to get photos off of my
Canon EOS 1100D on the 3rd Aug 2015
$ mkdir -p ~/Pictures/digital-camera/`date +%Y`/`date +%F--%H.%M.%S` cd
~/Pictures/digital-camera/`date +%Y`/`date +%F--%H.%M.%S` gphoto2 --debug
--debug-logfile=my-logfile.txt --get-all-files
mkdir: created directory
‘/home/dale/Pictures/digital-camera/2015/2015-08-18--10.30.34’
*** Error ***
An error occurred in the io-library ('I/O problem'): No error description
available
*** Error (-7: 'I/O problem') ***
0.68 main(2): ALWAYS INCLUDE THE FOLLOWING LINES
WHEN SENDING DEBUG MESSAGES TO THE MAILING LIST:
0.95 main(2): gphoto2 2.5.8
0.000104 main(2): gphoto2 has been compiled with the
following options:
0.000111 main(2): + gcc (C compiler used)
0.000117 main(2): + popt (mandatory, for handling
command-line parameters)
0.000123 main(2): + exif (for displaying EXIF
information)
0.000128 main(2): + cdk (for accessing configuration
options)
0.000134 main(2): + aa (for displaying live previews)
0.000139 main(2): + jpeg (for displaying live previews
in JPEG format)
0.000145 main(2): + readline (for easy navigation in
the shell)
0.000156 main(2): libgphoto2 2.5.8
0.000164 main(2): libgphoto2 has been compiled with the
following options:
0.000170 main(2): + all camlibs
0.000175 main(2): + gcc (C compiler used)
0.000181 main(2): + ltdl (for portable loading of
camlibs)
0.000186 main(2): + EXIF (for special handling of EXIF
files)
0.000192 main(2): libgphoto2_port 0.12.0
0.000199 main(2): libgphoto2_port has been compiled
with the following options:
0.000206 main(2): + gcc (C compiler used)
0.000211 main(2): + ltdl (for portable loading of
camlibs)
0.000216 main(2): + USB (libusb1, for USB cameras)
0.000222 main(2): + serial (for serial cameras)
0.000227 main(2): + no resmgr (serial port access and
locking)
0.000232 main(2): + no ttylock (serial port locking)
0.000238 main(2): + no lockdev (serial port locking)
0.000243 main(2): CAMLIBS env var not set, using
compile-time default instead
0.000249 main(2): IOLIBS env var not set, using
compile-time default instead
0.000254 main(2): invoked with following arguments:
0.000260 main(2): --debug
0.000266 main(2): --debug-logfile=my-logfile.txt
0.000271 main(2): --get-all-files
0.000304 load_settings (2): Creating gphoto config directory
('/home/dale/.gphoto')
0.000344 load_settings (2): Loading settings from file
'/home/dale/.gphoto/settings'.
0.000492 main(2): The user has not specified both a
model and a port. Try to figure them out.
0.000503 gp_port_info_list_load (2): Using ltdl to load io-drivers from
'/usr/lib/x86_64-linux-gnu/libgphoto2_port/0.12.0'...
0.000573 foreach_func(2): Called for filename
'/usr/lib/x86_64-linux-gnu/libgphoto2_port/0.12.0/disk'.
0.000726 gp_port_library_list(2): found fstab fsname proc
0.000739 gp_port_library_list(2): found fstab fsname
UUID=396a3e8b-38fa-464d-b9f5-7fa70be876d3
0.000754 gp_port_library_list(2): found fstab fsname
UUID=2874ada4-52f7-4f1e-8740-9d00ee948d48
0.000769 gp_port_library_list(2): found fstab fsname
UUID=2a26fe59-1ba2-47d9-b5cb-c300a21515b4
0.000782 gp_port_library_list(2): found fstab fsname
UUID=7ff00cc7-cbf1-4363-b85c-19457576549c
0.000798 gp_port_library_list(2): found fstab fsname /dev/sdc1
0.000813 gp_port_library_list(2): found fstab fsname /dev/scd0
0.000828 gp_port_library_list(2): found fstab fsname /dev/sg0
0.000946 gp_port_library_list(2): found mtab fsname sysfs
0.000959 gp_port_library_list(2): found mtab fsname proc
0.000968 gp_port_library_list(2): found mtab fsname udev
0.000985 gp_port_library_list(2): found mtab fsname devpts
0.000999 gp_port_library_list(2): found mtab fsname tmpfs
0.001017 gp_port_library_list(2): found mtab fsname /dev/sda6
0.001027 gp_port_library_list(2): found mtab fsname tmpfs
0.001039 gp_port_library_list
Bug#795890: ori: FTBFS on non-Linux: UNSUPPORTED OS
On الإثنين 17 آب 2015 10:51, Aaron M. Ucko wrote: Source: ori Version: 0.8.1+ds1-1 Severity: important Justification: fails to build from source Builds of ori on kFreeBSD and the Hurd have been failing: public/oriutil/rwlock.h:33:2: error: #error UNSUPPORTED OS The problem appears to be that ori has a whitelist of supported Unix-like architectures: FreeBSD is even on that whitelist, strangely enough. https://anonscm.debian.org/cgit/users/afif-guest/ori.git/tree/public/oriutil/rwlock.h#n27 I'd suggest substituting __unix__, as every vaguely-modern Unixlike system should support pthreads. (Certainly, all Debian architectures do.) Could you please take a look? Will do. Thanks for your report Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#795915: please upload 0.8.3 to unstable
Package: python-smmap Version: 0.8.3-1 Severity: normal fresh release/snapshot of python-git needs updated/fixed version, so it would be nice to see 0.8.3 in unstable to progress forward. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-smmap depends on: ii python 2.7.9-1 python-smmap recommends no packages. Versions of packages python-smmap suggests: ii python-nose 1.3.6-1 -- no debconf information
Bug#793674: [Pkg-hhvm-team] Bug#793674: hhvm: leaves alternatives after purge: php - /usr/bin/hhvm
tags 793674 + pending thanks On 7/26/15 5:44 AM, Andreas Beckmann wrote: Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8: This has been fixed as of http://anonscm.debian.org/cgit/pkg-hhvm/hhvm.git/commit/?id=1b3b1f321b369747ca57c9ca7aef7a17d0a57b44 and it will be present in the next upload (hopefully when the dust due to the GCC5 transition settles). Ender. signature.asc Description: OpenPGP digital signature
Bug#795920: libglademm2.4-1c2a: transition needed for g++-5 ABI
Package: libglademm2.4-1c2a Version: 2.6.7-4 Severity: important glademm2.4 is yet another C++ package that needs a transition to the g++-5 ABI. See the similar glibmm bug for all the tedious details. Matthias' build logs mention, for instance, 5880 gDF .text 0055 Base Gnome::Glade::Xml::create(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const, Glib::ustring const, Glib::ustring const) Starting this is blocked by starting the equivalent gtkmm2.4 transition. I will probably stage this in pkg-gnome svn tomorrow. S
Bug#792649: the demangler is not aware of the __cxx11 symbols in GCC 5's libstdc++
On 8/14/15 4:37 PM, GUO Yixuan wrote: Hi, On Wed, Aug 12, 2015 at 10:23:05PM +0200, Matthias Klose wrote: Control: tags -1 + important ignoring the check for now. looks like the package is good enough to be used even with the test failing. There's a patch recently submitted on github, although it is not merged into the upstream repo. https://github.com/Jo-Con-El/glog/commit/b1639e3014996fbc7635870e013559c54e7e3b2f Yes, I submitted that, but they haven't merged it yet because I hadn't signed the CLA. I was waiting on getting internal permission and it's all cleared now. The patch leaves cxx11 symbols as |google::LogDestination::addresses_[cxx11] i.e. enclosed in square brackets. Ender. | signature.asc Description: OpenPGP digital signature
Bug#794718: Bug now resolved
The segfault was due to an old version of the extdata plugin on the system (which was manually compiled and installed). A new version has been installed and now functions correctly. See http://www.dovecot.org/list/dovecot/2015-August/101590.html It would be useful if the extdata plugin was available as a Debian package; I will submit a separate request for this.
Bug#795911: jessie-pu: package gtk+3.0/3.14.5-1+deb8u1
It looks like #748469 was fixed in upstream 3.16.5: http://ftp.gnome.org/pub/gnome/sources/gtk+/3.16/gtk+-3.16.5.changes and #773135 was fixed in 3.15.4 : http://ftp.acc.umu.se/pub/gnome/sources/gtk+/3.15/gtk+-3.15.4.changes Thanks Mert, The versions you mention were never uploaded to Debian. I found the relevant Debian version numbers and added them to the two bug reports. See: https://bugs.debian.org/773135 https://bugs.debian.org/787419 I hope it looks better now, Adam. I will remember to do this first the next time. Thanks! Cheers, Ruben signature.asc Description: Digital signature
Bug#795826: Bug#795835: epydoc: Please use (deterministic) sorting for module and class trees
Hi Val, I'll apply both of these patches and upload sometime soon, hopefully within the next few days. KEN
