Bug#851877: fails every time

[Michael Stapelberg]

On Mon, May 15, 2017 at 1:52 AM, Guillaume Delacour  wrote:

> Hi,
>
> Le 15/05/2017 à 00:50, Adam Borowski a écrit :
>
> >
> > So it's a fully _reproducible_ bug, with a well-defined immediate cause
> > (even if we haven't identified the indirect cause yet) -- unlike the
> > original report by Santiago Villa.  Thus, it looks we have two different
> > bugs that just happen to trigger the same failure mode.
> >
> > And thus, even if we fix the schroot issue, Santiago's bug likely won't
> be
> > fixed.
> >
> >> Now, the next question is: where does this /etc/hosts come from? The
> file
> >> is present in the above form directly after unpacking the schroot
> tarball,
> >> before even entering the schroot.
> >
> >> Running debootstrap does not produce an /etc/hosts in --variant=minbase
> and
> >> --variant=buildd. When run without --variant, it does produce an
> >> /etc/hosts, but that looks correct:
> > [snip]
> >> So, where does the file get mangled? I can’t find any traces in the
> schroot
> >> and sbuild sources. Does anyone know by chance?
> >
> > Even more puzzling: I just recreated the chroot again, and despite using
> the
> > very same command to do so as before (last on 2017-05-04) there's no
> > /etc/hosts in the chroot now, which makes sslh build correctly.
> >
> > The version from 2017-05-04 includes has an /etc/hosts, with ::1
> replaced by
> > 127.0.0.1 just as you noticed.  And I see no uploads of debootstrap,
> sbuild,
> > schroot or a package that looks related in that time period.
> >
> > Got an unrelated big build running at the moment, once it's done I'll
> boot
> > from a snapshot (got backups from 2017-05-01 (plus earliers) and dailies
> > since 2017-05-06) to see if it's a matter of an installed package.
> >
> > But again, this is probably unrelated to Santiago's bug other than for
> the
> > results.
>
> As this bug is not related to sslh package itself, i've removed the
> pending tag, i let Michael revert
> https://anonscm.debian.org/cgit/collab-maint/sslh.git/commit/?id=
> 243bb3faa682afa8168664eaf5a4f72cfc21ee27
> and closing this bug to disable the autoremoval in testing.
>

Note that my commit still improves things, regardless of this specific bug
report or others. I think the best outcome in the long run would be to keep
the commit by upstreaming it. I can understand if you’d like to revert it
while we’re in a freeze, but let’s not drop it entirely please :).

-- 
Best regards,
Michael

Bug#189026: side-by-side diffs are unreadable

[Dima Kogan]

Hi.

The current behavior of splitting diffs into whitespace-separated tokens
completely obliterates readability of side-by-side diffs. Can we do
something about that?

I'm attaching a patch to handle this case specifically. This isn't very
nice, but it proves the concept.

To make side-by-side diffs look right, ucf needed to be patched also:

  http://bugs.debian.org/862607

With these two patches, these diffs are rendered properly. Should be do
this better in some way?


>From ea0a9f7ca0b440e76907b296f015d3c91d4d119d Mon Sep 17 00:00:00 2001
From: Dima Kogan 
Date: Sun, 14 May 2017 22:12:20 -0700
Subject: [PATCH] Don't split diff content into space-separated tokens

Prior to this patch, diffs are split by spaces and then reconstituted when
rendering. This is not only needless work, but affects readability, since
multiple consecutive spaces are crushed into one.

For side-by-side diffs this DESTROYS readability entirely.

This patch special-cases DIFFs, which possibly is not sufficient, but it solves
this specific issue
---
 Debconf/ConfModule.pm | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Debconf/ConfModule.pm b/Debconf/ConfModule.pm
index b3989a68..4615c247 100644
--- a/Debconf/ConfModule.pm
+++ b/Debconf/ConfModule.pm
@@ -200,6 +200,24 @@ whitespace.
 
 sub unescape_split {
 	my $text=shift;
+
+
+sub unescape {
+my $s = shift;
+$s =~ s/\\([rnt'"\\])/"qq{\\$1}"/gee;
+return $s;
+};
+if ( $text =~ /^
+  (SUBST) \s+
+  (\S+)   \s+
+  (DIFF)  \s+
+  (.*?) $
+ /sx ) {
+
+return ($1,$2,$3,unescape($4));
+}
+
+
 	my @words;
 	my $word='';
 	for my $chunk (split /(\\.|\s+)/, $text) {
-- 
2.11.0

Bug#862607: ucf: [PATCH] diffs are rendered with broken spacing

[Dima Kogan]

Package: ucf
Version: 3.0036
Severity: normal

Hi. Currently diffs generated by ucf produce TABs, which can make diffs
render improperly. This is especially an issue with side-by-side diffs,
where clobbered spacing makes the output unreadable. I'm attaching a
patch that asks diff to expand TABs into spaces to fix this. For
whiptail-based debconf this is necessary, but not sufficient: see

  http://bugs.debian.org/189026

>From 65ee66858dfdddff104c914b408ba42190d304ec Mon Sep 17 00:00:00 2001
From: Dima Kogan 
Date: Sun, 14 May 2017 22:00:29 -0700
Subject: [PATCH] diffs use spaces instead of tabs

They are thus rendered faithfully on all terminals. whiptail-based debconf
dialogs have a second bug that needs to be fixed to make it work properly. I'm
about to file it
---
 ucf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ucf b/ucf
index cbbeada..cccb686 100755
--- a/ucf
+++ b/ucf
@@ -1011,11 +1011,11 @@ else
 		exit 0;
 		;;
 	diff|D|d)
-		DIFF="$(run_diff diff -uBbw "$dest_file" "$new_file")"
+		DIFF="$(run_diff diff -uBbwt "$dest_file" "$new_file")"
 		show_diff "$DIFF"
 		;;
 	sdiff|S|s)
-		DIFF="$(run_diff sdiff -BbW "$dest_file" "$new_file")"
+		DIFF="$(run_diff sdiff -BbWt "$dest_file" "$new_file")"
 		show_diff "$DIFF"
 		;;
 	diff_threeway|3|t|T)
-- 
2.11.0




-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), 
(500, 'stable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.1 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ucf depends on:
ii  coreutils  8.26-3
ii  debconf1.5.60

ucf recommends no packages.

ucf suggests no packages.

-- debconf information:
* ucf/show_diff:
* ucf/changeprompt: install_new
* ucf/changeprompt_threeway: keep_current
  ucf/title:
* ucf/conflicts_found:

Bug#771790: Package broken

[Val Markovic]

I'm interested in fixing this package if there are still users interested
in using it. Popcon says 1 machine uses this:
https://qa.debian.org/popcon.php?package=dirty.js

Marcos, do you still use this package?

Bug#853801: useless with this bug

[Adam Borowski]

Control: severity -1 grave

Well, since left click is the only documented way to set up any mapping
(doing it manually requires 1. seeing a sample config, 2. having the table
of key codes), the package is effectively useless as shipped.

The patch doesn't apply, need to revert that clang "fix" first.  Looks like
someone only build-tested that, without even trying to run the program...


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.

Bug#862605: Missing ondemand CPU governor.

[dE]

Package: linux-image-3.16.0-4-amd64
Version: 3.16.39-1+deb8u2
Severity: serious

A kernel update removed the cpufreq_ondemand.ko kernel module. Don't 
know exactly which version. The module was build as per the kernel 
configuration --


grep -i ondemand config-3.16.0-4-amd64
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y

And is the default (and missing).

The kernel now defaults to powersave.

So it appears that all servers and desktops are now running in 
'powersave' mode now after an update.


Requesting check of other missing kernel modules if this is indeed a bug.

Bug#862606: intel-microcode: microcode update may hang Xeon E7-8891v4/E7-8893v4

[Henrique de Moraes Holschuh]

Package: intel-microcode
Version: 3.20160607.1
Severity: important

Erratum BDF90 (BDX90?) for the Xeon E7v4 (and maybe Xeon E5v4) may
result in a hung system on all affected processors when a microcode
update is attempted during boot on a Debian system with the
intel-microcode package installed.

If this errata is being triggered on a system and causing boot hangs,
please boot the kernel using the "dis_ucode_ldr" parameter to bypass the
kernel microcode loader, as described in the intel-microcode package
documentation (README.Debian):

https://sources.debian.net/src/intel-microcode/3.20161104.1/debian/README.Debian/#L104


Known details about BDF90:

   Intel® Xeon® Processor E7-8800/4800 v4 Product Family Specification
   Update, April 2017:

   BDF90 - Loading Microcode Updates or Executing an Authenticated Code 
   Module May Result in a System Hang

   Problem: An uncorrectable error (IA32_MC3_STATUS.MCACOD=0400 and
   IA32_MC3_STATUS.MSCOD=0080) may be logged for processors that have
   more than 2.5MB last-level-cache per core on attempting to load a
   microcode update or execute an authenticated code module. This issue
   does not occur with microcode updates with a signature of 0x0b21
   and greater.

   Implication: Due to this erratum, the processor may hang when
   attempting to load a microcode update or execute an authenticated
   code module.

Known-affected processors (list may be incomplete):
Xeon E7-8891v4
Xeon E7-8893v4

Other possibily-affected processors (incomplete list):
Xeon E5-2667v4
Xeon E5-2643v4
Xeon E5-2637v4
Xeon E5-4655v4

This erratum is worked around by microcode revision 0xb21, included
in the intel-microcode 20170511 release (which will be uploaded soon).

-- 
  Henrique Holschuh

Bug#861699: RFS: writegood-mode/2.0.2-1 [ITP]

[Nicholas D Steeves]

control: tag -1 -moreinfo

On Sun, May 14, 2017 at 05:02:23PM -0700, Sean Whitton wrote:
> control: owner -1 !
> control: tag -1 +moreinfo
> 
> On Tue, May 02, 2017 at 04:58:31PM -0400, Nicholas D Steeves wrote:
> > I am looking for a sponsor for my package "writegood-mode"
> 
> a5b0ac4 looks good, except I think you should install the README, which
> could be quite useful to users.

Fixed in 8b01827.  I also thought it might be helpful to file a
wishlist bug against dh-make-elpa's create_docs on this topic, so
filed one.

> If you're able to address the issues I've raised in this message, please
> remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
> to refresh the changelog timestamp.

Thank you for the reminder :-) Fixed in f2b952d.  For your convenience
I've also refreshed the package on mentors.

Cheers,
Nicholas





signature.asc
Description: Digital signature

Bug#862603: te923con: FTBFS on non-Linux: usb_*_driver_np undefined

[Aaron M. Ucko]

Source: te923con
Version: 0.6.1-1
Severity: important
Justification: fails to build from source

The build of te923con for hurd-i386 (admittedly not a release
architecture) failed:

  te923usb.c: In function 'te923_handle':
  te923usb.c:67:9: warning: implicit declaration of function 
'usb_get_driver_np' [-Wimplicit-function-declaration]
 ret = usb_get_driver_np(devh, 0, driver_name, driver_name_len);
   ^
  te923usb.c:69:5: warning: implicit declaration of function 
