Bug#910777: uscan: use upstream-repo in git mode if available

[Xavier Guimard]

Package: devscripts
Version: 2.18.6
Severity: wishlist
User: devscri...@packages.debian.org
Usertags: uscan

Hello,

when upstream repo is set in debian/upstream/metadata and debian/watch
uses mode=git and `git remote show` has a "upstream-repo" entry, uscan
should update "upstream-repo" (git fetch upstream-repo) and use provided
tags to scan and create archive.

It could be useful to add an option "--use-upstream-repo": uscan will
then add automatically "upstream-repo" if not already done and works then
as above.

-- Package-specific info:

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

--- ~/.devscripts ---
USCAN_EXCLUSION=0

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.2
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.6-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.7.0
ii  at  3.1.23-1
ii  curl7.61.0-1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2018.09.30
ii  dput-ng [dput]  1.21
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-2
ii  libdistro-info-perl 0.18
ii  libdpkg-perl1.19.2
ii  libencode-locale-perl   1.05-1
ii  libfile-which-perl  1.22-1
ii  libgit-wrapper-perl 0.048-1
ii  libipc-run-perl 20180523.0-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libmoo-perl 2.003004-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.35-2
ii  licensecheck3.0.31-2
ii  lintian 2.5.108
ii  man-db  2.8.4-2
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  python3-apt 1.7.0~rc1
ii  python3-debian  0.1.33
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.18.4-2
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-4
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2+b1
ii  wget1.19.5-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
ii  adequate  0.15.1
ii  autopkgtest   5.5
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.5
pn  check-all-the-things  
pn  cvs-buildpackage  
pn  devscripts-el 
pn  diffoscope
pn  disorderfs
pn  dose-extra
ii  duck  0.13
pn  faketime  
pn  gnuplot   
ii  gpgv  2.2.10-2
pn  how-can-i-help
ii  libauthen-sasl-perl   2.1600-1
ii  libdbd-pg-perl3.7.4-1
ii  libfile-desktopentry-perl 0.22-1
ii  libnet-smtps-perl 0.09-1
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
pn  libyaml-syck-perl 
ii  mozilla-devscripts0.53
ii  mutt  1.10.1-2
ii  openssh-client [ssh-client]   1:7.8p1-1
ii  piuparts  0.92
ii  postgresql-client-10 [postgresql-client]  10.5-1
ii  quilt 0.65-2
pn  ratt  
pn  reprotest 
pn  svn-buildpackage  
ii  w3m   0.5.3-36+b1

-- no debconf information

Bug#908551: apt-listchanges: apt update hangs if no mail system

[Robert Luberda]

Michael Meskes pisze:
> On Tue, Sep 11, 2018 at 11:11:34PM +0200, Robert Luberda wrote:
>> reassign 908551 citadel-server  902-4
>> ...
>> like this (BTW. I've just temporaily installed the latest version of
>> citadel-server, trying to reproduce the bug, but its sendmail command
>> just fails, not hangs):
> 
> Sorry, I don't understand this. Why do you reassign to citadel-server when 
> your
> test shows citadel-server works correctly?

I reassigned it, because the bug reporter had citadel-server installed,
and it appeared to hang for him for some reason.

(Also I wouldn't agree it worked correctly, as it showed some failure
message instead of sending my e-mail. Most probably it was a matter of
some missing configuration, but I didn't have time to spend on it; I
only installed the package, checked that I couldn't reproduce the exact
issue from the bug report, and then uninstalled it.)

Regards,
robert

Bug#907573: Please provide u-boot image for qemu

[Vagrant Cascadian]

On 2018-09-30, Ivo De Decker wrote:
> On Mon, Sep 10, 2018 at 01:12:14PM -0700, Vagrant Cascadian wrote:
>> > If you think this is a good idea, I can write a patch (or create a merge
>> > request) that creates a u-boot-qemu package. I wonder if this would be
>> > usefull on other architectures (besided arm*).
...
> I pushed a branch 'qemu' to salsa which creates a u-boot-qemu package with the
> images for the architectures that are actually in debian:
>
> qemu-x86_64 qemu-x86 qemu_arm qemu_arm64 qemu_mips qemu_mipsel qemu_mips64el

Thanks for working on it! The patches don't change too much and even
make some improvements to debian/rules, so that's great! I'll likely
merge parts of it regardless.


> Inspired by other qemu bootloaders (like edk2, openbios, ...), I created this
> as an arch all package, which is built using the cross compilers available in
> the archive. This caused some changes in the build of the package. I would be
> interested to get your feedback on this. Do you think this is an acceptable
> way forward?

Overall, I like the improvements, but I have mixed feelings.

With multi-arch being possible, I'm inclined to keep things native... At
the same time, multi-arch is a bit annoying to require for someone
wanting to use qemu to boot a foreign architecture...

Since all the cross-compilers are (currently) only available on
amd64/i386, this would mean you can't build u-boot's arch:all packages
on anything other than amd64/i386, which might cause problems for
tests.reproducible-builds.org, which builds both arch:any and arch:all
packages for amd64, i386, arm64 and armhf.

I think it would also be easier to transition to arch:all later and
start off with native packages than the other way around.


> The existing u-boot packages contain a build of qemu-mips. The transition to
> the new u-boot-qemu package still needs to be done.
>
>> I would want to have a documented way of what it actually takes to use
>> them, upstream and/or in README.Debian. I've tried some of these targets
>> in the past and was unable to figure it out, but it's been a while.
>
> I started a preliminary README.Debian, but I intend to add some examples to
> it. If there is specific information you want to see, please let me know.

That looks like a good start, even one example would made it
solid. Surely better than some of the other u-boot packages.


So, Not sure yet either way, but thanks for putting your time and energy
into it thus far!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#910776: moin: CVE-2017-5934: XSS in GUI editor related code

[Salvatore Bonaccorso]

Source: moin
Version: 1.9.9-1
Severity: important
Tags: patch security upstream

Hi,

The following vulnerability was published for moin.

CVE-2017-5934[0]:
XSS in GUI editor related code

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-5934
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5934
[1] 
https://github.com/moinwiki/moin-1.9/commit/70955a8eae091cc88fd9a6e510177e70289ec024

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#910775: pari-gp: ploth no display

[Kevin Ryde]

Package: pari-gp
Version: 2.11.0-1
Severity: normal
File: /usr/bin/gp

On i386 with only moderately recent libraries, a ploth of a function like

ploth(a=0,Pi, sin(a))
=> [0.E-307, 3.141592653589793116, 0.E-307, 0.987638285974256]

doesn't open an X11 window, where I hoped it would.

Some gdb and xmon suggests gp queries the server for the screen size,
probably gets at least to querying the font, but doesn't open an actual
window and doesn't leave its normal forked displaying process.  In my
build of the cvs head it's ok, so I don't know where it might have
stopped.


-- System Information:
Debian Release: buster/sid
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages pari-gp depends on:
ii  libc6 2.27-6
ii  libgmp10  2:6.1.2+dfsg-3
ii  libreadline7  7.0-5
ii  libx11-6  2:1.6.6-1

Versions of packages pari-gp recommends:
ii  pari-doc  2.11.0-1
pn  pari-elldata  
pn  pari-galdata  
pn  pari-seadata  

Versions of packages pari-gp suggests:
pn  pari-galpol  
ii  pari-gp2c0.0.11-1

Bug#759618: recheck the option

[Steve Robbins]

Hi,

The issue has returned with kmail (4:18.08.1-1).  Even though I have "Prefer 
HTML to plain text", messages all show up with the following text within a red 
box: 

Note: This HTML message may contain external references to images etc. For 
security/privacy reasons external references are not loaded. If you trust the 
sender of this message then you can load the external references for this 
message by clicking here.



On Mon, 15 Sep 2014 22:10:35 -0500 "Steve M. Robbins"  wrote:
> On Thu, Sep 11, 2014 at 04:48:21PM -0400, Brian DeRocher wrote:
> > I saw this too.  Unchecking and rechecking "Prefer HTML to plain text" 
seems to fix the issue.
> 
> Thanks for the tip!  For me, I had to:
> 
> 1. Uncheck "Prefer HTML to plain text"
> 2. Click "Apply"
> 3. Re-check "Prefer HTML to plain text"
> 4. Click "Apply"

This workaround no longer works.

-Steve
 

Bug#710511: alpine: passfile support (-passfile) seems completely broken

[Eduardo Chappa]

On Wed, 10 Oct 2018, Antos Andras wrote:

Here Debian Alpine 2.20 does not core dump/segfault/crash, but the 
password is still saved only if the passfile already exists (and same 
with Alpine 2.21 in CentOS).
From the mail above, it seems this is intended, so rather a feature not a 
bug, but this does not seem to be documented anywhere (apart from internet 
forums), and alpine does not give any hint about this when it happens.


Dear Antos,

  There is some documentation on password file support, which explains a 
little bit about this issue. You can find it from the Main screen, press 
"R" to read the release notes, and look for the link to the password file 
support there.


I understand that security is important and saving passwords should not be 
the default behavior when it is not expected. However, e.g., launching alpine 
by the -passfile option (even with a nonexisting file) the user's
expectation is to use it, not silently ignore it, especially, suggested by 
the help of Alpine saying:

-passfile 
Set the password file to something other than the default


I imagine that here we disagree about the meaning of what it means to 
start a program with a non-existing file. If I start an editor with a path 
to a non-existing file, the editor will create that file, but if I start a 
web broser with a path to a non-existent file, I will not get a meaningful 
startup. The purpose of the -passfile option is to use an existing file as 
the place to save passwords. Alpine does not create password files on 
behalf of users.


(Btw, either the default password file, which seems to vary among 
versions and distributions, does not seem to be documented anywhere 
around alpine, and should be traced by strace or string.)


There is no default password file, there is the one that people compile 
into Alpine. If the Debian distributor compiles such support, they should 
let users know what they built into it.


Besides stracing or using "string" you can run Alpine with debug level -9 
to see the password file name in the .pine-debug file. I do not know if 
Debian compiles debug files support into its distribution, but that is a 
way to know it.


Also, here https://github.com/termux/termux-packages/issues/2023 one 
finds reasonable complains about mandatory "master password" (password 
for S/MIME key?) demonstrating that all in all the decision between 
convenience and security should be left to the user's discretion with 
reasonable defaults (even is not each user is very skilled).


The current development version of Alpine contains an internal way to 
eliminate the password to encrypt the password file, so users need to 
learn how to do this, for those that prefer the convenience of not having 
to enter a password to unlock their password file.


--
Eduardo
https://tinyurl.com/yc377wlh (Web)
http://repo.or.cz/alpine.git (Git)
RSS: http://repo.or.cz/alpine.git/rss (Git updates)
RSS: https://tinyurl.com/ybj33j2a (Web updates)

Bug#910770: dash: systemd-detect-virt fails to detect virtualized environment when run under dash

[Andy Sparrow]

Hi,
> Do you have more details?
> What test does systemd-detect-virt use, and why is it failing on dash?

Good question(s); not looked at this in more detail.

>  What version of systemd are you using?

In the guest, systemd 215; which corresponds to whats in Jessie up to 8.11.

In the host, multiple versions; whatever GCE gives you in a Debian Jessie
instance, and whatever's main/upstream; currently 239. Doesn't seem to make
any difference.

Tried installing the Jessie systemd backport for other reasons, but it
wouldn't fly for dependency breakage (on ifup/down, I think).


Cheers,

Andy

On Wed, Oct 10, 2018 at 6:53 PM Jonathan Nieder  wrote:

> Hi,
>
> spuggy...@gmail.com wrote:
>
> > When run under dash, systemd-detect-virt returns "none" in a
> systemd-nspawn
> > chroot'd environment when it should not; same command under bash works
> > as expected.
>
> Do you have more details?  What test does systemd-detect-virt use, and
> why is it failing on dash?  What version of systemd are you using?
>
> Thanks,
> Jonathan
>
> > Because /bin/sh is linked to /bin/dash, this causes the MAKEDEV post-inst
> > script not to realize it's in a virtual environment (despite tests added
> > in 2.3.1-93 and 2.3.1-94 versions of makedev package to detect precisely
> > this situation).
> >
> > it will, therefore, attempt to inappropriately create devices in the
> > chroot. Which fails horribly, resulting in an uninstalled/unconfigured
> > package. (actually many, in a debootstrap run)
> >
> > Which makes it more awkward than it should be to build an OS image via
> > debootstrap in a systemd-nspawn container without hackery or workarounds.
> >
> > $ systemd-nspawn -D jessie-18-10-10/ /bin/bash -c "systemd-detect-virt"
> > Spawning container jessie-18-10-10 on
> /data/PXE/squashbuilder/jessie-18-10-10.
> > Press ^] three times within 1s to kill container.
> > systemd-nspawn
> > Container jessie-18-10-10 exited successfully.
> >
> > $ systemd-nspawn -D jessie-18-10-10/ /bin/dash -c "systemd-detect-virt"
> > Spawning container jessie-18-10-10 on
> /data/PXE/squashbuilder/jessie-18-10-10.
> > Press ^] three times within 1s to kill container.
> > none
> > Container jessie-18-10-10 failed with error code 1.
>

Bug#910774: RFP: cado-nfs -- implementation of the Number Field Sieve algorithm

[John Scott]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: cado-nfs
  Version : 2.3.0
  Upstream Author : CADO-NFS Development Team 

* URL : http://cado-nfs.gforge.inria.fr
* License : LGPL
  Programming Lang: C++
  Description : an open source number field sieve implementation

CADO-NFS is a complete implementation in C/C++ of the Number
Field Sieve (NFS) algorithm for factoring integers and computing
discrete logarithms in finite fields. It consists in various
programs corresponding to all the phases of the algorithm, and
a general script that runs them, possibly in parallel over a
network of computers.

This package is relevant for being arguably the most actively
developed implementation of the fastest algorithms for
factoring large numbers. It also comes with Python scripts
that makes it more intuitive to use than alternatives IMHO.
MPI integration especially makes it stand out and acheive
very good performance.
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEAXEkn09uX7g8Tv8W3qerYfa4vJcFAlu+uH0ACgkQ3qerYfa4
vJe+dwf/dyCKajXxkajjNS6CRKEUuPKnKkJ7Ma8X2266uk8kPz6TGhwSf6KU2iSo
XgLllDSnI0CAeZTMS8RVcpwOWNlmpvpqphuH0AERUJ1BO+sO12YnVa1TcYFXCKvQ
EfA5yH/iNvlsvg/YVo6g2ppl6d2mnFsiRg+9Sydg3B/2ojwkUEs2sMTLdxotk4aL
OTMFngFikQSmMwVSCYPPyyoVBFsaTee+G0ra80MKvTxRsGdFTMxuo8ky2xt9ows1
YGnc/47ELdFLwJT1kbfQj5Q9Av5kuR+s+1lQGK5Vgf5YGIwpc0nvq5wgij1hSuH9
PE7E7f0aIZIIqgAJlEQpu5WO7FVGRQ==
=vbVU
-END PGP SIGNATURE-

