Bug#892432: RFS: k2pdfopt/2.42+ds-1 [ITP]

[Yangfl]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: k2pdfopt
   Version : 2.42+ds-1
   Upstream Author : willus
 * URL : http://www.willus.com/k2pdfopt/
 * License : AGPL3+
   Section : utils

  It builds those binary packages:

k2pdfopt   - PDF Reflow tool

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/k/k2pdfopt/k2pdfopt_2.42+ds-1.dsc


  Regards,
   Yangfl

Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

Control: tags -1 - moreinfo

Alright, I've addressed all the points brought up by you two (thanks for 
the feedback so far!)


I have done a thorough check of the licenses, updated d/copyright, and 
found a few problematic Qt Commercial license files, which I reported to 
upstream. [1]


But, besides the files mentioned in [1], I think everything else is 
ready for review.


I've verified FreeCAD works well with this, and previously my WIP Netgen 
6.2 package worked well but is currently experiencing issues which I 
think are unrelated. The only other dependent package is deal.ii which I 
am not familiar with and will have to investigate later as part of the 
phase-out of liboce.


1. https://www.opencascade.com/content/packaging-again-debian#comment-20398

Bug#892062: bug 892062 is forwarded to https://github.com/OSGeo/proj.4/issues/833

[Sebastiaan Couwenberg]

On 03/09/2018 07:00 AM, Sebastiaan Couwenberg wrote:
> On 03/09/2018 12:20 AM, Olly Betts wrote:
>> Control: tags 892062 + patch
>>
>> On Sun, Mar 04, 2018 at 09:10:28PM +0100, Bas Couwenberg wrote:
>>> forwarded 892062 https://github.com/OSGeo/proj.4/issues/833
>>> thanks
>>
>> There's now a patch for this:
>>
>> https://github.com/OSGeo/proj.4/pull/845
> 
> The changes look a little invasive, though.
> 
> proj (5.0.0-2) migrated to testing this morning, so I'll cherry-pick the
> change and check if it fixes the issue and doesn't introduce regressions
> in the other packages.

survex (1.2.32-1) successfully built with proj (5.0.0-3~exp1) which has
been uploaded to experimental (but not available there yet at time of
writing).

After I've verified that the two upstream patches don't cause other
regressions I'll move the package from experimental to unstable.

Kind Regards,

Bas

Bug#892249: lintian: detect broken ftp://ftp.debian.org and ftp://security.debian.org links

[Chris Lamb]

tags 892249 + pending
thanks

Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=4b14bdcda77470a58bff415defd326e128d6d119


Regards,

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

Bug#892143: lintian: check packages that use mail-transport-agent but do not prefer default-mta

[Chris Lamb]

tags 892143 + pending
thanks

Thanks for the report. Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=1d7678bdc67792cfdc9ae5aa82d15daee37cf3d5


Regards,

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

Bug#892062: bug 892062 is forwarded to https://github.com/OSGeo/proj.4/issues/833

[Sebastiaan Couwenberg]

On 03/09/2018 12:20 AM, Olly Betts wrote:
> Control: tags 892062 + patch
> 
> On Sun, Mar 04, 2018 at 09:10:28PM +0100, Bas Couwenberg wrote:
>> forwarded 892062 https://github.com/OSGeo/proj.4/issues/833
>> thanks
> 
> There's now a patch for this:
> 
> https://github.com/OSGeo/proj.4/pull/845

The changes look a little invasive, though.

proj (5.0.0-2) migrated to testing this morning, so I'll cherry-pick the
change and check if it fixes the issue and doesn't introduce regressions
in the other packages.

Kind Regards,

Bas

Bug#892431: AppArmor denies access for libvirt to nova instances directory

[aradian]

Package: nova-compute
Version: 2:16.0.3-10
User: pkg-apparmor-t...@lists.alioth.debian.org
Usertags: new-profile

When launching a QEMU KVM instance, an error occurs immediately upon 
launching the qemu process:


Could not open backing file: Could not open 
'/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e': 
Permission denied


This is caused because the AppArmor profile for libvirt does not include 
access to nova's instances directory (/var/lib/nova/instances).


