Bug#883229: ibus: Enable emoji dictionary

[Osamu Aoki]

Thanks

I have a new package contain emoji database

It's stack in new

Maybe your approach is a good stop gap


2017/12/01 12:03 "Jeremy Bicha" :

Source: ibus
Version: 1.5.14-3
Severity: wishlist
Tags: patch

I'm attaching a patch in my follow up email to enable the emoji
dictionary. I'm not really sure how to make use of it though.

Thanks,
Jeremy Bicha

Bug#824827: mixmaster: hold on..

[Anonymous]

Package: mixmaster
Version: 3.0.0-8.1
Followup-For: Bug #824827

> I know that. What you fail to realise is that the mixmaster
> *specification* makes no mention of 4k keys!

Then why would you claim it's not a bug for mixmaster to write packets
for out-of-spec hosts?  If a host doesn't conform to mixmaster specs,
then it's not a mixmaster node, thus mixmaster shouldn't be talking to
it.  You might as well design it to create messages for FTP servers
(which are also non-compliant but equally functional as the current
state).

Bug#883239: Pending fixes for bugs in the maven-debian-helper package

[pkg-java-maintainers]

tag 883239 + pending
thanks

Some bugs in the maven-debian-helper package are closed in revision
5ffe0e850ad36d9c749f6936cbdae35f31289004 in branch 'master' by
Christopher Hoskin

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/maven-debian-helper.git/commit/?id=5ffe0e8

Commit message:

Fix "quilt and mh_patchpom sequence" by inserting extra calls to
mh_(un)patchpoms in share/perl/maven.pm (Closes: #883239)

Bug#225651: December

[Andreas Tille]

Hi everybody,

its really that simple to close a bug which I'm doing here without a line
of code closing my first bug in this mail after having checked that zstd
has hit backports and adding "882244-d...@bugs.debian.org" to the list of
receivers of this mail.

Not all bugs are *that* simple to solve but **everybody** is kindly
invited to head for the simple ones right now.

On Thu, Nov 30, 2017 at 12:44:39PM +0100, Thorsten Alteholz wrote:
> Hi everybody,
> 
> this time of the year has come again and in order to carry on a tradition
> (it is the seventh time this year), I want to remind everybody of our
> combined efforts to take care of some poor souls.
> 
> The days are closing in, the year is drawing to an end and we should think
> of all those, that are not around with their own kind. Again, during the
> last few months, lots of volunteers all around the world tracked down those
> poor souls and put their cases in the database. We should take care of those
> needy. This year, there are about 180 cases which are relevant to Debian
> Med[1] (this time 21 are serious[2]). So please feel pity for them and allow
> the transition of as many as possible poor souls to their final destination,
> the retirement community in the Archive. Maybe some of the "won't fix" can
> be resolved as well.

We should definitely try to fix the serious ones - even if they are mostly
not that simple.
 
> Furthermore I would like to mention another page[3] with lots of information
> about Debian Med packages. Besides the list of RC bugs you can also see
> packages that can not be built on a Debian architecture, packages that are
> not allowed to migrate from unstable to testing (and thus won't be included
> in the next release) and packages with a new upstream version. I think those
> packages need some care as well.

Definitely.
 
> As soon as I get the notice of a closed case I will record that in our
> Advent calendar[4]. In contrast to normal calendars, let us fill this
> special one with lot s of good deeds. Maybe we can hide at least one number
> of a closed case behind every door.
> 
> I would like to mention #225651 [5] here, as this seems to be the oldest one
> that needs some help (at least a proper closing).

Pinging Aaron explicitly to refresh his statement given several years ago.
 
> Have fun,
> Thorsten

Thanks for the fun and all your work

Andreas. 
 
> [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint=debian-med-packaging%40lists.alioth.debian.org=no=yes=yes=fixed=done
> [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint=debian-med-packaging%40lists.alioth.debian.org=no=done=critical=grave=serious
> [3]http://udd.debian.org/dmd.cgi?email=debian-med-packag...@lists.alioth.debian.org
> [4]http://debian-med.alteholz.de/advent-2017
> [5]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225651
> 

-- 
http://fam-tille.de

Bug#850670: RFS: rpyc/3.4.4-1 [ITP]

[Carl Suster]

retitle ! RFS: rpyc/3.4.4-1 [ITP]
thanks

I've updated to a recent upstream release and modern packaging.

You an find the new version on mentors:

https://mentors.debian.net/package/rpyc

dget -x https://mentors.debian.net/debian/pool/main/r/rpyc/rpyc_3.4.4-1.dsc

Cheers,
Carl

Bug#863704: duplicate of 843021

[Paolo Greppi]

sorry I did not notice this earlier !
https://bugs.debian.org/843021

Paolo

Bug#883238: spice-vdagent: CVE-2017-15108: Improper validation of xfers->save_dir in vdagent_file_xfers_data()

[Salvatore Bonaccorso]

Source: spice-vdagent
Version: 0.17.0-1
Severity: important
Tags: patch security upstream

Hi,

the following vulnerability was published for spice-vdagent.

CVE-2017-15108[0]:
|spice-vdagent: Improper validation of xfers->save_dir in
|vdagent_file_xfers_data()

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-15108
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15108
[1] 
https://cgit.freedesktop.org/spice/linux/vd_agent/commit/?id=8ba174816d245757e743e636df357910e1d5eb61

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#883239: maven-debian-helper: quilt and mh_patchpom sequence

[Christopher Hoskin]

Package: maven-debian-helper
Version: 2.2.7
Severity: normal

Dear Maintainer,

In order to achieve a successful build, it is sometimes it is necessary to 
modify a pom.xml file in a way which cannot be achieved purely through using 
mh_patchpoms. In these cases, one falls back on using quilt as the standard 
mechanism for patching an upstream source. See for example:

https://anonscm.debian.org/cgit/pkg-java/dropwizard-metrics.git/tree/debian/patches/drop-graphite-rabbitmq-support.patch?id=f2a998aeeaa7e4e3f209a37cc79fe0a168281561

However, this now means that there are two mechanisms modifying the same file, 
quilt and mh_(un)patchpom, which can be confusing.

In particular, I would normally expect running debuild followed by debclean in 
an unpacked source package to build the package and then return the package to 
its original state. However, this is not what happens at the moment:

Sequence during debuild:

dpkg-source --before-build dropwizard-metrics
  (This applies the quilt patch to the original pom.xml)
mh_unpatchpoms -plibdropwizard-metrics-java
  (This shouldn't do anything, as there are no mh patched poms at this stage)
mh_patchpoms -plibdropwizard-metrics-java --debian-build --keep-pom-version 
--maven-repo=/home/mans0954/src/pkg-java/dropwizard-metrics/debian/maven-repo
  (This copies the quilt patched pom.xml to pom.xml.save and then writes a mh 
modified pom to pom.xml)
dpkg-source --after-build dropwizard-metrics
  (This then attempts to unapply the quilt patch from the mh modified pom.xml, 
but not pom.xml.save.)

Sequence during debclean

mh_unpatchpoms -plibdropwizard-metrics-java
  (This moves pom.xml.save to pom.xml, so that pom.xml no longer has the mh 
modifications, but still has the quilt patch applied. Running "quilt pop -a" 
has no effect as quilt has previously unapplied the patch to the mh-modified 
pom.xml which has just been over-written))

This problem, workarounds and possible fixes have been discussed on the 
debian-java list, and a fix proposed:

https://lists.debian.org/debian-java/2017/11/msg00030.html

Christopher Hoskin

Bug#883236: scamp: segfault in load_field() at field.c:343

[Roy Clark (kralcyor)]

Package: scamp
Version: 2.0.4-4
Severity: normal

Dear Maintainer,

1. Reproduce

$ scamp test-scamp-segfault.cat

> WARNING: scamp.conf not found, using internal defaults


> WARNING: This executable has been compiled using a version of the
> ATLAS library without support for multithreading. Performance will be
> degraded.

- SCAMP 2.0.4 started on 2017-12-01 at 13:34:33 with 2 threads

- 1 inputs:
> Examining Catalog test-scamp-segfault.cat
Segmentation fault


Though any .cat accepted by scamp should works, I attached the test sample
"test-scamp-segfault.cat" in this Email.

The attachment "scamp-backtrace.txt" is a gdb backtrace obtained by
running following command:

$ gdb --batch -ex "r test-scamp-segfault.cat" -ex "bt" -ex "bt full" -ex 
"thread apply all bt full" -ex "quit" /usr/bin/scamp &> scamp-backtrace.txt 

2. Possible cause

This problem may be caused by that the questioned line is undefined
behaviour.

When build the package with gcc option -Wsequence-point enabled(add
"export DEB_CFLAGS_MAINT_APPEND = -Wsequence-point" to debian/rules),
there is the following warning:

gcc -DHAVE_CONFIG_H -I. -I..  -I/usr/include/plplot -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_REENTRANT -g -O2 
-fdebug-prefix-map=/home/kralcyor/tmp/packaging/scamp/scamp-2.0.4=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wsequence-point -c 
-o field.o field.c
field.c: In function ‘load_field’:
field.c:343:27: warning: operation on ‘n’ may be undefined [-Wsequence-point]
   set[n]->setindex = n++;
  ~^~

3. Walk around

Apply the patch:

--- a/src/field.c
+++ b/src/field.c
@@ -340,7 +340,8 @@
   nsample += set[n]->nsample;
   free_tab(set[n]->imatab);
   set[n]->imatab = NULL;
-  set[n]->setindex = n++;
+  set[n]->setindex = n;
+  n++;
   }
 
   field->nsample = nsample;

Regards,
Roy Clark

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

Kernel: Linux 4.13.0-1-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 scamp depends on:
ii  curl  7.57.0-1
ii  libatlas3-base3.10.3-5
ii  libc6 2.25-2
ii  libfftw3-single3  3.3.6p2-2
ii  libplplot15   5.13.0+dfsg-7

scamp recommends no packages.

scamp suggests no packages.

-- debconf-show failed


test-scamp-segfault.cat
Description: Binary data
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

> WARNING: scamp.conf not found, using internal defaults


> WARNING: This executable has been compiled using a version of the ATLAS 
> library without support for multithreading. Performance will be degraded.

> 
- SCAMP 2.0.4 started on 2017-12-01 at 13:55:43 with 2 threads

> 
- 1 inputs:
[New Thread 0x74769700 (LWP 10661)]
[New Thread 0x73f68700 (LWP 10662)]
> Examining Catalog test-scamp-segfault.cat

Thread 2 "scamp" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x74769700 (LWP 10661)]
0x5558e58a in load_field (filename=, 
fieldindex=fieldindex@entry=0) at field.c:343
343 field.c: No such file or directory.
#0  0x5558e58a in load_field (filename=, 
fieldindex=fieldindex@entry=0) at field.c:343
#1  0x5558eb94 in pthread_load_field (arg=) at 
field.c:655
#2  0x76879517 in start_thread (arg=0x74769700) at 
pthread_create.c:456
#3  0x7635182f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97
#0  0x5558e58a in load_field (filename=, 
fieldindex=fieldindex@entry=0) at field.c:343
wcs = 
cat = 0x7fffec0008c0
tab = 0x7fffec003a60
imatab = 
key = 
field = 
set = 
htype = 1452482960
ttype = 21845
str = 
"test-scamp-segfault.cat\000mp-segfault.cat\000t\000\000\000\377\377", '\000' 
, "\064`\366\377\177\000\000"...
label = 
"\000\000\000\000\000\000\000\000P<\207\366\377\177\000\000\340\216v\364\377\177\000\000\063\376\336\367\377\177",
 '\000' , 
"\270!\223VUU\000\000\220!\223VUU\000\000\340!\223VUU\000"
keystr = "\005", '\000' 
rfilename = 
pstr = 
astrombuf = 
photombuf = 
pspath = 
d = 
i = 
j = 
n = 1
s = 
nsample = 1
line = 
#1  0x5558eb94 in pthread_load_field (arg=) at 
field.c:655
findex = 0
proc = 
#2  0x76879517 in start_thread (arg=0x74769700) at 
pthread_create.c:456
__res = 
pd = 0x74769700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737294800640, 
1722582721818372361, 140737488346030, 140737488346031, 

Bug#877195: the patches

[Russell Coker]

On Sunday, 19 November 2017 9:41:58 PM AEDT Adam D. Barratt wrote:
> > Section 5.5.1 of the above seemed to indicate that I should do it
> > that way.  
> > Did I misunderstand it or does the documentation need improving?
>
> Some combination. :-)
>
> You used reportbug to file the report - did it not ask for a debdiff?

I can't remember.

> > I've attached such a debdiff.  NB It has one thing that is not
> > required (but 
> > is still handy) that is a build-conflicts against too-new versions of
> > the SE 
> > Linux tools.  This prevents anyone from accidentally building it on
> > Testing or 
> > Unstable (which will be unusable).  Obviously the package will work
> > OK without 
> > such a build-conflict, unless you build it with the wrong packages
> > installed.
>
> Technically, it's version-constrained build-dependencies, rather than a
> build-conflict.

Is that ok?

> In any case, the diff you supplied has:
>
> +refpolicy (2:2.20161023.1-10) unstable; urgency=medium
>
> which obviously isn't what you're proposing using for an upload to
> stable. I realise I said "a package", but the implication was that it
> be a package that you could simply upload "as-is" if the diff was OKed.

So if I upload the same diff with a better version number it will be OK?

Bug#883235: ITP: range-v3 -- range library for C++11/14/17

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

Package: wnpp
Severity: wishlist
Owner: !

* Package name: range-v3
  Version : 0.3.0
  Upstream Author : Eric Niebler 
* URL : https://github.com/ericniebler/range-v3
* License : Boost
  Programming Lang: C++
  Description : range library for C++11/14/17

This is a dependency for a forthcoming version of the telegram-desktop
package.

Bug#802284: git-buildpackage: should assemble overlay before issuing 'debian/rules' commands

[Ben Finney]

On 19-Nov-2017, Guido Günther wrote:
> So this looks like bzr-buildpackage is calling
> 
>debuild -S
> 
> after assembling the overlay. Wouldn't that be equivalent of calling
> 
>gbp buildpackage --git-postexport="debuild -S" …

When I try, it still fails because it's trying to invoke the upstream build
system *before* assembling the overlay:

=
$ gbp buildpackage --git-postexport='debuild -S'
gbp:info: Building with (cowbuilder) for sid
gbp:info: Postexport hook set, delaying tarball creation
gbp:info: Exporting 'WC' to 
'/home/bignose/Projects/debian/xkcdpass/build-area/xkcdpass-tmp'
 dpkg-buildpackage -rfakeroot -us -uc -ui -S
dpkg-buildpackage: info: source package xkcdpass
dpkg-buildpackage: info: source version 1.14.2-1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Ben Finney 
 dpkg-source --before-build xkcdpass-tmp
 fakeroot debian/rules clean
dh clean --with bash-completion,python3 --buildsystem=pybuild
   debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/home/bignose/Projects/debian/xkcdpass/build-area/xkcdpass-tmp'