'usb_detach_kernel_driver_np' [-Wimplicit-function-declaration]
   usb_detach_kernel_driver_np( devh, 0 );
   ^~~
  /tmp/ccHeVdmH.o: In function `te923_handle':
  ./te923usb.c:67: undefined reference to `usb_get_driver_np'
  ./te923usb.c:69: undefined reference to `usb_detach_kernel_driver_np'
  collect2: error: ld returned 1 exit status

The package is still in the Needs-Build queue on kfreebsd-*, but I
suspect it will hit the same problem there.  If these calls are
essential, please restrict the package's Architecture: field to
linux-any accordingly.  Otherwise, please conditionalize them on
LIBUSB_HAS_GET_DRIVER_NP and LIBUSB_HAS_DETACH_KERNEL_DRIVER_NP
respectively.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#862604: dh-make-elpa: extending create_docs{}

[Nicholas D Steeves]

Package: dh-make-elpa
Version: 0.7.1
Severity: wishlist

Hi Sean,

I thought I'd take a quick look at dh-make-elpa's create_docs, because
I've been using dh-make-elpa a lot recently.  What do you think of
iteratively printing (filename\n) from a list generated from *.md and
*.org instead of checking for an *.md and writing "*.md\n"?  Then the
file (containing an \n separated list) could be copied/moved to
package1.docs and package2.docs and the items not relevant to
$packageX could simply be cut from its packageX.docs.  That's more or
less way I do it from the shell.

Also, if there will be package-name-based heuristics then I'm guessing
any potential-doc-type.files that match a hungry glob for "first"
could go into elpa-first.doc, anything that matches "second" and not
"first" would go into elpa-second.doc, and anything that doesn't match
either can go into something like needs-review.doc.  That last one
ought to produce a lintian error and force manual review.

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#789150: #789150 boot failure with root=UUID= and software RAID

[Elliott Mitchell]

I ran into this issue myself and was trying to figure out how to solve
it.

Examining the initrd image which had been created, the
63-md-raid-arrays.rules and 64-md-raid-assembly.rules files were absent.
As mentioned in #789150, mdadm now has its own
/usr/share/initramfs-tools/hooks/mdadm which *should* copy those two
files into any initrd which is created.

When I regenerated the initrd by running `update-initramfs -u -k all`,
the two udev rules files *were* present.  Looking at things there are
two things I /suspect/ may have happened.

First, when initially building the image for this system I was working
from a qemu image.  Reliability was handled outside of qemu and hence the
mdadm package didn't include itself into the initrd.  Perhaps the mdadm
initramfs hook script should treat a value of "MODULES=most" as an
indicator to *always* include itself into the initrd (this IS a hint that
something major may change soon).

Second, perhaps the issue was the mdadm package was installed /after/
the kernel and bootloader packages were installed so the initial ramdisk
image was never rebuilt.  Perhaps this indicates mdadm's postinst script
needs to preemptively run `update-initramfs -u -k all` after
installation (similar situation for postrm).


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#862602: libcore-cache-clojure: Package is missing a dependency

[Elana Hashman]

Package: libcore-cache-clojure
Version: 0.6.5-1
Severity: grave
Justification: renders package unusable
Control: block -1 by 855722

Hello!

While working on packaging libstencil-clojure, I noticed that the
dependency org.clojure/data.priority-map was missing, and traced it down
to this package:

$ clojure -cp /usr/share/java/core.cache.jar
Clojure 1.8.0
user=> (use 'clojure.core.cache)
CompilerException java.io.FileNotFoundException: Could not locate 
clojure/data/priority_map__init.class or clojure/data/priority_map.clj 
on classpath.  Please check that namespaces with dashes use underscores 
in the Clojure file name., compiling:(clojure/core/cache.clj:1:1)


Indeed, libcore-cache-clojure does not have
org.clojure/data.priority-map as a build dep nor in its classpath. In
fact, it appears the POM packaged in maven-meta is outdated to version
0.6.2.

While it is not currently in Debian, there is already an ITP for
data-priority-map-clojure. I've marked that as blocking this bug.

I'd be happy to take a stab at fixing this some time in the next couple
of weeks.

- e


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcore-cache-clojure depends on:
ii  libclojure-java  1.8.0-2

libcore-cache-clojure recommends no packages.

libcore-cache-clojure suggests no packages.

-- no debconf information

Bug#862601: libmaven3-core-java: Version upgrade request to 3.5.0

[Elana Hashman]

Package: libmaven3-core-java
Version: 3.3.9-4
Severity: wishlist
Control: block 862233 by -1

To facilitate packaging leiningen2, this package needs an upgrade to 
version 3.5.0.


This is because its dependency libpomegranate-clojure currently depends 
on a version of maven much older than available in unstable. We are 
working to upgrade that upstream, and would prefer to use version 3.5.0 
over 3.3.9, as the latter has a dependency (libaether-java) that has 
been orphaned. Maven 3.5.0 imports aether directly into its codebase. 
See #862233 for more info.

Bug#862422: [pkg-golang-devel] Bug#862422: gccgo-go: wrap gccgo-7 for full Go 1.8 runtime

[Aaron M. Ucko]

Michael Hudson-Doyle  writes:

> Makes sense to me, I'd be happy to upload that change to experimental.

Great, thanks!

> What's the timeframe for gccgo-7 getting into unstable? Just waiting for
> buster development to open?

Presumably; I'm not aware of another reason to hold off.  (An official
7.1 release recently came out, and there aren't experimental versions of
binutils or glibc that could need to accompany GCC 7 to unstable.)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#861584: xfwm4 bug report filed

[Zenaan Harkness]

See XFCE / xfwm4 bug report filed here:
https://bugzilla.xfce.org/show_bug.cgi?id=13575

See recent email here:
https://mail.xfce.org/pipermail/xfce/2017-May/035584.html

Bug#860609: influxdb: FTBFS: Test failures

[Santiago Vila]

Version: 1.1.1+dfsg1-4

On Wed, 19 Apr 2017, Lucas Nussbaum wrote:

> Source: influxdb
> Version: 1.1.1+dfsg1-2
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20170418 qa-ftbfs
> Justification: FTBFS in stretch on amd64
> 
> Hi,
> 
> During a rebuild of all packages in stretch (in a stretch chroot, not a
> sid chroot), your package failed to build on amd64.
> 
> Relevant part (hopefully):
> > --- PASS: TestTSMWriter_Write_MaxKey (1.42s)
> > [tsm1] 2017/04/18 22:30:50 Snapshot for path /tmp/tsm1-930652078/data 
> > written in 4.939975ms
> > [tsm1] 2017/04/18 22:30:50 Snapshot for path /tmp/tsm1-248119605/data 
> > written in 4.998884ms
> > --- PASS: TestEngine_CreateIterator_Cache_Ascending (2.00s)
> > --- PASS: TestEngine_CreateIterator_Aux (2.00s)
> > --- PASS: TestEngine_CreateIterator_TSM_Ascending (2.00s)
> > --- PASS: TestEngine_CreateIterator_Cache_Descending (2.00s)
> > --- PASS: TestEngine_CreateIterator_TSM_Descending (2.00s)
> > --- PASS: TestEngine_CreateIterator_Condition (2.00s)
> > FAIL
> > exit status 1
> > FAILgithub.com/influxdata/influxdb/tsdb/engine/tsm1 54.021s
> > ?   github.com/influxdata/influxdb/tsdb/internal[no test files]
> > ?   github.com/influxdata/influxdb/uuid [no test files]

This failure is the same I reported in Bug #850282, and it should be
fixed in version 1.1.1+dfsg1-4.

Let's hope that britney takes this closing-with-version message
as an indication that version 1.1.1+dfsg1-4 should propagate to testing.

If this does not happen automatically, please ask for a freeze
exception, as the old version 1.1.1+dfsg1-2 used to fail more than 80%
of the time in my autobuilders.

Thanks.

Bug#842634: Bug#851877: fails every time

[Adam Borowski]

Control: severity -1 important

On Mon, May 15, 2017 at 01:52:09AM +0200, Guillaume Delacour wrote:
> Le 15/05/2017 à 00:50, Adam Borowski a écrit :
> > So it's a fully _reproducible_ bug, with a well-defined immediate cause
> > (even if we haven't identified the indirect cause yet) -- unlike the
> > original report by Santiago Villa.  Thus, it looks we have two different
> > bugs that just happen to trigger the same failure mode.
> > 
> > And thus, even if we fix the schroot issue, Santiago's bug likely won't be
> > fixed.
> >  
> >> Now, the next question is: where does this /etc/hosts come from? The file
> >> is present in the above form directly after unpacking the schroot tarball,
> >> before even entering the schroot.
> 
> As this bug is not related to sslh package itself, i've removed the
> pending tag, i let Michael revert
> https://anonscm.debian.org/cgit/collab-maint/sslh.git/commit/?id=243bb3faa682afa8168664eaf5a4f72cfc21ee27
> and closing this bug to disable the autoremoval in testing.

Well, closing is inappropriate, as we have at least _two_ bugs that result
in sslh hanging during the testsuite -- this one being deterministic means
it clearly is not the cause of random FTBFSes as in the original report.

Let's restore the severity then, as the not-yet-known bug happens only some
of the time.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.

Bug#861699: RFS: writegood-mode/2.0.2-1 [ITP]

[Sean Whitton]

control: owner -1 !
control: tag -1 +moreinfo

On Tue, May 02, 2017 at 04:58:31PM -0400, Nicholas D Steeves wrote:
> I am looking for a sponsor for my package "writegood-mode"

a5b0ac4 looks good, except I think you should install the README, which
could be quite useful to users.

If you're able to address the issues I've raised in this message, please
remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
to refresh the changelog timestamp.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#771671: Fixing kexec-tools bugs in jessie

[Khalid Aziz]

On 05/14/2017 05:59 AM, Adrian Bunk wrote:
> Hi Khalid,
> 
> the following RC bugs are open for kexec-tools in jessie and
> seem worth fixing:
> 
>   771671 /sbin/kexec: Unable to load kdump kernel on i386
>   782033 kexec-tools: Reboots the machine while removing the package
>   785714 kexec-tools is broken when using systemd, danger of filesystem 
> corruption
>   807018 kexec-tools: upgrade wheezy-jessie is broken (update-rc.d: 
> /etc/init.d/kexec exists during rc.d purge)
> 
> Could you make a jessie-pu upload [1] fixing them there?
> Alternatively, I can fix them for jessie if you don't object.
> 
> Thanks
> Adrian
> 
> [1] 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> 

Hi Adrian,

Please go ahead and fix them for jessie.

Thanks,
Khalid

Bug#862600: tests.r-b.o: tests version from sid in testing due to the source is in testing due to Built-Using:…

[Holger Levsen]

Package: jenkins.debian.org
Severity: normal
x-debbugs-cc: b...@debian.org

Dear Maintainer,

< bunk> 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-rackspace-gophercloud.html
< bunk> This seems confused by the more recent source that is in stretch due to 
Built-Using?
<  h01ger> | oh! it builds the sid version in stretch!
<  h01ger> | bunk: so the sid version "is in stretch" because some packages 
in stretch were build using the sid version and then migrated. wow. i think i 
have  discussed this with ivodd once in a corridor at the bsp at credativ in 
march 2017 or so…
<  h01ger> | i also think this is a topic for #-release
<  h01ger> | (unless they know)
<  h01ger> | and then its also a bug in the tests.r-b.o setup, to test the 
wrong version…
<  h01ger> | fwiw:
<  h01ger> | $ rmadison golang-github-rackspace-gophercloud
<  h01ger> | debian:
<  h01ger> |  golang-github-rackspace-gophercloud | 
1.0.0+git20160603.920.934dbf8-1   | stretch | source
<  h01ger> |  golang-github-rackspace-gophercloud | 
1.0.0+git20161013.1012.e00690e8-1 | sid | source
<  h01ger> | and tests.r-b.o only shows the sid version being tested in 
stretch+sid…
<   bunk> | h01ger: How does r-b pick the version? Sources?
<  h01ger> | etootired. check bin/reproducible_build.sh in jenkins.d.n.git 
please…
< bunk> 
https://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree/bin/reproducible_build.sh#n540
< bunk> apt-get -- --download-only --only-source source ${SRCPACKAGE}
< bunk> (if I read the script correctly)
<  h01ger> | bunk: may i quote your initial question into the BTS?
<  h01ger> | +could be it… ;)
< bunk> sure

Thanks for the bug report, Adrian!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#842634: Bug#851877: fails every time

[Guillaume Delacour]

Hi,

Le 15/05/2017 à 00:50, Adam Borowski a écrit :

> 
> So it's a fully _reproducible_ bug, with a well-defined immediate cause
> (even if we haven't identified the indirect cause yet) -- unlike the
> original report by Santiago Villa.  Thus, it looks we have two different
> bugs that just happen to trigger the same failure mode.
> 
> And thus, even if we fix the schroot issue, Santiago's bug likely won't be
> fixed.
>  
>> Now, the next question is: where does this /etc/hosts come from? The file
>> is present in the above form directly after unpacking the schroot tarball,
>> before even entering the schroot.
> 
>> Running debootstrap does not produce an /etc/hosts in --variant=minbase and
>> --variant=buildd. When run without --variant, it does produce an
>> /etc/hosts, but that looks correct:
> [snip]
>> So, where does the file get mangled? I can’t find any traces in the schroot
>> and sbuild sources. Does anyone know by chance?
> 
> Even more puzzling: I just recreated the chroot again, and despite using the
> very same command to do so as before (last on 2017-05-04) there's no
> /etc/hosts in the chroot now, which makes sslh build correctly.
> 
> The version from 2017-05-04 includes has an /etc/hosts, with ::1 replaced by
> 127.0.0.1 just as you noticed.  And I see no uploads of debootstrap, sbuild,
> schroot or a package that looks related in that time period.
> 
> Got an unrelated big build running at the moment, once it's done I'll boot
> from a snapshot (got backups from 2017-05-01 (plus earliers) and dailies
> since 2017-05-06) to see if it's a matter of an installed package.
> 
> But again, this is probably unrelated to Santiago's bug other than for the
> results.

As this bug is not related to sslh package itself, i've removed the
pending tag, i let Michael revert
https://anonscm.debian.org/cgit/collab-maint/sslh.git/commit/?id=243bb3faa682afa8168664eaf5a4f72cfc21ee27
and closing this bug to disable the autoremoval in testing.


-- 
Guillaume Delacour



signature.asc
Description: OpenPGP digital signature

Bug#862599: webhook.service should have ConditionFileExist=/etc/webhook.conf

[Felipe Sateler]

Package: webhook
Version: 2.5.0-1+b2
Severity: wishlist

Hi,

The webhook service file could benefit from having
ConditionFileExists=/etc/webhook.conf . Since webhook can't do anything
if there is no config file, it makes sense to not even start the service
if the config file does not exist.

Saludos

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages webhook depends on:
ii  init-system-helpers  1.48
ii  libc62.24-10

webhook recommends no packages.

webhook suggests no packages.

-- no debconf information

Bug#862593: xarchiver: Adding files to .tar.xz deletes existing content

[Nikolaus Rath]

> Steps to reproduce:
> 
> $ echo foo > "Kieran Daycare Contract.pdf"
> $ echo bar > "Kieran Daycare 2.pdf"
> $ tar cJvf "Kieran Daycare Contract.pdf.tar.xz" "Kieran Daycare
> Contract.pdf"
> Kieran Daycare Contract.pdf
> 
> $ xarchiver Kieran\ Daycare\ Contract.pdf.tar.xz 
> # Select Action->Add
> # Select the "bar.txt" file

This should of course have been "Select the 'Kieran Daycare 2.pdf'
file". 

Best,
-Nikolaus

Bug#862354: ITP: installation-birthday -- Receive congratulations on system installation anniversaries

[Holger Levsen]

On Fri, May 12, 2017 at 10:09:09AM +0100, Chris Lamb wrote:
> Updated the package description to make this clearer. :)

cool, thanks!

is it already suggested by debian-goodies? ;-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#862598: unblock: udfclient/0.8.7-1

[Pali Rohár]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package udfclient

New upstream version fixes CVE-2017-8305 (Buffer overflow in strlcpy
implementation), debian bug #861347. As protection for buffer overflows,
package has now enabled hardening. Source debdiff is attached.

unblock udfclient/0.8.7-1

-- 
Pali Rohár
pali.ro...@gmail.com
diff -Nru udfclient-0.8.7/cd_disect.c udfclient-0.8.8/cd_disect.c
--- udfclient-0.8.7/cd_disect.c	2017-01-16 15:35:03.0 +0100
+++ udfclient-0.8.8/cd_disect.c	2017-04-03 11:38:13.0 +0200
@@ -2,7 +2,7 @@
 
 /*
  * File "cd_disect.c" is part of the UDFclient toolkit.
- * File $Id: cd_disect.c,v 1.80 2016/04/25 20:55:30 reinoud Exp $ $Name:  $
+ * File $Id: cd_disect.c,v 1.81 2017/04/03 08:48:51 reinoud Exp $ $Name:  $
  *
  * Copyright (c) 2003, 2004, 2005, 2006, 2011
  * 	Reinoud Zandijk 
@@ -211,7 +211,7 @@
 		if (cntrl & 1) strcat(scrap, "; incremental  "); else strcat(scrap, "; uninterrupted");
 	} else {
 		strcat(scrap, "audio track");
-		if (cntrl & 1) strcat(scrap, "; pre-emphasis of 50/15 µs"); else strcat(scrap, "; no pre-emphasis");
+		if (cntrl & 1) strcat(scrap, "; pre-emphasis of 50/15 microseconds"); else strcat(scrap, "; no pre-emphasis");
 	}
 	if (cntrl & 2) strcat(scrap, "; copy prohibited");
 
@@ -1384,7 +1384,7 @@
 if (cntrl & 1) printf("; incremental  "); else printf("; uninterrupted");
 			} else {
 printf("audio track");
-if (cntrl & 1) printf("; pre-emphasis of 50/15 µs"); else printf("; no pre-emphasis");
+if (cntrl & 1) printf("; pre-emphasis of 50/15 microseconds"); else printf("; no pre-emphasis");
 			}
 			if (cntrl & 2) printf("; copy prohibited");
 			printf(")\n");
diff -Nru udfclient-0.8.7/configure udfclient-0.8.8/configure
--- udfclient-0.8.7/configure	2017-01-16 15:35:03.0 +0100
+++ udfclient-0.8.8/configure	2017-04-03 11:38:13.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for udfclient 0.8.7.
+# Generated by GNU Autoconf 2.69 for udfclient 0.8.8.
 #
 # Report bugs to .
 #
@@ -580,8 +580,8 @@
 # Identity of this package.
 PACKAGE_NAME='udfclient'
 PACKAGE_TARNAME='udfclient'
-PACKAGE_VERSION='0.8.7'
-PACKAGE_STRING='udfclient 0.8.7'
+PACKAGE_VERSION='0.8.8'
+PACKAGE_STRING='udfclient 0.8.8'
 PACKAGE_BUGREPORT='rein...@netbsd.org'
 PACKAGE_URL=''
 
@@ -1239,7 +1239,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures udfclient 0.8.7 to adapt to many kinds of systems.
+\`configure' configures udfclient 0.8.8 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1304,7 +1304,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of udfclient 0.8.7:";;
+ short | recursive ) echo "Configuration of udfclient 0.8.8:";;
esac
   cat <<\_ACEOF
 
@@ -1384,7 +1384,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-udfclient configure 0.8.7
+udfclient configure 0.8.8
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1810,7 +1810,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by udfclient $as_me 0.8.7, which was
+It was created by udfclient $as_me 0.8.8, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4537,7 +4537,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by udfclient $as_me 0.8.7, which was
+This file was extended by udfclient $as_me 0.8.8, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -4590,7 +4590,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-udfclient config.status 0.8.7
+udfclient config.status 0.8.8
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru udfclient-0.8.7/configure.ac udfclient-0.8.8/configure.ac
--- udfclient-0.8.7/configure.ac	2017-01-16 15:35:03.0 +0100
+++ udfclient-0.8.8/configure.ac	2017-04-03 11:38:13.0 +0200
@@ -2,7 +2,7 @@
 # Process this file with autoconf to produce a configure script.
 
 AC_PREREQ(2.57)
-AC_INIT([udfclient], [0.8.7], [rein...@netbsd.org])
+AC_INIT([udfclient], [0.8.8], [rein...@netbsd.org])
 #AC_CONFIG_SRCDIR([udf.c])
 AC_CANONICAL_HOST
 #AC_CONFIG_HEADER([config.h])
diff -Nru udfclient-0.8.7/debian/changelog udfclient-0.8.8/debian/changelog
--- 

Bug#844431: policy: packages should be reproducible

[Holger Levsen]

On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote:
> On Sun, May 14, 2017 at 03:20:54PM +, Holger Levsen wrote:
> > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> > a.) go to http://reproducible.debian.net/$srcpkg and see if its 
> > reproducible today.
> As I said, I would like to check that my package build is reproducible before
> I upload it, not after, so I can be sure that any bug is fixed in the
> upload.
 
b.), b.0), c.) and d.) were given as possible "tools" *to build twice with 
(some) variation(s) and compare the results*.

"Reproducible Builds" (in the sense of bit by bit identicall builds) is
really a rather new field in the era of software (well, not really, but 
thats history and bit rotted until it was rediscovered in the early 2010s…)

What is trivial, if given, is to show that a package is *un*reproducible.

It's much harder to show that a package is reproducible.

And given that this is a new field I think it's ok, while somewhat unsatisfying,
that maybe some unreproducibility will only be detected by a more advanced
tool, like reproducible.debian.net (which aint a,b,c nor d, but e.)
after an upload has taken place.

This is one of the reasons we are aiming for "packages *should* be reproducible"
now, and not "*must* be".

> Some of my package were listed as reproducible for several months and
> then became unreproducible without any new upload. I do not mind that.

I guess this is because we introduced many more variations during 2014 and 2015.
During 2016 I don't recall us introducing many varitions, or rather many
causing many new unreproducibilty issues…

For 2017 there weren't any.

> However from a policy point of view, reproducible need to be defined
> precisely.

Yes!

> Generally speaking, reproducible means that the build will
> not change if some (but not all) parameters are changed.

Yes.

> What parameters
> are allowed to change need to be defined.

I sadly think this is impossible.

> One way is specify that would be to provide an authoritative tool to
> validate packages.

the tool to validate builds should be diff/sha256sum. a tool to simulate all 
possible
variations in the wild would probably need endless time to operate… 

> PS: I thanks you for your advices, I will reply to you privately if I
> need to.

While you surely can do so (and I will happily reply) I would even more happily
prefer if you could ask me on public list (and ping in private if you havent 
gotten a reply in whatever you think is appropriate)… a.) then more people can 
learn b.) you'll probably get faster *and better replies* (esp. on language
specific details) and c.) this helps me getting my inbox under control :-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#789059: what is the state of this?

[Gürkan Myczko]

Hello Michael

Do you have anything done on this yet? I've quickly given it a look at, 
here

http://sid.ethz.ch/debian/infer/

Yours,

Bug#829046: Moving away from (unsupportable) FusionForge on Alioth?

[Sergio Durigan Junior]

On Sunday, May 14 2017, Boyuan Yang wrote:

> 在 2017年5月14日星期日 CST 下午3:04:26，Pirate Praveen 写道：
>> As far as I understand, the only thing that is blocking is non
>> availability of pagure package.
>> 
>> So helping fix this would help move this forward (currently pagure tests
>> are failing).
>> 
>> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046
>> 
>> After we have the package, then DSA standard processes for new service
>> would follow, I assume.
>
> I'm a little bit confused. The bug forwarding address in #829046 points at 
> http://git.sergiodj.net/, however I couldn't find packaging for pagure 
> anywhere. Seems all deleted sometime before.

Hi guys,

I have recently-ish moved my private things to another server, and I
think the pagure repo got lost somehow.  I'm currently out of town but
I'll fix this as soon as I get back, next weekend.

> The repository on collab-maint stops at September 2016 and lacks the work 
> around December 2016.

I wasn't really using the collab-maint repository because I haven't
created it, but I can move the latest version of my repo there.

On Sunday, May 14 2017, Pirate Praveen wrote:

> On ഞായര്‍ 14 മെയ് 2017 08:20 വൈകു, Boyuan Yang wrote:
>> I'm a little bit confused. The bug forwarding address in #829046 points at 
>> http://git.sergiodj.net/, however I couldn't find packaging for pagure 
>> anywhere. Seems all deleted sometime before.
>
> I don't know why Sergio does not want to create a stable repo at alioth.

It's not that I don't want.  It's that this is my usual workflow when
packaging things on Debian: I do everything on a local git repo, and
then move to collab-maint when the package is ready.

>> The repository on collab-maint stops at September 2016 and lacks the work 
>> around December 2016.
>
> Sergio,
>  Can we finalize on collab-maint and not resetting history for every change?

Sure.  I'll move everything to collab-maint as soon as I get back home,
as I said earilier.

>> Could you tell me where can I find the proper packaging repository?
>
> I have pushed my copy here
> https://git.fosscommunity.in/praveen/pagure
>
> It was originally at git://git.sergiodj.net/debian/pagure-new.git

Thanks for doing that.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#842634: Bug#851877: fails every time

[Adam Borowski]

On Sun, May 14, 2017 at 10:37:17PM +0200, Michael Stapelberg wrote:
> On Sun, May 14, 2017 at 7:59 AM, Adam Borowski  wrote:
> > > Use: gcc -Wall -o gai gai.c && ./gai localhost 9002
> >
> > On all three machines, it looks fine:
> >   ai_family = 10
> > host=::1, serv=9002
> >   ai_family = 2
> > host=127.0.0.1, serv=9002
> 
> This seems correct.

> > Inside the chroot:
> >   ai_family = 2
> > host=127.0.0.1, serv=9002
> >   ai_family = 2
> > host=127.0.0.1, serv=9002
> 
> This seems incorrect: the results are two IPv4 addresses (127.0.0.1:9002)
> as opposed to one IPv6 and one IPv4 address (or just one IPv4 address).
> 
> I can actually reproduce this issue on abel.debian.org (armhf porterbox):
> 
> On abel, my gai test program returns ::1, 127.0.0.1.
> On abel within an schroot, my gai test program returns 127.0.0.1, 127.0.0.1.
> 
> Looking at /etc/hosts within the schroot, I see:
> 127.0.0.1   localhost
> 127.0.0.1   localhost ip6-localhost ip6-loopback
> 172.28.17.11abel.debian.org abel
> 
> Modifying /etc/hosts by replacing ::1 with 127.0.0.1 results in being able
> to reproduce the issue on other machines as well.

So it's a fully _reproducible_ bug, with a well-defined immediate cause
(even if we haven't identified the indirect cause yet) -- unlike the
original report by Santiago Villa.  Thus, it looks we have two different
bugs that just happen to trigger the same failure mode.

And thus, even if we fix the schroot issue, Santiago's bug likely won't be
fixed.
 
> Now, the next question is: where does this /etc/hosts come from? The file
> is present in the above form directly after unpacking the schroot tarball,
> before even entering the schroot.

> Running debootstrap does not produce an /etc/hosts in --variant=minbase and
> --variant=buildd. When run without --variant, it does produce an
> /etc/hosts, but that looks correct:
[snip]
> So, where does the file get mangled? I can’t find any traces in the schroot
> and sbuild sources. Does anyone know by chance?

Even more puzzling: I just recreated the chroot again, and despite using the
very same command to do so as before (last on 2017-05-04) there's no
/etc/hosts in the chroot now, which makes sslh build correctly.

The version from 2017-05-04 includes has an /etc/hosts, with ::1 replaced by
127.0.0.1 just as you noticed.  And I see no uploads of debootstrap, sbuild,
schroot or a package that looks related in that time period.

Got an unrelated big build running at the moment, once it's done I'll boot
from a snapshot (got backups from 2017-05-01 (plus earliers) and dailies
since 2017-05-06) to see if it's a matter of an installed package.

But again, this is probably unrelated to Santiago's bug other than for the
results.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.

Bug#862597: clang-3.9-doc: -doc package contains (almost) no documentation

[Ben Harris]

Package: clang-3.9-doc
Version: 1:3.9.1-8
Severity: grave
Justification: renders package unusable

Dear Maintainer,

According to its description, this package should contain documentation 
for Clang.  It is, however, almost empty:


wraith:~$ dpkg -L clang-3.9-doc
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/clang-3.9-doc
/usr/share/doc/clang-3.9-doc/NEWS.Debian.gz
/usr/share/doc/clang-3.9-doc/changelog.Debian.gz
/usr/share/doc/clang-3.9-doc/copyright

Those files are also in clang-3.9, so this package is almost entirely
useless.  The same problem appears to afflict clang-4.0-doc and
clang-5.0-doc, but not clang-3.8-doc.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386
 (i686)

Kernel: Linux 4.9.0-2-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#862497: texlive-lang-portuguese: Extra \endcsname

[Norbert Preining]

tags + 862497 moreinfo
thanks

Dear Osamu,

thanks for your investigation and test case.

> Careful tracing of the bug lead me to the following minimal source case
> and root cause pf the problem seems to be this texlive-lang-portuguese
> package.  I suspect the file:
>   /usr/share/texlive/texmf-dist/tex/generic/babel-portuges/portuges.ldf

Since docbook.sty is hacking around in lots of corners, and hasn't probably
been updated to current babel, please check first whether this is a genuine
babel bug, that is whether it happens with babel-portugues but *not* using
third-party modules like docbook.sty/dblatex.

I tried to dig into the dblatex code, but it is so painfully convoluted
that I don't see the real chance to go to the bottom of it.

If you can reproduce the bug with a plain latex + babel-portugues *only*
setup, I will forward it to the authors/babel team.

Thanks for your understanding

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#862595: FTBFS with python3.6

[James Clarke]

Source: reprozip
Version: 1.0.9-2
Tags: upstream patch

Hi,
Currently reprozip FTBFS in Ubuntu[1], which has switched to python3.6.
The failure is in the test suite:

> ==
> ERROR: test_combine (test_reprozip.TestCombine)
> --
> Traceback (most recent call last):
>   File "/<>/debian/tests/test_reprozip.py", line 403, in 
> test_combine
> traceutils.combine_traces(traces, target)
>   File 
> "/<>/.pybuild/pythonX.Y_3.6/build/reprozip/traceutils.py", line 
> 237, in combine_traces
> ''')
> sqlite3.OperationalError: cannot DETACH database within transaction

Looking at the source, reprozip does a series of inserts and deletes
followed by a detach for a list of databases[2]. However, python3.6's
sqlite3 module no longer implicitly commits an open transaction[3] (and
an implicit transaction has been begun in this case), so the DETACH
fails. I have included a patch which fixes this (tested with an artful +
artful-proposed chroot, as well as unstable to check for regressions). I
see there's another conn.commit right after the final DETACH; maybe that
can go now, though it's probably not doing any harm...

Regards,
James

[1] 
https://launchpadlibrarian.net/319561506/buildlog_ubuntu-artful-amd64.reprozip_1.0.9-2_BUILDING.txt.gz
[2] 
https://sources.debian.net/src/reprozip/1.0.9-2/reprozip/traceutils.py/#L234 
and #L239
[3] https://docs.python.org/3/whatsnew/3.6.html

--- a/reprozip/traceutils.py
+++ b/reprozip/traceutils.py
@@ -230,12 +230,20 @@ def combine_traces(traces, target):
 DELETE FROM maps.map_processes;
 ''')
 
+# An implicit transaction gets created. Python used to implicitly
+# commit it, but no longer does as of 3.6, so we have to explicitly
+# commit before detaching.
+conn.commit()
+
 # Detach
 conn.execute(
 '''
 DETACH DATABASE trace;
 ''')
 
+# See above.
+conn.commit()
+
 conn.execute(
 '''
 DETACH DATABASE maps;

Bug#862596: libasyncns0: Assignment instead of check for equality in assert: asyncns_setuserdata, asyncns_getuserdata

[Myhailo Danylenko]

Package: libasyncns0
Severity: minor
Tags: upstream patch

Hello.

Since I forwarded my bugreport, I'll also forward this one, quite
obvious, and still present one, reported by Olof Sivertsson:
https://bugs.freedesktop.org/show_bug.cgi?id=91859

Bug applies to libasyncns release 0.8 and current git revision 68cd5a.

Both asyncns_setuserdata(...) and asyncns_getuserdata(...) contain the
following line:

  assert(q->asyncns = asyncns);


I believe this should not be assignment, but a check for equality, as is
correctly done already in asyncns_isdone(...):

  assert(q->asyncns == asyncns);

This bug probably does not realistically affect anything right now, but
theoretically it's a bad thing, since in an environment, where there's
several asyncns objects, a programming error instead of triggering
assertion may reassign query object to another asyncns object, that may
lead to various use-after-free issues and mystical bugs/crashes.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- a/libasyncns/asyncns.c  2009-10-15 04:49:09.0 +0300
+++ b/libasyncns/asyncns.c  2017-05-15 01:24:47.573562843 +0300
@@ -1506,7 +1506,7 @@
 void asyncns_setuserdata(asyncns_t *asyncns, asyncns_query_t *q, void 
*userdata) {
 assert(q);
 assert(asyncns);
-assert(q->asyncns = asyncns);
+assert(q->asyncns == asyncns);
 
 q->userdata = userdata;
 }
@@ -1514,7 +1514,7 @@
 void* asyncns_getuserdata(asyncns_t *asyncns, asyncns_query_t *q) {
 assert(q);
 assert(asyncns);
-assert(q->asyncns = asyncns);
+assert(q->asyncns == asyncns);
 
 return q->userdata;
 }

Bug#862594: libasyncns0: libasyncns using pthreads blocks until workers die on free()

[Myhailo Danylenko]

Package: libasyncns0
Severity: normal
Tags: patch upstream

Hello,

Forwarding here this bug, since there's no any action from upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=94849

When using libasyncns with pthreads support, it freezes entire
application, when you try to asyncns_free() instance, that have one of
its workers blocked by getaddrinfo() (worker may be blocked eg. because
of some problem with resolver servers).

An easy way to reproduce this bug is to set your nameserver in
resolv.conf to something non-existent (like 1.2.3.4), then create
asyncns resolver, make a request, and then immediately asyncns_free()
resolver. It will block the application, until worker gets network
timeout.

The problem, as I see it, lies in this code (in asyncns_free()):

/* Now terminate them and wait until they are gone. */
for (p = 0; p < asyncns->valid_workers; p++) {
#ifndef HAVE_PTHREAD
kill(asyncns->workers[p], SIGTERM);
for (;;) {
if (waitpid(asyncns->workers[p], NULL, 0) >= 0 || errno != EINTR)
break;
}
#else
for (;;) {
if (pthread_join(asyncns->workers[p], NULL) != EINTR)
break;
}
#endif
}

So, when pthreads are not in use, it kill()'s worker, then wait()'s for
it. When they are used - it just pthread_join()'s them, which, AFAICS,
is equal to just wait(). I'm no expert on threading, but I've found,
that pthread_cancel() just before waiting cycle solves this problem.
Please, consider including this fix (or any other, that resolves the
problem) into the upstream.

Patch, that fixes the problem for me (not sure, how to attach the file 
in reportbug, thus inserting plaintext):

--- a/libasyncns/asyncns.c  2016-03-19 19:13:00.774406379 +0200
+++ b/libasyncns/asyncns.c  2016-03-19 19:13:02.378415461 +0200
@@ -865,6 +865,7 @@
 break;
 }
 #else
+pthread_cancel(asyncns->workers[p]);
 for (;;) {
 if (pthread_join(asyncns->workers[p], NULL) != EINTR)
 break;

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#844431: policy: packages should be reproducible

[Bill Allombert]

On Sun, May 14, 2017 at 03:20:54PM +, Holger Levsen wrote:
> On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible 
> today.

As I said, I would like to check that my package build is reproducible before
I upload it, not after, so I can be sure that any bug is fixed in the
upload.

Some of my package were listed as reproducible for several months and
then became unreproducible without any new upload. I do not mind that.
However from a policy point of view, reproducible need to be defined
precisely. Generally speaking, reproducible means that the build will
not change if some (but not all) parameters are changed. What parameters
are allowed to change need to be defined.

One way is specify that would be to provide an authoritative tool to
validate packages.

Cheers,
PS: I thanks you for your advices, I will reply to you privately if I
need to.
-- 
Bill. 

Imagine a large red swirl here. 

Bug#862593: xarchiver: Adding files to .tar.xz deletes existing content

[Nikolaus Rath]

Package: xarchiver
Version: 1:0.5.4-1+deb8u1
Severity: critical
Justification: causes serious data loss

As far as I can tell, using xarchiver to add additional files to a
.tar.xz file will destroy the existing data.

Steps to reproduce:

$ echo foo > "Kieran Daycare Contract.pdf"
$ echo bar > "Kieran Daycare 2.pdf"
$ tar cJvf "Kieran Daycare Contract.pdf.tar.xz" "Kieran Daycare Contract.pdf"
Kieran Daycare Contract.pdf

$ xarchiver Kieran\ Daycare\ Contract.pdf.tar.xz 
# Select Action->Add
# Select the "bar.txt" file

Now the existing file is gone, and only the new file is
in the archive.

Please note that the filename seems to matter, I wasn't able
to recreate this when using "foo.txt", "bar.txt" and "test.tar.xz".

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xarchiver depends on:
ii  libc6   2.19-18+deb8u9
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u5
ii  libglib2.0-02.48.0-1~bpo8+1
ii  libgtk2.0-0 2.24.25-3+deb8u1
ii  libpango-1.0-0  1.36.8-3

Versions of packages xarchiver recommends:
ii  bzip2   1.0.6-7+b3
ii  p7zip-full  9.20.1~dfsg.1-4.1+deb8u2
ii  unzip   6.0-16+deb8u3
ii  xdg-utils   1.1.0~rc1+git20111210-7.4
ii  xz-utils5.1.1alpha+20120614-2+b3

Versions of packages xarchiver suggests:
pn  arj
pn  lhasa  
pn  rar
pn  rpm
pn  unar   
ii  zip3.0-8

-- no debconf information

Bug#862422: [pkg-golang-devel] Bug#862422: gccgo-go: wrap gccgo-7 for full Go 1.8 runtime

[Michael Hudson-Doyle]

Makes sense to me, I'd be happy to upload that change to experimental.
What's the timeframe for gccgo-7 getting into unstable? Just waiting for
buster development to open?

On 13 May 2017 at 03:13, Aaron M. Ucko  wrote:

> Package: gccgo-go
> Version: 2:1.8~1
> Severity: important
>
> Could you please switch gccgo-go's 1.8 series to wrap gccgo-7 rather than
> gccgo-6, so code that needs Go 1.8.x user packages but not necessarily
> Google's compiler can simply Build-Depend: gccgo-any (>= 2:1.8~)?
>
> This change will be helpful for packaging newer upstream releases of
> ncbi-entrez-direct, which have started using sort.Slice (and which will
> want to go to experimental for now anyway).
>
> Thanks!
>
> --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/
> finger/?a...@monk.mit.edu
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel
>

Bug#844431: policy: packages should be reproducible

[Holger Levsen]

On Sun, May 14, 2017 at 09:58:12PM +0200, Guillem Jover wrote:
> On Sun, 2017-05-14 at 15:20:54 +, Holger Levsen wrote:
> > Bill, did you do this for your packages?

on re-reading what I wrote here, it occurred to me that this could be
read *hostile* despite me having *zero* intentions to be hostile… I
just wanted to be friendly and give helpful URLs to you, Bill… I'm
sorry if this came across differently!

> b.0.) use debrepro (from devscripts)
 
Thanks for this additional hint, Guillem!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#862592: taskcoach: please make the build reproducible

[Chris Lamb]

Source: taskcoach
Version: 1.4.3-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that taskcoach could not be built reproducibly due to iteration
over the filesystem in a non-determinstic order.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build.diff1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible_build.diff2017-05-14 23:53:15.790046364 
+0200
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-05-14
+
+--- taskcoach-1.4.3.orig/templates.in/make.py
 taskcoach-1.4.3/templates.in/make.py
+@@ -42,7 +42,7 @@ def dumpDirectory(path):
+ fd.write('def getDefaultTemplates():\n')
+ fd.write('templates = []\n')
+ 
+-for name in os.listdir(path):
++for name in sorted(os.listdir(path)):
+ dumpTemplate(os.path.join(path, name), fd)
+ 
+ fd.write('\nreturn templates\n')
--- a/debian/patches/series 2017-05-14 23:50:28.805256147 +0200
--- b/debian/patches/series 2017-05-14 23:53:14.350039551 +0200
@@ -24,3 +24,4 @@
 disable_failing_test.diff
 run_img2py_inside_xvfb.diff
 missing-import-in-openfile.diff
+reproducible_build.diff

Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

[Michael Biebl]

Control: tags -1 moreinfo unreproducible
Control: severity -1 normal

Am 14.05.2017 um 22:57 schrieb Brian Warner:
> Package: libvte-2.91-0
> Version: 0.46.1-1
> Severity: grave
> 
> There seems to be a bug in sid's libvte, such that dumping a large
> amount of text to stdout in a short period of time causes the terminal
> program to crash. "cat" of a file with 1MB of the letter "a" is
> sufficient to reproduce it.

I just created a test file the size of 1GB. gnome-terminal and
xfce4-terminal handled that without a hitch.
So, given that this problem seems to be not generally reproducible, I'm
downgrading the severity accordingly. (up-to-date debian sid, amd64)


If you can reliably reproduce the problem, it would be great if you can
file an upstream bug report at
https://bugzilla.gnome.org/enter_bug.cgi?product=vte

A backtrace would certainly be helpful for upstream to further diagnose
this.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#830844: closed by Damyan Ivanov <d...@debian.org> (Bug#830844: fixed in libauthen-krb5-perl 1.9-5)

[Damyan Ivanov]

-=| Adrian Bunk, 14.05.2017 21:42:59 +0300 |=-
> On Tue, Jul 12, 2016 at 10:00:21AM +, Debian Bug Tracking System wrote:
> >...
> >[ Damyan Ivanov ]
> >* add patch removing references to obsolete krb5_{get,free}_krbhst.
> >  Thanks to Sergio Gelato. Closes: #830844
> >...
> 
> Hi Damyan,
> 
> thanks a lot for fixing this bug for stretch.
> 
> It is still present in jessie, could you also fix it there?
> Alternatively, I can fix it for jessie if you don't object.

You are more than welcome to do so.


Cheers,
dam


signature.asc
Description: PGP signature

Bug#861623: qytile: broken dependencies render it useless in Stretch

[Iain R. Learmonth]

qtile isn't in stretch.

On Sun, May 14, 2017, at 09:07 PM, Andreas Hoenen wrote:
> Same here.
> 
> Doesn't that mean that qtile is just unusable in Stretch?  Which would
> mean a release-critical severity like "grave", wouldn't it?
> 
> And shouldn't #861623 and #861680 get merged?
> 
> Regards, Andreas
> -- 
> Andreas Hoenen 
> GPG: 1024D/B888D2CE
>  A4A6 E8B5 593A E89B 496B
>  82F0 728D 8B7E B888 D2CE
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

Bug#862588: tkhtml1: please make the build reproducible

[Chris Lamb]

user 862588 reproducible-bui...@lists.alioth.debian.org
usertag 862588 = buildpath
thanks

Hi,

> tkhtml1: please make the build reproducible

This is due to shipping a `tkhtml1Config.sh` config file containing
build paths (hat won't work on end-user systems anyway as they will
never match. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

[Brian Warner]

Package: libvte-2.91-0
Version: 0.46.1-1
Severity: grave

There seems to be a bug in sid's libvte, such that dumping a large
amount of text to stdout in a short period of time causes the terminal
program to crash. "cat" of a file with 1MB of the letter "a" is
sufficient to reproduce it.

I'm assigning this to libvte because I was able to crash xfce4-terminal,
lilyterm, and termit this way, so it's clearly not specific to any one
terminal program. I'm marking it "grave" because losing a terminal is
pretty harsh.. any programs you've spawned from there (emacs, web
browsers) abruptly exit too.

I'm running this on an ARM64 chromebook (an Acer R13), which might be an
unusual platform, just in case that makes a difference.

I was able to get a stack trace by building vte2.91-0.46.1 and
xfce4-terminal-0.8.4 locally with debug symbols turned on. It looks like
this:

Thread 1 "xfce4-terminal" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  0x007cb52229fc in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x007cb5223df4 in __GI_abort () at abort.c:89
#2  0x007cb53dc59c in g_assertion_message
(domain=domain@entry=0x7cb5fa3bb8 "Vte", file=file@entry=0x7cb5fac250
"/home/warner/stuff/debian/vte2.91-0.46.1/./src/vtestream-file.h",
line=line@entry=790, func=func@entry=0x7cb5fac098
<_vte_boa_uncompress::__PRETTY_FUNCTION__> "unsigned int
_vte_boa_uncompress(char*, unsigned int, const char*, unsigned int)",
message=message@entry=0x5ccf97f720 "assertion failed (z_ret == Z_OK):
(4294967293 == 0)") at ././glib/gtestutils.c:2432
#3  0x007cb53dc96c in g_assertion_message_cmpnum
(domain=domain@entry=0x7cb5fa3bb8 "Vte", file=file@entry=0x7cb5fac250
"/home/warner/stuff/debian/vte2.91-0.46.1/./src/vtestream-file.h",
line=line@entry=790, func=func@entry=0x7cb5fac098
<_vte_boa_uncompress::__PRETTY_FUNCTION__> "unsigned int
_vte_boa_uncompress(char*, unsigned int, const char*, unsigned int)",
expr=expr@entry=0x7cb5fac3f8 "z_ret == Z_OK", arg1=,
cmp=cmp@entry=0x7cb5fa7420 "==", arg2=arg2@entry=0,
numtype=numtype@entry=105 'i')
at ././glib/gtestutils.c:2488
#4  0x007cb5fa0a94 in _vte_boa_uncompress (dstlen=65512,
srclen=6140, src=0x7fc82a4618 "", dst=) at
././src/vtestream-file.h:790
#5  0x007cb5fa0a94 in _vte_boa_read_with_overwrite_counter(VteBoa*,
gsize, char*, _vte_overwrite_counter_t*) (boa=0x5ccf75e420 [VteBoa],
offset=offset@entry=0, data=,
overwrite_counter=overwrite_counter@entry=0x7fc82b4714) at
././src/vtestream-file.h:911
#6  0x007cb5fa0e54 in _vte_boa_read (data=, offset=0,
boa=) at ././src/vtestream-file.h:922
#7  0x007cb5fa0e54 in _vte_file_stream_read(VteStream*, gsize,
char*, gsize) (astream=0x5ccf76dc50 [VteFileStream], offset=42288,
data=0x7fc82b4750 "", len=24)
at ././src/vtestream-file.h:1137
#8  0x007cb5f79dac in _vte_ring_read_row_record (ring=0x5ccf76e568,
position=, record=0x7fc82b4770) at ././src/ring.cc:124
#9  0x007cb5f79dac in _vte_ring_discard_one_row (ring=0x5ccf76e568)
at ././src/ring.cc:417
#10 0x007cb5f79dac in _vte_ring_maybe_discard_one_row
(ring=0x5ccf76e568) at ././src/ring.cc:439
#11 0x007cb5f79dac in _vte_ring_insert(VteRing*, gulong)
(ring=ring@entry=0x5ccf76e568, position=position@entry=2761) at
././src/ring.cc:551
#12 0x007cb5f7c604 in VteTerminalPrivate::ring_insert(long, bool)
(this=this@entry=0x5ccf76e490, position=2761, fill=fill@entry=false) at
././src/vte.cc:247
#13 0x007cb5f7e694 in VteTerminalPrivate::ring_append(bool)
(fill=false, this=0x5ccf76e490) at ././src/vte.cc:257
#14 0x007cb5f7e694 in VteTerminalPrivate::insert_rows(unsigned int)
(cnt=1, this=) at ././src/vte.cc:2188
#15 0x007cb5f7e694 in VteTerminalPrivate::update_insert_delta()
(this=0x5ccf76e490) at ././src/vte.cc:2234
#16 0x007cb5f7f9e0 in VteTerminalPrivate::insert_char(unsigned int,
bool, bool) (this=this@entry=0x5ccf76e490, c=97,
insert=insert@entry=false, invalidate_now=invalidate_now@entry=false) at
././src/vte.cc:2964
#17 0x007cb5f8b248 in VteTerminalPrivate::process_incoming()
(this=this@entry=0x5ccf76e490) at ././src/vte.cc:3686
#18 0x007cb5f8bf08 in VteTerminalPrivate::time_process_incoming()
(this=this@entry=0x5ccf76e490) at ././src/vte.cc:10428
#19 0x007cb5f8bfe8 in VteTerminalPrivate::process(bool)
(this=this@entry=0x5ccf76e490,
emit_adj_changed=emit_adj_changed@entry=true) at ././src/vte.cc:10452
#20 0x007cb5f8c244 in update_timeout(gpointer) (data=) at ././src/vte.cc:10679
#21 0x007cb53b5484 in g_timeout_dispatch (source=0x5ccf575f80,
callback=, user_data=) at
././glib/gmain.c:4674
#22 0x007cb53b4898 in g_main_dispatch (context=0x5ccf446770) at
././glib/gmain.c:3203
#23 0x007cb53b4898 in g_main_context_dispatch
(context=context@entry=0x5ccf446770) at ././glib/gmain.c:3856
#24 0x007cb53b4c40 in g_main_context_iterate (context=0x5ccf446770,

Bug#761627: libtomcrypt-dev: arch-dependent file in "Multi-Arch: same" package

[Michael Stapelberg]

Thanks for investigating this issue and providing the updated patch. As
Debian is currently in a freeze, I can’t upload the patch right now. Could
you ping this email thread/bug report once Debian left the freeze please?
Thank you.

On Sun, May 14, 2017 at 5:49 PM, François Poirotte 
wrote:

> Hi,
>
> It seems the patch "deterministic-latex.patch" is not working as it should.
> I guess it may have to do with the way it uses escape sequences (in my
> case, "\\fixedpdfdate" is actually replaced by a form feed character
> followed by "ixedpdfdate" in the final .tex file).
>
> Attached is an updated version of the patch that fixes the issue for me.
> It uses "printf" instead of "echo" to avoid possible issues with the
> interpretation of escape sequences.
> It blanks the "ModDate" & "CreationDate" fields instead of trying to be
> smart about them.
> It also removes pdfLaTeX's banner & trailer ID from the final output
> (which may also fix the issue you reported about different versions of the
> build-dependencies resulting in different output files).
>
> Best regards,
> François
>



-- 
Best regards,
Michael

Bug#862590: CVE-2017-8352

[Bastien ROUCARIES]

package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/452

  ReadXWDImage function in xwd.c allows attackers to cause a denial of
service (memory leak) via a crafted file.

Bug#861581: ITP: rainloop -- Simple, modern & fast web-based email client

[Gunnar Wolf]

Hi Daniel,

Daniel Ring dijo [Sun, May 07, 2017 at 11:01:33AM +]:
> Hi Gunnar,
> 
> I've finished putting together a preliminary version of the package, but I
> have a few concerns about it.
> 
> The largest one is that the build system is NodeJS-based, and requires a
> version of npm newer than the one currently in Debian. Bugs #857986 and 
> #794890
> have some details about npm's issues. Installing nodejs from its official
> repository works, as does building on Ubuntu.

Ugh. The whole NodeJS ecosystem makes me shiver :-(

Anyway, installing a newer version than what's available in Debian is
*not* acceptable for a package to go in Debian. Either it has to be
patched to build with older versions, or you have to wait to the newer
version to arrive to Debian.

> Secondly, the build system has the usual issue with NodeJS packaging; it
> downloads dependencies at runtime. Most of the packages don't exist in Debian
> or are out of date, and I found several existing packages doing this while
> looking for a better solution, so I'm not sure how much of an issue this is.
> This only occurs at build-time, and nodejs isn't required to use the software.

That is also something that cannot be done; packaging software cannot
depend on network connectivity (not even initiate network
connections). The dependencies must be somehow build-depended upon; in
the (ugliest, worst) case you could patch your sources to include the
packages to fulfill this... But I doubt the ftp-masters will approve
of it.

> Finally, the upstream source contains several embedded libraries. I was able 
> to
> swap a few of them for existing packages in Debian, but there are a few PHP
> libraries that don't have existing packages.

It is frowned upon, but tolerated; you have to just make sure to keep
track of them and properly attribute all of the copyrights in
debian/copyright. 

> The JavaScript libraries are amalgamated into a single file at
> build-time, and separating them out would be a non-trivial amount of
> work for decreased performance.

We have to ship sources for every piece of software. You don't need to
separate them as long as you provide all the sources and can *prove*
they can be amalgamated to the identical "binary" you are
shipping. That's not a trivial thing, sadly :(

> Again, I found several existing packages doing this, so I'm not sure
> how much of a problem it is.  Upstream provided sources for most, I
> added the few missing to satisfy lintian.
> 
> I've uploaded the package to mentors: 
> https://mentors.debian.net/package/rainloop
> Please review it when you have a chance, and let me know if there's anything I
> need to fix!

I'm just talking WRT your text, and have not looked at the packaging
itself; I think I can do it on ~thursday... If you find some other
sponsor, of course, feel free to follow up with them. I want to at
least try and get the work done with you.

If you find examples in Debian that have been accpeted in opposition
to what I have pointed out here, point me to them.

Bug#862588: tkhtml1: please make the build reproducible

[Chris Lamb]

Source: tkhtml1
Version: 1.04-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that tkhtml1 could not be built reproducibly.


Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2017-05-14 22:41:44.057736691 +0200
--- b/debian/rules  2017-05-14 22:54:42.449420258 +0200
@@ -10,6 +10,12 @@
 override_dh_auto_configure:
dh_auto_configure -- --libdir=/usr/lib/tcltk/$(DEB_HOST_MULTIARCH)
 
+override_dh_auto_install:
+   dh_auto_install
+   # Don't install tkhtml1Config.sh as it contains build paths that won't
+   # work on end-user systems anyway.
+   rm -f 
$(CURDIR)/debian/tk-html1/usr/lib/tcltk/$(DEB_HOST_MULTIARCH)/tkhtml1Config.sh
+
 override_dh_auto_test:
# ignore builtin tests
 

Bug#862589: CVE-2017-8351

[Bastien ROUCARIES]

package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/448

 he ReadPCDImage function in pcd.c allows attackers to cause a denial
of service (memory leak) via a crafted file.

Bug#862587: CVE-2017-8350

[Bastien ROUCARIES]

package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/447

 the ReadJNGImage function in png.c allows attackers to cause a denial
of service (memory leak) via a crafted file.

Bug#862485: fwsnort mustn't set iptables rules when purged

[Axel Beckert]

Axel Beckert wrote:
> Point taken. Will move that line (or an "fwsnort --ipt-flush") into a
> (to be created) prerm and do another QA upload. (Unless you're already
> onto it. Feel free to do that.)

Unfortunately "fwsnort --ipt-flush" only flushes the chains but does
not remove the chains:

  # iptables -L -v -n
  Chain INPUT (policy ACCEPT 34 packets, 6672 bytes)
   pkts bytes target prot opt in out source   
destination
  22598   17M FWSNORT_INPUT  all  --  !lo*   0.0.0.0/0
0.0.0.0/0
  
  Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
   pkts bytes target prot opt in out source   
destination
  0 0 FWSNORT_FORWARD  all  --  !lo*   0.0.0.0/0
0.0.0.0/0
  
  Chain OUTPUT (policy ACCEPT 34 packets, 2568 bytes)
   pkts bytes target prot opt in out source   
destination
  22777 1488K FWSNORT_OUTPUT  all  --  *  !lo 0.0.0.0/0
0.0.0.0/0
  
  Chain FWSNORT_FORWARD (1 references)
   pkts bytes target prot opt in out source   
destination
  
  Chain FWSNORT_FORWARD_ESTAB (0 references)
   pkts bytes target prot opt in out source   
destination
  
  Chain FWSNORT_INPUT (1 references)
   pkts bytes target prot opt in out source   
destination
  
  Chain FWSNORT_INPUT_ESTAB (0 references)
   pkts bytes target prot opt in out source   
destination
  
  Chain FWSNORT_OUTPUT (1 references)
   pkts bytes target prot opt in out source   
destination
  
  Chain FWSNORT_OUTPUT_ESTAB (0 references)
   pkts bytes target prot opt in out source   
destination

So a little bit more is needed in prerm to properly clean up: First
remove the remaining references to FWSNORT_* chains, then delete all
FWSNORT_* chains.

Regards, Axel
--
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#862585: Please re-enable build on x32

[James Clarke]

Source: reprozip
Version: 1.0.9-2
Severity: wishlist

Hi,
You disabled every architecture except amd64 and i386 as a result of
#862351, but upstream actually supports x32 too (I just successfully
built it in an x32 chroot). Please could you add x32 back to the list of
architectures?

Regards,
James

Bug#862586: devscripts: debrepro should first check that faketime is present

[Alexandre Detiste]

Package: devscripts
Version: 2.17.5
Severity: normal

I, if faketime is not installed,
debrepro will fail on the second run.

I realize it is already Suggested,
be can you please make debrepro fail sooner
to avoid wasting CPU/time ?

Cheers,


-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (501, 'testing')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.23
ii  libc62.24-10
ii  perl 5.24.1-2
pn  python3:any  

Versions of packages devscripts recommends:
ii  apt 1.4.1
pn  at  
ii  curl7.52.1-5
ii  dctrl-tools 2.24-2+b1
pn  debian-keyring  
ii  dput0.12.0
ii  equivs  2.0.9+nmu1
ii  fakeroot1.21-3.1
ii  file1:5.30-1
ii  gnupg   2.1.18-6
ii  gnupg2  2.1.18-6
pn  libdistro-info-perl 
ii  libdpkg-perl1.18.23
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.06-2
pn  libsoap-lite-perl   
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
pn  licensecheck
ii  lintian 2.5.50.3
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-debian  0.1.30
pn  python3-magic   
ii  sensible-utils  0.0.9
ii  strace  4.15-2
ii  unzip   6.0-21
pn  wdiff   
ii  wget1.18-5
ii  xz-utils5.2.2-1.2+b1

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.3
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
ii  faketime 0.9.6-7+b1
pn  gnuplot  
ii  gpgv 2.1.18-6
pn  how-can-i-help   
pn  libauthen-sasl-perl  
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:7.4p1-10
pn  piuparts 
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

Bug#842634: Bug#851877: fails every time

[Michael Stapelberg]

On Sun, May 14, 2017 at 7:59 AM, Adam Borowski  wrote:

> On Sat, May 13, 2017 at 08:44:15PM +0200, Michael Stapelberg wrote:
> > Sorry for the late reply.
> >
> > Adam, could you run the attached example program (derived from the
> > getaddrinfo and getnameinfo manpages) please? The output should help us
> > narrow down whether the problem is with the application code of sslh or
> > something in the environment.
> >
> > Use: gcc -Wall -o gai gai.c && ./gai localhost 9002
>
> On all three machines, it looks fine:
> .
> printing getaddrinfo(localhost, 9002) results:
>
>   ai_family = 10
>   ai_socktype = 2
>   ai_protocol = 17
>   rp->ai_addrlen = 28
> host=::1, serv=9002
>
>   ai_family = 2
>   ai_socktype = 2
>   ai_protocol = 17
>   rp->ai_addrlen = 16
> host=127.0.0.1, serv=9002
>
> done
> `
>