Bug#910770: dash: systemd-detect-virt fails to detect virtualized environment when run under dash

[Michael Biebl]

Am 11.10.18 um 03:53 schrieb Jonathan Nieder:
> Hi,
> 
> spuggy...@gmail.com wrote:
> 
>> When run under dash, systemd-detect-virt returns "none" in a systemd-nspawn
>> chroot'd environment when it should not; same command under bash works
>> as expected.
> 
> Do you have more details?  What test does systemd-detect-virt use, and
> why is it failing on dash?  What version of systemd are you using?

Fwiw, I can't reproduce

# machinectl shell debian
Connected to machine debian. Press ^] three times within 1s to exit session.
root@debian:~# systemd-detect-virt
systemd-nspawn
root@debian:~# dash
# systemd-detect-virt
systemd-nspawn

This is on stretch.

-- 
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#910773: clojure1.8: clojure fails to run with openjdk-11

[Tiago Daitx]

Please consider the attached debdiff which basically applies the
upstream fix and adds a dep3 header to it.
diff -Nru clojure1.8-1.8.0/debian/changelog clojure1.8-1.8.0/debian/changelog
--- clojure1.8-1.8.0/debian/changelog	2018-08-04 17:56:45.0 -0300
+++ clojure1.8-1.8.0/debian/changelog	2018-10-10 13:47:36.0 -0300
@@ -1,3 +1,11 @@
+clojure1.8 (1.8.0-8) cosmic; urgency=medium
+
+  * debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch:
+Add hint type to toArray method to resolve ambiguity introduced by
+JDK 11. (Closes: #910773, LP: #1796985).
+
+ -- Tiago Stürmer Daitx   Wed, 11 Oct 2018 02:12:55 +
+
 clojure1.8 (1.8.0-7) unstable; urgency=medium
 
   * Update Vcs-* links to point to the clojure-team repo.
diff -Nru clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch
--- clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch	1969-12-31 21:00:00.0 -0300
+++ clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch	2018-10-10 13:45:50.0 -0300
@@ -0,0 +1,37 @@
+Description: Add hint to overloaded toArray method
+ OpenJDK 11 added a new overload to the toArray method that
+ causes a slight API breakage. This requires calls to toArray
+ to set a type hint in order to prevent the exception
+ java.lang.IllegalArgumentException.
+Origin: https://github.com/clojure/clojure/commit/68d8b83138437c18f1d5cf9ba46c056aa2701d23
+Bug: https://dev.clojure.org/jira/browse/CLJ-2374
+Bug-Ubuntu: https://launchpad.net/bugs/1796985
+Applied-Upstream: https://github.com/clojure/clojure/commit/68d8b83138437c18f1d5cf9ba46c056aa2701d23
+Last-Update: 2018-10-10
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 68d8b83138437c18f1d5cf9ba46c056aa2701d23 Mon Sep 17 00:00:00 2001
+From: Alex Miller 
+Date: Mon, 1 Oct 2018 09:29:37 -0500
+Subject: [PATCH] CLJ-2374 Add type hint to toArray to resolve ambiguity in JDK
+ 11
+
+Signed-off-by: Stuart Halloway 
+---
+ src/clj/clojure/gvec.clj | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/clj/clojure/gvec.clj b/src/clj/clojure/gvec.clj
+index 3c4007379..6208f5539 100644
+--- a/src/clj/clojure/gvec.clj
 b/src/clj/clojure/gvec.clj
+@@ -397,7 +397,7 @@
+   (containsAll [this c] (every? #(.contains this %) c))
+   (isEmpty [_] (zero? cnt))
+   (toArray [this] (into-array Object this))
+-  (toArray [this arr]
++  (^objects toArray [this ^objects arr]
+ (if (>= (count arr) cnt)
+   (do
+ (dotimes [i cnt]
diff -Nru clojure1.8-1.8.0/debian/patches/series clojure1.8-1.8.0/debian/patches/series
--- clojure1.8-1.8.0/debian/patches/series	2018-03-19 16:31:31.0 -0300
+++ clojure1.8-1.8.0/debian/patches/series	2018-10-10 13:46:55.0 -0300
@@ -1 +1,2 @@
 02-modify-cli-usage.patch
+03-add-toarray-hint-type-68d8b83138437c18.patch

Bug#910773: clojure1.8: clojure fails to run with openjdk-11

[Tiago Stürmer Daitx]

Package: clojure1.8
Version: 1.8.0-7
Severity: important

Dear Maintainer,

when trying to run clojure1.8 with openjdk-11 it fails with

Exception in thread "main" java.lang.ExceptionInInitializerError
 at clojure.main.(main.java:20)
Caused by: java.lang.IllegalArgumentException: Must hint overloaded method: 
toArray, compiling:(clojure/gvec.clj:131:1)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6875)
 at clojure.lang.Compiler.analyze(Compiler.java:6669)
 at clojure.lang.Compiler.analyze(Compiler.java:6625)
 at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6003)
 at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6319)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
 at clojure.lang.Compiler.analyze(Compiler.java:6669)
 at clojure.lang.Compiler.analyze(Compiler.java:6625)
 at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6005)
 at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5380)
 at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3972)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6866)
 at clojure.lang.Compiler.analyze(Compiler.java:6669)
 at clojure.lang.Compiler.eval(Compiler.java:6924)
 at clojure.lang.Compiler.load(Compiler.java:7379)
 at clojure.lang.RT.loadResourceScript(RT.java:372)
 at clojure.lang.RT.loadResourceScript(RT.java:363)
 at clojure.lang.RT.load(RT.java:453)
 at clojure.lang.RT.load(RT.java:419)
 at clojure.core$load$fn__1621.invoke(core.clj:5893)
 at clojure.core$load.invokeStatic(core.clj:5892)
 at clojure.core$load.doInvoke(core.clj:5876)
 at clojure.lang.RestFn.invoke(RestFn.java:408)
 at clojure.core$eval3106.invokeStatic(core.clj:6523)
 at clojure.core$eval3106.invoke(core.clj:6523)
 at clojure.lang.Compiler.eval(Compiler.java:6927)
 at clojure.lang.Compiler.load(Compiler.java:7379)
 at clojure.lang.RT.loadResourceScript(RT.java:372)
 at clojure.lang.RT.loadResourceScript(RT.java:363)
 at clojure.lang.RT.load(RT.java:453)
 at clojure.lang.RT.load(RT.java:419)
 at clojure.lang.RT.doInit(RT.java:461)
 at clojure.lang.RT.(RT.java:331)
 ... 1 more
Caused by: java.lang.IllegalArgumentException: Must hint overloaded method: 
toArray
 at clojure.lang.Compiler$NewInstanceMethod.parse(Compiler.java:8206)
 at clojure.lang.Compiler$NewInstanceExpr.build(Compiler.java:7798)
 at 
clojure.lang.Compiler$NewInstanceExpr$DeftypeParser.parse(Compiler.java:7678)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
 ... 33 more

This is related to https://dev.clojure.org/jira/browse/CLJ-2374 and the 
proposed fix upstream is available at 
https://github.com/tirkarthi/clojure/commit/63dab8e6cb702a6b0c5b279721bee7eff0aba44f.patch

Regards,
Tiago

-- System Information:
Debian Release: buster/sid
  APT prefers cosmic
  APT policy: (500, 'cosmic'), (400, 'cosmic-proposed')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#910772: lists.debian.org: switch GMANE and MARC links to https

[Paul Wise]

Package: lists.debian.org
Severity: wishlist

On the page for Message-ID lookup failure, please switch the GMANE and
MARC links to https so that by default users get encryption.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#910771: tracker.debian.org: parse wnpp bug reports and display pages for ITP/RFP packages not yet in Debian

[Paul Wise]

Package: tracker.debian.org
Severity: wishlist

It would be nice if tracker.debian.org could parse wnpp bug reports and
display pages for ITP/RFP packages not yet in Debian. This would be an
easier alternative to wnpp.debian.net. The Homepage could be extracted from the 
initial submission and the package name and description from the current bug 
title.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#910770: dash: systemd-detect-virt fails to detect virtualized environment when run under dash

[Jonathan Nieder]

Hi,

spuggy...@gmail.com wrote:

> When run under dash, systemd-detect-virt returns "none" in a systemd-nspawn
> chroot'd environment when it should not; same command under bash works
> as expected.

Do you have more details?  What test does systemd-detect-virt use, and
why is it failing on dash?  What version of systemd are you using?

Thanks,
Jonathan

> Because /bin/sh is linked to /bin/dash, this causes the MAKEDEV post-inst
> script not to realize it's in a virtual environment (despite tests added
> in 2.3.1-93 and 2.3.1-94 versions of makedev package to detect precisely
> this situation).
>
> it will, therefore, attempt to inappropriately create devices in the
> chroot. Which fails horribly, resulting in an uninstalled/unconfigured
> package. (actually many, in a debootstrap run)
>
> Which makes it more awkward than it should be to build an OS image via
> debootstrap in a systemd-nspawn container without hackery or workarounds.
>
> $ systemd-nspawn -D jessie-18-10-10/ /bin/bash -c "systemd-detect-virt"
> Spawning container jessie-18-10-10 on /data/PXE/squashbuilder/jessie-18-10-10.
> Press ^] three times within 1s to kill container.
> systemd-nspawn
> Container jessie-18-10-10 exited successfully.
>
> $ systemd-nspawn -D jessie-18-10-10/ /bin/dash -c "systemd-detect-virt"
> Spawning container jessie-18-10-10 on /data/PXE/squashbuilder/jessie-18-10-10.
> Press ^] three times within 1s to kill container.
> none
> Container jessie-18-10-10 failed with error code 1.

Bug#910770: dash: systemd-detect-virt fails to detect virtualized environment when run under dash

[spuggy...@gmail.com]

Package: dash
Version: 0.5.7-4+b1
Severity: important

Dear Maintainer,

When run under dash, systemd-detect-virt returns "none" in a systemd-nspawn
chroot'd environment when it should not; same command under bash works
as expected.

Because /bin/sh is linked to /bin/dash, this causes the MAKEDEV post-inst
script not to realize it's in a virtual environment (despite tests added
in 2.3.1-93 and 2.3.1-94 versions of makedev package to detect precisely
this situation).

it will, therefore, attempt to inappropriately create devices in the
chroot. Which fails horribly, resulting in an uninstalled/unconfigured
package. (actually many, in a debootstrap run)

Which makes it more awkward than it should be to build an OS image via
debootstrap in a systemd-nspawn container without hackery or workarounds.


$ systemd-nspawn -D jessie-18-10-10/ /bin/bash -c "systemd-detect-virt"
Spawning container jessie-18-10-10 on /data/PXE/squashbuilder/jessie-18-10-10.
Press ^] three times within 1s to kill container.
systemd-nspawn
Container jessie-18-10-10 exited successfully.

$ systemd-nspawn -D jessie-18-10-10/ /bin/dash -c "systemd-detect-virt"
Spawning container jessie-18-10-10 on /data/PXE/squashbuilder/jessie-18-10-10.
Press ^] three times within 1s to kill container.
none
Container jessie-18-10-10 failed with error code 1.


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