dh_auto_clean
E: pybuild pybuild:96: cannot detect build system, please use --system option 
or set PYBUILD_SYSTEM env. variable
dh_auto_clean: pybuild --clean -i python{version} -p 3.6 returned exit code 11
debian/rules:48: recipe for target 'override_dh_auto_clean' failed
make[1]: *** [override_dh_auto_clean] Error 25
make[1]: Leaving directory 
'/home/bignose/Projects/debian/xkcdpass/build-area/xkcdpass-tmp'
debian/rules:35: recipe for target 'clean' failed
make: *** [clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2
debuild: fatal error at line 1151:
dpkg-buildpackage -rfakeroot -us -uc -ui -S failed
gbp:error: Postexport-hook 'debuild -S' failed: it exited with 29
=

That may be what you expected to see, but I'm not sure.

-- 
 \   “You can never entirely stop being what you once were. That's |
  `\   why it's important to be the right person today, and not put it |
_o__) off until tomorrow.” —Larry Wall |
Ben Finney 


signature.asc
Description: PGP signature

Bug#882554: Pending fixes for bugs in the golang-google-grpc package

[pkg-go-maintainers]

tag 882554 + pending
thanks

Some bugs in the golang-google-grpc package are closed in revision
ee9c570738a545c8db1f485851ddbf7ad8902bd1 in branch 'master' by
Shengjing Zhu

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-google-grpc.git/commit/?id=ee9c570

Commit message:

remove codes/code_string.go before running go generate (Closes: #882554).

codes/code_string.go is also generated file. running go generate on
file codes/codes.go will cause stringer to process all files in
dir codes, including this generated file.

Signed-off-by: Shengjing Zhu 

Bug#459427: changelog vs. NEWS handling

[Josh Triplett]

On Thu, Nov 30, 2017 at 09:37:32PM -0800, Russ Allbery wrote:
> This is okay 80% of the time and badly needs manual editing the remaining
> 20% of the time.  I personally would never be willing to forgo good
> changelogs in that remaining 20% of the time that can't really be handled
> with commit messages, and the systems I've seen for embedding metadata in
> Git just seem awkward.

I've seen some systems used very well, which can reliably generate NEWS
files with zero interaction. Those systems ought to be able to generate
debian/changelog similarly.

> That said, one reason why I hold this position is that I've personally
> found the concerns with changelogs checked into Git to be vastly
> overblown, and they've never caused me significant problems in practice.
> Those who have had other experiences might reach different cost/benefit
> tradeoffs.

I've had quite a few negative experiences with that, including merge
conflicts and having to write messages twice.

Bug#883234: ITP: node-gzip-js -- GZIP in pure JavaScript (works in the browser)

[Pirate Praveen]

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

* Package name: node-gzip-js
  Version : 0.3.2
  Upstream Author : T. Jameson Little 
* URL : https://github.com/beatgammit/gzip-js
* License : GPL
  Programming Lang: JavaScript
  Description : GZIP in pure JavaScript (works in the browser)

 This module is a pure JavaScript implementation of the GZIP file format. It
 uses the DEFLATE algorithm for compressing data.
 .
 Please note that since this is a pure JavaScript implementation, it
should NOT
 be used on the server for production code. It also does not comply 100%
with
 the standard, yet.
 .
 The main goal of this project is to bring GZIP compression to the browser.
 .
 Node.js is an event-based server-side JavaScript engine.

Build dependency of jquery 2.x (gitlab needs the node source as it
runs webpack during install and since grunt and other build dependencies
are now in archive, this could be used to generate libjs-jquery without
maintaining a custom build script).



signature.asc
Description: OpenPGP digital signature

Bug#459427: changelog vs. NEWS handling

[Russ Allbery]

Josh Triplett  writes:

> I *do* use apt-listchanges to reach changelogs, and I'm not advocating
> that they not exist; I'm simply arguing that they make it a pain to keep
> a Debian package in git, and that we ought to autogenerate them from git
> log and some care taken in commit messages.

This is okay 80% of the time and badly needs manual editing the remaining
20% of the time.  I personally would never be willing to forgo good
changelogs in that remaining 20% of the time that can't really be handled
with commit messages, and the systems I've seen for embedding metadata in
Git just seem awkward.

That said, one reason why I hold this position is that I've personally
found the concerns with changelogs checked into Git to be vastly
overblown, and they've never caused me significant problems in practice.
Those who have had other experiences might reach different cost/benefit
tradeoffs.

-- 
Russ Allbery (r...@debian.org)   

Bug#459427: changelog vs. NEWS handling

[Josh Triplett]

On Thu, Nov 30, 2017 at 08:50:11PM -0800, Russ Allbery wrote:
> Jonathan Nieder  writes:
> >> I would go so far as to say that I hope we one day stop shipping a
> >> non-generated debian/changelog in source packages, because it incurs
> >> all the same pain.
> 
> > I've been trying to make debian/changelog in packages I work on
> > user-focused, and no one has complained yet.
> 
> Yeah, I don't agree on debian/changelog.  I write debian/changelog by
> hand, and will always continue to do so, and I think it's extremely
> valuable.  I also read all debian/changelog files for all packages I
> install on my system, and find that incredibly useful when maintainers put
> real information in them.

I *do* use apt-listchanges to reach changelogs, and I'm not advocating
that they not exist; I'm simply arguing that they make it a pain to keep
a Debian package in git, and that we ought to autogenerate them from git
log and some care taken in commit messages.

- Josh Triplett

Bug#883205: isa-support: [INTL:ru] Russian translaton of debconf template

[Adam Borowski]

Control: tags -1 +pending

On Thu, Nov 30, 2017 at 10:02:54PM +0500, Lev Lamberov wrote:
> Dear Maintainer,
> 
> please find attached the Russian debconf translation for isa-support.

Awesome, in git.  Thanks!


Мяу!
-- 
⢀⣴⠾⠻⢶⣦⠀ Mozilla's Hippocritic Oath: "Keep trackers off your trail"
⣾⠁⢰⠒⠀⣿⡁ blah blah evading "tracking technology" blah blah
⢿⡄⠘⠷⠚⠋⠀ "https://click.e.mozilla.org/?qs=e7bb0dcf14b1013fca3820...;
⠈⠳⣄ (same for all links)

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Sean Whitton]

Hello Jonathan,

On Thu, Nov 30 2017, Jonathan Nieder wrote:

> Thanks.  As a followup, I'm a little confused at what I think is a
> wording issue:
>
>> + To avoid
>> + inconsistency between repeated builds of a package, the
>> + autobuilders will default to selecting the first alternative, after
>> + reducing any architecture-specific restrictions for the build
>> + architecture in question.  While this may limit the usefulness of
>> + alternatives in a single release, they can still be used to provide
>> + flexibility in building the same package across multiple
>> + distributions or releases, where a particular dependency is met by
>> + differently named packages.
>
> This means if I write
>
>   Build-Depends: a | b
>
> then it will always use 'a', regardless of the release, right?

Not quite; see below.

> What is the comment about providing flexibility talking about here?
> Is it saying that I can use 'a | b' to provide flexibility for people
> building outside an autobuilder environment?

I think this is included: this is another sense of flexibility it
provides.

> To help backporters, I have used this functionality before and
> backporters have uploaded the package as-is to a backports dist that
> didn't include 'a'.  The package built against 'b'.  Was this an
> autobuilder bug?

The backports autobuilders pass --build-dep-resolver=aptitude to sbuild,
which (I believe) causes them to use alternative dependencies.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#883223: pcre2: Please switch to 3.0 (quilt)

[Sean Whitton]

Dear Jeremy,

On Thu, Nov 30 2017, Jeremy Bicha wrote:

> I filed https://bugs.debian.org/862425 which has now been closed. I
> kinda feel like my bug was hijacked by a dgit supporter.

I think that your assessment of how I responded to #862425 is unfair.

It was quite reasonable for you to request that Matthew change the
source format.  But it was also quite acceptable for him to deny that
request.  That's the decision-making structure in Debian: the package
maintainer gets to decide things like that.

When I was made aware of the bug, I chimed in with a suggestion to
document the decision that Matthew had taken in a standardised way.  I
don't see how this could be hijacking.  Matthew had already decided to
use his workflow long before either of us got involved.

> Secondly, please add Vcs fields to your debian/control . That way
> someone doesn't have to find and read a README first. The Vcs fields
> have nice integration on pages like
> https://tracker.debian.org/pkg/mdadm

Seems like this should be a separate bug.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#459427: changelog vs. NEWS handling

[Sean Whitton]

Hello Jonathan,

On Thu, Nov 30 2017, Jonathan Nieder wrote:

> I've been trying to make debian/changelog in packages I work on
> user-focused, and no one has complained yet.
>
> I also use NEWS.Debian for notes about incompatibilities that will
> affect sysadmins upgrading.

Yes.  If you read the Developer's Reference, d/changelog is meant to be
"user visible" changes, and NEWS.Debian really urgent user visible
changes.

Which is different from the distinction between the upstream CHANGELOG
and NEWS distinction we've been working with in recent e-mails to this
thread...

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#883233: First footnote to section 7.1 should say which of Debian's autobuilders ignore alternative dependencies

[Sean Whitton]

Package: debian-policy
Version: 4.1.2.0
Severity: normal
User: debian-pol...@packages.debian.org
Usertags: informative

On Thu, Nov 30 2017, Rebecca N. Palmer wrote:

> Should [section 7.1, footnote 1] also make explicit which Debian
> suites have this restriction?
>
> I thought this rule also applied to backports having found [0] in a list
> archive search, and hence have been explicitly changing dependencies for
> backports [1] instead of using alternatives.

Yes, good point.  Backports autobuilders use --build-dep-resolver=aptitude
which (I believe) considers alternative dependencies.

> However after finding this proposal, I checked build logs, which
> suggest that sid (including -ports architectures) and stable do but
> backports doesn't.  (Though we should probably check that with someone
> who knows this better before writing it into Policy...)

Agreed, we need some clarity.

wanna-build team / Release Team / Backports Team: exactly which buildds
ignore alternative dependencies?  We want to include this in an
(existing) Policy footnote.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#883232: swaks fails to report an error if --tls-verify is used and hostname doesn't match certificate

[Russell Coker]

Package: swaks
Version: 20170101.0-2
Severity: normal
Tags: upstream

Here is what happens when I try to generate a TLS error:

$ swaks -tls --tls-verify --ehlo test.coker.com.au -f russ...@coker.com.au -t 
exam...@example.com -s pop.sws.net.au   
=== Trying pop.sws.net.au:25...
=== Connected to pop.sws.net.au.
<-  220 smtp.sws.net.au ESMTP Postfix - by sending email to this server you 
agree to the conditions at this URL: 
http://doc.coker.com.au/legal/conditions-of-sending-email/
 -> EHLO test.coker.com.au
<-  250-smtp.sws.net.au
<-  250-PIPELINING
<-  250-SIZE 5120
<-  250-ETRN
<-  250-STARTTLS
<-  250-AUTH PLAIN LOGIN
<-  250-AUTH=PLAIN LOGIN
<-  250-ENHANCEDSTATUSCODES
<-  250-8BITMIME
<-  250-DSN
<-  250 SMTPUTF8
 -> STARTTLS
<-  220 2.0.0 Ready to start TLS
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN="/CN=gpmail.sws.net.au"
 ~> EHLO test.coker.com.au
<~  250-smtp.sws.net.au
<~  250-PIPELINING
<~  250-SIZE 5120
<~  250-ETRN
<~  250-AUTH PLAIN LOGIN
<~  250-AUTH=PLAIN LOGIN
<~  250-ENHANCEDSTATUSCODES
<~  250-8BITMIME
<~  250-DSN
<~  250 SMTPUTF8
 ~> MAIL FROM:

Here is the sort of result that I expect:
$ gnutls-cli pop.sws.net.au:25 --starttls-proto=smtp  Processed 148 CA 
certificate(s).
Resolving 'pop.sws.net.au:25'...
Connecting to '203.15.121.86:25'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=gpmail.sws.net.au', issuer `CN=Let's Encrypt Authority 
X3,O=Let's Encrypt,C=US', serial 0x047a9875b9f1b27b186ec2a33ea735bc5d09, RSA 
key 2048 bits, signed using RSA-SHA256, activated `2017-10-10 08:12:15 UTC', 
expires `2018-01-08 08:12:15 UTC', 
pin-sha256="SckWTJ2pRMCxLlQYKi/USOxUfjP7hK2MDUdcaVRnyO4="
Public Key ID:
sha1:323a845463d17fcb45f7b49eb6742d8ac3eeae97

sha256:49c9164c9da944c0b12e54182a2fd448ec547e33fb84ad8c0d475c695467c8ee
Public Key PIN:
pin-sha256:SckWTJ2pRMCxLlQYKi/USOxUfjP7hK2MDUdcaVRnyO4=
Public key's random art:
+--[ RSA 2048]+
|=o   |
|   o .. . . .|
|  ..   . . o.|
| . .. . .  ..|
|  . . o So o  . o|
|   . . o  o   .=o|
|o. o .o.o|
| .E .  . |
|.*+. |
+-+

- Certificate[1] info:
 - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST 
Root CA X3,O=Digital Signature Trust Co.', serial 
0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, 
activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', 
pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="
- Status: The certificate is NOT trusted. The name in the certificate does not 
match the expected. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** handshake has failed: Error in the certificate.


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

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

Versions of packages swaks depends on:
ii  perl  5.26.1-2

Versions of packages swaks recommends:
ii  libnet-dns-perl 1.10-2
ii  libnet-ssleay-perl  1.80-1+b2

Versions of packages swaks suggests:
pn  libauthen-ntlm-perl  
ii  libauthen-sasl-perl  2.1600-1
ii  perl-doc 5.26.1-2

-- no debconf information

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Russ Allbery]

Jonathan Nieder  writes:

> This means if I write

>   Build-Depends: a | b

> then it will always use 'a', regardless of the release, right?

If 'a' is not installable, I thought it would then install 'b', but
perhaps I'm wrong about how the buildds work?

If 'b' is already installed, I also didn't think 'a' would be installed.

Could someone confirmm how this really works?

> What is the comment about providing flexibility talking about here?
> Is it saying that I can use 'a | b' to provide flexibility for people
> building outside an autobuilder environment?

I think some of the package-building tools that don't use clean chroots
will use 'b' if it's already installed and not try to install 'a'.

> To help backporters, I have used this functionality before and
> backporters have uploaded the package as-is to a backports dist that
> didn't include 'a'.  The package built against 'b'.  Was this an
> autobuilder bug?

Yeah, that's a great question.  How does this work for backports?

-- 
Russ Allbery (r...@debian.org)   

Bug#459427: changelog vs. NEWS handling

[Russ Allbery]

Jonathan Nieder  writes:

> How do you feel about generated changelogs in release tarballs that
> are generated by tools like "git log"?

I think they're a waste of space and effort.  The circumstances in which
those are useful are so obscure that I think more harm than good is being
done by making people download the additional bytes in release tarballs.
Essentially everyone who would read that file is much better off just git
cloning the repository.

>> I would go so far as to say that I hope we one day stop shipping a
>> non-generated debian/changelog in source packages, because it incurs
>> all the same pain.

> I've been trying to make debian/changelog in packages I work on
> user-focused, and no one has complained yet.

Yeah, I don't agree on debian/changelog.  I write debian/changelog by
hand, and will always continue to do so, and I think it's extremely
valuable.  I also read all debian/changelog files for all packages I
install on my system, and find that incredibly useful when maintainers put
real information in them.

-- 
Russ Allbery (r...@debian.org)   

Bug#459427: changelog vs. NEWS handling

[Russ Allbery]

Bill Allombert  writes:

> git log might be more useful in some situation and extremly inconvenient
> in some others (to start with it require network access and cloning the
> full project history).

A complete changelog is often an appreciable percentage of the size of
that full project history.  I'm dubious that, to avoid requiring users
clone the full project history, we should ship the full project history in
Debian packages.  Debian does not need to provide every piece of possibly
useful data provided by upstream; at some point, people really should go
directly to upstream for the obscure and marginally useful trivia.

I've stopped including VCS-level changelogs in any of my packages even if
upstream ships them.  The compressed changelog was sometimes over 80% of
the size of the entire package, which was a complete waste.

That said, I'm happy to leave this to the Debian package maintainer
discretion in cases where it really is useful for some reason.  I think
the most valuable starting point would to be to standardize on
/usr/share/doc/package/NEWS.gz for the human-readable summary and
explicitly say to never install that as
/usr/share/doc/package/changelog.gz.  Then, we can define changelog.gz as
always the detailed change-by-change upstream log (if such a thing
exists), and clearly indicate that it's optional and maintainers should
use their discretion in deciding whether it's useful to include, but
should always include the human-readable release notes and change summary
as NEWS.

Unfortunately, there's no good way to do this transition without making a
whole ton of packages buggy, since we're horribly inconsistent about how
we handle this now.  I think that's just something we should tackle, and
make it very clear that this is a *minor* bug and people shouldn't harass
maintainers about it, but we'd like to sort out this historic mess and
switch to consistent usage of these two files.

-- 
Russ Allbery (r...@debian.org)   

Bug#883231: override: less:text/important

[Adam Borowski]

Package: ftp.debian.org
Severity: wishlist

Hi!
I believe that it is time to bump the priority of "less" to important.
The .deb already has such priority set, thus it'd be nice if you could
update the override file accordingly.

The rationale is discussed in #880051.

It's a somewhat unusual request, as we tend to downgrade packages a lot,
and this is a step in the other direction, but I believe that an adequate
pager fulfulls the requirements of the Policy for priority:important.


Meow!

Bug#880051: less: please bump priority to important

[Matthias Klose]

less sets the priority to important. That has to be changed in some override 
file.

Bug#883230: Missing module Unix in tzlocal 1.5

[sagar bhandare]

Package: tzlocal
Version: 1.5

Missing module unix:

Error seen in prod:

return pytz.unix._tz_from_env(tzenv)
AttributeError: 'module' object has no attribute 'unix'

In newly added method _try_tz_from_env, call to
pytz.unix._tz_from_env(tzenv) fails

Please let me know if this is the issue with my env

Thanks,
Sagar

-- 
*Thanks,*
*Sagar *

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Thu, Nov 30 2017, Simon McVittie wrote:

>> Other than that, seconded. I'm not sure whether this is necessarily
>> how the autobuilders *should* work, but there's value in documenting
>> how the autobuilders *do* work.
>
> Thank you for reviewing this bug.
>
> Since Sean's patch doesn't require anything of package maintainers, it's
> what we call "informative", and we don't need formal seconds.  So I'm
> going to go ahead and apply the patch.

Thanks.  As a followup, I'm a little confused at what I think is a
wording issue:

> +To avoid
> +   inconsistency between repeated builds of a package, the
> +   autobuilders will default to selecting the first alternative, after
> +   reducing any architecture-specific restrictions for the build
> +   architecture in question.  While this may limit the usefulness of
> +   alternatives in a single release, they can still be used to provide
> +   flexibility in building the same package across multiple
> +   distributions or releases, where a particular dependency is met by
> +   differently named packages.