This seems correct.


>
> Inside the chroot:
> .
> [/srv/sbuild/stretch-armhf/tmp]# cp -p /tmp/gai .
> [/srv/sbuild/stretch-armhf/tmp]# chroot ..
> (stretch-armhf-sbuild)root@kholdan:/# tmp/gai localhost 9002
> printing getaddrinfo(localhost, 9002) results:
>
>   ai_family = 2
>   ai_socktype = 2
>   ai_protocol = 17
>   rp->ai_addrlen = 16
> host=127.0.0.1, serv=9002
>
>   ai_family = 2
>   ai_socktype = 2
>   ai_protocol = 17
>   rp->ai_addrlen = 16
> host=127.0.0.1, serv=9002
>
> done
> `
>

This seems incorrect: the results are two IPv4 addresses (127.0.0.1:9002)
as opposed to one IPv6 and one IPv4 address (or just one IPv4 address).

I can actually reproduce this issue on abel.debian.org (armhf porterbox):

On abel, my gai test program returns ::1, 127.0.0.1.
On abel within an schroot, my gai test program returns 127.0.0.1, 127.0.0.1.

Looking at /etc/hosts within the schroot, I see:
127.0.0.1   localhost
127.0.0.1   localhost ip6-localhost ip6-loopback
172.28.17.11abel.debian.org abel

Modifying /etc/hosts by replacing ::1 with 127.0.0.1 results in being able
to reproduce the issue on other machines as well.

This has already caused issues in other packages (e.g. rustc), and is
tracked as Debian bug #842634.

Now, the next question is: where does this /etc/hosts come from? The file
is present in the above form directly after unpacking the schroot tarball,
before even entering the schroot:

abel% sessionid=$(schroot -b -c sid)
abel% cat /srv/chroot/schroot-unpack/$sessionid/etc/hosts
127.0.0.1   localhost
127.0.0.1   localhost ip6-localhost ip6-loopback
172.28.17.11abel.debian.org abel

Running debootstrap does not produce an /etc/hosts in --variant=minbase and
--variant=buildd. When run without --variant, it does produce an
/etc/hosts, but that looks correct:

midna% sudo debootstrap --variant=minbase stretch /tmp/bootstrap
http://deb.debian.org/debian
midna% cat /tmp/bootstrap/etc/hosts
cat: /tmp/bootstrap/etc/hosts: No such file or directory
midna% sudo rm -rf /tmp/bootstrap
midna% sudo debootstrap stretch /tmp/bootstrap http://deb.debian.org/debian
midna% cat /tmp/bootstrap/etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

So, where does the file get mangled? I can’t find any traces in the schroot
and sbuild sources. Does anyone know by chance?



>
>
> Meow!
> --
> Don't be racist.  White, amber or black, all beers should be judged based
> solely on their merits.  Heck, even if occasionally a cider applies for a
> beer's job, why not?
> On the other hand, corpo lager is not a race.
>



-- 
Best regards,
Michael

Bug#862584: thunderbird: Thunderbird hang on some usenet articles with attachements

[kjonca]

Package: thunderbird
Version: 1:45.8.0-3
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

   I have subscribed to nntp group, where is a lot of articles with 
attachments. This group was a mirror of an email list. 
   So I have comparision to open imap folders with the same messages in imap 
folder and usenet newsgorup. (In IMAP folder these messages were showed fast 
and correctly)



   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   
   I tried to  view some messages in usenet newsgroup. 

   * What was the outcome of this action?

   thunderbird hangs on third/fourth message with image in it.


   * What outcome did you expect instead?

Show image.




-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunderbird depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-10
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.18-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.1
ii  libgcc1   1:6.3.0-17
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-2
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.4-0 1.4.1-2+b2
ii  libicu57  57.1-6
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  libpixman-1-0 0.34.0-1
ii  libsqlite3-0  3.16.2-3
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-17
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b2
ii  x11-utils 7.7+3+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-7
ii  lightning 1:45.8.0-3

Versions of packages thunderbird suggests:
pn  apparmor  
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.15-1

-- no debconf information

Bug#862583: RFS: reprozip/1.0.9-3 [RC]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: reprozip
  Version : 1.0.9
  Upstream Author : Remi Rampin
* URL : https://www.reprozip.org/
* License : BSD
  Section : science

One can check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/reprozip.git

Changes since the last upload:

  * Fix file conflict issue.
Thanks to Axel Beckert for reporting (Closes: #862542)

Best regards,
Ghis

Bug#862582: ITP: libtgvoip - VoIP library for Telegram clients

[Коля Гурьев]

Package: wnpp
Severity: wishlist

Hello everybody!

I intend to make a package for this VoIP library that is used by the
new version of Telegram Desktop.

The source is available on GitHub: https://github.com/grishka/libtgvoip
This library is software in public domain, and it's distributed under
the Unlicense conditions: https://unlicense.org

Bug#862581: mirror listing update for debian.redlibre.cl

[Pablo Umanzor]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: debian.redlibre.cl
Type: leaf
Archive-architecture: amd64 armhf i386 mips mipsel powerpc s390x
Archive-http: /debian/
Archive-upstream: mirrors.kernel.org
Updates: four
Maintainer: Pablo Umanzor 
Country: CL Chile
Location: Santiago , Las Condes
Comment: Hello, we've added 5 new architectures!
 
 Arch. Supported: amd64, i386 , armhf , mipsel , m68k , s390x , mips , powerpc 
and source
 
 best regards
 pablo umanzor



Trace Url: http://debian.redlibre.cl/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.redlibre.cl/debian/project/trace/debian.redlibre.cl

Bug#861623: qytile: broken dependencies render it useless in Stretch

[Andreas Hoenen]

Same here.

Doesn't that mean that qtile is just unusable in Stretch?  Which would
mean a release-critical severity like "grave", wouldn't it?

And shouldn't #861623 and #861680 get merged?

Regards, Andreas
-- 
Andreas Hoenen 
GPG: 1024D/B888D2CE
 A4A6 E8B5 593A E89B 496B
 82F0 728D 8B7E B888 D2CE


signature.asc
Description: PGP signature

Bug#862580: pam: PAM 'user unknown' prevents domain login but allows local logins

[Christian Meyer]

Package: libpam0g
Version: 1.1.8-3.5
Severity: important
File: pam

Dear Maintainer,

I'm trying to login via ssh as a Windows AD user and auth fails.
When doing a ssh-login as a local user it works fine.
After login out the local user and trying as domain user again, it works fine, 
like expected.
The bug mostly (only?) occurs after being idle (with no users logged in) for 
'some time', e.g. every mornig (24/7 machine) or after being shut down for the 
weekend.
I think this is a regression from jessie that should not go in final stretch.

When I compare a successfull run with a failed attempt I find the output of 
'service sshd status':

Mai 14 17:04:27 fail-host pam-script[2375]: can not stat 
/usr/share/libpam-script/pam_script_auth
Mai 14 17:04:27 fail-host sshd[2375]: pam_unix(sshd:auth): check pass; user 
unknown
Mai 14 17:04:27 fail-host sshd[2375]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.0.1
Mai 14 17:04:27 fail-host sshd[2375]: pam_winbind(sshd:auth): getting password 
(0x0388)
Mai 14 17:04:27 fail-host sshd[2375]: pam_winbind(sshd:auth): pam_get_item 
returned a password
Mai 14 17:04:29 fail-host sshd[2375]: Failed password for invalid user 
domainuser from 172.16.0.1 port 41037 ssh2
Mai 14 17:04:46 fail-host sshd[2375]: Connection closed by 172.16.0.1 port 
41037 [preauth]

Mai 14 17:05:14 success-host pam-script[30067]: can not stat 
/usr/share/libpam-script/pam_script_auth
Mai 14 17:05:14 success-host sshd[30067]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.0.1  user=domainuser
Mai 14 17:05:14 success-host sshd[30067]: pam_winbind(sshd:auth): getting 
password (0x0388)
Mai 14 17:05:14 success-host sshd[30067]: pam_winbind(sshd:auth): pam_get_item 
returned a password
Mai 14 17:05:15 success-host sshd[30067]: pam_winbind(sshd:auth): user 
'domainuser' granted access

Of course pam_unix fails for domain users, but I see it complains about 'user 
unknown':
When ever there is no parameter 'user=XYZ' on the pam_unix line then auth fails 
for domain users (with pam_winbind), too.
What causes that 'user=' mostly appears and works but sometimes is missing?
Local users do not fail.

I've seen a similar bug with missing 'user=...' using gdm3 on jessie, too, but 
that happened on about 1-2 of 40 computers a day
and vanished after some time with cron driven winbind restarts.
The actual problem is reproducible on a machine without GUI every day.

I know winbind crashes often (and that for it sucks heavily), so I first 
thought this could be a winbind issue.
But when pam_winbind does not know the 'user=' parameter its clear it can not 
succeed (Of course it really must not crash (as it does) in this case)

Since I'm not very good with PAM usage/debugging, please let me know what 
information I can provide to solve this bug.

Thanks for your attention,
Christian Meyer


# cat /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
authsufficient  pam_script.so 
auth[success=2 default=ignore]  pam_unix.so nullok_secure try_first_pass
auth[success=1 default=ignore]  pam_winbind.so krb5_auth 
krb5_ccache_type=FILE cached_login try_first_pass
# here's the fallback if no module succeeds
authrequisite   pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
authrequiredpam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam0g:amd64 depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  libaudit1  1:2.6.7-2
ii  libc6  2.24-10

libpam0g:amd64 recommends no packages.

Versions of packages 

Bug#862578: CVE-2017-8348

[Bastien ROUCARIES]

package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/445


ImageMagick 7.0.5-5, the ReadMATImage function in mat.c allows
attackers to cause a denial of service (memory leak) via a crafted
file.

Bug#862461: tiptop: requires root to run

[Ben Hutchings]

On Sun, 2017-05-14 at 10:43 +0200, Tomasz Buchert wrote:
> On 12/05/17 18:54, Nathaniel Beaver wrote:
> > [...]
> 
> Thank you, Nathaniel.
> 
> I confirm the problem. A safe bet is that
> https://lkml.org/lkml/2016/1/11/587 is the cause.  You can verify that
> /proc/sys/kernel/perf_event_paranoid contains "3". By running
> 
> echo 2 | sudo tee /proc/sys/kernel/perf_event_paranoid
> 
> you should be able to use tiptop as a normal user again.
> 
> I doubt that we can switch the default value in Debian kernels to "2",
> so I have to say that simply the tiptop website is not up-to-date, at
> least with respect to the Debian kernels (but also likely to other
> distributions as well). I'm CCing Ben to let him comment on this.

The Debian kernel default is not going to be changed in the short term.
 In the long term it's conceivable that performance events will
eventually become sufficiently robust that it would be reasonable to
change the default.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams

signature.asc
Description: This is a digitally signed message part

Bug#844431: policy: packages should be reproducible

[Guillem Jover]

On Sun, 2017-05-14 at 15:20:54 +, Holger Levsen wrote:
> On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> > OK, but how can I check that my package build is reproducible before 
> > uploading
> > it ?
> 
> in general you cannot find out with 100% certainity whether a given source 
> package
> will be reproducible. You can only find out with certainity if a package is 
> *not*
> reproducible…
> 
> that said
> 
> a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible 
> today.
> 
>   Bill, did you do this for your packages?
>   And then there is also 
> https://tests.reproducible-builds.org/debian/unstable/index_dd-list.html#ballo...@debian.org
>   which shows that half of your 26 packages in sid (main) are 
> unreproducible
>   with build path variation, though most of those unreproducible 
> ones
>   are reproducible without build path variation…
>   -> 
> https://tests.reproducible-builds.org/debian/testing/index_dd-list.html#ballo...@debian.org
>   only shows 4 unreproducible packages…

b.0.) use debrepro (from devscripts)

> b.) build it twice and compare using diffoscope
> c.) use reprotest

Thanks,
Guillem

Bug#862579: CVE-2017-8349

[Bastien ROUCARIES]

package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/443

The ReadSFWImage function in sfw.c allows attackers to cause a denial
of service (memory leak) via a crafted file.

Bug#862577: CVE-2017-8347

[Bastien ROUCARIES]

package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/441


In ImageMagick 7.0.5-5, the ReadEXRImage function in exr.c allows
attackers to cause a denial of service (memory leak) via a crafted
file.

Bug#797722: spamassassin cron.daily fails with permission denied for tmp file

[Simon Walter]

On 12.05.2017 00:52, Noah Meyerhans wrote:
> On Tue, Sep 01, 2015 at 10:57:57PM +, Simon Walter wrote:
>> Package: spamassassin
>> Version: 3.4.0-6
>>
>> cron.daily spamassassin fails because the tmp file can't be created. script 
>> seems to be executed in /root/
> This bug has been open for ages. I'd like to either figure out what went
> wrong, or close it. Has this issue recurred? Have you managed to work
> around it locally? I haven't heard any similar reports, so it seems like
> it's dependent on something specific to your environment.
>
> Have you tried the 3.4.1 packages from stretch of jessie-backports?
>
I'm not sure how it was resolve and don't remember how to reproduce it.
Sorry for this bugreport. You can close it.

--
Regards
Simon



signature.asc
Description: OpenPGP digital signature

Bug#862576: etoys: Doesn't get beyond Squeak security key generation

[Víctor Bettachini]

Package: etoys
Version: 5.0.2408-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Just running etoys&. 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Run etoys&
   * What was the outcome of this action?
It gets stuck at 99% of the Squeak security key generation procedure. 
   * What outcome did you expect instead?
The same procedure in a Jessie installation in the same system just 
took a few seconds and led to eToys main screen.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.utf8, LC_CTYPE=es_AR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages etoys depends on:
ii  squeak-vm  1:4.10.2.2614-4+b1

Versions of packages etoys recommends:
ii  etoys-doc  5.0.2408-1

etoys suggests no packages.

-- no debconf information

Bug#862575: CVE-2017-8346

[Bastien ROUCARIES]

package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/440


In ImageMagick 7.0.5-5, the ReadDCMImage function in dcm.c allows
attackers to cause a denial of service (memory leak) via a crafted
file.

Bug#862572: CVE-2017-8343: he ReadAAIImage function in aai.c allows attackers to cause a denial of service (memory leak) via a crafted file.

[Bastien ROUCARIES]

Package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/444


Fixed upstream

Bug#862574: CVE-2017-8344

[Bastien ROUCARIES]

package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/446


In ImageMagick 7.0.5-5, the ReadPCXImage function in pcx.c allows
attackers to cause a denial of service (memory leak) via a crafted
file.

Bug#862573: CVE-2017-8345

[Bastien ROUCARIES]

package: src:imagemagick
Version: 8:6.9.7.4+dfsg-6
Severity: important
Tags: security
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.7.7.10-5+deb7u13
control: found -1 8:6.7.7.10-5+deb7u4
forwarded: https://github.com/ImageMagick/ImageMagick/issues/442

In ImageMagick 7.0.5-5, the ReadMNGImage function in png.c allows
attackers to cause a denial of service (memory leak) via a crafted
file.


Fixed upstream

Bug#862571: pcmanfm: single instance socket may be blocked by another user.

[Andriy Grytsenko]

Package: pcmanfm
Version: 1.2.5-2
Version: 1.2.3-1.1
Severity: serious
Tags: upstream security

The socket placed in /tmp is predictable and public-writable. Therefore
if one user placed a symlink to another socket instead of socket for
another user then said another user will either be unable to use pcmanfm,
or may send requests to the first user's pcmanfm. Upstream released a fix
for this issue:

https://git.lxde.org/gitweb/?p=lxde/pcmanfm.git;a=commitdiff;h=bc8c3d871e9ecc67c47ff002b68cf049793faf08

Bug#684499: Streaming MOVE commands

[Emilio Jesús Gallego Arias]

Hi Adrian,

Adrian Bunk  writes:

> What was the result?
> Any chance of getting this one-line change into jessie?

So far the current Jessie packages don't include the fix, which forces
me to use my own custom packages, so indeed, this is not optimal.

jessie-backports seem to include the fix thou.

Best,
E.

Bug#862570: libmenu-cache: menu-cached socket may be blocked by another user.

[Andriy Grytsenko]

Package: libmenu-cache3
Version: 1.0.2-2
Severity: serious
Tags: upstream security

The socket placed in /tmp is predictable and public-writable. Therefore
if one user placed a symlink to another socket instead of socket for
another use then said another user will either be unable to get menu, or
will receive menu of some other user. Upstream released a fix for this
issue:

https://git.lxde.org/gitweb/?p=lxde/menu-cache.git;a=commitdiff;h=56f66684592abf257c4004e6e1fff041c64a12ce

Bug#830844: closed by Damyan Ivanov <d...@debian.org> (Bug#830844: fixed in libauthen-krb5-perl 1.9-5)

[Adrian Bunk]

On Tue, Jul 12, 2016 at 10:00:21AM +, Debian Bug Tracking System wrote:
>...
>[ Damyan Ivanov ]
>* add patch removing references to obsolete krb5_{get,free}_krbhst.
>  Thanks to Sergio Gelato. Closes: #830844
>...

Hi Damyan,

thanks a lot for fixing this bug for stretch.

It is still present in jessie, could you also fix it there?
Alternatively, I can fix it for jessie if you don't object.

Thanks
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#834213: perlcritic: some code causes a perltidy.ERR file to be created or overwritten

[Jakub Wilk]

Control: tags -1 + security

* Paul Wise , 2016-08-13, 15:09:
There is some code which causes perlcritic to create or overwrite a 
perltidy.ERR file in the current directory.


Perl::Tidy tries to delete existing perltidy.ERR; but if deleting fails, it 
proceeds as if nothing happened. This can be abused to overwrite arbitrary 
files via symlink attack:


   $ tar -xvvf 834213.tar.gz
   dr-xr-xr-x root/root 0 2017-05-14 16:33 834213/
   -r--r--r-- root/root 2 2017-05-14 16:30 834213/badsyntax.pm
   lr-xr-xr-x root/root 0 2017-05-14 16:30 834213/perltidy.ERR -> 
/tmp/moo

   $ cd 834213

   $ head -n1 /tmp/moo
   head: cannot open '/tmp/moo' for reading: No such file or directory

   $ perlcritic --noprofile -1 badsyntax.pm
   perltidy had errors!! at line 1, column 1.  See page 33 of PBP.  (Severity: 
1)
   Module does not end with "1;" at line 1, column 1.  Must end with a 
recognizable true value.  (Severity: 4)
   Code not contained in explicit package at line 1, column 1.  Violates 
encapsulation.  (Severity: 4)
   No package-scoped "$VERSION" variable found at line 1, column 1.  See page 
404 of PBP.  (Severity: 2)
   Code before strictures are enabled at line 1, column 1.  See page 429 of 
PBP.  (Severity: 5)
   Code before warnings are enabled at line 1, column 1.  See page 431 of PBP.  
(Severity: 4)

   $ head -n1 /tmp/moo
   1:   final indentation level: 1

--
Jakub Wilk


834213.tar.gz
Description: application/gzip

Bug#817837: closed by Jonathan McDowell <nood...@earth.li> (Bug#817837: fixed in l2tpns 2.2.1-2)

[Adrian Bunk]

On Tue, Jul 05, 2016 at 10:09:57AM +, Debian Bug Tracking System wrote:
>...
>  l2tpns (2.2.1-2) unstable; urgency=low
>  .
>* Fix log buffer overrun, thanks to Dave Reeve (closes: #817837)
>...

Hi Jonathan,

thanks a lot for fixing this bug for stretch.

It is still present in jessie, could you also fix it there?
Alternatively, I can fix it for jessie if you don't object.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#862569: unblock: bind9/1:9.10.3.dfsg.P4-12.3

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi

Please unblock package bind9

The upload fixes three issues:

+bind9 (1:9.10.3.dfsg.P4-12.3) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Dns64 with "break-dnssec yes;" can result in a assertion failure
+(CVE-2017-3136) (Closes: #860224)
+  * Some chaining (CNAME or DNAME) responses to upstream queries could trigger
+assertion failures (CVE-2017-3137) (Closes: #860225)
+  * 'rndc ""' could trigger a assertion failure in named (CVE-2017-3138)
+(Closes: #860226)
+
+ -- Salvatore Bonaccorso   Sun, 07 May 2017 15:22:46 +0200

of which CVE-2017-3137 should be considered RC (and filled as such),
the other two are minor, but were included as well in the stable
update released as DSA-3854-1.

unblock bind9/1:9.10.3.dfsg.P4-12.3

Attached is the full debdiff agains the current version in testing.

Regards,
Salvatore
diff -Nru bind9-9.10.3.dfsg.P4/debian/changelog 
bind9-9.10.3.dfsg.P4/debian/changelog
--- bind9-9.10.3.dfsg.P4/debian/changelog   2017-04-18 17:42:50.0 
+0200
+++ bind9-9.10.3.dfsg.P4/debian/changelog   2017-05-07 15:22:46.0 
+0200
@@ -1,3 +1,15 @@
+bind9 (1:9.10.3.dfsg.P4-12.3) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Dns64 with "break-dnssec yes;" can result in a assertion failure
+(CVE-2017-3136) (Closes: #860224)
+  * Some chaining (CNAME or DNAME) responses to upstream queries could trigger
+assertion failures (CVE-2017-3137) (Closes: #860225)
+  * 'rndc ""' could trigger a assertion failure in named (CVE-2017-3138)
+(Closes: #860226)
+
+ -- Salvatore Bonaccorso   Sun, 07 May 2017 15:22:46 +0200
+
 bind9 (1:9.10.3.dfsg.P4-12.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru bind9-9.10.3.dfsg.P4/debian/patches/CVE-2017-3136.patch 
bind9-9.10.3.dfsg.P4/debian/patches/CVE-2017-3136.patch
--- bind9-9.10.3.dfsg.P4/debian/patches/CVE-2017-3136.patch 1970-01-01 
01:00:00.0 +0100
+++ bind9-9.10.3.dfsg.P4/debian/patches/CVE-2017-3136.patch 2017-05-07 
15:22:46.0 +0200
@@ -0,0 +1,19 @@
+From 764240ca07ab1b796226d5402ccd9fbfa77ec32a Mon Sep 17 00:00:00 2001
+From: Mark Andrews 
+Date: Wed, 15 Feb 2017 12:18:51 +1100
+Subject: [PATCH] 4575.   [security]  Dns64 with break-dnssec yes; can
+ result in a assertion failure. (CVE-2017-3136) [RT
+ #44653]
+
+(cherry picked from commit 3bce12e4b6d37f570ffc7747b499f8b90e8521ac)
+---
+--- a/bin/named/query.c
 b/bin/named/query.c
+@@ -8145,6 +8145,7 @@ query_find(ns_client_t *client, dns_fetc
+   result = query_dns64(client, , rdataset,
+sigrdataset, dbuf,
+DNS_SECTION_ANSWER);
++  noqname = NULL;
+   dns_rdataset_disassociate(rdataset);
+   dns_message_puttemprdataset(client->message, );
+   if (result == ISC_R_NOMORE) {
diff -Nru bind9-9.10.3.dfsg.P4/debian/patches/CVE-2017-3137-1.patch 
bind9-9.10.3.dfsg.P4/debian/patches/CVE-2017-3137-1.patch
--- bind9-9.10.3.dfsg.P4/debian/patches/CVE-2017-3137-1.patch   1970-01-01 
01:00:00.0 +0100
+++ bind9-9.10.3.dfsg.P4/debian/patches/CVE-2017-3137-1.patch   2017-05-07 
15:22:46.0 +0200
@@ -0,0 +1,83 @@
+From 69fd759b4aa02047e42e5cf4227f8257c4547988 Mon Sep 17 00:00:00 2001
+From: Evan Hunt 
+Date: Thu, 23 Feb 2017 15:01:30 -0800
+Subject: [PATCH] [v9_10] remove unnecessary INSIST and prep 9.10.5rc2
+
+4578.  [security]  Some chaining (CNAME or DNAME) responses to upstream
+   queries could trigger assertion failures.
+   (CVE-2017-3137) [RT #44734]
+
+(cherry picked from commit a1365a0042db8c1cd0ee4dbd0c91ce65ae09e098)
+(cherry picked from commit 559cbe04e73cf601784a371e09554c20407a6c7b)
+---
+--- a/lib/dns/resolver.c
 b/lib/dns/resolver.c
+@@ -6924,15 +6924,15 @@ answer_response(fetchctx_t *fctx) {
+   rdataset->attributes |=
+   DNS_RDATASETATTR_CACHE;
+   rdataset->trust = dns_trust_answer;
+-  if (chaining == 0) {
++  if (external) {
+   /*
+-   * This data is "the" answer
+-   * to our question only if
+-   * we're not chaining (i.e.
+-   * if we haven't followed
+-   * a CNAME or DNAME).
++   * This data is outside of
++  

Bug#861718: src:cppunit: please update cppunit to 0.14.0

[Rene Engelhard]

Hi,

On Sun, May 14, 2017 at 10:25:48AM -0500, Steve Robbins wrote:
>Hi. I think your plan is fine. I no longer use cppunit myself so I'm happy
>to see you take an active role in the maintenance. Please consider

OK.

>yourself the lead maintainer and feel free to go ahead with upload or
>whatever.

Thanks, will do.

Regards,

Rene

Bug#862368: scan-copyrights fails to consolidate when licensecheck doesn't report years

[Paul Gevers]

Hi Dominique,

On 14-05-17 09:29, Dominique Dumont wrote:
> What command did you use ? scan-copyright or 'cme update' ?

cme update dpkg-copyright

> Which package are you working on ? (I need to retrieve your package to 
> reproduce the issue).

batmon.app¹, with proposed dsc included from here:
http://sid.ethz.ch/debian/batmon.app/batmon.app_0.9-1.dsc

Paul

¹ https://anonscm.debian.org/git/pkg-gnustep/batmon.app.git



signature.asc
Description: OpenPGP digital signature

Bug#862568: python-ncclient: Incomplete debian/copyright?

[Chris Lamb]

Source: python-ncclient
Version: 0.5.3-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Sebastien Badia 

Hi,

I just ACCEPTed python-ncclient from NEW but noticed it was missing 
attribution in debian/copyright for at least

  examples/csr1000v_example.py
  ncclient/transport/ssh.py
  setup.py

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#862567: [PATCH] apt.systemd.daily: fix error from locking code

[Alan Jenkins]

Error:

pkgs that look like they should be upgraded:
Error in function stop
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 240,
in stop
apt_pkg.size_to_str(self.current_cps))).rstrip("\n"))
  File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 51,
in _write
self._file.write("\r")
AttributeError: 'NoneType' object has no attribute 'write'
fetch.run() result: 0

Caused by:

LOCKFD=3
unattended_upgrades $LOCKFD>&-

Unfortunately this code does not work, it is equivalent to

unattended_upgrades 3 >&-

I.e. it left fd 3 open, but closed stdout!
---
 debian/apt.systemd.daily | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/debian/apt.systemd.daily b/debian/apt.systemd.daily
index 22cbbded6..d2a0bfbed 100755
--- a/debian/apt.systemd.daily
+++ b/debian/apt.systemd.daily
@@ -294,12 +294,22 @@ debug_echo()
 
 # Maintain a lock on fd 3, so we can't run the script twice at the same
 # time.
-LOCKFD=3
-eval $(apt-config shell StateDir Dir::State/d)
-exec 3>${StateDir}/daily_lock
-if ! flock -w 3600 $LOCKFD; then
-echo "E: Could not acquire lock" >&2
-exit 1
+
+if [ "$1" = "lock_is_held" ]; then
+shift
+else
+LOCKFD=3
+eval $(apt-config shell StateDir Dir::State/d)
+exec 3>${StateDir}/daily_lock
+if ! flock -w 3600 $LOCKFD; then
+echo "E: Could not acquire lock" >&2
+exit 1
+fi
+
+# We hold the lock.  Rerun this script as a child process, which
+# can run without propagating an extra fd to all of its children.
+"$0" lock_is_held "$@" 3>&-
+exit $?
 fi
 
 if test -r /var/lib/apt/extended_states; then
@@ -433,9 +443,9 @@ if [ "$1" = "update" -o -z "$1" ] ; then
 DOWNLOAD_UPGRADEABLE_STAMP=/var/lib/apt/periodic/download-upgradeable-stamp
 if [ $UPDATED -eq 1 ] && check_stamp $DOWNLOAD_UPGRADEABLE_STAMP 
$DownloadUpgradeableInterval; then
if [ $Debdelta -eq 1 ]; then
-   debdelta-upgrade >/dev/null 2>&1 $LOCKFD>&- || true
+   debdelta-upgrade >/dev/null 2>&1 || true
fi
-   if  eval apt-get $XAPTOPT -y -d dist-upgrade $XSTDERR $LOCKFD>&-; then
+   if  eval apt-get $XAPTOPT -y -d dist-upgrade $XSTDERR; then
update_stamp $DOWNLOAD_UPGRADEABLE_STAMP
debug_echo "download upgradable (success)"
else
@@ -446,7 +456,7 @@ if [ "$1" = "update" -o -z "$1" ] ; then
 fi
 
 if which unattended-upgrade >/dev/null 2>&1 && check_stamp 
$DOWNLOAD_UPGRADEABLE_STAMP $UnattendedUpgradeInterval; then
-   if unattended-upgrade -d $XUUPOPT $LOCKFD>&-; then
+   if unattended-upgrade -d $XUUPOPT; then
update_stamp $DOWNLOAD_UPGRADEABLE_STAMP
debug_echo "unattended-upgrade -d (success)"
else
@@ -461,7 +471,7 @@ if [ "$1" = "install" -o -z "$1" ] ; then
 # auto upgrade all upgradeable packages
 UPGRADE_STAMP=/var/lib/apt/periodic/upgrade-stamp
 if which unattended-upgrade >/dev/null 2>&1 && check_stamp $UPGRADE_STAMP 
$UnattendedUpgradeInterval; then
-   if unattended-upgrade $XUUPOPT $LOCKFD>&-; then
+   if unattended-upgrade $XUUPOPT; then
update_stamp $UPGRADE_STAMP
debug_echo "unattended-upgrade (success)"
else
-- 
2.11.0

Bug#862567: apt.systemd.daily always fails - 'NoneType' object has no attribute 'write' (self._file)

[Alan Jenkins]

Package: apt
Version: 1.4.3
Severity: important

I have a patch which fixes this error; I will attach it forthwith.

apt.systemd.daily fails every time.  Errors are shown in the system journal.

The error is from unattended-upgrades, so to reproduce this bug
you must have installed and enabled unattended-upgrades.

Then, remove `/var/lib/apt/periodic/download-upgradeable-stamp`
to force an update.

The error message can then be reproduced by running
`/usr/lib/apt/apt.systemd.daily update`:

Initial blacklisted packages: 
Initial whitelisted packages: 
Starting unattended upgrades script
Allowed origins are:
['origin=Debian,codename=stretch,label=Debian-Security',
'o=Debian,a=unstable']
pkgs that look like they should be upgraded: 
Error in function stop
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 240, in stop
apt_pkg.size_to_str(self.current_cps))).rstrip("\n"))
  File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 51, in _write
self._file.write("\r")
AttributeError: 'NoneType' object has no attribute 'write'
fetch.run() result: 0
...


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^linux-headers-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^.*-modules-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: 
"^linux-backports-modules-.*-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^linux-tools-4\.10\.14-200\.fc25\.x86_64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";

Bug#862183: Pending fixes for bugs in the libjgroups-java package

[pkg-java-maintainers]

tag 862183 + pending
thanks

Some bugs in the libjgroups-java package are closed in revision
1a2932b2662037acd2c01677ebfeb86d2cf9c331 in branch 'master' by tony
mancill

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libjgroups-java.git/commit/?id=1a2932b

Commit message:

Apply reproducible build patch (Closes: #862183)

Thanks to Chris Lamby.

Bug#859660: Bug#859660: artemis running issue

[tony mancill]

On Thu, May 11, 2017 at 12:33:36PM -0500, Jerome wrote:
> Thank's a lot for your questions and remark. This will help me to detect
> where was the problem.
> And i apologize that teh error is generated during the creation of a live
> debian iso file. As the error wa detected in the live itself, i send the
> report as this.. Forgetting that i'm in a live session. You're bug system is
> too perfect, as it permit report bugs in a live session!
> 
> The problem was detected and corrected in the binfmt-support bug (#750245).
> 
> So i'm declaring this issue corrected, as this from another problem.

Hello Jerome,

Thank you for the follow-up and for tracing the problem back to an issue
with the Live CD.  It's always useful to know where these issues remain.

While I was poking around with this, I was able to reproduce the problem
by installing the jessie-backports version of artemis into a jessie
chroot on a stretch (testing) system.  (Which is nothing new, because
it's just another mhandanifestation of #750245.)  The root cause of the
issue in the older chroot can be seen by trying to run the
jarwrapper.postinst directly:

# /var/lib/dpkg/info/jarwrapper.postinst
update-binfmts: warning: found manually created entry for jarwrapper in 
/proc/sys/fs/binfmt_misc; leaving it alone

Installing a artemis into a stretch or sid chroot on the same system
works fine.

What's curious to me (and perhaps helpful to others?), is that if I
create a jessie chroot and install jarwrapper *before* installing
artemis, and more to the point, before installing the JDK and its
dependencies, the jarwrapper binfmt functions correctly.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#862566: Pick a package name by clicking on a window

[Enrico Zini]

Package: reportbug
Version: 7.1.6
Severity: wishlist

Hello,

suppose I want to report a bug on a GUI software, but the window title
says "Video Player": what package name should I use?

This "simple" one-liner lets you pick a window and outputs its package name to
stdout:

dpkg -S $(readlink /proc/$(xwininfo -wm|sed -nre 's/.+Process id: 
([0-9]+).+/\1/p')/exe) | cut -d: -f1

Can you add it to reportbug, at least in its GUI interface? Like, when it asks
for the package name, there could be a button saying something like "select on
screen" that does that.

Today when showing people how to report bugs, the issue came out, and it turns
out that technically it could be easily solvable.


Enrico

-- Package-specific info:
** Environment settings:
DEBEMAIL="enr...@debian.org"
EMAIL="enr...@enricozini.org"
DEBFULLNAME="Enrico Zini"

** /home/enrico/.reportbugrc:
mode expert

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt1.4.1
ii  python3-reportbug  7.1.6
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
ii  debconf-utils1.5.60
ii  debsums  2.2
ii  dlocate  1.07+nmu1
pn  emacs23-bin-common | emacs24-bin-common  
ii  file 1:5.29-3
ii  gir1.2-gtk-3.0   3.22.11-1
ii  gir1.2-vte-2.91  0.46.1-1
ii  gnupg2.1.18-6
ii  postfix [mail-transport-agent]   3.1.4-4
ii  python3-gi   3.22.0-2
ii  python3-gi-cairo 3.22.0-2
pn  python3-gtkspellcheck
ii  python3-urwid1.3.1-2+b1
ii  xdg-utils1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4.1
ii  file   1:5.29-3
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1
pn  python3:any

python3-reportbug suggests no packages.

-- no debconf information

Bug#862565: unblock: packer/0.10.2+dfsg-5

[Roger Shimizu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package packer

This release add a patch to handle ABI change of
golang-golang-x-crypto-dev, which result FTBFS in all ARCHs.
After the patch, build is fixed.

Enclosed is the debdiff against the package in testing.
Thanks!

unblock packer/0.10.2+dfsg-5
diff -Nru packer-0.10.2+dfsg/debian/changelog 
packer-0.10.2+dfsg/debian/changelog
--- packer-0.10.2+dfsg/debian/changelog 2017-04-05 15:18:59.0 +0900
+++ packer-0.10.2+dfsg/debian/changelog 2017-05-15 00:51:19.0 +0900
@@ -1,3 +1,15 @@
+packer (0.10.2+dfsg-5) unstable; urgency=medium
+
+  * Team upload.
+  * deb/patches:
++ Add patch to handle ABI change of golang-golang-x-crypto-dev,
+  due to CVE security fix. (Closes: #861282)
+  * deb/control:
++ Bump up version of golang-golang-x-crypto-dev in Build-Depends
+  and Depends.
+
+ -- Roger Shimizu   Mon, 15 May 2017 00:51:19 +0900
+
 packer (0.10.2+dfsg-4) unstable; urgency=medium
 
   * deb/rules: disable a flaky test in packer/rpc/mux_broker_test.go
diff -Nru packer-0.10.2+dfsg/debian/control packer-0.10.2+dfsg/debian/control
--- packer-0.10.2+dfsg/debian/control   2016-11-16 02:14:02.0 +0900
+++ packer-0.10.2+dfsg/debian/control   2017-05-15 00:34:39.0 +0900
@@ -36,7 +36,7 @@
golang-github-pkg-sftp-dev,
golang-github-rackspace-gophercloud-dev (>= 
1.0.0+git20160416.884.c54bbac~),
golang-github-ugorji-go-codec-dev,
-   golang-golang-x-crypto-dev,
+   golang-golang-x-crypto-dev (>= 
1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782),
golang-golang-x-oauth2-dev (>= 0.0~git20161103.0.36bc617-2),
golang-golang-x-oauth2-google-dev,
golang-google-api-dev (>= 0.0~git20160408~),
@@ -84,7 +84,7 @@
  golang-github-pkg-sftp-dev,
  golang-github-rackspace-gophercloud-dev (>= 
1.0.0+git20160416.884.c54bbac~),
  golang-github-ugorji-go-codec-dev,
- golang-golang-x-crypto-dev,
+ golang-golang-x-crypto-dev (>= 
1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782),
  golang-golang-x-oauth2-dev (>= 0.0~git20161103.0.36bc617-2),
  golang-golang-x-oauth2-google-dev,
  golang-google-api-dev (>= 0.0~git20160408~),
diff -Nru 
packer-0.10.2+dfsg/debian/patches/handle-ABI-change-of-golang-golang-x-crypto-dev.patch
 
packer-0.10.2+dfsg/debian/patches/handle-ABI-change-of-golang-golang-x-crypto-dev.patch
--- 
packer-0.10.2+dfsg/debian/patches/handle-ABI-change-of-golang-golang-x-crypto-dev.patch
 1970-01-01 09:00:00.0 +0900
+++ 
packer-0.10.2+dfsg/debian/patches/handle-ABI-change-of-golang-golang-x-crypto-dev.patch
 2017-05-15 00:46:25.0 +0900
@@ -0,0 +1,42 @@
+From: Roger Shimizu 
+Date: Sun, 14 May 2017 23:54:04 +0900
+Subject: handle ABI change of golang-golang-x-crypto-dev
+
+That ABI change was due to CVE security fix
+
+Fix is picked from upstream of golang-golang-x-crypto-dev:
+  
https://github.com/golang/crypto/commit/e4e2799dd7aab89f583e1d898300d96367750991
+
+Closes: #861282
+---
+ communicator/ssh/communicator_test.go | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/communicator/ssh/communicator_test.go 
b/communicator/ssh/communicator_test.go
+index b0bc035..7010800 100644
+--- a/communicator/ssh/communicator_test.go
 b/communicator/ssh/communicator_test.go
+@@ -132,6 +132,7 @@ func TestNew_Invalid(t *testing.T) {
+   Auth: []ssh.AuthMethod{
+   ssh.Password("i-am-invalid"),
+   },
++  HostKeyCallback: ssh.InsecureIgnoreHostKey(),
+   }
+ 
+   address := newMockLineServer(t)
+@@ -160,6 +161,7 @@ func TestStart(t *testing.T) {
+   Auth: []ssh.AuthMethod{
+   ssh.Password("pass"),
+   },
++  HostKeyCallback: ssh.InsecureIgnoreHostKey(),
+   }
+ 
+   address := newMockLineServer(t)
+@@ -195,6 +197,7 @@ func TestHandshakeTimeout(t *testing.T) {
+   Auth: []ssh.AuthMethod{
+   ssh.Password("pass"),
+   },
++  HostKeyCallback: ssh.InsecureIgnoreHostKey(),
+   }
+ 
+   address := newMockBrokenServer(t)
diff -Nru packer-0.10.2+dfsg/debian/patches/series 
packer-0.10.2+dfsg/debian/patches/series
--- packer-0.10.2+dfsg/debian/patches/series2016-11-16 01:25:20.0 
+0900
+++ packer-0.10.2+dfsg/debian/patches/series2017-05-15 00:47:25.0 
+0900
@@ -1 +1,2 @@
 fix-tails-import-path.patch
+handle-ABI-change-of-golang-golang-x-crypto-dev.patch

Bug#862564: ITP: node-chokidar -- wrapper around node.js fs.watch / fs.watchFile / fsevents

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-chokidar
  Version : 1.7.0
  Upstream Author : Paul Miller (http://paulmillr.com)
* URL : https://github.com/paulmillr/chokidar
* License : Expat
  Programming Lang: JavaScript
  Description : wrapper around node.js fs.watch / fs.watchFile /
fsevents

 The main motivations for this library is the following short comings of
Node.js `fs.watch`:
 .
  * Doesn't report filenames on OS X.
  * Doesn't report events at all when using editors like Sublime on OS X.
  * Often reports events twice.
  * Emits most changes as `rename`.
  * Has a lot of other issues.
  * Does not provide an easy way to recursively watch file trees.
 .
 and the following short comings of Node.js `fs.watchFile`:
 .
  * Almost as bad at event handling.
  * Also does not provide any recursive watching.
  * Results in high CPU utilization.
 .
 Chokidar resolves these problems.
 .
 Node.js is an event-based server-side JavaScript engine.

Dependency of webpack



signature.asc
Description: OpenPGP digital signature

Bug#862563: debian-live: Check for updates function don't work

[syl]

Package: debian-live
Severity: normal

Dear Maintainer,

After launch the command apt update, when you click in Settings > Details >
Check for updates, it say "Software is up to date". But when go to Synaptic,
they have a lot of upgrades to do.



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#862521: further investigation

[Martin Maney]

Correction: the Realtek NIC doesn't, in fact, require that firmware. 
System works the same (aside from the boot message abouit not finding
the firmware file) without it, devices renamed the same...  And I
booted into d-i far enough to see that, yep, it sees the new name when
it sets up the NIC.

So I went and did a non-desktop install, and lo, without
NetworkManager installed, it does work as it used to.   It's been long
enough, I guess, since I did a new install with a desktop that I'd
forgotten the glitches that brings.

I still think the "improved" NIC naming is a pointless step backwards
for those of us not blessed with 64-NIC firebreathing enterprise NUMA
full-rack machines.  Not that I'd want to have that power consumption
and heat generation around here anyway!


BTW, trying to reboot into the previous install (that led to this
report in the first broken place) fails: it hangs with a cursor on a
black screen.  So apparently the grub setup for another partition is
messed up.  If I decide to put any more effort into this, which at the
moment seems unlikely as I've spent too much time already, I'll
followup.

-- 
Distributionis non sunt multiplicanda praeter necessitatem.
  (William of Occam, in the parallel universe where he was a Linux sysop)

Bug#862561: unblock: debian-reference/2.68

[Osamu Aoki]

Hi,

debdiff attached.

> 862561: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862561
diff -Nru debian-reference-2.67/bin/fuzzypo debian-reference-2.68/bin/fuzzypo
--- debian-reference-2.67/bin/fuzzypo	1970-01-01 09:00:00.0 +0900
+++ debian-reference-2.68/bin/fuzzypo	2017-05-06 23:16:56.0 +0900
@@ -0,0 +1,11 @@
+#! /bin/sh -e
+# vim: set sts=4 expandtab:
+# $1: es.po fr.po pt.po zh-cn.po zh-cn.po-best ...
+#
+DPO="po"
+MSGATTR="msgattrib"
+#
+echo "no-obsolete  $1  `${MSGATTR} --no-obsolete  $1 |grep ^msgid |sed 1d|wc -l`"
+echo "untranslated $1  `${MSGATTR} --untranslated $1 |grep ^msgid |sed 1d|wc -l`"
+echo "fuzzy$1  `${MSGATTR} --fuzzy$1 |grep ^msgid |sed 1d|wc -l`"
+echo
diff -Nru debian-reference-2.67/bin/genxml debian-reference-2.68/bin/genxml
--- debian-reference-2.67/bin/genxml	1970-01-01 09:00:00.0 +0900
+++ debian-reference-2.68/bin/genxml	2017-05-06 23:16:56.0 +0900
@@ -0,0 +1,73 @@
+#! /bin/sh -e
+# vim: set sts=4 expandtab:
+# $1: en fr pt zh-cn ...
+#
+DPO="po"
+DBIN="bin"
+DCC="/usr/share/opencc"
+MANUAL="debian-reference"
+# The threshold should be 80 if translation is completed.
+THRESHOLD="0"
+TRANSLATE="po4a-translate -M utf-8 --format docbook --keep ${THRESHOLD} -v"
+MSGCAT="msgcat"
+OPENCC="opencc"
+
+# Generate XML (en)
+gen_xml_en () {
+echo "!!! Should not be here !!!" >&2
+false
+}
+
+# Generate XML (other)
+gen_xml_other () {
+if [ -f ${DPO}/${1}.add ]; then
+${TRANSLATE} -m ${MANUAL}.en.xml -a ${DPO}/${1}.add -p ${DPO}/${1}.po -l ${MANUAL}.${1}.xml
+else
+${TRANSLATE} -m ${MANUAL}.en.xml -p ${DPO}/${1}.po -l ${MANUAL}.${1}.xml
+fi
+}
+
+# Generate XML (zh-cn)
+gen_xml_zh_CN () {
+if which opencc >/dev/null ; then
+${MSGCAT} --no-wrap ${DPO}/zh-cn.po |\
+${OPENCC} -c ${DCC}/tw2sp.json -o ${DPO}/zh-cn.po-opencc
+${MSGCAT} -o ${DPO}/zh-cn.po-best --use-first ${DPO}/zh-cn.po ${DPO}/zh-cn.po-opencc
+${DBIN}/fuzzypo ${DPO}/zh-cn.po-best >>fuzzy.log
+else
+ln -f ${DPO}/zh-cn.po ${DPO}/zh-cn.po-best
+fi
+if [ -f ${DPO}/zh-cn.add ]; then
+${TRANSLATE} -m ${MANUAL}.en.xml -a ${DPO}/zh-cn.add -p ${DPO}/zh-cn.po-best -l ${MANUAL}.zh-cn.xml
+else
+${TRANSLATE} -m ${MANUAL}.en.xml -p ${DPO}/zh-cn.po-best -l ${MANUAL}.zh-cn.xml
+fi
+#rm -f ${DPO}/zh-cn.po-best
+}
+
+# Generate XML (zh-tw)
+gen_xml_zh_TW () {
+if which opencc >/dev/null ; then
+${MSGCAT} --no-wrap ${DPO}/zh-cn.po |\
+${OPENCC} -c ${DCC}/s2twp.json -o ${DPO}/zh-tw.po-opencc
+${MSGCAT} -o ${DPO}/zh-tw.po-best --use-first ${DPO}/zh-tw.po ${DPO}/zh-tw.po-opencc
+${DBIN}/fuzzypo ${DPO}/zh-tw.po-best >>fuzzy.log
+else
+ln -f ${DPO}/zh-tw.po ${DPO}/zh-tw.po-best
+fi
+if [ -f ${DPO}/zh-tw.add ]; then
+${TRANSLATE} -m ${MANUAL}.en.xml -a ${DPO}/zh-tw.add -p ${DPO}/zh-tw.po-best -l ${MANUAL}.zh-tw.xml
+else
+${TRANSLATE} -m ${MANUAL}.en.xml -p ${DPO}/zh-tw.po-best -l ${MANUAL}.zh-tw.xml
+fi
+#rm -f ${DPO}/zh-tw.po-best
+}
+
+# Main routine
+case "$1" in
+"zh-tw")gen_xml_zh_TW;;
+"zh-cn")gen_xml_zh_CN;;
+"en")   gen_xml_en;;
+*)  gen_xml_other "$1";;
+esac
+
diff -Nru debian-reference-2.67/bin/mkindexhtml debian-reference-2.68/bin/mkindexhtml
--- debian-reference-2.67/bin/mkindexhtml	2014-10-08 23:39:16.0 +0900
+++ debian-reference-2.68/bin/mkindexhtml	2017-05-06 23:16:56.0 +0900
@@ -54,7 +54,7 @@
   echo ", epub"
 fi
 #echo ", PS"
-#echo ", PDF"
+echo ", PDF"
 echo ""
   done
   echo ""
@@ -62,7 +62,7 @@
 fi
 echo "" 
 echo "All files are encoded in UTF-8."
-#echo "HTML (single) file format is provided as substitute for PS/PDF format for full text serach."
+#echo "HTML (single) file format is provided as substitute for PS/PDF format for full text search."
 #echo "All contents are now in version 2 series based on XML source."
 #echo "The old translated contents in German, Spanish, Polish, Portuguese (Brazil), Chinese (Traditional), and Chinese (Simplified) are available as squeeze packages.  "
 echo "If your favorite language is not found in this list, please install the corresponding debian-reference-* package."
diff -Nru debian-reference-2.67/datadatepop.ent debian-reference-2.68/datadatepop.ent
--- debian-reference-2.67/datadatepop.ent	2016-12-05 01:10:07.0 +0900
+++ debian-reference-2.68/datadatepop.ent	2017-05-06 23:16:56.0 +0900
@@ -1 +1 @@
-
+
diff -Nru debian-reference-2.67/datadatesize.ent debian-reference-2.68/datadatesize.ent
--- debian-reference-2.67/datadatesize.ent	2016-12-05 01:09:48.0 +0900
+++ debian-reference-2.68/datadatesize.ent	2017-05-06 23:16:56.0 +0900
@@ -1,5 +1,5 @@
-
-
+
+
 
-
-
+
+
diff -Nru debian-reference-2.67/debian/all.install-in debian-reference-2.68/debian/all.install-in
--- debian-reference-2.67/debian/all.install-in	2014-10-08 

Bug#862562: debian-live: Log Out option don't work

[syl]

Package: debian-live
Severity: normal

Dear Maintainer,

The menu on the top right offers an option to log out (in the submenu "Debian
Live user"), it does not work and crash the system.



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#862561: unblock: debian-reference/2.68

[Osamu Aoki]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package debian-reference

(explain the reason for the unblock here)
* Added PDF (This is also for updating www.debian.org page)
  * Local browser script updated.
* Updated translation
  * Many ES and zh-cn updates.
  * Improved zh-tw translation by making opencc as the back up method 
other than the manual PO updates.

(include/attach the debdiff against the package in testing)
Attached after removing PO

unblock debian-reference/2.68

-- System Information:
Debian Release: 9.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (98, 
'experimental'), (98, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-rc6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#862219: unblock: at-spi2-atk/2.22.0-2

[Cyril Brulebois]

Niels Thykier  (2017-05-12):
> > Upstream of at-spi has released some serious fixes for at-spi2-atk,
> > which I have uploaded as at-spi2-atk 2.22.0-2, and attached to this
> > mail.
> > 
> > git-7cdc1f91c9802b0b8ecd2afea38c1717b1921736 fixes a memory corruption
> > reported by valgrind, which could make basically any application crash
> > when the Orca screen reader is running, when processing events. It does
> > so by just using the right glib function for what the buggy code meant
> > to do.
> > 
> > git-8d3cc68f7bc62c7015d986212be0d5d776920ee2 fixes memory references
> > after dropping a refcount from the object (thus potentially freed), also
> > leading to potential crash of any application when the Orca screen
> > reader is running.
> > 
> > unblock at-spi2-atk/2.22.0-2
> > 
> > [...]
> 
> Ack from here, CC'ing KiBi for a d-i ack.

No objections, thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#862220: unblock: at-spi2-core/2.22.0-6

[Cyril Brulebois]

Niels Thykier  (2017-05-12):
> > Upstream of at-spi has released some serious fixes for at-spi2-core,
> > which I have uploaded as at-spi2-core 2.22.0-6, and attached to this
> > mail.
> > 
> > git-329ef2c4ebcb3aec6dcfcac15357fd583a60c969 is reported to help fixing
> > https://bugzilla.gnome.org/show_bug.cgi?id=767074
> > Orca would sometimes hang or crash when closing an application, thus
> > leaving blind users without access to the computer, and have to restart
> > Orca blindly.  It seems there are still some cases where the crash
> > happens, but only after upgrading at-spi2-atk to version 2.24, which we
> > do not have in Debian yet.
> > 
> > git-eba079f3e72e61e6b55d81727ab50c85d505d296 fixes crashes in Orca too
> > when getting the Position property fails.
> > 
> > These would probably help with the grave orca Bug#862008
> > 
> > Samuel
> > 
> > unblock at-spi2-core/2.22.0-6
> > 
> > [...]
> 
> Ack from here, CC'ing KiBi for a d-i ack.

No objections, thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#862243: unblock: linux/4.9.25-1

[Cyril Brulebois]

Niels Thykier  (2017-05-12):
> > There was need of an ABI bump for this update, which should possibly
> > be the last one before stretch release, but not completely ruled
> > out.
> > 
> > unblock linux/4.9.25-1

No objections, thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#861282: Pending fixes for bugs in the packer package

[pkg-go-maintainers]

tag 861282 + pending
thanks

Some bugs in the packer package are closed in revision
3b5252a6242d6f53c6f2abb41d0d86932df69785 in branch 'master' by Roger
Shimizu

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/packer.git/commit/?id=3b5252a

Commit message:

Add patch to handle ABI change of golang-golang-x-crypto-dev

* deb/patches:
  + Add patch to handle ABI change of golang-golang-x-crypto-dev,
due to CVE security fix.
* deb/control:
  + Bump up version of golang-golang-x-crypto-dev in Build-Depends
and Depends.

Closes: #861282

Bug#862560: debian-live: GNOME Software in Debian Live lists only installed packages

[syl]

Package: debian-live
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Launch GNOME Software in Debian Live.
Only "Installed" tab show packages.
The "All" tab only show "Editor's Picks" on the top, the rest is blank.

   * What exactly did you do (or not do) that was effective (or ineffective)?
I launch the command "sudo apt update".

   * What was the outcome of this action?
After launch this command, the "All" tab is still blank.

   * What outcome did you expect instead?
Show all packages.



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#861718: src:cppunit: please update cppunit to 0.14.0

[Steve Robbins]

Hi.  I think your plan is fine.  I  no  longer use cppunit myself so I'm happy 
to see you take an active role in the maintenance.   Please consider yourself 
the lead maintainer and feel free to go ahead with upload or whatever.

Best
Steve 

On May 14, 2017 6:49:49 AM CDT, Rene Engelhard  wrote:
>Hi,
>
>On Wed, May 03, 2017 at 09:19:53AM +0200, Rene Engelhard wrote:
>> I prepared the update, if you want I can commit to collab-maint
>and/or add myself as co-maintainer
>> and/or even upload it.
>
>Thought I saw it on collab-maint but I must have dreamed, see none.
>
>So I imported it into pkg-openoffice's git:
>https://anonscm.debian.org/cgit/pkg-openoffice/cppunit.git
>
>I also changed the maintainer to Debian LibreOffice Maintainers, see
>ab57c8c93276a09b52e376608a36c593a0895aac, kept you as Uploaders: (and
>added 
>me)
>
>cppunit is maintained upstream at TDF so I guess it's better related.
>If you wish I can revert that, though, and move the .git somewhere
>else...
>
>Regards,
> 
>Rene

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#852750: libreadline7: readline() interferes with blocked SIGALRM

[Peter Colberg]

Control: tags -1 fixed-upstream
Control: severity -1 serious
Justification: renders package twinkle-console unusable by all users

Hi Matthias,

Could you apply upstream patch 003 to resolve this issue?

https://ftp.gnu.org/gnu/readline/readline-7.0-patches/readline70-003

Please let me know if you are busy, in which case I can offer to
upload an NMU (via sponsorship) and request an unblock for stretch.

Regards,
Peter