Kernel: Linux 4.18.10-arch1-1-ARCH (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dash depends on:
ii  debianutils  4.4+b1
ii  dpkg 1.17.27
ii  libc62.19-18+deb8u10

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#910766: requests: CVE-2018-18074

[Daniele Tricoli]

Hello Salvatore,

On 10/10/18 10:50 PM, Salvatore Bonaccorso wrote:
> The following vulnerability was published for requests.
> 
> CVE-2018-18074[0]:
> | The Requests package through 2.19.1 before 2018-09-14 for Python sends
> | an HTTP Authorization header to an http URI upon receiving a
> | same-hostname https-to-http redirect, which makes it easier for remote
> | attackers to discover credentials by sniffing the network.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

Many thanks for the report! I will work on this by the end of the week.

Kind regards,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org



signature.asc
Description: OpenPGP digital signature

Bug#903698: sphinxbase: build appears broken for multiple python3 versions

[Samuel Thibault]

Samuel Thibault, le mer. 10 oct. 2018 18:33:18 +0200, a ecrit:
> Emilio Pozuelo Monfort, le mer. 10 oct. 2018 18:27:18 +0200, a ecrit:
> > debian/tmp/usr/lib/python3* usr/lib
> > 
> > That is causing both the python3.6/ and python3.7/ contents to be moved to
> > usr/lib,
> 
> D'oh!
> 
> Thanks for the fix, I have pushed it to our tree.

Mmm, we still have an issue:

W: python3-sphinxbase: python-module-in-wrong-location 
usr/lib/python3.6/site-packages/sphinxbase/ 
usr/lib/python3/dist-packages/sphinxbase/
W: python3-sphinxbase: python-module-in-wrong-location 
usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so 
usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so

These are indeed completely bogus.

Samuel

Bug#903989: vcr.py: autopkgtest needs update for python3.7 in supported versions

[Daniele Tricoli]

Hello,

On 9/24/18 3:09 PM, Mattia Rizzolo wrote:
> I think so, hence I'm rising the severity of this bug.
> 
> I believe the latest upstream version 2.0.0 fixes this bug, however.
> https://github.com/kevin1024/vcrpy/commit/e93060c81bef0130d0626b348ab753db50e3f8fb
> https://github.com/kevin1024/vcrpy/commit/b38915a89aef77f7169fdf3aa949072050029648

Many thanks for the investigation, I will update vcr.py during this
week! Sorry for the delay!

Cheers,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org



signature.asc
Description: OpenPGP digital signature

Bug#907800: simple fix

[Thomas Lange]

It's easy to extend the savelog.LAST.sh with a few lines, so all error
lines also appear on the screen and in fai.log


--- savelog.LAST.sh 2018-07-26 13:59:33.678976391 +0200
+++ /home//savelog.LAST.sh 2018-10-11 02:28:31.947821982 +0200
@@ -203,6 +203,9 @@
 
 if [ -s $errfile ]; then
echo "ERRORS found in log files. See $errfile" >&2
+   echo  === ERRORS ===
+   cat $errfile
+   echo  === ERRORS ===
 else
echo "Congratulations! No errors found in log files."
 fi

-- 
regards Thomas

Bug#907800: hooks are not affected

[Thomas Lange]

I did a test with a hook that exits with an error. This is what
appears in fai.log:

mountdisks.DEFAULT   FAILED with exit code 77.

Hooks are not affected by this bug report.
-- 
regards Thomas

Bug#910707: s-s-d: please implement service readiness protocol

[Michael Biebl]

Am 10.10.18 um 21:00 schrieb Michael Biebl:
> On Wed, 10 Oct 2018 11:10:38 -0300 Felipe Sateler 
> wrote:
> 
>> Awesome. This should help a lot.
> 
> This is great indeed, thanks Guillem!
> I quickly looked at the branch, and noticed a a few typos. Patch attached.

A quick test with /lib/systemd/systemd-udevd suggests that this is not
quite working yet.

One thing I noticed is that NOTIFY_SOCKET is not set.
And even if I manually set that via
export NOTIFY_SOCKET=/run/s-s-d-channel.id.notify
a test script using systemd-notify [1] yields

Failed to notify init system: Connection refused

Regards,
Michael

[1] https://www.freedesktop.org/software/systemd/man/systemd-notify.html

-- 
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#908796: udev (with sysvinit) fails to find devices at boot

[Bill Brelsford]

On Wed Oct 10 2018 at 09:03 PM +0200, Michael Biebl wrote:
> I've compiled a dpkg test package from this branch [1].
> Bill, it would be great if you can install this dpkg package and try it
> along with the attached patch for the udev init script.

I installed your new dpkg and patched the udev init script, but it
doesn't work.  S-s-d apparently doesn't wait for udev to be ready.

Bill

Bug#905959: elf-arch: first stab

[Adam Borowski]

> The question "Does executable / shared libary / object file X plausibly
> match Debian architecture Y?" needs to be answered in a number of places.

Sorry for the delay, I only today found some time to work on this.

> All of them work based on examining the output of file.

... which comes from the ELF/PE header, and produces output meant for humans
that tends to change.

> changes over time. The latter causes implementations to differ. For
> instance, lintian presently lacks support for mipsr6, mipsr6el, nios2,
> or1k, riscv64 and sh3.

nios2 and or1k are obscure archs, riscv64 merely new.  On the other hand,
there's as far as I know no way to distinguish between sh3 and sh4 other
than disassembling the file.

As for mipsr6{,el}, I have no such file at hand -- could you send me a
sample so I can have a look?

My current version is at http://github.com/kilobyte/arch-test -- does this
seem to be what you want?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Bug#910769: Split out featherpad-l10n

[Alf Gaida]

Package: featherpad
Version: 0.9.1
Severity: normal

Just split out featherpad-l10n. Now there are more than two languages are
supported it is worth it.

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

Kernel: Linux 4.19.0-rc6-siduction-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages featherpad depends on:
ii  libc62.27-6
ii  libgcc1  1:8.2.0-7
ii  libqt5core5a 5.11.1+dfsg-9
ii  libqt5gui5   5.11.1+dfsg-9
ii  libqt5network5   5.11.1+dfsg-9
ii  libqt5printsupport5  5.11.1+dfsg-9
ii  libqt5svg5   5.11.1-2
ii  libqt5widgets5   5.11.1+dfsg-9
ii  libqt5x11extras5 5.11.1-2
ii  libstdc++6   8.2.0-7
ii  libx11-6 2:1.6.7-1

Versions of packages featherpad recommends:
ii  featherpad-l10n  0.9.2~1-gac3fa61-1
ii  libglib2.0-bin   2.58.1-2

featherpad suggests no packages.

-- no debconf information

Bug#910737: dpkg-source -b /path/to/somewhere should not delete somewhere.orig

[Ian Jackson]

Guillem Jover writes ("Re: Bug#910737: dpkg-source -b /path/to/somewhere should 
not delete somewhere.orig"):
> Well, this is the documented behavior for source format 1.0 (it does
> not apply to newer source formats) which has acted like this since its
> introduction in dpkg 1.3.0:
> 
>   
> 

I'm very prepared to believe this is my bug.

> Even considering changing this seems too painful, when the easy way
> forward is to just switch to one of the new source formats. So I'm
> inclined to just close this, as one of the known historic warts of
> the 1.0 format.

I think it would be better to change the default from -sA to -sa,
even if nothing else is done.

Even better would be to change the spec for -sa/-sA/-sp to use a
temporary directory for the orig unupack.

Leaving aside the supposed merits of the new source formats, which I
don't entirely agree with: it is not in general feasible to change to
newer source formats.  Someone doing QA work (especially NMUs), or a
downstream, is often not in a position to change the source format.
They need to be able to work with what they are given.

Ian.

Bug#910705: Bug#910687: dgit: build-source and push-source disregard -wc

[Ian Jackson]

Sean Whitton writes ("Bug#910705: Bug#910687: dgit: build-source and 
push-source disregard -wc"):
> I'm pretty sure this is a straightforward bug -- unless --ignore-dirty
> or --include-dirty is specified, push-source and build-source are meant
> to error out if the tree is dirty.

There are three levels of dirtiness: contains uncommitted changes to
tracked files; contains untracked but ignored files; contains
untracked and un-ignored files.

Currently dgit only *complains* about uncommitted changes to tracked
files.

Untracked files of both kinds are deleted by -wg[f] - except that if
dgit uses a playtree it doesn't need to clean at all so it doesn't and
the files are not included but also not deleted.

That -wc does not spot untracked files is clearly a bug.  But it would
be sensible to have a variant that tolerates ignored untracked files.

What -wd[d] ought to do about untracked files - especially un-ignored
ones - is far from clear.  It runs rules clean and then hopefully the
build products are deleted, but clean targets are often buggy.
gitignore files are often missing or incomplete.

Hence my suggestion for -wd[d] by default to trip on untracked
unignored files, but to ignore untracked ignored ones.  An ignored
file has been deliberately marked to be excluded from the source
code.  And there should be an option to allow un-ignored ones too.

The underlying thing going on here is that when making a source
package the user might reasonably want to simply not include the junk
that is cluttering their tree, rather than having dgit insist on it
being either deleted or included in the output.

Ian.

Bug#910753: apt: Race condition between apt's systemd timers & cloud-init

[Ross Vandegrift]

On Wed, Oct 10, 2018 at 11:24:16PM +0200, Julian Andres Klode wrote:
> > Would you be open to adding cloud-init.target to the After list on
> > apt-daily.timer? 
> 
> No. cloud-init injects itself into the boot to try to run as early
> as possible. It must ensure it works properly itself, and probably
> wants to run Before=timers.target.

That's fair - I'll test this, thanks for the alternative idea!

Thanks,
Ross

Bug#910705: Bug#910687: dgit: build-source and push-source disregard -wc

[Ian Jackson]

Ian Jackson writes ("Re: Bug#910687: dgit: build-source and push-source 
disregard -wc"):
> I think in fact that this needs to be more general.  For example, with
> --clean=dpkg-source: if dpkg-source leaves untracked files, this
> should be detected.  I think this check should happen any time dgit
> builds a source package.

I made this table.  You'll need a wide window and a fixed-width font
and 8-column tabs.

In summary:

dgit used to always clean the tree.  But push-source and build-source
don't need to (when working in a playtree, ie without
--include-dirty), so don't.  I think we need to reintroduce some
variant of tree cleaning to those operations.

But I'm not really convinced that push-source and build-source ought
ever to run rules clean.  So I think we need a new interpretation of
clean modes: ie, the source builds should look at the clean mode and
do *something*: and that something will be to check that it doesn't
look like a git-add was forgotten.

And then I think we need a way to override this.  Given the special
nature of the various cases, I think that is going to be some new
clean modes which are varients of existing ones.

Ian.

/: = without --include-dirty
i: = with --include-dirty

ACTION ON BINARIES BUILD
ACTION ON SOURCE BUILD

ignored files   unignored files 
ignored files   unignored files


(These are gitignored files (These are un-ignored files,

 which could have resulted   maybe from a build (buggy  

 from a build without there  gitignore), or maybe   

 being any bug.) forgot to git add) 


quite possibly present  hopefully not present

often present in non-dgit pkgs

dpkg-source }   (runs rules clean)  (runs rules clean)  
(used to run rules clean)   (used to run rules clean)
dpkg-source-d   }   /: disregarded  /: disregarded  
do we want rules clean ?do we want rules clean ?
i: used*i: used*
without, makes check less good  without, makes check less good
(These are  (These are un-gitignored
/: disregarded  /: disregarded
 gitignored filesfiles left by rules clean. 
i: used*i: used*
 left by rules clean;Either buggy clean or  
 probably a bug but  forgot to git add.)
 not one we care about) 

/: ** should trip **
/: ** should trip **
 ** wddu ? **   ** want opt to disregard ** 
** want opt to disregard **
 aka --dpkg-source,untracked

git }   deleted deleted 
/: disregarded  /: disregarded
git-ff  }   
   would be fine to delete but

   ** better to trip ? **

** want opt to disregard **


i: used*i: used*

check   trips   trips   
/: disregarded  /: disregarded

i: used*i: used*


both: ** should trip ** both: ** should trip **

 ** wci ? **
** want opt to tolerate (only) ignored files **
 aka --clean=check,ignore

none/: disregarded  /: disregarded  
/: disregarded  /: disregarded
i: used*i: used*
i: used*  

Bug#910768: Acknowledgement (svn-load: TypeError when svn-load needs to ask for a password)

[Philipp Spitzer]

Actually, I attached the patch to the last mail. I tested it on my
system and it worked well. :-)

Bug#910753: apt: Race condition between apt's systemd timers & cloud-init

[Julian Andres Klode]

Control: reassign -1 cloud-init

On Wed, Oct 10, 2018 at 10:14:14AM -0700, Ross Vandegrift wrote:
> Package: apt
> Version: 1.7.0
> Severity: normal
> 
> Hello,
> 
> When a cloud VM is booted with systemd, the timers for apt's periodic actions
> are launched in parallel with cloud-init.  cloud-init does some initial
> setup, but it also allows end users to customize the system by e.g.,
> installing packages with apt.

I have not heard or seen this before.

> 
> Would you be open to adding cloud-init.target to the After list on
> apt-daily.timer? 

No. cloud-init injects itself into the boot to try to run as early
as possible. It must ensure it works properly itself, and probably
wants to run Before=timers.target.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#910768: svn-load: TypeError when svn-load needs to ask for a password

[Philipp Spitzer]

Package: svn-load
Version: 1.3-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

since I reinstalled my system, using svn-load like

svn-load https://www.example.com/svn/myproject/ current /tmp/somedir

terminates with the following traceback:

TypeError: get_login() takes exactly 3 arguments (4 given)
Traceback (most recent call last):
  File "/usr/bin/svn-load", line 652, in 
"Load %s into %s." % (os.path.basename(d), import_dir))
pysvn._pysvn_2_7.ClientError: unhandled exception in callback_get_login

after doing the local work, just before commiting the changes to the svn
server. With the freshly installed system, svn-load would need to ask me
for the svn password but fails to do so. As the version I had installed
on my old system worked well and was idendical, I assume that when a
cached password is present (which is the case in most scenarios -
therefore I could not find a bug report for this problem), the script
works well.

I created a simple patch that I'll attach to my next mail.

-- System Information:
Debian Release: 9.5
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages svn-load depends on:
ii  python  2.7.13-2
ii  python-svn  1.9.4-2

svn-load recommends no packages.

svn-load suggests no packages.

-- no debconf information
diff --git a/svn-load b/svn-load
index 9c18fa0..37cddbe 100755
--- a/svn-load
+++ b/svn-load
@@ -68,11 +68,11 @@ class NotifiedClient:
 def ssl_client_cert_password_prompt(realm, may_save):
 return True, getpass.getpass("Passphrase for '%s': " % (realm)), False
 
-def get_login(realm, username, may_save):
+def get_login(self, realm, username, may_save):
 if not self.password:
 self.password = raw_input("Password for %s (svn): " % username)
 
-return (True, username, password, False)
+return (True, username, self.password, False)
 
 ## pysvn supports a number of callbacks for scenarios I've yet to
 ## encounter. For now, just emit a warning to hopefully clue the user

Bug#910767: RM: tomcat8.0 -- ROM; not needed anymore

[Timo Aaltonen]

Package: ftp.debian.org
Severity: normal

This was a temporary package until dogtag-pki and tomcatjss were ported
to tomcat 8.5 and uploaded to sid, which they are now. There aren't any
reverse depends left.

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

Am 10.10.18 um 22:28 schrieb Bill Brelsford:
> On Wed Oct 10 2018 at 09:03 PM +0200, Michael Biebl wrote:
>> I've compiled a dpkg test package from this branch [1].
>> Bill, it would be great if you can install this dpkg package and try it
>> along with the attached patch for the udev init script.
> 
> I'd be glad to, but that machine is running i686.  Can you make a
> 32-bit version..?

Sure, no problem. You can find them at the same URL.



-- 
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#910766: requests: CVE-2018-18074

[Salvatore Bonaccorso]

Source: requests
Version: 2.18.4-2
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/requests/requests/issues/4716

Hi,

The following vulnerability was published for requests.

CVE-2018-18074[0]:
| The Requests package through 2.19.1 before 2018-09-14 for Python sends
| an HTTP Authorization header to an http URI upon receiving a
| same-hostname https-to-http redirect, which makes it easier for remote
| attackers to discover credentials by sniffing the network.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-18074
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18074
[1] https://github.com/requests/requests/issues/4716
[2] 
https://github.com/requests/requests/commit/c45d7c49ea75133e52ab22a8e9e13173938e36ff
[3] https://github.com/requests/requests/pull/4718

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#910707: Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

Am 10.10.18 um 21:00 schrieb Michael Biebl:
> I quickly looked at the branch, and noticed a a few typos. Patch attached.
  ^^^
oh the irony :-)


-- 
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#910637: installation failure

[Simon McVittie]

Control: tags 910637 = stretch
Control: retitle 910637 Fails to install in lxc container: fork() failed: 
Resource temporarily unavailable
Control: reassign 910637 avahi-daemon 0.6.32-2
Control: affects 910637 libnss-mdns

On Wed, 10 Oct 2018 at 13:56:36 +0200, Harald Dunkel wrote:
> I did not ask for Avahi at all.