This means if I write

Build-Depends: a | b

then it will always use 'a', regardless of the release, right?

What is the comment about providing flexibility talking about here?
Is it saying that I can use 'a | b' to provide flexibility for people
building outside an autobuilder environment?

To help backporters, I have used this functionality before and
backporters have uploaded the package as-is to a backports dist that
didn't include 'a'.  The package built against 'b'.  Was this an
autobuilder bug?

Thanks,
Jonathan

Bug#459427: changelog vs. NEWS handling

[Josh Triplett]

On Thu, Nov 30, 2017 at 06:56:53PM -0800, Jonathan Nieder wrote:
> Josh Triplett wrote:
> > On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert  
> > wrote:
> 
> >> The fact that some upstream do not bother to ship useful changelog does
> >> not mean that all changelog are useless, and by removing them we
> >> discourage upstream of producing useful changelog.
> >
> > I sincerely hope so.  Convincing upstreams to "git rm ChangeLog" becomes
> > much easier the more widespread existing practice we can point to.
> > Having a ChangeLog file in version control is actively detrimental.
> 
> I agree with you about GNU-style changelogs.  But I don't think I've
> seen those much outside of GNU packages.

I still see them in some other packages that started out pre-git, where
nobody quite felt empowered to delete the changelog.

> How do you feel about generated changelogs in release tarballs that
> are generated by tools like "git log"?

As long as they're completely autogenerated, they don't do any harm. I'd
sooner not ship them at all and just say "see the git repository", but
if you have to have one then autogenerate it.

> I also use NEWS.Debian for notes about incompatibilities that will
> affect sysadmins upgrading.

NEWS.Debian is *absolutely* valuable.

Bug#802284: git-buildpackage: should assemble overlay before issuing 'debian/rules' commands

[Ben Finney]

On 19-Nov-2017, Guido Günther wrote:
> dug this one out again since I really would like to see this adressed
> and I'm still unsure if we really need to do something:

Thank you for returning to this. I also want this to be addressed to
completion.

> So this looks like bzr-buildpackage is calling
> 
>debuild -S
> 
> after assembling the overlay. Wouldn't that be equivalent of calling
> 
>gbp buildpackage --git-postexport="debuild -S" …
> 
> If this works we could update the documentation (which at the moment
> doesn't talk about --git-overlay at all).

On the manual pages ‘gbp(1)’ and ‘gbp.conf(5)’ I can't see the
‘--git-postexport’ option described. Where is that documented?

-- 
 \  “One time a cop pulled me over for running a stop sign. He |
  `\said, ‘Didn't you see the stop sign?’ I said, ‘Yeah, but I |
_o__)don't believe everything I read.’” —Steven Wright |
Ben Finney 


signature.asc
Description: PGP signature

Bug#883189: cross-toolchain-base: dpkg-cross correct libc.so file for mips ports

[YunQiang Su]

On Fri, Dec 1, 2017 at 2:53 AM, Helmut Grohne  wrote:
> Control: reassign -1 dpkg-cross
> Control: tags -1 + moreinfo
>
> On Thu, Nov 30, 2017 at 09:33:22PM +0800, YunQiang Su wrote:
>> Hi, in the previous version, we dropped
>> /usr/$(multiarch)/lib/ld.so.1
>> for N32 and N64, while it seems libc.so hardcode this filename,
>> Then, let's change it.
>
> I concur with James Cowgill in all points:
>  * This is a bug in dpkg-cross if anything.
>  * You should be explaining what problem you solve.
>
> Last time Matthias merged a dpkg-cross patch of yours it broke the
> mips64el cross toolchain. I suggest that you provide test build logs
> well to avoid a similar disaster.
>
> I propose that you use a dpkg-cross with your prospective patch to
> convert the in-archive glibc packages and cross build some non-trivial
> packages with that toolchain. Also checking coinstallability with the
> original is something worth checking as mips* is prone to violating
> that.
>

I am sorry for previous bugs, I will have more test in future.

> Helmut



-- 
YunQiang Su

Bug#883229: ibus: Enable emoji dictionary

[Jeremy Bicha]

Source: ibus
Version: 1.5.14-3
Severity: wishlist
Tags: patch

I'm attaching a patch in my follow up email to enable the emoji
dictionary. I'm not really sure how to make use of it though.

Thanks,
Jeremy Bicha

Bug#459427: changelog vs. NEWS handling

[Jonathan Nieder]

Josh Triplett wrote:
> On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert  wrote:

>> The fact that some upstream do not bother to ship useful changelog does
>> not mean that all changelog are useless, and by removing them we
>> discourage upstream of producing useful changelog.
>
> I sincerely hope so.  Convincing upstreams to "git rm ChangeLog" becomes
> much easier the more widespread existing practice we can point to.
> Having a ChangeLog file in version control is actively detrimental.

I agree with you about GNU-style changelogs.  But I don't think I've
seen those much outside of GNU packages.

How do you feel about generated changelogs in release tarballs that
are generated by tools like "git log"?

> I would go so far as to say that I hope we one day stop shipping
> a non-generated debian/changelog in source packages, because it incurs
> all the same pain.

I've been trying to make debian/changelog in packages I work on
user-focused, and no one has complained yet.

I also use NEWS.Debian for notes about incompatibilities that will
affect sysadmins upgrading.

Thanks,
Jonathan

Bug#459427: changelog vs. NEWS handling

[Josh Triplett]

On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert  wrote:
> Both the content and the name of the upstream changelogs is an upstream
> issue. The fact that a file is named by upstream Changelog instead of
> NEWS does not imply anything on its usefulness. It might even happen
> that NEWS is the real changelog.

That's certainly possible, though not a particularly good or
conventional practice.  But using NEWS for user-visible release notes
rather than a full source-code changelog seems a sufficiently common
practice to make it the default assumption, which a source package could
override if necessary.

> The fact that some upstream do not bother to ship useful changelog does
> not mean that all changelog are useless, and by removing them we
> discourage upstream of producing useful changelog.

I sincerely hope so.  Convincing upstreams to "git rm ChangeLog" becomes
much easier the more widespread existing practice we can point to.
Having a ChangeLog file in version control is actively detrimental.

I would go so far as to say that I hope we one day stop shipping
a non-generated debian/changelog in source packages, because it incurs
all the same pain.

Now, a NEWS file or similar, containing user-visible *release notes* and
similar highlights, would most certainly be useful.  I would love to see
*more* upstreams providing files like those.  But those certainly aren't
changelogs.

- Josh Triplett

Bug#883228: bind9: apparmor policy is denying the ability to change worker thread names

[Jon]

Package: bind9
Version: 1:9.11.2+dfsg-1
Severity: minor
Tags: patch

Dear Maintainer,

The bind apparmor policy is blocking the ability of bind to change its
worker thread names.

type=AVC msg=audit(1512011335.533:12422): apparmor="DENIED"
operation="open" profile="/usr/sbin/named"
name="/proc/31264/task/31268/comm" pid=31264 comm="named"
requested_mask="wr" denied_mask="wr" fsuid=108 ouid=108

Adding this line to the policy allowed bind to change it thread names:

owner @{PROC}/@{pid}/task/@{tid}/comm rw,



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

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 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: sysvinit (via /sbin/init)

Versions of packages bind9 depends on:
ii  adduser3.116
ii  bind9utils 1:9.11.2+dfsg-1
ii  debconf [debconf-2.0]  1.5.65
ii  libbind9-160   1:9.11.2+dfsg-1
ii  libc6  2.25-2
ii  libcap21:2.25-1.2
ii  libcomerr2 1.43.7-1
ii  libdns169  1:9.11.2+dfsg-1
ii  libgeoip1  1.6.11-3
ii  libgssapi-krb5-2   1.15.2-2
ii  libirs160  1:9.11.2+dfsg-1
ii  libisc166  1:9.11.2+dfsg-1
ii  libisccc1601:9.11.2+dfsg-1
ii  libisccfg160   1:9.11.2+dfsg-1
ii  libjson-c3 0.12.1-1.2
ii  libk5crypto3   1.15.2-2
ii  libkrb5-3  1.15.2-2
ii  liblwres1601:9.11.2+dfsg-1
ii  libssl1.1  1.1.0g-2
ii  libxml22.9.4+dfsg1-5.1
ii  lsb-base   9.20170808
ii  net-tools  1.60+git20161116.90da8a0-1
ii  netbase5.4

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind9-doc   
ii  dnsutils1:9.11.2+dfsg-1
pn  resolvconf  
pn  ufw 

-- Configuration Files:
/etc/bind/named.conf changed [not included]
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]
/etc/bind/zones.rfc1918 changed [not included]

-- debconf information:
* bind9/run-resolvconf: false
* bind9/different-configuration-file:
* bind9/start-as-user: bind

Bug#882487: thunderbird: Thunderbird wont start and crashreporter fails to run

[Jeff Lehrkamp]

Package: thunderbird
Version: 1:52.4.0-1
Followup-For: Bug #882487

Dear Maintainer,

Thunderbird fails to start on everyrun, then the crashreporter fails also.  Was 
working correctly through 11/29.  
I use thunderbird, lightning, icedove, iceowl-extension, and 
calendar-google-provider.

I Have removed (purged) the package and reinstalled with same effect.  have 
also removed the .icedove and .thunderbird folders, also with
same result.

Program was working correctly prior to 11/28/17.  The following updates were 
installed on 11/28 - 11/29.
-
Upgraded the following packages:
libbasicusageenvironment1 (2017.09.12-1) to 2017.10.28-2
libfinance-quote-perl (1.45-1) to 1.47-1
libgroupsock8 (2017.09.12-1) to 2017.10.28-2
libidn2-0 (2.0.2-5) to 2.0.4-1.1
libidn2-0:i386 (2.0.2-5) to 2.0.4-1.1
libmlt++3 (6.4.1-6) to 6.4.1-6+b1
libmlt6 (6.4.1-6) to 6.4.1-6+b1
libsox-fmt-alsa (14.4.1-5+b2) to 14.4.2-2
libsox-fmt-base (14.4.1-5+b2) to 14.4.2-2
libusageenvironment3 (2017.09.12-1) to 2017.10.28-2
melt (6.4.1-6) to 6.4.1-6+b1
sox (14.4.1-5+b2) to 14.4.2-2

Installed the following packages:
libsox3 (14.4.2-2)

Upgraded the following packages:
console-setup (1.170) to 1.171
console-setup-linux (1.170) to 1.171
cowsay (3.03+dfsg2-3) to 3.03+dfsg2-4
cowsay-off (3.03+dfsg2-3) to 3.03+dfsg2-4
glusterfs-common (3.12.2-2) to 3.12.3-1
indi-bin (1.2.0-5) to 1.2.0-6
kdenlive (17.08.3-1) to 17.08.3-2
kdenlive-data (17.08.3-1) to 17.08.3-2
keyboard-configuration (1.170) to 1.171
libindi-data (1.2.0-5) to 1.2.0-6
libindi-plugins (1.2.0-5) to 1.2.0-6
libindi1 (1.2.0-5) to 1.2.0-6
libindialignmentdriver1 (1.2.0-5) to 1.2.0-6
libindidriver1 (1.2.0-5) to 1.2.0-6
python3-pyatspi (2.24.0+dfsg-1) to 2.26.0+dfsg-1
x11proto-xf86dga-dev (2.1-3) to 2.1-4

Installed the following packages:
python-jwt (1.5.3+ds1-1)
-
Commit Log for Wed Nov 29 22:50:14 2017


Upgraded the following packages:
audacity (2.1.2-2) to 2.2.0-2
audacity-data (2.1.2-2) to 2.2.0-2
cvs (2:1.12.13+real-24) to 2:1.12.13+real-25
ffmpeg (7:3.4-3) to 7:3.4-4
libassuan0 (2.4.3-3) to 2.4.4-1
libavcodec-extra (7:3.4-3) to 7:3.4-4
libavcodec-extra57 (7:3.4-3) to 7:3.4-4
libavcodec-extra57:i386 (7:3.4-3) to 7:3.4-4
libavdevice57 (7:3.4-3) to 7:3.4-4
libavfilter6 (7:3.4-3) to 7:3.4-4
libavformat57 (7:3.4-3) to 7:3.4-4
libavresample3 (7:3.4-3) to 7:3.4-4
libavresample3:i386 (7:3.4-3) to 7:3.4-4
libavutil55 (7:3.4-3) to 7:3.4-4
libavutil55:i386 (7:3.4-3) to 7:3.4-4
libpostproc54 (7:3.4-3) to 7:3.4-4
libswresample2 (7:3.4-3) to 7:3.4-4
libswresample2:i386 (7:3.4-3) to 7:3.4-4
libswscale4 (7:3.4-3) to 7:3.4-4
python-sip (4.19.5+dfsg-1) to 4.19.6+dfsg-1
python3-sip (4.19.5+dfsg-1) to 4.19.6+dfsg-1
sqlitebrowser (3.9.1-2) to 3.10.1-1
virtualbox (5.2.0-dfsg-5) to 5.2.2-dfsg-2
virtualbox-dkms (5.2.0-dfsg-5) to 5.2.2-dfsg-2
virtualbox-guest-additions-iso (5.2.1-118918-1) to 5.2.2-1
virtualbox-qt (5.2.0-dfsg-5) to 5.2.2-dfsg-2


The following is the output from the console when run
ExceptionHandler::GenerateDump cloned child 4982
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
jlehrkamp@HP510-p010z:~$ *** Error in `/usr/lib/thunderbird/crashreporter': 
double free or corruption (fasttop): 0x561454d584f0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7230b)[0x7f90321d430b]
/lib/x86_64-linux-gnu/libc.so.6(+0x7896e)[0x7f90321da96e]
/lib/x86_64-linux-gnu/libc.so.6(+0x791ce)[0x7f90321db1ce]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(FcConfigParseAndLoad+0x13a)[0x7f9030242d4a]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x2415e)[0x7f903024315e]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xb238)[0x7f902cb99238]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xc00c)[0x7f902cb9a00c]
/lib/x86_64-linux-gnu/libexpat.so.1(+0x99e3)[0x7f902cb979e3]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xa915)[0x7f902cb98915]
/lib/x86_64-linux-gnu/libexpat.so.1(XML_ParseBuffer+0x7d)[0x7f902cb9c4dd]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x23b43)[0x7f9030242b43]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(FcConfigParseAndLoad+0x366)[0x7f9030242f76]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(FcConfigParseAndLoad+0x3d8)[0x7f9030242fe8]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x2415e)[0x7f903024315e]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xb238)[0x7f902cb99238]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xc00c)[0x7f902cb9a00c]
/lib/x86_64-linux-gnu/libexpat.so.1(+0x99e3)[0x7f902cb979e3]
/lib/x86_64-linux-gnu/libexpat.so.1(+0xa915)[0x7f902cb98915]
/lib/x86_64-linux-gnu/libexpat.so.1(XML_ParseBuffer+0x7d)[0x7f902cb9c4dd]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x23b43)[0x7f9030242b43]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(FcConfigParseAndLoad+0x366)[0x7f9030242f76]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x16d34)[0x7f9030235d34]
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1(+0x16f86)[0x7f9030235f86]

Bug#883227: Please package >= 2.7.1 (latest stable upstream is 2.7.2)

[Nicholas D Steeves]

Source: mathjax
Version: 2.7.0-2
Severity: normal

Dear mathjax maintainer,

I'm currently working on solving the privacy-breach-uses-embedded-file
(downloaded from internet) lintian errors in clang-x.0-doc and an
exact replacement requires libjs-mathjax-2.7.1.

Would you please package the latest stable upstream version at your
earliest convenience?

Thank you,
Nicholas

Bug#883226: docker-engine: Cannot use docker from Debian Live CD images (aufs mount point already stacked)

[Witold Baryluk]

FYI.

I managed to make docker run work by putting

{
  "storage-manager": "device-mapper"
}

In /etc/docker/daemon.json.

But I imaging this is less efficient than aufs.

Also error message could be a bit more descriptive, and recommend some
solutions.


On 1 Dec 2017 2:03 am, "Witold Baryluk"  wrote:

Package: docker-engine
Version: 17.05.0~ce-0~debian-stretch
Severity: normal

Hi,

I was trying to run some docker programs (benchmarks in particular) on a
machine that I booted using Debian Stretch Live CD, and after
installation using apt.dockerproject.org repos to install docker-engine,
adjusting groups, and installing aufs, I got this:

user@debian:~$ docker run --rm -it x/y

...
docker: Error response from daemon: error creating aufs mount to
/var/lib/docker/aufs/mnt/1a6afb5b3077fe541918749fd87e68
c3dac7a1647f7d46417d3217da9005c065-init: invalid argument.
See 'docker run --help'.
$

# dmesg
...
[ 2162.158988] aufs test_add:255:dockerd[19036]: already stacked,
/var/lib/docker/tmp/docker-aufs-base911373706 (overlay)
[ 2167.623460] aufs test_add:255:dockerd[18978]: already stacked,
/var/lib/docker/aufs/diff/b67d6807b58fb8bd80bedfa39cbcaf
142bd586e9d343c53fd0f8c13b0a6c41f9-init (overlay)
#

