Bug#901199: ITP: node-name-all-modules-plugin -- Names all remaining modules that do not get named via NamedModulesPlugin
Package: wnpp Severity: wishlist Owner: Apurva Pavaskar X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-name-all-modules-plugin Version : 1.0.1 Upstream Author : Tim Sebastian * URL : https://github.com/timse/name-all-modules-plugin#readme * License : Expat Programming Lang: JavaScript Description : Names all remaining modules that do not get named via NamedModulesPlugin . This is a plugin for webpack . Webpack takes code targeted at node.js and makes it run in the browser. Node.js comes with API of its own that is not available in the browsers. Webpack exposes this code to programs that are unaware they are running in a browser . Node.js is an event-based server-side JavaScript engine. This plugin is required for Gitlab. I want to maintain this package in Javascript team. Praveen has agreed to sponsor this package. Sent with ProtonMail Secure Email.
Bug#901198: git-buildpackage: create remote repo fails due wrong used submodul urllib
Package: git-buildpackage Version: 0.9.9 Severity: normal Hello Guido, I was trying to use 'gbp create-remote-repo' again after a long time but this was failing with a import error due the line 'import urllib' in create_remote_repo.py. $ gbp create-remote-repo --remote-url-pattern="g...@somewere.org:my-team/%(pkg)s" --remote-name=myrepo Traceback (most recent call last): File "/usr/bin/gbp", line 149, in sys.exit(supercommand()) File "/usr/bin/gbp", line 145, in supercommand return module.main(args) File "/usr/lib/python3/dist-packages/gbp/scripts/create_remote_repo.py", line 395, in main retval = do_create(options) File "/usr/lib/python3/dist-packages/gbp/scripts/create_remote_repo.py", line 317, in do_create options.bare) File "/usr/lib/python3/dist-packages/gbp/scripts/create_remote_repo.py", line 77, in parse_url frags = urllib.parse.urlparse(remote_url) AttributeError: module 'urllib' has no attribute 'parse' This happen because pyhton3-urllib3 is providing the parse submodul not automatically anymore and you need to import this submodul specifically. The added patch should correct the wanted behavior at least the create command is working then again. Regards Carsten -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git-buildpackage depends on: ii devscripts 2.18.3 ii git1:2.17.1-1 ii man-db 2.8.3-2 ii python33.6.5-3 ii python3-dateutil 2.6.1-1 ii python3-pkg-resources 39.1.0-1 Versions of packages git-buildpackage recommends: ii cowbuilder0.87+b1 ii pbuilder 0.229.2 ii pristine-tar 1.44 ii python3-requests 2.18.4-2 Versions of packages git-buildpackage suggests: pn python3-notify2 ii sudo 1.8.23-1 ii unzip6.0-21 -- no debconf information >From 91c88c99a908e5c67bcdf028a0cd9e5bbf9a4919 Mon Sep 17 00:00:00 2001 From: Carsten Schoenert Date: Sun, 10 Jun 2018 07:03:01 +0200 Subject: [PATCH] create_remote_repo: import urllib.parse Pyhon3 modul After the switch of git-buildpackage to Python3 the import of urllib (from python3-urllib3) is not automatic including the parse submodul anymore. Ipmorting the submodul directly is providing the needed functions now. --- gbp/scripts/create_remote_repo.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gbp/scripts/create_remote_repo.py b/gbp/scripts/create_remote_repo.py index b744c255..6c1ff7a0 100644 --- a/gbp/scripts/create_remote_repo.py +++ b/gbp/scripts/create_remote_repo.py @@ -20,7 +20,7 @@ import sys import os -import urllib +import urllib.parse import subprocess import tty import termios -- 2.17.1
Bug#901185: me too
On 2018-06-10 積丹尼 Dan Jacobson wrote: > Oops. I mean just: > Setting up exim4-config (4.91-5) ... > /etc/exim4/update-exim4.conf.conf: line 26: dc_eximconfig_configtype: command > not found Hello, Are you running bash (or other stuff) from experimental? IIRC there is some breakage there. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#635385: qemu-user-static should upgrade static libraries in qemu-debootstrap created chroots
On Tue, 26 Jul 2011 02:27:51 +0900 Emmet Hikory wrote: > When qemu-debootstrap is used to create an emulation chroot, it > copies a static library into the chroot for use by binfmt-misc. Recent qemu-user-static versions in sid now use the binfmt "fix binary" mode, which will allow qemu-debootstrap to stop copying the static binaries into the foreign-arch chroots. That would be another way to satisfy this issue, so this bug could be closed now. https://bugs.debian.org/901197 https://bugs.debian.org/868030 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#901197: qemu-debootstrap: don't copy qemu-*-static binaries into the chroot when binfmt "fix binary" mode is enabled
Package: qemu-user-static Version: 1:2.12+dfsg-3 Severity: normal File: /usr/sbin/qemu-debootstrap The binfmt "fix binary" mode was recently enabled for the qemu-user-static binfmt entries: https://bugs.debian.org/868030 qemu-debootstrap should check if it is enabled (in case the sysadmin deliberately or accidentally broke it or enabled it manually) and skip copying the qemu-*-static binaries into the chroot, since the foreign arch device will not need it and neither will the local device. It will only get outdated because it never gets updated: https://bugs.debian.org/635385 -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.1.8-2 Versions of packages qemu-user-static suggests: ii sudo 1.8.23-1 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#900545: dput: Emit error response body as a debug message
Control: retitle -1 dput: Emit the response body as a debug message, when HTTP error response Howdy, I have an implementation of this feature, that is awaiting review at https://salsa.debian.org/debian/dput/merge_requests/1>. -- \ “Natural catastrophes are rare, but they come often enough. We | `\ need not force the hand of nature.” —Carl Sagan, _Cosmos_, 1980 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#884891: closed by Michael Tokarev (Re: qemu-user-static: add a qemu-chroot script)
On Thu, 2018-06-07 at 12:51 +, Debian Bug Tracking System wrote: > Please take a look at #868030 - maybe this is sufficient for your needs? Looks perfect, since it means a normal chroot should work. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#901196: tmperamental: rebuild to include dbgsym package
Package: tmperamental Version: 1.0 Severity: wishlist I am getting some segfaults when running ls/cp and other things with tmperamental. It would be nice to have a dbgsym package so I can report bugs about the issues. Please rebuild the package with recent debhelper so that a dbgsym package is automatically created. https://wiki.debian.org/AutomaticDebugPackages $ tmperamental ls Segmentation fault (core dumped) $ tmperamental cp Segmentation fault (core dumped) -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tmperamental depends on: ii libc6 2.27-3 tmperamental recommends no packages. tmperamental suggests no packages. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#901185: me too
Oops. I mean just: Setting up exim4-config (4.91-5) ... /etc/exim4/update-exim4.conf.conf: line 26: dc_eximconfig_configtype: command not found
Bug#862166: tmperamental: support TMP, TEMP, TEMPDIR and program-specific variables
On Tue, 2018-06-05 at 19:29 +0200, Jakub Wilk wrote: > TMPDIR is specified by POSIX; the other variable names are non-standard. > If a program supports TMP or TEMP or ... but not TMPDIR, then that's a > bug that should be fixed. Some of them are standard on non-POSIX platforms like Windows. > libtmperamental wouldn't be able to catch such bugs if these > non-standard variables were set. I think the best solution here would be for tmperamental to set each variable to a different directory and then warn about use of each of the directories for non-POSIX variables, with an option to also blow up for uses of the non-POSIX variables. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#901185: me too
Setting up exim4-config (4.91-5) ... /var/lib/dpkg/info/exim4-config.postinst: line 330: export: `dc_eximconfig_configtype dc_other_hostnames dc_local_interfaces dc_readhost dc_relay_domains dc_minimaldns dc_relay_nets dc_smarthost CFILEMODE dc_use_split_config dc_hide_mailname dc_mailname_in_oh dc_localdelivery': not a valid identifier dpkg: error processing package exim4-config (--configure):
Bug#157299:
Bug#896295: Tensorflow is missing
Hello Debian-Science folks, Please feel free to CC me if you need any input about deep learning. > From: Andreas Tille > the description says: > > ... Alternatively, Keras could run on Google's > TensorFlow (not yet available in Debian, but coming up). > > Is there some estimated time frame to package TensorFlow? No estimated time frame for it. TensorFlow provides bazel build for linux and cmake build for windows. Bazel itself is blocking for years, and a DD, Paul Liu, who worked on it in the past had said that it was hard to deal with. I guess the bazel build system is still blocking currently. > If not please try to deactivate this alternative since the package does > not work as this bug report explains. I'd suggest patching upstream source to use Theano as the default backend, and comment it clearly in the descriptions. > From: Stephen Sinclair > Regarding Tensorflow packaging I do not know, someone on debian-science > mentioned difficulties with its build system. I do hope these are > resolvable but it seems to be a big issue. That so-called "someone" was me, actually. Bazel build is actually a big issue, and I have no plan to patch the windows cmake build in a reasonable time frame. You may have found that Debian-team holds a tensorflow repo on Salsa, but that's merely an old copy of upstream code. https://salsa.debian.org/science-team/tensorflow I'm currently maintaing several TensorFlow dependencies. Hope that They will be helpful sometime in the future. farmhash gemmlowp highwayhash The full list of dependency can be found in the third_part directory of tensorflow source.
Bug#901195: tracker.debian.org: linkify bugs in testing removal news items
Package: tracker.debian.org Severity: wishlist Tags: newcomer It would be nice if the news item display could turn Debian bug numbers in testing removal emails into links to Debian bugs. Being able to click the bug link instead of manually writing the URL would be faster. For example: https://tracker.debian.org/news/943250/mysql-workbench-removed-from-testing/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#901194: jessie-pu: package openldap/2.4.40+dfsg-1+deb8u4
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Dear OSRM,
Please consider this openldap update for jessie. I apologize for the
late request and will understand if it doesn't make it.
* Fix upgrade failure when olcSuffix contains a backslash. (Closes: #864719)
I would like to apply this fix in jessie to ensure that if openldap gets
a security update during jessie LTS, affected systems will be able to
install it. As well there may be some users who choose to upgrade from
wheezy after its LTS ends. I have tested both upgrade scenarios
(jessie->jessie and wheezy->jessie).
For avoidance of doubt: this includes the changes also proposed for
stretch in #901192 (the affected code is always executed in
wheezy->jessie upgrades).
* Import upstream patches to fix memory corruption caused by calling
sasl_client_init() multiple times and possibly concurrently.
(ITS#8648) (Closes: #860947)
This issue affected several slapd users and came with a variety of
symptoms. A typical example of an affected setup would be a multi-master
setup where replication is authenticated using Kerberos (SASL/GSSAPI).
These patches have been applied in stretch (in +deb9u1) and in Ubuntu
xenial, with no regressions reported.
thanks,
Ryan
-- System Information:
Debian Release: 9.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u openldap-2.4.40+dfsg/debian/changelog
openldap-2.4.40+dfsg/debian/changelog
--- openldap-2.4.40+dfsg/debian/changelog
+++ openldap-2.4.40+dfsg/debian/changelog
@@ -1,3 +1,12 @@
+openldap (2.4.40+dfsg-1+deb8u4) jessie; urgency=medium
+
+ * Fix upgrade failure when olcSuffix contains a backslash. (Closes: #864719)
+ * Import upstream patches to fix memory corruption caused by calling
+sasl_client_init() multiple times and possibly concurrently.
+(ITS#8648) (Closes: #860947)
+
+ -- Ryan Tandy Tue, 05 Jun 2018 20:16:25 -0700
+
openldap (2.4.40+dfsg-1+deb8u3) jessie-security; urgency=high
* debian/patches/ITS-8655-paged-results-double-free.patch: Fix a double free
diff -u openldap-2.4.40+dfsg/debian/patches/series
openldap-2.4.40+dfsg/debian/patches/series
--- openldap-2.4.40+dfsg/debian/patches/series
+++ openldap-2.4.40+dfsg/debian/patches/series
@@ -29,0 +30,2 @@
+ITS-8648-check-result-of-ldap_int_initialize-in-ldap.patch
+ITS-8648-init-SASL-library-in-global-init.patch
diff -u openldap-2.4.40+dfsg/debian/slapd.scripts-common
openldap-2.4.40+dfsg/debian/slapd.scripts-common
--- openldap-2.4.40+dfsg/debian/slapd.scripts-common
+++ openldap-2.4.40+dfsg/debian/slapd.scripts-common
@@ -100,7 +100,7 @@
}
# }}}
update_databases_permissions() { # {{{
- get_suffix | while read suffix; do
+ get_suffix | while read -r suffix; do
dbdir=`get_directory "$suffix"`
update_permissions "$dbdir"
done
@@ -163,11 +163,11 @@
dir=`database_dumping_destdir`
echo >&2 " Dumping to $dir: "
- (get_suffix | while read suffix; do
+ (get_suffix | while read -r suffix; do
dbdir=`get_directory "$suffix"`
if [ -n "$dbdir" ]; then
file="$dir/$suffix.ldif"
- echo -n " - directory $suffix... " >&2
+ printf ' - directory %s... ' "$suffix" >&2
# Need to support slapd.d migration from preinst
if [ -f "${SLAPD_CONF}" ]; then
slapcat_opts="-g -f ${SLAPD_CONF}"
@@ -194,7 +194,7 @@
dir=`database_dumping_destdir`
echo >&2 " Loading from $dir: "
- get_suffix | while read suffix; do
+ get_suffix | while read -r suffix; do
dbdir=`get_directory "$suffix"`
if [ -z "$dbdir" ]; then
continue
@@ -206,11 +206,11 @@
fi
file="$dir/$suffix.ldif"
- echo -n " - directory $suffix... " >&2
+ printf ' - directory %s... ' "$suffix" >&2
# If there is an old DB_CONFIG file, restore it before
# running slapadd
- backupdir=`compute_backup_path -n "$dbdir" "$suffix"`
+ backupdir="$(compute_backup_path -n "$dbdir" "$suffix")"
if [ -e "$backupdir"/DB_CONFIG ]; then
cp -a "$backupdir"/DB_CONFIG "$dbdir"/
fi
@@ -249,7 +249,7 @@
# }}}
move_incompatible_databases_away() { # {{{
echo >&2 " Moving old database directories to /var/backups:"
-
Bug#795021: DDPO: Filter out packages with no version >= testing?
On Saturday, June 9, 2018 1:38:43 PM CDT Christoph Berg wrote: > > In the DDPO display, I have some packages that have been removed from > > unstable and testing, but remain in stable, oldstable, etc. I'd like > > to filter these out from the display. > > In the Display Configuration, I set the "Version" flag to "testing and > > newer" thinking it would do the trick. It removes the columns related > > to other versions. But all packages remain listed, even if the > > package has no version in testing and newer. > > > > Can you either modify the filtering of "Version" or add some way > > to achive my goal? > > I tweaked the Version setting some time ago to do exactly that. Please > let me know if there's anything missing. It's perfect. Works just as I would expect. Thank you! -Steve
Bug#901003: There is no standard way of removing transitional / dummy packages
Control: clone -1 -2 Control: reassign -2 release-notes On Fri, 2018-06-08 at 16:42 +0100, Sean Whitton wrote: > Hello Ben, > > On Fri, Jun 08 2018, Ben Hutchings wrote: > > > Reassigning this to debian-handbook, which doesn't seem to say > > anything about this currently. > > Perhaps a better location would be the upgrading chapter of the release > notes? [1] > > That includes various things that one can do to clean up your system > after the upgrade; removing transitional packages would seem like a good > thing to do at that point. > > [1] > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#for-next That would also be a good place. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
Bug#862030: jessie-pu: package rar/2:4.2.0+dfsg.1-0.1
On Fri, 2018-06-08 at 21:39 +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Fri, 2017-11-24 at 17:14 +, Ben Hutchings wrote: > > On Tue, 2017-06-27 at 22:55 +0200, Cyril Brulebois wrote: > > > Control: tag -1 moreinfo > > > > > > Ben Hutchings (2017-05-07): > > > > rar should be updated to fix #860952. > > > > > > > > The orig tarballs need to be repacked to exclude > > > > rar_static. Then I > > > > would apply the following source patch: > > > > > > ... > > > Based on the last line of context and the first line of the diff > > > (marked > > > with <=== above), I'm not sure whether you plan to remove > > > default.sfx > > > along with it, since the previous line still mentions it, and the > > > rules > > > file as well, see below. > > > > That was intentional, although I forgot to mention it. default.sfx > > hasn't been statically linked since (I think) version 3.9.3-1. > > > > Please go ahead; apologies for the long delay. Done. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
Bug#901192: stretch-pu: package openldap/2.4.44+dfsg-5+deb9u2
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Dear SRM, Please consider this openldap update for stretch. I apologize for the late request and will understand if it doesn't make it. Both fixes have already had some time in testing and stretch-backports. * Import upstream patch to fix an out-of-sync issue with delta-syncrepl replication in multi-master environments, resulting from changes losing tracking information and being applied multiple times. (ITS#8) (Closes: #877166) This issue impacts replication when the memberof overlay is used in a multi-master setup. Sven Mäder (in X-D-CC) has tested the proposed package on a stretch system and verified the fix. * Really fix upgrades when the config contains backslash-escaped special characters. The previous fix was incomplete and didn't fully fix upgrades involving a database reload. (Closes: #864719) The first part of this, fixing simple upgrades that don't require a database reload, is already in stretch (as +deb9u1). This additional patch deals with code that is not executed in a typical upgrade but might be triggered based on the old version or the debconf settings. thanks, Ryan -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru openldap-2.4.44+dfsg/debian/changelog openldap-2.4.44+dfsg/debian/changelog --- openldap-2.4.44+dfsg/debian/changelog 2017-08-10 12:12:46.0 -0700 +++ openldap-2.4.44+dfsg/debian/changelog 2018-05-22 21:25:19.0 -0700 @@ -1,3 +1,15 @@ +openldap (2.4.44+dfsg-5+deb9u2) stretch; urgency=medium + + * Import upstream patch to fix an out-of-sync issue with delta-syncrepl +replication in multi-master environments, resulting from changes losing +tracking information and being applied multiple times. +(ITS#8444) (Closes: #877166) + * Really fix upgrades when the config contains backslash-escaped special +characters. The previous fix was incomplete and didn't fully fix upgrades +involving a database reload. (Closes: #864719) + + -- Ryan Tandy Tue, 22 May 2018 21:25:19 -0700 + openldap (2.4.44+dfsg-5+deb9u1) stretch; urgency=medium * Relax the dependency of libldap-2.4-2 on libldap-common to also permit diff -Nru openldap-2.4.44+dfsg/debian/patches/ITS-8444-Do-not-clear-the-pending-operation-when-che.patch openldap-2.4.44+dfsg/debian/patches/ITS-8444-Do-not-clear-the-pending-operation-when-che.patch --- openldap-2.4.44+dfsg/debian/patches/ITS-8444-Do-not-clear-the-pending-operation-when-che.patch 1969-12-31 16:00:00.0 -0800 +++ openldap-2.4.44+dfsg/debian/patches/ITS-8444-Do-not-clear-the-pending-operation-when-che.patch 2018-05-22 21:25:19.0 -0700 @@ -0,0 +1,30 @@ +From bb6438fb7ae32a622f456af8c4c9b8d479d5b209 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ond=C5=99ej=20Kuzn=C3=ADk?= +Date: Fri, 25 Aug 2017 16:25:23 +0100 +Subject: [PATCH] ITS#8444 Do not clear the pending operation when + checkpointing + +When a checkpoint happens, if we remove the CSN from the pending list, +accesslog won't pass it onto the accesslog DB. But in a delta-mmr +scenario, an accesslog entry without a CSN faces a race where it might +be applied twice - that usually fails and causes a full refresh, other +times it can cause a silent desync - both are undesirable. +--- + servers/slapd/overlays/syncprov.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c +index 3e7667336..4c2d939d4 100644 +--- a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c +@@ -1494,6 +1494,7 @@ syncprov_checkpoint( Operation *op, slap_overinst *on ) + opm.o_bd->bd_info = on->on_info->oi_orig; + opm.o_managedsait = SLAP_CONTROL_NONCRITICAL; + opm.o_no_schema_check = 1; ++ opm.o_opid = -1; + opm.o_bd->be_modify( , ); + + if ( rsm.sr_err == LDAP_NO_SUCH_OBJECT && +-- +2.11.0 + diff -Nru openldap-2.4.44+dfsg/debian/patches/series openldap-2.4.44+dfsg/debian/patches/series --- openldap-2.4.44+dfsg/debian/patches/series 2017-08-09 22:07:34.0 -0700 +++ openldap-2.4.44+dfsg/debian/patches/series 2018-05-22 21:25:19.0 -0700 @@ -31,3 +31,4 @@ ITS-8432-fix-infinite-looping-mods-in-delta-mmr.patch ITS-8648-check-result-of-ldap_int_initialize-in-ldap.patch ITS-8648-init-SASL-library-in-global-init.patch +ITS-8444-Do-not-clear-the-pending-operation-when-che.patch diff -Nru openldap-2.4.44+dfsg/debian/slapd.scripts-common
Bug#901191: libfabric-bin: missing Breaks+Replaces: libfabric1 (<< 1.6)
Package: libfabric-bin Version: 1.6.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Selecting previously unselected package libfabric-bin. Preparing to unpack .../libfabric-bin_1.6.1-1_amd64.deb ... Unpacking libfabric-bin (1.6.1-1) ... dpkg: error processing archive /var/cache/apt/archives/libfabric-bin_1.6.1-1_amd64.deb (--unpack): trying to overwrite '/usr/bin/fi_info', which is also in package libfabric1 1.5.3-1 Errors were encountered while processing: /var/cache/apt/archives/libfabric-bin_1.6.1-1_amd64.deb cheers, Andreas libfabric1=1.5.3-1_libfabric-bin=1.6.1-1.log.gz Description: application/gzip
Bug#901190: libcob4-dev: removal of libcob4-dev makes files disappear from libcob1-dev
Package: libcob4-dev Version: 2.2-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts replaces-without-breaks Hi, during a test with piuparts and DOSE tools I noticed your package causes removal of files that also belong to another package. This is caused by using Replaces without corresponding Breaks. The installation sequence to reproduce this problem is apt-get install libcob1-dev # (1) apt-get install libcob4-dev apt-get remove libcob4-dev # (2) The list of installed files at points (1) and (2) should be identical, but the following files have disappeared: /usr/include/libcob.h /usr/include/libcob/common.h /usr/include/libcob/exception.def This is a serious bug violating policy 7.6, see https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces and also see the footnote that describes this incorrect behavior https://www.debian.org/doc/debian-policy/ (old: footnotes.html#f53) [footnote permalink broken (#879048), search for /To see why/] The libcob4-dev package has the following relationships with libcob1-dev: Conflicts: n/a Breaks:n/a Replaces: libcob1-dev >From the attached log (scroll to the bottom...): 0m19.8s ERROR: FAIL: After purging files have disappeared: /usr/include/libcob.h owned by: libcob4-dev /usr/include/libcob/common.h owned by: libcob4-dev /usr/include/libcob/exception.def owned by: libcob4-dev 0m19.8s ERROR: FAIL: After purging files have been modified: /var/lib/dpkg/info/libcob1-dev.listnot owned cheers, Andreas libcob1-dev=1.1-2+b2_libcob4-dev=2.2-1.log.gz Description: application/gzip
Bug#901189: timidity,timidity-el: both packages ship the manpages
Package: timidity,timidity-el Version: 2.14.0-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): Selecting previously unselected package timidity-el. Preparing to unpack .../timidity-el_2.14.0-2_all.deb ... Unpacking timidity-el (2.14.0-2) ... dpkg: error processing archive /var/cache/apt/archives/timidity-el_2.14.0-2_all.deb (--unpack): trying to overwrite '/usr/share/man/ja/man1/timidity.1.gz', which is also in package timidity 2.14.0-2 Errors were encountered while processing: /var/cache/apt/archives/timidity-el_2.14.0-2_all.deb The following files are shipped by both packages: usr/share/man/ja/man1/timidity.1.gz usr/share/man/ja/man5/timidity.cfg.5.gz usr/share/man/man1/timidity.1.gz usr/share/man/man5/timidity.cfg.5.gz cheers, Andreas timidity=2.14.0-2_timidity-el=2.14.0-2.log.gz Description: application/gzip
Bug#901188: utils.py: Make the line "Dear Maintainer" more specific
Package: reportbug Version: 7.1.10 Severity: minor Make the line "Dear Maintainer" more specific and mention what distribution is meant, for example by using "Dear Debian maintainer". This line is in the file "/usr/lib/python3/dist-packages/reportbug/utils.py". See an answer to the bug #893444, "mandoc.1: Some fixes in the manual" (package "mandoc") for a reason for this additional information. -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.88-1-u1 (SMP w/2 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages reportbug depends on: ii apt1.6.1 ii python33.6.5-3 ii python3-reportbug 7.1.10 ii sensible-utils 0.0.12 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn dlocate pn emacs24-bin-common | emacs25-bin-common ii exim4 4.91-4 ii exim4-daemon-light [mail-transport-agent] 4.91-4 ii file 1:5.33-2 pn gir1.2-gtk-3.0 pn gir1.2-vte-2.91 ii gnupg 2.2.7-1 pn python3-gi pn python3-gi-cairo pn python3-gtkspellcheck pn python3-urwid ii xdg-utils 1.1.3-1 Versions of packages python3-reportbug depends on: ii apt1.6.1 ii file 1:5.33-2 ii python33.6.5-3 ii python3-apt1.6.1 ii python3-debian 0.1.32 ii python3-debianbts 2.7.2 ii python3-requests 2.18.4-2 python3-reportbug suggests no packages. -- no debconf information -- Bjarni I. Gislason
Bug#900994: [www.debian.org] Issues with the diff links in the translator dashboards (https://www.debian.org/devel/website/stats/xx)
Hi again I just noticed that the English dashboard shows a different table including "git diff" command lines: https://www.debian.org/devel/website/stats/en.en.html I'm not sure why it's English different than the other languages. I have looked at the stattrans.pl code: https://salsa.debian.org/webmaster-team/webwml/blob/master/stattrans.pl but I couldn't arrive to any conclusion. Kind regards, -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Bug#901187: Please drop explicit dependency against systemd
Package: iio-sensor-proxy Version: 2.4-2 Severity: normal Hi, iio-sensor-proxy has an explicit dependency against systemd, but that seems to be useless. systemd package doesn't garantee that you have systemd running as PID1. Kind regards, Laurent Bigonville -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages iio-sensor-proxy depends on: ii libc6 2.27-3 ii libglib2.0-02.56.1-2 ii libgudev-1.0-0 232-2 ii systemd 238-5 iio-sensor-proxy recommends no packages. iio-sensor-proxy suggests no packages. -- no debconf information
Bug#901185: exim4-config: fails to install
Control: tags -1 + moreinfo On Sun, 2018-06-10 at 00:17 +0200, Eric Valette wrote: > Paramétrage de exim4-config (4.91-5) ... > /etc/exim4/update-exim4.conf.conf: ligne 32: dc_eximconfig_configtype > : commande introuvable > /etc/exim4/update-exim4.conf.conf: ligne 32: dc_eximconfig_configtype > : commande introuvable > That doesn't make huge amounts of sense, at least at first glance. update-exim4.conf, which is what will be being called here, sources update-exim4.conf.conf, but that shouldn't be leading to "command not found" errors. The mention of line 32 is also interesting, as the standard file appears to be 31 lines long. Could you share the content of the file on the relevant machine, please? Regards, Adam
Bug#899006: stretch-pu: package intel-microcode/3.20180425.1~deb9u1
Control: tags -1 + confirmed On Fri, 2018-05-18 at 10:32 -0300, Henrique de Moraes Holschuh wrote: > I'd like to update the intel-microcode package in Debian stretch. > > This update adds the microcode-side fix for CVE-2017-5715 aka Spectre > v2. > Please go ahead. Regards, Adam
Bug#901186: RFP: node-esquery -- ECMAScript AST query library
Package: wnpp Severity: wishlist * Package name: node-esquery Version : 1.0.0 Upstream Author : Michael Ficarra * URL : https://notabug.org/themusicgod1/esquery * License : BSD-3-Clause Programming Lang: javascript Description : ECMAScript AST query library ESQuery is a library for querying the AST output by Esprima for patterns of syntax using a CSS style selector system. Demo: https://estools.github.io/esquery/
Bug#884229: 500 Internal Server Error for packages in experimental suite
Dear maintainers, server administrators and web masters, a couple of weeks ago package sites from experimental suite started to fail opening with error 500 Internal Server Error. Because this failure is not temporary anymore but became unfortunately stable, I'd like to ask you to check the situation. Thanks, Andrey
Bug#888561: jessie-pu: package nvidia-graphics-modules/340.106+3.16.0+1
On 2018-06-09 21:05, Adam D. Barratt wrote: > Unfortunately I missed the fact that the upload had ended up in NEW due > to the kernel ABI change, and dak will no longer accept it because: I could just rebuild ist in a current jessie-pu environment ... but given the fact that this will be the final jessie point release, it's probably better to RM the package, as it will probably not be updatable within LTS. There is already #894123 for that. I also don't plan to provide it via backports. Andreas
Bug#551006: Delivery In Progress
Open Attached File for details Este mensaje y los ficheros adjuntos pueden contener información confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente y pueden estar protegidos por secreto profesional. Si usted recibe este correo electrónico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Diputación de Málaga no se hace responsable por su contenido. Su contenido no constituye ningún compromiso para la Diputación de Málaga, salvo ratificación escrita por ambas partes. Aunque se esfuerza al máximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no será responsable de cualesquiera daños que puedan resultar de una transmisión de virus. This e-mail and the documents attached are confidential and intended solely for the addressess it may also be privileged. If you receive this e-mail in error, please no tify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, Diputacion de Malaga liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. OpenFile.rtf Description: Binary data
Bug#901185: exim4-config: fails to install
Package: exim4-config Version: 4.91-5 Severity: grave Justification: renders package unusable apt-get -f install Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait 0 mis à jour, 0 nouvellement installés, 0 à enlever et 2 non mis à jour. 4 partiellement installés ou enlevés. Après cette opération, 0 o d'espace disque supplémentaires seront utilisés. Paramétrage de exim4-config (4.91-5) ... /etc/exim4/update-exim4.conf.conf: ligne 32: dc_eximconfig_configtype : commande introuvable /etc/exim4/update-exim4.conf.conf: ligne 32: dc_eximconfig_configtype : commande introuvable dpkg: erreur de traitement du paquet exim4-config (--configure) : installed exim4-config package post-installation script subprocess returned error exit status 127 dpkg: des problèmes de dépendances empêchent la configuration de exim4-base : exim4-base dépend de exim4-config (>= 4.82) | exim4-config-2 ; cependant : Le paquet exim4-config n'est pas encore configuré. Le paquet exim4-config-2 n'est pas installé. Le paquet exim4-config qui fournit exim4-config-2 n'est pas encore configuré. dpkg: erreur de traitement du paquet exim4-base (--configure) : problèmes de dépendances - laissé non configuré dpkg: des problèmes de dépendances empêchent la configuration de exim4 : exim4 dépend de exim4-base (>= 4.91-5) ; cependant : Le paquet exim4-base n'est pas encore configuré. exim4 dépend de exim4-base (<< 4.91-5.1) ; cependant : Le paquet exim4-base n'est pas encore configuré. -- Package-specific info: Exim version 4.91 #4 built 09-Jun-2018 16:10:39 Copyright (c) University of Cambridge, 1995 - 2018 (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018 Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC Event OCSP PRDR SOCKS TCP_Fast_Open Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Configure owner: 0:0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.48 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages exim4-config depends on: ii adduser3.117 ii debconf [debconf-2.0] 1.5.66 exim4-config recommends no packages. exim4-config suggests no packages. -- Configuration Files: /etc/exim4/passwd.client [Errno 13] Permission non accordée: '/etc/exim4/passwd.client' -- debconf information excluded
Bug#636184: #636184: some values
On Sat, Jun 09, 2018 at 10:40:05AM -0400, Philippe Cloutier wrote: > Thank you Adam, > I like your proposal, but have a few comments below. > > First, "It has been since greatly outpaced" is odd when we don't > specify a time. Any new entrants are not going to be worse on the size-vs-speed graph, thus such statement won't become untrue in the future, and that's why naming a specific time seems pointless to me. > I think it would indeed be relevant to mention that bzip2 was developed > between 1996 and 2000 (for machines with very limited RAM). While especially xz can take enormous amounts of RAM, on levels where they provide slightly better compression ratio than bzip2 they actually need less RAM, both for compressing and decompressing. Thus, memory use is not an advantage of bzip2. > Second, there's a typo in "Thus, bzip2 shouldn't in be used in new > designs, although you want it available to access historic data.", and > it's a little simplistic, and perhaps a little strong, since there > might be cases for which bzip2 is superior to all alternatives. I think that's a true statement. With most algorithms supporting multiple levels, you can't speak about a single size-to-speed number but have to measure the whole envelope at all supported levels, for various types of files. It's rare for an algorithm to be outclassed on its entire range -- even lzop has cases when it wins with zstd, but as far as I can tell this is indeed the case for bzip2. I'm stopping short at "strictly inferior" as it's possible one may construct a file which bzip2 processes miraculously fast, but I know of no real-world file type where bzip2 would win. > I would favor "Thus, bzip2 should unlikely be used when there is no > compatibility concern (for example, to decompress data previously > compressed in bzip2's format).". > > Finally, the existing description is problematic because it's based on > tests which were once valid, but which are outdated. I am extremely > far from being an expert of compression, but I am afraid that the > proposal may be also somewhat over-reliant on different tests. I have > no doubt that zstd was much better with the file you used for testing, > but giving these numbers based on a single file is generalizing from > little. I think it's very useful to provide data on performance, but > unless a comprehensive comparison was made, I would still prefer > providing no or little data to providing data which is inexact or > which gets outdated. I used a single data point as I'm more inclined to believe what I see with my own eyes, but there are many comprehensive comparisons available on the Net. If you don't want specific numbers, something like "several times as fast" could be good. New research goes on, and in another decade or two we'll be talking about replacing xz and zstd -- but bzip2's time is over. Let's see what its author comes with next -- I don't think he said his last word. > Le mar. 5 juin 2018 à 15:45, Adam Borowski a écrit : > > > The extended description says of bzip2: > > > > > > > It typically compresses files to within 10% to 15% of the best available > > > > techniques, whilst being around twice as fast at compression and six > > > > times faster at decompression. > > bzip2 is a freely available, patent free, data compressor. It has been > > since greatly outpaced by newer alternatives, for example zstd at > > equivalent shrinking ratio compresses thrice as fast while decompressing > > nearly 15 times faster than bzip2. Thus, bzip2 shouldn't in be used in > > new designs, although you want it available to access historic data. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal).
Bug#901184: ITP: libedlib -- library for sequence alignment using edit distance
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: libedlib
Version : 1.2.3
Upstream Author : Martin Šošić
* URL : https://github.com/Martinsos/edlib
* License : MIT
Programming Lang: C
Description : library for sequence alignment using edit distance
A lightweight and super fast C/C++ library for sequence alignment using
edit distance.
.
Calculating edit distance of two strings is as simple as:
.
edlibAlign("hello", 5, "world!", 6,
edlibDefaultAlignConfig()).editDistance;
Features
.
* Calculates edit distance (Levehnstein distance).
* It can find optimal alignment path (instructions how to transform
first sequence into the second sequence).
* It can find just the start and/or end locations of alignment path -
can be useful when speed is more important than having exact
alignment path.
* Supports multiple alignment methods: global(NW), prefix(SHW) and
infix(HW), each of them useful for different scenarios.
* You can extend character equality definition, enabling you to e.g.
have wildcard characters, to have case insensitive alignment or to
work with degenerate nucleotides.
* It can easily handle small or very large sequences, even when finding
alignment path, while consuming very little memory.
* Super fast thanks to Myers's bit-vector algorithm.
.
This package contains the shared library.
Remark: This package is maintained by Debian Med Packaging Team at
https://salsa.debian.org/med-team/libedlib-dev
It is a precondition for racon (#890187)
Bug#901183: RFP: node-es6-promisify -- Convert callback-based javascript to ES6 Promises
Package: wnpp Severity: wishlist * Package name: node-es6-promisify Version : 5.0.0 Upstream Author : Mike Hall * URL : https://notabug.org/themusicgod1/es6-promisify * License : MIT Programming Lang: javascript Description : Convert callback-based javascript to ES6 Promises Converts callback-based functions to ES6/ES2015 Promises, using a boilerplate callback function.
Bug#901182: RFP: node-agent-base -- Turn a function into an http.Agent instance
Package: wnpp Severity: wishlist * Package name: node-agent-base Version : 4.2.0 Upstream Author : Nathan Rajlich * URL : https://notabug.org/themusicgod1/node-agent-base * License : MIT Programming Lang: javascript Description : Turn a function into an http.Agent instance This module provides an http.Agent generator. That is, you pass it an async callback function, and it returns a new http.Agent instance that will invoke the given callback function when sending outbound HTTP requests.
Bug#901082: libpgobject-type-json-perl: FTBFS with Perl 5.28: t/02-serialization.t failure
On Sat, Jun 09, 2018 at 10:14:22AM +0300, Niko Tyni wrote: > On Fri, Jun 08, 2018 at 11:14:35PM +0200, gregor herrmann wrote: > > On Fri, 08 Jun 2018 21:38:12 +0300, Niko Tyni wrote: > > > > > Source: libpgobject-type-json-perl > > > Version: 2.01-1 > > > Severity: important > > > User: debian-p...@lists.debian.org > > > Usertags: perl-5.28-transition > > > > > > This package fails to build with Perl 5.28 (currently in experimental.) > > > > > > > > > http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libpgobject-type-json-perl_2.01-1/libpgobject-type-json-perl_2.01-1_amd64-2018-06-08T17:55:53Z.build > > > > > > # Failed test 'Literal serializes correctly' > > > # at t/02-serialization.t line 49. > > > # got: '123' > > > # expected: '"123"' > > > # Looks like you failed 1 test of 23. > > > > > > I don't see an upstream bug or a failing CPAN test report > > > but it fails consistently for me. > > > > I can confirm the failure with 5.28, and it still passes the tests > > with 5.26. > > > > No idea which JSON thing in which part adds/removes the quotation > > marks. All I can think of is the different version of JSON::PP but > > then the problem should show up elsewhere as well. > > It's indeed to do with JSON::PP and not specific to Perl 5.28. > > Reduced to > > perl -MJSON::PP -le '$p=123; "". $p; print > JSON::PP->new->allow_nonref->encode($p)' > > which gives the string "123" on older versions of JSON::PP and the number 123 > on newer ones (at least 2.97001-1). This bisects to https://github.com/makamaka/JSON-PP/commit/87bd6a49bacc3a2634cbb1dd0ce9cc75675bb524 and I've filed https://github.com/makamaka/JSON-PP/issues/39 about it. Not sure yet if it's a bug or if others need to adapt. -- Niko Tyni nt...@debian.org
Bug#900920: stretch-pu: package freedink-dfarc/3.12-1+deb9u1
On 09/06/2018 22:29, Adam D. Barratt wrote: > On Fri, 2018-06-08 at 20:12 +0200, Sylvain wrote: >> On 08/06/2018 19:55, Adam D. Barratt wrote: >>> Control: tags -1 + confirmed >>> >>> On Wed, 2018-06-06 at 19:54 +0200, b...@debian.org wrote: Please consider this update to freedink-dfarc for stretch. It fixes a security issue that can overwrite arbitrary user files. Sending to stable following security team's directions from 2018- 06- 01. >>> +freedink-dfarc (3.12-1+deb9u1) stable; urgency=high >>> >>> Please use "stretch" as the distribution. >>> >>> + * Fix directory traversal in D-Mod extractor (CVE-2018-0496) >>> + * Upload to 'stable' as security team rejected a DSA to >>> +'stretch-security' (no justification) >>> >>> The changelog is not the place for such commentary - please remove >>> it. >>> >>> With the above changes made, and assuming that the resulting >>> package >>> has been tested on stretch, please feel free to upload. >> As per Social Contract #3 I do have to explain to my users why they >> get the security fix after the disclosure. > As with basically all core teams, Debian's security team is generally > stretched in terms of manpower and can't handle every possible update > that's security-related. Things have to be prioritised and sometimes > those updates end up being provided via proposed-updates. That's always > going to be the case in a volunteer project, and even larger and/or > commercially-backed projects will still have to decide which updates > they handle before others. This isn't a problem as such, just the way > things are. Workload: that's not what they say. When asked on IRC, they said the team was "fine". Priorities: I do accept them. However I can report that they are neither documented nor explained: - "In the past, uploads to |stable| were used to address security problems as well. However, this practice is deprecated" https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable - "I don't think this warrants a DSA." is the sole explanation I could get. Plus, as I'm learning this 2-tier security support after years in Debian, I deemed this all-the-more relevant to the changelog. Incidentally, are you part of the Security Team? If yes, I'd appreciate that you say so. If not, that you don't speak for them. >> This is not a commentary, this is purely factual. > It's not a description of a change made to the package, nor information > that users need in order to decide whether they should be installing > it. As such, it is commentary. That has nothing to do with its > factuality or otherwise. It's a description of where the package is uploaded and why. Moreover I fail to see how adding this information is causing any harm, and in what way it's good to waste both our time complaining about it rather than just accepting the upload as-is. Since each question here needs a day or two to be answered, and since I'm not going to stall the update any more, I'll apply what will only look like helping hiding problems, as well as the AFAICS undocumented (https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable) stable->stretch change. Working on Debian is so depressing these days. - Sylvain
Bug#842425: meteor dependencies
so the script that runs meteor appears to download the following node packages (that do not appear to be in debian yet, some doublechecking is required) before running: node-agent-base node-agentkeepalive node-asap node-asynckit node-aws4 node-babel node-babel-helper-evaluate-path node-babel-helper-flip-expressions node-babel-helper-is-nodes-equiv node-babel-helper-is-void-0 node-babel-helper-mark-eval-scopes node-babel-helper-remove-or-void node-babel-helper-to-multiple-sequence-expressions node-babel-plugin-minify-builtins node-babel-plugin-minify-constant-folding node-babel-plugin-minify-dead-code-elimination node-babel-plugin-minify-flip-comparisons node-babel-plugin-minify-guarded-expressions node-babel-plugin-minify-infinity node-babel-plugin-minify-mangle-names node-babel-plugin-minify-numeric-literals node-babel-plugin-minify-replace node-babel-plugin-minify-simplify node-babel-plugin-minify-type-constructors node-babel-plugin-transform-es2015-modules-reify node-babel-plugin-transform-inline-consecutive-adds node-babel-plugin-transform-member-expression-literals node-babel-plugin-transform-merge-sibling-variables node-babel-plugin-transform-minify-booleans node-babel-plugin-transform-property-literals node-babel-plugin-transform-regexp-constructors node-babel-plugin-transform-remove-console node-babel-plugin-transform-remove-debugger node-babel-plugin-transform-remove-undefined node-babel-plugin-transform-simplify-comparison-operators node-babel-plugin-transform-undefined-to-void node-babel-preset-meteor node-babel-preset-minify node-buffer-from node-cacache node-chownr node-code-point-at node-commonmark node-emissary node-es6-promisify node-eventemitter3 node-event-kit node-expand-range node-fast-json-stable-stringify node-fs-minipass node-fs-plus node-grim node-http-cache-semantics node-http-proxy node-http-proxy-agent node-https-proxy-agent node-humanize-ms node-ignore node-ignore-walk node-immutable-tuple node-is-fullwidth-code-point node-is-posix-bracket node-kexec node-lodash.isplainobject node-lodash.some node-make-fetch-happen node-math-random node-meteor-babel node-meteor-babel-helpers node-mime-db node-minipass node-minizlib node-mixto node-netroute node-next-tick node-node-fetch-npm node-node-gyp node-node-pre-gyp node-npm node-npm-package-arg node-npm-packlist node-npm-pick-manifest node-optimism node-os-homedir node-pacote node-path-parse node-pathwatcher node-promise-retry node-property-accessors node-protoduck node-randomatic node-reify node-runas node-safer-buffer node-smart-buffer node-socks node-socks-proxy-agent node-string_decoder node-trim-right node-underscore-plus node-unique-filename node-unique-slug node-uuid
Bug#760022: libpam-tmpdir fails to work properly with systemd and suspend
Hi, First of all, apologies for never following up on this. ]] John Gruenenfelder [...] > Given the complexity of systemd, I'm not sure where the conflict arises. > Considering how frequently systemd seems to create and tear down sessions, > that seems a likely area for problems. I think the only PAM module that > touches tmp-anything is libpam-tmpdir, so my best guess is that at some point, > pre-suspend, systemd removes the user session triggering libpam-tmpdir to > remove the user tmpdir and anything in it. When the system resumes, systemd > creates a new session and libpam-tmpdir creates a new per-user tmpdir, but it > is, of course, now empty. libpam-tmpdir never cleans up the temporary directory, though, so I'm not sure how this would happen. If anything it sounds like a systemd bug. Are you still experiencing this, or did it get resolved in the meantime? Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#901181: mupdf-tools: exporting to xml drops newlines
Package: mupdf-tools Version: 1.13.0+ds1-1 Severity: normal Hello, I wanted to use mutool to export a pdf to xhtml and keep the document structure, but the xhtml output drops newlines. See for instance the attached file, mutool draw -o test.txt ~/test.pdf produces: 1 foo two words apart 1 2 foobar several words again apart again 2 but mutool draw -o test.xhtml ~/test.pdf produces: ... 1foo two wordsapart 1 2foobar several words againapart again 2 Samuel -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mupdf-tools depends on: ii libc62.27-3 ii libfreetype6 2.8.1-2 ii libharfbuzz0b1.7.6-1+b1 ii libjbig2dec0 0.14-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libopenjp2-7 2.3.0-1 ii libssl1.11.1.0h-4 ii zlib1g 1:1.2.11.dfsg-1 mupdf-tools recommends no packages. mupdf-tools suggests no packages. -- no debconf information -- Samuel faut en profiter, aujourd'hui, les blagues bidon sont à 100 dollars -+- #sos-bourse -+- test.pdf Description: Adobe PDF document
Bug#901177: cdck FTCBFS: configure.ac hard codes gcc in one place
On Sat, 09 Jun 2018 21:36:19 +0200, Helmut Grohne wrote: > cdck fails to cross build from source, because configure.ac hard codes > the build architecture compiler gcc in one place and thus tries to use > the build architecture libsupc++. Using $CC there fixes the cross build. > Please consider applying the attached patch. Thanks! Patch applied, package uploaded. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#774415: #774415: devscripts: please add the srebuild wrapper for reproducible builds
control: reassign -1 devscripts control: retitle -1 devscripts: please add the srebuild wrapper for reproducible builds thanks On Sat, Jun 09, 2018 at 10:33:16PM +0200, Johannes Schauer wrote: > Quoting Holger Levsen (2018-06-09 22:12:33) > > As it sounds, I now believe this script would better live in src:devscripts > > and as such I would like to reassign #774415 to devscripts - or do you see > > any issue with that? > I see no issues with that from my side. ok :) thanks! -- cheers, Holger signature.asc Description: PGP signature
Bug#774415: Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Quoting Holger Levsen (2018-06-09 22:12:33) > As it sounds, I now believe this script would better live in src:devscripts > and as such I would like to reassign #774415 to devscripts - or do you see > any issue with that? I see no issues with that from my side. signature.asc Description: signature
Bug#900920: stretch-pu: package freedink-dfarc/3.12-1+deb9u1
On Fri, 2018-06-08 at 20:12 +0200, Sylvain wrote: > Hi, > > On 08/06/2018 19:55, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Wed, 2018-06-06 at 19:54 +0200, b...@debian.org wrote: > > > Please consider this update to freedink-dfarc for stretch. > > > It fixes a security issue that can overwrite arbitrary user > > > files. > > > Sending to stable following security team's directions from 2018- > > > 06- > > > 01. > > > > +freedink-dfarc (3.12-1+deb9u1) stable; urgency=high > > > > Please use "stretch" as the distribution. > > > > + * Fix directory traversal in D-Mod extractor (CVE-2018-0496) > > + * Upload to 'stable' as security team rejected a DSA to > > +'stretch-security' (no justification) > > > > The changelog is not the place for such commentary - please remove > > it. > > > > With the above changes made, and assuming that the resulting > > package > > has been tested on stretch, please feel free to upload. > > As per Social Contract #3 I do have to explain to my users why they > get the security fix after the disclosure. > As with basically all core teams, Debian's security team is generally stretched in terms of manpower and can't handle every possible update that's security-related. Things have to be prioritised and sometimes those updates end up being provided via proposed-updates. That's always going to be the case in a volunteer project, and even larger and/or commercially-backed projects will still have to decide which updates they handle before others. This isn't a problem as such, just the way things are. (There's an argument that co-ordinated disclosure is in fact hiding issues in and of itself. I don't particularly subscribe to that, nor do I believe that any of this is what SC3 is actually trying to ensure.) > This is not a commentary, this is purely factual. It's not a description of a change made to the package, nor information that users need in order to decide whether they should be installing it. As such, it is commentary. That has nothing to do with its factuality or otherwise. Regards, Adam
Bug#901180: release notes fails to build in a clean checkout
Package: release-notes Severity: normal Hello I have cloned the release-notes repo and did "make" to build the release notes, but I got an error (attached complete log, here an extract): LANG=C ./transcount en ca cs >> statistics.txt svn: E155007: '/srv/www.debian.org/release-notes/release-notes/en/moreinfo.dbk' is not a working copy svn: E155007: '/srv/www.debian.org/release-notes/release-notes/en/issues.dbk' is not a working copy svn: E155007: '/srv/www.debian.org/release-notes/release-notes/en/old-stuff.dbk' is not a working copy svn: E155007: '/srv/www.debian.org/release-notes/release-notes/en/installing.dbk' is not a working copy svn: E155007: '/srv/www.debian.org/release-notes/release-notes/en/upgrading.dbk' is not a working copy svn: E155007: '/srv/www.debian.org/release-notes/release-notes/en/release-notes.dbk' is not a working copy svn: E155007: '/srv/www.debian.org/release-notes/release-notes/en/about.dbk' is not a working copy svn: E155007: '/srv/www.debian.org/release-notes/release-notes/en/whats-new.dbk' is not a working copy Traceback (most recent call last): File "./transcount", line 37, in if revision >= revisions[fn]: KeyError: 'moreinfo.dbk' Makefile:346: recipe for target 'statistics.txt' failed make: *** [statistics.txt] Error 1 I guess the "transcount" script needs to be adapted to use git instead of subversion. However, if I run again "make", the build goes on and finishes correctly. If I do "make clean" and then "make" again, I face the issue again. Kind regards, -- Laura Arjona Reina https://wiki.debian.org/LauraArjona for l in en da de es fr it ja nl pt-br pt ro ru sv sk pl; do \ make FORCE LINGUA=$l; \ done make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'FORCE'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make en/old-stuff.dbk LINGUA=`basename en` make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes' make[1]: Nothing to be done for 'en/old-stuff.dbk'. make[1]: Leaving directory '/srv/www.debian.org/release-notes/release-notes' make en/release-notes.dbk LINGUA=`basename en` make[1]: Entering directory '/srv/www.debian.org/release-notes/release-notes'
Bug#774415: Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Hi josch, adding #774415 to to: and reply-to:… On Fri, Jun 08, 2018 at 07:54:20PM +0200, Johannes Schauer wrote: > > as I'm not an sbuild user (yet) myself, I was hesistant to try this > > myself, so I'm confused now: does it work as it is now? (or does it need > > changes to snapshot.d.o?) > > yes, it does work as it is now. > > Just supply the script with a buildinfo file to see it in action. > > It does not require superuser privileges. > > The script will query snapshot.debian.org to retrieve the right snapshot > timestamp that contains all the package versions specified in the buildinfo > file. > > At the end of execution the script will print how to either reproduce the > buildinfo manually via dpkg-buildpackage or how to run sbuild such that it > does > it for you. > > People who know how to use pbuilder could easily add a section that outputs > how > to run pbuilder to do the same. > > Naturally, instead of just printing how to use sbuild or pbuilder, the script > could also be made actually run either. > > The main two limitations of the script are: > > 1. it will fail if there is not a single snapshot that contains all the right > package versions > > 2. it will instruct sbuild/pbuilder to use the last stable release as the > base > which might not allow upgrading to the right package versions > > Both issues can be fixed by manually downloading exactly the required binary > package set and creating a completely new chroot with exactly the required > packages. But I didn't get around to doing that yet. thank you very much for this nice summary! As it sounds, I now believe this script would better live in src:devscripts and as such I would like to reassign #774415 to devscripts - or do you see any issue with that? -- cheers, Holger signature.asc Description: PGP signature
Bug#892275: (No Subject)
> I can second that with redshift-gtk it is indeed broken. Same for me, Cheers, Florent
Bug#901179: gri FTCBFS: does not pass --host to ./configure
Source: gri Version: 2.12.26-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap gri fails to cross build from source, because debian/rules does not pass --host to ./configure. The easiest way of doing so is letting dh_auto_configure do it and that makes gri cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru gri-2.12.26/debian/changelog gri-2.12.26/debian/changelog --- gri-2.12.26/debian/changelog2017-08-15 17:20:56.0 +0200 +++ gri-2.12.26/debian/changelog2018-06-09 22:02:13.0 +0200 @@ -1,3 +1,10 @@ +gri (2.12.26-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1) + + -- Helmut Grohne Sat, 09 Jun 2018 22:02:13 +0200 + gri (2.12.26-1) unstable; urgency=medium * New upstream release. diff --minimal -Nru gri-2.12.26/debian/control gri-2.12.26/debian/control --- gri-2.12.26/debian/control 2017-08-15 17:20:56.0 +0200 +++ gri-2.12.26/debian/control 2018-06-09 22:01:23.0 +0200 @@ -2,7 +2,7 @@ Section: science Priority: optional Maintainer: Peter S Galbraith -Build-Depends: debhelper (>= 0), libnetcdf-dev, libreadline-dev, texlive-latex-base, texlive-generic-recommended, texinfo, imagemagick, info, ghostscript, gsfonts +Build-Depends: debhelper (>= 7), libnetcdf-dev, libreadline-dev, texlive-latex-base, texlive-generic-recommended, texinfo, imagemagick, info, ghostscript, gsfonts Homepage: http://gri.sourceforge.net/ Standards-Version: 3.9.8 diff --minimal -Nru gri-2.12.26/debian/rules gri-2.12.26/debian/rules --- gri-2.12.26/debian/rules2017-08-15 17:20:56.0 +0200 +++ gri-2.12.26/debian/rules2018-06-09 22:02:11.0 +0200 @@ -76,7 +76,7 @@ Makefile: # To test on g++-3.0 : # CC=gcc-3.0 CXX=g++-3.0 ./configure --prefix=/usr - ./configure --prefix=/usr --enable-linux_debian + dh_auto_configure -- --enable-linux_debian # Build architecture-independent files here (no need to be root). build-indep: debian/gri_merge.1 Makefile
Bug#901178: latex2rtf FTCBFS: rebuilds latex2rtf during make install
Source: latex2rtf Version: 2.3.16-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap latex2rtf fails to cross build from source, because make install tries to relink latex2rtf. Since dh_auto_install does not pass cross compilers to make, that doesn't go particularly well. The attached patch removes latex2rtf from .PHONY and makes latex2rtf cross build successfully. Please consider applying it. Helmut --- latex2rtf-2.3.16.orig/Makefile +++ latex2rtf-2.3.16/Makefile @@ -253,7 +253,7 @@ splint: splint -weak $(SRCS) $(HDRS) -.PHONY: all check checkdir clean depend dist doc install install_info realclean latex2rtf uptodate releasedate splint fullcheck +.PHONY: all check checkdir clean depend dist doc install install_info realclean uptodate releasedate splint fullcheck # created using "make depend" commands.o: commands.c cfg.h main.h convert.h chars.h fonts.h preamble.h \
Bug#901177: cdck FTCBFS: configure.ac hard codes gcc in one place
Source: cdck Version: 0.7.0+dfsg-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap cdck fails to cross build from source, because configure.ac hard codes the build architecture compiler gcc in one place and thus tries to use the build architecture libsupc++. Using $CC there fixes the cross build. Please consider applying the attached patch. Helmut --- cdck-0.7.0+dfsg.orig/configure.ac +++ cdck-0.7.0+dfsg/configure.ac @@ -96,7 +96,7 @@ CXXFLAGS="$CXXFLAGS -Wall -Wwrite-strings -Woverloaded-virtual -fno-exceptions -fno-rtti -export-dynamic " fi -SUPCXX=`gcc -print-file-name=libsupc++.a` +SUPCXX=`$CC -print-file-name=libsupc++.a` LIBS="$SUPCXX $LIBS"
Bug#901175: evolution: Selecting text and trying to copy it actually deletes it.
Package: evolution Version: 3.28.2-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Entering text into body of email * What exactly did you do (or not do) that was effective (or ineffective)? Tried to select and copy text using both right select menu and edit menu * What was the outcome of this action? Text was deleted on clicking right select or edit, no text available for paste * What outcome did you expect instead? Text was copied and available for paste Note: Same problem using Joomla 3.8.8 editor within Gnome Web (works OK in any other browser) *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf-8, LC_CTYPE=en_GB.utf-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution depends on: ii dbus 1.12.8-2 ii evolution-common 3.28.2-1 ii evolution-data-server 3.28.2-1+b1 ii libc6 2.27-3 ii libcamel-1.2-613.28.2-1+b1 ii libclutter-gtk-1.0-0 1.8.4-3 ii libecal-1.2-19 3.28.2-1+b1 ii libedataserver-1.2-23 3.28.2-1+b1 ii libevolution 3.28.2-1 ii libglib2.0-0 2.56.1-2 ii libgtk-3-0 3.22.29-3 ii libical3 3.0.1-5+b1 ii libnotify4 0.7.7-3 ii libsoup2.4-1 2.62.1-1 ii libwebkit2gtk-4.0-37 2.20.2-1+b1 ii libxml22.9.4+dfsg1-7 ii psmisc 23.1-1+b1 Versions of packages evolution recommends: ii evolution-plugin-bogofilter 3.28.2-1 ii evolution-plugin-pstimport 3.28.2-1 ii evolution-plugins3.28.2-1 ii yelp 3.28.1-1 Versions of packages evolution suggests: pn evolution-ews pn evolution-plugins-experimental ii gnupg 2.2.7-1 ii network-manager 1.10.8-1 -- debconf information: evolution/needs_shutdown: evolution/kill_processes:
Bug#901176: wipe FTCBFS: upstream build system forces build architecture compiler
Source: wipe Version: 0.24-2 Tags: patch User: helm...@debian.org Usertags: rebootstrap wipe fails to cross build from source, because the upstream build system tries quite hard to be in charge of the compiler choice and chooses wrongly. The attached patch is a way to inject our cross compiler and makes wipe cross build successfully. Please consider applying it. Helmut diff --minimal -Nru wipe-0.24/debian/changelog wipe-0.24/debian/changelog --- wipe-0.24/debian/changelog 2016-11-17 22:55:39.0 +0100 +++ wipe-0.24/debian/changelog 2018-06-09 21:27:13.0 +0200 @@ -1,3 +1,10 @@ +wipe (0.24-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Tell build system to use our CC. (Closes: #-1) + + -- Helmut Grohne Sat, 09 Jun 2018 21:27:13 +0200 + wipe (0.24-2) unstable; urgency=medium * debian/copyright: removed an outdated upstream email address. diff --minimal -Nru wipe-0.24/debian/rules wipe-0.24/debian/rules --- wipe-0.24/debian/rules 2016-09-06 18:19:22.0 +0200 +++ wipe-0.24/debian/rules 2018-06-09 21:27:10.0 +0200 @@ -6,11 +6,11 @@ # Define the OS ifeq ($(DEB_HOST_GNU_SYSTEM), linux-gnu) -target = linux +target = linux CC_LINUX='$$(CC)' else ifeq ($(DEB_HOST_GNU_SYSTEM), kfreebsd-gnu) -target = freebsd +target = freebsd CC_FREEBSD='$$(CC)' else -target = generic +target = generic CC_GENERIC='$$(CC)' endif %:
Bug#848256: lastpass-cli: lpass segfaults attempting to log in
Hi, > lastpass-cli: lpass segfaults attempting to log in Can you folks reproduce this in lastpass-cli 1.3.1? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#901160: Updating the description of the Standards-Version field
Sean Whitton writes ("Bug#901160: Updating the description of the
Standards-Version field"):
> The upgrading checklist explicitly states that it does not have
> normative status, so a 'should not' requirement should not defer to it.
I don't see a problem with this referral. The reason the upgrading
checklist isn't normative is to avoid having to review the summaries
contained in it in detail. As a *list of changes* it surely must be
normative. But I don't mind your new text.
> Also, IMO this should be 'must' rather than 'should' -- since it is pure
> metadata, bumping the s-v without reviewing the changes to Policy can
> only be counterproductive.
I don't think that's true. For example, one might have redone the
packaging from scratch, in which case there is no need to review the
*changes* to policy.
> > +As a rule of thumb,
> > +each package should be reviewed at least once per Debian release,
> > +so a Standards-Version older than the previous Debian release
> > +is indicative of work (if only review work) that needs doing.
>
> s/As a rule of thumb, each package should be/It is recommended that each
> package be/
>
> "Should" carries the weight of a bug of 'important' severity, but I
> don't think that was your intent (and I don't think it should have
> been).
Fine by me.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#901174: fontforge-extras FTCBFS: uses the build architecture compiler
Source: fontforge-extras Version: 0.3-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap fontforge-extras fails to cross build from source, because it uses the make default of CC as compiler. Letting dpkg's buildtools.mk initializes CC with a cross compiler fixes that and makes fontforge-extras cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru fontforge-extras-0.3/debian/changelog fontforge-extras-0.3/debian/changelog --- fontforge-extras-0.3/debian/changelog 2013-09-30 00:13:47.0 +0200 +++ fontforge-extras-0.3/debian/changelog 2018-06-09 21:13:34.0 +0200 @@ -1,3 +1,10 @@ +fontforge-extras (0.3-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dpkg's buildtools.mk set up CC. (Closes: #-1) + + -- Helmut Grohne Sat, 09 Jun 2018 21:13:34 +0200 + fontforge-extras (0.3-4) unstable; urgency=low * Team upload. diff --minimal -Nru fontforge-extras-0.3/debian/rules fontforge-extras-0.3/debian/rules --- fontforge-extras-0.3/debian/rules 2013-09-30 00:13:47.0 +0200 +++ fontforge-extras-0.3/debian/rules 2018-06-09 21:13:32.0 +0200 @@ -2,6 +2,7 @@ #export DH_VERBOSE=1 export DEB_BUILD_MAINT_OPTIONS := hardening=+all +-include /usr/share/dpkg/buildtools.mk %: dh $@
Bug#900938: blueman: Blueman-manager should not automatically reconnect when manually disconnected
On Fri, 8 Jun 2018 07:48:30 +0200 Christopher Schramm wrote: > Hi Ron, > > there should not be any such auto-connect feature in blueman. You can > easily confirm that by stopping blueman-applet and check if it still > happens (you can use bluetoothctl to disconnect if that's necessary). > > I actually think it is a feature of the headphones and not triggered > from your Linux system. > > Could be my headphones, but it doesn't happen with the Windows 10 box. I'll try your suggestion when I get a chance, and let you know how it goes. Thanks, .Ron -- Ron Murray PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761
Bug#900268: lintian is fooled by openjdk's .debuginfo files
tags 900268 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/lintian/lintian/commit/82e3ecc5b8e483bb28378427a0de608de64cc06c checks/binaries.pm | 1 + debian/changelog | 4 2 files changed, 5 insertions(+) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#888561: jessie-pu: package nvidia-graphics-modules/340.106+3.16.0+1
On Mon, 2018-05-07 at 14:14 +0200, Andreas Beckmann wrote: > Followup-For: Bug #888561 > > Hi, > > updated to ABI 6 and uploaded binaries for amd64 and i386. > > Refreshed debdiff attached. > Unfortunately I missed the fact that the upload had ended up in NEW due to the kernel ABI change, and dak will no longer accept it because: ArchiveException: n/nvidia-graphics-modules/nvidia-kernel-3.16.0-6-686- pae_340.106+1+1+3.16.56-1_i386.deb: Built-Using refers to package linux (= 3.16.56-1) not in target archive ftp-master. Regards, Adam
Bug#901173: dracut FTCBFS: build system expects PKG_CONFIG variable
Source: dracut Version: 047+31-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap dracut fails to cross build from source, because it falls back to the build architecture pkg-config. It uses a non-autotools ./configure that does not derive pkg-config from the --host flag but rather expect the builder exporting a suitable PKG_CONFIG. After doing so, dracut cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru dracut-047+31/debian/changelog dracut-047+31/debian/changelog --- dracut-047+31/debian/changelog 2018-05-17 17:44:36.0 +0200 +++ dracut-047+31/debian/changelog 2018-06-09 20:46:34.0 +0200 @@ -1,3 +1,10 @@ +dracut (047+31-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let buildtools.mk export PKG_CONFIG etc. (Closes: #-1) + + -- Helmut Grohne Sat, 09 Jun 2018 20:46:34 +0200 + dracut (047+31-1) unstable; urgency=medium * new upstream version diff --minimal -Nru dracut-047+31/debian/rules dracut-047+31/debian/rules --- dracut-047+31/debian/rules 2018-05-17 17:28:36.0 +0200 +++ dracut-047+31/debian/rules 2018-06-09 20:46:32.0 +0200 @@ -1,6 +1,8 @@ #!/usr/bin/make -f export DH_VERBOSE=1 +DPKG_EXPORT_BUILDTOOLS=1 +-include /usr/share/dpkg/buildtools.mk %: dh $@
Bug#901001: python3-minimal should Pre-Depend on python3.N-minimal
On Sat, Jun 09, 2018 at 06:39:19PM +0200, Matthias Klose wrote: > On 09.06.2018 18:31, Matthias Klose wrote: > > On 09.06.2018 11:55, Philipp Kern wrote: > > > On 6/9/18 7:20 AM, Steve Langasek wrote: > > > > - the package is being upgraded; it is in the common case (when no > > > > python > > > > module names have been dropped from within the package) less > > > > important to > > > > run py3clean because the same files will be recreated shortly > > > > afterwards > > > > by py3compile from the new postinst. > > > What's the consequence from deleting the files and only recreating them > > > later? Longer startup time of the interpreter in that short window? > > yes, that's the only thing. > > > Because if it's worse, it'd be good to have py3clean only delete the > > > obsolete files in the postinst? > but as written in the bug report, there is another solution, to have > py3clean search for the interpreter it uses, and which doesn't need the > pre-dependency. Is the following scenario a concern that we should take into consideration? - a core library that python3.5-minimal (or libpython3.5-minimal) depends on has an ABI change and must be renamed, with a conflicts on the old package name. - new python-minimal is unpacked. /usr/bin/python is a dangling symlink. - python3.5-minimal is removed due to the conflict. - python3.6-minimal is not yet unpacked, because ordering is not guaranteed. - python3-foo module is removed due to another conflict. The prerm fails because py3clean can find no version of python3 interpreter on the disk. The pre-depends would address this case, by enforcing the configuration of python3.6-minimal before unpacking python-minimal (and before removing python3.5-minimal). It does constrain apt's solver, but as long as apt can find a solution, that's ok. It may be an ignorable hypothetical, since the set of libraries that python3.5-minimal + libpython3.5-minimal depends on is quite small, and they are all very stable and well-maintained upstream (zlib, libexpat1, libc6, libssl). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#901172: update 7release-notes script to use the git repo of "release-notes"
Package: www.debian.org Severity: normal User: debian-...@lists.debian.org Usertags: scripts Tags: patch X-Debbugs-CC: debian-...@lists.debian.org Hello all The "often" cron job for building the release notes (for the Debian website) currently fails because it's still using svn and alioth. Here is the log: https://www-master.debian.org/build-logs/webwml/release-notes.log and its content: Sat Jun 9 16:55:05 UTC 2018 rebuilding the release notes for wheezy Updating '.': svn: E170013: Unable to connect to a repository at URL 'svn://svn.debian.org/svn/ddp/manuals/branches/release-notes/wheezy' svn: E670002: Unknown hostname 'svn.debian.org' The job script is here: https://salsa.debian.org/webmaster-team/cron/blob/master/parts/7release-notes I'm attaching a patch to update the job to use git. Reviews are appreciated. Some notes: 1.- With svn we had one folder for each branch that was storing the release notes of one release. So, now we have this structure in www-master.debian.org: /srv/www.debian.org/release-notes /srv/www.debian.org/release-notes/stretch /srv/www.debian.org/release-notes/jessie /srv/www.debian.org/release-notes/wheezy /srv/www.debian.org/release-notes/squeeze /srv/www.debian.org/release-notes/lenny /srv/www.debian.org/release-notes/etch /srv/www.debian.org/release-notes/build.log /srv/www.debian.org/release-notes/build.log.* In git we have branches but everything is in the same folder. So in my patch I assume that we have a clone of the release-notes repo, and thus we would have this structure in www-master.debian.org: /srv/www.debian.org/release-notes /srv/www.debian.org/release-notes/release-notes (git repo) /srv/www.debian.org/release-notes/build.log /srv/www.debian.org/release-notes/build.log.* and use git checkout to each release (branch). 2.- I have cloned locally the release-notes repo to try to test my changes to the cron script, but the local build fails. I will file a separate bug about this against release-notes. When that issue is fixed I will try to build the notes locally and test my patch, but in the meanwhile any comment is welcome. Cheers -- Laura Arjona Reina https://wiki.debian.org/LauraArjona From f143f2a3e7f7e7c918664d050b22008a03be241a Mon Sep 17 00:00:00 2001 From: Laura Arjona Reina Date: Sat, 9 Jun 2018 20:37:42 +0200 Subject: [PATCH] Update 7release-notes script to use the git repo in Salsa --- parts/7release-notes | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/parts/7release-notes b/parts/7release-notes index 395607f..664da58 100755 --- a/parts/7release-notes +++ b/parts/7release-notes @@ -13,18 +13,13 @@ date > $notesdir/build.log # Add the release name once released/branched out of trunk for release in wheezy jessie stretch ; do echo "rebuilding the release notes for $release" >> $notesdir/build.log -if ! [ -d "$notesdir/$release" ] ; then -echo "directory $notesdir/$release does not exist. checking out SVN" >> $notesdir/build.log -cd $notesdir -if [ "$release" = "stretch" ]; then -svn checkout svn://svn.debian.org/svn/ddp/manuals/trunk/release-notes $release >> $notesdir/build.log 2>&1 -else -svn checkout svn://svn.debian.org/svn/ddp/manuals/branches/release-notes/$release >> $notesdir/build.log 2>&1 -fi +cd $notesdir/release-notes +if [ "$release" = "stretch" ]; then +git checkout master && git pull >> $notesdir/build.log 2>&1 else -(cd $notesdir/$release && svn update) >> $notesdir/build.log 2>&1 +git checkout $release && git pull >> $notesdir/build.log 2>&1 fi - make -C $notesdir/$release publish \ +make -C $notesdir/release-notes publish \ PUBLISHTARBALL=yes PUBLISHDIR=$webtopdir/www/releases/$release >> $notesdir/build.log 2>&1 done -- 2.11.0
Bug#901171: adanaxisgpl FTCBFS: abuses AC_CHECK_FILE
Source: adanaxisgpl Version: 1.2.5.dfsg.1-6 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap adanaxisgpl fails to cross build from source, because the build system abuses AC_CHECK_FILE, which is meant for discovering files on the host system. adanaxisgpl however uses it to check files in the build tree. That's wrong. The attached patch fixes that and makes adanaxisgpl cross buildable. Please consider applying it. Helmut --- adanaxisgpl-1.2.5.dfsg.1.orig/configure.in +++ adanaxisgpl-1.2.5.dfsg.1/configure.in @@ -282,8 +282,8 @@ ] ) dnl Check that autogenerated Makefile.am files are there -AC_CHECK_FILE(src,[ -AC_CHECK_FILE(src/Makefile.am,,[ +AS_IF([test -d src],[ +AS_IF([test -f src/Makefile.am],,[ AC_MSG_ERROR([src/Makefile.am not present. Please run autogen]) ]) ])
Bug#901170: ostree: flaky autopkgtest
Source: ostree Version: 2018.5-1 Severity: important User: debian...@lists.debian.org Usertags: flaky While inspecting regressions in autopkgtest results¹, I noticed that your package ostree version 2018.5-1 failed twice²³ with a spurious error: error: opendir(staging-966866a4-cd46-45f4-b642-013c2b097a53-5prA5F): No such file or directory or error: opendir(staging-10828279-c222-4a21-aeea-fce753e7bbd3-lBM3P5): No such file or directory The last one was delaying the migration of gnupg2. Could you please investigate and make your autopkgtest more robust? Please contact me if you need help and you think I can provide that (I am not subscribed to this bug). Recent discussion of gating migration by autopkgtests on debian-devel⁴ noted that if this is going to work, and in particular if we are going to *block* migration when it causes autopkgtest regressions rather than merely delaying it, intermittent autopkgtest failures are likely to have to be considered RC due to their impact on the tested package's dependencies; for now I've filed it as important. Paul ¹ https://ci.debian.net/packages/o/ostree/ ² https://ci.debian.net/data/autopkgtest/unstable/amd64/o/ostree/416480/log.gz ³ https://ci.debian.net/data/autopkgtest/testing/amd64/o/ostree/429816/log.gz ⁴ https://lists.debian.org/debian-devel/2018/05/msg00061.html signature.asc Description: OpenPGP digital signature
Bug#890778:
Control: retitle -1 ITP: plasma-browser-integration -- Components necessary to integrate browsers into the Plasma Desktop.
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Sean Whitton writes: >> David Bremner wrote >> >> I (so-far) had the idea that "dpkg-dev", and "debian" could be >> upstream packages in e.g. melpa-stable. OTOH, "debian" is annoyingly >> generic, so that might have to change. > > If they are native packages, they should not be published to MELPA. > > I think they should probably be native packages. Perhaps. There is this: https://apps.fedoraproject.org/packages/emacs-goodies https://bugzilla.redhat.com/show_bug.cgi?id=1063750 If other (non-downstream) distros are going to have them, it's maybe better to have a real upstream to centralize bug reporting. In any case, they need an "elpa name" to e.g. go in the define-package form and the binary package name. What are the advantages of being native packages? I don't propose to have seperate upstream repos, only branches. d
Bug#901169: camlzip: autopkgtest regression
Source: camlzip Version: 1.07-1 User: debian...@lists.debian.org Usertags: regression Dear maintainers, With the upload of version 1.07-1 your autopkgtest¹ started to fail. I have copied the output below. Could you please investigate and fix your autopkgtest? This is currently delaying the migration of your package to testing with 13 days. Paul ¹ https://ci.debian.net/packages/c/camlzip https://ci.debian.net/data/autopkgtest/testing/amd64/c/camlzip/430665/log.gz autopkgtest [04:03:52]: test upstream: [--- make: *** No rule to make target '../zip.cma', needed by 'minizip'. Stop. autopkgtest [04:03:52]: test upstream: ---] signature.asc Description: OpenPGP digital signature
Bug#901155: transition: octave-4.4
Control: tags -1 confirmed On 09/06/18 16:22, Sébastien Villemot wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-octave.html > > Dear Release Team, > > Please schedule a transition for octave 4.4. The new package is already in > experimental. > > Few reverse dependencies will need sourceful NMUs. In any case, we stand ready > to NMU. Go ahead. Emilio
Bug#901168: schleuder: autopkgtest regression
Source: schleuder Version: 3.2.2-1 User: debian...@lists.debian.org Usertags: needs-update Dear maintainers, Since ruby-mail-gpg version 0.4.0-1 your autopkgtest¹ fails. I have copied the output below. Could you please investigate and fix your autopkgtest? It seems you need to raise your dependency in the code. Additionally, your dependency in Debian context (d/control) is unversioned, which sounds wrong if the code is versioned. Sorry that the autopkgtest integration missed the check for the new version of ruby-mail-gpg, we had an out-of-sync archive at that moment. Paul ¹ https://ci.debian.net/packages/s/schleuder https://ci.debian.net/data/autopkgtest/unstable/amd64/s/schleuder/363094/log.gz autopkgtest [05:16:59]: test upstream-tests: [--- ┌──┐ │ Checking Rubygems dependency resolution on ruby2.5 │ └──┘ Invalid gemspec in [schleuder.gemspec]: No such file or directory - git GEM_PATH= ruby2.5 -e gem\ \"schleuder\" /usr/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs': Could not find 'mail-gpg' (~> 0.3.0) - did find: [mail-gpg-0.4.0] (Gem::MissingSpecVersionError) Checked in 'GEM_PATH=/root/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all', execute `gem env` for more information from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1469:in `block in activate_dependencies' from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `each' from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `activate_dependencies' from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1440:in `activate' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:68:in `block in gem' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `synchronize' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `gem' from -e:1:in `' activemodel (4.2.10) activerecord (4.2.10) activesupport (4.2.10) arel (6.0.4) atomic (1.1.16) backports (3.11.1) bigdecimal (default: 1.3.4) blankslate (3.1.3) builder (3.2.3) cmath (default: 1.0.0) csv (default: 1.0.0) daemons (1.1.9) database_cleaner (1.5.1) date (default: 1.0.0) dbm (default: 1.0.0) did_you_mean (1.2.1) diff-lcs (1.3) etc (default: 1.0.0) eventmachine (1.0.7) factory_girl (4.7.0) fcntl (default: 1.0.0) fiddle (default: 1.0.0) fileutils (default: 1.0.2) gdbm (default: 2.0.0) gpgme (2.0.16) i18n (0.7.0) io-console (default: 0.4.6) ipaddr (default: 1.2.0) json (default: 2.1.0) mail (2.6.4) mail-gpg (0.4.0) mime-types (3.1) mime-types-data (3.2015.1120) minitest (5.10.3) multi_json (1.12.1) net-telnet (0.1.1) openssl (default: 2.1.0) power_assert (1.1.1) psych (default: 3.0.2) rack (1.6.4) rack-protection (1.5.3) rack-test (0.7.0) rake (12.3.1) rdoc (default: 6.0.1) rspec (3.7.0) rspec-core (3.7.1) rspec-expectations (3.7.0) rspec-mocks (3.7.0) rspec-support (3.7.1) scanf (default: 1.0.0) schleuder (3.2.2) sdbm (default: 1.0.0) sinatra (1.4.8) sinatra-contrib (1.4.7) sqlite3 (1.3.13) stringio (default: 0.0.1) strscan (default: 1.0.0) test-unit (3.2.7) thin (1.6.3) thor (0.19.4) thread_order (1.1.0) thread_safe (0.3.6) tilt (2.0.8) tzinfo (1.2.5) webrick (default: 1.4.2) zlib (default: 1.0.0) autopkgtest [05:17:00]: test upstream-tests: ---] signature.asc Description: OpenPGP digital signature
Bug#901167: sbuild should not run autopkgtest if a source package has no tests
Package: sbuild Version: 0.73.0-4 Severity: normal Currently, if autopkgtest is enabled, it is run for every source package build including for source packages that don't even specify tests. This is wasting lots of time because in the worst case, autopkgtest spends lots of time updating the backend before figuring out that the source package doesn't even have tests. So instead, sbuild should itself check whether the source package has tests and only run autopkgtest if it does.
Bug#819349: new patch
> I'm afraid there's a problem in the hardware AES implementation on x32 on > certain Intel CPUs. Despite the real cause being known (hardcoded struct offsets in assembly), no one provided a proper fix yet. I for one don't know AES crypto instructions well enough, and according to Jed Javis, taking offsets from the struct is or was problematic with Solaris toolchains. So here's an updated version of the "just don't use hw aes on x32" patch; the old one doesn't apply anymore due to code reorganizations. You update nss really often, thus it's quite a burden to keep r-b-deps satisfied; even though most people who use x32 don't actually use nss (beside ceph it's mostly GUI stuff) and thus we need it mostly due to dependency chains, it would be nice to have it working. Thus, please apply the interim patch. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal). Description: disable Intel AES on x32 Intel AES extensions are broken on x32 due to wrong hardcoded offsets in assembly; they match the structs on amd64 but not x32. With no proper fix coming, disable HW AES for now. --- nss-3.37.1.orig/nss/lib/freebl/Makefile +++ nss-3.37.1/nss/lib/freebl/Makefile @@ -224,7 +224,9 @@ ifeq ($(CPU_ARCH),x86_64) DEFINES += -DMP_IS_LITTLE_ENDIAN # DEFINES += -DMPI_AMD64_ADD # comment the next four lines to turn off Intel HW acceleration. -DEFINES += -DUSE_HW_AES -DINTEL_GCM +ifeq (,$(USE_X32)) + DEFINES += -DUSE_HW_AES -DINTEL_GCM +endif ASFILES += intel-aes.s intel-gcm.s EXTRA_SRCS += intel-gcm-wrap.c INTEL_GCM = 1
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Hello, On Sat, Jun 09 2018, David Bremner wrote: > Nicholas D Steeves writes: > >> P.P.S. I can start with one of debian-el, devscripts-el, or >> dpkg-dev-el as a proof of concept, and it will also be easier to just >> iterate over the *.els once these exceptions have been dealt with. I >> assume that they ought to remain grouped together and become >> elpa-debian-el, elpa-devscripts.el, and elpa-dpkg-dev.el, with >> repositories on salsa named debian-el, devscripts-el, and >> dpkg-dev-el. > > I've actually done this, before finding this message. > > See > > https://salsa.debian.org/emacsen-team/dpkg-dev-el > https://salsa.debian.org/emacsen-team/debian-el > > The former depends on the latter, as it turns out. > > FWIW, I don't think any binary package ought to start with "elpa" and > end "-el" or "\.el", but other than that I'm flexible about the > naming. > > I (so-far) had the idea that "dpkg-dev", and "debian" could be > upstream packages in e.g. melpa-stable. OTOH, "debian" is annoyingly > generic, so that might have to change. If they are native packages, they should not be published to MELPA. I think they should probably be native packages. -- Sean Whitton
Bug#901166: ITP: python-markdown-math -- Math extension for Python-Markdown
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: python-markdown-math Version : 0.5 Upstream Author : Dmitry Shachnev * URL : https://github.com/mitya57/python-markdown-math * License : BSD-3-clause Programming Lang: Python Description : Math extension for Python-Markdown This package extends Python-Markdown with support for displaying math formulas using MathJax or AsciiMath. I need it for packaging the latest version of PyMarkups. It will be maintained under Debian Python Modules Team umbrella. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#901165: ITP: mkdocs-nature -- Nature theme from Sphinx adapted for MkDocs
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: mkdocs-nature Version : 0.2.1 Upstream Author : Waylan Limberg * URL : http://waylan.limberg.name/mkdocs-nature/ * License : BSD-2-clause Programming Lang: Python, CSS Description : Nature theme from Sphinx adapted for MkDocs This package provides the Nature theme for MkDocs documentation generator. I need it for packaging the latest version of Python-Markdown. I will be maintaining it in https://salsa.debian.org/debian/mkdocs-nature. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#901001: python3-minimal should Pre-Depend on python3.N-minimal
On 09.06.2018 18:31, Matthias Klose wrote: On 09.06.2018 11:55, Philipp Kern wrote: On 6/9/18 7:20 AM, Steve Langasek wrote: - the package is being upgraded; it is in the common case (when no python module names have been dropped from within the package) less important to run py3clean because the same files will be recreated shortly afterwards by py3compile from the new postinst. What's the consequence from deleting the files and only recreating them later? Longer startup time of the interpreter in that short window? yes, that's the only thing. Because if it's worse, it'd be good to have py3clean only delete the obsolete files in the postinst? Kind regards Philipp Kern but as written in the bug report, there is another solution, to have py3clean search for the interpreter it uses, and which doesn't need the pre-dependency.
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Nicholas D Steeves writes: > P.P.S. I can start with one of debian-el, devscripts-el, or > dpkg-dev-el as a proof of concept, and it will also be easier to just > iterate over the *.els once these exceptions have been dealt with. I > assume that they ought to remain grouped together and become > elpa-debian-el, elpa-devscripts.el, and elpa-dpkg-dev.el, with > repositories on salsa named debian-el, devscripts-el, and dpkg-dev-el. I've actually done this, before finding this message. See https://salsa.debian.org/emacsen-team/dpkg-dev-el https://salsa.debian.org/emacsen-team/debian-el The former depends on the latter, as it turns out. FWIW, I don't think any binary package ought to start with "elpa" and end "-el" or "\.el", but other than that I'm flexible about the naming. I (so-far) had the idea that "dpkg-dev", and "debian" could be upstream packages in e.g. melpa-stable. OTOH, "debian" is annoyingly generic, so that might have to change. d
Bug#901164: caja-eiciel FTCBFS: configure.ac hard codes build architecture pkg-config
Source: caja-eiciel Version: 1.18.1-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap caja-eiciel fails to cross build from source, because configure.ac hard codes the build architecture pkg-config in one place. The attached patch fixes that and makes caja-eiciel cross build successfully. Please consider applying it. Helmut --- caja-eiciel-1.18.1.orig/configure.ac +++ caja-eiciel-1.18.1/configure.ac @@ -96,7 +96,7 @@ ] , [dnl Linux distributions - extensiondir=`pkg-config --variable=extensiondir libcaja-extension`; + extensiondir=`$PKG_CONFIG --variable=extensiondir libcaja-extension`; if test -n "$extensiondir" ; then AC_SUBST(CAJA_EXTENSIONS_DIR, [$extensiondir])
Bug#901001: python3-minimal should Pre-Depend on python3.N-minimal
On 09.06.2018 11:55, Philipp Kern wrote: On 6/9/18 7:20 AM, Steve Langasek wrote: - the package is being upgraded; it is in the common case (when no python module names have been dropped from within the package) less important to run py3clean because the same files will be recreated shortly afterwards by py3compile from the new postinst. What's the consequence from deleting the files and only recreating them later? Longer startup time of the interpreter in that short window? yes, that's the only thing. Because if it's worse, it'd be good to have py3clean only delete the obsolete files in the postinst? Kind regards Philipp Kern
Bug#901163: gkrellm-volume FTCBFS: hard codes build architecture pkg-config, non-standard use of CC
Source: gkrellm-volume
Version: 2.1.13-1.1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap
gkrellm-volume fails to cross build from source. Its upstream build
system hard codes the build architecture pkg-config. Furthermore it
stuffs compiler flags into $(CC), such that those flags go missing when
dh_auto_build supplies a cross compiler. The attached patch fixes both
and makes gkrellm-volume cross build successfully. Please consider
applying it.
Helmut
--- gkrellm-volume-2.1.13.orig/Makefile
+++ gkrellm-volume-2.1.13/Makefile
@@ -6,7 +6,8 @@
FLAGS += -DPACKAGE="\"$(PACKAGE)\""
export PACKAGE LOCALEDIR
-GTK_CONFIG = pkg-config gtk+-2.0
+PKG_CONFIG ?= pkg-config
+GTK_CONFIG = $(PKG_CONFIG) gtk+-2.0
PLUGIN_DIR ?= /usr/local/lib/gkrellm2/plugins
GKRELLM_INCLUDE = -I/usr/local/include
@@ -31,7 +32,7 @@
export enable_nls
endif
-CC = gcc $(CFLAGS) $(FLAGS)
+CC = gcc
INSTALL = install -c
INSTALL_PROGRAM = $(INSTALL)
@@ -40,7 +41,7 @@
(cd po && ${MAKE} all )
volume.so: $(OBJS)
- $(CC) $(LDFLAGS) $(OBJS) -o volume.so $(LIBS)
+ $(CC) $(CFLAGS) $(FLAGS) $(LDFLAGS) $(OBJS) -o volume.so $(LIBS)
clean:
rm -f *.o core *.so* *.bak *~
@@ -50,5 +51,5 @@
(cd po && ${MAKE} install)
$(INSTALL_PROGRAM) volume.so $(PLUGIN_DIR)
-%.c.o: %.c
-
+%.o: %.c
+ $(CC) $(CFLAGS) $(FLAGS) -c $< -o $@
Bug#895917: Libav-tools relegated to Suggests
Hi, On 09/06/18 14:17, Ross Gammon wrote: > Hi, > > FFmpeg is already recommended by multimedia-video. > > Removing libav-tools from the blends task would mean that people running > stable would not be able to find the package on the blends website: > https://blends.debian.org/multimedia/tasks/ Is this really a problem? libav-tools was deprecated before stretch was released so even in stable people should not be encouraged to install it. James signature.asc Description: OpenPGP digital signature
Bug#901162: xbomb FTCBFS: uses the build architecture strip
Source: xbomb Version: 2.2b-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap xbomb fails to cross build from source. xbomb fails to honour DEB_BUILD_OPTIONS=nostrip. xbomb does not generate a useful -dbgsym package. All of these issues have the same reason: make install strips before dh_strip with the build architecture strip. All of these are fixed by simply not stripping. Please consider applying the attached patch. Helmut --- xbomb-2.2b.orig/Makefile +++ xbomb-2.2b/Makefile @@ -51,7 +51,6 @@ install : - strip xbomb install -d $(INSTDIR)/bin install -d $(INSTDIR)/man/man6 install -d $(INSTDIR)/lib/app-defaults
Bug#895627: intone: Dead upstream (last commit Feb 2012)
On 2018-04-13 Andreas Metzler wrote: > Package: intone > Version: 0.77+git20120308-1 > Severity: normal > Hello, > intone is dead upstream: > * last commit March 2012 > * no homepage, just the archived copy on > https://code.google.com/archive/p/intone/source > * Popcon 33 > * Uses E_DBus, also dead upstream since 2014. > Could this be dropped from Debian? I have requested removal of edbus today. #901143 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#901161: audacious-plugins FTCBFS: configure.ac hard codes build architecture pkg-config
Source: audacious-plugins Version: 3.9-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap audacious-plugins fails to cross build from source, because configure.ac hard codes the build architecture pkg-config in one place. The attached patch fixes that and makes audacious-plugins cross buildable. Please consider applying it. Helmut --- audacious-plugins-3.9.orig/configure.ac +++ audacious-plugins-3.9/configure.ac @@ -16,6 +16,7 @@ AC_CONFIG_MACRO_DIR([m4]) AUD_COMMON_PROGS +PKG_PROG_PKG_CONFIG BUILDSYS_SHARED_LIB @@ -626,7 +627,7 @@ dnl *** End of all plugin checks *** -plugindir=`pkg-config audacious --variable=plugin_dir` +plugindir=`$PKG_CONFIG audacious --variable=plugin_dir` AC_SUBST(plugindir) dnl XXX
Bug#901160: Updating the description of the Standards-Version field
Package: debian-policy Version: 4.1.4.1 Severity: normal User: debian-pol...@packages.debian.org Usertags: normative discussion Thank you for pointing out that Policy's description is out-of-date, Ian, and for the patch. I agree that it captures the consensus we established in that previous discussion, but it's not quite right for Policy yet; see below. Firstly, I think this text should go in section 4.1, and the description of the Standards-Version field should have a link back to section 4.1. The text in 4.1 is currently a bit strong about how often people have to check Policy, so we can replace that with your new text. On Fri, Jun 08 2018, Ian Jackson wrote: > +For a package to have an old Standards-Version > +is not itself a bug. > +It just means that no-one has yet > +reviewed the package with changes to the standards in mind. > +The Standards-Version should not be updated > +except after reviewing the applicable upgrading checklist. The upgrading checklist explicitly states that it does not have normative status, so a 'should not' requirement should not defer to it. Also, IMO this should be 'must' rather than 'should' -- since it is pure metadata, bumping the s-v without reviewing the changes to Policy can only be counterproductive. How about: The Standards-Version must not be updated except after reviewing the changes between the old and the new versions of the standards (the upgrading checklist[hyperlink] can help with this task). > +A very old Standards-Version > +can mean that infelicities in the package are likely. > +As a rule of thumb, > +each package should be reviewed at least once per Debian release, > +so a Standards-Version older than the previous Debian release > +is indicative of work (if only review work) that needs doing. s/As a rule of thumb, each package should be/It is recommended that each package be/ "Should" carries the weight of a bug of 'important' severity, but I don't think that was your intent (and I don't think it should have been). If others are happy with the changes in this e-mail I'll prepare a patch for seconding. -- Sean Whitton
Bug#851810: xcalib: "Error - unsupported ramp size 0" when trying to invert screen
> Do you think we could backport it to Stretch? Should I move the bug from > xcalib package to X.org? It definitely can be done, as the patch is very short, and there were no significant changes around patched code for quite a long time. And yes, the first step should be a bugreport against xserver-xorg-core package. However, I'm in doubt. Will they update a package in a stable release? --- Rinat
Bug#895917: Libav-tools relegated to Suggests
Hi James, On 06/09/2018 05:33 PM, James Cowgill wrote: > Hi, > > On 09/06/18 14:17, Ross Gammon wrote: >> Hi, >> >> FFmpeg is already recommended by multimedia-video. >> >> Removing libav-tools from the blends task would mean that people running >> stable would not be able to find the package on the blends website: >> https://blends.debian.org/multimedia/tasks/ > > Is this really a problem? libav-tools was deprecated before stretch was > released so even in stable people should not be encouraged to install it. > > James > No, it is not really a problem. It is just the way blends work. The blends website shows you all the packages that are available for you to install in the e.g. video category. Libav-tools now shows in the "Official Debian packages with lower relevance" category (because I dropped it to Suggests): https://blends.debian.org/multimedia/tasks/video I don't imagine anyone would be crazy enough to install one of the meta packages with suggestions included. Anyway, I suppose libav and ffmpeg is a bit of a special case, as it is a transitional package. And anyone that is using libav in a script or whatever will already have it installed. The bug is still open, so when it is time for the next upload I will remember to remove it. Thanks for following up with the query. Cheers, Ross signature.asc Description: OpenPGP digital signature
Bug#901158: postgis: FTBFS: testsuite failure
Control: tags -1 upstream Control: forwarded -1 https://trac.osgeo.org/postgis/ticket/4104 On 06/09/2018 05:05 PM, Niko Tyni wrote: > This package fails to build from source on current sid/amd64. Thanks for reporting this issue, I've forwarded it upstream. In the mean time I'll likely skip this test or ignore the failure(s). Kind Regards, Bas
Bug#690465: closing RFP: pidgin-opensteamworks -- Steam IM / Steam Friends plugin for Pidgin (libpurple)
Control: reopen -1 Debian Bug Tracking System wrote: > RFP 690465 has no visible progress for a long time, so closing. This reason is only valid, if the upstream project is dead. Which pidgin-opensteamworks isn't: The latest commit is from June 2, 2017. Hence reopening.
Bug#901159: linux-image-arm64: enable configuration options needed by Firefly-RK3399 board
Package: linux-latest Version: 94 Severity: wishlist Dear maintainer, to fully support the Firefly-RK3399 board, please, enable the following configuration items for linux-image-arm64: CONFIG_DRM_ROCKCHIP CONFIG_PHY_ROCKCHIP_TYPEC CONFIG_ROCKCHIP_ANALOGIX_DP CONFIG_ROCKCHIP_DW_HDMI CONFIG_ROCKCHIP_DW_MIPI_DSI CONFIG_ROCKCHIP_EFUSE CONFIG_ROCKCHIP_IOMMU CONFIG_ROCKCHIP_SARADC CONFIG_ROCKCHIP_THERMAL The corresponding drivers are selected by the device tree. Best regards Heinrich Schuchardt
Bug#898021: (no subject)
I can confirm libbsd0 0.9.1-1/bug #898088 does not fix my problems, and neither does upgrading to linux-image-4.16.0-2-amd64. (Btw. this is on a Skylake CPU.) Sten
Bug#901158: postgis: FTBFS: testsuite failure
Package: postgis Version: 2.4.4+dfsg-1 Severity: serious This package fails to build from source on current sid/amd64. ### /tmp/pgis_reg/test_50_diff ### --- rt_gdalwarp_expected 2018-04-06 05:05:52.0 + +++ /tmp/pgis_reg/test_50_out 2018-06-09 14:27:15.049036062 + @@ -19,8 +19,8 @@ 0.17|993309|243|243|1|50.000|50.000|0.000|0.000|950760.000|1396957.000|t|t|t 0.18|992163|10|10|1|1000.000|-1000.000|3.000|3.000|-500030.000|60.000|t|t|t 0.19|993310|12|12|1|1009.894|-1009.894|3.000|3.000|950691.792|1409281.783|t|t|t -0.2|993309|12|12|1|1009.916|-1009.916|0.000|0.000|950762.305|1409088.896|t|t|t -0.20|993309|12|12|1|1009.916|-1009.916|1.000|3.000|950742.107|1409088.896|t|t|t +0.2|993309|12|12|1|1009.876|-1009.876|0.000|0.000|950808.447|1409091.640|t|t|t +0.20|993309|12|12|1|1009.876|-1009.876|1.000|3.000|950788.250|1409091.640|t|t|t 0.21|993310|24|24|1|500.000|500.000|3.000|3.000|950657.188|1397356.783|t|t|t 0.22|993310|26|26|1|500.000|500.000|0.000|6.000|950452.000|1396632.000|t|t|t 0.23|984269|12|8|1|0.012|-0.012|0.000|0.000|-107.029|50.206|t|t|t @@ -63,12 +63,12 @@ 1.9|992163|11|10|1|1000.000|-1000.000|0.000|0.000|-51.000|60.000|t|t|t 2.1|993310|12|12|1|1009.894|-1009.894|0.000|0.000|950732.188|1409281.783|t|t|t 2.10|993310|24|24|1|500.000|500.000|0.000|0.000|950732.188|1397281.783|t|t|t -2.11|993309|121|121|1|100.000|100.000|0.000|0.000|950762.305|1396988.896|t|t|t +2.11|993309|121|121|1|100.000|100.000|0.000|0.000|950808.447|1396991.640|t|t|t 2.12|993310|6|6|1|2000.000|2000.000|0.000|0.000|950732.188|1397281.783|t|t|t 2.13|993310|8|8|1|1500.000|1500.000|0.000|0.000|950732.188|1397281.783|t|t|t 2.14|993310|24|24|1|500.000|500.000|0.000|0.000|950732.188|1397281.783|t|t|t 2.15|993310|16|16|1|750.000|750.000|0.000|0.000|950732.188|1397281.783|t|t|t -2.2|993309|12|12|1|1009.916|-1009.916|0.000|0.000|950762.305|1409088.896|t|t|t +2.2|993309|12|12|1|1009.876|-1009.876|0.000|0.000|950808.447|1409091.640|t|t|t 2.3|994269|12|8|1|0.012|-0.012|0.000|0.000|-107.029|50.206|t|t|t 2.4| 2.5|993310|12|12|1|1009.894|-1009.894|0.000|0.000|950732.188|1409281.783|t|t|t ### end of log dumps ### make[1]: *** [debian/rules:200: override_dh_auto_test] Error 2 make[1]: Leaving directory '/<>/postgis-2.4.4+dfsg' make: *** [debian/rules:111: build] Error 2 Full build log attached. -- Niko Tyni nt...@debian.org postgis_amd64-2018-06-09T14:19:48Z.build.gz Description: application/gzip
Bug#901157: dpkg-dev-el: fails to initialize with unversioned emacs
Package: dpkg-dev-el Version: 36.4 Severity: important User: debian-emac...@lists.debian.org Usertags: unversioned-emacs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer/Uploader; As described in [1], we are currently transitioning to an unversioned "emacs" package; i.e. the actual useful-to-users package will be "emacs" instead of "emacs25" or "emacs26". An unversioned emacs package has been uploaded to experimental. Unfortunately your package does not byte-compile with this new emacs. In addition to the obvious performance impact, this causes your packages to not skip user initialization (since it checks for byte compiled code) One option to fix your package is to convert to dh-elpa, and (optionally) join the debian-emacsen team [1]. Unfortunately dh-elpa does not support xemacs, so if that's important to you, you'll have to find some other solution (i.e. update your maintainer/emacsen scripts by hand). This bug will become RC when unversioned emacs is uploaded to unstable. There is no fixed schedule for this, but please try to address this bug so we can move on to other emacs related maintenance tasks (e.g. new versions of emacs). - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg-dev-el depends on: ii debian-el36.4 ii emacs1:25.2+1-7 ii emacs-gtk [emacsen] 1:25.2+1-7 ii emacsen-common 3.0.0 Versions of packages dpkg-dev-el recommends: ii wget 1.19.5-1 Versions of packages dpkg-dev-el suggests: ii dpkg-dev 1.19.0.5 - -- no debconf information -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlsb670ACgkQ8gKXHaSn nizCeAv+KBAgiZaK+frMeQ6bSywAvly3WIpB760odACZV7PdBU4dekpA8M9O6Yvt XczfZuXFdzZDKjsEM4G4QZQDdYWnWHBQpDv8qo+D0kWWizbD6Z9H1Cx0t+WRJ87C RbcHWhzne/j3/7LWNKebJngLctuhF5iUkVhKsKBw1HUF6xVm00snG5PlfCef8t3B TYb0afqwWCXmW+nr64UpB3ihlPBBEnKF6Tg/mqy0sUOHPnLme/C+BEGO2uzXOLJS Fls5Y3z3grp8wxIpASt6gzpwfC70Z3gcX5GvbTHA9EnyhPYOUWyZvWdCI//ciWF7 b+g/Ufu5jNc1VE9b96Pmake2XKey4epR/KTIuLh8oIvLbu2rfGPqCAMIKFSBK1kc j8v6UI3uHG0B9IYG0pNhXm+HGCAGOz0mpOPlSfPdDq1C7WsgGL0Jr6xaDk4Mg4aC TvtjDfdr3fLM7rFKzF8nA76LEgHgNrMi61KvNHsfYPtI+ewX8Fm+4D5HAI1lVVDV k+mu+qMK =cNt9 -END PGP SIGNATURE-
Bug#901156: double invocation of "rsnapshot beta" causes "beta" rotation without adding backup data
Package: rsnapshot
Version: 1.4.2-1
Severity: normal
Tags: patch
Problem: the robustness of rsnapshot program under desktop environment
when cron is not always running and "beta" may be invoked consecutively
without invoking "alpha".
(I am using Debian/stable now but the version in testing/unstable is the same)
How to re-produce problem:
Let me present a simple manual invocation case as below (No
cron/anacron/systemd.timer...):
With /etc/rsnapshot.conf having:
---
retain alpha 6
retain beta7
retain gamma 4
---
Let's invoke:
---
$ sudo rsnapshot alpha
---
Invoking this 6 times will create:
/var/cache/rsnapshot/alpha.0/
/var/cache/rsnapshot/alpha.1/
/var/cache/rsnapshot/alpha.2/
/var/cache/rsnapshot/alpha.3/
/var/cache/rsnapshot/alpha.4/
/var/cache/rsnapshot/alpha.5/
So far, this looks good. Then, let's invoke:
---
$ sudo rsnapshot beta
---
Invoking this will create:
/var/cache/rsnapshot/alpha.0/
/var/cache/rsnapshot/alpha.1/
/var/cache/rsnapshot/alpha.2/
/var/cache/rsnapshot/alpha.3/
/var/cache/rsnapshot/alpha.4/
/var/cache/rsnapshot/beta.0/
So far still good. Let's suppose to invoke the following again and see
the result:
---
$ sudo rsnapshot beta
/var/cache/rsnapshot/alpha.5 not present (yet), nothing to copy
---
This message is true but the result is a bit unexpected:
/var/cache/rsnapshot/alpha.0/
/var/cache/rsnapshot/alpha.1/
/var/cache/rsnapshot/alpha.2/
/var/cache/rsnapshot/alpha.3/
/var/cache/rsnapshot/alpha.4/
/var/cache/rsnapshot/beta.1/
Why beta.0 is missing ???
What happens is delete and rotate actions for "beta" is performed then
it fails to move file from "alpha.5" to "beta.0". Rotating without new
data added to "*.0" is bad. It should not do this delete and rotate
actions if "alpha.5" isn't there.
I am afraid this problem may be the root cause of many unexpected
results under non-optimal invocation of rsnapshot.
https://bugs.debian.org/523923
https://bugs.debian.org/573254
Backup script should be robust ;-)
Solution proposal:
Let's check situation with:
-d "$config_vars{'snapshot_root'}/$prev_interval.$prev_interval_max")
If not exist, "delete" and "rotate" should be skipped.
See attached patch file (patch -p0) for exact detail.
This may be better to be addressed by the upstream.
Osamu
-- System Information:
Debian Release: 9.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages rsnapshot depends on:
ii liblchown-perl 1.01-3+b2
ii logrotate 3.11.0-0.1
ii perl5.24.1-3+deb9u3
ii rsync 3.1.2-1+deb9u1
Versions of packages rsnapshot recommends:
ii openssh-client [ssh-client] 1:7.4p1-10+deb9u3
rsnapshot suggests no packages.
-- Configuration Files:
/etc/rsnapshot.conf changed:
config_version 1.2
snapshot_root /var/cache/rsnapshot/
cmd_cp /bin/cp
cmd_rm /bin/rm
cmd_rsync /usr/bin/rsync
cmd_logger /usr/bin/logger
cmd_du /usr/bin/du
cmd_rsnapshot_diff /usr/bin/rsnapshot-diff
retain alpha 6
retain beta7
retain gamma 4
verbose 2
loglevel3
logfile /var/log/rsnapshot.log
lockfile/var/run/rsnapshot.pid
du_args -csh
link_dest 1
backup /home/ localhost/
backup /etc/ localhost/
backup /usr/local/ localhost/
-- no debconf information
--- rsnapshot-program.pl.orig 2018-06-09 23:14:10.0 +0900
+++ rsnapshot-program.pl 2018-06-09 23:17:47.010919314 +0900
@@ -4666,9 +4666,8 @@
# ROTATE DIRECTORIES
#
- # delete the oldest one (if we're keeping more than one)
- if (-d "$config_vars{'snapshot_root'}/$interval.$interval_max") {
-
+ # delete the oldest one (if we're keeping more than one), if needed
+ if ((-d "$config_vars{'snapshot_root'}/$prev_interval.$prev_interval_max") and (-d "$config_vars{'snapshot_root'}/$interval.$interval_max")) {
# if use_lazy_deletes is set move the oldest directory to _delete.$$
# otherwise preform the default behavior
if (1 == $use_lazy_deletes) {
@@ -4703,35 +4702,45 @@
}
}
- else {
+ elsif (-d "$config_vars{'snapshot_root'}/$prev_interval.$prev_interval_max") {
print_msg(
"$config_vars{'snapshot_root'}/$interval.$interval_max not present (yet), nothing to delete", 4);
}
+ else {
+ print_msg(
+ "$config_vars{'snapshot_root'}/$interval.$prev_interval_max not present (yet), no need to delete $config_vars{'snapshot_root'}/$interval.$interval_max", 4);
+ }
# rotate the middle ones
- for (my $i = ($interval_max - 1); $i >= 0; $i--) {
- if (-d "$config_vars{'snapshot_root'}/$interval.$i") {
- print_cmd(
-"mv $config_vars{'snapshot_root'}/$interval.$i/ ",
-"$config_vars{'snapshot_root'}/$interval." . ($i + 1) . "/"
- );
-
- if (0 ==
Bug#896141: msxpertsuite: binary-all FTBFS
While we are at it: Is this bug not already fixed? https://buildd.debian.org/status/package.php?p=msxpertsuite If it is, please close it with a Version string. Thanks.
Bug#901155: transition: octave-4.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-octave.html Dear Release Team, Please schedule a transition for octave 4.4. The new package is already in experimental. Few reverse dependencies will need sourceful NMUs. In any case, we stand ready to NMU. Thanks! -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#896141: msxpertsuite: binary-all FTBFS
retitle 896141 msxpertsuite: FTBFS with new Tex Live packages thanks Hi. The package FTBFS with and without "dpkg-buildpackage -A" so I'm dropping the binary-all part from the subject. (The old title was a little bit misleading to me since I am also occasionally building the entire archive to catch those "dpkg-buildpackage -A" bugs). > > See the inputenc package documentation for explanation. > > Type H for immediate help. > > ... > > l.122 ...\'Ecole Polytechnique} (Institut Européen > > de > > ./preface.tex:122: ==> Fatal error occurred, no output PDF file produced! > > Transcript written on massxpert-doc.log. > > Why doesn't the build stop at that point? Very good point. I've just reported that separately as Bug #901154. I guess that's probably the reason it fails in a different way depending on "dpkg-buildpackage -A" being used or not. Thanks.
Bug#901154: msxpertsuite: Does not trap errors in upstream Makefile
Package: msxpertsuite Version: 5.3.0-1 Severity: serious In Bug #896141, where the build fails because of new Tex Live, Adrian Bunk points out why the build process does not stop as soon as there is an error. Quote: > > ./preface.tex:122: ==> Fatal error occurred, no output PDF file produced! > > Transcript written on massxpert-doc.log. > > Why doesn't the build stop at that point? This is in fact a violation of Policy 4.6, "Error trapping in makefiles": https://www.debian.org/doc/debian-policy/#error-trapping-in-makefiles so I'm reporting it here separately. I have not tested it, but maybe the fix could be as easy as removing the hyphen prefix from pdflatex command in these two Makefiles: massxpert/user-manual/Makefile minexpert/user-manual/Makefile Thanks.
Bug#901153: gnome-software: Displays binNMU upgrades as "Downgrades"
Package: gnome-software Version: 3.28.2-1 Severity: normal See attachment -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-software depends on: ii appstream0.12.0-3 ii apt-config-icons 0.12.0-3 ii dconf-gsettings-backend [gsettings-backend] 0.28.0-2 ii gnome-software-common3.28.2-1 ii gsettings-desktop-schemas3.28.0-1 ii libappstream-glib8 0.7.7-2 ii libatk1.0-0 2.28.1-1 ii libc62.27-3 ii libcairo21.15.10-3 ii libfwupd21.0.8-1 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libglib2.0-0 2.56.1-2 ii libgnome-desktop-3-173.28.2-1 ii libgspell-1-11.6.1-1 ii libgtk-3-0 3.22.30-1 ii libgtk3-perl 0.034-1 ii libgudev-1.0-0 232-2 ii libjson-glib-1.0-0 1.4.2-4 ii libpackagekit-glib2-18 1.1.10-1 ii libpolkit-gobject-1-00.105-20 ii libsecret-1-00.18.6-2 ii libsoup2.4-1 2.62.2-1 ii packagekit 1.1.10-1 ii software-properties-gtk 0.96.20.2-1 gnome-software recommends no packages. Versions of packages gnome-software suggests: pn apt-config-icons-hidpi pn fwupd pn gnome-software-plugin-flatpak pn gnome-software-plugin-limba pn gnome-software-plugin-snap -- no debconf information
Bug#901152: fbxkb FTCBFS: uses the build architecture toolchain
Source: fbxkb Version: 0.6-2 Tags: patch User: helm...@debian.org Usertags: rebootstrap fbxkb fails to cross build from source, because it uses the build architecture toolchain. While it does use dh_auto_build, the autoconf build system expects that compilers are set up during dh_auto_configure and thus doesn't pass them for dh_auto_build. In a way fbxkb's build system is more like a makefile build system as configure only sets up some paths. Thus I propose using --buildsystem=makefile to pass those cross compilers along. Still the upstream build system hard codes the build architecture pkg-config. After fixing both, fbxkb cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru fbxkb-0.6/debian/changelog fbxkb-0.6/debian/changelog --- fbxkb-0.6/debian/changelog 2014-11-05 16:38:59.0 +0100 +++ fbxkb-0.6/debian/changelog 2018-06-09 15:40:39.0 +0200 @@ -1,3 +1,12 @@ +fbxkb (0.6-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ cross.patch: make pkg-config substitutable. ++ Use the makefile build system as configure does not set up compilers. + + -- Helmut Grohne Sat, 09 Jun 2018 15:40:39 +0200 + fbxkb (0.6-2) unstable; urgency=low * New maintainer (Closes: #767970) diff --minimal -Nru fbxkb-0.6/debian/patches/cross.patch fbxkb-0.6/debian/patches/cross.patch --- fbxkb-0.6/debian/patches/cross.patch1970-01-01 01:00:00.0 +0100 +++ fbxkb-0.6/debian/patches/cross.patch2018-06-09 15:40:39.0 +0200 @@ -0,0 +1,14 @@ +--- fbxkb-0.6.orig/Makefile.common fbxkb-0.6/Makefile.common +@@ -20,8 +20,9 @@ + endif + + CC = gcc +-LIBS = -lX11 $(shell pkg-config --libs gtk+-2.0 gdk-pixbuf-2.0 gdk-pixbuf-xlib-2.0) -L/usr/X11R6/lib -lXmu +-INCS = $(shell pkg-config --cflags gtk+-2.0 gdk-pixbuf-2.0 gdk-pixbuf-xlib-2.0) ++PKG_CONFIG ?= pkg-config ++LIBS = -lX11 $(shell $(PKG_CONFIG) --libs gtk+-2.0 gdk-pixbuf-2.0 gdk-pixbuf-xlib-2.0) -L/usr/X11R6/lib -lXmu ++INCS = $(shell $(PKG_CONFIG) --cflags gtk+-2.0 gdk-pixbuf-2.0 gdk-pixbuf-xlib-2.0) + CFLAGS ?= -O2# overwriten by command line or env. variable + CFLAGS += -Wall # always nice to have + ifneq (,$(DEVEL)) diff --minimal -Nru fbxkb-0.6/debian/patches/series fbxkb-0.6/debian/patches/series --- fbxkb-0.6/debian/patches/series 2014-11-05 14:44:30.0 +0100 +++ fbxkb-0.6/debian/patches/series 2018-06-09 15:40:39.0 +0200 @@ -7,3 +7,4 @@ respect-dpkg-buildflags.patch drop-extra-deps.patch fix-for-dh.patch +cross.patch diff --minimal -Nru fbxkb-0.6/debian/rules fbxkb-0.6/debian/rules --- fbxkb-0.6/debian/rules 2014-11-05 14:33:21.0 +0100 +++ fbxkb-0.6/debian/rules 2018-06-09 15:40:37.0 +0200 @@ -10,7 +10,7 @@ #export DH_VERBOSE=1 %: - dh $@ + dh $@ --buildsystem=makefile override_dh_auto_configure: ./configure --prefix=/usr
Bug#901151: fitsverify FTCBFS: uses the build architecture compiler
Source: fitsverify Version: 4.18-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap fitsverify fails to cross build from source, because it uses the build architecture compiler as a make default. The attached patch makes it cross buildable, by letting dpkg's buildtools.mk set up CC. Please consider applying it. Helmut diff --minimal -Nru fitsverify-4.18/debian/changelog fitsverify-4.18/debian/changelog --- fitsverify-4.18/debian/changelog2016-04-16 23:22:10.0 +0200 +++ fitsverify-4.18/debian/changelog2018-06-09 15:35:32.0 +0200 @@ -1,3 +1,10 @@ +fitsverify (4.18-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dpkg's buildtools.mk set up $(CC). (Closes: #-1) + + -- Helmut Grohne Sat, 09 Jun 2018 15:35:32 +0200 + fitsverify (4.18-1) unstable; urgency=low * New upstream version diff --minimal -Nru fitsverify-4.18/debian/rules fitsverify-4.18/debian/rules --- fitsverify-4.18/debian/rules2016-04-16 23:13:21.0 +0200 +++ fitsverify-4.18/debian/rules2018-06-09 15:35:30.0 +0200 @@ -3,6 +3,8 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +-include /usr/share/dpkg/buildtools.mk + %: dh $@