This error was fixed by adding the following lines to 
/etc/apparmor.d/usr.lib.libvirt.virt-aa-helper:


  /var/lib/nova/instances/_base/ r,
  /var/lib/nova/instances/_base/* r,
  /var/lib/nova/instances/** rw,

and running:
sudo apparmor_parser -r /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper

Probably it would be more appropriate to put that in a separate profile?


This is on a system installed as debian-stretch, then upgraded to 
debian-buster.

$ uname -a
Linux callisto 4.14.0-3-amd64 #1 SMP Debian 4.14.17-1 (2018-02-14) 
x86_64 GNU/Linux




AppArmor DENIED messages from /var/log/syslog:

Mar  8 21:31:09 callisto kernel: [688136.384367] audit: type=1400 
audit(1520566269.565:85): apparmor="DENIED" operation="open" 
profile="virt-aa-helper" 
name="/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e" 
pid=30420 comm="virt-aa-helper" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=64055
Mar  8 21:31:09 callisto kernel: [688136.609529] audit: type=1400 
audit(1520566269.789:87): apparmor="DENIED" operation="open" 
profile="virt-aa-helper" 
name="/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e" 
pid=30426 comm="virt-aa-helper" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=64055
Mar  8 21:31:10 callisto kernel: [688136.854752] audit: type=1400 
audit(1520566270.033:89): apparmor="DENIED" operation="open" 
profile="virt-aa-helper" 
name="/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e" 
pid=30432 comm="virt-aa-helper" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=64055
Mar  8 21:31:10 callisto kernel: [688137.075108] audit: type=1400 
audit(1520566270.253:91): apparmor="DENIED" operation="open" 
profile="virt-aa-helper" 
name="/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e" 
pid=30438 comm="virt-aa-helper" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=64055
Mar  8 21:31:10 callisto kernel: [688137.603399] audit: type=1400 
audit(1520566270.781:94): apparmor="DENIED" operation="open" 
profile="libvirt-39477509-a5d2-4f52-a751-bef5013484e4" 
name="/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e" 
pid=30475 comm="qemu-system-x86" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=0




Relevant part of /var/log/nova/nova-compute.log:

2018-03-02T05:15:27.083155Z qemu-system-x86_64: -drive 
file=/var/lib/nova/instances/9ac0d3ec-35ad-4420-ae20-f6c0c9845f05/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none: 
Could not open backing file: Could not open 
'/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e': 
Permission denied
2018-03-01 23:15:27.373 2376 ERROR nova.virt.libvirt.driver 
[req-3cb9fbc5-8f4e-4244-8b14-b52ac1f0494b 
a6f48b630f634371ba94558f3ba576b8 5f46526ffab3410a9cf71b37fa242e11 - 
default default] [instance: 9ac0d3ec-35ad-4420-ae20-f6c0c9845f05] Failed 
to start libvirt guest: libvirtError: internal error: process exited 
while connecting to monitor: outputs=1,bus=pci.0,addr=0x2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on
2018-03-02T05:15:27.083155Z qemu-system-x86_64: -drive 
file=/var/lib/nova/instances/9ac0d3ec-35ad-4420-ae20-f6c0c9845f05/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none: 
Could not open backing file: Could not open 
'/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e': 
Permission denied
2018-03-01 23:15:27.374 2376 INFO os_vif 
[req-3cb9fbc5-8f4e-4244-8b14-b52ac1f0494b 
a6f48b630f634371ba94558f3ba576b8 5f46526ffab3410a9cf71b37fa242e11 - 
default default] Successfully unplugged vif 
VIFBridge(active=False,address=fa:16:3e:b4:ed:53,bridge_name='brq03b5dd02-ac',has_traffic_filtering=True,id=042a5f68-01bb-453e-bb2a-2d798b7691d5,network=Network(03b5dd02-ac2f-49f0-b1ff-fa26059f352c),plugin='linux_bridge',port_profile=,preserve_on_delete=False,vif_name='tap042a5f68-01')
2018-03-01 23:15:27.434 2376 INFO nova.virt.libvirt.driver 
[req-3cb9fbc5-8f4e-4244-8b14-b52ac1f0494b 
a6f48b630f634371ba94558f3ba576b8 5f46526ffab3410a9cf71b37fa242e11 - 
default default] [instance: 9ac0d3ec-35ad-4420-ae20-f6c0c9845f05] 
Deleting instance files 
/var/lib/nova/instances/9ac0d3ec-35ad-4420-ae20-f6c0c9845f05_del
2018-03-01 23:15:27.436 2376 INFO nova.virt.libvirt.driver 
[req-3cb9fbc5-8f4e-4244-8b14-b52ac1f0494b 
a6f48b630f634371ba94558f3ba576b8 5f46526ffab3410a9cf71b37fa242e11 - 
default default] [instance: 9ac0d3ec-35ad-4420-ae20-f6c0c9845f05] 
Deletion of 

Bug#887323: dewalls i386 test failure

[Wookey]

Is this test actually right? Shouldn't it be Angle::Gradians?

CHECK_THROWS( WallsSurveyParser("400g").azimuth(Angle::Degrees) )

same for;
CHECK_THROWS( WallsSurveyParser("-0.1g").azimuth(Angle::Degrees) );
CHECK_THROWS( WallsSurveyParser("N100gE").azimuth(Angle::Degrees) );


I tried changing the test to:
CHECK_THROWS( WallsSurveyParser("400g").azimuth(Angle::Gradians) )
CHECK_THROWS( WallsSurveyParser("400").azimuth(Angle::Gradians) )

but they both still fail. 

Changing the tests to this:
CHECK_THROWS( WallsSurveyParser("360.1").azimuth(Angle::Degrees) );
CHECK_THROWS( WallsSurveyParser("-0.1").azimuth(Angle::Degrees) );
CHECK_THROWS( WallsSurveyParser("400.1g").azimuth(Angle::Gradians) 
);
CHECK_THROWS( WallsSurveyParser("-0.1g").azimuth(Angle::Gradians) );
CHECK_THROWS( WallsSurveyParser("N90.1E").azimuth(Angle::Degrees) );
CHECK_THROWS( 
WallsSurveyParser("N100.1gE").azimuth(Angle::Gradians) );

makes them all pass. Which strongly suggsts that this really is a
rounding problem on i386. I could experiment further to try and
determine the size of the rounding error.

I could leave this bodge in in order to get i386 built and dewalls
migrated into testing, but it would be better to actually fix the
problem if possible. I could also arrange not to run the tests on
i386.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#892240: diffoscope: crashes comparing directories with python3-xattr installed

[Chris Lamb]

tags 892240 + pending
thanks

Fixed in Git, pending upload. Thanks!

  
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=ec51d78da0bbc32fac09cf5b0f56039b8f79c696


Regards,

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

Bug#892144: lintian: check for relationships with packages that provide mail-transport-agent but don't use m-t-a

[Chris Lamb]

tags 892144 + moreinfo
thanks

Hi Paul,

> In other words, lintian should look in the apt cache to find out which
> packages provide the virtual package mail-transport-agent

Unless I'm mistaken, I think this is outside the "information horizon"
of Lintian.


Regards,

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

Bug#887323: dewalls i386 test failure

[Wookey]

On 2018-01-31 20:59 +, Philip Schuchardt wrote:
> Nice! I wonder if i386 don’t support exceptions properly or something...

It's not that simple.

I found out how to run specific tests with catch. There are two other groups of 
tests which are expected to throw and those work OK:
(sid_i386-dchroot)wookey@barriere:~/dewalls-1.0.0+ds1$ 
qbs-build/dewalls-test.a3cdf9ea/dewalls-test -f test/azimuthparsingtests.cpp 
azimuth* -c "misc invalid values throw"
===
All tests passed (6 assertions in 1 test case)

(sid_i386-dchroot)wookey@barriere:~/dewalls-1.0.0+ds1$ 
qbs-build/dewalls-test.a3cdf9ea/dewalls-test -f test/azimuthparsingtests.cpp 
azimuth* -c "negative numbers throw for azimuth"
===
All tests passed (1 assertion in 1 test case)

But the 'out of range values throw' tests fail:
(sid_i386-dchroot)wookey@barriere:~/dewalls-1.0.0+ds1$ 
qbs-build/dewalls-test.a3cdf9ea/dewalls-test -f test/azimuthparsingtests.cpp 
azimuth* -c "out of range values throw"
~~~
dewalls-test is a Catch v1.10.0 host application.
Run with -? for options

---
azimuth parsing tests
  out of range values throw
---
/home/wookey/dewalls-1.0.0+ds1/test/azimuthparsingtests.cpp:63
...

/home/wookey/dewalls-1.0.0+ds1/test/azimuthparsingtests.cpp:64: FAILED:
  CHECK_THROWS( WallsSurveyParser("360").azimuth(Angle::Degrees) )
because no exception was thrown where one was expected:

/home/wookey/dewalls-1.0.0+ds1/test/azimuthparsingtests.cpp:66: FAILED:
  CHECK_THROWS( WallsSurveyParser("400g").azimuth(Angle::Degrees) )
because no exception was thrown where one was expected:

/home/wookey/dewalls-1.0.0+ds1/test/azimuthparsingtests.cpp:68: FAILED:
  CHECK_THROWS( WallsSurveyParser("N90E").azimuth(Angle::Degrees) )
because no exception was thrown where one was expected:

/home/wookey/dewalls-1.0.0+ds1/test/azimuthparsingtests.cpp:69: FAILED:
  CHECK_THROWS( WallsSurveyParser("N100gE").azimuth(Angle::Degrees) )
because no exception was thrown where one was expected:

===
test cases: 1 | 1 failed
assertions: 6 | 2 passed | 4 failed


I'm not sure what to make of this, but it suggests that the issue is
more likely to be not with catch itself, but with the actual parser.

How can I test the parser directly, to eliminate catch as part of the issue?

Can one of you knock up a little test case that tries to read in a
file containing these sorts of error, that can be built against
libdewalls? Then we can see whether the library is actually getting
this wrong or if it's only in the test framework.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#892426: [Pkg-opencl-devel] Bug#892426: pocl: FTBFS on most non-x86 architectures: 12-16% of tests pass

[Andreas Beckmann]

Control: block -1 with 891690

On 2018-03-09 03:51, Aaron M. Ucko wrote:
> Builds of pocl for most non-x86 architectures, including several
> release architectures, failed with heavy test suite errors: between
> 12% and 16% of tests passed, depending on the architecture [1].  The
> only exceptions are arm64, which succeeded, and armhf, on which 43% of
> tests passed [2] -- still not great, but better.

many of these tests failed with some error similar to

  /usr/bin/ld: cannot find
  
/usr/lib/llvm-4.0/bin/../lib/clang/4.0.1/lib/linux/libclang_rt.builtins-mipsel.a:
  No such file or directory

at least for mipsel I found that such a file existed in the past
and therefore I filed a bug against llvm.

That file is not referenced from pocl at all, but from llvm.

Probably not worth visiting this in detail before I switch
to llvm-5.0 with pocl-1.1 soon.


Andreas

Bug#892428: [Pkg-opencl-devel] Bug#892428: pocl: FTBFS on x32: tries to build kernel/host/ for amd64

[Andreas Beckmann]

On 2018-03-09 03:55, Aaron M. Ucko wrote:
> Builds of pocl for x32 (admittedly not a release architecture) have
> been failing, as detailed at [1]:
> 
>   cd "/<>/obj-x86_64-linux-gnux32/lib/kernel/host" && 
> /usr/bin/clang-4.0 --target=x86_64-pc-linux-gnu -D_CL_DISABLE_HALF 
> -march=x86-64 -emit-llvm -ffp-contract=off -xc -D__CBUILD__ 
> -fno-stack-protector -fno-PIC -DDORENAME -DVEC128 -I 
> "/<>/lib/kernel/sleef/arch" -I 
> "/<>/lib/kernel/sleef/libm" -I 
> "/<>/lib/kernel/sleef/include" -O1 -o 
> "/<>/obj-x86_64-linux-gnux32/lib/kernel/host/x86-64/v128_sleefsimddp.c.bc"
>  -c "/<>/lib/kernel/sleef/libm/sleefsimddp.c"
>   In file included from 
> /<>/lib/kernel/sleef/libm/sleefsimddp.c:8:
>   In file included from 
> /usr/lib/llvm-4.0/bin/../lib/clang/4.0.1/include/stdint.h:61:
>   /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file 
> not found
> 
> Could you please take a look?  (Note the explicit inappropriate
> -march=x86-64.)

So what is the correct setting for x32 here? I think already
--target=x86_64-pc-linux-gnu is wrong ... (and that one gets
autodetected, not overridden by me)

I need to pass an -march or similar option since pocl does not know
about the "use the compilers default" concept (and does the equivalent
of -march=native by default)


Andreas

Bug#892393: dewalls: build-depends on GCC 6

[Wookey]

On 2018-03-08 18:20 +, Wookey wrote:
> It looks like we have libstdc++6 and libstdc++-dev virtual
> packages. Is it OK to build-depend on just a virtual package? Perusing
> Policy has not made me much wiser.

Using:
Build-Depends: libstdc++-dev

builds OK, but I found the info pointing out that a default real package 
should be set to get a conssitent environment on buildds.

So I've set it to Build-Depends: libstdc++-8-dev || libstdc++-dev

which should keep working for a while, and also allow the 8->9
transition in due course.

This will go in next upload. WHich is waiting on fiding out what's up
with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887323
(exception tests failing on i386)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#892430: unattended-upgrades: Disabling unattended-upgrades and removing leaves apt update flag not set

[annadane]

Package: unattended-upgrades
Version: 1.0
Severity: normal

Dear Maintainer,

I had installed the pk-update-icon package which also installed and enabled 
unattended-upgrades. I did not want this in Debian Sid so I disabled and then 
apt removed unattended-upgrades.

I then would only get updated packages in general if I typed "apt update" 
manually. It turns out that turning off unattended-upgrades turns off all 
updates in general in an automatic way. I was of course still able to manually 
check the mirrors via apt update and get my updates in that way.

The solution to this in my particular case was that after unattended-upgrades 
was turned off and subsequently removed, to apt purge unattended-upgrades.

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

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

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  lsb-base   9.20170808
ii  lsb-release9.20170808
ii  python33.6.4-1
ii  python3-apt1.4.0~beta3+b1
ii  ucf3.0038
ii  xz-utils   5.2.2-1.3

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-128.1

Versions of packages unattended-upgrades suggests:
pn  bsd-mailx  
ii  exim4-daemon-light [mail-transport-agent]  4.90.1-1
ii  needrestart3.0-1

Bug#892429: irtt: FTBFS w/gccgo

[Aaron M. Ucko]

Package: irtt
Version: 0.9.0-2
Severity: important
Justification: fails to build from source

Builds of irtt with gccgo (on s390x and most non-release
architectures) failed with various errors, as detailed at [1].
Perhaps some of these architectures will be able to do better now that
we have gccgo 8, but if they don't, you may wish to consider
specifically build-depending on golang-go.

Could you please take a look?

Thanks!

[1] https://buildd.debian.org/status/logs.php?pkg=irtt=0.9.0-2

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

Bug#892428: pocl: FTBFS on x32: tries to build kernel/host/ for amd64

[Aaron M. Ucko]

Source: pocl
Version: 1.0-2
Severity: normal
User: debian-...@lists.debian.org
Usertags: x32

Builds of pocl for x32 (admittedly not a release architecture) have
been failing, as detailed at [1]:

  cd "/<>/obj-x86_64-linux-gnux32/lib/kernel/host" && 
/usr/bin/clang-4.0 --target=x86_64-pc-linux-gnu -D_CL_DISABLE_HALF 
-march=x86-64 -emit-llvm -ffp-contract=off -xc -D__CBUILD__ 
-fno-stack-protector -fno-PIC -DDORENAME -DVEC128 -I 
"/<>/lib/kernel/sleef/arch" -I 
"/<>/lib/kernel/sleef/libm" -I 
"/<>/lib/kernel/sleef/include" -O1 -o 
"/<>/obj-x86_64-linux-gnux32/lib/kernel/host/x86-64/v128_sleefsimddp.c.bc"
 -c "/<>/lib/kernel/sleef/libm/sleefsimddp.c"
  In file included from /<>/lib/kernel/sleef/libm/sleefsimddp.c:8:
  In file included from 
/usr/lib/llvm-4.0/bin/../lib/clang/4.0.1/include/stdint.h:61:
  /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not 
found

Could you please take a look?  (Note the explicit inappropriate
-march=x86-64.)

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=pocl=x32=1.1%7Erc2-1=1520368921=0

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

Bug#892427: mailman3-suite: Wrong permission on /var/lib/mailman3/suite/static/CACHE

[Markus Gschwendt]

Package: mailman3 (sid)
Version: 3.1.1
System: debian stretch

The directory is created with ownership root:root

Fix: chown www-data:www-data /var/lib/mailman3/suite/static/CACHE


ii  mailman3 0+20170523-
11all  Full Mailman3 mailing list management
suite (metapackage)
ii  mailman3-core3.1.1-
4  all  Mailing list management system
ii  mailman3-suite   0+20170523-
11all  Django project integrating Mailman3
Postorius and HyperKitty
ii  python-django-mailman3   1.1.0-
3  all  Django library to help interaction
with Mailman3 (Python 2 version)
ii  python-mailmanclient 3.1.1-
4  all  Python bindings for Mailman3 REST
API (Python 2 version)
ii  python3-mailman-hyperkitty   1.1.0-
1  all  Mailman3 plugin to archive emails
with HyperKitty

Bug#892426: pocl: FTBFS on most non-x86 architectures: 12-16% of tests pass

[Aaron M. Ucko]

Source: pocl
Version: 1.1~rc2-1
Severity: normal
Tags: upstream
User: debian-m...@lists.debian.org
Usertags: mips mips64el mipsel

Builds of pocl for most non-x86 architectures, including several
release architectures, failed with heavy test suite errors: between
12% and 16% of tests passed, depending on the architecture [1].  The
only exceptions are arm64, which succeeded, and armhf, on which 43% of
tests passed [2] -- still not great, but better.

More specifically, the failures in question occurred on armel, mips,
mips64el, mipsel, ppc64el, s390x, and the non-release architectures
powerpc, ppc64, and sparc64.  94 tests failed identically on all nine
of these architectures, as detailed below.  In addition, some tests
failed on only a subset of architectures:

  25 - kernel/test_shuffle_half (Failed): armel
  46/47 - regression/infinite_loop_REPL (Failed): sparc64
  60/61 - regression/infinite_loop_LOOPS (Failed): sparc64
  67/68 - regression/passing_a_constant_array_as_an_arg (Failed): sparc64
  79/80 - runtime/test_event_cycle (Failed): powerpc
  83/84 - runtime/clCreateKernel (Failed): sparc64
  84/85 - runtime/clGetKernelArgInfo (Failed): sparc64
  113/114 - examples/example1_dot_product (Child aborted): all but sparc64
  114/115 - examples/example2_matrix_transpose (Child aborted): all but sparc64
  115/116 - examples/example2_matrix_transpose_alocals (Child aborted): all but 
sparc64
  116/117 - poclcc (Child aborted): all but sparc64
  118/119 - examples/trig (Child aborted): all but sparc64
  119/120 - EinsteinToolkit (Child aborted): all but mips*
  120/121 - EinsteinToolkit_SubDev (Child aborted): all but mips*

NB: Test numbers vary somewhat because kernel/test_shuffle_half is #25
on armel and does not exist on the other eight affected architectures.

Could you please take a look?

Thanks!

[1] https://buildd.debian.org/status/logs.php?pkg=pocl=1.1%7Erc2-1
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888063

Here's the list of tests that failed on all nine of these architectures:

2 - kernel/test_as_type (Failed)
3 - kernel/test_convert_type_1 (Failed)
4 - kernel/test_convert_type_2 (Failed)
5 - kernel/test_convert_type_4 (Failed)
6 - kernel/test_convert_type_8 (Failed)
7 - kernel/test_convert_type_16 (Failed)
8 - kernel/test_bitselect (Failed)
9 - kernel/test_hadd_loopvec (Failed)
10 - kernel/test_hadd_loops (Failed)
11 - kernel/test_min_max (Failed)
12 - kernel/test_length_distance (Failed)
13 - kernel/test_fmin_fmax_fma (Failed)
14 - kernel/test_convert_sat_regression (Failed)
15 - kernel/test_rotate (Failed)
16 - kernel/test_fabs (Failed)
17 - kernel/test_short16 (Failed)
18 - kernel/test_frexp_modf (Failed)
19 - kernel/test_local_struct_array (Failed)
20 - kernel/test_sampler_address_clamp (Failed)
21 - kernel/test_image_query_funcs (Failed)
22 - kernel/test_shuffle_char (Failed)
23 - kernel/test_shuffle_short (Failed)
24 - kernel/test_shuffle_ushort (Failed)
26/27 - kernel/test_shuffle_uint (Failed)
27/28 - kernel/test_shuffle_float (Failed)
28/29 - kernel/test_shuffle_long (Failed)
29/30 - kernel/test_shuffle_ulong (Failed)
30/31 - kernel/test_shuffle_double (Failed)
31/32 - kernel/test_printf (Failed)
32/33 - kernel/test_sizeof_uint (Failed)
33/34 - regression/test_issue_231 (Failed)
34/35 - regression/test_issue_445 (Failed)
35/36 - regression/test_issue_553 (Failed)
37/38 - regression/phi_nodes_not_replicated_REPL (Failed)
38/39 - regression/issues_with_local_pointers_REPL (Failed)
39/40 - regression/barrier_between_two_for_loops_REPL (Failed)
40/41 - regression/simple_for-loop_with_a_barrier_inside_REPL (Failed)
41/42 - regression/for-loop_with_computation_after_the_brexit_REPL (Failed)
42/43 - regression/for-loop_with_a_variable_iteration_count_REPL (Failed)
43/44 - regression/early_return_before_a_barrier_region_REPL (Failed)
44/45 - regression/id-dependent_computation_before_kernel_exit_REPL (Failed)
45/46 - regression/barrier_just_before_return_REPL (Failed)
47/48 - regression/undominated_variable_from_conditional_barrier_handling_REPL 
(Failed)
48/49 - 
regression/assigning_a_loop_iterator_variable_to_a_private_makes_it_local_REPL 
(Failed)
49/50 - 
regression/assigning_a_loop_iterator_variable_to_a_private_makes_it_local_2_REPL
 (Failed)
50/51 - regression/test_program_from_binary_with_local_1_1_1_REPL (Failed)
51/52 - regression/phi_nodes_not_replicated_LOOPS (Failed)
52/53 - regression/issues_with_local_pointers_LOOPS (Failed)
53/54 - regression/barrier_between_two_for_loops_LOOPS (Failed)
54/55 - regression/simple_for-loop_with_a_barrier_inside_LOOPS (Failed)
55/56 - regression/for-loop_with_computation_after_the_brexit_LOOPS (Failed)
56/57 - regression/for-loop_with_a_variable_iteration_count_LOOPS (Failed)
57/58 - regression/early_return_before_a_barrier_region_LOOPS (Failed)
58/59 - regression/id-dependent_computation_before_kernel_exit_LOOPS (Failed)
59/60 - regression/barrier_just_before_return_LOOPS (Failed)
61/62 - 

Bug#892425: node-package-preamble: please make the output reproducible

[Ben Finney]

On 09-Mar-2018, Chris Lamb wrote:

> Upstream. I've filed it here:
>   https://github.com/mbostock/preamble/pull/4

I see that now, thank you.

> > Does this change apply more generally to many JavaScript packages?
> Not that I am aware of. It would only apply to a limit subset of
> packages where […]

Great, thank you for indulging my curiosity.

-- 
 \   “During the Middle Ages, probably one of the biggest mistakes |
  `\   was not putting on your armor because you were ‘just going down |
_o__)to the corner.’” —Jack Handey |
Ben Finney 


signature.asc
Description: PGP signature

Bug#892425: node-package-preamble: please make the output reproducible

[Ben Finney]

Chris Lamb  writes:

> diff --git a/bin/preamble b/bin/preamble
> index a563140..be96d96 100755
> --- a/bin/preamble
> +++ b/bin/preamble
> @@ -3,12 +3,17 @@
>  var os = require("os"),
>  fs = require("fs");
>  
> +var now = new Date();
> +if (process.env.SOURCE_DATE_EPOCH) {
> +  now = new Date((process.env.SOURCE_DATE_EPOCH * 1000) + 
> (now.getTimezoneOffset() * 6));
> +}
> +
>  fs.readFile("package.json", "utf8", function(error, text) {
>if (error) throw error;
>var json = JSON.parse(text);
>process.stdout.write("// " + (json.homepage || json.name)
>+ " Version " + json.version + "."
> -  + " Copyright " + (new Date).getFullYear()
> +  + " Copyright " + now.getFullYear()
>+ " " + json.author.name + (/\.$/.test(json.author.name) ? "" : ".")
>+ os.EOL);
>  });

Is this change generally useful to recipients of the upstream code base?
Or is it specific to OS distributions?

Does this constitute an improvement to the upstream code base? Or should
remain a persistent patch in the Debian package?

Does this change apply more generally to many JavaScript packages?

-- 
 \   “I prayed for twenty years but received no answer until I |
  `\  prayed with my legs.” —Frederick Douglass, escaped slave |
_o__)  |
Ben Finney 

Bug#892425: node-package-preamble: please make the output reproducible

[Chris Lamb]

Hi Ben,

> Is this change generally useful to recipients of the upstream code base?
> Or is it specific to OS distributions?

It is generally useful, not specific to any OS.

> Does this constitute an improvement to the upstream code base? Or should
> remain a persistent patch in the Debian package?

Upstream. I've filed it here:

  https://github.com/mbostock/preamble/pull/4
 
> Does this change apply more generally to many JavaScript packages?

Not that I am aware of. It would only apply to a limit subset of
packages where:

  a) We use the output during a package build
  b) That output ends up in the resulting binaries
  c) The output actually is not reproducible (ie. dates).

(The only other example I can recall right now is in uglifyjs which
has non- determinstic dictionary ordering IIRC.)


Regards,

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

Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram*

[Ben Hutchings]

On Thu, 2018-03-08 at 17:08 -0800, Kevin Hilman wrote:
> I'm not sure exactly what you're referring to, so I guess that means no.

Aren't you using LAVA in conjunction with kernelci?  That's where I've
seen this odd usage of "root=/dev/ram0" before.

> I'm just trying to avoid an unnecessary delay when "root=/dev/ram*" is
> (mistakenly) used on the command-line when passing in the debian
> ramdisk.  If that happens, it eventually falls through to the
> initramfs shell, but not before trying 30 times (with a "sleep 1"
> between each) to find another ramdisk on /dev/ramX

I'm pretty sure "break" does what you need.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source



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

Bug#892425: node-package-preamble: please make the output reproducible

[Chris Lamb]

forwarded 892425 https://github.com/mbostock/preamble/pull/4
thanks

I've forwarded this upstream here:

  https://github.com/mbostock/preamble/pull/4


Regards,

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

Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram*

[Ben Hutchings]

On Fri, 2018-03-09 at 00:55 +, Ben Hutchings wrote:
> Control: tag -1 moreinfo
> 
> Are you trying to fix the LAVA health check?

A longer and possibly more helpful answer:

1. initramfs-tools is primarily meant for booting a "real" system.  The
"root" kernel parameter says where that system is.  It doesn't make
sense to me to overload that parameter.

2. An initramfs is not the same thing as a ramdisk.  Treating device
names matching /dev/ram* specially could possibly conflict with a
configuration where both an initramfs and a ramdisk are used.

3. There is already a way to tell initramfs-tools abort the boot
process and start a shell - the "break" parameter, documented in
initramfs-tools(8).  (Hmm, that should probably be in section 7.)

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source



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

Bug#892425: node-package-preamble: please make the output reproducible

[Chris Lamb]

Source: node-package-preamble
Version: 0.1.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that node-package-preamble generates output that is not
reproducible which is affecting the reproducibility of (at least)
5 packages.

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/bin/preamble b/bin/preamble
index a563140..be96d96 100755
--- a/bin/preamble
+++ b/bin/preamble
@@ -3,12 +3,17 @@
 var os = require("os"),
 fs = require("fs");
 
+var now = new Date();
+if (process.env.SOURCE_DATE_EPOCH) {
+  now = new Date((process.env.SOURCE_DATE_EPOCH * 1000) + 
(now.getTimezoneOffset() * 6));
+}
+
 fs.readFile("package.json", "utf8", function(error, text) {
   if (error) throw error;
   var json = JSON.parse(text);
   process.stdout.write("// " + (json.homepage || json.name)
   + " Version " + json.version + "."
-  + " Copyright " + (new Date).getFullYear()
+  + " Copyright " + now.getFullYear()
   + " " + json.author.name + (/\.$/.test(json.author.name) ? "" : ".")
   + os.EOL);
 });

Bug#892417: RFS: streamlink/0.11.0+dfsg-1

[Paul Wise]

On Fri, Mar 9, 2018 at 7:37 AM, Alexis Murzeau wrote:

> I am looking for a sponsor for my package "streamlink" for a new
> upstream version 0.11.0.

Uploaded.

PS: if you would like to upload an official backport, feel free to
file another RFS for that when it reaches testing.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#892424: ITP: uhubctl -- USB hub per-port power control

[gustavo panizzo]

Package: wnpp
Severity: wishlist
Owner: gustavo panizzo 

* Package name: uhubctl
  Version : 1.8
  Upstream Author : Vadim Mikhailov 
* URL : https://github.com/mvp/uhubctl
* License : GPL
  Programming Lang: C
  Description : USB hub per-port power control

Utility to control USB power per-port on smart USB hubs.
Smart hub is defined as one that implements per-port power switching.

Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram*

[Kevin Hilman]

I'm not sure exactly what you're referring to, so I guess that means no.

I'm just trying to avoid an unnecessary delay when "root=/dev/ram*" is
(mistakenly) used on the command-line when passing in the debian
ramdisk.  If that happens, it eventually falls through to the
initramfs shell, but not before trying 30 times (with a "sleep 1"
between each) to find another ramdisk on /dev/ramX

On Thu, Mar 8, 2018 at 4:55 PM, Ben Hutchings  wrote:
> Control: tag -1 moreinfo
>
> Are you trying to fix the LAVA health check?
>
> Ben.
>
> --
> Ben Hutchings
> compatible: Gracefully accepts erroneous data from any source
>

Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram*

[Ben Hutchings]

Control: tag -1 moreinfo

Are you trying to fix the LAVA health check?

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source



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

Bug#892423: man -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz (and several others) enter infinite loop

[Anthony DeRobertis]

Package: man-db
Version: 2.8.2-1
Severity: normal

Running:

man -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz

starts outputting the manpage, but then at some point switches over to
outputting an (so far as I can tell) infinite loop of newlines:

   sources.list(5) ファイルに列挙された場所から取得した Packages ファイル
   や Release ファイルはすべて、/var/lib/apt/lists ディレクトリ
   や、apt.conf ファイルの Dir::State::Lists 変数で指定した場所に取得され
   ます。例え




Attaching the requested debug output is... difficult, but attached are
the first 100,000 lines:

   man --debug -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz |& head -n 
10 | gzip -v9 > /tmp/man-debug.txt.gz

I've also attached the apt_preferences page, just in case you have a
different version of apt; but note that other pages do this too (e.g.,
Japanese dos2unix page).

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

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

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2
ii  debconf [debconf-2.0]  1.5.66
ii  dpkg   1.19.0.5
ii  groff-base 1.22.3-10
ii  libc6  2.27-1
ii  libgdbm5   1.14.1-4
ii  libpipeline1   1.5.0-1
ii  libseccomp22.3.1-2.1
ii  zlib1g 1:1.2.8.dfsg-5

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor
ii  chromium [www-browser]  62.0.3202.89-1
ii  elinks [www-browser]0.12~pre6-13
ii  firefox [www-browser]   58.0.1-1+b1
ii  google-chrome-stable [www-browser]  65.0.3325.146-1
ii  groff   1.22.3-10
ii  konqueror [www-browser] 4:17.08.3-2
ii  less487-0.1
ii  links2 [www-browser]2.14-5
ii  lynx [www-browser]  2.8.9dev16-3
ii  w3m [www-browser]   0.5.3-36

-- debconf information:
  man-db/auto-update: true
* man-db/install-setuid: false


man-debug.txt.gz
Description: application/gzip


apt_preferences.5.gz
Description: application/gzip

Bug#892422: meson: autopkgtest fails on architectures where libasan is not available

[Jeremy Bicha]

Source: meson
Version: 0.45.0-1

meson's autopkgtest fails on Ubuntu's s390x architecture because
libasan is not available there.

Ubuntu has a simple patch that simply ignores failures for the
test_pch_with_address_sanitizer test. Otherwise, meson would be stuck
in the -proposed repository because of the autopkgtest regression.

References
--
https://autopkgtest.ubuntu.com/packages/meson/bionic/s390x
https://packages.debian.org/unstable/libasan3
http://launchpadlibrarian.net/360024047/meson_0.44.1-1ubuntu2_0.44.1-1ubuntu3.diff.gz

Thanks,
Jeremy Bicha

Bug#892420: nova: please make the build reproducible

[Chris Lamb]

forwarded 892420 https://github.com/openstack/nova/pull/80
thanks

I've forwarded this upstream here:

  https://github.com/openstack/nova/pull/80


Regards,

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

Bug#875343: Pending fixes for bugs in the carrotsearch-hppc package

[pkg-java-maintainers]

tag 875343 + pending
thanks

Some bugs in the carrotsearch-hppc package are closed in revision
bea14a12329f10d99aff587e0ef05cad7948df5f in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/carrotsearch-hppc.git/commit/?id=bea14a1

Commit message:

Fixed the build failure with Java 9 (Closes: #875343)

Bug#892421: apropos.1: Some cleaning of the manual

[Bjarni Ingi Gislason]

Package: man-db
Version: 2.8.2-1
Severity: minor
Tags: patch

Dear Maintainer,

Input file is apropos.1

Test nr. 1:
Remove space at end of lines to simplify other automatic tests to
improve typesetting.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".

6:.\" License as specified in the file COPYING that comes with the 
9:.\" Sat Oct 29 13:09:31 GMT 1994  Wilf. (g.wilf...@ee.surrey.ac.uk) 
10:.\" 
16:.B apropos 
33:Each manual page has a short description available within it. 
39:is usually a regular expression, as if 
124:.B \-m 
125:.I system\c 
127:.BI \-\-systems= system\c 
131:descriptions, they can be searched using this option. 
136:The 
139:To include a search of the native operating system's 
142:.B man 
152:By default, 
154:uses the 
156:environment variable, unless it is empty or unset, in which case it will 
157:determine an appropriate manpath based on your 
211:argument to the 
234:If 
236:is set, even to a null value, the default 
237:.B apropos 
238:search will be as an extended regex 
255:A traditional 

#

Test nr. 2:
Enable and fix warnings from 'test-groff'.

Input file is /tmp/apropos.1

:187 (macro BR): only 1 argument, but more are expected

chk_manuals: Output is from: test-groff -Tutf8 -b -e -mandoc -rF0 -t -w w -z 

Test nr. 15:
Change the name of a macro for two fonts (e.g., BR and IR) to one letter,
if there is only one argument.
Add the second argument if needed.  It is sometimes part of the first one.

187:.BR \-\-usage

#

Test nr. 8:
Protect a full stop (.) with "\&", if it has a blank (white-space) in
front of or (ignoring transparent characters to the full stop) after
it, and it does not mean an end of a sentence.

9:.\" Sat Oct 29 13:09:31 GMT 1994  Wilf. (g.wilf...@ee.surrey.ac.uk) 
264:Wilf. (g.wilf...@ee.surrey.ac.uk).

#

Test nr. 19:
Use '\e' to print the escape character instead of '\\'  (which gets
interpretet in copy mode).

48:or escape (\\) the special characters to stop the shell from interpreting

#

Test nr. 20:
Use a macro to change to the italic font, instead of \fI [1], if
possible.
The macros have the italic corrections, but "\c" removes them.
[1] man-pages(7)

104:\fB\-s\fP \fIlist\fP, \fB\-\-sections\fP \fIlist\fP, \fB\-\-section\fP 
\fIlist\fP

#

Test nr. 30:
Surround a block of comments with the macros ".ig" and "..".
The .\" at the beginning of each line is then not needed.
Makes it easier to add and remove text and adjust lenght of lines.

NO PATCH

1:.\" Man page for apropos
2:.\"
3:.\" Copyright (C), 1994, 1995, Graeme W. Wilford. (Wilf.)
4:.\"
5:.\" You may distribute under the terms of the GNU General Public
6:.\" License as specified in the file COPYING that comes with the 
7:.\" man-db distribution.
8:.\"
9:.\" Sat Oct 29 13:09:31 GMT 1994  Wilf. (g.wilf...@ee.surrey.ac.uk) 
10:.\" 
116:.\"
117:.\" Due to the rather silly limit of 6 args per request in some `native'
118:.\" *roff compilers, we have do the following to get the two-line
119:.\" hanging tag on one line. .PP to begin a new paragraph, then the
120:.\" tag, then .RS (start relative indent), the text, finally .RE
121:.\" (end relative indent).
122:.\"

#

Test nr. 35:
Add a space around "|" to increase readability.

243:.I /usr/share/man/index.(bt|db|dir|pag)
248:.I /var/cache/man/index.(bt|db|dir|pag)

#


The patch is in the attachment.

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

Kernel: Linux 4.9.80-2 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2
ii  debconf [debconf-2.0]  1.5.66
ii  dpkg   1.19.0.5
ii  groff-base 1.22.3-10
ii  libc6  2.27-1
ii  libgdbm5   1.14.1-4
ii  libpipeline1   1.5.0-1
ii  libseccomp22.3.1-2.1
ii  zlib1g 1:1.2.8.dfsg-5

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor   
ii  firefox-esr [www-browser]  52.6.0esr-2+b1
ii  groff  1.22.3-10
ii  less   487-0.1
ii  lynx [www-browser] 2.8.9dev16-3
ii  w3m [www-browser]  0.5.3-36

-- debconf information:
  man-db/auto-update: true
  man-db/install-setuid: false

-- 
Bjarni I. Gislason
--- apropos.1   2018-02-28 15:04:14.0 +
+++ apropos.1.new   2018-03-08 12:40:33.0 +
@@ -3,17 +3,17 @@
 .\" Copyright (C), 1994, 1995, Graeme W. Wilford. (Wilf.)
 .\"
 .\" You may distribute under the terms of the GNU General Public
-.\" License as specified in the file COPYING that comes with the 
+.\" License as specified in 

Bug#886798: libpoppler46: displays empty pages after security update

[Michael Siegel]

On Wed, 10 Jan 2018 11:43:47 +0100 Michael Weghorn 
wrote:
> Just a note: #886733 seems to describe the same problem for Debian stable.

And while that has already been fixed, the problem persists in
oldstable. I've been told that there's a workaround, but a fix would
still be much appreciated.


Thanks,

Michael

Bug#892419: gnocchi: please make the build reproducible

[Chris Lamb]

forwarded 892419 https://github.com/gnocchixyz/gnocchi/pull/803
thanks

I've forwarded this upstream here:

  https://github.com/gnocchixyz/gnocchi/pull/803


Regards,

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

Bug#892420: nova: please make the build reproducible

[Chris Lamb]

Source: nova
Version: 2:17.0.0~rc1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that nova could not be built reproducibly as the docs etc contain
the absolute build path.

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-build.patch   2018-03-08 16:02:34.172527581 
-0800
@@ -0,0 +1,14 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-03-08
+
+--- nova-17.0.0~rc1.orig/nova/conf/paths.py
 nova-17.0.0~rc1/nova/conf/paths.py
+@@ -22,6 +22,7 @@ from oslo_config import cfg
+ 
+ ALL_OPTS = [
+ cfg.StrOpt('pybasedir',
++sample_default='',
+ default=os.path.abspath(os.path.join(os.path.dirname(__file__),
+  '../../')),
+ help="""
--- a/debian/patches/series 2018-03-08 15:12:30.939719515 -0800
--- b/debian/patches/series 2018-03-08 16:02:32.928431102 -0800
@@ -3,3 +3,4 @@
 python3-fix-for-sphinx-doc.patch
 Fix_PatternPropertiesTestCase_for_py3.6.patch
 remove-crashing-blockdiag-doc-line.patch
+reproducible-build.patch

Bug#892419: gnocchi: please make the build reproducible

[Chris Lamb]

Source: gnocchi
Version: 4.2.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that gnocchi could not be built reproducibly as it iterates over
a Python set when generating documentation.

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-build.patch   2018-03-08 16:01:06.117130673 
-0800
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-03-08
+
+--- gnocchi-4.2.0.orig/gnocchi/common/redis.py
 gnocchi-4.2.0/gnocchi/common/redis.py
+@@ -102,7 +102,7 @@ OPTS = [
+   - http://redis.io/topics/sentinel
+   - http://redis.io/topics/cluster-spec
+ 
+-""" % "`, `".join(CLIENT_ARGS)),
++""" % "`, `".join(sorted(CLIENT_ARGS))),
+ ]
+ 
+ 
--- a/debian/patches/series 2018-03-08 15:26:55.192361493 -0800
--- b/debian/patches/series 2018-03-08 16:01:04.913021066 -0800
@@ -1 +1,2 @@
 py3-compat.patch
+reproducible-build.patch

Bug#868404: Pending fixes for bugs in the swt-gtk package

[pkg-java-maintainers]

tag 868404 + pending
thanks

Some bugs in the swt-gtk package are closed in revision
6925d8298081d484ab9873b601664dbc8c9e24b6 in branch '  master-4.3' by
Jeremy Bicha

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/swt-gtk.git/commit/?id=6925d82

Commit message:

Import Debian changes 4.6.3-1.1

swt4-gtk (4.6.3-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Drop libswt-gnome-gtk-4-jni (Closes: #868404)
  * Release to unstable

Bug#890102: openshot: Openshot 2.4.1-2 will not start

[waxhead]

Dr. Tobias Quathamer wrote:

control: severity -1 important

Am 11.02.2018 um 10:48 schrieb Svein Engelsgjerd:

Dear Maintainer,

When I start openshot the GUI constantly flickers between the main
window and the "welcome window" / tutorial dialog. It is not possible
to click the next button so the welcome window prevents the
application from being useful. (the desktop environment is XFCE)

Dear Svein,

thanks for filing this bug. I'm sorry that you cannot use openshot. Did
you start "openshot-qt" or "openshot"? Please note that the old binary
openshot does no longer exist, you should run "openshot-qt" now.
However, under normal circumstances, the upgrade you did perform should
have removed "openshot".

Unfortunately, I cannot reproduce this bug. Therefore, I'm downgrading
the bug's severity to important.

It might be due to my Xorg setup, but I was able to dismiss the flicking 
welcome window somehow and now OpenShot works great!


In case it helps my Xorg.conf looks like this and I started openshot on 
screen0


---snip---
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 331.67  (pbuilder@zam904)  Tue Apr 22 
12:02:15 UTC 2014


Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
Screen  1  "Screen1" RightOf "Screen0"
Screen  2  "Screen2" LeftOf "Screen0"
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
#Option "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"
# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
# HorizSync source: xconfig, VertRefresh source: xconfig
Identifier "MonitorCRT"
VendorName "Panasonic"
ModelName  "PanaSyncSL95"
HorizSync   30.0 - 97.0
VertRefresh 50.0 - 180.0
ModeLine   "1280x1024" 157.50 1280 1344 1504 1728 1024 1025 
1028 1072 +hsync +vsync

##Option "DPMS"
EndSection

Section "Monitor"
# HorizSync source: edid, VertRefresh source: edid
Identifier "MonitorLCD_Left"
VendorName "Unknown"
ModelName  "ViewSonic VP230mb"
HorizSync   30.0 - 82.0
VertRefresh 50.0 - 75.0
##Option "DPMS"
EndSection

Section "Monitor"
# HorizSync source: edid, VertRefresh source: edid
Identifier "MonitorLCD_Right"
VendorName "Unknown"
ModelName  "ViewSonic VP230mb"
HorizSync   30.0 - 82.0
VertRefresh 50.0 - 75.0
##Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName  "GeForce GTX 660"
BusID  "PCI:1:0:0"
Screen  0
EndSection

Section "Device"
Identifier "Device1"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName  "GeForce GTX 660"
BusID  "PCI:1:0:0"
Screen  1
EndSection

Section "Device"
Identifier "Device2"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName  "GeForce GTX 660"
BusID  "PCI:1:0:0"
Screen  2
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"MonitorCRT"
DefaultDepth24
Option "Stereo" "0"
#Option "nvidiaXineramaInfoOrder" "CRT-0"
Option "metamodes" "1280x1024 +0 +0"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth   24
EndSubSection
EndSection


Section "Screen"
Identifier "Screen1"
Device "Device1"
Monitor"MonitorLCD_Right"
DefaultDepth24
Option "Stereo" "0"
#Option "metamodes" "HDMI-0: nvidia-auto-select +0+0"
Option "metamodes" "1600x1200 +0 +0"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth   24
EndSubSection
EndSection

Section "Screen"
Identifier "Screen2"
Device "Device2"
Monitor"MonitorLCD_Left"
DefaultDepth24
Option "Stereo" "0"
#Option "metamodes" "DVI-D-0: nvidia-auto-select +0+0"
Option "metamodes" "1600x1200 +0 +0"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth   24
EndSubSection
EndSection
---snap---


Regards,
Tobias

Bug#892062: bug 892062 is forwarded to https://github.com/OSGeo/proj.4/issues/833

[Olly Betts]

Control: tags 892062 + patch

On Sun, Mar 04, 2018 at 09:10:28PM +0100, Bas Couwenberg wrote:
> forwarded 892062 https://github.com/OSGeo/proj.4/issues/833
> thanks

There's now a patch for this:

https://github.com/OSGeo/proj.4/pull/845

Cheers,
Olly

Bug#892417: RFS: streamlink/0.11.0+dfsg-1

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 0.11.0.

 * Package name: streamlink
   Version : 0.11.0+dfsg-1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  livestreamer - transitional package - streamlink
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documenta
  streamlink - CLI for extracting video streams from various websites to
a video

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.11.0+dfsg-1.dsc

More information about streamlink can be obtained from
https://streamlink.github.io/

Changes since the last upload:
streamlink (0.11.0+dfsg-1) unstable; urgency=low

  * Fix comments in d/rules.
  * Use streamlink's own donation page instead of opencollective one.
  * Fix random test failure caused by hexdump output optimization with
 wildcards.
  * Add example directory.
  * New upstream version 0.11.0+dfsg.
  * python3-socks is now required as a build dependency.

 -- Alexis Murzeau   Fri, 09 Mar 2018 00:12:49 +0100

Regards,
--
 Alexis Murzeau
 PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F







signature.asc
Description: OpenPGP digital signature

Bug#892418: lyx-common: Invalid python2 syntax

[Michael Rasmussen]

Package: lyx-common
Version: 2.3.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Either lyx-common scripts should be python neutral - run both with python 2.7 
and python 3.x or explicitely specify python3 in the shebang line.

  File "/usr/share/lyx/scripts/convertDefault.py", line 68
print(sys.argv[0], 'ERROR', file=sys.stderr)
^
SyntaxError: invalid syntax

  File "/usr/share/lyx/scripts/fig_copy.py", line 23
print("Usage: fig_copy.py  ", file=sys.stderr)
  ^
SyntaxError: invalid syntax

dpkg: error processing package lyx-common (--configure):
 installed lyx-common package post-installation script subprocess returned 
error exit status 101

An example:
$ python
Python 2.7.14+ (default, Feb  6 2018, 19:12:18) 
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print("Usage: fig_copy.py  ", file=sys.stderr)
  File "", line 1
print("Usage: fig_copy.py  ", file=sys.stderr)
  ^
SyntaxError: invalid syntax
>>> 

$ python3
Python 3.6.4+ (default, Feb 12 2018, 08:25:03) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print("Usage: fig_copy.py  ", file=sys.stderr)
Usage: fig_copy.py  
>>> 


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

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

Versions of packages lyx-common depends on:
ii  python  2.7.14-4
ii  tex-common  6.09

Versions of packages lyx-common recommends:
iu  lyx  2.3.0-1

lyx-common suggests no packages.

-- no debconf information



This mail was virus scanned and spam checked before delivery.
This mail is also DKIM signed. See header dkim-signature.

Bug#892411: Pending fixes for bugs in the java3d package

[pkg-java-maintainers]

tag 892411 + pending
thanks

Some bugs in the java3d package are closed in revision
d17a89ba073c90777eda223e5e32305a74092796 in branch 'master' by
Emmanuel Bourg

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

Commit message:

Added the client JVM to the link path (Closes: #892411)

Bug#892411: java3d FTBFS on armhf: compile-ogl fails

[Emmanuel Bourg]

Le 08/03/2018 à 21:13, Adrian Bunk a écrit :

> Likely caused by:
> 
> openjdk-8 (8u144-b01-1) unstable; urgency=medium
> ...
>   * debian/rules:
> - add aarch32 hotspot support.
> - build aarch32 using client jvm-variant (no server in aarch32 port).

Good analysis, thank you. I'll add the client path.

Emmanuel Bourg

Bug#892358: xul-ext-gnome-keyring: Don't depend on libgnome-keyring

[Jeremy Bicha]

On Thu, Mar 8, 2018 at 4:26 PM, Ximin Luo  wrote:
> Do you have some advice on how to migrate? Last time I checked there was no 
> straightforward 1-1 correspondence between the libsecret vs the 
> libgnome-keyring API and data models.
>
> Forcing people to do extra work they don't know how to do, or else risk 
> losing their most precious data, is extremely irresponsible software 
> development.

libgnome-keyring has been deprecated for 4 years. [1]

Maybe https://wiki.gnome.org/Initiatives/GnomeGoals/LibsecretMigration can help.

I apologize that a bug for this issue wasn't filed here sooner. By my
estimates, libgnome-keyring will otherwise be ready for removal from
Buster in early April.

As you're aware, xul-ext-gnome-keyring won't work with Firefox 60 ESR
anyway, which will be released in 2 months (Debian may delay the
switch a few months but that isn't very long really.) [2]

[1] https://git.gnome.org/browse/libgnome-keyring/commit/?id=6a5adea4aec93
[2] https://bugs.debian.org/881506 and
https://wiki.mozilla.org/RapidRelease/Calendar

Thanks,
Jeremy Bicha

Bug#803713: Elasticsearch should not be part of a Debian release

[Emmanuel Bourg]

Le 08/03/2018 à 22:50, Nicolas Braud-Santoni a écrit :

> Given that this is the last activity and the package, that the last upload
> is almost 2 years old, and that no progress has been made towards fixing the
> RC bugs (esp. the issues wrt. security), should we ask ftp-masters to remove
> this package from sid?

+1

Bug#892360: core: do not free stack-allocated strings

[Elimar Riesebieter]

* Jindřich Makovička  [2018-03-08 19:46 +]:

> There is a fix in upstream master.
> 
> https://github.com/systemd/systemd/pull/8391

Patched Debian sources and tried to build packages:

OK:   239
FAIL:   1
SKIP:  15
TIMEOUT:0
debian/rules:281: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/source/systemd/systemd-238'
debian/rules:294: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned
exit status 2
debuild: fatal error at line 1152:
dpkg-buildpackage -rfakeroot -us -uc -ui -jauto failed
mydebuild auto  4036,66s user 309,41s system 98% cpu 1:13:39,49 tota


Hope Debian mainatiners provide new packages for testing

Thanks for your efforts
Elimar
-- 
  Alles, was viel bedacht wird, wird bedenklich!;-)
 Friedrich Nietzsche

Bug#892416: ITP: opam-file-format -- Parser and printer for the opam file syntax

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

* Package name: opam-file-format
  Version : 2.0.0~beta5
  Upstream Author : Louis Gesbert 
* URL : https://github.com/ocaml/opam-file-format/blob/master/opam
* License : LGPL-2.1 with OCaml linking exception
  Programming Lang: OCaml
  Description : Parser and printer for the opam file syntax

opam-file-format is a dependency for OPAM 2.x (which is currently
a release candidate); the package would be maintained as part of
pkg-ocaml.


Best,

  nicoo

Bug#268492: mark entries as unread

[Paul Gevers]

In the upcoming release, you have the ability to install a
nomarkallunread plugin to prevent this issue.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#892389: eztrace-contrib: build-depends on GCC 6

[Samuel Thibault]

Control: clone -1 -2
Control: reassign -2 nvidia-cuda-toolkit
Control: block -1 by -2
Control: block 892403 by -2

Hello,

po...@debian.org, on jeu. 08 mars 2018 18:48:47 +0100, wrote:
> eztrace-contrib build-depends on GCC 6.
> starpu-contrib build-depends on GCC 6.

This is due to CUDA, whose version 9.1 still doesn't support gcc more
recent than gcc 6.

Samuel

Bug#884123: liferea: Liferea 1.12.0 hides the preview by default

[Paul Gevers]

Hi Annadane,

On Tue, 12 Dec 2017 00:03:35 +0100 Lars Windolf  wrote:
> Hi,
> 
> one of the changes in 1.12 was an improved handling of the pane proportion
> in 3-pane modes (both email-like and wide-view). A possible bug could be 
> that
> a pane is resized to 0 width.
> 
> @Annadane: you could check for a zero width pane by checking wether there
> is a resize bars at the right border of the item list?
> If there is, try dragging it to the left.
> 
> Best Regards,
> Lars
> 
> 
> On 11.12.2017 20:29, Paul Gevers wrote:
> > Hi Annadane,
> >
> > Thanks for the report.
> >
> > On 11-12-17 19:16, annadane wrote:
> >> Liferea 1.12.0 seems to start in "full screen" - ie, there is no
> >> split view between the feed links at the top and the article/feed at
> >> the bottom. I suspect this is unintentional? There doesn't seem to be
> >> anything to toggle it in the preferences
> > Can you please elaborate what you see (and maybe add a screenshot)?
> >
> > I am running 1.12.0 myself and I think I don't have your issue, so, some
> > more questions:
> >
> > * Did you install liferea new, or did you upgrade?
> >
> > * If you upgraded, do you experience the same issue when you
> > (temporarily) move ~/.config/liferea/ out of the way (while liferea is
> > not running)?
> >
> > * What desktop are you using?
> >
> > * Have you tried all three different views in the "View" tab? Does that
> > make any difference?

Can you please reply the questions? Otherwise, I'll probably close the
bug (in more than a month from now) as there is nothing we can do
without more info.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#892414: O: trac-bitten -- continuous integration plugin for Trac

[W. Martin Borgert]

Package: wnpp
Severity: normal

I intend to orphan the trac-bitten package.
I'm not using it anymore, because bitten (without additional
patches) does not play well with git.
Our project moved to buildbot, which, while not integrated into
Trac, plays well.

The package description is:
 Bitten is a Trac extension for continuous integration. It uses
 a distributed build model, where one or more "slaves" run the
 actual tests, and a "master" gathers the results and displays
 them nicely on a web page.
 .
 Bitten is similar to BuildBot, Gump, Hudson, Jenkins, or
 Tinderbox, but integrated well into Trac.
 .
 This package contains the master, implemented as Trac plugin.

Bug#660683: O: xmlroff -- XSL formatter mainly for DocBook

[W. Martin Borgert]

As the second uploader of this package, I also have to orphan it.
I'm not using xmlroff anymore, but it was very helpful for me,
before dblatex became as good as it is now.

Bug#803713: Elasticsearch should not be part of a Debian release

[Nicolas Braud-Santoni]

On Mon, Nov 21, 2016 at 09:33:18PM +0100, Hilko Bengen wrote:
> * Emmanuel Bourg:
> > Do you think elasticsearch should be removed from unstable?
> 
> Not necessarily. It should just not become part of stretch because there
> is no sensible way to support it.

Given that this is the last activity and the package, that the last upload
is almost 2 years old, and that no progress has been made towards fixing the
RC bugs (esp. the issues wrt. security), should we ask ftp-masters to remove
this package from sid?


Best,

  nicoo

Bug#892412: O: rabbitvcs -- Easy version control

[W. Martin Borgert]

Package: wnpp
Severity: normal

I'm not using rabbitvcs myself and my colleagues moved to the
command line since long. Nice program to have in Debian, but
it needs a maintainer who actually uses it.

Bug#892358: xul-ext-gnome-keyring: Don't depend on libgnome-keyring

[Ximin Luo]

Do you have some advice on how to migrate? Last time I checked there was no 
straightforward 1-1 correspondence between the libsecret vs the 
libgnome-keyring API and data models.

Forcing people to do extra work they don't know how to do, or else risk losing 
their most precious data, is extremely irresponsible software development.

X

Jeremy Bicha:
> Package: xul-ext-gnome-keyring
> Version: 0.12-1
> Severity: serious
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs libgnome-keyring-removal
> Tags: sid buster
> 
> As announced [1], we are working to remove libgnome-keyring from
> Debian. The libgnome-keyring library is deprecated and its usage is strongly
> discouraged [2].
> 
> Your package xul-ext-gnome-keyring depends on libgnome-keyring0.
> 
> Please update your application to use libsecret instead [3].
> Such a port should ideally happen with upstream being involved.
> 
> Otherwise, please consider requesting that your package be removed
> from Debian to
> help us complete this goal.
> 
> [1] https://lists.debian.org/debian-devel/2018/02/msg00169.html
> [2] https://git.gnome.org/browse/libgnome-keyring/commit/?id=6a5adea4aec93
> [3] https://wiki.gnome.org/Projects/Libsecret
> 
> On behalf of the Debian GNOME team,
> Jeremy Bicha
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#892041: qemu: CVE-2018-7550: i386: multiboot OOB access while loading kernel image

[Salvatore Bonaccorso]

On Sun, Mar 04, 2018 at 02:12:45PM +0100, Salvatore Bonaccorso wrote:
> [2] https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg06890.html

Actual upstream patch according to
https://bugzilla.redhat.com/show_bug.cgi?id=1549798 is
https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01885.html

Regards,
Salvatore

Bug#892406: live-build: UEFI boot fails on SuperMicro dev board with AMI bios

[Thomas Schmitt]

Hi,

i wonder why the built-in configuration of the EFI boot file does not work:

 # mount debian-live-9.3.0-amd64-xfce.iso /mnt/iso
 # mount /mnt/iso/boot/grub/efi.img /mnt/fat
 # strings /mnt/fat/efi/boot/bootx64.efi | tail -4
 search --file --set=root /.disk/info
 set prefix=($root)/boot/grub
 source $prefix/x86_64-efi/grub.cfg
 (memdisk)/boot/grub

Isn't this program supposed to start GRUB, look for the marker file in the
ISO filesystem, and execute /boot/grub/x86_64-efi/grub.cfg in there ?

The commit
  
https://salsa.debian.org/live-team/live-build/merge_requests/3/diffs?commit_id=7676cc8988781dc9899cf3bac2e822618f117f3e
shows a similar gesture with a different marker file path and different
execution commands for grub.cfg, which are quite equivalent:
  https://www.gnu.org/software/grub/manual/grub/html_node/source.html


Have a nice day :)

Thomas

Bug#892411: java3d FTBFS on armhf: compile-ogl fails

[Adrian Bunk]

Source: java3d
Version: 1.5.2+dfsg-11
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/buster/armhf/java3d.html
https://buildd.debian.org/status/fetch.php?pkg=java3d=armhf=1.5.2%2Bdfsg-12=1520519146=0

...
compile-ogl:
...
 [exec] ld: cannot find -ljvm
 [exec] Result: 1
...
install -m 644 -D j3d-core/build/default/opt/native/libj3dcore-ogl.so \
debian/libjava3d-jni/usr/lib/jni/libj3dcore-ogl.so
install: cannot stat 'j3d-core/build/default/opt/native/libj3dcore-ogl.so': No 
such file or directory
debian/rules:25: recipe for target 'override_dh_auto_install-arch' failed
make[1]: *** [override_dh_auto_install-arch] Error 1


Likely caused by:

openjdk-8 (8u144-b01-1) unstable; urgency=medium
...
  * debian/rules:
- add aarch32 hotspot support.
- build aarch32 using client jvm-variant (no server in aarch32 port).
...
 -- Matthias Klose   Wed, 23 Aug 2017 21:41:07 +0200

Bug#892360: systemd: No problem on my amd64 systems

[Elimar Riesebieter]

* Diederik de Haas  [2018-03-08 20:29 +0100]:

> Package: systemd
> Followup-For: Bug #892360
> 
> Wanting to let you know that I had no problem on my PC (from which I'm
> reporting) and also not on my laptop.
> 
> I did not have to specify any (systemd related) kernel parameters
> $ cat /proc/cmdline
> BOOT_IMAGE=/vmlinuz-4.15.0-1-amd64 
> root=UUID=a2a5e481-0ac6-4e68-818f-38255bf7dd57 ro quiet

Well, I reported the initial reportfor x86 only, though.

Elimar
-- 
  "Talking much about oneself can also
   be a means to conceal oneself."
 -Friedrich Nietzsche

Bug#892360: core: do not free stack-allocated strings

[Jindřich Makovička]

There is a fix in upstream master.

https://github.com/systemd/systemd/pull/8391
-- 
Jindřich Makovička

Bug#892410: Updating the compactheader Uploaders list

[Tobias Frost]

Source: compactheader
Version: 2.1.1~beta1-1 2.0.8-1 2.1.0-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Williams Orellana  has not been working on
the compactheader package for quite some time. Addtionally, his email
adress is bouncing. 

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#892360: systemd: Breaks also all my tested amd64 machines

[Elimar Riesebieter]

* Elimar Riesebieter  [2018-03-08 19:13 +0100]:

[...]

> ATM I am building a x86 with CONFIG_CGROUP_CPUACCT=not set. Let's
> wait and see

"CONFIG_CGROUP_CPUACCT is not set" gives the same error as shown in
the picture of my initial bug report.

The problem must be triggerd from within systemd.

Elimar
-- 
  355/113: Not the famous irrational number pi,
   but an incredible simulation!
-unknown

Bug#892360: systemd: No problem on my amd64 systems

[Diederik de Haas]

Package: systemd
Followup-For: Bug #892360

Wanting to let you know that I had no problem on my PC (from which I'm
reporting) and also not on my laptop.

I did not have to specify any (systemd related) kernel parameters
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.15.0-1-amd64 
root=UUID=a2a5e481-0ac6-4e68-818f-38255bf7dd57 ro quiet

$ grep CGROUP /boot/config-$(uname -r)
CONFIG_CGROUPS=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_BPF=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_NETFILTER_XT_MATCH_CGROUP=m
CONFIG_NET_CLS_CGROUP=m
CONFIG_CGROUP_NET_PRIO=y
CONFIG_CGROUP_NET_CLASSID=y

HTH

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.117
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.12-3
ii  libaudit11:2.8.2-1
ii  libblkid12.31.1-0.5
ii  libc62.27-1
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.1-1
ii  libgcrypt20  1.8.1-4
ii  libgpg-error01.27-6
ii  libidn11 1.33-2.1
ii  libip4tc01.6.2-1
ii  libkmod2 25-1
ii  liblz4-1 0.0~r131-2+b1
ii  liblzma5 5.2.2-1.3
ii  libmount12.31.1-0.5
ii  libpam0g 1.1.8-3.7
ii  libseccomp2  2.3.1-2.1
ii  libselinux1  2.7-2+b1
ii  libsystemd0  238-1
ii  mount2.31.1-0.5
ii  procps   2:3.3.12-4
ii  util-linux   2.31.1-0.5

Versions of packages systemd recommends:
ii  dbus1.12.6-2
ii  libpam-systemd  238-1

Versions of packages systemd suggests:
ii  policykit-10.105-18
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 238-1

-- no debconf information

Bug#892408: firmware-iwlwifi: please package new upstream version to get firmware-iwlwifi-8265-34

[Felipe Sateler]

Package: firmware-iwlwifi
Version: 20170823-1
Severity: wishlist

Hi,

The currently packaged snapshot is missing (at least)
firmware-iwlwifi-8265-34, which is required for the intel wifi card on
my laptop (Dell Latitude 5285) to work. 

02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
Subsystem: Intel Corporation Wireless 8265 / 8275
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

Fetching the file from upstream git repository was enough to make the
wifi card work.

Saludos

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.130

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/firmware/intel/ibt-11-5.ddc (from firmware-iwlwifi 
package)
debsums: changed file /lib/firmware/intel/ibt-11-5.sfi (from firmware-iwlwifi 
package)

Bug#877040: New upstream version, including transition to webext

[david s]

Hello,

I'm interested in potentially taking on maintenance of this package. I
am new to Debian but I'd like to start contributing.

To explore this possibility, I've created a proof-of-concept transition
script. Please take a look at the attached script and let me know your
thoughts and suggestions.

Regarding the other part of this bug, it appears that some work has been
done on #866997 to support webext. I plan to look into this and see if I
can contribute to that as well.

David


ublock_migration.sh
Description: Bourne shell script

Bug#886145: shutter: Don't recommend libgoo-canvas-perl

[Jeremy Bicha]

Control: severity -1 serious

It is my understanding that is a RC bug for package to recommend a
library that has been removed from Testing because recommended
packages won't be auto-removed on upgrade.

See Debian Policy § 2.2.1.

Thanks,
Jeremy Bicha

Bug#892083: smplayer: recodes filenames to wrong encoding

[Oleg Broytman]

Hi! Thanks for trying but still doesn't work.

On Thu, Mar 08, 2018 at 05:27:18PM +0100, Fabian Greffrath  
wrote:
> Am Montag, den 05.03.2018, 06:28 +0300 schrieb Oleg Broytman:
> > ii  mpv   1:0.27.2-dmo1+deb9u1
> 
> Please try again with Debian's mpv package.

   The command

mpv media/Видео/somevideo.avi

   plays the video perfectly. (The Russian word in the path means
"Video", written in koi8-r, locale is ru_RU.KOI8-R.)

   The command

smplayer media/Видео/somevideo.avi

   doesn't work. smplayer's error log in the log window is

/usr/bin/mpv --no-config --no-quiet --terminal --no-msg-color 
--input-file=/dev/stdin --no-fs --hwdec=no --sub-auto=fuzzy --vo=xv, 
--ao=pulse, --no-input-default-bindings --input-vo-keyboard=no 
--no-input-cursor --cursor-autohide=no --no-keepaspect --wid=37748755 
--monitorpixelaspect=1 --osd-scale=0 --sub-ass --embeddedfonts 
--sub-ass-line-spacing=0 --sub-scale=1 --sub-font=Arial --sub-color=# 
--sub-shadow-color=#ff00 --sub-border-color=#ff00 --sub-border-size=2.5 
--sub-shadow-offset=5 --sub-codepage=enca:ru:CP1251 --sub-pos=100 --volume=64 
--cache=auto --osd-level=0 --screenshot-template=cap_%F_%p_%02n 
--screenshot-format=jpg 
--screenshot-directory=/home/phd/tmp/smplayer_screenshots --audio-channels=2 
--audio-pitch-correction=yes --af-add=equalizer=0:0:0:0:0:0:0:0:0:0 
--volume-max=100 --ytdl=no --term-playing-msg=MPV_VERSION=${=mpv-version:}
INFO_VIDEO_WIDTH=${=width}
INFO_VIDEO_HEIGHT=${=height}
INFO_VIDEO_ASPECT=${=video-aspect}
INFO_VIDEO_FPS=${=container-fps:${=fps}}
INFO_VIDEO_FORMAT=${=video-format}
INFO_VIDEO_CODEC=${=video-codec}
INFO_AUDIO_FORMAT=${=audio-codec-name}
INFO_AUDIO_CODEC=${=audio-codec}
INFO_AUDIO_RATE=${=audio-params/samplerate}
INFO_AUDIO_NCH=${=audio-params/channel-count}
INFO_LENGTH=${=duration:${=length}}
INFO_DEMUXER=${=current-demuxer:${=demuxer}}
INFO_SEEKABLE=${=seekable}
INFO_TITLES=${=disc-titles}
INFO_CHAPTERS=${=chapters}
INFO_TRACKS_COUNT=${=track-list/count}
METADATA_TITLE=${metadata/by-key/title:}
METADATA_ARTIST=${metadata/by-key/artist:}
METADATA_ALBUM=${metadata/by-key/album:}
METADATA_GENRE=${metadata/by-key/genre:}
METADATA_DATE=${metadata/by-key/date:}
METADATA_TRACK=${metadata/by-key/track:}
METADATA_COPYRIGHT=${metadata/by-key/copyright:}
INFO_MEDIA_TITLE=${=media-title:}
 --term-status-msg=STATUS: ${=time-pos} / ${=duration:${=length:0}} P:
${=pause} B: ${=paused-for-cache} I: ${=core-idle}
media/???/somevideo.avi

Playing: media/???/somevideo.avi
[file] Cannot open file 'media/???/somevideo.avi': No such file or 
directory
Failed to open media/???/somevideo.avi.
Exiting... (Errors when loading file)

   media/Видео/somevideo.avi is recoded to a wrong encoding, probably
utf-8. When I move the file to tmp/somevideo.avi smplayer plays it. But
I don't want to rename all my directories and files.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.

Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram*

[Kevin Hilman]

Package: initramfs-tools
Version: 0.130

>From a2aef0d83cd19d9b69a747c7ddbcee564faac914 Mon Sep 17 00:00:00 2001
From: Kevin Hilman 
Date: Thu, 8 Mar 2018 11:01:38 -0800
Subject: [PATCH] scripts/local: ignore /dev/ram*

These scripts are already running in a ramdisk, so ignore
any root=/dev/ram* so we don't waste 30 sec looping.

Signed-off-by: Kevin Hilman 
---
 scripts/local | 8 
 1 file changed, 8 insertions(+)

diff --git a/scripts/local b/scripts/local
index 4ec926cae6cb..103a8fffd7c7 100644
--- a/scripts/local
+++ b/scripts/local
@@ -60,6 +60,14 @@ local_device_setup()
local time_elapsed
local count
 
+   # We're already in a ramdisk, don't waste 30 sec looping waiting
+   # for /dev/ram* devices
+   expr match ${dev_id#/dev/} "ram" > /dev/null
+   if [ $? = 0 ]; then
+   echo "Ignoring ${dev_id}.  We're already in a ramdisk."
+   return 1
+   fi
+
wait_for_udev 10
 
# Load ubi with the correct MTD partition and return since fstype
-- 
2.11.0

Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition

[Sven Joachim]

Control: tags -1 + patch

On 2018-03-07 18:54 +0100, Sven Joachim wrote:

> Package: libcdk5
> Version: 5.0.20161210-5
>
> There is a new ncurses version in experimental which changes the soname
> of the libraries from 5 to 6.  One notable change between libncurses5
> and libncurses6 is that the "chtype" data type has changed from unsigned
> long to unsigned int.  This affects the cdk library, which makes use of
> chtype all over the place.
>
> If libcdk5 has been rebuilt against libncurses6 but the application
> using it has not, or vice versa, they disagree about what "chtype" is,
> and bad things can happen on 64-bit architectures, where
> sizeof(long) != sizeof(int).
>
> For testing purposes, I have built the example programs in libcdk5-doc
> on amd64 with libncurses6 and the libcdk5 library which is still linked
> against libncurses5.  While most of them seem to work, I got a segfault
> in demos/clock and a bus error in buttonbox_ex.
>
> My conclusion is that it is very risky to allow such combinations, and
> to rule them out I propose to change the package name of the cdk
> library, say to libcdk5a.  It would then have to build-depend on
> libncurses-dev (>= 6.1+20180210) to ensure that it is linked against
> libncurses6 and not libncurses5.  Of course this can only be uploaded
> to experimental for now, but should go to unstable when the ncurses
> transition starts there.

Attached is a patch which should do the trick.  Maybe there are other
ways to address the incompatibility, but renaming the libcdk5 library
package looks both safe and simple to me.

Cheers,
   Sven

>From 0be150d0078ebf4711f08a0aa2e795cdd948ab9d Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Wed, 7 Mar 2018 19:02:30 +0100
Subject: [PATCH] Rename the library package to libcdk5a

The change of the "chtype" data type in libncurses6 means that it is
not safe to have the cdk library and applications using it linked
against different ncurses versions.

To ensure that both the library and the application are linked against
libncurses6 rather than libncurses5, rename the library package and
bump the build-dependency.

Add a lintian override for the resulting
package-name-doesnt-match-sonames warning.
---
 debian/control   | 8 +---
 debian/{libcdk5.install => libcdk5a.install} | 0
 debian/libcdk5a.lintian-overrides| 3 +++
 debian/{libcdk5.symbols => libcdk5a.symbols} | 2 +-
 4 files changed, 9 insertions(+), 4 deletions(-)
 rename debian/{libcdk5.install => libcdk5a.install} (100%)
 create mode 100644 debian/libcdk5a.lintian-overrides
 rename debian/{libcdk5.symbols => libcdk5a.symbols} (99%)

diff --git a/debian/control b/debian/control
index 194ad46..6dd5a6f 100644
--- a/debian/control
+++ b/debian/control
@@ -3,15 +3,17 @@ Section: libs
 Priority: optional
 Maintainer: Herbert Parentes Fortes Neto 
 Standards-Version: 4.1.3
-Build-Depends: debhelper (>= 9), libncurses5-dev, pkg-config
+Build-Depends: debhelper (>= 9), libncurses-dev (>= 6.1+20180210), pkg-config
 Homepage: http://invisible-island.net/cdk
 Vcs-Git: https://salsa.debian.org/debian/libcdk5.git
 Vcs-Browser: https://salsa.debian.org/debian/libcdk5
 
-Package: libcdk5
+Package: libcdk5a
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Conflicts: libcdk5
+Replaces: libcdk5
 Description: C-based curses widget library
  CDK stands for "Curses Development Kit". CDK sits on top of the curses
  library and provides 22 ready to use widgets for rapid application
@@ -22,7 +24,7 @@ Description: C-based curses widget library
 Package: libcdk5-dev
 Architecture: any
 Section: libdevel
-Depends: libcdk5 (= ${binary:Version}), libncurses5-dev, ${misc:Depends}
+Depends: libcdk5a (= ${binary:Version}), libncurses5-dev, ${misc:Depends}
 Description: C-based curses widget library (development files)
  CDK stands for "Curses Development Kit". CDK sits on top of the curses
  library and provides 22 ready to use widgets for rapid application
diff --git a/debian/libcdk5.install b/debian/libcdk5a.install
similarity index 100%
rename from debian/libcdk5.install
rename to debian/libcdk5a.install
diff --git a/debian/libcdk5a.lintian-overrides b/debian/libcdk5a.lintian-overrides
new file mode 100644
index 000..d6057a5
--- /dev/null
+++ b/debian/libcdk5a.lintian-overrides
@@ -0,0 +1,3 @@
+# library package had to be renamed for libncurses6 transition
+# see https://bugs.debian.org/892280
+libcdk5a: package-name-doesnt-match-sonames libcdk5
diff --git a/debian/libcdk5.symbols b/debian/libcdk5a.symbols
similarity index 99%
rename from debian/libcdk5.symbols
rename to debian/libcdk5a.symbols
index 962abd4..f68b0e2 100644
--- a/debian/libcdk5.symbols
+++ b/debian/libcdk5a.symbols
@@ -1,4 +1,4 @@
-libcdk.so.5 libcdk5 #MINVER#
+libcdk.so.5 libcdk5a #MINVER#
  Beep@Base 5.0.20161120
  CDKDEBUG@Base 5.0.20161120
  CDKVersion@Base 5.0.20161120
-- 
2.16.2

Bug#892360: systemd: Breaks also all my tested amd64 machines

[Eric Valette]

On 3/8/18 7:26 PM, Eric Valette wrote:

On 3/8/18 7:13 PM, Elimar Riesebieter wrote:


I do have CONFIG_CGROUP_CPUACCT=y on my amd64 kernels and systemd
runs fine...


Ok. So still in line with hypothesis...


ATM I am building a x86 with CONFIG_CGROUP_CPUACCT=not set. Let's
wait and see


And I'm rebuilding my failing kernel with only this config variable 
manually changed... Let wait and report.


OK. My own kernel now boots so the problem is induced by code that is 
trigerred when not set.


I have no need for cgroup accounting, only process group sheduling so it 
is only for a try...


--eric

Bug#892406: live-build: UEFI boot fails on SuperMicro dev board with AMI bios

[Luca Boccassi]

Package: live-build
Version: 1:20171207
Tags: patch
Severity: minor

Dear Maintainer,

On some UEFI implementations, like the AMI found on the SuperMicro
X10SDV-TP8F dev board, the fat32 partition will be loaded first and so
Grub will set it the root, and then drop to the console as it cannot
find any config on it.

A solution is to have a minimal grub.cfg that just finds the ISO 9660
partition with the main grub.cfg and loads it. A Merge Request with
this implementation, which has been tested on the above platform, has
been sent to Salsa. [1]

This minimal grub.cfg will also be useful for Secure Boot support,
which has been implemented in a separate commit, in the same Merge
Request.

Thanks!

-- 
Kind regards,
Luca Boccassi

[1] https://salsa.debian.org/live-team/live-build/merge_requests/3

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

Bug#865931: mysql-server: Does not allow me to change root password

[Antonio Ospite]

Package: mariadb-server-10.1
Followup-For: Bug #865931

Dear Maintainer,

I think this bug can be closed because MariaDB works as intended and as
documented in /usr/share/doc/mariadb-server-10.1/README.Debian.gz

The database root user is not supposed to log in with a password, but
via the unix_socket plugin with the system root user.

To the users who reported the issue: please don't change the settings of
the root user, you'll break the maintenance scripts.

Creating an additional admin user is what Debian maintainers recommend
in /usr/share/doc/mariadb-server-10.1/README.Debian.gz in the PASSWORDS
section, also here:
https://salsa.debian.org/mariadb-team/mariadb-10.1/blob/stretch/debian/mariadb-server-10.1.README.Debian#L73

Ciao,
   Antonio

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

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

Versions of packages mariadb-server-10.1 depends on:
ii  adduser   3.117
ii  debconf [debconf-2.0] 1.5.66
ii  galera-3  25.3.22-1
ii  gawk  1:4.1.4+dfsg-1+b1
ii  iproute2  4.15.0-2
ii  libaio1   0.3.110-5
ii  libc6 2.27-1
ii  libdbi-perl   1.640-1
ii  libpam0g  1.1.8-3.7
ii  libstdc++68-20180218-1
ii  libsystemd0   238-1
ii  lsb-base  9.20170808
ii  lsof  4.89+dfsg-0.1
ii  mariadb-client-10.1   1:10.1.29-6
ii  mariadb-common1:10.1.29-6
ii  mariadb-server-core-10.1  1:10.1.29-6
ii  passwd1:4.5-1
ii  perl  5.26.1-5
ii  psmisc23.1-1
ii  rsync 3.1.2-2.1
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mariadb-server-10.1 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.1 suggests:
ii  mailutils [mailx]  1:3.4-1
ii  netcat-openbsd 1.187-1
pn  tinyca 

-- debconf information excluded
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#892360: systemd: Breaks also all my tested amd64 machines

[Eric Valette]

On 3/8/18 7:13 PM, Elimar Riesebieter wrote:


I do have CONFIG_CGROUP_CPUACCT=y on my amd64 kernels and systemd
runs fine...


Ok. So still in line with hypothesis...


ATM I am building a x86 with CONFIG_CGROUP_CPUACCT=not set. Let's
wait and see


And I'm rebuilding my failing kernel with only this config variable 
manually changed... Let wait and report.


--eric

Bug#892405: installation-reports: Theobroma Systems RK3399-Q7 SoM, partial success

[Vagrant Cascadian]

Package: installation-reports
Severity: normal

Install required manual installation of firmware, boot loader,
device-tree and initial boot configuration, but otherwise went mostly
ok. Some of that will be fixed in upcoming u-boot and flash-kernel
uploads.

The install ran very slow, as cpu frequency scaling was not enabled, and
the default processor speeds on this board are very slow.

More specific details in the Comments/Problems section below.

live well,
  vagrant


-- Package-specific info:

Boot method: network
Image version: 
https://d-i.debian.org/daily-images/arm64/20180307-02:05/netboot/debian-installer/arm64/
Date: 2018-03-07

Machine: Theobroma Systems RK3399-Q7 SoM
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs979508   0979508   0% /dev
tmpfs  tmpfs   2047845356199428   3% /run
/dev/mmcblk1p3 ext4   4740224 1460868   3018852  33% /
tmpfs  tmpfs  1023912   0   1023912   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs  1023912   0   1023912   0% /sys/fs/cgroup
tmpfs  tmpfs   204780   0204780   0% /run/user/1000

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[O]

Comments/Problems:

For arm64, debian-installer does not include the device-tree files from
the linux-image package, so I had to manually download the appropriate
linux-image package and extract the correct .dtb file. This works for
boards where the firmware provides a device-tree, but not all boards do.

U-boot and flash-kernel didn't include support; both will be fixed in
next uploads.

In order to load u-boot, this board requires building
arm-trusted-firmware and m0 firmware from theobroma's git repositories,
so until that is present in Debian it may not be possible for
debian-installer to provide initial boot images out of the box.

The daily installer was running a 4.15.x kernel, and I saw that the
4.15.x kernels had landed in buster, so was surprised on initial boot
that it installed the 4.14.x kernel. Linux 4.14.x had some instabilities
that seem to be fixed in 4.15.x.

Enabling cpu frequency scaling from debian-installer would significantly
speed up the install process for this board, as the default CPU speeds
are quite slow. Ironically, the faster A72 cores do not support CPU
frequency scaling in the kernel, and the board appears to run faster
with those cores disabled.

-- 

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20180307-02:03"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux rk3399pma 4.15.0-1-arm64 #1 SMP Debian 4.15.4-1 (2018-02-18) 
aarch64 GNU/Linux
lsmod: Module  Size  Used by
lsmod: dm_mod143360  0
lsmod: md_mod159744  0
lsmod: xfs  1241088  0
lsmod: libcrc32c  16384  1 xfs
lsmod: jfs   196608  0
lsmod: btrfs1257472  0
lsmod: xor20480  1 btrfs
lsmod: zstd_decompress77824  1 btrfs
lsmod: zstd_compress 163840  1 btrfs
lsmod: xxhash 16384  2 zstd_compress,zstd_decompress
lsmod: raid6_pq  102400  1 btrfs
lsmod: vfat   24576  0
lsmod: fat81920  1 vfat
lsmod: ext4  667648  1
lsmod: crc16  16384  1 ext4
lsmod: mbcache16384  1 ext4
lsmod: jbd2  114688  1 ext4
lsmod: crc32c_generic 16384  0
lsmod: fscrypto   32768  1 ext4
lsmod: ecb16384  0
lsmod: usb_storage73728  0
lsmod: scsi_mod  241664  1 usb_storage
lsmod: dwc3  135168  0
lsmod: udc_core   49152  1 dwc3
lsmod: micrel 24576  1
lsmod: dwc3_of_simple 16384  0
lsmod: dwmac_rk   32768  0
lsmod: ehci_platform  16384  0
lsmod: ohci_platform  16384  0
lsmod: stmmac_platform20480  1 dwmac_rk
lsmod: ohci_hcd   61440  1 ohci_platform
lsmod: stmmac131072  3 stmmac_platform,dwmac_rk
lsmod: ehci_hcd   90112  1 ehci_platform
lsmod: ptp24576  1 stmmac
lsmod: pps_core   20480  1 ptp
lsmod: usbcore   

Bug#892360: systemd: Breaks also all my tested amd64 machines

[Elimar Riesebieter]

* Eric Valette  [2018-03-08 19:08 +0100]:

> On 3/8/18 7:03 PM, Elimar Riesebieter wrote:
> > * Michael Biebl  [2018-03-08 18:54 +0100]:
> > 
> > [...]
> > > Can you check your custom kernel config, specifically if
> > > CONFIG_CGROUP_CPUACCT=y
> > 
> > I do have CONFIG_CGROUP_CPUACCT=y
> > 
> > Well, but why does 237 works with the very same kernel?
> 
> In my case it is not set, so maybe it is another combined config set ...

I do have CONFIG_CGROUP_CPUACCT=y on my amd64 kernels and systemd
runs fine...

ATM I am building a x86 with CONFIG_CGROUP_CPUACCT=not set. Let's
wait and see

Elimar
-- 
  Obviously the human brain works like a computer.
  Since there are no stupid computers humans can't be stupid.
  There are just a few running with Windows or even CE ;-)

Bug#892360: systemd: Breaks also all my tested amd64 machines

[Eric Valette]

On 3/8/18 7:03 PM, Elimar Riesebieter wrote:

* Michael Biebl  [2018-03-08 18:54 +0100]:

[...]

Can you check your custom kernel config, specifically if
CONFIG_CGROUP_CPUACCT=y


I do have CONFIG_CGROUP_CPUACCT=y

Well, but why does 237 works with the very same kernel?


In my case it is not set, so maybe it is another combined config set ...

--eric

Bug#892360: systemd: Breaks also all my tested amd64 machines

[Elimar Riesebieter]

* Michael Biebl  [2018-03-08 18:54 +0100]:

[...] 
> Can you check your custom kernel config, specifically if
> CONFIG_CGROUP_CPUACCT=y

I do have CONFIG_CGROUP_CPUACCT=y

Well, but why does 237 works with the very same kernel?

Elimar
-- 
  Numeric stability is probably not all that
  important when you're guessing;-)

Bug#892360: systemd: Breaks also all my tested amd64 machines

[Eric Valette]

Can you check your custom kernel config, specifically if
CONFIG_CGROUP_CPUACCT=y

Probably easiest if you just use grep
grep CGROUP /boot/config-$(uname -r)


Done in another private email. Can copy here:


diff config-4.14.0-3-amd64 config-4.14.23 | grep CGROUP
< CONFIG_BLK_CGROUP=y
< # CONFIG_DEBUG_BLK_CGROUP is not set
< CONFIG_CGROUP_WRITEBACK=y
> # CONFIG_BLK_CGROUP is not set
< CONFIG_CGROUP_PIDS=y
> # CONFIG_CGROUP_PIDS is not set
< CONFIG_CGROUP_FREEZER=y
> # CONFIG_CGROUP_FREEZER is not set
< CONFIG_CGROUP_CPUACCT=y
< CONFIG_CGROUP_PERF=y
< # CONFIG_CGROUP_BPF is not set
> # CONFIG_CGROUP_CPUACCT is not set
> # CONFIG_CGROUP_PERF is not set
< CONFIG_SOCK_CGROUP_DATA=y
> # CONFIG_SOCK_CGROUP_DATA is not set
< CONFIG_NETFILTER_XT_MATCH_CGROUP=m
< CONFIG_NET_CLS_CGROUP=m
< CONFIG_CGROUP_NET_PRIO=y
< CONFIG_CGROUP_NET_CLASSID=y
> # CONFIG_CGROUP_NET_PRIO is not set
> # CONFIG_CGROUP_NET_CLASSID is not set

Bug#892360: systemd: Breaks also all my tested amd64 machines

[Michael Biebl]

Am 08.03.2018 um 18:31 schrieb Elimar Riesebieter:
> * Michael Biebl  [2018-03-08 17:09 +0100]:
> 
>> Am 08.03.2018 um 17:05 schrieb Michael Biebl:
>>> Control: tags -1 moreinfo
>>>
>>> Am 08.03.2018 um 16:23 schrieb valette:
>>>
> [...]
> 
>> Could you check if
>> https://github.com/systemd/systemd/issues/8387
>> looks related
>>
>> I.e. if booting with systemd.unified_cgroup_hierarchy avoids the problem.
> 
> Booting with ystemd.unified_cgroup_hierarchy avoids the problem. But
> FMPOV this is only a workaround. Maybe
> https://github.com/systemd/systemd/pull/8391 should be merged
> upstream?

So, I got confirmation from Eric, that booting with a Debian kernel,
i.e. linux-image-4.14.0-3-amd64 avoids the problem, so does booting with
systemd.unified_cgroup_hierarchy according to Elimar.

Can you check your custom kernel config, specifically if
CONFIG_CGROUP_CPUACCT=y

Probably easiest if you just use grep
grep CGROUP /boot/config-$(uname -r)

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



signature.asc
Description: OpenPGP digital signature

Bug#888935: node-xterm FTBFS: error TS2339: Property 'parentElement' does not exist on type 'never'

[Ghislain Vaillant]

> Source: node-xterm
> Version: 2.7.0+ds1-1
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/no
> de-xterm.html
> 
> ...
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/build/1st/node-xterm-2.7.0+ds1'
> tsc --project .
> src/utils/Mouse.ts(30,80): error TS2339: Property 'parentElement'
> does not exist on type 'never'.
> debian/rules:19: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 2

No idea how to fix this. The package used to build fine.

Without further context, I am clueless about what to do about it.

Please help,
Ghis

Bug#892387: ITP: python3-pyzabbix -- PyZabbix is a Python module for working with the Zabbix API.

[Michal Arbet]

Package: wnpp
Severity: wishlist
Owner: Michal Arbet 

* Package name: python3-pyzabbix
  Version : 0.7.4
  Upstream Author : Luke Cyca >
* URL : https://github.com/lukecyca/pyzabbix

* License : LGPL-2.1
  Programming Lang: Python
  Description : Zabbix API Python Library.

This is a client library for Zabbix API which is dependency for vitrage -
Openstack Service.

 - This package is dependency for vitrage - Openstack Service.
 - I will maintain it inside a packaging team Debian Openstack

Bug#882538: jpeg-6b configure.in (etc.) reconstruction

[Adam Sampson]

This sounded like an interesting software archeology problem...

Tom Lane of IJG posted a slightly later version of jpeg's configure.in
and associated files to the UnixOS2 mailing list in 2004:
http://unix.os2site.com/pub/list/unixos2/2004/03/2004Mar31000402.txt
> Let's see ... configure is built like this:
> 
> configure: configure.in sed.cfg aclocal.m4
> autoconf configure.in | sed -f sed.cfg >configure
> chmod +x configure

I've lightly modified the files he posted so that they exactly reproduce
the configure script in jpeg-6b, which is what's bundled in outguess and
various other packages, when built with autoconf 2.12. The modified
files are attached; you also need libtool.m4 from libtool 1.2.

-- 
Adam Sampson  
dnl IJG auto-configuration source file. [reconstructed 2018]
dnl Process this file with autoconf to produce a configure script.
AC_INIT(jcmaster.c)
AC_CONFIG_HEADER(jconfig.h:jconfig.cfg)
dnl
dnl do these first since other macros rely on them
AC_PROG_CC
AC_PROG_CPP
dnl
dnl See if compiler supports prototypes.
AC_MSG_CHECKING(for function prototypes)
AC_CACHE_VAL(ijg_cv_have_prototypes,
[AC_TRY_COMPILE([
int testfunction (int arg1, int * arg2); /* check prototypes */
struct methods_struct { /* check method-pointer declarations */
  int (*error_exit) (char *msgtext);
  int (*trace_message) (char *msgtext);
  int (*another_method) (void);
};
int testfunction (int arg1, int * arg2) /* check definitions */
{ return arg2[arg1]; }
int test2function (void)/* check void arg list */
{ return 0; }
], [ ], ijg_cv_have_prototypes=yes, ijg_cv_have_prototypes=no)])
AC_MSG_RESULT($ijg_cv_have_prototypes)
if test $ijg_cv_have_prototypes = yes; then
  AC_DEFINE(HAVE_PROTOTYPES,)