Running Debian 9.1.0 (Stretch) amd64, MATE version in live mode.

user@debian:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=
4017744k,nr_inodes=1004436,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,
gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=806292k,mode=755)
/dev/sda1 on /lib/live/mount/medium type iso9660 (ro,noatime)
/dev/loop0 on /lib/live/mount/rootfs/filesystem.squashfs type squashfs
(ro,noatime)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,relatime)
overlay on / type overlay (rw,noatime,lowerdir=//
filesystem.squashfs/,upperdir=/live/overlay//rw,workdir=/live/overlay//work)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,
relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,
relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-
agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,
relatime)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,
relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,
relatime,memory)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,
relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,
relatime,pids)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,
relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,
relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,
relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,
relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,
timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10693)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,
size=806288k,mode=700,uid=1000,gid=1000)
overlay on /var/lib/docker/aufs type overlay (rw,noatime,lowerdir=//
filesystem.squashfs/,upperdir=/live/overlay//rw,workdir=/live/overlay//work)
$


Cheers.

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/8 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 docker-engine depends on:
ii  init-system-helpers  1.48
ii  iptables 1.6.0+snapshot20161117-6
ii  libapparmor1 2.11.0-3
ii  libc62.24-11+deb9u1
ii  libdevmapper1.02.1   2:1.02.137-2
ii  libltdl7 2.4.6-2
ii  libseccomp2  2.3.1-2.1
ii  libsystemd0  232-25+deb9u1

Versions of packages docker-engine recommends:
ii  aufs-tools   1:4.1+20161219-1
ii  ca-certificates  20161130+nmu1
ii  cgroupfs-mount   1.3
ii  git  1:2.11.0-3+deb9u2
ii  xz-utils 5.2.2-1.2+b1

docker-engine suggests no packages.

-- no debconf information

Bug#883226: docker-engine: Cannot use docker from Debian Live CD images (aufs mount point already stacked)

[Witold Baryluk]

Package: docker-engine
Version: 17.05.0~ce-0~debian-stretch
Severity: normal

Hi,

I was trying to run some docker programs (benchmarks in particular) on a
machine that I booted using Debian Stretch Live CD, and after
installation using apt.dockerproject.org repos to install docker-engine,
adjusting groups, and installing aufs, I got this:

user@debian:~$ docker run --rm -it x/y

...
docker: Error response from daemon: error creating aufs mount to 
/var/lib/docker/aufs/mnt/1a6afb5b3077fe541918749fd87e68c3dac7a1647f7d46417d3217da9005c065-init:
 invalid argument.
See 'docker run --help'.
$

# dmesg
...
[ 2162.158988] aufs test_add:255:dockerd[19036]: already stacked, 
/var/lib/docker/tmp/docker-aufs-base911373706 (overlay)
[ 2167.623460] aufs test_add:255:dockerd[18978]: already stacked, 
/var/lib/docker/aufs/diff/b67d6807b58fb8bd80bedfa39cbcaf142bd586e9d343c53fd0f8c13b0a6c41f9-init
 (overlay)
#

Running Debian 9.1.0 (Stretch) amd64, MATE version in live mode.

user@debian:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=4017744k,nr_inodes=1004436,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=806292k,mode=755)
/dev/sda1 on /lib/live/mount/medium type iso9660 (ro,noatime)
/dev/loop0 on /lib/live/mount/rootfs/filesystem.squashfs type squashfs 
(ro,noatime)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,relatime)
overlay on / type overlay 
(rw,noatime,lowerdir=//filesystem.squashfs/,upperdir=/live/overlay//rw,workdir=/live/overlay//work)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs 
(rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup 
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10693)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=806288k,mode=700,uid=1000,gid=1000)
overlay on /var/lib/docker/aufs type overlay 
(rw,noatime,lowerdir=//filesystem.squashfs/,upperdir=/live/overlay//rw,workdir=/live/overlay//work)
$


Cheers.

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/8 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 docker-engine depends on:
ii  init-system-helpers  1.48
ii  iptables 1.6.0+snapshot20161117-6
ii  libapparmor1 2.11.0-3
ii  libc62.24-11+deb9u1
ii  libdevmapper1.02.1   2:1.02.137-2
ii  libltdl7 2.4.6-2
ii  libseccomp2  2.3.1-2.1
ii  libsystemd0  232-25+deb9u1

Versions of packages docker-engine recommends:
ii  aufs-tools   1:4.1+20161219-1
ii  ca-certificates  20161130+nmu1
ii  cgroupfs-mount   1.3
ii  git  1:2.11.0-3+deb9u2
ii  xz-utils 5.2.2-1.2+b1

docker-engine suggests no packages.

-- no debconf information

Bug#866840: [b7f99fd] Fix for Bug#866840 committed to git

[Sandro Tosi]

tags 866840 + pending
thanks

Hello,

 The following change has been committed for this bug by
 Sandro Tosi  on Thu, 30 Nov 2017 19:34:57 -0500.
 The fix will be in the next upload. 
=
remove Giuseppe Iuculano from Uploaders; Closes: #866840


=

You can check the diff of the fix at:

;a=commitdiff;h=b7f99fd

Bug#874295: Not a bug

[Ben Finney]

Control: notfound -1 clementine/1.3.1+git276-g3485bbe43+dfsg-1

On 30-Nov-2017, Ben Finney wrote:
> Thomas Pierson  writes:
> > So unless someone point me a clear justification I will close this
> > bug as invalid for now.
> 
> I agree that, despite the problems remarked on of downloading and
> executing unpackaged code to execute on the user's computer, this is
> not a dependency for the program performing its normal function. So
> this does not appear to be a Policy §2.2.1 violation.

I'm recording the effects of this resolution on the metadata of this
report.

-- 
 \“If you continue running Windows, your system may become |
  `\unstable.” —Microsoft, Windows 95 bluescreen error message |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#874295: clementine: Third-party plug-ins should be packaged for Debian

[Ben Finney]

Control: clone -1 -2
Control: retitle -2 clementine: Third-party plug-ins should be packaged for 
Debian
Control: found -2 clementine/1.3.1+git276-g3485bbe43+dfsg-1
Control: severity -2 minor
Control: tags -2 - upstream

On 04-Sep-2017, Jonas Smedegaard wrote:

> One of several functions of Clementine is to stream audio from cloud
> service Spotify. Initially selecting that function triggers a
> routine where Clementine (asks for concent and then) downloads and
> installs a non-free binary driver.

As discussed in bug#874295, I think there is a separate bug to be
resolved here: the program should not download code for execution from
a third-party website, when that code can instead be packaged for
Debian and installed using the OS package manager.

On 30-Nov-2017, Ben Finney wrote:
> Thomas Pierson  writes:
> > It's only if a user want to connect to a particular external
> > service that a plugin file is downloaded and used.
> 
> That is still a problem, IMO. It would be best if the program did
> not do that, and instead prompted the user to install the non-free
> package providing that plug-in.

This (new) bug report requests that the program in Debian should not
have the behaviour Jonas describes above.

Instead, if there are third-party plug-ins to enable Clementine
features, those plug-ins should be packaged separately for Debian, and
only enabled by installing the Debian package.

The license conditions of those third-party packages will determine
whether they are in Debian, or in some other archive area. This bug
report does not relate to that issue.

Instead, this bug report requests the download and execution of
third-party code should not happen preferring to have the third-party
code packaged and managed by the Debian package manager.

-- 
 \  “… a Microsoft Certified System Engineer is to information |
  `\ technology as a McDonalds Certified Food Specialist is to the |
_o__)   culinary arts.” —Michael Bacarella |
Ben Finney 


signature.asc
Description: PGP signature

Bug#883094: Accessibility: Mate: Screen reader is not available in login screen

[sirgazil]

On 30/11/17 04:38, Mike Gabriel wrote:

Hi,

On  Mi 29 Nov 2017 16:59:27 CET, sirgazil wrote:


Package: mate-desktop
Version: 1.16.2-2

I'm using Debian Linux zenme 4.9.0-4-686-pae #1 SMP Debian 4.9.51-1 
(2017-09-28) i686 GNU/Linux.


When a blind person starts the computer, they don't have any way of 
knowing whether the login screen has loaded or not. The system does 
not provide any aural cues for blind users, so they have to call 
sighted people to help them log in.


Thanks for your feedback on accessibility.

Please note that the MATE desktop does not come with a login manager 
itself. It uses a "3rd party product" for session login management.


The default display manager in use for MATE desktop installations is 
LightDM.


Please also note that I have recently uploaded the Arctica Greeter, a 
fork from Ubuntu's Unity Greeter. Arctica Greeter, like Unity Greeter, 
sends a little drum roll to the speaker, so there is indeed an accoustic 
signal that the greeter has loaded and the computer is ready for login.


The greeter has Orca support built-in, so you can enable it (or have it 
enabled by default as a system-wide setting that survives reboot of the 
computer). Orca then will read to you the different text fragments you 
find on the login screen.


I will ping you via this bug, once the Arctica Greeter has landed in 
Debian testing.


Please note that such changes as requested / proposed cannot be made in 
a Debian stable release, so we need to look forward regarding this and 
improve ourselves for Debian 10 (aka buster).


Thanks for your input!
Mike



Thank you for the information, Mike.

I'd like to add that working around this problem by activating Orca 
screen reader in the LightDM GTK+ Greeter Settings is not possible 
because the greeter hangs when doing so (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883215).


So it seems Debian 9 with Mate is currently not accessible at all to 
blind users?

Bug#866030: reopening

[Georg Faerber]

tags 866030 = upstream
thanks

(Sorry for missing In-Reply-To: and References:)

The situation improved a lot, but still, sometimes, schleuder does
FTBFS. Therefore, reopening and marking as not fixed in 3.2.1-1.

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#883216: git-cola: handle already-removed changelog in debian/rules

[Steve Langasek]

On Thu, Nov 30, 2017 at 10:28:55PM +0100, László Böszörményi (GCS) wrote:
> On Thu, Nov 30, 2017 at 9:34 PM, Steve Langasek
>  wrote:
> > git-cola was failing to build in Ubuntu, because debian/rules removes the
> > upstream changelog from /usr/share/doc/git-cola as part of the build
> > process, but Ubuntu already has code in its autobuilders to exclude upstream
> > changelogs from packages on an archive-wide basis.
>  Do you know if Debian autobuilders is going to be patched as well?

Not that I know of.  This is an Ubuntu policy decision regarding package
contents; it seems likely that Debian would instead implement any policy
changes in debhelper itself.

> > A simple one-line change
> > to use 'rm -rf' instead of 'rm -r' fixes this to ignore the case of a
> > missing file.
>  Yes, this is the easiest fix. But I think it will shadow the fact if
> the directory or relnotes.rst is no longer installed.

> > Would you consider applying this patch in Debian?
>  Would you mind if I sort of simulate the Ubuntu dh_installchangelogs
> working with:
> dh_installchangelogs -XCHANGELOG
> and the file removal is not needed anymore?

That also makes sense to me.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#883202: systemd: only sets baud rate for first console= kernel parameter

[Michael Biebl]

Am 30.11.2017 um 17:23 schrieb Joshua Marshall:
> Package: systemd
> Version: 232-25+deb9u1
> Severity: normal
> 
> Dear Maintainer,
> 
> root@debian:/home/testing# uname -a   
>   
> Linux debian 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 
> GNU/Linux
> 
> root@debian:/home/testing# systemctl --version
> systemd 232
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
> 
> root@debian:/home/testing# update-grub --version
> grub-mkconfig (GRUB) 2.02~beta3-5
> 
> 
> It seems only the first console= kernel parameter's baud rate is set once the
> system starts. I'm not entirely sure this is a systemd issue but at the very
> least grub passes the correct kernel parameters.

I don't think systemd cares for the kernel baud parameters (why should it?)


-- 
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#882755: Debian mirror debian.mirror.iweb.ca: ftpsync version

[Benjamin Navaro]

Ref: #882755

Hi,

Please note that debian.mirror.iweb.ca has now been updated with the latest 
ftpsync script.

Regards,
-Ben.

---
INAP™
Benjamin Navaro
Cloud Platform and Engineering Specialist
  

Bug#883179: dash: compiles in signals from build architecture when cross-compiled

[Jonathan Nieder]

Control: tags 883179 + upstream

Hi,

James Cowgill wrote:

> When cross-compiled, dash compiles in a list of signal names used for
> various purposes (eg kill -NAME). Unfortunately the signal names are
> generated by using the *build* compiler instead of the *host* compiler
> so the signals are incorrect when dash is actually run on the host machine.

Interesting!  I assume you're referring to src/mksignames.c.

I think this should be doable using preprocessor alone instead of
generated code.  Failing that, I think we can do something in
configure e.g. using the #warning trick.  Will look into it.

> I notice the signal generation code has been copied from bash. Newer
> versions of bash have a fix for this which initialized the list of
> signals at runtime when cross-compiled. Maybe you could copy the fix
> from bash?

I think that would go against dash's goal of being small and simple.
It might be possible to simplify the way the signal name table is used
to avoid the need for code generation altogether, though, which would
be even nicer.

Thanks,
Jonathan

Bug#861027: Can Confirm

[Barak A. Pearlmutter]

This bit me today too. In a lecture hall full of students.
Luckily I had SWI Prolog installed as well, or it would have been a serious
disaster.

--Barak.

$ cat mortal.pl

man(aristotle).
mortal(X) :- man(X).% for all X


$ gprolog
GNU Prolog 1.4.5 (64 bits)
Compiled Feb  5 2017, 10:30:08 with gcc
By Daniel Diaz
Copyright (C) 1999-2016 Daniel Diaz
| ?- ['mortal.pl'].
compiling /home/barak/tmp/mortal.pl for byte code...
/home/barak/tmp/mortal.pl compiled, 4 lines read - 356 bytes written, 6 ms

yes
| ?- mortal(barak).
uncaught exception: error(existence_error(procedure,man/0),mortal/0)
| ?- mortal(aristotle).
uncaught exception: error(existence_error(procedure,man/0),mortal/0)
| ?- man(barak).

no
| ?- man(aristotle).

yes
| ?- man(X).

X = aristotle

yes
| ?-

Bug#459427: changelog vs. NEWS handling

[Bill Allombert]

On Tue, Nov 28, 2017 at 11:01:08PM -0500, Jeremy Bicha wrote:
> As others have said, running 'git log' is far more useful than a
> complete changelog and in my experience, most projects these days
> outside of GNU don't bother shipping changelogs.
> 
> Most of my Debian and Ubuntu work involves GNOME packaging. For the
> most part, GNOME components ships NEWS files which are much more
> interesting for users or developers to read for highlights of what
> changed when.
> 
> Ubuntu took the position 7 years ago that shipping full upstream
> changelogs is a waste of space. [1] This whole situation introduces a
> bad problem: for the hundreds of packages that use
> 'dh_installchangelogs NEWS', [2] Ubuntu silently drops the NEWS file
> (renamed as changelog.gz)!
> 
> I believe Policy's advice to install upstream changelogs should be
> dropped. In its place, I think a recommendation to ship NEWS files in
> /usr/share/doc/ would be useful. Notably, debhelper does not currently
> install NEWS files unless explicitly told to.[3]

I disagree with removing this requirement.

Both the content and the name of the upstream changelogs is an upstream
issue. The fact that a file is named by upstream Changelog instead of
NEWS does not imply anything on its usefulness. It might even happen
that NEWS is the real changelog.

The fact that some upstream do not bother to ship useful changelog does
not mean that all changelog are useless, and by removing them we
discourage upstream of producing useful changelog.

git log might be more useful in some situation and extremly inconvenient
in some others (to start with it require network access and cloning
the full project history).

The ability to extract upstream changelog from .deb is useful.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#883224: pcre2: Update to new version

[Jeremy Bicha]

Source: pcre2
Version: 10.22-4
Severity: wishlist

pcre2 10.30 has been available since August. Please upgrade.

https://vcs.pcre.org/pcre2/code/trunk/NEWS?view=markup
https://vcs.pcre.org/pcre2/code/trunk/ChangeLog?view=markup

Thanks,
Jeremy Bicha

Bug#862425: closed by Matthew Vernon <matt...@debian.org> (Bug#862425: fixed in pcre2 10.22-4)

[Jeremy Bicha]

On Thu, Nov 30, 2017 at 10:21 AM, Debian Bug Tracking System
 wrote:
> #862425: pcre2: Please switch to 3.0 (quilt) or use dgit-maint-merge(7)
>
> It has been closed by Matthew Vernon .

I was unhappy with the resolution of this bug, so I opened
https://bugs.debian.org/883223

Thanks,
Jeremy Bicha

Bug#880889: zfs-linux: zvol not in /dev after upgrade to 0.7.3-1

[Antonio Russo]

Control: found -1 zfs-linux/0.6.5.11-1

This problem is not new to 0.7.3, so to avoid blocking the migration,
I'm marking this as found in the old version too.

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Rebecca N. Palmer]

