Bug#1071675: duplicity: SSH broken with Paramiko 3.4
reassign 1071675 python3-paramiko 3.4.0-1 retitle 1071675 "paramiko: ed25519 broken" tags 1071675 -moreinfo -unreproducible +upstream thanks On Mon, 27 May 2024 10:16:38 -0700, tony mancill writes: >It's happening here too, for backups using an ed25519 SSH key that has >worked with duplicity in the past. thanks for the debug output, that has indeed helped. as far as i can tell that's a bug in paramiko, which was reported late last year: https://github.com/paramiko/paramiko/issues/2320 i'm therefore reassigning this bug to the paramiko package. >(I think >the severity should be important; duplicity fails for one of its primary >use cases.) i disagree, because the ssh/sftp backend is just one of many, and there is a workaround (the pexpect+sftp backend). regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Ah, a Uniform Type Identifier, not a Urinary Tract Infection. Though, reading further in this document I found, I'm not sure there's too much of a difference. -- Jed Davis signature.asc Description: Digital Signature
Bug#1071675: duplicity: SSH broken with Paramiko 3.4
tags 1071675 +moreinfo +unreproducible severity 1071675 normal thanks On Thu, 23 May 2024 18:16:58 +0200, Fiona Klute writes: >When trying to do backup to an sftp:// target Duplicity fails since >python3-paramiko was updated to 3.4.0-1, with the following error which >looks like an API change in Paramiko: i cannot reproduce this problem. please provide the output of a duplicity -v9 run and the ssh key types involved on your target machine. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Q. What kind of a dog says: "bofh! bofh!?" A. A rootweiler. signature.asc Description: Digital Signature
Bug#1060402: liblinux-termios2-perl: FTBFS on ppc64el: OS unsupported - no struct termios2
On Wed, 10 Jan 2024 20:37:37 +0200, Niko Tyni writes: >> This package has never built on riscv64. >Sorry, s/riscv64/ppc64el/ here. > ... >> test-8985-0.c:4:19: error: storage size of ‘t’ isn’t known >>4 | struct termios2 t; >> | ^ >>OS unsupported - no struct termios2 i no idea what is going wrong there. the TCGETS2 syscall (with the associated termios2 structure) was added to the linux kernel many ages ago (in 2.6.20 apparently), and i cannot find any indications anywhere that this isn't supported on all architectures. it's certainly part of the termbits.h and ioctls.h of the linux-libc-dev:ppc64el package... for now i'll tag this package with the archs that seem to work - but a better explanation for the gotcha would be welcome. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Application has reported a "Not My Fault" in module KRNL.EXE in line 0200:103F signature.asc Description: Digital Signature
Bug#1059076: duplicity: --version returns $version, instead of an actual version
On Wed, 20 Dec 2023 15:57:54 -0600, Kenneth Loafman writes: >Duplicity has been this way for a long time. Where do you get your sources >from? launchpad, as long as duplicity lived there. not duplicity.gitlab.io, as that send you nowhere. gitlab, since. anyway, code modified, case closed. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ You possess a mind not merely twisted, but actually sprained. -- BSD fortune file signature.asc Description: Digital Signature
Bug#1059076: duplicity: --version returns $version, instead of an actual version
On Wed, 20 Dec 2023 09:15:05 -0600, Kenneth Loafman writes: >duplicity uses SCM versioning, not the old "mod the code" versioning, i.e. >based on the git tag. You can get the versioned source from GitLab ><https://gitlab.com/duplicity/duplicity/-/releases> under 2.1.4 / Other. well, dear upstream: that's exceedinglu unhelpful. '2.1.4' is plastered all over the normal/visible/everybody-would-expect-that-is-usable release tarball, dirname, setup.py, everywhere except that one crucial spot in __init__ - seriously? that's your official release? >If it's in the Debian repo that way, please alert the maintainer. he has. you're responding to a debian bug. i'll now go back to doing the 'old "mod the code"'. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Politicians are like diapers. They should be changed often, and for the same reason. signature.asc Description: Digital Signature
Bug#1057183: welcome message in 1.8~RC2-2 is always shown (+workaround)
Package: nmh Version: 1.8~RC2-2 Severity: minor the nmh code normally shows a 'welcome to the new version' banner/message once, if it finds an nmh context file with an older nmh version. however, with the release candidate version in bookworm that detection logic fails...and the welcome doesn't go away and becomes very unwelcome. workaround: add Welcome: disable to your ~/.mh_profile.
Bug#1053535: Add support for timestamps with nanoseconds [patch]
severity 1053535 wishlist tags 1053535 + moreinfo thanks On Thu, 05 Oct 2023 21:51:40 +0200, markus writes: >here is a patch to add support for timestamps with nanoseconds for dump >and restore ... >As a consequence dumpfiles (or -tapes) from previous versions >of dump are not compatible with the new version of restore. i'm not at all convinced that this is a useful change, in particular in a backup/restore tool. please provide more information as to what benefits this change is expected to provide, and how those benefits are supposed to outweight the massive downside of complete incompatibility with existing backups. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ "Mary had a little key,/She kept it in escrow/And everything that Mary sent/The Feds were sure to know." -- Sam Simpson signature.asc Description: Digital Signature
Bug#1000693: ITP: libnet-mqtt-simple-perl -- Minimal MQTT version 3 interface
On Wed, 27 Sep 2023 14:53:41 +0200, Roland Mas writes: >No objection at all, I'm even glad that someone takes over where time >prevented me from going forward. very good, thanks. an initial upload should follow in a day or two. >Actually I did prepare a package at that time (see >https://salsa.debian.org/perl-team/modules/packages/libnet-mqtt-simple-perl) >and even pushed an upload that was rejected by FTP-masters because of >ambiguity in the copyright file, i did get in touch with upstream about the...let's say, minimal copyright and licence info that adorns his code, and asked him about maybe publishing a new release with a proper/explicit copyright notice but he is not oo interested in that and instead has indicated that two of his other modules have made it in with exactly that sparse structure...we'll see, fingers crossed. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Surely the 4 sysadmins of the apocalypse should be: edquota, rm -rf, kill -9, and shutdown. -- Rob Blake signature.asc Description: Digital Signature
Bug#1000693: ITP: libnet-mqtt-simple-perl -- Minimal MQTT version 3 interface
On Sat, 27 Nov 2021 11:46:22 +0100, Roland Mas writes: >Package: wnpp >Severity: wishlist >Owner: Roland Mas roland, do have any objections to me taking over this bug and the packaging/maintainership of libnet-mqtt-simple-perl? i do need that package for/at work, a first lintian-clean upload is already ready, and it looks as if there hasn't been any progress since your ITP in 2021. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Application has reported a "Not My Fault" in module KRNL.EXE in line 0200:103F signature.asc Description: Digital Signature
Bug#1052369: lib/finit/reboot should be shipped by finit-sysv, if at all
Package: finit-sysv Version: 4.2-1 Severity: normal all the normal frontends for initctl EXCEPT reboot are shipped by finit-sysv, where they make good sense. however, reboot is shipped as /lib/finit/reboot by the main finit package which makes no sense (after all finit's reboot won't work unless finit is the active init system, which it likely won't be until finit-sysv is installed); furthermore that oddball symlink then gets replumbed as yet another symlink from /sbin/reboot to /lib/finit/reboot (to ...) by finit-sysv. not only is /lib/finit/reboot the wrong location (it's to be invoked by the admin), it's very also inconsistent compared to all the other frontend links. i would suggest to change the symlinks for /sbin/halt, poweroff, shutdown and reboot all be made direct ones to /sbin/initctl, and that the /lib/finit/reboot (symlink to initctl) is removed altogether, and that finit should not deal with any of these, only finit-sysv.
Bug#1052368: initctl is installed in the wrong location
Package: finit Version: 4.2-1 Severity: normal Tags: patch initctl is supposed to be installed in /sbin, as it is vital for the admin to invoke and should thus be in the standard path (as also indicated by its manpage). however, your packaging logic currently installs it in /lib/finit/initctl. the following small patch fixes that one --- debian/finit.install2022-01-22 23:23:43.0 +1000 +++ debian/finit.install-lessbad2023-09-21 13:03:18.471568436 +1000 @@ -2,7 +2,7 @@ lib/finit/logit lib/finit/sulogin sbin/finit -sbin/initctl lib/finit/ +sbin/initctl sbin/reboot lib/finit/ lib/*/finit/rescue.conf lib/finit/ contrib/debian/finit.conf etc/
Bug#1052367: watch file doesn't work
Source: finit Severity: normal Tags: patch this is related to #1019696, which explains why normal github watchfiles have stopped working sometime last year. finit's watch file falls into the no-longer-working category and doesn't find any releases whatsoever. the following suggested replacement watch file works (even with oldstable's devscripts), and does indicate that there are some newer versions that await packaging (4.3 in particular is marked a critical bugfix release). ---cut--- version=4 opts="searchmode=plain,\ filenamemangle=s%v?@ANY_VERSION@%@PACKAGE@-$1.tar.xz%,\ uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha|a|b)\d*)$/$1~$2/" \ https://api.github.com/repos/troglobit/finit/releases?per_page=50 \ https://api.github.com/repos/[^/]+/[^/]+/tarball/v?@ANY_VERSION@ ---cut---
Bug#1034861: ITP: libanyevent-riperedis-perl -- Flexible non-blocking Redis client
Package: wnpp Severity: wishlist Owner: Alexander Zangerl X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libanyevent-riperedis-perl Version : 0.48 Upstream Author : Eugene Ponizovsky, * URL : https://metacpan.org/release/AnyEvent-RipeRedis * License : Artistic or GPL-1+ Programming Lang: (pure) Perl Description : Flexible non-blocking Redis client This module provides a flexible non-blocking Redis client which supports subscriptions, transactions and automatic reconnection. i'm packaging this because the sole alternative package in debian (libanyevent-redis-perl) has fewer features, is buggier and has an inactive upstream with a near-zero chance of fixes (e.g. open issues and pull requests going back to 2013).
Bug#1032965: Upstream 1.2.2 with Prelim Packaging
severity 1032965 wishlist thanks On Tue, 14 Mar 2023 21:16:50 +, "Barak A. Pearlmutter" writes: >Please let me know if there's anything else I can do to help get >duplicity updated; please give me about two weeks to update the duplicity package. (i got sick of upstream's jumping around like headless chickens and decided to not follow their bleeding edge mess too closely.) -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Fachbegriffe der Informatik, Urinstinkte: Mail ... News ... Dilbert -- Lars Marowsky-Bree signature.asc Description: Digital Signature
Bug#1032097: ITP: libpromise-xs-perl -- Fast promises in Perl
Package: wnpp Severity: wishlist Owner: Alexander Zangerl X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libpromise-xs-perl Version : 0.18 Upstream Author : Tom van der Woerdt , Felipe Gasper https://metacpan.org/release/Promise-XS * License : Artistic Programming Lang: Perl, C Description : Fast promises in Perl This module provides a Promises/A+ interface with its major parts implemented in XS for speed. It is a fork and refactor of AnyEvent::XSPromises, and retains that module's bare-bones interface. This is one of a few Promises implementations in perl, none of which have made it into debian yet. i think it's time to change that.
Bug#1029752: tests fail with nmh 1.8~RC-2, blocking nmh from entering testing
severity 1029752 normal thanks to expand on this issue a little: the autopkgtest is legitimately indicating a regression in nmh, where a set-but-empty $HOME is treated differnt (= as fatal exception) from an unset $HOME variable. this has triggered a long discussion on upstream's mailing list about the desirable/least-surprising behaviour. stephen's already adjusted xlbiff's behaviour for greater robustness in a pending release. for consistency i've also addressed this in nmh version 1.8~RC2-2, which falls back to getpw*() for both set-but-empty and unset $HOME. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ > Hi, my name is Rebecca, and I'm a computing whore. -- Rebecca Gray If I pay you twenty bucks, will you blow my EPROM? -- Joe signature.asc Description: Digital Signature
Bug#1029752: tests fail with nmh 1.8~RC-2, blocking nmh from entering testing
Package: xlbiff Version: 4.6.3-1 Severity: important xlbiff's autopkgtests fail (silently) with nmh 1.8, which means that version of nmh cannot enter testing. the autopkgtest "regression" log files are devoid of any useful information, so i cannot pinpoint *what* in xlbiff fails, but something is broken.
Bug#1029573: gnuserv: hangs while installing if xemacs21 is installed
On Tue, 24 Jan 2023 18:42:07 +0100, Andreas Beckmann writes: >during a test with piuparts I noticed your package failed to install. *agh* >This is an automated install test with DEBIAN_FRONENT=noninteractive and >stdin coming from /dev/null which got killed after reaching a timeout, > so there is no log output :-( no problem, i'm relatively certain i know roughly where the gotcha is; should get fixed tonight or tomorrow. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Fachbegriffe der Informatik, Updateitis: Softwarebulemie -- Frank Klemm signature.asc Description: Digital Signature
Bug#1022982: mark libfile-slurp-perl Multi-Arch: foreign
unblock 1022982 by 749826 thanks On Sat, 29 Oct 2022 07:47:43 +0200, Helmut Grohne writes: >Does this count as authoritative documentation to you? a policy change that hasn't made it in in 8+ years (and has been dead w/o even the minutest twitches for 5 years) is not what i'd normally call authoritative, but if adjusting file::slurp a little has the potential to improve matters downsteram then so be it. done. >Feedback on these texts (in particular on how easy they are to >understand) would be very welcome. i have no problems with the textual description. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ IBM: It may be slow, but it's hard to use. -- Simon Cozens signature.asc Description: Digital Signature
Bug#1022982: mark libfile-slurp-perl Multi-Arch: foreign
On Fri, 28 Oct 2022 16:51:17 +0200, Helmut Grohne writes: >Please consider applying the attached patch. not until somebody points me to some authoritative documentation of this multi-arch field. (and no, wikis in ubuntu-land don't count.) -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ "Die Majorität der Dummen ist unüberwindbar und für alle Zeiten gesichert." -- Albert Einstein signature.asc Description: Digital Signature
Bug#1021803: gnuserv FTBFS with emacs 28
tags 1021803 + unreproducible retitle 1021803 "gnuserv seems to be affected badly by #1017739" thanks On Sat, 15 Oct 2022 06:25:57 +0300, Adrian Bunk writes: >Source: gnuserv >Version: 3.12.8-8 >Severity: serious >Tags: ftbfs >Control: block 1020050 by -1 >Debugger entered--Lisp error: (error "Cannot find suitable directory for >output in 'nati...") i cannot reproduce this: the package builds fine in a blank pbuilder chroot. however, searching for 'cannot find suitable directory...' returns other reports about emacs 28 itself being the party that stuffs up, in particular https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017739 right now i have no idea how to work around this issue, as i cannot reproduce the build fault at all. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. -- Edward Snowden signature.asc Description: Digital Signature
Bug#1012389: duplicity: Can't backup anymore - AssertionError
severity 1012389 normal forwarded 1012389 https://bugs.launchpad.net/duplicity/+bug/140 tags 1012389 + moreinfo thanks On Mon, 06 Jun 2022 10:50:27 +0200, Christophe Lohr writes: ... >in get_sorted_chains >assert len(chain_list) == 2 > AssertionError looks like you've run into yet another long-unfixed problem that upstream is ignoring; see the link to the upstream bug report. apparently long-running and/or often-retried backups can lead to duplicity losing its smarts. >What's wrong? i don't know. > What should I do? i suspect you might get somewhere with a clean slate, ie. after renaming all of your current backups *and* the cache directories. to go any further it'll be necessary that you a) report your full duplicity invocation (without that i have no clue what backend you're using, whether this was a full backup only or incremental or whatever) and b) reproduce the problem from a clean state, run duplicity with -v9 and provide the resulting log as well (minus personal/private information). -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ The determined programmer can write a FORTRAN program in any language. signature.asc Description: Digital Signature
Bug#737564: dump should accomodate backups of media named by their UUID
retitle 737564 dump: change dumpdates to support incrementals by UUID=blah thanks doing backups for uuid- and label-backed devices has worked since the switch to libblkid (roughly around 2004), ie. "dump -0f someplace UUID=whatever" and "dump -0f otherplace LABEL=tagyoureit" has and does work fine. there are two uuid-related issues: a) the documentation isn't uptodate, files-to-dump in dump.8 only says mountpoint or device, and doesn't mention what libblkid gained us, ie. it doesn't mention looking up devices by TOKEN=value. that is easy to fix and i'll take care of that on the next upload. b), which is the core of this bug report - dumpdates always only saves the device name, hence doesn't find reordered devices. i think the least messy way out is to rework the dumpdates stuff to stop canonicalising the memorised device name, and instead park whatever the user gave us for the device lookup. ie: if you dump -u /dev/sdy then "/dev/sdy" will be saved, just as before, but if you dump -u LABEL=foobardiddly then dumpdates will hold "LABEL=foobardiddly". pro: 100% backwards compatible, and minimal amount of code change. contra: you cannot mix incremental dumps of /dev/sdxyz with UUID=whatever and expect dump to find one by the other. i think that's quite acceptable a limitation, as long as it makes it into the documentation. i'll be working on this Real Soon Now(tm). regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Never trust a computer you can't throw out the window. - S. Hunt signature.asc Description: Digital Signature
Bug#1010153: nmh: Please replace mime-support with media-types in Depends
On Mon, 25 Apr 2022 21:36:40 +0900, Charles Plessy writes: >May I ask you to replace mime-support with media-types in nmh's Depends ? sure, i'll update that on the next build. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, E-Learning: Feststellung, daß Strom weh tut. -- Oliver Schad signature.asc Description: Digital Signature
Bug#1007215: solved/workaround
severity 1007215 minor retitle 1007215 duplicity: document optional not-quite-dependencies better thanks On Sun, 13 Mar 2022 16:01:36 -0400, Paul Galbraith writes: >After the following steps, duplicity is now working for me >with a b2 backend (I didn't try reinstalling backblaze-b2): hmm, i've got no really good idea what to do about this relationship between duplicity and the very very optional backblaze module(s). as far as i'm aware there's no easy way for the package management system to specify a conditional relationship like 'if you want to use duplicity with backblaze then you need python3-b2sdk'. i'm certainly not going to make duplicity depend on python3-b2sdk because it's not needed for most users of the package. i guess i'll have a look at adding something to the news and readme files and shipping upstream's requirements.txt as part of the docs (as that document lists the python module names needed for various backends). regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "Unterschätze nie die Macht dummer Leute, die einer Meinung sind." -- Kurt Tucholsky signature.asc Description: Digital Signature
Bug#1007574: libyaml-shell-perl: please consider upgrading to 3.0 source format
On Tue, 15 Mar 2022 08:52:00 +0100, Lucas Nussbaum writes: >This package is among the few (1.9%) that still use source format 1.0 in >bookworm. Please upgrade it to source format 3.0, as (1) this format has many >advantages, i refuse. i will not spend my time on make-work like this while format 1.0 is not prohibited. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, Shockwave Flash: Augenkrebs -- FvL signature.asc Description: Digital Signature
Bug#1004417: -o docs is nonexistent and should be removed from code and manual page
Package: foomatic-filters
Version: 4.0.17-11
Severity: normal
the logic for PPD documentation extraction and presentation that was
present in foomatic 3.x was never migrated to the new codebase of versions 4.x.
however, the foomatic-rip manual page still states that you can get
a printout of the PPD options with "-o docs". this is misleading and incorrect
and should be removed.
the code in foomaticrip.c that is supposed to "Print documentation page
when asked for" (line 1460 or thereaboutes) doesn't and cannot, because
two lines down the track it just says
/* Start the documentation page generator */
/* TODO tbd */
ie. there IS no documentation page generator - and the rest of the code then
builds up a really broken environment with a call out to a2ps & co (as per
bug 776315) and no input to those.
as upstream is clearly not inclined to do any work on stuff they left by the
wayside when the rewrote foomatic-rip multiple years ago, the '-o docs' option
should be rejected and not be allowed to cause this misleading mess.
however, if anybody does want that nice PPD option listing that the old
foomatic-rip gave us, here you are: i just recreated a cut down minimal version
of said PPD documentation extractor and presenter, which you find attached.
feel free to ship it in docs/contrib, it's under GPL 2.
#!/usr/bin/perl
# $Id$
#
# File: ppd-doc-extractor
# Date: 27 Jan 2022 16:28:17
# Author: Alexander Zangerl
#
# Abstract:
#very minimal recreation of the PPD documentation extractor
#of foomatic-rip 3.x (which you got with foomatic-rip -o docs), which
#is not part of the rewritten 4.x versions despite the documentation's
#claims and the broken option code that doesn't reject what it cannot
#handle.
#
# copyright (c) 2022 Alexander Zangerl
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2
# as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
use strict;
use File::Slurp;
use Data::Dumper;
my ($ppdfile,@a2ps) = @ARGV;
die "usage: $0 [a2ps args]\n
no a2ps args: print to stdout
automatically added: --center-title, --footer\n\n" if (!-f $ppdfile);
my @stuff = read_file($ppdfile);
# parse everything but massage and handle just the relevant parts
my (%x, $curopengroup);
for (my $i = 0; $i <= $#stuff; ++$i)
{
my $line = $stuff[$i];
$line =~ s/\r\n$//; # de-dos
chomp $line;
my ($key, $value, $option, $xlatoption);
next if ($line =~ /^(\*%.*)?$/ or $line eq "*End");
if ($line =~ /^\*([^:]+):\s*(.+)\s*$/)
{
($key, $value) = ($1,$2);
if ($key =~ /^(\S+)\s+(.+)$/)
{
$key = $1;
$option = $2;
if ($option =~ m!^([^/]+)/(.+)$!)
{
($option,$xlatoption) = ($1,$2);
undef $xlatoption if ($xlatoption eq $option); # unnecessary ones
}
}
# invocationvalue and quotedvalue allow continuation
if ($value =~ /^"([^"]+)"\s*$/)
{
$value = $1;
}
elsif ($value =~ /^"([^"]*)*$/)
{
$value = $1;
while ((my $nextline = $stuff[++$i]) !~ /"/)
{
$value .= $nextline;
}
if ($stuff[$i] =~ /^([^"]+)"\s*$/)
{
$value .= $1;
}
}
# orderdependency is laid out extraspecially stupidly
if ($key =~ /^(NonUI)?OrderDependency$/)
{
$key = "OrderDependency"; # we lump these together
my ($num,$dontcare,$appliesto) = split(/\s+/,$value);
($option = $appliesto) =~ s/^\*//;
$value = $num;
}
# want the options under openui w/o fluff
elsif ($key eq "OpenUI")
{
$option =~ s/^\*//;
}
# another instance of shitty structural layout
elsif ($key eq "OpenGroup")
{
if ($value =~ m!^\s*(\S+)/(.+)$!)
{
($option,$xlatoption) = ($1,$2);
}
else
{
$xlatoption = $option = $value;
}
$curopengroup = $value = $option;
}
elsif ($key eq "CloseGroup")
{
undef $curopengroup;
}
if (defined $option)
{
# for option entries add a sequence number for sorting - simply use the
line number
$x{$key}->{$option} = { xlat => $xlatoption,
value => $value,
sequence => $i,
ingroup => $curopengroup, };
}
else
{
$x{$key} = $value;
Bug#776315: foomatic-filters: foomatic-rip can't properly execute text filters
On Mon, 26 Jan 2015 18:34:44 +, Martín Ferrari writes:
>Following with strace, I see that foomatic-rip is incorrectly executing
>commands in the shell:
>
>[pid 13859] execve("/bin/bash", ["/bin/bash", "-c", "mpage -o -1 -b Letter -H
>-h Documentation for the Lexmark X792 Foomatic/Postscript -m36l36b36t36r -f -P-
>-"], [/* 38 vars */]) = 0
this can be fixed by changing just one line in fileconverters.c;
if the @@JOBTITLE@@ placeholder is prefixed by '\"' (and only prefixed),
then the argument prep logic wraps it suitably. (it's still a
pretty ugly mess, what with unnecessary detours via a shell but
that's a separate story.)
the attached patch makes that change, and a quick check with strace confirms
that a2ps is now called correctly:
25389 execve("/bin/bash", ["/bin/bash", "-c", "a2ps -1 --medium=A4dj
--center-title=\"Documentation for the Ricoh SP C250DN PS\" -o -"],
0x7fffc24477b8 /* 38 vars */
...
25389 execve("/usr/bin/a2ps", ["a2ps", "-1", "--medium=A4dj",
"--center-title=Documentation for the Ricoh SP C250DN PS", "-o", "-"],
0x55f407b0f1b0 /* 37 vars */) = 0
>At the same time, I don't see any code generating the docs I am looking for, it
>seems commented out. So maybe that is also broken?
yes, it's nonexistent: they never migrated the documentation extraction code
from version 3.x's perl (where it was very simple to do) to version 4.x's c
codebase (where it's a bit more work) - but the did leave the
broken/incomplete '-o docs' in the code and the documentation :-(
i recreated something not entirely unlike that doc extractor earlier today
and will submit it in a separate bug regarding the misleading docs and
code leftovers.
--- a/fileconverter.c
+++ b/fileconverter.c
@@ -37,9 +37,9 @@
* is not set. (Except if the spooler is CUPS, then 'texttops' is used
*/
const char *fileconverters[][2] = {
-{ "a2ps", "a2ps -1 @@--medium=@@PAGESIZE@@ @@--center-title=@@JOBTITLE@@ -o -" },
+{ "a2ps", "a2ps -1 @@--medium=@@PAGESIZE@@ @@--center-title=\"@@JOBTITLE@@ -o -" },
{ "enscript", "enscript -G @@-M @@PAGESIZE@@ @@-b \"Page $%|@@JOBTITLE@@ --margins=36:36:36:36 --mark-wrapped-lines=arrow --word-wrap -p-" },
-{ "mpage", "mpage -o -1 @@-b @@PAGESIZE@@ @@-H -h @@JOBTITLE@@ -m36l36b36t36r -f -P- -" },
+{ "mpage", "mpage -o -1 @@-b @@PAGESIZE@@ @@-H -h \"@@JOBTITLE@@ -m36l36b36t36r -f -P- -" },
{ "paps", "paps @@--paper @@PAGESIZE@@ --header --font=11.5" },
{ NULL, NULL }
};
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, GNU: GNU is Not Useful, ohne Windows
oder Linux darunter. -- Uwe Ohse
signature.asc
Description: Digital Signature
Bug#1002675: re hubic/pyrax problem
fabrice, upstream has reported that the problem you're encountering is pretty much certainly not coming from duplicity but pyrax - which is deprecated and no longer being maintained. upstream requests the log of a duplicity run with full -v9 logging/debugging on in order to track this down any further. if you can provide such a log the chances of getting this sorted out will rise a bit. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Q. what do you get whan you cross a tsetse with a mountain climber? A. nothing, you can't cross a vector with a scalar. signature.asc Description: Digital Signature
Bug#996577: fixed in duplicity 0.8.21-1
clone 996577 -1 retitle -1 hubic backend: init fails with a type error thanks On Sun, 26 Dec 2021 16:53:12 +0100, Fabrice Lamareille writes: >Unfortunately, the hubic backend does not seem to work yet. I now get >the following error: > >Connection failed, please check your credentials: TypeError __init__() >got an unexpected keyword argument 'username' i'll forward your new bug report upstream, but don't hold your breath: the hubic service seems to be mostly if not quite entirely dead for multiple years now, so interest in supporting that is not likely to be high. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "Any sufficiently advanced political correctness is indistinguishable from irony." -- Erik Naggum signature.asc Description: Digital Signature
Bug#998456: duplicity: b-d on python3-all-dev, but not built for all supported Python3 versions
On Thu, 04 Nov 2021 16:39:09 +0200, Graham Inggs writes: >Please either replace the b-d python3-all-dev with python3-dev, python policy 7.1: "The python3-all-dev should be used when building extensions for any or all Python 3 versions" >or build for all supported Python3 versions. what undocumented magic do you expect me to bake for doing this? the package already uses dh $@ --with python3 --buildsystem=pybuild what more do you want? -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ My name is sendmail.cf. You killed my process. Prepare to vi. signature.asc Description: Digital Signature
Bug#995996: dump: segfaults on long paths
On Sat, 09 Oct 2021 19:06:21 +0200, наб writes: ... ># mkdir -p /tmp/img.d/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a 2030+ levels deep. >Picking Severity: important, because this means it's /impossible/ to >restore (or even view!) a valid dump. sorry, but i disagree. yes, it is a bug. but no, it is not severity important: a 2000+ levels deep directory hierarchy has no practical relevance whatsoever. and a workaround exists: don't create ridiculously deep hierarchies ;-) naturally i'll have a look at what's going wrong here, and whether there is a chance of surviving a pretty hopeless situation like this; don't hold your breath, however. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ I came, I saw, I deleted all your files. signature.asc Description: Digital Signature
Bug#995992: dump: restore errors out when restoring to a directory with non-power-of-two st_blksize
On Sat, 09 Oct 2021 18:33:35 +0200, наб writes: >I'm attaching a patch that instead of erroring out just resets it to >MAXBSIZE because thanks for spotting this. i'll have a new release ready in a day or two. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Application has reported a "Not My Fault" in module KRNL.EXE in line 0200:103F signature.asc Description: Digital Signature
Bug#993336: libclass-trait-perl: arch:all but depends on perlapi-5.32.0
On Tue, 31 Aug 2021 00:53:09 +0300, Niko Tyni writes: >Package: libclass-trait-perl i've requested removal of that package (#993410). regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ In German, a young lady has no sex, while a turnip has. Think what overwrought reverence that shows for the turnip, and what callous disrespect for the girl. -- Mark Twain signature.asc Description: Digital Signature
Bug#993410: RM: libclass-trait-perl -- ROM; deprecated upstream, development ceased ages ago
Package: ftp.debian.org Severity: normal i'd like to request the removal of libclass-trait-perl from debian. it's marked as deprecated and dead by upstream, and only libtm-perl needs it and i've requested removal of that package, too.
Bug#993411: RM: libtm-perl -- ROM; ancient, buggy, development has ceased
Package: ftp.debian.org Severity: normal i'd like to request that libtm-perl be removed from debian. upstream has stopped working on the code ages ago, it's somewhat incomplete and buggy and not worth bothering with anymore. topicmaps as a concept are dead.
Bug#991784: kuvert FTCBFS: builds for the build architecture
On Sun, 01 Aug 2021 20:30:37 +0200, Helmut Grohne writes: >kuvert fails to cross build from source, because it does not pass cross >tools to make. The easiest way of doing so - using dh_auto_build - makes >kuvert cross buildable. Please consider applying the attached patch. thanks for the note, i'll take care of this within a day or two. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "One World, One Web, One Program" - Microsoft Promotional Ad "Ein Volk, Ein Reich, Ein Führer" - Adolf Hitler signature.asc Description: Digital Signature
Bug#968072: ITP: libdata-downsample-largesttrianglethreebuckets-perl -- Perl module for downsampling time series for visual representation
Package: wnpp Severity: wishlist Owner: Alexander Zangerl * Package name: libdata-downsample-largesttrianglethreebuckets-perl Version : 1.00 Upstream Author : Steve Troxel * URL : https://metacpan.org/release/Data-DownSample-LargestTriangleThreeBuckets * License : Artistic 2 Programming Lang: Perl Description : Perl module for downsampling time series for visual representation This module implements a downsampling technique known as Largest Triangle Three Buckets, which aims at retaining the visual character of the plotted data even at very much reduced data set size. The technique is described in detail in Sveinn Steinarsson's thesis which can be found at https://skemman.is/handle/1946/15343
Bug#968070: ITP: liblinux-termios2-perl -- Perl module for accessing the termios2 structure and ioctl
Package: wnpp Severity: wishlist Owner: Alexander Zangerl * Package name: liblinux-termios2-perl Version : 0.01 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Linux-Termios2 * License : same as Perl - GPL 1+ or Artistic Programming Lang: Perl, C Description : Perl module for accessing the termios2 structure and ioctl This module provides an API equivalent to the POSIX::Termios class, but backed by the Linux-specific struct termios2 structure instead. The primary use case is setting arbitrary baud rates, because POSIX::Termios only knows the standard speeds up to 38400 baud.
Bug#949389: nmh: after version upgrade, mh_build not run on outgoing messages
norman, sorry for the late response; i didn't find any time for nmh until now... On Mon, 20 Jan 2020 10:43:19 -0500, Norman Ramsey writes: >I tried forwarding message using `forw -mi`, then telling whatnow to send. >I expected mh_build to be run, as it would have been had I typed >`mime` to whatnow. (This is an improvement that was made a few >versions back.) > The feature worked as expected under Debian 9.11, but stopped >working after a fresh install of Debian 10.2. (A fresh install >was necessary, not an upgrade, because I was migrating from x86 to amd64.) 9 had nmh 1.6.something, 10 has 1.7.something. the NEWS file states that for 1.7 various bugs were fixed, e.g. "mhbuild no longer parses lines that start with # as directives with -nodirectives." in addition to that, automimeproc was removed in 1.6. the man page for forw (and others) was changed to say 'Note that nmh will not invoke mhbuild automatically; you must specifically give the command What now? mime prior to sending the draft.' before it mentioned automimeproc as alternative setup. your profile still sets automimeproc. i do concur that forw -mime, with a plain 'send' at the whatnowproc prompt does not translate #forw... directives; i just tried it with a trivial .mh_profile. however: as far as i can tell that is working as designed! man mh-mime says "All messages sent by send(1) will automatically be processed by mhbuild(1) before being passed to post(1) for message submission." followed by this crucial bit "It is important to note that when using mhbuild directives the user must run mhbuild outside of send to have it process directives; when being run by send, mhbuild is configured to not process directives so normal user text is not mistaken for a directive. When using directives a user typically uses the mime command at the “What now?” prompt to process them." this is related to the removal of automimeproc, which your mh_profile still refers to; and forw -mime, which does indeed generate mhbuild directives; the send manpage mentions that mhbuild is run with -auto, and the mhbuild manpage says that -auto implies -nodirectives. so, in 1.6 this worked because -nodirectives in mhbuild wasn't honored. in 1.7 -nodirectives wins. as far as i can tell from digging through the source, forw -mime will not work unless an explicit 'mime' step is given at the whatnowproc prompt. i cannot see a way anymore to convince whatnow to automate that step - the relevant source commit comment from before the 1.6 release states 'Remove automimeproc functionality; it's redundant now.' but it seems that's not quite the case in the forw -mime scenario. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol. -- Larry Wall signature.asc Description: Digital Signature
Bug#947956: duplicity: mega backend fails to create directory
forwarded 947956 https://bugs.launchpad.net/duplicity/+bug/1858153 thanks On Thu, 02 Jan 2020 20:06:45 +0100, Jean-Michel Vourgère writes: >This is actually easy to fix, it's just a typo calling _make_dir while >the class function, just above, is named _makedir. thanks for the info; i'll make sure your patch makes it into the next debian release. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ MASER, n.: Mail Amplification by Stimulation of Emitted Rejections -- Steve VanDevender, Patrick Wade signature.asc Description: Digital Signature
Bug#945423: duplicity fails tests with Python 3.8
tags 945423 + upstream forwarded 945423 https://bugs.launchpad.net/duplicity/+bug/1853809 thanks On Sun, 24 Nov 2019 17:17:46 +0100, Matthias Klose writes: >Package: src:duplicity >Version: 0.8.07-1 >Severity: serious >Tags: sid bullseye ftbfs >User: debian-pyt...@lists.debian.org >Usertags: python3.8 > >duplicity fails tests with Python 3.8, all architectures: upstream claims to have fixed those warning-related failures, (see forwarded) but the fix doesn't work and the test suite now fails differently with "cannot import name '_librsync' from 'duplicity'". regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ The moving cursor writes, and having written, blinks on. -- BSD fortune file signature.asc Description: Digital Signature
Bug#944765: duplicity: Python 3 SyntaxWarnings during package configuration
On Thu, 14 Nov 2019 23:51:03 +0100, Axel Beckert writes: >Upgrading duplicity today threw the follwing SyntaxWarnings for me: thanks for the note. >Setting up duplicity (0.8.05-3) ... >/usr/lib/python3/dist-packages/duplicity/selection.py:213: SyntaxWarning: "is" >with a literal. Did you mean "=="? > if result is 2: this one will be fixed in the next uploadd of duplicity later today. >Setting up python3-tasklib (1.2.1-2) ... ... these need to be raised against the python3-tasklib package, not duplicity. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, Recht: internet-freier Raum. -- Hartmut Pilch signature.asc Description: Digital Signature
Bug#944512: duplicity: shouldn't be able to create a backup chain with two different passwords
On Tue, 12 Nov 2019 17:10:40 -0500, "Michael Terry" writes: >I don’t suppose you’d object to an update to the patch that at least >makes it conditional to gpg key scenarios? absolutely no objection; i just hadn't found the time to add that clean logic the last time i looked at that particular issue. >I could throw you a patch tomorrow. And it could have the benefit of >being upstreamable too. that sounds very good; thanks for your time! regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ COBOL is for morons. -- Dijkstra signature.asc Description: Digital Signature
Bug#944512: duplicity: shouldn't be able to create a backup chain with two different passwords
On Tue, 12 Nov 2019 07:46:37 -0500, "Michael Terry" writes: >Wait, you mean that you want to back up without even needing the >passphrase for the secret gpg key? that's precisely it. the secret key isn't even present on the machines that the backup runs on, just the public key. gpg (on duplicity's behalf) encrypts the data to and for the public key in question and thus performs a non-reversible one-way transformation as far as that backup machine is concerned. that way you get zero leakage potential on the backup machines (no secret data whatsoever is present), at the cost of not having cryptographic integrity assurance (as no signature can be generated w/o some secret key). regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on speed. -- Chris "Saundo" Saunderson signature.asc Description: Digital Signature
Bug#944512: duplicity: shouldn't be able to create a backup chain with two different passwords
On Mon, 11 Nov 2019 00:57:03 -0500, Michael Terry writes: >But then duplicity fixed the issue with gpg encryption keys and Debian never >dropped its patch. i disagree with that assessment: the way i read validate_encryption_settings in dup_main, resuming a backup with gpg encryption only (and no signing) will fail without the 01-reverify patch, because restore_get_enc_fileobj will fail without passphrase for decryption. >test the gpg encryption key issue (this one needs you to specify both >KEY and PASSPHRASE environment variables -- your gpg key id and >passphrase respectively). your scenario doesn't cover the case i'm trying to keep working, ie. an gpg-encrypted but not signed backup where duplicity just has a key to encrypt to and does not know any passphrases by design. given that that setup is one of the few relatively safe ones i certainly don't want to break that. when i find some time i will try to reassess the need for 01-reverify further but right now i don't see how validate_encryption_settings is supposed to succeed for gpg-encrypted-but-not-signed backups. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Unix and C are the ultimate computer viruses. -- Richard Gabriel signature.asc Description: Digital Signature
Bug#942593: b2backend: still broken - backblaze folders broken
reopen 942593 thanks On Thu, 24 Oct 2019 15:15:59 +0100, Graham Cobb writes: >Unfortunately b2backend is still broken upstream. I have sent a patch and I >think that should fix it. thanks for sending the links to the two launchpad bugs. >Will you reopen this bug to track this or do you want me to submit another one? reopening now. with a bit of luck i'll find some time tomorrow to apply the magic sauce from upstream's trunk and push out a new release. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ LISP: To call a spade a thpade. signature.asc Description: Digital Signature
Bug#942593: b2backend: fails with "can only concatenate str (not "bytes") to str"
tags 942593 + upstream forwarded https://bugs.launchpad.net/duplicity/+bug/1843995 thanks On Fri, 18 Oct 2019 17:50:58 +0100, Graham Cobb writes: >Attempt 1 failed. TypeError: can only concatenate str (not "bytes") to str as far as i can tell that bug was reported to upstream (see url above) and has been fixed in 0.8.05; i'll be updating debian's duplicity in a few days, at which point that problem should be history. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Competely pointless fact of the day: One of my rats is called Solaris, due to the fact it's fat and bloated. The other is called Perl. It's a nervous insane little animal. -- Ashley Penney signature.asc Description: Digital Signature
Bug#940473: dump: Verify fails when multiple extended attributes are present
here's a quick update wrt progress on this bug. On Mon, 16 Sep 2019 08:22:56 +0100, Tim Woodall writes: >When files have multiple extended attributes, the restore and verify >applies them one by one. yes and no. if you are using ext4 and have an inode size of > 128 byte, and if you have more than one extended attribute and if at least one of them is not very big then ext4 does store the attributes split into two pieces, some in the inode itself and the rest in one extra block (see ...linux source.../fs/ext4/xattr.c). (ext2 doesn't do that, and i don't know what the ext3 behaviour is.) dump transforms that into two records on tape, which you can see if you run dump with -v: DUMP: dumping EA (inode) in inode #467585 DUMP: dumping EA (block) in inode #467585 if you see only 'block' outputs no attribute splitting has happened, and the verification bug will not be tickled. if you have both 'inode' and 'block' xattr records, then restore will see two blocks for this one inode, and this is where the old logic gets things wrong. assuming you have 4 attributes, 1 of which ended up in the inode and 3 of which were parked in the block; restore will see the inode record first, and complain about 'ea count changed from 1 (ie. what the tape block in question holds) to 4 (ie what the file on the filesystem has)', and then once more about the change from 3 to 4. having two tape blocks contribute to one file's (attribute) data is a bit of a pain to fix, but i've got a fix in the works; not covering all 100% of the possible situations yet but close. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Never meddle in the affairs of NT. It is slow to boot and quick to crash. -- Stephen Harris signature.asc Description: Digital Signature
Bug#940473: dump: Verify fails when multiple extended attributes are present
On Mon, 16 Sep 2019 08:22:56 +0100, Tim Woodall writes: >This is a very longstanding, but minor, bug that I've finally got around >to reporting. I did investigate trying to fix but it appeared highly >non-trivial. tim, thanks for the note. i'll have a look at this issue as soon as i find a few spare moments. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much." -- Matt Blaze signature.asc Description: Digital Signature
Bug#939165: nmh: spost execs /usr/lib/mh/nmh/post, could do with s:nmh/::
On Sun, 01 Sep 2019 21:33:34 +0200, Robert Waldner writes: >Upgraded jessie->strecch->buster, spost no longer coooperated. When used >via exmh I got >"/usr/lib/mh/spost: 13: exec: /usr/lib/mh/nmh/post: not found" thanks. i'll fix that in the next upload. however: spost has been marked deprecated and superseded by post since the 1.6 release, and you should very likely change your postproc in .mh_profile to post. cheers az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ A)bort, R)etry, P)ee in drive door signature.asc Description: Digital Signature
Bug#929949: New upstream version 0.8 available, compatible with python3
On Fri, 09 Aug 2019 20:16:34 +0200, Andreas Ronnquist writes: >Is this really a target worth pursuing? To me it looks like the Debian >Python team is working to drop Python 2 from Debian during the Bullseye >development cycle. i'm not entirely certain that it is, and in the meantime i've focused on getting it to build with and against python 3. after some work on this i've determined that duplicity 0.8.0 doesn't properly work with python 3 either. i haven't had the time to look at the new 0.8.1 yet, which is going to be the next step. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ By 2000 we were supposed to have computers bright enough to argue with us, but that doesn't mean the way Word does it. -- Jo Walton signature.asc Description: Digital Signature
Bug#929949: status update
i've worked a bit more on massaging duplicity 0.8.00 and here's the latest state of affairs: 1. it doesn't build with python 2.7 because of test suite errors. most of these issues have been raised in upstream's bts at https://bugs.launchpad.net/duplicity/+bug/1833573, https://bugs.launchpad.net/duplicity/+bug/1833562, https://bugs.launchpad.net/duplicity/+bug/1833561 and https://bugs.launchpad.net/duplicity/+bug/1833560 2. it doesn't work with python 2.7 even after massaging item 1. i haven't bothered digging any deeper or raising bugs regarding that aspect until upstream looks as item 1. 3. it doesn't build with python 3.5, again because of test suite errors. different errors, raised upstream at https://bugs.launchpad.net/duplicity/+bug/1833998 https://bugs.launchpad.net/duplicity/+bug/1833808 4. it does build against python 3.7, and *seems* to work in that enviroment. net result: duplicity 0.8.00 can be built for testing/buster and for sid, but not for stretch (at least not at this time). as i'm still using stretch on my main systems i'm reluctant to call this version releasable yet: i think that it would be better to wait for a bit of feedback from upstream before 0.8.00 is allowed to enter the debian archives. the relevant bits of hacky patchery live at https://salsa.debian.org/debian/duplicity/commits/debian if anybody want to play with this straight away. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Blessed are the PHBs-who-do-not-understand-hardware, for they can be coerced into signing for upgrades to make life a bit more tolerable signature.asc Description: Digital Signature
Bug#929949: New upstream version 0.8 available, compatible with python3
On Thu, 20 Jun 2019 00:12:05 +0200, Sebastien Bacher writes: >Oh, also could you share your current packaging work? It would make >easier to trigger the problem and help with upstream reporting... done (somewhat reluctantly) at https://salsa.debian.org/debian/duplicity branch master is for upstream as-is, and the debian branch contains the quilt patches and so on. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "Mama, was kreut da?" - "Das heißt kriecht!" - "Mama, wo kreut das Kriecht hin?" -- gschropperl.myblog.de signature.asc Description: Digital Signature
Bug#929949: New upstream version 0.8 available, compatible with python3
On Tue, 18 Jun 2019 21:23:18 +0200, Sebastien Bacher writes: >Thanks for the status update. Did you report those issues upstream yet? one only, at this time; i've seen that you added a few of them. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, Zertifiziernung: Ein Geschäftsmodell, das heisse Luft zu Papier verdichtet und dann gegen Währung tauscht. -- Jörg Dorchain signature.asc Description: Digital Signature
Bug#929949: New upstream version 0.8 available, compatible with python3
On Tue, 18 Jun 2019 13:35:02 +0200, Sebastien Bacher writes: >Any news about that update? yes. so far i can't make duplicity 0.8.0 work with python 2.7 which is still the default version in debian and hence important in my opinion. (by "does not work" i mean: the built-in test suite fails quite a lot, and after patching that part basic functionality is still very very broken.) no promises as to when i will find time and mental strength to wade through this (upstream-induced) mess. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' but 'That's funny ...'" -- Isaac Asimov signature.asc Description: Digital Signature
Bug#929949: New upstream version 0.8 available, compatible with python3
tags 929949 + wishlist severity 929949 minor thanks On Mon, 03 Jun 2019 22:27:58 +0200, Sebastien Bacher writes: >Upstream rolled out a 0.8 version which is finally compatible with >python3, it would be nice to have it uploaded to Debian thanks for the note, i'll have a look sometime in the next two weeks. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "Sorry, we don't support the worship of gods on this list, we only support the worship of penguins." "what about us agnustics?" -- Russell Coker and Graham Wilson signature.asc Description: Digital Signature
Bug#926297: duplicity: azure dependency broken?
tags 926297 + upstream forwarded 926297 https://bugs.launchpad.net/duplicity/+bug/1694770 thanks On Wed, 03 Apr 2019 14:27:31 +1100, Dean Hamstead writes: >Similarly, if i do a 'pip install azure' i get the same error. that's an api incompatibility problem known to upstream (see the launchpad tracker link above). a comment on that bug report indicates that forcing the installation of an older azure api version with pip install azure-storage==0.20.0 should provide a workaround for now (you may also have to ditch the python-azure-storage debian package). regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ AA - American Association Against Acronym Abuse Anonymous. signature.asc Description: Digital Signature
Bug#921244: comp/send: strange error and undocumented behaviour when using Bcc-header
retitle 921244 broken bcc handling with transport sendmail/pipe thanks On Sun, 03 Feb 2019 14:13:24 +, Harald Geyer writes: >I get the following error: >| What now? send >| sendmail: No recipients specified although -t option used >| exit 1 could you please provide (possibly sanitised) copies of your ~/.mh_profile and /etc/nmh/mts.conf? >Both recipients get messages with different Message-Ids, but the >content seems to be exactly the same. ... >I believe this is in conflict >with the man page of send(1), which states that Bcc-recipients will >receive a message with a clear indication in the body, warning them >not to disclose their status as recipients by replying. i don't see any indication in the send manpage that supports your reasoning. but looking closely at the FAQ, the post manpage and the actual code i do see that nmh tries to reformat bcc's under some/many/most circumstances (and offers a weird nonstandard dcc header to create the 'normal'/classic behaviour of identical copies). i can confirm that nmh 1.7 has buggy bcc handling, at least when sendmail/pipe is used as transport: using a shim program instead of actual sendmail/postfix/whatever i could see that the sequence of comp-whatnow-post creates TWO messages to transmit, * one that contains the original body, complete with to: and bcc:, ie. leaving sendmail/postfix/whatever to handle that bcc:, which causes normal mail transfer agents to produce the 'normal'/classic bcc: behaviour, * and one that has the warning-encrusted body but no to: at all and only a blank bcc: header. that one is clearly untransmittable, which is what causes the error message you saw. i'll get in touch with upstream and have a deeper look at the problem myself as well. you might try switching to 'smtp' or 'sendmail/smtp' in /etc/nmh/mts.conf as a potential workaround until that bug is sorted; note that according to the mts.conf manpage dcc: is NOT supported if 'sendmail/pipe' is the transport. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin signature.asc Description: Digital Signature
Bug#917331: nmh message include via POP3 ignores password (null pointer?)
On Wed, 26 Dec 2018 09:21:21 +, halfdog writes: >No matter which password is entered, inc will always send the >password string "(null)" to the server, thus failing authentication. i've found the root cause; it's a one-liner logical mistake that broke the handling of prompted-for passwords. (upstream has actually also found & fixed that one at some point after the 1.7.1 release.) a new version of nmh will hit unstable within the next 24 hours, and you should be able to recreate your jessie-backport build at that time. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ This mind intentionally left blank. signature.asc Description: Digital Signature
Bug#917031: nmh: co-installability with mmh
On Sun, 23 Dec 2018 14:58:21 +, Dmitry Bogatov writes: >For cases of developing/testing something, that should work with both MH >implementation. i'm sorry, but i don't consider this sufficient justification for a mix-n-match installation: if i want to test something's ability to work with the mh flavour provided by mmh, then i need all of mmh and none of nmh on my system, and vice versa. it makes no sense whatsoever to have half of mmh and half of nmh active for such compatibility testing or front-end development. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Consider the set of blacklists that do not blacklist themselves... -- David Richerby on blacklisting blacklists signature.asc Description: Digital Signature
Bug#917331: nmh message include via POP3 ignores password (null pointer?)
severity 917331 normal thanks On Wed, 26 Dec 2018 09:21:21 +, halfdog writes: >No matter which password is entered, inc will always send the >password string "(null)" to the server, thus failing authentication. thanks for reporting this; i can confirm your observation, and it looks as if there's a bug in the 'credentials: legacy' handling (which happens to be the default as per man mh-profile). i'll investigate the issue as soon as i find a bit of time. however, the netrc credentials mechanism is not affected by the bug, so for the time being i'd suggest using that as a workaround. (because this workaround exists i'm lowering the severity of the bug to normal.) ie 'credentials: file:.netrc' in .mh_profile, and a 0600-chmod'd ~/.netrc with 'machine localhost login testme password whatever' does convince inc to pass the password as expected. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ #define sizeof(x) rand() -- Dark_Brood signature.asc Description: Digital Signature
Bug#917072: mmm-mode: fails to byte-compile with emacs-26
On Sat, 22 Dec 2018 16:34:29 +0900, David Bremner writes: >I'm not quite sure whether this is a bug in emacs 26 or in mmm-mode, i found the issue, and it's a bug/mistake in mmm-mode; somehow or other i ended up adding the following, very dud, patch in version 0.5.7-2: +;; emacs >= 25 has no more caddr -> cl-caddr alias +(if (>= emacs-major-version 25) + (defalias 'caddr 'cl-caddr)) + with that dud thing in place mmm-vars.el fails to compile on e26 when cl-third is first called. that's because on e24 cl-third is an alias for cl-caddr. on e26, cl-third is an alias for caddr. i don't exactly understand why compilation works if you skip mmm-sample, but the issue above is certainly the root cause for the whole mess. >Attached is an nmudiff that I plan to upload to DELAYED/5 i've nuked that dud patch and now everything incl. mmm-sample byte-compiles fine on e26 in a fresh sid chroot, so i'm about to upload 0.5.7-3; that'll invalidate your delayed nmu. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "If you want sympathy, look in the dictionary; it's between sex and syphilis." -- Joe Zeff signature.asc Description: Digital Signature
Bug#917072: mmm-mode: fails to byte-compile with emacs-26
On Sat, 22 Dec 2018 16:34:29 +0900, David Bremner writes: >I'm not quite sure whether this is a bug in emacs 26 or in mmm-mode, >but in any case it seems the file mmm-sample.el doesn't really need to >be byte compiled. weird. i'll try to experiment a bit with mmm-sample, see if i can narrow this down any further but it's already pretty small...somehow this does smell like an emacs bug. >Attached is an nmudiff that I plan to upload to DELAYED/5 thanks for that; certainly no objections from my side. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Any suffiently advanced magic is indistinguishable from technology. signature.asc Description: Digital Signature
Bug#917031: nmh: co-installability with mmh
On Fri, 21 Dec 2018 18:54:41 +, Dmitry Bogatov writes: >please make `nmh' co-installable with `mmh'. upon reviewing of mmh's documentation and stated goals i don't think this will work. i think that mmh has to conflict with nmh. it's not compatible with nmh (except in terms of mail storage on disk), and this breaks exmh and mh-e (which depend on nmh and its behaviour). the readme states: "...rather mmh breaks compatibility to nmh in order to modernize and simplify it." "...my experimental version more and more feels like being a fork." for example, schnalke's thesis shows that he's removed pretty essential tools like post and reinstated spost, which nmh has deprecated completely in favour of only post. to switch some nmh/mmh tools over to the other flavour via alternatives is doomed to fail in my opinion, because it'll cause any of the remaining *mh tools to operate on the wrong defaults/preferences. this will cause nothing but confusion and frustration for users. to always switch all tools over, well, that's achieved in a better fashion by just having one of the two packages on a box. unless you can provide me with a compelling resonining and case for why this mixing of incompatible and overlapping code should be beneficial i'll close this as wontfix and make nmh explicitely conflict with mmh. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ A successful sysadmin must accept no limits on his laziness. -- Peter da Silva signature.asc Description: Digital Signature
Bug#917031: nmh: co-installability with mmh
On Fri, 21 Dec 2018 18:54:41 +, Dmitry Bogatov writes: >please make `nmh' co-installable with `mmh'. I, as maintainer of `mmh', >took first step and made `mmh' alternative of /usr/bin/mh/mh and bunch >of slave links. sure, i'll have a look at making those changes in the next few days. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ I just went visual on this goofy looking Finn riding on a gnu, wielding one pissed off penguin... gah -- Bob The Sane signature.asc Description: Digital Signature
Bug#908743: mmm-mode: package cl-lib conflicts with emacs cl-lib
On Thu, 13 Sep 2018 12:03:31 +0100, Julian Gilbey writes: >Real cl-lib shadowed by compatibility cl-lib? >(/usr/share/emacs/site-lisp/mmm-mode/cl-lib.el) agh. to support xemacs mmm-mode needs to ship a cl-lib.el as xemacs doesn't have one of those. looks like the mmm-mode postinstall (which already byte-compiles only the applicable files for the emacs platform in question) needs to be a bit more agressive and get rid of or neuter the cl-lib.el if used with a non-xemacs emacs. i'll look into ths in the next few days. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Systems programmers are the high priests of a low cult. - R. S. Barton signature.asc Description: Digital Signature
Bug#906427: duplicity: FTBFS: test failure (gpg failed)
tags 906427 upstream forwarded 906427 https://bugs.launchpad.net/duplicity/+bug/1780617 thanks On Fri, 17 Aug 2018 13:15:57 +, Damyan Ivanov writes: >ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest) >Test getting signature chain fileobjs from archive_dir looks like gnupg 2.2.8 has changed its behaviour in a fairly incompatible fashion, which throws the test suite off. upstream has a fix but it's not part of a release - yet. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Meddle not in the affairs of sysadmins, for they are subtle and quick to lart. signature.asc Description: Digital Signature
Bug#826492: libtm-perl: Unescaped left brace in regex is deprecated
reassign 826492 libparse-yapp-perl found 826492 1.05-12 notfound 826492 1.21-1 thanks the unescaped left brace is actually an issue in yapp, not libtm-perl; according to the yapp change log at https://metacpan.org/changes/distribution/Parse-Yapp that issue was fixed in 1.06. stretch has 1.05, testing has 1.21 so that's fine; i'm not sure if that bug should be closed outright, but it certainly does belong to libparse-yapp-perl. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ It is not I who seek the young fool; The young fool seeks me. At the first oracle I inform him. If he asks two or three times, it is importunity. If he importunes, I give him no information. -- I Ching signature.asc Description: Digital Signature
Bug#901590: duplicity: Backblaze B2 backups error with "Bucket cannot be created"
On Fri, 15 Jun 2018 08:03:47 +, Marc Warne writes: >This is FIXED in the latest upstream, i.e. 0.7.17. Installing this (via >dpkg-bu ildpackage) worked just fine so this package should probably >just be updated. duplicity 0.7.17 has been available in testing since late march, so i'm closing this bug. i'll have a look at producing a backport version for stretch/stable. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "Zeilen muessen scrollen fuer den Sig." -- Christian Pree signature.asc Description: Digital Signature
Bug#900885: dump FTBFS on Alpha; no getpid syscall
On Thu, 07 Jun 2018 08:51:35 +1200, Michael Cree writes: >I doubt that this has anything to do with posix. yes, you're right, i had forgotten about that patch actually having to work around the clone syscall by using not just getpid() (which is in posix) but the lower level syscall stuff. >Was that for 32-bit sparc (which Debian no longer >supports) or 64-bit sparc (which is a ports architecture)? 64 bit if i remember correctly. >I'll ask on #debian-ports as to >whether anyone knows why the sparc patch was introduced. don't bother: i wrote that patch about 8-10 years ago when i needed this to work on sparc boxes. anyway, i'll sort this out for alpha without breaking sparc if possible. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ To clean and uninfected by the Empire remain, Emacs you use must. -- Tollef Fog Heen signature.asc Description: Digital Signature
Bug#900885: dump FTBFS on Alpha; no getpid syscall
On Wed, 06 Jun 2018 22:51:08 +1200, Michael Cree writes: >dump FTBFS on alpha with [1]: ... >Alpha Linux does not have the getpid syscall; it follows OSF1.0 oh the joy of non-posix environments :-( but thanks for the info and the patch; i'll get that sorted out sometime in the next few days. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Hit any user to continue. signature.asc Description: Digital Signature
Bug#893930: mmm-mode: broken under XEmacs: Cannot open load file: cl-lib
severity 893930 normal
thanks
(justification: affects only xemacs, and can be fixed by manually installing
cl-lib.el.)
On Fri, 23 Mar 2018 17:43:45 -0400, "Aaron M. Ucko" writes:
>Byte-compiling mmm-mode 0.5.5 under XEmacs fails:
...
>!! File error (("Cannot open load file" "cl-lib"))
upstream recently changed over to requiring cl-lib instead of
cl, as cl-lib is shipped with emacs 24.3+... for xemacs cl-lib has
to be installed separately (from elpa or elsewhere). meh.
however, according to the emacs wiki xemacs and older emacsen do have a
not-totally-ideal-but-workable cl.el which provides the same functionality
but is not properly namespaced.
upstream seems to be busy fiddling with this right now, i saw a few commits
that change namespacing backwards and forwards over the last few days.
i'll look at adding some backwards-compat logic for xemacs, but it'll take
a few days.
regards
az
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
"The first rule of magic is simple. Don't waste your time waving your
hands and hoping when a rock or a club will do." -- McCloctnik the Lucid
signature.asc
Description: Digital Signature
Bug#893365: mmm-mode was transfered under FSF umbrella, copyright needs to be updated
On Sun, 18 Mar 2018 14:42:06 +0500, Lev Lamberov writes: >its new webpage is https://elpa.gnu.org/packages/mmm-mode.html. this is not mentioned anywhere in any of the code or the docs at https://github.com/purcell/mmm-mode. i will therefore continue to consider the github site authoritative. >Now its copyright is >stated as 1999-2004, 2012-2015, 2018 Free Software Foundation, Inc., >which is reflected in the source code. this is NOT reflected in any news or changes file at the authoritative site and it is also NOT fully reflected in the source code; various files have quite different copyright markers. mmm.texinfo: copyright does not include the fsf at all. install-sh: copyright does not include the fsf at all. mmm-noweb.el: has overlapping different copyright markers mmm-rpm.el: copyright odes not include the fsf at all. until is properly consolidated at the source level i will not change anything. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ You are trapped in a maze of screens and ssh sessions all alike. It is dark, and you are likely to log off the wrong account. -- Nep signature.asc Description: Digital Signature
Bug#890645: duplicity: Duplicity fails on Backblaze B2 list-current-files
On Mon, 19 Feb 2018 18:37:48 +, Graham Cobb writes: >Are the changes from 0.7.11-1 to 0.7.16-1 sufficiently important that this >regression has to be implemented? please complain to upstream; i don't use backblaze or any of the other commercial storage services, and i don't care much about any of them. the changelogs don't even hint at the new requirements, all they say is "* Fixed bug #1654756 with new b2backend.py module from Vincent Rouille - Faster (big files are uploaded in chunks) - Added upload progress reporting support" the manpages don't say anything about backblaze either. as to 'has to be implemented' - the answer is yes: i use upstream's code, and i make only the absolutely minimum number of required changes to make it fit for debian. consequentially i will not attempt to create, curate and keep alive a totally debian-specific variant of duplicity, just so that module support can be cherry-picked. >Is there any information or testing on whether the out-of-repository workround >described in the error message works? i don't know. backblaze is one of many backends that duplicity claims to support, backblaze is commercial and therefore i don't use it and i don't care about it. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ ...wild Colostomy lurk dangerously in the trees, while out on the prairie, large herds of chocolate brown Bulimia graze contentedly... -- Tanuki signature.asc Description: Digital Signature
Bug#890645: duplicity: Duplicity fails on Backblaze B2 list-current-files
tags 890645 + upstream forwarded 890645 https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/174324 thanks On Fri, 16 Feb 2018 23:50:05 -0800, Charlie Hagedorn writes: >The suggested solution is pulling in the Backblaze API implementation via pip, >but this shouldn't be necessary. as far as i can tell (not being a backblaze user) this *is* necessary because the backblaze api isn't available as debian package. i'll add a note about this to news.debian for the next release; there is nothing else that i can do about this. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ IBM - "Internally Blackened Machines" -- Bob Vaughan about PSU failures signature.asc Description: Digital Signature
Bug#888878: fails to restore signed backup
tags 78 + unreproducible moreinfo severity 78 normal thanks On Tue, 30 Jan 2018 21:14:57 +0100, Erwan David writes: >When trying to restore a signed backup, with -v 8 I get following >error >Volume was signed by key EE04D0D2B40F856F, not 0xEE04D0D2B40F856F first, i'd recommend not passing any sign-key parameter to the restore call as that only makes it picky wrt missigned files. as far as i can tell the signature check does not result in termination of the restore job; a mismatched sig only causes an error message and a nonzero exit code, but the file restoration still happens normally. second, i cannot reproduce this with the current version of duplicity (0.7.16-1): backing up with --sign-key X --encrypt-key X results in a correctly encrypted and restorable archive, signed with and encrypted to a subkey of my key X. in order to perform any further diagnostics i need the actual output of a failed restore run with -v9. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Some people think I'm nice & are shocked when they find out different. I'm not a nice person, & I don't care about you. -- Linus @ lca2015 signature.asc Description: Digital Signature
Bug#880111: closed by Alexander Zangerl <a...@debian.org> (Bug#880111: fixed in duplicity 0.7.16-1)
On Sun, 28 Jan 2018 12:13:34 +0100, Francesco Poli writes: >I upgraded to duplicity/0.7.16-1, but I still get the error on >incremental backups: upstream considers having this 'error message that is just a notice message' to be _the_ fix. ie. benign and ignorable. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ The only truly safe "embedded system" is the system that has an axe embedded in it... -- Tanuki signature.asc Description: Digital Signature
Bug#886117: FTBFS: most of testsuite
tags 886117 + unreproducible moreinfo
severity 886117 normal
thanks
On Wed, 03 Jan 2018 16:24:57 +0100, Adam Borowski writes:
>Working hypothesis so far is that the testsuite fails on btrfs; I won't be
>able to confirm until the evening.
sorry, but i can't reproduce your problem.
duplicity builds and tests fine on stretch with ext4 and and with btrfs,
kernel 4.9.69; on sid with ext4 and btrfs (same kernel), and on the
build daemons as per
https://buildd.debian.org/status/package.php?p=duplicity=sid.
i've removed the output-silencing for the tar invocation that fails
in your environment (see the attached updated patch), but all that
changed is that i get a number of 'implausibly old timestamp' warnings;
these are legit as the test files do contain time stamps near 1.1.1970.
regards
az
Author: Michael Terry <mte...@ubuntu.com>
Subject: Disable some tests for being flaky
--- a/testing/functional/test_restart.py
+++ b/testing/functional/test_restart.py
@@ -111,6 +111,7 @@ class RestartTest(FunctionalTestCase):
# there should be 2 differences found, one missing file, one mtime change
# self.verify("testfiles/largefiles")
+@unittest.skip("Flaky test because it relies on knowing how many volumes the source files will be split into")
def test_last_file_missing_at_end(self):
"""
Test restart when the last file being backed up is missing on restart.
--- a/testing/unit/test_gpg.py
+++ b/testing/unit/test_gpg.py
@@ -129,6 +129,7 @@ class GPGTest(UnitTestCase):
sig = decrypted_file.get_signature()
assert sig == self.sign_key, sig[-8:]
+@unittest.skip("Flaky test because it relies on compressed size of random bytes")
def test_GPGWriteFile(self):
"""Test GPGWriteFile"""
size = 400 * 1000
@@ -144,6 +145,7 @@ class GPGTest(UnitTestCase):
profile, size=size)
# print os.stat("testfiles/output/gpgwrite.gpg").st_size
+@unittest.skip("Flaky test because it relies on compressed size of random bytes")
def test_GzipWriteFile(self):
"""Test GzipWriteFile"""
size = 400 * 1000
--- a/testing/unit/test_selection.py
+++ b/testing/unit/test_selection.py
@@ -173,6 +173,7 @@ class MatchingTest(UnitTestCase):
assert select.glob_get_sf("**", 0)(root) == 0
assert select.glob_get_sf("/foo/*", 0)(root) is None
+@unittest.skip("unreliable ass-U-me wrt / and /usr on one fs")
def test_other_filesystems(self):
"""Test to see if --exclude-other-filesystems works correctly"""
root = Path("/")
--- a/testing/unit/test_statistics.py
+++ b/testing/unit/test_statistics.py
@@ -59,12 +59,13 @@ class StatsObjTest(UnitTestCase):
s1 = StatsDeltaProcess()
assert s1.get_stat('SourceFiles') == 0
+@unittest.skip("TZ setting seems to fail under sbuild, #880251")
def test_get_stats_string(self):
"""Test conversion of stat object into string"""
s = StatsObj()
stats_string = s.get_stats_string()
assert stats_string == "", stats_string
-
+
self.set_obj(s)
stats_string = s.get_stats_string()
assert stats_string == """\
--- a/testing/__init__.py
+++ b/testing/__init__.py
@@ -85,7 +85,7 @@ class DuplicityTestCase(unittest.TestCas
def unpack_testfiles(self):
assert not os.system("rm -rf testfiles")
-assert not os.system("tar xzf testfiles.tar.gz > /dev/null 2>&1")
+assert not os.system("tar xzf testfiles.tar.gz")
assert not os.system("mkdir testfiles/output testfiles/cache")
def _update_env(self, key, value):
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
"I can't see any data coming out of this Tolkien Ring card."
"Well of course not, it confers invisibility." -- Anthony de Boer
signature.asc
Description: Digital Signature
Bug#886117: FTBFS: most of testsuite
On Wed, 03 Jan 2018 16:24:57 +0100, Adam Borowski writes: >Working hypothesis so far is that the testsuite fails on btrfs; I won't be >able to confirm until the evening. i'm just building a kernel with btrfs to verify your very probable hypothesis; upstream's test suite is a fairly yucktastic setup that ditches a lot of very useful output for content-free assertions. what does fail in your tests is the test priming in testing/__init__.py, where testing/testfiles.tar.gz is unpacked. it's running "tar xzf testfiles.tar.gz > /dev/null 2>&1" and that tarball does contain a number of nastily named files (glancing at hexdump tells me it's iso-8859-1 and not utf-8). i suspect these file names are the root cause. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "Ein Blitzableiter auf einem Kirchturm ist das denkbar stärkste Mißtrauensvotum gegen den lieben Gott." -- Karl Kraus signature.asc Description: Digital Signature
Bug#886117: FTBFS: most of testsuite
On Tue, 02 Jan 2018 14:40:33 +0100, Adam Borowski writes:
>I'm afraid that your package fails to build on current unstable, failing the
>vast majority of tests:
looks like every one of the failed tests fails for the same reason,
(which to me indicates rather a failure of the test suite
than a failure of duplicity itself):
File "/<>/testing/__init__.py", line 88, in unpack_testfiles
assert not os.system("tar xzf testfiles.tar.gz > /dev/null 2>&1")
AssertionError
i'll go dig deeper when i find the time, but i've got no clue how
why that could be a platform-specific failure.
regards
az
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
"Unterschätze nie die Macht dummer Leute, die einer Meinung sind."
-- Kurt Tucholsky
%
Which is worse: Ignorance or apathy? I don't know and I don't care.
signature.asc
Description: Digital Signature
Bug#880111: duplicity: fails to ask for GPG key passphrase and claims that none was given
retitle 880111 duplicity should log a warning (not error) for encrypted manifest severity 880111 minor tags 880111 - moreinfo thanks On Wed, 01 Nov 2017 20:19:31 +0100, Francesco Poli writes: >> 2. could you run another backup invocation with -v9 and attach the output? ... >Attached as duplicity.out thanks for your diagnostic data. >I cannot spot the error there, though... :-| yes, there is no problem in that run. in the meantime i've started up a blank unstable chroot, and i can reproduce the issue on incremental backups. exec summary: please ignore that error message. i've checked the source, and this is actually working as designed: upstream changed the handling of remote manifests in 0.7.14 to more-or-less blindly attempt to access an encrypted remote manifest and if unsuccessful, log that as a nonfatal 'error'. http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/revision/1252/duplicity/collections.py as far as i can tell duplicity doesn't even attempt to fully interact with gpg in this situation, and that's why you see the error message - which is utterly benign: duplicity doesn't even NEED the remote manifest in that situation (earlier on it's logged that "local and remote are in sync"). i'll raise a bug with upstream to improve the logging for this situation. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "There are only two industries that refer to their customers as 'users'." -- Edward Tufte signature.asc Description: Digital Signature
Bug#880251: duplicity: FTBFS: Test failures
On Mon, 30 Oct 2017 20:30:40 +0100, Lucas Nussbaum writes: >About the archive rebuild: The rebuild was done on EC2 VM instances from >Amazon Web Services, using a clean, minimal and up-to-date chroot. hmm. the test suite code in question does set an appropriate $TZ at the very start. i have no diea how that could have failed in the chroot that you used for the archive build? the very same code survives the tests just fine in a sid chroot under pbuilder. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "Militant *BSD users are frequently in favour of gnu control." -- Nix signature.asc Description: Digital Signature
Bug#880251: duplicity: FTBFS: Test failures
On Mon, 30 Oct 2017 20:30:40 +0100, Lucas Nussbaum writes: >Relevant part (hopefully): almost but not quite, the actual issue is five or six lines before your quoted part: it's a bug in the test suite, which asserts string equality for an input that depends on the time zone of the box the test runs on (if i read the code correctly it will only work in GMT-6). i'll sort this out within the next day or two and report the problem upstream. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ 'Glaube' heißt Nicht-wissen-wollen, was wahr ist. -- Friedrich Nietzsche signature.asc Description: Digital Signature
Bug#880111: duplicity: fails to ask for GPG key passphrase and claims that none was given
tags 880111 + moreinfo severity 880111 normal thanks On Sun, 29 Oct 2017 16:38:10 +0100, "Francesco Poli (wintermute)" writes: >When doing so, duplicity (or maybe gpg) complains that it could not >perform any decryption, since no passphrase was given: hmm. i suspect the interaction of gpg v2.2, the gnupg-agent and some leftover/broken data in the local cache that duplicity thinks it needs to to decrypt before doing its backup job. as far as i'm aware, the local manifest/cache is the only thing which duplicity possibly needs to decrypt, given your encrypt-only command line. >I tried to restore one file from my backup (from inside an X graphical >session) and it seems to work correctly: it asks for the GPG key passphrase >(on the terminal emulator) and successfully restore a file identical to >the original. ok, good, that confirms that at least the core functionality works. >Please note that this bug is similar to #565398, yes, superficially similar - but debian's duplicity has ignored locales as a workaround for this bug for a long time now; that's most certainly not it. >Is there anything I failed to understand? not that i'm aware of; you're using duplicity pretty much like i do myself, except that i've decided to stay with gpg v1 for a while longer (b/c i dislike the gnupg-vs-agent architecture). a few things might helpful for further diagnostics/triage: 1. what does collection-status report? does that also attempt to decrypt something and fail? does a cleanup improve matters? 2. could you run another backup invocation with -v9 and attach the output? feel free to blank your keyid and other sensitives; the remaining fine print of what is being attempted when/why would be helpful. 3. does a totally new backup to a different location, with an empty/new .cache/duplicity directory work? (alternative to nuking cache: --archive-dir in the invocation) 4. does your gnupg config contain anything special that might interfere with --pinentry-mode=loopback? most specifically, does your agent config contain anything like no-allow-loopback-pinentry? 5. does duplicity work correctly if you run it with --use-agent? see --use-agent in man duplicity; this directly affects who might ask for a passphrase, duplicity or gpg-agent. 6. does the duplicity backup work if you run it from X? 7. does gnupg sign work if you run it from a non-X console, like where your failing duplicity was run? regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, Halflife-Server: Server, der nur halb lebt. Kurz: IIS. -- Andreas Dau signature.asc Description: Digital Signature
Bug#871432: nmh: please switch to SSLv23_… or TLS_…_method
On Tue, 08 Aug 2017 00:04:04 +0200, Sebastian Andrzej Siewior writes:
>Package: nmh
>Version: 1.6-16
>Severity: important
>User: pkg-openssl-de...@lists.alioth.debian.org
>Usertags: TLS1.0_1.1_removal
fyi, i'm mostly finished upgrading the nmh package to upstream's
new version 1.7-rc3, which has modern tls support. a few more days
of local testing and i'll upload that.
regards
az
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, Interaktives Fernsehen: Fernsteuerung mit
Taste 'Bezahlen' statt 'Aus'. ('Standpay'-Taste) -- nach Peter Berlich
signature.asc
Description: Digital Signature
Bug#873162: duplicity: missing dependency to gpg
On Fri, 25 Aug 2017 06:57:11 +, Markus Kasten writes: >installing duplicity on a system without having gpg installed leaves the >duplicity tool in a broken state. gnupg is 'priority: important' https://www.debian.org/doc/debian-policy/index.html#priorities so it should normally be installed. however, strictly speaking, only 'essential' packages are officially exempt from listing as dependencies, so i'll fix this in the next upload. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ One of the main advantages of Unix over, say, MVS, is the tremendous number of features Unix lacks. -- Chris Torek signature.asc Description: Digital Signature
Bug#726731: #726731: dump: Huge RAM usage on restore
On Mon, 17 Jul 2017 20:55:04 -0700, Elliott Mitchell writes: >I should mention a reasonable alternative method. i'm not sure i'd want to go to a dir tree for this; if one just wants to handle level 0 backups then my understanding is that the restoresymtable could be skipped completely. there's no code for such a skip at this time, but i suspect that that would be a cheap remedy - at least for full backups. >I /think/ it should be reasonable to replace restoresymtable with a >small directory tree. right now i don't see why the symtable cannot be dumped incrementally instead of being held in memory. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "It's a pity that punched card equipment is now almost all gone. There's nothing better for grabbing a tie and breaking the wearer's neck." -- Mike Andrews signature.asc Description: Digital Signature
Bug#866563: dump: Bad package description
On Thu, 29 Jun 2017 20:35:59 -0700, Elliott Mitchell writes: >First line of description "4.4bsd dump and restore for ext2 filesystems". i guess that arrived via the lsm entry, which says Description:Port of the 4.4BSD dump and restore backup suite >thereby reusing old i-node numbers. personally i don't think this difference is worth any argument; nobody should depend on particular inodes for anything, really. that the linux dump is not quite bit-nor-bug-compatible with 4.4BSD is a legit part of the 'port of' aspect in my opinion; and not really a big surprise, given that linux isn't 4.4BSD whose last release was 22 years ago... anyway, i'll adjust the description for the next release. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism." -- Paul Tomblin signature.asc Description: Digital Signature
Bug#861703: duplicity: please run tests during build
On Tue, 02 May 2017 17:27:51 -0400, Michael Terry writes: >Here it is, please consider it for Debian too. done. >We do skip some tests. Those are the ones that we've found unreliable >for various architectures over the years. i've added another skip: / and /usr are not guaranteed to be one the same fs. i've also added the missing check for DEB_BUILD_OPTIONS=nocheck to the new rules file (based on yours) and a bit of cleanup for setup.py test which doesn't seem to honor PYTHONPATH and consequentially compiles stuff again and leaves a mess behind (duplicity/*.so, testing/gnupg/random_seed and so on). >It's just something we've also done since maybe trusty because >upstream fixed the issues those patches solve. i disagree with that claim: the relevant lauchpad bugs are still open, and i don't see any fixes in the code. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, HTTP: Hot Tits Transport Pr0nocol. -- Ulrich Schwarz signature.asc Description: Digital Signature
Bug#801907: closed by Alexander Zangerl <a...@debian.org> (Bug#801907: fixed in jesred 1.2pl1-20)
On Sun, 14 May 2017 01:22:11 +0300, Adrian Bunk writes: >It is still present in jessie, could you also fix it there? i've requested an ok for stable-proposed-updates in #862523. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ NT and security should not be used in the same sentence without negation -- Joe Zeff signature.asc Description: Digital Signature
Bug#862523: jessie-pu: package jesred/1.2pl1-19+deb8
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
i've been asked to retrofit the fix for #801907 to the version
in jessie. that bug is fixed in testing. the bug causes jesred to not
interoperate properly with squid versions 3.4 and newer.
changes are as per the attached debdiff: patch 05-squid3 (which makes
jesred work with squid 3 in the first place) was updated, and a small
followup was made to patch 07-ipv6 which was necessary as it
didn't apply properly on top of the updated 05-squid3 patch.
regards
az
diff -Nru jesred-1.2pl1/debian/changelog jesred-1.2pl1/debian/changelog
--- jesred-1.2pl1/debian/changelog 2013-09-29 13:37:11.0 +1000
+++ jesred-1.2pl1/debian/changelog 2017-05-14 13:20:06.0 +1000
@@ -1,3 +1,10 @@
+jesred (1.2pl1-19+deb8) stable; urgency=high
+
+ * fix of #801907 for jessie: squid 3.4 and newer uses an incompatible
+format for interacting with redirectors like jesred.
+
+ -- Alexander Zangerl <a...@debian.org> Sun, 14 May 2017 13:11:36 +1000
+
jesred (1.2pl1-19) unstable; urgency=low
* added support for ipv6 (closes: #714819)
diff -Nru jesred-1.2pl1/debian/patches/05-squid3 jesred-1.2pl1/debian/patches/05-squid3
--- jesred-1.2pl1/debian/patches/05-squid3 2015-10-23 22:50:25.0 +1000
+++ jesred-1.2pl1/debian/patches/05-squid3 2017-05-14 13:26:30.0 +1000
@@ -13,7 +13,7 @@
#ifdef LINUX
#include
#else
-@@ -61,89 +62,77 @@ static int match_accel(char *, char *, i
+@@ -61,89 +62,85 @@ static int match_accel(char *, char *, i
int
parse_buff(char *buff, char **url, char **src_addr, char **ident,
@@ -97,17 +97,20 @@
+ struct in_addr address;
+ char *token;
+ char *next_token = buff;
-+
++ char *errorptr;
+
+ /* az [2015-10-23 Fri 21:20]
-+ goodbye squid2, hello squid3.5
-+
-+ no more url groups; a numeric channel id, a url, space and extra stuff or a newline.
-+ apparently extras was configurable with url_rewrite_extras, but that has been
-+ removed in one of the newest squid versions (the docs re this are pretty damn confused...)
-+
-+ [channel-ID ] URL [ extras]
-+ and extras are supposed to be (adjustable in 3.5, adjustability removed(??) in 4)
++ goodbye squid2..3.3, hello squid3.5
++
++ no more url groups; a numeric channel id, a url, space
++ and extra stuff or a newline.
++ apparently extras was configurable with url_rewrite_extras,
++ but that has been removed in one of the newest squid
++ versions (the docs re this are pretty damn confused...)
++
++ [channel-ID ] URL [ extras]
++ and extras are supposed to be (adjustable in 3.5,
++ adjustability removed(??) in 4)
+ ip/fqdn username method myip= myport=
+ */
+
@@ -117,15 +120,20 @@
+ mylog(ERROR, "invalid input, no extras in (%s)", buff);
+ return 1;
+ }
-+
-+ char *errorptr;
-+
++
+ /* channel-id? must be numeric */
+ j = (int)strtol(buff, , 10);
+ if (!*errorptr) /* conversion successful */
+ {
+ *chanid = j;
+ *url = next_token;
++
++ /* now find end of url/start of ip/fqdn */
++ if (!(token = strsep(_token, " ")))
++ {
++ mylog(ERROR, "invalid input, no ip/fqdn in (%s)", buff);
++ return 1;
++ }
+ }
+ else
+ {
@@ -148,7 +156,7 @@
+ return 1;
+ }
+ *ident = token;
-+
++
+ /* find end of method */
+ if (!(token = strsep(_token, " ")))
+ {
@@ -169,9 +177,35 @@
/* URL with less than 7 char is invalid */
if(strlen(*url) <= 7) {
mylog(ERROR, "strlen url to short (%d)\n", strlen(*url));
+@@ -159,7 +156,7 @@ parse_buff(char *buff, char **url, char
+it is already loaded, when squid runs - so not much waste of
+memory ;-) */
+ if ( (address.s_addr = inet_addr(*src_addr)) == -1 ) {
+- mylog(ERROR, "client IP address not valid %s\n",
++ mylog(ERROR, "client IP address (%s) not valid\n",
+ *src_addr ? *src_addr : "");
+ if ( token )
+ *token = '/';
+@@ -171,7 +168,7 @@ parse_buff(char *buff, char **url, char
+ /* make sure the IP source address matches that of the ones in our list */
+ if( ip_access_check(address, ip) == IP_DENY ) {
+ #ifdef DEBUG
+- mylog(DEBG, "client IP address %s not matched\n", *src_addr);
++ mylog(DEBG, "client IP address (%s) not matched\n", *src_addr);
+ #endif
+ return 1;
+ }
--- a/main.c
+++ b/main.c
-@@ -75,7 +75,7 @@ int main(int argc, char **argv)
+@@ -23,6 +23,7 @@
+
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -75,7 +76,7 @@ int main(int argc, char **argv)
/*int first_run = 1; */
char buff[BUFSIZE];
char redirect_url[BUFSIZE];
@@ -180,7 +214,7 @@
int finished = 0;
int buff_status = 0;
ip_acl *ip_list = NULL;
-@@ -93,7 +93,7 @@ int main(i
Bug#862005: duplicity crashes with "-tempdir failed" messg
severity 862005 normal tags 862005 + upstream forwarded 862005 https://bugs.launchpad.net/duplicity/+bug/1177381 thanks On Sun, 07 May 2017 12:27:57 +0200, Ralf writes: >duplicity --no-encryption full --archive-dir /media/userL/backup/log >/home/userL file:///media/userL/backup/backup just for the record/completeness of the evidence: what version of gpg do you have installed? what kind of filesystem is used for /media/userL? do you have something like tmpreaper installed that might delete tempfiles from underneath duplicity? is this running on a laptop that may have gone to sleep while the backup was running? could you provide the output of a run with -v 9 (anonymised if need be)? >Given the simplicity of the command sequence, I am expecting >this to be a bug upstream's bug tracker has a report that matches your usage and error at https://bugs.launchpad.net/duplicity/+bug/1177381 i cannot reproduce the problem here, but upstream seems to be working on that particular issue. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, Putzfrau: Nicht absichtlich bösartig handelnde Person ohne Entscheidungsgewalt -- Bodo Eggert signature.asc Description: Digital Signature
Bug#860849: duplicity: Duplicity OOMs machines while processing backup chains (memleak?)
On Sun, 23 Apr 2017 00:19:17 +0200, Maarten Aertsen writes: >Because duplicity does not perform the cleanup, at some point >the oldest chain breaks (when the first incremental gets deleted). (sorry for the long delay, i had an undiscovered gotcha in my email setup...) does the problem surface before or after s3 has started ditching files belonging to duplicity? does the problem also appear if you run with --max-blocksize=20480 or higher (which is mentioned as a possible limiting mechanism for memory use especially when backing up large individual files, as per https://bugs.launchpad.net/duplicity/+bug/1005478) regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, Halflife-Server: Server, der nur halb lebt. Kurz: IIS. -- Andreas Dau signature.asc Description: Digital Signature
Bug#860849: duplicity: Duplicity OOMs machines while processing backup chains (memleak?)
tags 860849 + moreinfo severity 860849 normal thanks On Thu, 20 Apr 2017 23:47:19 +0200, Maarten Aertsen writes: >Using duplicity with a S3 remote for a while, until multiple backup >chains exist. could you please provide the output of a collection-status, 'multiple chains exist' is a bit too little information to debug. how often do you remove chains? how many chains are there? how many incrementals per chain? > * What exactly did you do (or not do) that was effective (or ineffective)? >/usr/bin/duplicity full --s3-use-ia --asynchronous-upload --encrypt-key > --encrypt-key --include-filelist /etc/backup-targets / does your /etc/backup-targets exclude /proc, /sys and /dev? otherwise your invocation as given here would attempt to back up everything, including stuff like /dev/mem. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Gratitude is a disease of dogs. -- Joseph Stalin signature.asc Description: Digital Signature
Bug#859903: kuvert aborts with syslog enabled and UTF-8 chars in messages
On Sun, 09 Apr 2017 02:14:11 +0200, gregor herrmann writes: >kuvert failed to start for me today (i.e. at the first start after >upgrading to 2.1.0) with > >Wide character in syswrite at >/usr/lib/x86_64-linux-gnu/perl/5.24/Sys/Syslog.pm line 544. oops. looks like i've run afoul of https://rt.cpan.org/Public/Bug/Display.html?id=41233 >this case [0]) cyrillic characters. thanks for the example key, that was very helpful. >The same happens when writing to a logfile (after enabling the option >in the config): > >Wide character in print at /usr/bin/kuvert line 1357. not quite the same: that one is just a nuisance warning, not a terminal gotcha. as a workaround i'd recommend that you use kuvert with a logfile unti l i've got this sorted out properly (hopefully within the next day or two). regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism." -- Paul Tomblin signature.asc Description: Digital Signature
Bug#852422: Please stop yelling about deprecation
reassign 852422 python-paramiko thanks On Tue, 24 Jan 2017 11:27:39 +0100, Jean-Michel Vourgère writes: >Since I updated python-crypto to 2.6.1-5+deb8u1 [1] duplicity prints warnings >every time it runs. Like most user, I suppose, I run from cron. This means I >now receive a daily spam with: >/usr/lib/python2.7/dist-packages/Crypto/Cipher/blockalgo.py:141: >FutureWarning: CTR mode needs counter parameter, not IV > self._cipher = factory.new(key, *args, **kwargs) it is not duplicity that's causing/printing this message but python-paramiko: duplicity does not use python-crypto. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin signature.asc Description: Digital Signature
Bug#751902: bug 751902
On Mon, 09 Jan 2017 23:17:05 +0100, Moritz Muehlenhoff writes: >Given that this is unfixed upstream for years, let's exclude the backend from >the Debian binary package? no, i don't want to do that. as of python-boto 2.6, certificate validation is auto-enabled. pity that that's not in debian yet... http://docs.pythonboto.org/en/latest/releasenotes/v2.6.0.html (or is it 2.45? utter confusion seems to reign over there...) having looked at this now it seems easy to simply hack the 'mandatory not optional' part into the debian version. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ cc:Mail is a wonderful application, as long as you don't want to read or send mail. -- Jan van den Broek signature.asc Description: Digital Signature
Bug#850077: duplicity: Backup fail since upgrade of python-crypto from 2.6-4+deb7u3 to 2.6-4+deb7u4
reassign 850077 python-paramiko retitle 850077 python-paramiko doesn't work with python-crypto 2.6-4 thanks, On Tue, 03 Jan 2017 21:49:21 +0100, Patrick Valsecchi writes: >Since yesterday's update, backup to a SSH target is broken and leads to this st >acktrace: > >ssh: Unknown exception: CTR mode needs counter parameter, not IV >ssh: Traceback (most recent call last): >ssh: File "/usr/lib/python2.7/dist-packages/paramiko/transport.py", line 1542 >, in run >ssh: self.kex_engine.parse_next(ptype, m) this is a bug in python-paramiko, not duplicity. as far as i can tell that particular problem seems to be known to paramiko's upstream and tracked at https://github.com/paramiko/paramiko/issues/713 i've got no idea what paramiko releases do contain the fix. the workarounds options for duplicity and for now include your python-crypto downgrade, or falling back to the ssh/pexpect ssh backend. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Q. how many lightbulbs does it take to change a light bulb? A. one, if it knows its own Goedel number. signature.asc Description: Digital Signature
Bug#848259: nmh: Sending messages over TLS results in erroneous "send: message not delivered to anyone"
On Thu, 15 Dec 2016 11:27:13 -0800, "C. Morgan Hamill" writes: >My suspicion is that this is because of the recent change to building >against OpenSSL 1.1, though I am not positive. i've traced the issue down to openssl 1.1, which indeed is the cause; contrary to the docs bio_ssl_shutdown() is no good for shutting down a normal connection when done with it; it segfaults. mts/smtp/smtp.c is where that happens, which is part of /usr/lib/mh/post, which is what send forks and execs for the actual work. post segfaults basically after finishing all its work bar the socket/ssl cleanup, send catches that and reports 'not delivered to anybody'. a fix is in the works and an updated version will be uploaded within the next 24 hours. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism." -- Paul Tomblin signature.asc Description: Digital Signature