else
  echo Your compiler does not seem to know about function prototypes.
  echo Perhaps it needs a special switch to enable ANSI C mode.
  echo If so, we recommend running configure like this:
  echo "   ./configure  CC='cc -switch'"
  echo where -switch is the proper switch.
fi
dnl
dnl check header files
AC_CHECK_HEADER(stddef.h, AC_DEFINE(HAVE_STDDEF_H,))
AC_CHECK_HEADER(stdlib.h, AC_DEFINE(HAVE_STDLIB_H,))
AC_CHECK_HEADER(string.h,, AC_DEFINE(NEED_BSD_STRINGS,))
dnl See whether type size_t is defined in any ANSI-standard places;
dnl if not, perhaps it is defined in .
AC_MSG_CHECKING(for size_t)
AC_TRY_COMPILE([
#ifdef HAVE_STDDEF_H
#include 
#endif
#ifdef HAVE_STDLIB_H
#include 
#endif
#include 
#ifdef NEED_BSD_STRINGS
#include 
#else
#include 
#endif
typedef size_t my_size_t;
], [ my_size_t foovar; ], ijg_size_t_ok=yes,
[ijg_size_t_ok="not ANSI, perhaps it is in sys/types.h"])
AC_MSG_RESULT($ijg_size_t_ok)
if test "$ijg_size_t_ok" != yes; then
AC_CHECK_HEADER(sys/types.h, [AC_DEFINE(NEED_SYS_TYPES_H,)
AC_EGREP_CPP(size_t, [#include ],
[ijg_size_t_ok="size_t is in sys/types.h"], ijg_size_t_ok=no)],
ijg_size_t_ok=no)
AC_MSG_RESULT($ijg_size_t_ok)
if test "$ijg_size_t_ok" = no; then
  echo Type size_t is not defined in any of the usual places.
  echo Try putting '"typedef unsigned int size_t;"' in jconfig.h.
fi
fi
dnl
dnl check compiler characteristics
AC_MSG_CHECKING(for type unsigned char)
AC_TRY_COMPILE(, [ unsigned char un_char; ],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_UNSIGNED_CHAR,)], AC_MSG_RESULT(no))
AC_MSG_CHECKING(for type unsigned short)
AC_TRY_COMPILE(, [ unsigned short un_short; ],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_UNSIGNED_SHORT,)], AC_MSG_RESULT(no))
AC_MSG_CHECKING(for type void)
AC_TRY_COMPILE([
/* Caution: a C++ compiler will insist on valid prototypes */
typedef void * void_ptr;/* check void * */
#ifdef HAVE_PROTOTYPES  /* check ptr to function returning void */
typedef void (*void_func) (int a, int b);
#else
typedef void (*void_func) ();
#endif

#ifdef HAVE_PROTOTYPES  /* check void function result */
void test3function (void_ptr arg1, void_func arg2)
#else
void test3function (arg1, arg2)
 void_ptr arg1;
 void_func arg2;
#endif
{
  char * locptr = (char *) arg1; /* check casting to and from void * */
  arg1 = (void *) locptr;
  (*arg2) (1, 2);   /* check call of fcn returning void */
}
], [ ], AC_MSG_RESULT(yes), [AC_MSG_RESULT(no)
AC_DEFINE(void,char)])