Should this also make explicit which Debian suites have this restriction?

I thought this rule also applied to backports having found [0] in a list 
archive search, and hence have been explicitly changing dependencies for 
backports [1] instead of using alternatives.


However after finding this proposal, I checked build logs [2], which 
suggest that sid (including -ports architectures) and stable do but 
backports doesn't.  (Though we should probably check that with someone 
who knows this better before writing it into Policy...)


[0] https://lists.debian.org/debian-backports/2011/08/msg00089.html
[1] 
https://anonscm.debian.org/cgit/pkg-opencl/beignet.git/commit/?h=jessie-backports=b1cf2fe7c0d392cc4f99e31458e871de1fe2a574
[2] comparing "Merged Build-Depends" and "Filtered Build-Depends"; 
https://buildd.debian.org/status/logs.php?pkg=linux is a suitable example

Bug#883223: pcre2: Please switch to 3.0 (quilt)

[Jeremy Bicha]

Control: retitle -1 pcre2: Please switch to 3.0 (quilt)

I filed https://bugs.debian.org/862425 which has now been closed. I
kinda feel like my bug was hijacked by a dgit supporter. pcre2 is the
first package I've noticed where dgit is used and to put it bluntly,
it hasn't left a good impression. I'm sure I'm coming across as upset
but I waited almost 6 months and the only improvement we got is a
minimal README.

Please switch to a standard 3.0 (quilt) workflow. I assume that
dgit-maint-gbp will work fine. That way you can keep using dgit since
apparently you like it. And the packaging is actually maintained in a
way that will allow for Ubuntu developers to easily backport security
fixes.

Otherwise, I feel like Ubuntu is more or less forced to "fork" the
packaging in Ubuntu to switch to 3.0 (quilt) to have a normal, modern
workflow.

Secondly, please add Vcs fields to your debian/control . That way
someone doesn't have to find and read a README first. The Vcs fields
have nice integration on pages like
https://tracker.debian.org/pkg/mdadm

Thanks,
Jeremy Bicha

Bug#879719: libsane-hpaio: Does not recognize OfficeJet Pro 8710

[Gedalya]

On 11/30/2017 11:19 PM, Brian Potkin wrote:



  lpadmin -p 4500 -v hp:/net/envy_4500_series?ip=192.168.9.238 -E -m 
drv:///hpcups.drv/hp_envy_4500_series.ppd\
   ^
   ^
We both have access to the same manual. :)


You're right. But I'm just not following most of what you're having me 
do. Sorry..


# lpadmin -p 4500 -v hp:/net/envy_4500_series?ip=192.168.9.238 -E -m 
drv:///hpcups.drv/hp_envy_4500_series.ppd

lpadmin: Unable to copy PPD file.
# scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).

(cupsd running)


You seem to be able to scan with Bonjour enabled. If necessary, I'll
quote you on this.


Please do. I'm definitely having trouble keeping track. Either I didn't 
understand what I wrote, or possibly I should re-test, correct and clarify.




Shows that editing models.dat is incorrect.



So how does having to delete "HP_" come into the picture?



Now I really don't know what's not clear.
When did this become a matter of "correct" or "incorrect"?
Is there a bug here or am I entirely just wasting your time?
Should scanners be automatically detected, or is all this trouble part 
of the plan?
I'm trying my very best to report on a problem and I'm not trying to 
opine on what is "correct" or how it should be fixed. It's way beyond me.


The last message in this entire bug that I actually understand is the 
first one, in which I opened this bug.
I have re-read it now and I find it error-free. It seems clear and to 
the point.

Bug#883217: linux: open on NFSv4 exported file on nfs server: "Resource temporarily unavailable" under reproducible conditions when client has granted read delegation on file

[Stephen Dowdy]

On 11/30/2017 01:39 PM, Salvatore Bonaccorso wrote:
> Is this worth trying to be fixed for the jessie kernel?

Salvatore,

I believe this is likely the reason for my bug report:

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

as that system has thrown EAGAIN errors since i installed it in April, 2015.
It's a 10 NIC NFS server for the department, and often throws the error when i 
update files that are likely being read/open by client systems.
(it doesn't have a huge resource consumption load ever and i get that failure)

So, i vote yeah ;)

--stephen

-- 
Stephen Dowdy  -  Systems Administrator  -  NCAR/RAL
303.497.2869   -  sdo...@ucar.edu-  http://www.ral.ucar.edu/~sdowdy/

Bug#883098: RFS: libreoffice-texmaths/0.43-1 [ITP]

[Rene Engelhard]

Hi,

On Thu, Nov 30, 2017 at 12:49:52AM -0600, kkremit...@gmail.com wrote:
> On Wed, 2017-11-29 at 19:20 +0100, Rene Engelhard wrote:
> > On Wed, Nov 29, 2017 at 11:05:43AM -0600, kkremit...@gmail.com wrote:
> > > * Package name: libreoffice-texmaths
> > >   Version : 0.43-1
> > >   Upstream Author : Roland Baudin 
> > > * URL : htthttp://roland65.free.fr/texmaths/
> > > * License : GPL2
> > >   Section : tex
> > > 
> > > It builds those binary packages:
> > > 
> > >   libreoffice-texmaths - TexMaths is a LaTeX equation editor for
> > > LibreOffice
> > 
> > Looks good basically. What I saw, though is:
> > 
> > Depends: libreoffice-common, libreoffice-core (>= 3.3.0~),
> > libreoffice-writer, texlive, dvipng, ${misc:Depends}
> > 
> > - common and -core are superfluous (writer would depend on them
> > anyway)
> >   and 3.3.0 is there since the beginning. Even wheezy has 3.5.4
> > - README says
> > " - LibreOffice Draw (version 4 or later)
> > "
> >   so you probably want to a) add -draw b) make it >= 4.0 :-)
> > 
> > Regards,
> > 
> > Rene
> 
> 
> Thanks for the feedback. I tested the dependencies some more and
> uploaded libreoffice-texmaths-0.43-2 with the changes. To summarize:
> 
> Depends: libreoffice-draw (>= 4.0), texlive, ${misc:Depends}
> Enhances: libreoffice-writer, libreoffice-impress, libreoffice-draw

Thanks, uploaded.

No idea what's customary in these RFS bugs. Are you going to close it?
:)

Regards,

Rene

Bug#883220: RFS: ekg2/1:0.4~pre+20120506.1-14 [QA] [RC]

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "ekg2"

 * Package name: ekg2
   Version : 1:0.4~pre+20120506.1-14
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : net

  It builds those binary packages:

ekg2  - instant messenger and IRC client for UNIX systems
 ekg2-api-docs - instant messenger and IRC client for UNIX systems - 
API documenta
 ekg2-core  - instant messenger and IRC client for UNIX systems - main 
program

 ekg2-gnupg - instant messenger and IRC client for UNIX systems - GnuPG
 ekg2-jabber - instant messenger and IRC client for UNIX systems - 
Jabber/XMPP
 ekg2-scripting-perl - instant messenger and IRC client for UNIX 
systems - Perl scriptin
 ekg2-scripting-python - instant messenger and IRC client for UNIX 
systems - Python script
 ekg2-ui-gtk - instant messenger and IRC client for UNIX systems - GTK+ 
interfac
 ekg2-ui-ncurses - instant messenger and IRC client for UNIX systems - 
ncurses inter


  To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/ekg2

  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/e/ekg2/ekg2_0.4~pre+20120506.1-14.dsc


  Changes since the last upload:

  * QA upload.
  * Add patch taken from Mageia to fix FTBFS with OpenSSL 1.1.0.
(Closes: #828292)
  * debian/control:
- ekg2-scripting-*: Add dependency "Suggests: ekg2-api-docs"
 (Closes: #849599)
- ekg2: remove Suggests: sms-pl - it has been removed from
repository 7 years ago.
- Bump Standards-Version to 4.1.1.


  Regards,
   Mateusz Łukasik

Bug#883183: libdbd-firebird-perl FTBFS on i386: t/embed-rt110979.t failure

[Damyan Ivanov]

Control: tags -1 confirmed

-=| Adrian Bunk, 30.11.2017 14:06:34 +0200 |=-
> Source: libdbd-firebird-perl
> Version: 1.26-1
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=libdbd-firebird-perl=i386=1.26-1=1511985831=0

I am able to reproduce this in a (freshly created) i386 sbuild chroot.

Not really sure what is going on, the upstream changes since 1.25 
don't seem relevant.

Ah, trying 1.25-1 builds OK, but most of the tests aren't run, because 
libfbembed is not found. The "detect Firebird API version even when 
patch are supplied via environment" is relevant, because API version 
30+ is used to check whether libfbclient2 can be used in embedded 
mode.

So it seems the root bug was there with 1.25-1 too, just not triggered 
because the embedded tests weren't run.

> DBD::FirebirdEmbedded::st finish failed: Firebird error
> -invalid database handle (no active connection) at t/embed-rt110979.t line 68.
> # Tests were run but no plan was declared and done_testing() was not seen.
> # Looks like your test exited with 255 just after 7.
> t/embed-rt110979.t .. 
> ok 1 - Connected to the database
> ok 2 - Table is 'TESTAA'
> ok 3 - CREATE TABLE 'TESTAA'
> ok 4 - create generator gen_TESTAA
> ok 5 - create trigger TESTAA_bi
> ok 6 - Insert worked
> ok 7 - Autoinc PK retrieved
> Dubious, test returned 255 (wstat 65280, 0xff00)
> All 7 subtests passed 

Bug#879719: libsane-hpaio: Does not recognize OfficeJet Pro 8710

[Brian Potkin]

On Thu 30 Nov 2017 at 18:34:22 +0100, Gedalya wrote:

> On 11/30/2017 03:11 PM, Brian Potkin wrote:
> > I wonder how you would go on with the queue
> >
> >
> >  lpadmin -p 4500 hp:/net/envy_4500_series?ip=192.168.9.238 -E -m 
> > drv:///hpcups.drv/hp_envy_4500_series.ppd\
> 
> lpadmin: Unknown argument "hp:/net/envy_4500_series?ip=192.168.9.238".
> 
> not sure where to go from here.

 lpadmin -p 4500 -v hp:/net/envy_4500_series?ip=192.168.9.238 -E -m 
drv:///hpcups.drv/hp_envy_4500_series.ppd\
  ^
  ^
We both have access to the same manual. :)
  
> > and 'scanimage -L'?
> >  
> >
> >  
> >> After re-enabling Bonjour, I noticed something new.
> >> With the original models.dat, I get in syslog, regardless or cupsd running 
> >> or not:
> >>
> >> scanimage: io/hpmud/model.c 532: no officejet_pro_8710 attributes found in 
> >> /usr/share/hplip/data/models/models.dat
> >>
> >> with cupsd running, the output is:
> >>
> >> device `hpaio:/net/HP_OfficeJet_Pro_8710?ip=192.168.9.238' is a 
> >> Hewlett-Packard HP_OfficeJet_Pro_8710 all-in-one
> >>
> >> with cupsd stopped, the scanner is not found, as before.
> >>
> >>
> >> now, with the edited file hp_ removed, cupsd running:
> >>
> >> device `hpaio:/net/officejet_pro_8710?ip=192.168.9.238=false' is a 
> >> Hewlett-Packard officejet_pro_8710 all-in-one
> >>
> >> and syslog:
> >>
> >> scanimage: io/hpmud/model.c 532: no HP_OfficeJet_Pro_8710 attributes found 
> >> in /usr/share/hplip/data/models/models.dat
> >>
> >> cupsd stopped:
> >>
> >> device `hpaio:/net/officejet_pro_8710?ip=192.168.9.238=false' is a 
> >> Hewlett-Packard officejet_pro_8710 all-in-one
> >>
> >> nothing in syslog.
> >>
>  There is, the other printer was HP AIO too, but it's a different model.
> >>> I'm a little lost here, but if libsane-hpaio and libhpmud are on the
> >>> system then the 8710 scanning function should be detectable from its
> >>> Bonjour broadcasts wih 'scanimage -L'
> >> Yes, and it's not working, that's what this bug is about.
> > I thought you had shown at the beginning of this mail that scanning is
> > being done due to Bonjour?
> 
> This bug is to report that it is impossible to use the OfficeJet Pro 8710 as 
> a scanner without doing one of the following:
> * configure the printer function in cups, and keep cupsd running
> * edit models.dat

You seem to be able to scan with Bonjour enabled. If necessary, I'll
quote you on this.
 
> >
> > Incidently. how do you on with
> >
> >  scanimage -vv -d hpaio:/net/HP_OfficeJet_Pro_8710?ip=192.168.9.238 > 
> > image.pnm ?
> >
> > Bonjour is not involved with this command and a print queue is not
> > necessary for it to be successful.
> >
> 
> Yes, works fine, original models.dat, on desktop and laptop, cupsd running or 
> not.

That's what is expected.

> edited models.dat produces:
> 
> scanimage: open of device hpaio:/net/HP_OfficeJet_Pro_8710?ip=192.168.9.238 
> failed: Operation not supported

Shows that editing models.dat is incorrect.

> Calling sane_exit
> scanimage: finished
> 
> OK so not "impossible" to use the scanner ;-)

So how does having to delete "HP_" come into the picture?

Cheers,

Brian,

Bug#883221: RFS: smplayer/17.11.2~ds0-1

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "smplayer"

 * Package name: smplayer
   Version : 17.11.2~ds0-1
   Upstream Author : Ricardo Villalba 
 * URL : http://smplayer.sourceforge.net/
 * License : GPL-2+
   Section : video

  It builds those binary packages:

smplayer   - Complete front-end for MPlayer and mpv
 smplayer-l10n - Complete front-end for MPlayer and mpv - translation files

  To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/smplayer


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/s/smplayer/smplayer_17.11.2~ds0-1.dsc


  Changes since the last upload:
  * New upstream release.
  * Bump Standards-Version to 4.1.1.
  * Change smplayer-l10n section to localization.


  Regards,
   Mateusz Łukasik

Bug#883222: RFS: gxkb/0.8.0-1

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "gxkb"

 * Package name: gxkb
   Version : 0.8.0-1
   Upstream Author : Dmitriy Poltavchenko 
 * URL : http://sourceforge.net/projects/gxkb/
 * License : GPL-2+
   Section : x11

  It builds those binary packages:

gxkb  - X11 keyboard indicator and switcher

  To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/gxkb


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/g/gxkb/gxkb_0.8.0-1.dsc


  Changes since the last upload:

  * New upstream release.
  * Bump Standards-Version to 4.1.1 (no changes needed).


  Regards,
   Mateusz Łukasik

Bug#882263: libc6-dev-mips64el-cross breaks linking executables

[Aurelien Jarno]

On 2017-11-20 21:42, Helmut Grohne wrote:
> Package: libc6-dev-mips64el-cross
> Version: 20
> Severity: serious
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> I was trying to use gcc-mips64el-linux-gnuabi64 to link a trivial
> executable:
> 
> $ echo 'int main(){return 0;}' | mips64el-linux-gnuabi64-gcc -x c - -o 
> /dev/null
> 
> With libc6-dev:mips64el installed, this just works. As soon as I install
> libc6-dev-mips64el-cross, it fails though:
> 
> /usr/lib/gcc-cross/mips64el-linux-gnuabi64/7/../../../../mips64el-linux-gnuabi64/bin/ld:
>  cannot find /usr/mips64el-linux-gnuabi64/lib/ld.so.1
> collect2: error: ld returned 1 exit status
> 
> This renders libc6-dev-mips64el-cross pretty much useless.

This is due to the following change, introduced in
cross-toolchain-base-20:

diff -Nru cross-toolchain-base-19/debian/dpkg-cross 
cross-toolchain-base-20/debian/dpkg-cross
--- cross-toolchain-base-19/debian/dpkg-cross   2016-01-21 08:48:01.0 
+
+++ cross-toolchain-base-20/debian/dpkg-cross   2017-11-19 22:01:44.0 
+
@@ -1026,6 +1026,11 @@
# Skip links that are going to point to themselves
next if ($lv eq $_);
 
+   # skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
+   # their ld.so.1 should be in lib32 and lib64.
+   next if ($multiarch =~ m/^mips[n32,64]/ && $_ =~ 
m/lib\/ld.so.1$/);
+
+   # m/lib\/ld.so.1$/);
# skip links to private modules and plugins that are not
# useful or packaged in the -cross package, basically anything
# in a directory beneath /usr/lib/. See #499292

I don't really see the point of this change, and why it would be
different the s390x cross-libc for example, which has ld64.so.1 in
/usr/s390x-linux-gnu/lib/ while the rtld directory is /lib64. Removing
this file has the same effect:

| $ echo 'int main(){return 0;}' | s390x-linux-gnu-gcc  -x c - -o /dev/null 
| $ sudo rm /usr/s390x-linux-gnu/lib/ld64.so.1  
| $ echo 'int main(){return 0;}' | s390x-linux-gnu-gcc  -x c - -o /dev/null 
| /usr/lib/gcc-cross/s390x-linux-gnu/7/../../../../s390x-linux-gnu/bin/ld: 
cannot find /usr/s390x-linux-gnu/lib/ld64.so.1
| collect2: error: ld returned 1 exit status

It therefore looks like to me that this hunk has to be reverted.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#862425: pcre2: Please switch to 3.0 (quilt)

[Sean Whitton]

Hello Jeremy,

On Thu, Nov 30 2017, Jeremy Bicha wrote:

> I still strongly urge you to switch to the popular 3.0 (quilt) source
> format. Maybe the dgit-maint-gbp workflow would work for this. I don't
> know. I touch a very large number of Debian/Ubuntu packages and
> git-buildpackage is far more popular than dgit in my experience.

Yes, dgit-maint-gbp(7) works fine with 3.0 (quilt).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#786470: debian-policy: [copyright-format] Add an optional “License-Grant” field

[Sean Whitton]

Hello Simon,

On Thu, Nov 30 2017, Simon McVittie wrote:

> I assume a normative change to the available fields, and to the
> meaning of License, would make this be copyright format 1.1?

I spoke to Russ about this and I think we want to avoid bumping the
version number unless we make an incompatible change.  It just creates
work for people.  Adding a strictly optional field can be done without
doing this.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#882445: Proposed change of offensive packages to -offensive [and 1 more messages]

[Sean Whitton]

control: tag -1 -patch +pending

Hello Ian,

On Thu, Nov 30 2017, Ian Jackson wrote:

>> Is this a proposal/seconding of the modified patch?
>
> Sure.

Thanks for confirming that.

> Thanks for keeping on top of this.
>
> But, I guess you already know that I think that this is excessive
> bureaucracy.  You do know it's self-imposed ?

Indeed, I think you have a point, but I cannot imagine an alternative
procedure that wouldn't leave package maintainers feeling beholden to
the Policy Editors in a way that would be bad for the project.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#883067: transition: ntfs-3g

[GCS]

On Thu, Nov 30, 2017 at 7:34 PM, Emilio Pozuelo Monfort
 wrote:
> On 29/11/17 10:07, László Böszörményi (GCS) wrote:
>> Mini transition of ntfs-3g which changed the library name from
>> libntfs-3g872 to libntfs-3g88 .
[...]
> Go ahead.
 Thanks, uploaded and its building started on the supported architectures.

Laszlo/GCS

Bug#882308: http-parser 2.7 breaks ruby-em-http-request's tests

[Christoph Biedl]

Control: tags 882308 confirmed help

No clue, I don't speak Ruby and after some looking around I'm rather
lost and could use some advice.

Matthias Klose wrote...

> 1) EventMachine::HttpRequest should close connection on
> invalid HTTP response Failure/Error: if !client.continue?
> 
>   NoMethodError:
>   undefined method `continue?' for
> nil:NilClass#

The thing that puzzles me is the "nil:NilClass" - it's probably
supposed to be "EventMachine::HttpClient" so I assume initialization
failed but this did not abort program execution.

Christoph


signature.asc
Description: Digital signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Sean Whitton]