Not directly, but libnss-mdns requires avahi-daemon and can't work
without it.

> The unwanted Avahi daemon complains about missing or broken mdns
> support:
> 
>   Failed to start Avahi mDNS/DNS-SD Stack.

Ah, I see. You're misunderstanding that message: "Avahi mDNS/DNS-SD
Stack" is just a description of avahi-daemon (Avahi is an implementation
of the mDNS and DNS-SD protocols). Avahi doesn't require libnss-mdns,
but libnss-mdns requires Avahi.

This looks like the same issue as  so
I'm reassigning it.

Workaround: edit /etc/avahi/avahi-daemon.conf and comment out all the
lines starting with "rlimit-".

smcv

Bug#910765: very slow boot with backport kernel (+workaround)

[stefano gozzi]

Package: linux-image-4.18.0-0.bpo.1-amd64


Debian stable (updated) with kernel 4.18.0-0.bpo.1-amd64 #1 SMP Debian
4.18.6-1~bpo9+1 (2018-09-13) x86_64 GNU/Linux

updating from standard kernel to backports, the boot is very slow (gdm
login appears after ~3 minutes)

boot process is stuck before "crng init done" as you can see by messages:
Oct 10 18:06:24 gozzi-MBP NetworkManager[598]:   [1539187584.4027]
dhcp6 (wlp4s0b1): state changed bound -> done
Oct 10 18:09:15 gozzi-MBP kernel: [  194.178094] random: crn

Workaround that solves the problem: install the package haveged


workaround tried but not working
install backport headers
install rng-tools

hardware informations
Manufacturer: Apple Inc.
Product Name: Mac-C3EC7CD22292981F
Version: MacBookPro10,1

thanks for the effort
stefano

Bug#830865: any progress?

[Matija Nalis]

This still seems to happen on bugs.debian.org mails, for example I
got RUF reports like:

Authentication-Results: mail.susi-moog.de;
dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=voyager.hr header.i=@voyager.hr header.b=jhX0w52b;
dkim-atps=neutral

It is really problematic, because if person reporting bug uses DKIM,
and MTA of package maintainer (or other subscribed persons) verifies
it, then the bug report might never reach the maintainer /
interested subscribers.

This is especially likely to happen if DMARC is also used with
policy different than "none".

Could some solution/workaround (like #500965 for similar problems in
lists.debian.org) be adopted?

-- 
Opinions above are GNU-copylefted.

Bug#910731: kaddressbook: crashes at startup

[Bernhard Übelacker]

Hello Francesco,
just came around and found this could be related to that
bug report [1], related to package libkf5kontactinterface5.

Kind regards,
Bernhard

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910581

Bug#904316: Any updates to boost 1.67 rebuilds ?

[Giovanni Mascellani]

Hi,

Il 10/10/18 20:02, shirish शिरीष ha scritto:
> Dear Giovanni,
> 
> were you able to get any more insight into the boost rebuilds ?

I have been busy with other things, but I have begun writing some
patches. None published yet, however. You can track something of my
status on the file I posted in the BTS. I will keep working on it in the
next days, as time permits.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#910761: [Pkg-freeipa-devel] Bug#910761: 389-ds-base: missing dependencies on python modules that dsconf can work

[Timo Aaltonen]

On 10.10.2018 22:54, Vaclav Ovsik wrote:
> Package: 389-ds-base
> Version: 1.4.0.16-1
> Severity: normal
> 
> Dear Maintainer,
> the package misses dependency on python3-ldap, python3-argcomplete
> and python3-lib389. These are needed for dsconf utility to work.
> Thanks

Well, in fact these tools should be in python3-lib389, I just hadn't
noticed them when packaging 1.4.0.x, and they got automatically added to
389-ds-base because the .install pulls everything in usr/sbin.

also, to get the manpages for the new utils argparse-manpage needs to
get out of NEW...


-- 
t

Bug#910705: Bug#910687: dgit: build-source and push-source disregard -wc

[Sean Whitton]

Hello,

On Wed 10 Oct 2018 at 01:51AM +0100, Ian Jackson wrote:

> Also, arguably something should have stopped you proceeding with an
> untracked unignored files (perhaps, especially as you specified -wc).
> But the clean mode is basically ignored with build-source (and
> push-source) since the tree does not need to be cleaned.  But spotting
> uncommitted files is important.

I'm pretty sure this is a straightforward bug -- unless --ignore-dirty
or --include-dirty is specified, push-source and build-source are meant
to error out if the tree is dirty.

> I'm not sure exactly what to do about this but I have cloned this bug
> to track this issue.  It seems odd to say that --clean=check ought to
> make build-source and push-source check for loose files, even though
> they usually don't actually clean the tree at all.  Perhaps there
> should be a separate check which doesn't depend on the clean mode ?

I don't follow what's difficult about this.  push-source and
build-source should always just check for a dirty tree, and error out,
unless they've been told not to.

The presence of absence of -wc does not seem relevant.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Bill Brelsford]

On Wed Oct 10 2018 at 09:03 PM +0200, Michael Biebl wrote:
> Am 10.10.18 um 09:37 schrieb Guillem Jover:
> > Hah, this is already almost implemented. Was planning on finishing the
> > couple of XXX (including setting the envvar) and docs, testing and
> > merging it for 1.19.3 or so (targeted at 1w or 2w from now). :)
> > 
> >   
> > 
> 
> 
> I've compiled a dpkg test package from this branch [1].
> Bill, it would be great if you can install this dpkg package and try it
> along with the attached patch for the udev init script.

I'd be glad to, but that machine is running i686.  Can you make a
32-bit version..?

Bill

Bug#910763: openjpeg2: CVE-2018-18088

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.3.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/1152

Hi,

The following vulnerability was published for openjpeg2.

CVE-2018-18088[0]:
| OpenJPEG 2.3.0 has a NULL pointer dereference for "red" in the
| imagetopnm function of jp2/convert.c

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-18088
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18088
[1] https://github.com/uclouvain/openjpeg/issues/1152

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#910575: ITA: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

[Boyuan Yang]

X-Debbugs-CC: roman.fied...@ait.ac.at markus.wurzenber...@ait.ac.at
Control: tag -1 + moreinfo

Hi Markus,

I noticed your RFS and ITA document. However, it seems that the
original maintainer
(Roman Fiedler) never submitted the RFA or Orphaning bug to declare
that this package is given up for adoption. I think an acknowledgment
from the original maintainer should be necessary.

Dear Roman, could you please send an public email to confirm that you
are willing to have Markus taken over the package maintenance?

If Markus is no longer able to send emails to make confirmation, that
is another situation and needs to be handled differently.

--
Regards,
Boyuan Yang

Bug#910762: uscan: generated git date uses embedded timezone, should use UTC

[Daniel Kahn Gillmor]

Package: devscripts
Version: 2.18.6
Severity: normal
Control: affects -1 publicsuffix

I'd like to use a debian/watch file for the publicsuffix package like
this:

version=4
opts=mode=git,pretty=%cd,date=%Y%m%d.%H%M \
 https://github.com/publicsuffix/list HEAD

however, the publicsuffix package versions are using the UTC form of
the date of the git HEAD, since it's a global project and commits from
around the world.

The above invocation of uscan appears to use the timezone stored in
the git commit message, which produces variable results.

I think the right fix is to change --date=format: to
date=format-local:, like so:

diff --git a/lib/Devscripts/Uscan/git.pm b/lib/Devscripts/Uscan/git.pm
index 1df77c7d..dcfc0154 100644
--- a/lib/Devscripts/Uscan/git.pm
+++ b/lib/Devscripts/Uscan/git.pm
@@ -84,7 +84,7 @@ sub git_search {
 "--git-dir=$self->{downloader}->{destdir}/$self->{gitrepo_dir}",
 'log',
 '-1',
-"--date=format:$self->{date}",
+"--date=format-local:$self->{date}",
 "--pretty=$self->{pretty}"
 ],
 wait_child => 1,


and then also to explicitly set TZ=UTC for the environment of the
spawned git subprocess. (i don't know how to do that with this perl
spawn() subroutine, whose documentation i can't locate right now --
hopefully someone else does!)

I don't think there's any reason to prefer local time in this case --
presumably we want to measure the timestamp based on a universal,
monotonically-increasing clock.

 --dkg


-- Package-specific info:

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

--- ~/.devscripts ---
DEBSIGN_KEYID=0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.6-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.7.0
ii  at  3.1.23-1
ii  curl7.61.0-1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2018.09.30
ii  dput-ng [dput]  1.21
ii  dupload 2.9.2
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-3
ii  gnupg2  2.2.10-3
ii  libdistro-info-perl 0.18
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
ii  libfile-which-perl  1.22-1
pn  libgit-wrapper-perl 
ii  libipc-run-perl 20180523.0-1
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
ii  libmoo-perl 2.003004-1
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.35-2
pn  licensecheck
ii  lintian 2.5.108
ii  man-db  2.8.4-2
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  python3-apt 1.7.0~rc1
ii  python3-debian  0.1.33
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.18.4-2
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2+b1
ii  wget1.19.5-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate   
ii  autopkgtest5.5
pn  bls-standalone 
ii  build-essential12.5
pn  check-all-the-things   
pn  cvs-buildpackage   
ii  devscripts-el  40.1
ii  diffoscope 103
pn  disorderfs 
pn  dose-extra 
pn  duck   
ii  faketime   0.9.7-2.1
pn  gnuplot
ii  gpgv   2.2.10-3
ii  gpgv2  2.2.10-3
pn  

Bug#910761: 389-ds-base: missing dependencies on python modules that dsconf can work

[Vaclav Ovsik]

Package: 389-ds-base
Version: 1.4.0.16-1
Severity: normal

Dear Maintainer,
the package misses dependency on python3-ldap, python3-argcomplete
and python3-lib389. These are needed for dsconf utility to work.
Thanks
-- 
Zito

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages 389-ds-base depends on:
ii  389-ds-base-libs 1.4.0.16-1
ii  acl  2.2.52-3+b1
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.69
ii  ldap-utils   2.4.46+dfsg-5
ii  libc62.27-6
ii  libcrack22.9.2-5.2+b1
ii  libdb5.3 5.3.28+dfsg1-0.2
ii  libevent-2.1-6   2.1.8-stable-4
ii  libicu60 60.2-6
ii  libldap-2.4-22.4.46+dfsg-5
ii  libmozilla-ldap-perl 1.5.3-2+b4
ii  libnetaddr-ip-perl   4.079+dfsg-1+b2
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.39-1
ii  libpam0g 1.1.8-3.8
ii  libpci3  1:3.5.2-1
ii  libperl4-corelibs-perl   0.004-1
ii  libsasl2-2   2.1.27~rc8-1
ii  libsasl2-modules-gssapi-mit  2.1.27~rc8-1
ii  libsensors4  1:3.4.0-4
ii  libsnmp305.7.3+dfsg-3
ii  libsocket-getaddrinfo-perl   0.22-3
ii  libssl1.11.1.1-1
ii  libsystemd0  239-10
ii  libwrap0 7.6.q-27
ii  perl 5.26.2-7+b1
ii  python   2.7.15-3
ii  python3  3.6.6-1
ii  python3-selinux  2.8-1+b1
ii  python3-semanage 2.8-1+b1
ii  python3-sepolicy 2.8-2
ii  systemd  239-10

389-ds-base recommends no packages.

389-ds-base suggests no packages.

-- Configuration Files:
/etc/dirsrv/config/certmap.conf [Errno 13] Permission denied: 
'/etc/dirsrv/config/certmap.conf'
/etc/dirsrv/config/ldap-agent.conf [Errno 13] Permission denied: 
'/etc/dirsrv/config/ldap-agent.conf'
/etc/dirsrv/config/slapd-collations.conf [Errno 13] Permission denied: 
'/etc/dirsrv/config/slapd-collations.conf'
/etc/dirsrv/config/template-initconfig [Errno 13] Permission denied: 
'/etc/dirsrv/config/template-initconfig'
/etc/dirsrv/schema/99user.ldif [Errno 13] Permission denied: 
'/etc/dirsrv/schema/99user.ldif'

-- no debconf information

Bug#910760: paramiko: CVE-2018-1000805: Authentication bypass in auth_handler.py

[Salvatore Bonaccorso]

Source: paramiko
Version: 2.0.0-1
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/paramiko/paramiko/issues/1283

Hi,

The following vulnerability was published for paramiko.

CVE-2018-1000805[0]:
| Paramiko version 2.4.1, 2.3.2, 2.2.3, 2.1.5, 2.0.8, 1.18.5, 1.17.6
| contains a Incorrect Access Control vulnerability in SSH server that
| can result in RCE. This attack appear to be exploitable via network
| connectivity.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1000805
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000805
[1] https://github.com/paramiko/paramiko/issues/1283
[2] 
https://github.com/paramiko/paramiko/commit/56c96a659658acdbb873aef8809a7b508434dcce

Regards,
Salvatore

Bug#910759: devscripts: uscan documentation: git has a "hash" not a "hush"

[Daniel Kahn Gillmor]

Package: devscripts
Version: 2.18.6
Severity: minor
Tags: patch

Attached is a simple documentation fix.

thanks for uscan!

 --dkg

-- Package-specific info:

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

--- ~/.devscripts ---
DEBSIGN_KEYID=0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.6-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.7.0
ii  at  3.1.23-1
ii  curl7.61.0-1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2018.09.30
ii  dput-ng [dput]  1.21
ii  dupload 2.9.2
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-3
ii  gnupg2  2.2.10-3
ii  libdistro-info-perl 0.18
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
ii  libfile-which-perl  1.22-1
pn  libgit-wrapper-perl 
ii  libipc-run-perl 20180523.0-1
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
ii  libmoo-perl 2.003004-1
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.35-2
pn  licensecheck
ii  lintian 2.5.108
ii  man-db  2.8.4-2
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  python3-apt 1.7.0~rc1
ii  python3-debian  0.1.33
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.18.4-2
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2+b1
ii  wget1.19.5-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate   
ii  autopkgtest5.5
pn  bls-standalone 
ii  build-essential12.5
pn  check-all-the-things   
pn  cvs-buildpackage   
ii  devscripts-el  40.1
ii  diffoscope 103
pn  disorderfs 
pn  dose-extra 
pn  duck   
ii  faketime   0.9.7-2.1
pn  gnuplot
ii  gpgv   2.2.10-3
ii  gpgv2  2.2.10-3
pn  how-can-i-help 
pn  libauthen-sasl-perl
ii  libdbd-pg-perl 3.7.4-1
pn  libfile-desktopentry-perl  
pn  libnet-smtps-perl  
pn  libterm-size-perl  
ii  libtimedate-perl   2.3000-2
pn  libyaml-syck-perl  
ii  mailutils [mailx]  1:3.4-1+b1
ii  mozilla-devscripts 0.52
pn  mutt   
ii  openssh-client [ssh-client]1:7.8p1-1
pn  piuparts   
ii  postgresql-client-10 [postgresql-client]   10.5-1
ii  postgresql-client-9.5 [postgresql-client]  9.5.4-3
ii  postgresql-client-9.6 [postgresql-client]  9.6.5-1
ii  quilt  0.65-2
pn  ratt   
ii  reprotest  0.7.8
ii  svn-buildpackage   0.8.7
ii  w3m0.5.3-36+b1