AC_C_CONST
dnl check for non-broken inline under various spellings
AC_MSG_CHECKING(for inline)
ijg_cv_inline=""
AC_TRY_COMPILE(, [} __inline__ int foo() { return 0; }
int bar() { return foo();], ijg_cv_inline="__inline__",
AC_TRY_COMPILE(, [} __inline int foo() { return 0; }
int bar() { return foo();], ijg_cv_inline="__inline",
AC_TRY_COMPILE(, [} inline int foo() { return 0; }
int bar() { return foo();], ijg_cv_inline="inline")))
AC_MSG_RESULT($ijg_cv_inline)
AC_DEFINE_UNQUOTED(INLINE,$ijg_cv_inline)
dnl we cannot check for bogus warnings, but at least we can check for errors
AC_MSG_CHECKING(for broken incomplete types)
AC_TRY_COMPILE([ typedef struct undefined_structure * undef_struct_ptr; ], ,
AC_MSG_RESULT(ok),

Bug#892360: systemd: Breaks also all my tested amd64 machines

[Elimar Riesebieter]

* Michael Biebl  [2018-03-08 17:09 +0100]:

> Am 08.03.2018 um 17:05 schrieb Michael Biebl:
> > Control: tags -1 moreinfo
> > 
> > Am 08.03.2018 um 16:23 schrieb valette:
> > 
[...]

> Could you check if
> https://github.com/systemd/systemd/issues/8387
> looks related
> 
> I.e. if booting with systemd.unified_cgroup_hierarchy avoids the problem.

Booting with ystemd.unified_cgroup_hierarchy avoids the problem. But
FMPOV this is only a workaround. Maybe
https://github.com/systemd/systemd/pull/8391 should be merged
upstream?

Elimar
-- 
  Learned men are the cisterns of knowledge,
  not the fountainheads ;-)