control: tag -1 +pending

Hello Simon,

On Thu, Nov 30 2017, Simon McVittie wrote:

> 6½ years later, ideally this would mention Build-Depends-Arch too.
>
> Other than that, seconded. I'm not sure whether this is necessarily
> how the autobuilders *should* work, but there's value in documenting
> how the autobuilders *do* work.

Thank you for reviewing this bug.

Since Sean's patch doesn't require anything of package maintainers, it's
what we call "informative", and we don't need formal seconds.  So I'm
going to go ahead and apply the patch.

We're trying to reduce the number of footnotes in Policy, but in this
case I can't see a place to insert the text without interrupting the
flow.  I'm going ahead and adding it as a footnote, but I would
appreciate any suggestions for where else the text could go.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#665916: usbmuxd: don't use /home/ for the users homedir

[Yves-Alexis Perez]

On Tue, 27 Mar 2012 02:20:25 +0200 Christoph Anton Mitterer  wrote:
> Package: usbmuxd
> Version: 1.0.7-2
> Severity: normal
> 
> 
> Hi.
> 
> Currently the maintainer scripts set the homedir for this package to be
> in /home/.
> As this is system user, I'd say this is rather bad style.
> 
> Could you please move this to something more reasonable and also change
> it for upgraded systems?

Current usbmuxd uses /var/lib/usbmux. I'm unsure about changing it for
upgrades since that might involve moving files from /home folder.

Regards,
-- 
Yves-Alexis

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

Bug#883101: tracker.d.o no longer shows RM bugs

[Pierre-Elliott Bécue]

Control: tags -1 patch

Here are two patches to solve the bug. They might need some rework, as I'm
not quite sure I did my best here.

Essentially, the issue was the Python3 transition: the file wnpp_rm is
treated as bytes, but the function receiving it and analyzing was expecting
content of type str.

I used a function I wrote for a previous feature request to ensure that the
content is decoded.

Cheers,

-- 
PEB
From 144960dfc453fc5d97913854bdf50ecf7051f86c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Elliott=20B=C3=A9cue?= 
Date: Thu, 30 Nov 2017 22:29:21 +0100
Subject: [PATCH 1/2] Adds an only_if_updated argument to
 get_resource{content,text}

 If set to True, then both functions return None instead of the content
---
 distro_tracker/core/tests/tests_utils.py | 84 
 distro_tracker/core/utils/http.py| 28 +--
 2 files changed, 88 insertions(+), 24 deletions(-)

diff --git a/distro_tracker/core/tests/tests_utils.py b/distro_tracker/core/tests/tests_utils.py
index 572d31f..d5e6d9b 100644
--- a/distro_tracker/core/tests/tests_utils.py
+++ b/distro_tracker/core/tests/tests_utils.py
@@ -771,6 +771,12 @@ class HttpCacheTest(SimpleTestCase):
 headers=headers,
 status_code=status_code)
 
+@staticmethod
+def cache_is_expired_false(self):
+"""Function to override cache.is_expired when needed"""
+
+return False
+
 def setUp(self):
 # Set up a cache directory to use in the tests
 self.cache_directory = tempfile.mkdtemp(suffix='test-cache')
@@ -1091,42 +1097,82 @@ class HttpCacheTest(SimpleTestCase):
 content = cache.get_content(url, compression=None)
 self.assertEqual(content, b"Hello world!")
 
-def test_get_resource_content_utility_function_cached(self):
+@mock.patch('distro_tracker.core.utils.http.requests')
+def test_get_resource_content_utility_function_cached(self, mock_requests):
 """
 Tests the :func:`distro_tracker.core.utils.http.get_resource_content`
 utility function when the resource is cached in the given cache
 instance.
 """
-mock_cache = mock.create_autospec(HttpCache)
-mock_cache.is_expired.return_value = False
-expected_content = b"Some content"
-mock_cache.get_content.return_value = expected_content
+self.response_content = b"Hello world!"
+self.set_mock_response(mock_requests)
+cache = HttpCache(self.cache_directory)
 url = 'http://some.url.com'
 
-content = get_resource_content(url, cache=mock_cache)
-
 # The expected content is retrieved
-self.assertEqual(content, expected_content)
-# The function did not update the cache
-self.assertFalse(mock_cache.update.called)
+content = get_resource_content(url, cache=cache)
+self.assertEqual(content, self.response_content)
 
-def test_get_resource_content_utility_function_not_cached(self):
+# Forces the cache to return False when asked if something is expired.
+cache.is_expired = self.cache_is_expired_false
+
+# To make sure that .update is not called, we shoot the function once
+# with only_if_updated set to True. The return has to be None if
+# .update is not called.
+content = get_resource_content(url, cache=cache, only_if_updated=True)
+self.assertIsNone(content)
+
+# Then, call again without only_if_updated.
+content = get_resource_content(url, cache=cache)
+self.assertEqual(content, self.response_content)
+
+@mock.patch('distro_tracker.core.utils.http.requests')
+def test_get_resource_content_utility_function_not_cached(self,
+  mock_requests):
 """
 Tests the :func:`distro_tracker.core.utils.http.get_resource_content`
 utility function when the resource is not cached in the given cache
 instance.
 """
-mock_cache = mock.create_autospec(HttpCache)
-mock_cache.is_expired.return_value = True
-expected_content = b"Some content"
-mock_cache.get_content.return_value = expected_content
+self.response_content = b"Hello world!"
+self.set_mock_response(mock_requests)
+cache = HttpCache(self.cache_directory)
 url = 'http://some.url.com'
 
-content = get_resource_content(url, mock_cache)
+content = get_resource_content(url, cache=cache)
+self.assertEqual(content, self.response_content)
+
+# Forces the cache to return False when asked if something is expired.
+cache.is_expired = self.cache_is_expired_false
+
+# If the cache is filled, then a call with only_if_updated will return
+# None.
+content = get_resource_content(url, cache=cache, only_if_updated=True)
+self.assertIsNone(content)
+
+

Bug#867817: jessie-pu: package ncurses/5.9+20140913-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2017-09-06 at 19:02 +0200, Sven Joachim wrote:
> On 2017-08-12 19:24 +0200, Sven Joachim wrote:
> 
> > Control: tags -1 - moreinfo
> > 
> > On 2017-07-15 12:54 +0200, Sven Joachim wrote:
> > 
> > > On 2017-07-15 11:38 +0100, Adam D. Barratt wrote:
> > > 
> > > > Control: tags -1 + confirmed
> > > > 
> > > > On Sun, 2017-07-09 at 19:40 +0200, Sven Joachim wrote:
> > > > > The same problem as in #867814 for stretch and almost the
> > > > > same fix,
> > > > > except that one inapplicable hunk has been removed from the
> > > > > patch.
> > > > 
> > > > Please go ahead.
> > > 
[...]
> > > As in #867814, I would like to fix the seven new CVEs 2017-
> 137{28..34}
> as well.  The two additional patches are the same as the ones for
> stretch (modulo line numbers, since I ran "quilt refresh").
> 

+  * Cerry-pick upstream fixes from the 20170902 patchlevel to fix

s/Cerry/Cherry/

Please go ahead.

Regards,

Adam

Bug#883216: git-cola: handle already-removed changelog in debian/rules

[GCS]

Control: tags -1 +pending

Hi Steve,

On Thu, Nov 30, 2017 at 9:34 PM, Steve Langasek
 wrote:
> git-cola was failing to build in Ubuntu, because debian/rules removes the
> upstream changelog from /usr/share/doc/git-cola as part of the build
> process, but Ubuntu already has code in its autobuilders to exclude upstream
> changelogs from packages on an archive-wide basis.
 Do you know if Debian autobuilders is going to be patched as well?

> A simple one-line change
> to use 'rm -rf' instead of 'rm -r' fixes this to ignore the case of a
> missing file.
 Yes, this is the easiest fix. But I think it will shadow the fact if
the directory or relnotes.rst is no longer installed.

> Would you consider applying this patch in Debian?
 Would you mind if I sort of simulate the Ubuntu dh_installchangelogs
working with:
dh_installchangelogs -XCHANGELOG
and the file removal is not needed anymore?

Regards,
Laszlo/GCS

Bug#883219: udev: There is not connection with BLACKVIEW P2 lite

[ΑΘΑΝΑΣΙΟΣ]

Package: udev
Version: 232-25+deb9u1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser  3.115
ii  dpkg 1.18.24
ii  libacl1  2.2.52-3+b1
ii  libblkid12.29.2-1
ii  libc62.24-11+deb9u1
ii  libkmod2 23-2
ii  libselinux1  2.6-3+b3
ii  libudev1 232-25+deb9u1
ii  lsb-base 9.20161125
ii  procps   2:3.3.12-3
ii  util-linux   2.29.2-1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  232-25+deb9u1

-- debconf information:
  udev/new_kernel_needed: false
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:
  udev/title/upgrade:
P: /devices/LNXSYSTM:00
E: DEVPATH=/devices/LNXSYSTM:00
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXSYSTM:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7874074

P: /devices/LNXSYSTM:00/LNXCPU:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7874954

P: /devices/LNXSYSTM:00/LNXCPU:01
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7874490

P: /devices/LNXSYSTM:00/LNXCPU:02
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7874506

P: /devices/LNXSYSTM:00/LNXCPU:03
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7874486

P: /devices/LNXSYSTM:00/LNXCPU:04
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:04
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7874526

P: /devices/LNXSYSTM:00/LNXCPU:05
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:05
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7874926

P: /devices/LNXSYSTM:00/LNXPWRBN:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: DRIVER=button
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXPWRBN:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7875264

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
E: EV=3
E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: KEY=10 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PRODUCT=19/0/1/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=8880273

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event3
N: input/event3
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event3
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event3
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: LIBINPUT_DEVICE_GROUP=19/0/1/0:LNXPWRBN/button
E: MAJOR=13
E: MINOR=67
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=11197047
E: XKBLAYOUT=us,gr
E: XKBMODEL=pc105
E: XKBOPTIONS=grp:alt_shift_toggle,grp_led:scroll
E: XKBVARIANT=,

P: /devices/LNXSYSTM:00/LNXSYBUS:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:LNXSYBUS:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7874958

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:PNP0A03:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7875404

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/INTC0102:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/INTC0102:00
E: ID_VENDOR_FROM_DATABASE=Interphase Corporation
E: MODALIAS=acpi:INTC0102:PNP0C31:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7875880

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C02:03
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C02:03
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: MODALIAS=acpi:PNP0C02:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7875982

P: 

Bug#760945: fixed in smokeping 2.6.11-4

[Sven Hartge]

On 30.11.2017 22:24, Antoine Beaupré wrote:
> On 2017-11-30 21:54:57, Sven Hartge wrote:

>> You need to change the code in postinst to
>>
>>chown smokeping:www-data /etc/smokeping/smokeping_secrets
> 
> can you cook me a patch for that?

No problem, see attachment.

Grüße,
Sven.
From 9ebc28f37e74723e3f4a867bec8c8e3d4c8fa269 Mon Sep 17 00:00:00 2001
From: Sven Hartge 
Date: Thu, 30 Nov 2017 22:26:23 +0100
Subject: [PATCH] Change group of secrets file for slaves to www-data
Cc: s...@svenhartge.de

Signed-off-by: Sven Hartge 
---
 debian/postinst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/postinst b/debian/postinst
index 16c379b..e15c8ea 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -31,7 +31,7 @@ setup_permissions() {
 chown www-data /var/cache/smokeping/images
 chown smokeping:www-data /var/lib/smokeping/__cgi
 chmod 2775 /var/lib/smokeping/__cgi
-chown smokeping:smokeping /etc/smokeping/smokeping_secrets
+chown smokeping:www-data /etc/smokeping/smokeping_secrets
 chmod 640 /etc/smokeping/smokeping_secrets
 }
 
-- 
2.15.0



signature.asc
Description: OpenPGP digital signature

Bug#817942: usbmuxd: /var/lib/lockdown/SystemConfiguration.plist not removed on purge

[Yves-Alexis Perez]

On Fri, 11 Mar 2016 21:04:38 +0100 Alexandre Detiste  wrote:
> Package: usbmuxd
> Version: 1.1.0-2+b1
> Severity: normal
> 
> 
> 
> This is not a duplicate of #562817.
> 
> 
> The directory /var/lib/lockdown can be created
> by usbmuxd with a single file called "SystemConfiguration.plist".
> 
> Code is here, a bit obfuscated by all the defines:
> https://sources.debian.net/src/usbmuxd/1.1.0-2/src/conf.c
> 
> This happened when someone used my laptop's
> usb port to charge up his iPhone.
> 
> 
> This file is never removed on purge.
> 
> So just please "rm -rf /var/lib/lockdown" in postrm.
> 

Hi,

I'm considering NMU-ing usbmuxd to update it to a more recent git snapshot.

I'm not really sure we want to remove completely the lockdown directory, even
at purge time. That directory will contains pairing records to various
idevices (usually managed by idevicepair). If there are records there, I don't
really think we want to remove them.

Maybe it'd be enough to rm /var/lib/lockdown/SystemConfiguration.plist ; rmdir
/var/lib/lockdown || true

That way, if usbmuxd was never used to actually pair an iphone/ipad, the
cleanup would be done, but otherwise no pairing record would be lost (that
beeing said, if the package is reinstalled later, the
SystemConfiguration.plist will be recreated, maybe with a different ID so I'm
unsure the pairing records will still be valid).

Regards,
-- 
Yves-Alexis

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

Bug#760945: fixed in smokeping 2.6.11-4

[Antoine Beaupré]