-- no debconf information
From 34f245c53570d9fd83dfa28db7727f314070fc11 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Wed, 10 Oct 2018 15:37:49 -0400
Subject: [PATCH] git uses a hash, not a hush :)

---
 po4a/po/de.po  | 2 +-
 po4a/po/devscripts.pot | 2 +-
 po4a/po/fr.po  | 2 +-
 scripts/uscan.pl   | 2 +-
 4 files changed, 4 insertions(+), 4 

Bug#740893: Prepared an update of this package

[Thomas Goirand]

Hi Ben and the others,

I've prepared an update of this package to the version available at:
https://github.com/jeresig/jquery.hotkeys

Can you please try? Here's how to build

git clone https://salsa.debian.org/js-team/libjs-jquery-hotkeys
cd libjs-jquery-hotkeys
./debian/rules gen-orig-xz
git-buildpackage

Let me know if the new package addresses the issues and can replace the
old one. If it does, I'll upload.

Cheers,

Thomas Goirand (zigo)

Bug#910683: RFS: borgmatic/1.2.7-1 [ITP]

[Johan Fleury]

Le 10/10/2018 à 14:59, Andrej Shadura a écrit :
> Thanks. I’ve done some changes too, you can find them at:
> 
> https://salsa.debian.org/debian/borgmatic/
>

Thank you so much!

I see you uploaded the package to ftp-master so I removed the one on 
mentors.debian.net.
 
> It seems to me you have slightly misunderstood the purpose of branches
> or how they’re used. I think this document may be helpful:
> 
> https://dep-team.pages.debian.net/deps/dep14/
> 

Thank you for the info. I actually didn't know how to work with branches in a 
Debian repository and couldn't find any references.

I'll keep this in mind for my future contributions.

-- 
Johan Fleury
PGP Key ID : 0x5D404386805E56E6



signature.asc
Description: OpenPGP digital signature

Bug#910758: ghostscript: CVE-2018-18073: saved execution stacks can leak operator arrays

[Salvatore Bonaccorso]

Source: ghostscript
Version: 9.25~dfsg-2
Severity: grave
Tags: patch security upstream
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=699927

Hi,

The following vulnerability was published for ghostscript.

CVE-2018-18073[0]:
saved execution stacks can leak operator arrays

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-18073
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18073
[1] https://bugs.ghostscript.com/show_bug.cgi?id=699927
[2] https://bugs.chromium.org/p/project-zero/issues/detail?id=1690
[3] 
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=34cc326eb2c5695833361887fe0b32e8d987741c
[4] https://www.openwall.com/lists/oss-security/2018/10/10/12

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#910757: gnulib: CVE-2018-17942 heap-based buffer overflow

[Markus Koschany]

Package: gnulib
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for gnulib.

CVE-2018-17942[0]:
| The convert_to_decimal function in vasnprintf.c in Gnulib before
| 2018-09-23 has a heap-based buffer overflow because memory is not
| allocated for a trailing '\0' character during %f processing.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-17942
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17942

Patch is available here:

https://github.com/coreutils/gnulib/commit/278b4175c9d7dd47c1a3071554aac02add3b3c35


Please adjust the affected versions in the BTS as needed.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#910756: xul-ext-useragentswitcher: Firefox 60esr breaks user-agent-switcher. Please upgrade to upstream version which works.

[Julien Aubin]

Package: xul-ext-useragentswitcher
Version: 0.7.3-3
Severity: grave
Justification: renders package unusable

Hi,

After upgrade to Firefox 60esr, package user agent switcher is no longer
functional. However there's an upstream release of the component which works
well w/ Firefox 60+.

Could you please upgrade to it ?

Thanks,



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

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

Versions of packages xul-ext-useragentswitcher depends on:
ii  firefox-esr  60.2.2esr-1~deb9u1
ii  iceweasel60.2.2esr-1~deb9u1

xul-ext-useragentswitcher recommends no packages.

xul-ext-useragentswitcher suggests no packages.

-- no debconf information

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

Am 10.10.18 um 09:37 schrieb Guillem Jover:
> Hah, this is already almost implemented. Was planning on finishing the
> couple of XXX (including setting the envvar) and docs, testing and
> merging it for 1.19.3 or so (targeted at 1w or 2w from now). :)
> 
>   
> 


I've compiled a dpkg test package from this branch [1].
Bill, it would be great if you can install this dpkg package and try it
along with the attached patch for the udev init script.

Regards,
Michael


[1] https://people.debian.org/~biebl/dpkg/

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/debian/udev.init b/debian/udev.init
index 9c394bb..73a23f4 100644
--- a/debian/udev.init
+++ b/debian/udev.init
@@ -166,7 +166,7 @@ case "$1" in
 
 log_daemon_msg "Starting $DESC" "$NAME"
 if start-stop-daemon --start --name $NAME --user root --quiet \
---pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then
+--pidfile $PIDFILE --exec $DAEMON --background --make-pidfile --notify-await; then
 # prevents udevd to be killed by sendsigs (see #791944)
 mkdir -p $OMITDIR
 ln -sf $PIDFILE $OMITDIR/$NAME
@@ -220,7 +220,7 @@ case "$1" in
 
 log_daemon_msg "Starting $DESC" "$NAME"
 if start-stop-daemon --start --name $NAME --user root --quiet \
---pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then
+--pidfile $PIDFILE --exec $DAEMON --background --make-pidfile --notify-await; then
 # prevents udevd to be killed by sendsigs (see #791944)
 mkdir -p $OMITDIR
 ln -sf $PIDFILE $OMITDIR/$NAME


signature.asc
Description: OpenPGP digital signature

Bug#910683: RFS: borgmatic/1.2.7-1 [ITP]

[Andrej Shadura]

On Wed, 10 Oct 2018 at 20:51, Johan Fleury  wrote:
>
> Hi Andrej.
>
> Just to let you know, I commit some small changes in my borgmatic respository 
> regarding what you did on pykwalify.
>
> I added a configuration file for gbp and removed "explicit dependencies" in 
> debian/control (to let dh_python manage them).
>
> I also renamed the master branch to debian/master and the upstream/1.2.7 
> branch to upstream/latest (I imported the full upstream history up to the 
> 1.2.7 tag).
>
> Please let me know if something else is missing.

Thanks. I’ve done some changes too, you can find them at:

https://salsa.debian.org/debian/borgmatic/

It seems to me you have slightly misunderstood the purpose of branches
or how they’re used. I think this document may be helpful:

https://dep-team.pages.debian.net/deps/dep14/

-- 
Cheers,
  Andrej

Bug#910707: Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

On Wed, 10 Oct 2018 11:10:38 -0300 Felipe Sateler 
wrote:

> Awesome. This should help a lot.