Bug#892360: systemd pid 1 freezes at startup on x86 systems

[Michael Biebl]

Am 08.03.2018 um 18:27 schrieb Elimar Riesebieter:
> * Michael Biebl  [2018-03-08 17:05 +0100]:
> 
>> Control: tags -1 moreinfo
>>
>> Am 08.03.2018 um 16:23 schrieb valette:
>>
>>> Kernel: Linux 4.14.23 (SMP w/2 CPU cores; PREEMPT)
>>
>> Is this also happening with a Debian provided kernel?
>> I see both you and Elimar use a custom one.
> 
> Didn't test it.

Please do

Please also try to gather the other data I asked for in my other replies


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

Bug#892360: systemd pid 1 freezes at startup on x86 systems

[Elimar Riesebieter]

* Michael Biebl  [2018-03-08 17:05 +0100]:

> Control: tags -1 moreinfo
> 
> Am 08.03.2018 um 16:23 schrieb valette:
> 
> > Kernel: Linux 4.14.23 (SMP w/2 CPU cores; PREEMPT)
> 
> Is this also happening with a Debian provided kernel?
> I see both you and Elimar use a custom one.

Didn't test it.

> Is this a virtualized environment or read hardware?
> Do you get a coredump? If so, please attach to this bug report.

No coredump available. This is on real hardware.