On 2017-11-30 21:54:57, Sven Hartge wrote:
> reopen 760945
> thanks
>
> On 30.11.2017 19:20, Antoine Beaupré wrote:
>
>>* fix slave permissions configuration - thanks Sven Hartge (Closes: 
>> #760945)
>
> Unfortunately this is still not closed. You fixed the "dyndir" issue,
> but the smokeping_secrets file still has the wrong permissions after
> installation/upgrade.
>
> You need to change the code in postinst to
>
>chown smokeping:www-data /etc/smokeping/smokeping_secrets

can you cook me a patch for that?

the code is in collab-maint too, i'd be happy to welcome
co-maintainers...

see also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824712

a.

-- 
We tend to overestimate the effect of a technology in the short run and
underestimate the effect in the long run.
- Roy Amara

Bug#820910: apt no longer verifies repositories using sha1 hash

[Ben Longbons]

Package: apt
Version: 1.4.8
Followup-For: Bug #820910

Dear Maintainer,

This also affects pulling old stuff from snapshots.debian.org ... which
is a lot more useful when you can put `[check-valid-until=no]` in
sources.list, which is only in recent apt.

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (no /etc/apt/sources.list.d/* present) --


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-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 apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2017.5
ii  gpgv2.1.18-8~deb9u1
ii  init-system-helpers 1.48
ii  libapt-pkg5.0   1.4.8
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18
ii  libstdc++6  6.3.0-18

Versions of packages apt recommends:
ii  gnupg   2.1.18-8~deb9u1
ii  gnupg2  2.1.18-8~deb9u1

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.7-1
ii  dpkg-dev1.18.24
ii  powermgmt-base  1.31+nmu1
pn  python-apt  

-- no debconf information

Bug#876521: FTBFS with CGAL 4.11

[Sebastiaan Couwenberg]

Hi Joachim,

On 11/30/2017 08:11 PM, Joachim Reichel wrote:
> On 12.11.2017 22:20, Sebastiaan Couwenberg wrote:
>> You shouldn't have waited for this issue to request the transition slot.
>> As I said before, I'll remove the SFCGAL dependency from PostGIS if this
>> issue is not resolved when the CGAL transition starts. That way we can
>> keep postgis is testing.
> 
> Don't worry, sfcgal was not the only reverse dependency that needs more than a
> binNMU.

Thanks for the notice. I've just uploaded a new revision of postgis
without SFCGAL support.

Hopefully upstream will fix this issue soon. Otherwise I'll have the
sfcgal package removed from Debian.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#760945: fixed in smokeping 2.6.11-4

[Sven Hartge]

reopen 760945
thanks

On 30.11.2017 19:20, Antoine Beaupré wrote:

>* fix slave permissions configuration - thanks Sven Hartge (Closes: 
> #760945)

Unfortunately this is still not closed. You fixed the "dyndir" issue,
but the smokeping_secrets file still has the wrong permissions after
installation/upgrade.

You need to change the code in postinst to

   chown smokeping:www-data /etc/smokeping/smokeping_secrets

to fully fix the problem.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#883218: RFS: elpy/1.17.0-1 [ITP]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "elpy"

Package name: elpy
Version : 1.17.0-1
Upstream Author : Jorgen Schaefer 
URL : https://github.com/jorgenschaefer/elpy
License : GPL-3+
Section : lisp

It builds this binary package:

elpa-elpy  - Emacs Python Development Environment

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/elpy

Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.17.0-1.dsc

Alternatively, one can clone the package repository with git:

git clone ssh://git.debian.org/git/pkg-emacsen/pkg/elpy.git

More information about elpy can be obtained from https://elpy.readthedocs.io/


Regards,
Nicholas D Steeves

Bug#883217: linux: open on NFSv4 exported file on nfs server: "Resource temporarily unavailable" under reproducible conditions when client has granted read delegation on file

[Salvatore Bonaccorso]

Source: linux
Version: 3.16.7-ckt25-2
Severity: important
Tags: upstream
Control: fixed -1 3.18-1~exp1

[the fixed version is assuming the bisect result is right]

Hi

This was originally reported in the debian-user mailinglist at [1],
followup [2] and [3] and it might be actually a duplicate of #855632.
It sounds very simliar, so we might merge the bugs if turns to be the
case.

On a NFSv4 exported filesystem, one might see regularly "Resource
temporarily unavailable" when trying to open a file for which a client
has been granted read delegation on the file. In my case it was noted
while regularly clients access and execute a script on such export and
on server side the script needed to be updated. But simlilary as well
as in #855632's case where the file was read by a client, whilest from
another system scp'ing a new version to the server.

Steps to reproduce with minimalized customized settings (at least
tried):

root@nfs-test:~# apt-get install nfs-kernel-server
root@nfs-test:~# mkdir -p /srv/test
root@nfs-test:~# echo '/srv/test *' >> /etc/exports
root@nfs-test:~# systemctl restart nfs-kernel-server.service
root@nfs-test:~# mount localhost:/srv/test /mnt
root@nfs-test:~# grep '/mnt' /proc/mounts
localhost:/srv/test /mnt nfs4 
rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1
 0 0
root@nfs-test:~#

on one terminal
root@nfs-test:~# while : ; do date >/srv/test/foo ; sleep 1 ; done

and on a second
root@nfs-test:~# while : ; do cat /mnt/foo ; sleep 1 ; done

within a couple of minutes

root@nfs-test:~# mount localhost:/srv/test /mnt
root@nfs-test:~# while : ; do date >/srv/test/foo ; sleep 1 ; done
-bash: /srv/test/foo: Resource temporarily unavailable

I tried to bisect, although in the "fixed" case it might not have been
correct that it's actually fixed, so this is more empirical result,
whereas when running a 'broken' kernel, that occured within a couple
of minutes.

cut-cut-cut-cut-cut-cut-
git bisect start '--term-old' 'broken' '--term-new' 'fixed'
# broken: [754c780953397dd5ee5191b7b3ca67e09088ce7a] Merge branch 'for-v3.18' 
of git://git.linaro.org/people/mszyprowski/linux-dma-mapping
git bisect broken 754c780953397dd5ee5191b7b3ca67e09088ce7a
# fixed: [2d65a9f48fcdf7866aab6457bc707ca233e0c791] Merge branch 'drm-next' of 
git://people.freedesktop.org/~airlied/linux
git bisect fixed 2d65a9f48fcdf7866aab6457bc707ca233e0c791
# fixed: [5e40d331bd72447197f26525f21711c4a265b6a6] Merge branch 'next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
git bisect fixed 5e40d331bd72447197f26525f21711c4a265b6a6
# broken: [a2ce35273c2f1aa0dcddd8822681d64ee5f31852] Merge tag 'sound-3.18-rc1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect broken a2ce35273c2f1aa0dcddd8822681d64ee5f31852
# fixed: [81ae31d78239318610d7c2acb3e2610d622a5aa4] Merge tag 
'stable/for-linus-3.18-rc0-tag' of 
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
git bisect fixed 81ae31d78239318610d7c2acb3e2610d622a5aa4
# broken: [ac0c49396d5ed9a33f08ce661635ac1bff80bb4f] Merge branch 'for_linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
git bisect broken ac0c49396d5ed9a33f08ce661635ac1bff80bb4f
# broken: [e6c4efd87ab04e5ead363f24e6ac35ed3506d401] btrfs: Fix and enhance 
merge_extent_mapping() to insert best fitted extent map
git bisect broken e6c4efd87ab04e5ead363f24e6ac35ed3506d401
# broken: [90d0c376f5ee1927327b267faf15bf970476f09e] Merge branch 'for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
git bisect broken 90d0c376f5ee1927327b267faf15bf970476f09e
# fixed: [6e129d00689c4d75253d1d428e82047b0aef5891] locks: flock_make_lock 
should return a struct file_lock (or PTR_ERR)
git bisect fixed 6e129d00689c4d75253d1d428e82047b0aef5891
# broken: [bfe8602436c803c6d5e271d52cd985d491a7470a] locks: close potential 
race in lease_get_mtime
git bisect broken bfe8602436c803c6d5e271d52cd985d491a7470a
# broken: [1c7dd2ff430fa14b45c9def54468e3a25ab8342b] locks: define a lm_setup 
handler for leases
git bisect broken 1c7dd2ff430fa14b45c9def54468e3a25ab8342b
# broken: [843c6b2f4cef384af8e0de6b7ac7191675030e3a] locks: remove 
i_have_this_lease check from __break_lease
git bisect broken 843c6b2f4cef384af8e0de6b7ac7191675030e3a
# fixed: [4d01b7f5e7576858b71cbaa72b541e17a229cb91] locks: give lm_break a 
return value
git bisect fixed 4d01b7f5e7576858b71cbaa72b541e17a229cb91
# fixed: [03d12ddf845a4eb874ffa558d65a548aee9b715b] locks: __break_lease 
cleanup in preparation of allowing direct removal of leases
git bisect fixed 03d12ddf845a4eb874ffa558d65a548aee9b715b
# first fixed commit: [03d12ddf845a4eb874ffa558d65a548aee9b715b] locks: 
__break_lease cleanup in preparation of allowing direct removal of leases
cut-cut-cut-cut-cut-cut-

The above commit leads to 

Bug#856628: live-wrapper: Fails with AttributeError: 'Package' object has no attribute 'version_list'

[Alf Gaida]

should be a dup. of 854204 
- did not
occour with current builds

Bug#883216: git-cola: handle already-removed changelog in debian/rules

[Steve Langasek]

Package: git-cola
Version: 3.0-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Hi Laszlo,

git-cola was failing to build in Ubuntu, because debian/rules removes the
upstream changelog from /usr/share/doc/git-cola as part of the build
process, but Ubuntu already has code in its autobuilders to exclude upstream
changelogs from packages on an archive-wide basis.  A simple one-line change
to use 'rm -rf' instead of 'rm -r' fixes this to ignore the case of a
missing file.

Would you consider applying this patch in Debian?

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru git-cola-3.0/debian/rules git-cola-3.0/debian/rules
--- git-cola-3.0/debian/rules   2017-11-26 09:39:34.0 -0800
+++ git-cola-3.0/debian/rules   2017-11-30 11:13:54.0 -0800
@@ -49,7 +49,7 @@
dh_testdir
dh_testroot
dh_installchangelogs 
-   rm -r $(PKGDIR)/usr/share/doc/git-cola/changelog \
+   rm -rf $(PKGDIR)/usr/share/doc/git-cola/changelog \
$(PKGDIR)/usr/share/doc/git-cola/html/sources/
dh_installdocs
dh_installexamples

Bug#883215: [Accessibility] LightDM GTK+ Greeter hangs after enabling Orca

[sirgazil]

Package: lightdm-gtk-greeter
Version: 2.0.2-1


Dear maintainer,

I'm using Debian Linux zenme 4.9.0-4-686-pae #1 SMP Debian 4.9.51-1 
(2017-09-28) i686 GNU/Linux with Mate 1.16.2-2.


After enabling the Orca screen reader for the greeter, the login screen 
hangs everytime a user tries to log in.



Steps to reproduce
==

1. Log in to the Mate desktop.
2. Install lightdm-gtk-greeter-settings (1.2.1-2).
3. Open System → Administration → LightDM GTK+ Greeter Settings.
4. Click on the "Misc." tab.
5. In the "Accessibility" section, tick the "Reader" check box.
6. Select "orca" in "Command to launch screen reader" field.
7. In the dropdown below the previous field, select either "Enable at 
start" or the third option.

8. Click the Save button.
9. Click the Close button.
10. Restart the system.


Expected result
===

The system becomes accessible to blind users.

1. The login screen loads.
2. Orca informs the user that the screen reader is active.
3. The blind user enters username and password with the assistance of 
the reader.

4. The blind user logs in.


Unexpected result
=

Step 4 fails, and makes the system inaccessible to blind users.

1. The login screen loads.
2. Orca informs the user that the screen reader is active.
3. The blind user enters username and password with the assistance of 
the reader.

4. The blind user cannot log in.

Step 4 fails because when the user hits the Enter key or the button to 
log in, the greeter hangs. Then, the blind user has to call for human 
assistance.


Note that before hanging, just after pressing Enter or the log in 
button, Orca informs that the screen reader has been disabled. Once the 
greeter hangs, you cannot focus any fields or buttons with the keyboard, 
nor with the mouse, but you can still move the pointer around.


To be able to log in to the desktop, you have to access tty1 (Ctrl + Alt 
+ F1) and startx manually. Finally, you have to make sure to disable 
Orca in the greeter settings to be able to log in graphically again.


--
https://sirgazil.bitbucket.io/

Bug#881339: let's find a solution

[Don Armstrong]

On Thu, 30 Nov 2017, Paolo Greppi wrote:
> babel-preset-env is an essential component of babel:
> https://babeljs.io/docs/plugins/preset-env
> 
> babel is a sort of "compiler" that translates from bleeding-edge javascript
> to older, more widespread standard versions (such as the javascript that
> runs in a browser).
> It's a very successful project at the moment, see for example:
> https://tomdale.net/2017/09/compilers-are-the-new-frameworks/
> It is written in javascript itself so it makes sense that it must
> be bootstrapped like gcc.

This seems pretty cool, but is there a reason why babel can't just
bootstrap itself from its own source package? Just checking briefly, its
makefile[1] seems to have code to bootstrap itself.

Also, have you discussed this with Thorsten or another ftp master
directly? Perhaps they just rejected it because the reasoning for the
build-dependency was not clear, nor was it clear how to bootstrap babel
to generate the first package.

1: https://github.com/babel/babel/blob/master/Makefile#L128
-- 
Don Armstrong  https://www.donarmstrong.com

-tommorow is our permanent address
and there they'll scarcely find us(if they do,
we'll move away still further:into now
 -- e.e. cummings "XXXIX" _1 x 1_

Bug#883213: Please package new 2.x version (now named nyx)

[Dererk]

Hi.

It has been in NEW queue for quite some time nos

https://ftp-master.debian.org/new.html

On November 30, 2017 4:14:47 PM GMT-03:00, "Santiago R.R." 
 wrote:
>Package: tor-arm
>Severity: wishlist
>
>Dear Ulises,
>
>A new arm version, now renamed Nyx, has been released. Please, consider
>packaging it:
>https://nyx.torproject.org/changelog/index.html#version-2-0
>
>Cheers,
>
> -- Santiago

Bug#861174: RFP: elpa-elpy -- Emacs Python Development Environment

[Nicholas D Steeves]

Hi Antoine, Diane, and Ben,

With all the time it took to figure out why find-file-in-project (a
dependency of elpy) self-tests weren't passing on debci, even when
they were passing on buildd I think it would be best to upload Elpy
with elpa_tests disabled.  There's also a bug in either
libdebian-source-perl or dh-elpa that makes elpa_test choke on the
X-Python3-Version field, so I think it would be best to upload now and
file a "enable self-tests" bug after elpy hits unstable.

Do any of you have the time to review the package and make sure it's
more advanced features work properly?

Sincerely
Nicholas

On Fri, Jul 14, 2017 at 02:04:59PM -0400, Antoine Beaupré wrote:
> On 2017-07-12 11:14:40, Nicholas Steeves wrote:
> > On 26 April 2017 at 21:55, Antoine Beaupré  wrote:
> >> On 2017-04-26 21:26:33, Nicholas Steeves wrote:
> >>> By the way, what kind of a timeline do you have in mind?
> >>
> >> I'm away for a month, so no rush. :)
> >
> > Hi Antoine,
> >
> > If you have time could you please sponsor #863216, which is indirectly
> > blocking #861242, which is blocking this bug?  I've been waiting for
> > sponsorship for almost a month and would like to resume progress
> > towards fulfilling the prerequisites for your RFPs.
> 
> No time right now, unfortunately. But maybe we could review this during
> the debcamp early august! :)
> 
> a.
> 
> -- 
> No animal has more liberty than the cat; but it buries the mess it
> makes. The cat is the best anarchist. Until they learn that from the cat
> I cannot respect them.
> - For whom the bell tolls, Ernest Hemingway


signature.asc
Description: PGP signature

Bug#874295: Not a bug

[Ben Finney]

Ian Jackson  writes:

> Ben Finney writes ("Re: Bug#874295: Not a bug"):
> > (Yes, I think a web browser should not download and execute
> > arbitrary JavaScript either. That one problem remains unaddressed is
> > not a justification for the same problem elsewhere.)
>
> This is obviously out of scope for the discussion of this bug.

Certainly. I was responding parenthetically to a point that, I agree
with you, was out of scope.

-- 
 \  “I would rather be exposed to the inconveniences attending too |
  `\  much liberty than those attending too small a degree of it.” |
_o__)—Thomas Jefferson, 1791-12-23 |
Ben Finney 

Bug#883214: Please package new upstream 3.0 version in experimental (with GTK+ 3.0 support)

[Josh Triplett]

Package: pidgin
Version: 2.12.0-1+b1
Severity: wishlist

Upstream has a new 3.0 version in development, which includes GTK+ 3.0
support. Please consider packaging it in experimental.

-- 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.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pidgin depends on:
ii  libatk1.0-0 2.26.1-1
ii  libc6   2.25-2
ii  libcairo2   1.15.8-2
ii  libdbus-1-3 1.12.2-1
ii  libdbus-glib-1-20.108-3
ii  libfontconfig1  2.12.6-0.1
ii  libfreetype62.8.1-0.1
ii  libgadu31:1.12.2-2
ii  libgdk-pixbuf2.0-0  2.36.11-1
ii  libglib2.0-02.54.2-1
ii  libgstreamer1.0-0   1.12.3-1
ii  libgtk2.0-0 2.24.31-3
ii  libgtkspell02.0.16-1.1
ii  libice6 2:1.0.9-2
ii  libpango-1.0-0  1.40.13-2
ii  libpangocairo-1.0-0 1.40.13-2
ii  libpangoft2-1.0-0   1.40.13-2
ii  libpurple0  2.12.0-1+b1
ii  libsm6  2:1.2.2-1+b3
ii  libx11-62:1.6.4-3
ii  libxss1 1:1.2.2-1+b2
ii  perl-base [perlapi-5.26.0]  5.26.1-3
ii  pidgin-data 2.12.0-1

Versions of packages pidgin recommends:
ii  gstreamer1.0-alsa  1.12.3-1
ii  gstreamer1.0-libav 1.12.3-1
ii  gstreamer1.0-plugins-base  1.12.3-1
ii  gstreamer1.0-plugins-good  1.12.3-1
ii  gstreamer1.0-pulseaudio1.12.3-1

Versions of packages pidgin suggests:
ii  libsqlite3-0  3.21.0-1

-- no debconf information

Bug#882867: krb5-kdc: cannot write to default log location

[Sam Hartman]

Hi.
When I install krb5-kdc, it logs to syslog not to /var/log/krb5kdc.log.
Where in the files installed by the krb5-kdc package are you seeing
configuration to install to /var/log/krb5kdc.log.
I agree upstream configures (or in some cases recommends configuring)
things that way, but I'm not seeing that in the Debian package.

--Sam

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Second attempt, updated debdiff attached.

Changes:

also address:

+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]

A call for tests was sent to debian-boot three days ago¹, no
reaction though.

Assuming your

> I'd be happy with this in general, but the udeb means we need an
> explicit d-i RM ack; CCing appropriately.

still applies, Cc: is set accordingly.

Regards,

Christoph

¹ https://lists.debian.org/debian-boot/2017/11/msg00379.html
diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2016-04-17 17:37:25.0 +0200
+++ busybox-1.22.0/debian/changelog 2017-09-25 22:42:41.0 +0200
@@ -1,3 +1,19 @@
+busybox (1:1.22.0-19+deb9u1) stretch; urgency=medium
+
+  * Fix pointer misuse unziping files. Closes: #803097
+  * Fix Heap-based buffer overflow in the DHCP client.
+Closes: #818497 [CVE-2016-2148]
+  * Fix integer overflow in the DHCP client (udhcpc).
+Closes: #818499 [CVE-2016-2147]
+  * Fix directory traversal vulnerability in tar implementation.
+Closes: #802702 [CVE-2011-5325]
+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]
+
+ -- Christoph Biedl   Mon, 25 Sep 2017 
22:42:41 +0200
+
 busybox (1:1.22.0-19) unstable; urgency=medium
 
   * busybox-udeb, udhcpc: Remove /udhcpc/usr/share/udhcpc/default.script,
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
2017-09-25 22:42:41.0 +0200
@@ -0,0 +1,58 @@
+Subject: Udhcpc: fix OPTION_6RD parsing (could overflow its malloced buffer)
+ID: CVE-2016-2148
+Origin: 1_24_0-139-g352f79a
+Upstream-Author: Denys Vlasenko 
+Date: Fri Feb 26 15:54:56 2016 +0100
+Bug-Debian: https://bugs.debian.org/818497 
+
+--- a/networking/udhcp/common.c
 b/networking/udhcp/common.c
+@@ -140,7 +140,7 @@
+  * udhcp_str2optset: to determine how many bytes to allocate.
+  * xmalloc_optname_optval: to estimate string length
+  * from binary option length: (option[LEN] / dhcp_option_lengths[opt_type])
+- * is the number of elements, multiply in by one element's string width
++ * is the number of elements, multiply it by one element's string width
+  * (len_of_option_as_string[opt_type]) and you know how wide string you need.
+  */
+ const uint8_t dhcp_option_lengths[] ALIGN1 = {
+@@ -160,7 +160,18 @@
+   [OPTION_S32] = 4,
+   /* Just like OPTION_STRING, we use minimum length here */
+   [OPTION_STATIC_ROUTES] = 5,
+-  [OPTION_6RD] =22,  /* ignored by udhcp_str2optset */
++  [OPTION_6RD] =12,  /* ignored by udhcp_str2optset */
++  /* The above value was chosen as follows:
++   * len_of_option_as_string[] for this option is >60: it's a string of 
the form
++   * "32 128 ::::::: 255.255.255.255 ".
++   * Each additional ipv4 address takes 4 bytes in binary option and 
appends
++   * another "255.255.255.255 " 16-byte string. We can set [OPTION_6RD] = 
4
++   * but this severely overestimates string length: instead of 16 bytes,
++   * it adds >60 for every 4 bytes in binary option.
++   * We cheat and declare here that option is in units of 12 bytes.
++   * This adds more than 60 bytes for every three ipv4 addresses - more 
than enough.
++   * (Even 16 instead of 12 should work, but let's be paranoid).
++   */
+ };
+ 
+ 
+--- a/networking/udhcp/dhcpc.c
 b/networking/udhcp/dhcpc.c
+@@ -99,7 +99,7 @@
+   [OPTION_IP  ] = sizeof("255.255.255.255 "),
+   [OPTION_IP_PAIR ] = sizeof("255.255.255.255 ") * 2,
+   [OPTION_STATIC_ROUTES   ] = sizeof("255.255.255.255/32 255.255.255.255 
"),
+-  [OPTION_6RD ] = sizeof("32 128 
::::::: 255.255.255.255 "),
++  [OPTION_6RD ] = sizeof("132 128 
::::::: 255.255.255.255 "),
+   [OPTION_STRING  ] = 1,
+   [OPTION_STRING_HOST ] = 1,
+ #if ENABLE_FEATURE_UDHCP_RFC3397
+@@ -206,7 +206,7 @@
+   type = optflag->flags & OPTION_TYPE_MASK;
+   optlen = dhcp_option_lengths[type];
+   upper_length = 

Bug#883213: Please package new 2.x version (now named nyx)

[Santiago R.R.]

Package: tor-arm
Severity: wishlist

Dear Ulises,

A new arm version, now renamed Nyx, has been released. Please, consider
packaging it:
https://nyx.torproject.org/changelog/index.html#version-2-0

Cheers,

 -- Santiago

Bug#877260: jessie-pu: package busybox/1:1.22.0-9+deb8u2

[Christoph Biedl]

Second attempt, updated debdiff attached.

Changes:

also address:

+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]

A call for tests was sent to debian-boot three days ago¹, no
reaction though.

Assuming your

> I'd be happy with this in general, but the udeb means we need an
> explicit d-i RM ack; CCing appropriately.

still applies, Cc: is set accordingly.

Christoph

¹ https://lists.debian.org/debian-boot/2017/11/msg00379.html
diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2015-02-17 18:30:02.0 +0100
+++ busybox-1.22.0/debian/changelog 2017-11-30 19:41:31.0 +0100
@@ -1,3 +1,20 @@
+busybox (1:1.22.0-9+deb8u2) jessie; urgency=medium
+
+  * Reject module names with slashes. Closes: #776186 [CVE-2014-9645]
+  * Fix pointer misuse unziping files. Closes: #803097
+  * Fix Heap-based buffer overflow in the DHCP client.
+Closes: #818497 [CVE-2016-2148]
+  * Fix integer overflow in the DHCP client (udhcpc).
+Closes: #818499 [CVE-2016-2147]
+  * Fix directory traversal vulnerability in tar implementation.
+Closes: #802702 [CVE-2011-5325]
+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]
+
+ -- Christoph Biedl   Thu, 30 Nov 2017 
19:41:31 +0100
+
 busybox (1:1.22.0-9+deb8u1) jessie; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
 1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
 2017-11-30 19:41:23.0 +0100
@@ -0,0 +1,27 @@
+Subject: Modprobe,rmmod: reject module names with slashes
+ID: CVE-2014-9645
+Origin: 1_22_0-220-g4e314fa
+Upstream-Author: Denys Vlasenko 
+Date: Thu Nov 20 18:24:33 2014 +0100
+Bug-Debian: https://bugs.debian.org/776186
+
+--- a/modutils/modprobe.c
 b/modutils/modprobe.c
+@@ -239,6 +239,17 @@
+ {
+   struct module_entry *m;
+ 
++  /*
++   * get_or_add_modentry() strips path from name and works
++   * on remaining basename.
++   * This would make "rmmod dir/name" and "modprobe dir/name"
++   * to work like "rmmod name" and "modprobe name",
++   * which is wrong, and can be abused via implicit modprobing:
++   * "ifconfig /usbserial up" tries to modprobe netdev-/usbserial.
++   */
++  if (strchr(name, '/'))
++  bb_error_msg_and_die("malformed module name '%s'", name);
++
+   m = get_or_add_modentry(name);
+   if (!(option_mask32 & (OPT_REMOVE | OPT_SHOW_DEPS))
+&& (m->flags & (MODULE_FLAG_LOADED | MODULE_FLAG_BUILTIN))
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
2017-11-28 16:44:39.0 +0100
@@ -0,0 +1,58 @@
+Subject: Udhcpc: fix OPTION_6RD parsing (could overflow its malloced buffer)
+ID: CVE-2016-2148
+Origin: 1_24_0-139-g352f79a
+Upstream-Author: Denys Vlasenko 
+Date: Fri Feb 26 15:54:56 2016 +0100
+Bug-Debian: https://bugs.debian.org/818497 
+
+--- a/networking/udhcp/common.c
 b/networking/udhcp/common.c
+@@ -140,7 +140,7 @@
+  * udhcp_str2optset: to determine how many bytes to allocate.
+  * xmalloc_optname_optval: to estimate string length
+  * from binary option length: (option[LEN] / dhcp_option_lengths[opt_type])
+- * is the number of elements, multiply in by one element's string width
++ * is the number of elements, multiply it by one element's string width
+  * (len_of_option_as_string[opt_type]) and you know how wide string you need.
+  */
+ const uint8_t dhcp_option_lengths[] ALIGN1 = {
+@@ -160,7 +160,18 @@
+   [OPTION_S32] = 4,
+   /* Just like OPTION_STRING, we use minimum length here */
+   [OPTION_STATIC_ROUTES] = 5,
+-  [OPTION_6RD] =22,  /* ignored by udhcp_str2optset */
++   

Bug#876521: FTBFS with CGAL 4.11

[Joachim Reichel]

severity 876521 serious
thanks

On 12.11.2017 22:20, Sebastiaan Couwenberg wrote:
> You shouldn't have waited for this issue to request the transition slot.
> As I said before, I'll remove the SFCGAL dependency from PostGIS if this
> issue is not resolved when the CGAL transition starts. That way we can
> keep postgis is testing.

Don't worry, sfcgal was not the only reverse dependency that needs more than a
binNMU.

> Just raise the severity of this issue to serious when the transition
> starts. That's the usual procedure for blocking issues and transitions. [0]

The transition just started. Done.

Best regards,
  Joachim

Bug#883143: ejabberd: mod_http_upload fails with permission denied

[Adrien Dorsaz]

Hello,

As I've written on the ejabberd chatroom, I hade same issue with my
server running Debian Stretch since last Saturday IIRC.

I've just checked my apt logs and Apparmor has been installed
automatically during an upgrade:

> Start-Date: 2017-11-21  07:04:28
> Commandline: apt upgrade
> Upgrade: libxml-libxml-perl:amd64 (2.0128+dfsg-1+b1, 2.0128+dfsg-
> 1+deb9u1), procmail:amd64 (3.22-25+b1, 3.22-25+deb9u1)
> End-Date: 2017-11-21  07:05:00
> 
> Start-Date: 2017-11-21  07:58:45
> Install: php-zmq:amd64 (1.1.3-5), libpgm-5.2-0:amd64 (5.2.122~dfsg-2, 
> automatic), libzmq5:amd64 (4.2.1-4, automatic), libsodium18:amd64
> (1.0.11-2, automatic)
> End-Date: 2017-11-21  07:58:59
> 
> Start-Date: 2017-11-24  21:23:57
> Commandline: apt upgrade
> Install: libapparmor-perl:amd64 (2.11.0-3, automatic), apparmor:amd64
> (2.11.0-3, automatic)
> Upgrade: linux-headers-4.13.0-0.bpo.1-amd64:amd64 (4.13.4-2~bpo9+1,
> 4.13.13-1~bpo9+1), gitlab-ce:amd64 (10.1.4-ce.0, 10.2.1-ce.0), linux-
> image-4.13.0-0.bpo.1-amd64:amd64 (4.13.4-2~bpo9+1, 4.13.13-1~bpo9+1), 
> linux-kbuild-4.13:amd64 (4.13.4-2~bpo9+1, 4.13.13-1~bpo9+1), linux-
> headers-4.13.0-0.bpo.1-common:amd64 (4.13.4-2~bpo9+1, 4.13.13-
> 1~bpo9+1)
> End-Date: 2017-11-24  21:34:08
> 
> Start-Date: 2017-11-26  15:42:37
> Remove: libapparmor-perl:amd64 (2.11.0-3), apparmor:amd64 (2.11.0-3)
> End-Date: 2017-11-26  15:42:50
> 
> Start-Date: 2017-11-30  06:32:27
> Commandline: /usr/bin/unattended-upgrade
> Upgrade: libcurl3:amd64 (7.52.1-5+deb9u2, 7.52.1-5+deb9u3),
> curl:amd64 (7.52.1-5+deb9u2, 7.52.1-5+deb9u3), libcurl3-gnutls:amd64
> (7.52.1-5+deb9u2, 7.52.1-5+deb9u3)
> End-Date: 2017-11-30  06:32:49
> 

In the ejabberd log, for the http_upload server, I have:

> 2017-11-30 17:49:19.971 [error]
> <0.23175.0>@mod_http_upload:process:371 Cannot store file
> /srv/var/ejabberd/http_upload/4a573a53f8a83374e2dbbdcbc8083b7413c34d8
> 4/E4ggWg10PReyzn6b9su2DHTxky4khRUefeFhnmU2/a-REOv9LQMSruzWoDoXJ0Q.jpg 
> from :::213.55.211.109 for adorsaz.ch: "permission denied"

As I've written in the chatroom, it also happened with my TLS
certificates which I've installed at /usr/lib/ssl/private/ directory.

See the ejabberd error log:

> 2017-11-25 22:33:07.067 [error]
> <0.279.0>@ejabberd_pkix:mk_cert_state:244 failed to read certificate
> from /usr/lib/ssl/private/adorsaz.ch/chain_with_key.pem: permission
> denied
> 2017-11-25 22:33:20.087 [error]
> <0.479.0>@ejabberd_c2s:process_terminated:291 (tcp|<0.478.0>) Failed
> to secure c2s connection: TLS failed: SSL_CTX_use_certificate_file
> failed: error:0200100D:system library:fopen:Permission denied
> 

For certificates, I've moved them to /etc/ejabberd and it worked well
(I've also tried in /var/lib/ejabberd and it worked).

Looking forward who recommended installation of apparmor:

> 19:33:51 [root@kadabra:/var/log/ejabberd] # aptitude why apparmor
> i   linux-image-amd64Dépend linux-image-4.13.0-
> 0.bpo.1-amd64
> i A linux-image-4.13.0-0.bpo.1-amd64 Recommande apparmor 

For information, other packages which would recommends/suggests
apparmor:

> 19:34:40 [root@kadabra:/var/log/ejabberd] # apt-cache rdepends --
> installed apparmor
> apparmor
> Reverse Depends:
>   systemd
>   systemd
>   linux-image-4.13.0-0.bpo.1-amd64
>   ejabberd
>   haveged
>   ejabberd
>   clamav-freshclam
>   clamav-daemon
> 

In my apt log above, you can see I've removed the apparmor package on
26th November, but it didn't resolve the issue. I've seen today, with
aptitude, that the package was in the 'c' state. So I've just purged it
and rebooted my server:

Now it works :-)

Adrien Dorsaz

Bug#881339: let's find a solution

[Paolo Greppi]

babel-preset-env is an essential component of babel:
https://babeljs.io/docs/plugins/preset-env

babel is a sort of "compiler" that translates from bleeding-edge javascript
to older, more widespread standard versions (such as the javascript that
runs in a browser).
It's a very successful project at the moment, see for example:
https://tomdale.net/2017/09/compilers-are-the-new-frameworks/
It is written in javascript itself so it makes sense that it must
be bootstrapped like gcc.

For sure the javascript ecosystem culture is different from debian's, and
that ecosystem is just starting to stabilize. Bur there is already a lot
of valuable open-source stuff in there.

Such as a number of server-oriented tools that it would be nice to have in
debian:
- etherpad-lite (ITP: https://bugs.debian.org/576998)
- gitlab
- gitea
- buildbot 0.9.x (if we want to keep the web client)
- ...
- 

Also if only debian were kind enough with front-end developers to provide
the tools they need, there is potential to attract quite a few new debian
(and derivatives) desktop users.

What matters most now is to get the tooling required to package stuff.

So please let's find a way to get babel-preset-env in.

Paolo