This is great indeed, thanks Guillem!
I quickly looked at the branch, and noticed a a few typos. Patch attached.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/utils/start-stop-daemon.c b/utils/start-stop-daemon.c
index 07b886b10..0b1449402 100644
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
@@ -621,7 +621,7 @@ daemonize(void)
 		fatal("unable to do first fork");
 	else if (pid) { /* First Parent. */
 		if (notify_await) {
-			/* Wait for a readinnes notification from the second
+			/* Wait for a readiness notification from the second
 			 * child, so that we can safely exit when the service
 			 * is up. */
 			wait_for_notify(notify_fd);
@@ -731,7 +731,7 @@ usage(void)
 "  scheduler (default prio is 4)\n"
 "  -k, --umask change the umask to  before starting\n"
 "  -b, --background  force the process to detach\n"
-"  --notify-awaitwait for a readinnes notification\n"
+"  --notify-awaitwait for a readiness notification\n"
 "  --notify-timeout timeout after  seconds of notify wait\n"
 "  -C, --no-closedo not close any file descriptor\n"
 "  -m, --make-pidfilecreate the pidfile before starting\n"
@@ -1124,7 +1124,7 @@ parse_options(int argc, char * const *argv)
 		{ "iosched",	  1, NULL, 'I'},
 		{ "umask",	  1, NULL, 'k'},
 		{ "background",	  0, NULL, 'b'},
-		{ "notify-away",  0, NULL, OPT_NOTIFY_AWAIT},
+		{ "notify-await", 0, NULL, OPT_NOTIFY_AWAIT},
 		{ "notify-timeout", 0, NULL, OPT_NOTIFY_TIMEOUT},
 		{ "no-close",	  0, NULL, 'C'},
 		{ "make-pidfile", 0, NULL, 'm'},


signature.asc
Description: OpenPGP digital signature

Bug#910755: goobook query raises exception

[Matthew Moore]

Package: goobook
Version: 1.9-14-g71ed97e-1
Severity: important

Dear Maintainer,

After updating goobook, I notice that running $ goobook query ... raises
an exception:

 Traceback (most recent call last):
   File "/usr/bin/goobook", line 11, in 
 load_entry_point('goobook==1.10.dev0', 'console_scripts', 'goobook')()
   File "/usr/share/goobook/goobook/application.py", line 100, in main
 args.func(config, args)
   File "/usr/share/goobook/goobook/application.py", line 142, in do_query
 goobk.query(args.query)
   File "/usr/share/goobook/goobook/goobook.py", line 66, in query
 matching_contacts = sorted(self.__query_contacts(query), key=lambda c: 
c.display_name)
   File "/usr/share/goobook/goobook/goobook.py", line 139, in __query_contacts
 if self.__config.filter_groupless_contacts and not contact.groups:
 AttributeError: 'NoneType' object has no attribute 'groups'

Downgrading goobook fixes the issue.


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

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

Versions of packages goobook depends on:
ii  python3   3.6.6-1
ii  python3-googleapi 1.5.5-1
ii  python3-oauth2client  4.1.2-3
ii  python3-simplejson3.15.0-1+b1

goobook recommends no packages.

goobook suggests no packages.

-- no debconf information

Bug#910683: RFS: borgmatic/1.2.7-1 [ITP]

[Johan Fleury]

Hi Andrej.

Just to let you know, I commit some small changes in my borgmatic respository 
regarding what you did on pykwalify.

I added a configuration file for gbp and removed "explicit dependencies" in 
debian/control (to let dh_python manage them).

I also renamed the master branch to debian/master and the upstream/1.2.7 branch 
to upstream/latest (I imported the full upstream history up to the 1.2.7 tag).

Please let me know if something else is missing.

Regards.

-- 
Johan Fleury
PGP Key ID : 0x5D404386805E56E6



signature.asc
Description: OpenPGP digital signature

Bug#910642: [Pkg-sssd-devel] Bug#910642: New upstream release

[Mathieu Parent (Debian)]

Le mer. 10 oct. 2018 à 19:36, Timo Aaltonen  a écrit :
>
> On 09.10.2018 11:38, Mathieu Parent wrote:
> > Package: libpam-wrapper
> > Version: 1.0.6-1
> > Severity: wishlist
> >
> > Please package the latest upstream version (1.0.7).
> >
> > We need this for Samba selftest.
>
> uploaded, is in NEW because of the python bindings which I forgot to
> upload earlier

Thanks!

-- 
Mathieu Parent

Bug#910734: dpkg-source: please expand @builddeps@ in Testsuite-Triggers

[Antonio Terceiro]

On Wed, Oct 10, 2018 at 07:56:39PM +0200, Guillem Jover wrote:
> Hi!
> 
> On Wed, 2018-10-10 at 15:34:02 +0200, Mattia Rizzolo wrote:
> > Package: dpkg-dev
> > Version: 1.19.1
> > Severity: wishlist
> > X-Debbugs-Cc: debian...@lists.debian.org
> 
> > From to dsc(5):
> >   Testsuite-Triggers: package-list
> >  This  field  declares  the  comma-separated union of all test 
> > dependencies
> >  (Depends fields  in  debian/tests/control  file),  with  all  
> > restrictions
> >  removed, and OR dependencies flattened (that is, converted to separate 
> > AND
> >  relationships), except for binaries generated by this source  package  
> > and
> >  meta-dependencies such as @ or @builddeps@.
> > 
> > That says that the special value @builddeps@ is ignored for the purposes
> > of the generation of this field.
> 
> Ah, I think I might have misunderstood your original issue when
> reported on IRC. I see that the problem is the omission of those
> values from the generated field.
> 
> > Informally talking on IRC revealed the following concerns:
> > 1. duplicating the build-dependencies in the triggers has the potential
> >to bloat the Sources index file even more
> > 2. this could be a job better done by the testing migration software, by
> >e.g. always triggering tests for changing build-dependencies, like it
> >already does for changing direct dependencies
> > 3. it would potentially cause useless test runs for things like changed
> >debhelper or other build tools that unlikely would change the
> >run-time behaviour of the software
> > 
> > IMHO, concerns 1. and 2. could be taken care of by not expanding
> > @builddeps@ inside Testsuite-Triggers, but instead having it copied
> > as-is, and then the testing migration software would expand it while
> > evaluating the triggers.  This would also avoid needless test runs as
> > they would happen as proposed in concern 2. if all packages had their
> > build-dependencies trigger tests (however there is a valid idea here
> > maybe).  I also don't think concern 3. is valid: the extra resources
> > used would hardly matter in my opinion.
> > 
> > 
> > For what my proposal here is concerned, if @builddeps@ end up expanded
> > in Testsuite-Triggers, it should be flattened like the rest of the
> > dependencies listed directly in the Depends field of d/tests/control.
> 
> I think expanding the @ and @builddeps@ markers would not be ideal,
> because that its loses semantic meaning. And makes the job of the
> reader harder, by having to possibly infer (although that might end up
> being wrong), whether the listed dependencies are the ones coming from
> the build-dependencies or from the binary packages or similar.

yeah I don't think dpkg should expand those.

> I think that if we want to expose these, they should just be exposed
> as is, and accepted by any parser. They then can decide whether to
> honor these values or ignore them easily.

yes please.

> This would need someone to hunt down and audit any parser, file bugs
> and block this one on them. Once the parsers have been updated, we
> could make dpkg-source let these through.

A quick look at codesearch¹ does not show any parsers in the archive
so far.

¹ https://codesearch.debian.net/search?q=Testsuite-Triggers


signature.asc
Description: PGP signature

Bug#855251:

[Hannah Justin]

Hello!!

Good day, I'm Hannah Justin , looking for a respectful, honest,
trustworthy and caring someone for a cordial relationship.

Best regard!

Hannah


Ciao!!

Buon giorno, sono Hannah Justin, alla ricerca di un rispetto, onesto,
degno di fiducia e cura qualcuno per una relazione cordiale.

Distinti saluti!

Hannah

Bug#910734: dpkg-source: please expand @builddeps@ in Testsuite-Triggers

[Paul Gevers]

Hi,

On 10-10-18 19:56, Guillem Jover wrote:
>> For what my proposal here is concerned, if @builddeps@ end up expanded
>> in Testsuite-Triggers, it should be flattened like the rest of the
>> dependencies listed directly in the Depends field of d/tests/control.
> 
> I think expanding the @ and @builddeps@ markers would not be ideal,
> because that its loses semantic meaning. And makes the job of the
> reader harder, by having to possibly infer (although that might end up
> being wrong), whether the listed dependencies are the ones coming from
> the build-dependencies or from the binary packages or similar.
> 
> I think that if we want to expose these, they should just be exposed
> as is, and accepted by any parser. They then can decide whether to
> honor these values or ignore them easily.
> 
> This would need someone to hunt down and audit any parser, file bugs
> and block this one on them. Once the parsers have been updated, we
> could make dpkg-source let these through.

britney2 in Debian would only need @builddeps@ (but I don't mind it
being more generic and having @ as well). I'll can fix this soon. I
suppose you would want to just transfer the full set of test
dependencies to Test-Trigger. (Slightly of topic, that would make the
problem of "needs-recommends" also simpler, because then we could
migrate to a @recommends@ syntax and define that properly).

britney2 in Ubuntu is not at all in sync with Debian nowadays, so Ubuntu
needs to be informed and they need to adapt as well.

I don't know of other parsers.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#906016: transition: gjs built with mozjs60

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 10/10/2018 12:41, Simon McVittie wrote:
> On Wed, 10 Oct 2018 at 10:13:32 +0200, Emilio Pozuelo Monfort wrote:
>> On 05/10/2018 10:10, Simon McVittie wrote:
>>> The new mozjs version does not work on s390x, so to make gjs migrate,
>>> we will need to do architecture-specific removals (I'm not sure whether
>>> this should be from testing or unstable) of binaries from at least
>>> [some] source packages
> 
> I assume these removals will need to be requested *after* we have uploaded
> gjs 1.54.x (the branch that uses mozjs60) to unstable, otherwise they
> will just get rebuilt on s390x at their next upload. Is that correct?

Yes.

> When it's time to do those removals, should we be asking the ftp team
> to remove s390x binaries from unstable, or asking the release team to
> remove s390x binaries from testing?

>From unstable against the ftp.debian.org metapackage.

>>> Is there a better way we can deal with packages like gdm3 (which require
>>> gnome-shell at runtime) [...] Perhaps a (slightly spurious) Build-Depends
>>> on gjs?
>>
>> A build-dep would be preferred, either on gjs or gnome-shell or whatever you
>> deem appropriate.
> 
> We've been adding build-dependencies on gjs as our way to stop non-working
> s390x binaries from coming back. Jeremy says he'll NMU the various
> Architecture: any GNOME Shell extensions to add this, if necessary.
> 
>> My only question: is cjs moving to mozjs60 too, so that we can remove 
>> mozjs52?
> 
> Not in the short term. Moving to a new mozjs version is a major change
> that needs to be coordinated with cjs upstream. Unfortunately, cjs
> upstream seem to be refusing to consider any request coming from Debian
> until unrelated (?) bugs are fixed in NetworkManager in stable (if I'm
> understanding correctly). See 
> (trigger warning: hostility towards Debian as a project, and Debian
> maintainers as representatives of Debian).
> 
> libproxy1-plugin-mozjs (a proxy-auto-configuration backend for libproxy)
> was recently reintroduced and also uses mozjs52, although meta-gnome3
> still depends on libproxy1-plugin-webkit instead, for its better security
> support. Laurent, was there a particular reason for reintroducing the
> mozjs plugin while we are discussing a move from mozjs52 to mozjs60,
> and would its addition be OK to revert? It seems that it tends to make
> libproxy crash whenever run by a gjs app in a non-GNOME environment:
> . As with cjs,
> porting libproxy to mozjs60 should happen upstream or not at all.
> 
> policykit-1 in experimental also uses mozjs52, so even if gjs, cjs and
> libproxy are all dealt with somehow (ported or removed, as appropriate),
> I would like to keep mozjs52 in unstable until policykit-1 moves to
> mozjs60 (which, again, should happen upstream or not at all). If gjs,
> cjs and libproxy all stop using mozjs52, then it would be OK to remove
> it from testing, and leave it unstable-only for policykit-1's benefit,
> with an artificial RC bug to stop it from migrating.

Ok. We no longer have mozjs or mozjs24 in sid so I can leave with keeping
mozjs52 if necessary. Obviously if those rdeps can be ported for buster, then
all the better.

Please go ahead.

Emilio

Bug#904316: Any updates to boost 1.67 rebuilds ?

[shirish शिरीष]

Dear Giovanni,

were you able to get any more insight into the boost rebuilds ?

Would be nice to have a update.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#906016: transition: gjs built with mozjs60

[Michael Biebl]

Am 10.10.2018 um 12:41 schrieb Simon McVittie:

> Not in the short term. Moving to a new mozjs version is a major change
> that needs to be coordinated with cjs upstream. Unfortunately, cjs
> upstream seem to be refusing to consider any request coming from Debian
> until unrelated (?) bugs are fixed in NetworkManager in stable (if I'm
> understanding correctly). See 
> (trigger warning: hostility towards Debian as a project, and Debian
> maintainers as representatives of Debian).

I think this refers to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892998
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896818
(why archlinux users go ranting about Debian in this bug reports is
beyond me, but so be it)

Anyway, I've filed stretch-pu bugs for those two issues

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910628
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910629

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

Bug#910754: dnsruby: warning: constant ::TimeoutError is deprecated

[Santiago R.R.]

Source: dnsruby
Severity: normal
Tags: upstream patch

Dear maintainer,

dnsruby uses TimeoutError that was deprecated in ruby2.3. Just requiring
dnsruby produces this warning in stretch (ruby2.3) and sid (ruby2.5):

irb(main):001:0> require "dnsruby"
/usr/lib/ruby/vendor_ruby/dnsruby.rb:413: warning: constant ::TimeoutError 
is deprecate

This was fixed upstream:

https://github.com/alexdalitz/dnsruby/commit/31a2a6b4b533f056c6e18ec9439ba0f65bc6b638

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#910734: dpkg-source: please expand @builddeps@ in Testsuite-Triggers

[Guillem Jover]

Hi!

On Wed, 2018-10-10 at 15:34:02 +0200, Mattia Rizzolo wrote:
> Package: dpkg-dev
> Version: 1.19.1
> Severity: wishlist
> X-Debbugs-Cc: debian...@lists.debian.org

> From to dsc(5):
>   Testsuite-Triggers: package-list
>  This  field  declares  the  comma-separated union of all test 
> dependencies
>  (Depends fields  in  debian/tests/control  file),  with  all  
> restrictions
>  removed, and OR dependencies flattened (that is, converted to separate 
> AND
>  relationships), except for binaries generated by this source  package  
> and
>  meta-dependencies such as @ or @builddeps@.
> 
> That says that the special value @builddeps@ is ignored for the purposes
> of the generation of this field.

Ah, I think I might have misunderstood your original issue when
reported on IRC. I see that the problem is the omission of those
values from the generated field.

> Informally talking on IRC revealed the following concerns:
> 1. duplicating the build-dependencies in the triggers has the potential
>to bloat the Sources index file even more
> 2. this could be a job better done by the testing migration software, by
>e.g. always triggering tests for changing build-dependencies, like it
>already does for changing direct dependencies
> 3. it would potentially cause useless test runs for things like changed
>debhelper or other build tools that unlikely would change the
>run-time behaviour of the software
> 
> IMHO, concerns 1. and 2. could be taken care of by not expanding
> @builddeps@ inside Testsuite-Triggers, but instead having it copied
> as-is, and then the testing migration software would expand it while
> evaluating the triggers.  This would also avoid needless test runs as
> they would happen as proposed in concern 2. if all packages had their
> build-dependencies trigger tests (however there is a valid idea here
> maybe).  I also don't think concern 3. is valid: the extra resources
> used would hardly matter in my opinion.
> 
> 
> For what my proposal here is concerned, if @builddeps@ end up expanded
> in Testsuite-Triggers, it should be flattened like the rest of the
> dependencies listed directly in the Depends field of d/tests/control.

I think expanding the @ and @builddeps@ markers would not be ideal,
because that its loses semantic meaning. And makes the job of the
reader harder, by having to possibly infer (although that might end up
being wrong), whether the listed dependencies are the ones coming from
the build-dependencies or from the binary packages or similar.

I think that if we want to expose these, they should just be exposed
as is, and accepted by any parser. They then can decide whether to
honor these values or ignore them easily.

This would need someone to hunt down and audit any parser, file bugs
and block this one on them. Once the parsers have been updated, we
could make dpkg-source let these through.

Thanks,
Guillem

Bug#910737: dpkg-source -b /path/to/somewhere should not delete somewhere.orig

[Guillem Jover]

Hi!

On Wed, 2018-10-10 at 15:01:37 +0100, Ian Jackson wrote:
> Package: dpkg-dev
> Version: 1.18.25
> Severity: important
> 
> This seems like a potential data loss bug.
> Transcript of repro follows.

Well, this is the documented behavior for source format 1.0 (it does
not apply to newer source formats) which has acted like this since its
introduction in dpkg 1.3.0:

  


Even considering changing this seems too painful, when the easy way
forward is to just switch to one of the new source formats. So I'm
inclined to just close this, as one of the known historic warts of
the 1.0 format.

> I think this is related to #865426.  Note that the orig seems to be
> correctly picked up from dpkg-source's cwd.

That seems unrelated.

Thanks,
Guillem

Bug#910753: apt: Race condition between apt's systemd timers & cloud-init

[Ross Vandegrift]

Package: apt
Version: 1.7.0
Severity: normal

Hello,

When a cloud VM is booted with systemd, the timers for apt's periodic actions
are launched in parallel with cloud-init.  cloud-init does some initial
setup, but it also allows end users to customize the system by e.g.,
installing packages with apt.

Depending on timing, apt-daily can go first and lock the db.  If the update
takes a while, then the db will still be locked when cloud-init tries to
apply the user's customizations.  Since this can happen on the first boot,
there's no clean way for an end-user to ensure that their packages will
install.  There's a useful ubuntu-focused discussion of this at [1].

Would you be open to adding cloud-init.target to the After list on
apt-daily.timer?  If I've understood the issue correctly, this should be
sufficient.  If units can use Before to delay timer triggers, this could be
done on the cloud-init side.  But I've been unable to confirm what systemd
does with that config.

Thanks,
Ross

[1] - 
https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (40, 'unstable'), (30, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2017.7
ii  gpgv2.2.10-2
ii  libapt-pkg5.0   1.7.0
ii  libc6   2.27-6
ii  libgcc1 1:8.2.0-7
ii  libgnutls30 3.5.19-1
ii  libseccomp2 2.3.3-3
ii  libstdc++6  8.2.0-7

Versions of packages apt recommends:
ii  ca-certificates  20170717

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.11-3
ii  dpkg-dev1.19.0.5
ii  gnupg   2.2.10-2
ii  gnupg2  2.2.10-2
ii  powermgmt-base  1.33
ii  synaptic0.84.3

-- no debconf information

Bug#891620: Transition of linphone

[Emilio Pozuelo Monfort]

Control: block -1 with 890606
Control: tags -1 = confirmed

On 10/10/2018 12:53, Bernhard Schmidt wrote:
> Am 02.10.2018 um 18:04 schrieb Emilio Pozuelo Monfort:
> 
> Hi,
> 
>> You are making things way too complicated just to avoid patching one rdep. 
>> The
>> solution here is to propose a good patch for kopete (there's already one 
>> patch
>> proposed upstream but it's not clear if it's good - if it is, then explaining
>> why would be enough).
> 
> The upstream patch was bad, but thankfully Felix Lechner has come up
> with a patch for kopete (current upstream version in experimental) that
> allows building against the updated linphone libraries, see Bug#890606.
> He made the patch against the current upstream, not against the version
> currently in unstable. I've asked the kopete maintainers whether there
> is anything preventing an upload into unstable for this.

Let's do this transition now.

Cheers,
Emilio

Bug#910693: systemd: systemd-networkd.service / network.target does not wait for IPv6LL to make a network device ready

[Michael Biebl]

[CCing the bug report]

Am 10.10.2018 um 01:33 schrieb Michael Pietsch:
> Thanks this solved the problem. I literally searched for hours but not
> once stumbled about the need to use systemd-networkd-wait-online because
> I thought it was about the link-local address and not the
> systemd-networkd itself.

I think the wiki page I referenced explains it rather well.
But improvements to the documentation are always welcome.

> From a user perspective it might help if the man page would explicitly
> say that the network might not be fully configured after this service is
> started and you have to use systemd-networkd-wait-online.service.
> 
> Greeting another Michael :D
> 
> Am 10.10.2018 um 0:44 schrieb Michael Biebl:
>> Am 09.10.18 um 23:33 schrieb mich...@mi-pietsch.de:
>>
>>> The service file is
>>> ```
>>> [Unit]
>>> Description=BIND Domain Name Server
>>> Documentation=man:named(8)
>>> After=network.target systemd-networkd.service network-online.target
>>> Wants=systemd-networkd.service network-online.target network.target
>> Please drop
>> Wants/After=systemd-networkd.service
>> You don't want a dependency on a specific network configuration in your
>> unit files.
>>
>> What you need is to actually make network-online.target delay until the
>> network is configured.
>> You thus most likely want to use
>> systemctl enable systemd-networkd-wait-online.service
>>
>> network-online.target by itself does nothing. It needs services which
>> hook into network-online.target and delay the target until network is
>> configured.
>>
>> 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#910642: [Pkg-sssd-devel] Bug#910642: New upstream release

[Timo Aaltonen]

On 09.10.2018 11:38, Mathieu Parent wrote:
> Package: libpam-wrapper
> Version: 1.0.6-1
> Severity: wishlist
> 
> Please package the latest upstream version (1.0.7).
> 
> We need this for Samba selftest.

uploaded, is in NEW because of the python bindings which I forgot to
upload earlier


-- 
t

Bug#910590: bsd-mailx: error about missing command "jalias"

[Francesco Potortì]

>> $ echo test | mailx pot
>> Unknown command: "jalias"
>> $
>> 
>> The mail is sent, ma an error is signaled
>
>Please check your ~/.mailrc and /etc/mail.rc files. I guess one of them
>contains the "jalias" command... If you remove it or replace with
>"alias", then the error should be gone.

Yes, thanks, that's was it...

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(entrance 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

Bug#910232: transition: postgresql-11

[Emilio Pozuelo Monfort]

tags 910232 confirmed
forwarded 910232 https://release.debian.org/transitions/html/postgresql-11.html

On 03/10/2018 19:28, Christoph Berg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> PostgreSQL 11 RC1 will be released next week, and 11.0 will follow one
> week later if everything goes well. I plan to target unstable with RC1.
> PG 11 is the version that will be released with buster; PG 10 will be
> removed once all packages have been migrated.
> 
> As usual, there should be little release team coordination needed, the
> PostgreSQL team will be doing the necessary sourceful uploads for the
> PostgreSQL module packages.
> 
> Ben file attached.

This has started now, marking it as such.

Cheers,
Emilio

Bug#909000: Thunderbird 60 cannot STILL be at stretch normal repository

[Narcis Garcia]

Stable packages aren't ready for Thunderbird 60 presence.
It's better to wait for better repository consistence before adding this
update.

Bug#903579: basemap: Generate _geoslib.c with Cython 0.28.2 for Python 3.7 transition

[Emilio Pozuelo Monfort]

On Wed, 11 Jul 2018 10:38:51 -0400 Sandro Tosi  wrote:
> control: tags -1 - patch
> 
> On Wed, Jul 11, 2018 at 10:29 AM Bas Couwenberg  wrote:
> >
> > On 2018-07-11 16:23, Sandro Tosi wrote:
> > > On Wed, Jul 11, 2018 at 10:03 AM Bas Couwenberg 
> > > wrote:
> > >> The _geoslib.c file needs to regenerated with a recent Cython to be
> > >> compatible with Python 3.7.
> > >
> > > the attached patch looks it's including only the regenerated files,
> > > wouldnt it be better to b-d on cython and actual regenerate the .c
> > > file at debian package build time?
> >
> > That would be better, but not something I'm willing to spend my time on.
> 
> fair enough, but as is this patch cannot be accepted.

Don't let the perfect be the enemy of good. The patch is fine: your package
already ships a pre-built file, so updating it is a fine solution to fix this
bug and let us move on with the python3 transition. Sure, regenerating it at
build time would be better, but that can be done later if you don't have the
time to do it now. For the time being, this patch is no different than when we
had to manually run autoreconf and ship the results in a patch to get an updated
config.guess, for example.

I'd propose to ship this now and file a bug upstream asking to generate the file
during the build. Then you can drop the patch when that happens (or when they
just update the file to a new version, whichever happens first).

Cheers,
Emilio

Bug#910752: syndie: please make the build reproducible

[Chris Lamb]

Source: syndie
Version: 1.107b-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because it:

  a) Did not call dh_fixperms "correctly" resulting in files under /
 usr/share depending on the current umask

  b) Some .jars were not installed to /usr/bin (is that correct?) with
 a .jar suffix, dh_strip_nondeterminism did not normalise them.

Patch for both issues is attached. Enjoy..


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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/control2018-10-10 18:08:37.731186608 +0100
--- b/debian/control2018-10-10 18:21:31.159937883 +0100
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Masayuki Hatta 
-Build-Depends: debhelper (>= 11), ant, default-jdk, libswt-gtk-3-java, 
libhsqldb-java, i2p-router
+Build-Depends: debhelper (>= 11), ant, default-jdk, libswt-gtk-3-java, 
libhsqldb-java, i2p-router, strip-nondeterminism
 Standards-Version: 4.2.1
 Homepage: http://syndie.i2p2.de
 Vcs-Browser: https://salsa.debian.org/debian/syndie
@@ -20,4 +20,4 @@
  Syndie operates like blogs, newsgroups, and forums.  Authors can post
  messages privately or publicly.  Messages are pushed and pulled to and
  from archive servers, which are hosted in a variety of anonymous and
- non-anonymous networks including I2P, Tor, and Freenet.
\ No newline at end of file
+ non-anonymous networks including I2P, Tor, and Freenet.
--- a/debian/rules  2018-10-10 18:08:37.731186608 +0100
--- b/debian/rules  2018-10-10 18:20:16.995484168 +0100
@@ -19,7 +19,7 @@
 
 override_dh_auto_build:
ant stub-jars-debian -Dlib.dir=/usr/share/java 
-Di2p.jar=/usr/share/i2p/lib/i2p.jar -Djavac.version=1.8
-   chmod 755 pkg-temp/bin/*.jar
+   strip-nondeterminism --verbose pkg-temp/bin/*.jar
mv pkg-temp/bin/syndie-cli.jar pkg-temp/bin/syndie-cli
mv pkg-temp/bin/syndie.jar pkg-temp/bin/syndie
mv pkg-temp/bin/syndie-desktop.jar pkg-temp/bin/syndie-desktop
@@ -34,4 +34,5 @@
   $(CURDIR)/debian/syndie/usr/share/doc/syndie/html
 
 override_dh_fixperms:
-   dh_fixperms -Xsyndie.jar -Xsyndie-cli.jar -Xsyndie-desktop.jar
+   dh_fixperms
+   chmod 755 $(CURDIR)/debian/syndie/usr/share/syndie/*.jar

Bug#796257: dpkg-dev: dpkg-source does not respect permissions from tarball when umask is set to 0002

[Ian Jackson]

Stéphane writes:
> Concerning #390915, I don't agree with the way the original (LP
> #51468) bug was fixed.  Again, plain tar behaves correctly IMHO.

Sorry that I didn't reply at the time.  I found this bug again now.

I still think that the fix in #390915 is correct.  Unpacking source
code definitely ought to respect the user's umask.  Otherwise the
source will not be writeable to their collaborators, as intended.

That tar (often, depending on options) behaves differently is because
tar is trying to be several different kinds of utility in one.

I think a package build where the output file permissions depend on
the user's umask is a buggy package build.  (And this is not just a
reproducibility issue.)  This is what we have dh_fixperms for: to
manage the difference between source file and intermediate build
product permissions (which should respect the user's umask) and 
binary-package-in-preparation permissions (which need to be those
intended for the output package).

Does that make sense ?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#910751: python3-tinycss: fails to build python3 extension for python3.7

[Emilio Pozuelo Monfort]

Package: python3-tinycss
Version: 0.4-1
Severity: important

Hi,

Your package attempts to build the python3 extension for python3.7 (which
is a supported python3 version). However, that fails as the shipped .c
file was built with an old version of cython that didn't support 3.7:

building 'tinycss.speedups' extension
creating build/temp.linux-i386-3.7
creating build/temp.linux-i386-3.7/tinycss
i686-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-I/usr/include/python3.7m -c tinycss/speedups.c -o 
build/temp.linux-i386-3.7/tinycss/speedups.o
tinycss/speedups.c: In function '__Pyx__ExceptionSwap':
tinycss/speedups.c:6591:24: error: 'PyThreadState {aka struct _ts}' has no 
member named 'exc_type'; did you mean 'curexc_type'?
 tmp_type = tstate->exc_type;
^~~~
curexc_type
[...]
***
WARNING: The extension could not be compiled, speedups are not enabled.
Failure information, if any, is above.
Retrying the build without the Cython extension now.
***

It'd be good to get speedups.c regenerated with a newer cython, or
even better to regenerate it during the build.

Cheers,
Emilio

Full log: 
https://buildd.debian.org/status/fetch.php?pkg=python-tinycss=i386=0.4-1%2Bb3=1530354240=0

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-tinycss depends on:
ii  libc62.27-5
ii  python3  3.6.6-1

python3-tinycss recommends no packages.

Versions of packages python3-tinycss suggests:
pn  python-tinycss-doc  

Bug#910750: pycorrfit: build-deps on libpython3-all-dev but only builds for one python3 version

[Emilio Pozuelo Monfort]

Package: pycorrfit
Version: 1.1.4+dfsg-1
Severity: important

Hi,

pycorrfit builds its extensions for the default python3 version, which is quite
alright given pycorrfit is an app and not a public module. However, there 
doesn't
seem to be a need to build-dep on libpython3-all-dev. Just python3-dev (which
is already a build-dep) would be enough.

Thus please drop the libpython3-all-dev, that should avoid false positives and
unnecessary rebuilds when adding or removing python3 versions to the supported
list.

Thanks,
Emilio

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pycorrfit depends on:
ii  libc6   2.27-5
ii  python  2.7.15-3
pn  python-lmfit
pn  python-matplotlib   
pn  python-numpy
pn  python-scipy
pn  python-wxgtk3.0 
ii  python-yaml 3.12-1+b2
ii  python3 3.6.6-1
pn  python3-lmfit   
pn  python3-matplotlib  
pn  python3-numpy   
pn  python3-scipy   
pn  python3-simplejson  
pn  python3-sympy   
pn  python3-wxgtk4.0
ii  python3-yaml3.12-1+b2

Versions of packages pycorrfit recommends:
ii  dvipng  1.15-1
pn  python-sympy
pn  texlive-latex-base  
pn  texlive-science 

pycorrfit suggests no packages.

Bug#645157: dpkg-source: handling of symlinks to external files

[Ian Jackson]

I stumbled across this bug.

Paul writes:
> And more fundamentally, dpkg-dev should never extract or follow
> symlinks that point outside the source package. That includes all
> absolute ones and any relative ones with too many .. in their link
> target. Even if dpkg-source doesn't write to them during unpack,
> they could have some other impact on the user's system if they
> access them thinking that since Debian source packages are
> self-contained they should be safe.

I agree with this.

Raphaël writes:
> dpkg-source delegates extraction to tar. It can't easily cherry-pick
> what to extract...

It could search the tree for bad links after extraction but before
exiting status 0.

Or we could request that tar grow an option like rsync's --safe-links.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#897725: auto-gdbm transition

[Dmitry Bogatov]

control: tag -1 patch

Hello!

This bug blocks auto-gdbm transition.
I prepared and uploaded NMU, debdiff is below.


diff -Nru courier-authlib-0.68.0/debian/changelog 
courier-authlib-0.68.0/debian/changelog
--- courier-authlib-0.68.0/debian/changelog 2017-09-11 21:06:17.0 
+
+++ courier-authlib-0.68.0/debian/changelog 2018-10-10 16:35:27.0 
+
@@ -1,3 +1,11 @@
+courier-authlib (0.68.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax checks for C++ symbols (Closes: #897725)
+  * Update Vcs-* fields in debian/control
+
+ -- Dmitry Bogatov   Wed, 10 Oct 2018 16:35:27 +
+
 courier-authlib (0.68.0-4) unstable; urgency=medium
 
   [ Matthias Klose ]
diff -Nru courier-authlib-0.68.0/debian/control 
courier-authlib-0.68.0/debian/control
--- courier-authlib-0.68.0/debian/control   2017-08-06 20:10:56.0 
+
+++ courier-authlib-0.68.0/debian/control   2018-10-10 16:35:27.0 
+
@@ -20,8 +20,8 @@
pkg-config,
procps
 Homepage: https://www.courier-mta.org/
-Vcs-Git: https://anonscm.debian.org/git/collab-maint/courier-authlib.git
-Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/courier-authlib.git
+Vcs-Git: https://salsa.debian.org/debian/courier-authlib.git
+Vcs-Browser: https://salsa.debian.org/debian/courier-authlib
 
 Package: courier-authlib
 Architecture: any
diff -Nru courier-authlib-0.68.0/debian/rules 
courier-authlib-0.68.0/debian/rules
--- courier-authlib-0.68.0/debian/rules 2017-09-11 20:43:47.0 +
+++ courier-authlib-0.68.0/debian/rules 2018-10-10 16:35:27.0 +
@@ -15,8 +15,6 @@
 # package maintainers to append LDFLAGS
 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
-export DPKG_GENSYMBOLS_CHECK_LEVEL=4
-
 # the build captures $SHELL, hard-wire to "/bin/sh"
 export CONFIG_SHELL=/bin/sh
 




pgp8AmKfHeDpd.pgp
Description: PGP signature

Bug#854281: Crash because of NULL pointer dereference in `pick_next_task_fair`

[Robin Thoni]

Hi,

I also encountered this bug randomly three times on the last 2 months,
on two servers (Linux x 3.16.0-6-amd64 #1 SMP Debian
3.16.56-1+deb8u1 (2018-05-08) x86_64 GNU/Linux), same hardware (I can
share if needed), mainly running Apache, Docker and VirtualBox
(Windows guests). They are running since February, but this bug only
happened recently.

Is it still happening on Debian Stretch with a 4.x kernel?

Thanks.

-- 
Robin THONI
NVIDIA

Bug#909914: ejabberd: Starting ejabberd via systemd, epmd does not honor /etc/default/ejabberd

[Philipp Huebner]

Hi,

thanks for bringing this up!

Am 29.09.18 um 23:38 schrieb Matt Marjanovic:
> In particular, this means that the ERL_EPMD_ADDRESS parameter is ignored.
> This is typically used to reduce the attack surface of epmd by telling it
> to only listen on localhost.  As installed, epmd will listen on all 
> interfaces.
> 
> This is to some degree an issue for the erlang-base package, which provides
> epmd
> and its systemd units and *should* provide a config option to restrict epmd to
> listening on localhost only.  However, it is the ejabberd package that 
> provides
> the /etc/default/ejabberd file.

I will patch out the ERL_EPMD_ADDRESS part of /etc/default/ejabberd, the
rest should be fine as it does not concern epmd but the Erlang VM that
ejabberd is running in.

I will also contact the Erlang maintainer.


Best wishes,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#909000: Thunderbird 60 cannot be at stretch normal repository

[Daniel Kahn Gillmor]

On Wed 2018-10-10 17:30:33 +0200, Narcis Garcia wrote:
> The good solution for this is to move Thunderbird 60 to
> stretch-backports instead of being at normal repository.
>
> Normal users will keep current Enigmail 2:1.9 , current Thunderbird 1:52
> and current GnuPG 2.1 and not unstable repositories.
>
> Other users will be allowed to use stretch-backports to upgrade to
> Thunderbird 1:60 , Enigmail 2:2.2 and GnuPG 2.2 when all available.
>
> No packages break, no Enigmail loss for unexperienced users.

i haven't heard anyone from debian say that they're up for
maintaining/supporting thunderbird 52 in stretch.  do you know anyone
who is volunteering for that task?

if there isn't anyone, then moving to TB 60 in stretch is probably
pretty important, while it also requires all the rest of the maintenance
work described upthread.

Software maintenance within the context of an active network and complex
upstreams is hard :(

--dkg

Bug#910428: Acknowledgement (linux-image-4.18.0-2-amd64: linux 4.18.10 drastically increases power consumption for polaris on idle)

[at46]

Bug is fixed with 4.18.13

Bug#903698: sphinxbase: build appears broken for multiple python3 versions

[Samuel Thibault]

Emilio Pozuelo Monfort, le mer. 10 oct. 2018 18:27:18 +0200, a ecrit:
> debian/tmp/usr/lib/python3* usr/lib
> 
> That is causing both the python3.6/ and python3.7/ contents to be moved to
> usr/lib,

D'oh!

Thanks for the fix, I have pushed it to our tree.

Samuel

Bug#910749: ITP: r-cran-iso -- GNU R functions to perform isotonic regression

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-iso
  Version : 0.0
  Upstream Author : Rolf Turner 
* URL : https://cran.r-project.org/package=Iso
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R functions to perform isotonic regression
 This GNU R package provides linear order and unimodal order
 (univariate) isotonic regression; bivariate isotonic regression
 with linear order on both variables.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-iso
This package is needed to close bug #901767.

Bug#903698: sphinxbase: build appears broken for multiple python3 versions

[Emilio Pozuelo Monfort]

Control: reassign -1 src:sphinxbase

On Tue, 25 Sep 2018 23:55:56 +0200 Andreas Beckmann  wrote:
> Followup-For: Bug #903698
> 
> There is still something broken in python3-sphinxbase:
> 
> The package ships
>   /usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
> ans the dangling symlink
>   /usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so -> 
> _sphinxbase.so.0.0.0

It's still broken because this is a packaging bug in sphinxbase.
debian/python3-sphinxbase.install has:

debian/tmp/usr/lib/python3* usr/lib

That is causing both the python3.6/ and python3.7/ contents to be moved to
usr/lib, causing files with the same name (most or all) to be overwritten,
and ending up with this content after the dh_python3 magic:

./usr/lib/python3.6/site-packages/sphinxbase/_sphinxbase.so -> 
_sphinxbase.so.0.0.0
./usr/lib/python3/dist-packages/sphinxbase/__init__.py
./usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-37m-i386-linux-gnu.so
./usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.so.0.0.0
./usr/lib/python3/dist-packages/sphinxbase/sphinxbase.py

Note how there's only one shared module, because the rename happens at
dh_python3 and before that, both the 3.6 and the 3.7 had the same name and one
overwrote the other. With the attached debdiff, we keep python3.6 and python3.7
as they should be, which allows dh_python3 to do its job, ending up with:

./usr/lib/python3/dist-packages/sphinxbase/__init__.py
./usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-36m-x86_64-linux-gnu.so
./usr/lib/python3/dist-packages/sphinxbase/_sphinxbase.cpython-37m-x86_64-linux-gnu.so
./usr/lib/python3/dist-packages/sphinxbase/sphinxbase.py

And this gives the proper dependencies:

Depends: [...], python3 (<< 3.8), python3 (>= 3.6~), python3:any (>= 3.0~)

Cheers,
Emilio
diff -Nru sphinxbase-0.8+5prealpha+1/debian/changelog 
sphinxbase-0.8+5prealpha+1/debian/changelog
--- sphinxbase-0.8+5prealpha+1/debian/changelog 2018-04-28 11:53:25.0 
+0200
+++ sphinxbase-0.8+5prealpha+1/debian/changelog 2018-10-10 12:38:01.0 
+0200
@@ -1,3 +1,10 @@
+sphinxbase (0.8+5prealpha+1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix python3 bindings.
+
+ -- Emilio Pozuelo Monfort   Wed, 10 Oct 2018 12:38:01 +0200
+
 sphinxbase (0.8+5prealpha+1-2) unstable; urgency=medium
 
   * Make testsuite just fail on big-endian archs, which just don't work yet.
diff -Nru sphinxbase-0.8+5prealpha+1/debian/python3-sphinxbase.install 
sphinxbase-0.8+5prealpha+1/debian/python3-sphinxbase.install
--- sphinxbase-0.8+5prealpha+1/debian/python3-sphinxbase.install
2018-04-28 11:41:31.0 +0200
+++ sphinxbase-0.8+5prealpha+1/debian/python3-sphinxbase.install
2018-10-10 12:37:44.0 +0200
@@ -1 +1 @@
-debian/tmp/usr/lib/python3* usr/lib
+debian/tmp/usr/lib/python3*
diff -Nru sphinxbase-0.8+5prealpha+1/debian/python-sphinxbase.install 
sphinxbase-0.8+5prealpha+1/debian/python-sphinxbase.install
--- sphinxbase-0.8+5prealpha+1/debian/python-sphinxbase.install 2015-09-19 
16:35:52.0 +0200
+++ sphinxbase-0.8+5prealpha+1/debian/python-sphinxbase.install 2018-10-10 
12:37:58.0 +0200
@@ -1 +1 @@
-debian/tmp/usr/lib/python2* usr/lib
+debian/tmp/usr/lib/python2*

Bug#910748: lombok: Fails to build with openjdk-11

[Jeremy Bicha]

Source: lombok
Version: 1.16.22-3
Severity: important
Tags: ftbfs

lombok fails to build on unstable using the java-common 0.69 packages
from experimental that default to openjdk-11.

Build log
---
https://launchpad.net/~jbicha/+archive/ubuntu/arch/+build/15525598

Build log excerpt
---
[ivy:compile] /<>/src/core/lombok/javac/JavacAST.java:538:
error: no suitable method found for
error(DiagnosticPosition,String,String)
[ivy:compile] log.error(pos, "proc.messager", message);
[ivy:compile]   ^
[ivy:compile] method AbstractLog.error(String,Object...) is not applicable
[ivy:compile]   (argument mismatch; DiagnosticPosition cannot be
converted to String)
[ivy:compile] method
AbstractLog.error(DiagnosticFlag,DiagnosticPosition,Error) is not
applicable
[ivy:compile]   (argument mismatch; DiagnosticPosition cannot be
converted to DiagnosticFlag)
[ivy:compile] method AbstractLog.error(int,String,Object...) is
not applicable
[ivy:compile]   (argument mismatch; DiagnosticPosition cannot be
converted to int)
[ivy:compile] method AbstractLog.error(DiagnosticFlag,int,Error)
is not applicable
[ivy:compile]   (argument mismatch; DiagnosticPosition cannot be
converted to DiagnosticFlag)
[ivy:compile] /<>/src/core/lombok/javac/JavacAST.java:546:
error: incompatible types: DiagnosticPosition cannot be converted to
LintCategory
[ivy:compile] log.warning(pos, "proc.messager", message);
[ivy:compile]^
[ivy:compile] /<>/src/core/lombok/javac/JavacAST.java:550:
error: incompatible types: DiagnosticPosition cannot be converted to
LintCategory
[ivy:compile] log.mandatoryWarning(pos, "proc.messager", message);
[ivy:compile] ^
[ivy:compile] /<>/src/core/lombok/javac/JavacAST.java:554:
error: no suitable method found for
note(DiagnosticPosition,String,String)
[ivy:compile] log.note(pos, "proc.messager", message);
[ivy:compile]   ^
[ivy:compile] method AbstractLog.note(Note) is not applicable
[ivy:compile]   (actual and formal argument lists differ in length)
[ivy:compile] method AbstractLog.note(DiagnosticPosition,Note) is
not applicable
[ivy:compile]   (actual and formal argument lists differ in length)
[ivy:compile] method AbstractLog.note(int,Note) is not applicable
[ivy:compile]   (actual and formal argument lists differ in length)
[ivy:compile] method AbstractLog.note(JavaFileObject,Note) is not applicable
[ivy:compile]   (actual and formal argument lists differ in length)
[ivy:compile] Note: Some messages have been simplified; recompile with
-Xdiags:verbose to get full output
[ivy:compile] 4 errors


Thanks,
Jeremy Bicha

Bug#910747: python3-grapefruit: short package description mentions Python2 instead of Python 3

[Beatrice Torracca]

Package: python3-grapefruit
Severity: minor

Hi!

the short package description of the package python3-grapefruit now
contains "(Python2)". I imagine that is the wrong Python version since
the package is called python3-grapefruit (and not python-grapefruit).

Thanks,

beatrice

Bug#908564: Migration of dwarves-dfsg to samba.d.o

[Domenico Andreoli]

On Mon, Sep 24, 2018 at 8:40 AM Domenico Andreoli  wrote:
> On September 23, 2018 9:46:45 AM GMT+02:00, Thomas Girard 
>  wrote:
> >Hello,

Hi Thomas,

> >Sorry for the late reply. I have been quite busy for a while but now my 
> >available bandwidth should be hopefully better.

how is it going? ;)

cheers,
Domenico

Bug#907829: p4est: FTBFS on single CPU machines (?)

[Chris Lamb]

Adrian Bunk wrote:

> You are being a complete asshole when you are trying to use RC bugs for 
> forcing other people to spend any time *ever* on your pet project.

Whatever the technical merits here, calling a colleague an "asshole" in
any context is completely inappropriate and moreover behaviour
unbecoming of a Debian Developer.

Adrian, I cordially invite you to withdraw your statement.


Best wishes,

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

Bug#901368: chromium-browser: build-depends on GCC 6

[Emilio Pozuelo Monfort]

Control: severity -1 serious

On Tue, 12 Jun 2018 08:35:14 +0200 Emilio Pozuelo Monfort  
wrote:
> Source: chromium-browser
> Version: 66.0.3359.26-2
> Severity: serious
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: gcc-6-rm
> 
> Hi,
> 
> chromium build-depends on GCC 6. We now have GCC 7 (default) and GCC 8
> in the archive, so please make your package build with a newer
> compiler (preferably the default one) again, since we'd like to
> remove GCC 6 from testing before the buster release.

Bumping this to serious. chromium is the only GCC 6 rdep in testing (pending
firefox-esr migration), so please try to move it to GCC 7 or 8 for buster.

Cheers,
Emilio

Bug#910746: orca: Support configuration migration

[Samuel Thibault]

Package: orca
Version: 3.30.0-1
Tags: a11y upstream
Owner: b...@hypra.fr
User: b...@hypra.fr
Usertags: hypra colomban
Severity: wishlist
Forwarded: https://gitlab.gnome.org/GNOME/orca/issues/21

As reported upstream:

“
For instance, https://gitlab.gnome.org/GNOME/orca/merge_requests/17 changes the 
orca key binding option content, which would thus need to automatically migrate 
old configurations to the new option name for capslock.

This is a more general problem which we should implement more generally.
”


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages orca depends on:
ii  gir1.2-glib-2.01.58.0-1
ii  gir1.2-gtk-3.0 3.24.1-2
ii  gir1.2-pango-1.0   1.42.4-3
ii  gir1.2-wnck-3.03.30.0-1
ii  gsettings-desktop-schemas  3.28.1-1
ii  python33.6.6-1
ii  python3-brlapi 5.6-5
ii  python3-cairo  1.16.2-1+b1
ii  python3-gi 3.30.1-1
ii  python3-louis  3.7.0-1
ii  python3-pyatspi2.30.0+dfsg-1
ii  python3-speechd0.8.8-7
ii  speech-dispatcher  0.8.8-7

Versions of packages orca recommends:
pn  python3-gst-1.0  
ii  xbrlapi  5.6-5

orca suggests no packages.

-- no debconf information

-- 
Samuel
 > Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me
 > disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que
 > vous teniez vous même la tronçonneuse" (traduction libre)
 NC in Guide du linuxien pervers : "Bien configurer sa tronçonneuse."

Bug#910740: dgit: please enable make --include-dirty work with --build-products-dir

[Ian Jackson]

Mattia Rizzolo writes ("Bug#910740: dgit: please enable make --include-dirty 
work with --build-products-dir"):
> Package: dgit
> Version: 7.1
> Severity: wishlist
> Control: block -1 by 910737 865426
> 
> As requested in Bug#910725 ("something eats ../foo_1.2.3.orig.tar.gz")
> I'm opening this bug here to track the re-enabling of this feature,
> after the relevant dpkg-source bugs have been fixed.

Thanks.  For my reference, the place that needs to be fixed is
build_source, by the error message about this not being supported.

My proposed implemntation is for dgit run dpkg-source in the bpd,
passing the absolute path of $maindir as the argument to -b.

Ian.

Bug#910745: thunderbird 60 breaks enigmail 2.1 and gnupg 2.1

[Narcis Garcia]

Package: thunderbird
Version: 1:60.0-3~deb9u1
Severity: serious

thunderbird:
  Breaks: enigmail (< 2:2~) but 2:1.9.9-1~deb9u1 is installed
  Breaks: xul-ext-sogo-connector (< 31.0.5-2~) but 31.0.3-3 is installed

thunderbird >= 1:60 should be at stretch-backports instead of stretch
repository, and there will be possible to introduce higher enigmail and
gnupg versions.

This is related to bug report:
https://bugs.debian.org/909000

Bug#909000: Thunderbird 60 cannot be at stretch normal repository

[Narcis Garcia]

The good solution for this is to move Thunderbird 60 to
stretch-backports instead of being at normal repository.

Normal users will keep current Enigmail 2:1.9 , current Thunderbird 1:52
and current GnuPG 2.1 and not unstable repositories.

Other users will be allowed to use stretch-backports to upgrade to
Thunderbird 1:60 , Enigmail 2:2.2 and GnuPG 2.2 when all available.

No packages break, no Enigmail loss for unexperienced users.

-- 


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.