Elimar
-- 
  Never make anything simple and efficient when a way
  can be found to make it complex and wonderful ;-)

Bug#892386: ITP: python3-pgzero -- pygame zero, environment for zero-boilerplate programming of 2D games.

[plugwash]

Package: wnpp
Severity: wishlist
Owner: plugwash 

* Package name: python3-pgzero
  Version : 1.2.post1
  Upstream Author : Daniel Pope 
* URL : https://bitbucket.org/lordmauve/pgzero
* License : LGPLv3
  Programming Lang: python3
  Description : pygame zero, environment for zero-boilerplate programming 
of 2D games.

Pygame zero provides an environment in which 2D games can be developed in
python without the need for boilerplate code or complex APIs.

It is intended for use in education, so that teachers can teach basic
programming without needing to explain the Pygame API or write an event loop.

Bug#662794: nmudiff: Please, add a non-dd template for those who can not upload NMUs

[Pierre-Elliott Bécue]

Le jeudi 08 mars 2018 à 02:44:21+0100, Mattia Rizzolo a écrit :
> On Wed, Mar 07, 2018 at 11:41:08PM +0100, Pierre-Elliott Bécue wrote:
> > In the other cases, it only adds a tag pending, which is not in
> > contradiction with not being a DD, as a pending tag only means that the
> > changes are included in the package's vcs and will be included in the next
> > release.
> 
> That's not true.
> Despite being from a time before me, I know that the 'pending' tag long
> predates the common usage of a VCS for packaging.
> It just means the change has been added to the maintainer's working
> tree, whatever that means.
> In the case of a NMU it just has a different meaning of being already
> uploaded to a delayed queue (or not, you can do a NMU by announcing you
> will upload in 5 days without using the technicality of the delayed
> upload queue).  Consider that usually NMUs are not committed anywhere in
> the maintainer's space.

Yes, you're right, I kind of interpreted pending according to what I see
now, but it's biased as it doesn't reflect the full reality.

> > I think the appropriate answer to your remarks is to include your template
> > feature, and add a --no-pending-tag argument to prevent the pending tag from
> > being added to the mail.
> > 
> > Apart from that, I don't see how it would make a real difference between 
> > being
> > DD/DM or just a contributor.
> 
> As a non-DD I'd probably look for a template that says something like
> "I've prepared …… and I'm now looking for sponsorship for an upload to
> DELAYED/whatever", with the idea that then whenever a sponsor uploads
> just adds the 'pending' tag.
> But I've been a DD for too long, I don't remember anymore my troubles
> with NMUs when I wasn't yet a DD, what about you?

The fact that a non-DD would ask for sponsorship seems quite relevant to me.
It seems to fit with my proposition doesn't it?

Thanks,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#891623: Will need updates for new version of libwebservice-musicbrainz-perl

[Steve McIntyre]

Hi Elimar!

On Tue, Mar 06, 2018 at 03:09:12PM +0100, Elimar Riesebieter wrote:
>* Steve McIntyre  [2018-02-27 11:37 +]:
>> Based on the code changes we've needed in abcde, I'm assuming this
>> will cause ripit to stop working in unstable at that point. The
>> changes aren't *huge*, but they're not small (see the patch in
>> https://abcde.einval.com/bugzilla/show_bug.cgi?id=60 as a guide) so
>> I'm assuming you'll need to work with ripit upstream to make that
>> happen. Although... the ripit homepage link now points to a "domain
>> for sale" site - is there still an upstream?
>
>Felix Suwald is MIA. I tried several time to contact him since 09/17
>but got no response :-(

That's a shame.

>As I am not a perl hacker I can not take over ripit's upstream so
>there are two possibilities:
>
>1st: I could try to find a successor on debian-devel or somewhere else.
>2nd: I orphan ripit in Debian.

ACK. If upstream has gone away and you're not up to maintaining the
perl then it's definitely time to do one of those. Maybe an RFH to see
if somebody can help with the work? Maybe time to learn perl if you're
still wanting to use it.

>Anyway I'll try to adapt the new API to ripit myself but won't be
>willing to maintain as an upstream.

Right.

As a heads-up, I uploaded the new version of
libwebservice-musicbrainz-perl late last night along with the new
upstream version of abcde, so the musicbrainz code in ripit will no
longer work in unstable:

(SID-AMD64)steve@tack:~/debian/abcde/abcde.git$ ripit --mb
RipIT version 4.0.0-beta20140508.

Lame not found (needed to encode mp3)!
Use oggenc instead (to generate ogg)?
Do you want to try oggenc? [y/n] (y) y

Please install WebService::MusicBrainz and dependencies
from your closest CPAN mirror before trying again with
option --mb.
Install by hand or using force because using (as root):
perl -MCPAN -e 'install WebService::MusicBrainz'
might fail.


For users happy with cddb it seems it will still work for now, though.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll

Bug#892286: RFP: python3-aiosasl -- pure python generic asyncio SASL library

[Jonas Wielicki]

> Supported SASL mechanisms
>  - PLAIN: authenticate with plaintext password (RFC 4616)
>  - ANONYMOUS: anonymous "authentication" (RFC 4505)
>  - SCRAM-SHA-1, SCRAM-SHA-224, , SCRAM-SHA-512, SCRAM-SHA-384,
>and SCRAM-SHA-256: Salted Challenge Response Authentication
>(RFC 5802), (and the -PLUS variants with channel binding).

The currently released version does not have support for -PLUS, so I suggest 
to use (for now):

> Supported SASL mechanisms
>  - PLAIN: authenticate with plaintext password (RFC 4616)
>  - ANONYMOUS: anonymous "authentication" (RFC 4505)
>  - SCRAM-SHA-1, SCRAM-SHA-224, SCRAM-SHA-512, SCRAM-SHA-384,
>and SCRAM-SHA-256: Salted Challenge Response Authentication
>(RFC 5802), without channel binding (-PLUS variants)

kind regards,
Jonas

Bug#892385: easytag-nautilus: Move appstream metadata here

[Jeremy Bicha]

Package: easytag-nautilus
Severity: important
Version: 2.4.3-2
Tags: patch

easytag includes the AppStream metadata for both easytag and
easytag-nautilus. easytag-nautilus' AppStream metadata needs to be
moved to the easytag-nautilus package for AppStream clients like GNOME
Software to be able to correctly install easytag-nautilus.

I will submit a merge request
https://salsa.debian.org/multimedia-team/easytag/merge_requests

Thanks,
Jeremy Bicha

Bug#892384: RFP: jabbercat -- modern XMPP client

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

Package name: jabbercat
Version : git snapshot 2018-03-08
Upstream Author : Jonas Wielicki 
URL : https://jabbercat.org/
License : GPL3
Programming Lang: Python (with Qt5)
Description : modern XMPP client

"If you are intrigued by the User Experience provided by
modern, non-XMPP and/or non-free chat applications, this
is for you. We aim to provide Conversations-like chat
experience based on XMPP on the Desktop!"

This is pretty much a work in progress and should be
packaged only for experimental for now.

Bug#892383: RFS: librime/1.2.10+dfsg2-1

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-input-met...@lists.debian.org

  Dear mentors,

  I am looking for a sponsor for team package "librime"

 * Package name: librime
   Version : 1.2.10+dfsg2-1
   Upstream Author : GONG Chen 
 * URL : https://github.com/lotem/librime
 * License : GPL-3
   Section : libs

  It builds those binary packages:

 librime-bin - Rime Input Method Engine - utilities
 librime-dev - Rime Input Method Engine, the core library - development files
 librime1   - Rime Input Method Engine - core library

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/libr/librime/librime_1.2.10+dfsg2-1.dsc

  Git packaging repository:

https://anonscm.debian.org/git/pkg-ime/librime.git

  I'm also looking for a DD to move this git repository onto Salsa (under
Debian group).

  Changes since the last upload:

librime (1.2.10+dfsg2-1) unstable; urgency=medium

  * Team upload.
  * New upstream release.
  * Remove more unused source code and regenerate +dfsg2 tarball.
  * d/patches: Backport some fixes, refresh patches.
  * d/copyright: Refresh copyright information.
  * d/control: Use debian-input-method maillist in Maintainer field.
  * d/control: Add libboost-locale-dev as build dependency.
  * d/rules: Install CHANGELOG.md as upstream changelog.
  * d/rules: Disable tests since GTest module is problematic.
  * d/control: Apply "wrap-and-sort -abst".
  * d/compat: Bump to debhelper compat v11.
  * d/watch: Use dversionmangle instead of uversionmangle.

 -- Boyuan Yang <073p...@gmail.com>  Sun, 25 Feb 2018 16:16:40 +0800


  Regards,
   Boyuan Yang

Bug#885728: Pending fixes for bugs in the icu4j-4.2 package

[pkg-java-maintainers]

tag 885728 + pending
thanks

Some bugs in the icu4j-4.2 package are closed in revision
3241d4d895f3fc3da94c68f1fade54f8eed5f2a6 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/icu4j-4.2.git/commit/?id=3241d4d

Commit message:

No longer exclude the .gz files from the upstream tarball (Closes: #885728)

Bug#875402: Pending fixes for bugs in the icu4j-4.2 package

[pkg-java-maintainers]

tag 875402 + pending
thanks

Some bugs in the icu4j-4.2 package are closed in revision
7eb09152b37d25078eb010c090c3de64e0a28608 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/icu4j-4.2.git/commit/?id=7eb0915

Commit message:

Fixed the build failure with Java 9 (Closes: #875402)

Bug#892083: smplayer: recodes filenames to wrong encoding

[Fabian Greffrath]

Am Montag, den 05.03.2018, 06:28 +0300 schrieb Oleg Broytman:
> ii  mpv   1:0.27.2-dmo1+deb9u1

Please try again with Debian's mpv package.

 - Fabian


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

Bug#889877: Not reproduceable

[Frédéric Bonnard]

Hi,
it seems that we can't reproduce this bug anymore as golang went from
1.9 to 1.10 now.
Well, it fails on another issue on ppc64el, but it seems to be the same on 
amd64 .
Should we close that bug ?

F.


pgp9_HmRMlFTP.pgp
Description: PGP signature

Bug#892382: devscripts: FTBFS in mipsel/mips64el: uscan_ftp test timeouts

[Mattia Rizzolo]

Source: devscripts
Version: 2.18.1
Severity: serious
X-Debbugs-Cc: Osamu Aoki 

Hi Osamu-san :)

the new uscan_ftp tests seems to misbehave on mipsel/mips64el.
Just to mention one:

|testWatch4NonNativeDlUversion
|FTP starting ... /tmp/tmp.XEqC4nYhhq/repo
|uscan warn: In directory ., downloading
|  ftp://127.0.0.1:37207/0.0/foo/ooo/foo-0.0.tar.gz.asc failed: 401 
[LWP::Protocol::MyFTP] Timeout
|uscan die: FAIL Checking OpenPGP signature (no signature file downloaded).
|uscan: Newest version of foo on remote site is 0.0, specified download version 
is 0.0
|ASSERT:uscan: exit_code!=0 but exit_code=0 expected:<255> but was:<0>
|ASSERT:foo_0.0.orig.tar.gz missing: opts=pgpsigurlmangle=s/$/.asc/ 
@@@url@@@([\.\d]+)/(.+)/(.+)/ @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate
|./test_uscan_ftp: 293: cd: can't cd to /tmp/tmp.XEqC4nYhhq/foo-0.0
|ASSERT:pristine tarball is not extracted
|tail: cannot open 'debian/changelog' for reading: No such file or directory
|dpkg-parsechangelog: error: tail of debian/changelog subprocess returned exit 
status 1
|ASSERT:uscan: Version should be 0.0-1 but  expected:<> but was:<0.0-1>

Could you please have a look at it?


Seems to be an unreliable failure, as on mipsel it passed at the 3rd
try.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature