Bug#916606: Possible cause

[Stephen Kitt]

On Sat, Jan 05, 2019 at 03:32:02AM -0500, Full Name wrote:
> A similar problem occurs in DOSBox.  I'm not sure if this is a bug in xorg or 
> SDL.
> 
> What is happening is that when you unpause, lbreakout2 tries to fence the 
> mouse in its window,
> but instead the window immediately loses focus causing lbreakout2 to pause 
> again.  I'm not sure
> why the mouse lock works the first time, but once it releases it cannot be 
> regained.

Yup, this does seem to be the case. This issue was fixed in DOSBox
with the patch available at
https://www.dosbox.com/downloads/74-2-events.diff (also included in
the current DOSBox package in unstable and testing).

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#914357: Cannot reproduce this problem

[Yanhao Mo]

Finally, the reason of build failure was founded. The kallsyms testcase
use operating system parameters `kernel.kptr_restrict` and
`kernel.perf_event_paranoid` to determine if a ordinary user could read
the address info from /proc/kallsyms file. Obviously that's not true,
because both machines of you and I have the same value for the two
parameters, but on your machine a ordinary user can get address info
from /proc/kallsyms which is not the case for mine.

`$ head /proc/kallsyms` from your mainche:

>  A irq_stack_union
>  A __per_cpu_start
>  A __per_cpu_user_mapped_start
> 4000 A vector_irq
> 4800 A unsafe_stack_register_backup
> 4840 A cpu_debug_store
> 48c0 A cpu_tss
> 7000 A exception_stacks
> c000 A gdt_page
> d000 A espfix_waddr

`$ head /proc/kallsyms` from my mainche:

>  A irq_stack_union
>  A __per_cpu_start
>  A cpu_debug_store
>  A cpu_tss_rw
>  A gdt_page
>  A exception_stacks
>  A entry_stack_storage
>  A espfix_waddr
>  A espfix_stack
>  A cpu_llc_id

I need some extra time to find a new way to fix this problem. But for
now I'd like to disable the kallsyms testcase temporarily and close
this bug for successfully testing transition.

Thanks again for letting me use your machine to test this.

Bug#913567: fixed in python-numpy 1:1.16.0~rc2-1)

[Jörg-Volker Peetz]

Package: python-numpy
Version: 1:1.16.0~rc2-1

Hi Sandro,

thanks for taking care of this issue.
I've upgraded to the new version and see the following

$ ldd
/usr/lib/python2.7/dist-packages/numpy/linalg/lapack_lite.x86_64-linux-gnu.so |
grep blas
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 
(0x7f8f59855000)
libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 
(0x7f8f57494000)

Thus, python-numpy still won't work without package libopenblas-base.
Maybe, there is a bug in the building system of numpy.

I'm experiencing the same problem when trying to build a local version of
sagemath which builds its own numpy.

Any ideas?

Regards,
Jörg.

Bug#918533: gnucap-python: please make the build reproducible

[Chris Lamb]

Source: gnucap-python
Version: 0.0.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because it uses:

  $ echo "\n"

… or similar which is not the same across dash/bash etc, resulting in
a diff of:

│ │ │ │ ├── NEWS
│ │ │ │ │ @@ -1,3 +1 @@
│ │ │ │ │ -0.0.0
│ │ │ │ │ -=
│ │ │ │ │ -* initial release
│ │ │ │ │ +0.0.0\n=\n* initial release

A patch is attached, although given that this NEWS entry is pretty
meaningless, it is unclear whether the best course of action would
be to simply remove its creation…

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-01-07 08:17:54.232102376 +0100
--- b/debian/rules  2019-01-07 09:16:36.921058809 +0100
@@ -52,7 +52,7 @@
cd debian/tmp/usr/lib/*/gnucap[0-9]; ln -sf c_python${PYDEF}.so 
c_python.so
mv debian/tmp${PYDEF}/usr/share debian/tmp/usr
 
-   echo "0.0.0\n=\n* initial release" > 
debian/tmp/usr/share/doc/gnucap-python/NEWS
+   printf "0.0.0\n=\n* initial release\n" > 
debian/tmp/usr/share/doc/gnucap-python/NEWS
 
 override_dh_auto_configure: $(PYVERS:%=ac-python%)
 override_dh_auto_build: $(PYVERS:%=ab-python%)

Bug#918534: vit: please make the build reproducible

[Chris Lamb]

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

Hi,

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

This is actually a regression from vit 1.2-4 — unfortunately whilst
the changelog mentions that the patches were merged upstream they
appeared to miss the --utc argument resulting in:

│ │ │ │ -# 1.3.beta1 built after Mon Aug  6 03:08:23 -12 2018
│ │ │ │ +# 1.3.beta1 built after Tue Aug  7 05:08:23 +14 2018

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/ReproducibleBuild.diff 1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/ReproducibleBuild.diff 2019-01-07 09:21:39.536578880 
+0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2019-01-07
+
+--- vit-1.3~beta1.orig/Makefile.in
 vit-1.3~beta1/Makefile.in
+@@ -18,7 +18,7 @@ build:
+   fi && \
+   cat vit.pl | grep -v ^require \
+ | sed "s:%prefix%:$(PREFIX):" \
+-| sed "s/%BUILD%/$(VERSION) built after `date -r CHANGES`/" \
++| sed "s/%BUILD%/$(VERSION) built after `date -u -r CHANGES`/" \
+ | sed "s/%VERSION%/$(VERSION)$${GITHASH}/" \
+ | sed "s:%TASK%:$(TASK):" \
+ | sed "s:%CLEAR%:$(CLEAR):" \
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2019-01-07 09:21:38.204622716 +0100
@@ -0,0 +1 @@
+ReproducibleBuild.diff

Bug#477498: Fwd: Shutdown & Reboot scripts try umount CIFS but CIFSD is killed first

[Peter Nowee]

On 12/30/18, Dmitry Bogatov  wrote:
> Dear submitter, does bug reproduces on current system. If yes,
> do you have NetworkManager installed?

Sorry, I stopped using CIFS-mounts since then, so I can't easily test
if the bug still exists right now.

Hopefully somebody else can comment on this.

Best regards,
Peter Nowee

Bug#918532: Acknowledgement (emacs: Daemon mode does not apply font preferences)

[ಚಿರಾಗ್ ನಟರಾಜ್]

Never mind, fixed it using code from 
https://stackoverflow.com/questions/33074370/how-can-i-use-a-different-ttf-fonts-for-certain-utf-8-characters-in-emacs.
 Basically, the idea is to hook into the 'after-make-frame-functions hook. I 
found that I also had to manually call the function so that just directly 
running emacs would still apply the font preferences.

Seems like this is a fairly long-standing issue that people have just worked 
around for a while...

Anyway, feel free to close this.

Sincerely,

Chiraag
-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Graduate Student at Brown University
Email: chiraag.nata...@gmail.com
Phone: 610-350-6329
Website: http://chiraag.nataraj.us

On 07/01/19 07:57, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 918532: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918532.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Rob Browning 
> 
> If you wish to submit further information on this problem, please
> send it to 918...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 918532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918532
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems


signature.asc
Description: PGP signature

Bug#917726: globus-gass-copy: FTBFS: tests failed

[Lucas Nussbaum]

Hi,

On 07/01/19 at 08:28 +0100, Mattias Ellert wrote:
> Hi!
> 
> The globus-gass-copy package and dependent packaged have now been
> tagged for autoremoval due to this RC bug. So I need to resolve this
> with some urgency.
> 
> Since I did not receive any reply to my previous comment I need to
> resolve this without the additional feedback I requested.
> 
> I will close this as "not a bug" since I believe the failure to be due
> to a misconfiguration of the rebuild test build server, and not a real
> bug (see the above mentioned comment for details).
> 
> If this is not satisfactory, please feel welcome to reopen the bug and
> provide additional information about why you believe the bug report is
> valid.
> 
>   Mattias

Well, I'm not sure about this bug.

It seems that it fails to build with '!' in /etc/shadow, with '*' in
/etc/shadow, and even with a password in /etc/shadow. I don't know if
sbuild is doing something strange, but it doesn't look like it.

Also, this is (AFAIK) the only package failing because of this.

Lucas


signature.asc
Description: PGP signature

Bug#918535: smartmontools: New upstream release (7.0)

[James Page]

Package: smartmontools
Version: 6.6-1
Severity: wishlist

Dear Maintainer,

smartmontools upstream just did a 7.0 release that includes JSON
output support which is needed for the disk health metrics scraping
and failure prediction support currently in development for Ceph.

It would be great if this package could be updated to this new
release to support this work.

Cheers

James


-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages smartmontools depends on:
ii  debianutils  4.8.6
ii  init-system-helpers  1.54
ii  libc62.28-0ubuntu1
ii  libcap-ng0   0.7.9-1
ii  libgcc1  1:8.2.0-7ubuntu1
ii  libselinux1  2.8-1build1
ii  libstdc++6   8.2.0-7ubuntu1
ii  lsb-base 9.20170808ubuntu1

Versions of packages smartmontools recommends:
pn  mailx | mailutils  

Versions of packages smartmontools suggests:
pn  gsmartcontrol   
pn  smart-notifier  

Bug#918534: vit: please make the build reproducible

[Chris Lamb]

forwarded 918534 https://github.com/scottkosty/vit/pull/161
thanks

I've gone ahead and forwarded this upstream here:

  https://github.com/scottkosty/vit/pull/161


Regards,

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

Bug#878340: libmariadbclient-dev-compat: mysqlclient.pc is not visible to pkg-config

[Otto Kekäläinen]

Hello!

su 6. tammik. 2019 klo 23.52 Nikolay Dimitrov
(nikolay.dimit...@retrohub.org) kirjoitti:
>
> Hi Otto, Helmut,
>
> Thanks for fixing the bug and sharing the progress with me.
>
> To be honest, I could have sent a patch for this issue even back then,
> but I'm not familiar with Debian's contributors' policy and procedures,
> and decided to not experiment with it (if it takes months for
> experienced Debian developers to push patches through the system, there
> aren't any high hopes for external contributors like me).

It is actually very easy nowadays to contribute. Just fork the
packaging repo, do your changes, test and submit a merge request. Once
the change is approved, it will be part of the next upload, usually
within a few weeks.

If you do some improvements to the mariadb-10.3 packaging this week, I
can promise it will be in Debian unstable next week.

Bug#776450: Xen PVH support for grub-xen in Buster

[Colin Watson]

On Mon, Jan 07, 2019 at 01:58:19AM +0100, Hans van Kranenburg wrote:
> On 1/6/19 11:21 AM, Colin Watson wrote:
> > Given what you've described, I see no intrinsic reason we couldn't do
> > the same thing with PVH, but I'm pretty sure that GRUB's Xen multiboot
> > support doesn't yet support using the PVH entry point, so I don't think
> > it will work with the code as it stands.  It probably makes more sense
> > to package what we have today (which I can do) and then work on the
> > two-stage system as a further refinement.
> 
> Ok great. Since I'm not using (and probably not going to use) the
> multi-stage multiboot things, this is harder for me to help with.

With any luck I should be able to work that bit out myself, since I
think stable's Xen has backported PVH support.

> Now, while trying to start doing the same for PVH, I just started by
> copying the build output of grub master branch into the source package,
> #yolo, and then I have a grub-mkstandalone that can do -O i386-xen_pvh...
> 
> https://salsa.debian.org/knorrie-guest/pvhgrub2/blob/master/Makefile
> 
> So my question is... Will the new grub-mkstandalone that I drag in as
> build dependency be able to do -O x86_64-xen as well as -O i386-xen_pvh?

Yes, that should work.  The tools are intentionally multi-target; in
order to support a given target they just need to have its modules etc.
available.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#918536: /etc/reportbug.conf: bad example for mua

[Jakub Wilk]

Package: reportbug
Version: 7.5.1

/etc/reportbug.conf contains the following example:

  # mua 'mutt -H'

But this doesn't actually work. If you uncomment it, you get:

  Specified mail user agent is not supported; exiting.

-- System Information:
Architecture: i386

Versions of packages reportbug depends on:
ii  python33.7.1-3
ii  apt1.8.0~alpha3
ii  python3-reportbug  7.5.1
ii  sensible-utils 0.0.12

--
Jakub Wilk

Bug#918537: reportbug: *.pyc file in tarball

[Jakub Wilk]

Source: reportbug
Version: 7.5.1

The reportbug tarball includes a bunch of *.pyc files:

  $ tar --wildcards -tf reportbug_7.5.1.tar.xz '*.pyc'
  reportbug-7.5.1/reportbug/__init__.pyc
  reportbug-7.5.1/reportbug/__pycache__/__init__.cpython-35.pyc
  reportbug-7.5.1/reportbug/__pycache__/__init__.cpython-36.pyc
  ...

I don't think they were supposed to be included. Please remove them from 
the future releases.


--
Jakub Wilk

Bug#834625: lighttpd: Add autopkgtests test to check mitigation against HTTPoxy

[Helmut Grohne]

On Wed, Aug 17, 2016 at 06:08:52PM +0200, Santiago Ruano Rincón wrote:
> Please, find attached the patches to include a DEP-8 test to check if
> lighttpd correctly avoids passing http proxy variables to CGIs.

Thank you for your contribution to the lighttpd package. Raising the
absence of tests was very useful and I now added a few simpler ones.

Unfortunately, I think that it is not reasonable to include your patch
as is.

> +Tests: do-not-emit-http-proxy-to-cgi

This is a very specific test. However, we still lack a lot of simpler
tests. When this test breaks, one has a hard time figuring out what the
cause is.

At the time of your bug filing, lighttpd had no autopkgtests at all.
Now, we have some very basic tests (thanks to your bug), but not even a
single cgi test.

Before adding such a specific test, I think it would be prudent to
include a basic cgi test.

> +Depends: @, python2.7, python-requests, curl, netcat
> +Restrictions: needs-root, allow-stderr

This test can be reasonably implemented without needs-root. Requiring
needs-root means that you cannot run it under schroot unfortunately.

So I don't think your patch is usable as is. Would you be interested in
addressing the points raised?

Helmut

Bug#918538: Please fully switch to python3

[Laurent Bigonville]

Source: dogtag-pki
Version: 10.6.8-2
Severity: normal

Hi,

Are there any reasons why part of the generated packages are still
using python2?

Looking at the .spec file you can apparently use the following to make
everything use python3 (no tested):

-DWITH_PYTHON3:BOOL=ON
-DWITH_PYTHON2:BOOL=OFF
-DWITH_PYTHON3_DEFAULT:BOOL=ON

Kind regards,

Laurent Bigonville

-- 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)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#870448: hw-detect - stop using modprobe -l

[Vincent McIntyre]

On Wed, Aug 02, 2017 at 07:58:05PM +0100, Ben Hutchings wrote:
> On Wed, 2017-08-02 at 12:26 +1000, Vincent McIntyre wrote:
> > Package: hw-detect
> > Version: 1.124
> > Severity: normal
> > Tags: patch
> > 
> > I keep seeing this in installer logs, back to jessie.
> > 
> > Aug  2 01:52:11 main-menu[193]: (process:224): modprobe: invalid option -- 
> > 'l'
> > 
> > 
> > I rated this normal rather than minor because the way it is working
> > now the is_available() function always returns 1 (failure)
> > 
> > My suggestion is to use modinfo instead.
> > This will return multiline output inside the quotes but
> > a couple of tests suggests that is ok.
> > It does fail with some modules (nvidia), not sure if we care.
> >
> > diff --git a/hw-detect.sh b/hw-detect.sh
> > index 7977814..d8196c1 100755
> > --- a/hw-detect.sh
> > +++ b/hw-detect.sh
> > @@ -43,7 +43,7 @@ is_not_loaded() {
> >  }
> >  
> >  is_available () {
> > -   [ "$(modprobe -l $1)" ] || return 1
> > +   [ "$(modinfo $1)" ] || return 1
> >  }
> 
> But this still prints error messages for missing modules.  I think the
> function should be implemented as:
> 
> is_available () {
>   modprobe -qn "$1"
> }
> 

That seems much better, can someone please apply Ben's version?
Thanks for tickling this Holger.

Cheers
Vince

Bug#918388: fixed in nodejs 10.15.0~dfsg-8

[Emilio Pozuelo Monfort]

On 06/01/2019 13:11, Pirate Praveen wrote:
> [asking -release]
> 
> On 1/6/19 5:31 PM, Pirate Praveen wrote:
>> Control: reopen -1
>>
>> On Sun, 06 Jan 2019 10:34:48 + =?utf-8?b?SsOpcsOpbXkgTGFs?=
>>  wrote:
>>>* Suggests npm - because nodejs must not be blocked by it.
>>>  Closes: #918388.
>>
>> I don't think this reasoning is correct. gitlab recommends gitaly with
>> the expectation that gitaly andd gitlab could be on different machines.
>> ruby-rails currently recommends packages not even in the archive
>> currently and it is not marked for auto removals for that.
>>
>> I'd be happy to be proven wrong.
>>
> 
> Hi Release team,
> 
> Can you confirm if an rc bug in a packaged listed in recommends will
> block testing migration of a package? (in this specific case, the fear
> is that rc bug in npm will block nodejs testing migration).

Recommends are not taken into account for testing migration.

Emilio

Bug#918539: mini-transition: libnfs

[Bálint Réczey]

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

Dear Release Team,

I would like to update libnfs in unstable to the 3.0 version.

It is built for all release architectures in experimental  except for
mips* but it is unlikely to have arch-specific issues there.

The mini transition would involve libnfs and its reverse
dependencies:
 gvfs mpd kodi qemu vlc

They build with the new libnfs version. (Mpd did FTBFS for me in tests
for a seemingly unrelated reason)

In terms of 'ben' lingo, the transition has the following parameters:

Affected: .depends ~ /\b(libnfs\-utils|libnfs12|libnfs11)\b/
Good: .depends ~ /\b(libnfs\-utils|libnfs12)\b/ | .recommends ~ /\b(libnfs12)\b/
Bad: .depends ~ /\b(libnfs11)\b/ | .recommends ~ /\b(libnfs11)\b/

Cheers,
Balint

Bug#918540: RM: ruby-sinatra-simple-navigation -- ROM; unmaintained, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

Its uploader removed themselves 2 years ago (ruby team maintained)
https://salsa.debian.org/ruby-team/ruby-sinatra-simple-navigation/commit/f9ee2965c4725674d2e9d4d38fad1c8d5a9f2408

It's autopkgtest is breaking and delaying rails 5 migration. There are
no reverse (build) dependencies.



signature.asc
Description: OpenPGP digital signature

Bug#911822: dpkg: cycle found while processing triggeres of libc-bin package

[Giacomo]

Yes, it is working.
I do not how, I did not do anything, I just upgraded the system day by day.

On Sat, Dec 29, 2018 at 1:27 PM Aurelien Jarno  wrote:

> control: tag -1 + moreinfo
>
> Hi,
>
> On 2018-10-25 23:18, Guillem Jover wrote:
> > Hi!
> >
> > On Thu, 2018-10-25 at 09:52:38 +0200, Giacomo wrote:
> > > Package: libc-bin
> > > Version: 2.27-6
> >
> > > I upgraded from debian stable (strecth) to debian testing, and now
> when I
> > > execute apt-get upgrade I always get this error:
> > > Processing triggers for libc-bin (2.27-6) ...
> > >
> > > dpkg: cycle found while processing triggers:
> > >  chain of packages whose triggers are or may be responsible:
> > >   libc-bin -> man-db
> > >  packages' pending triggers which are or may be unresolvable:
> > >   man-db: /usr/share/man
> > >   libc-bin: ldconfig
> > > dpkg: error processing package man-db (--configure):
> > >  triggers looping, abandoned
> > > Processing triggers for libc-bin (2.27-6) ...
> > > Processing triggers for libc-bin (2.27-6) ...
> > > dpkg: cycle found while processing triggers:
> > >  chain of packages whose triggers are or may be responsible:
> > >   libc-bin -> libc-bin -> libc-bin
> > >  packages' pending triggers which are or may be unresolvable:
> > >   libc-bin: ldconfig
> > > dpkg: error processing package libc-bin (--configure):
> > >  triggers looping, abandoned
> > > Errors were encountered while processing:
> > >  man-db
> > >  libc-bin
> > > E: Sub-process /usr/bin/dpkg returned an error code (1)
> >
> > Could you run «dpkg --audit». And then send that output and a tarball
> > with some of the dpkg database files, generated like this:
> >
> >   $ tar -caf dpkg-911822.tar.xz /var/lib/dpkg/{status,triggers,updates}
> >
> > Take into account this might perhaps contain sensitive information, so
> > you might want to make sure before sending it to the BTS that it does
> > not, the BTS might even reject it if it's too big, or alternatively
> > send it directly to me.
> >
> > Does, running just «dpkg --configure --pending» solve the issue?
>
> Any news on this issue? Without the requested details, it will be
> difficult to debug it as it is not reproducible.
>
> Thanks,
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
>


-- 
Giacomo

Bug#918541: RM: ruby-simple-navigation -- ROM; unmaintained, blocking rails 5 transition

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 918540

Its uploaded removed themselves 2 years ago (ruby team maintained)

https://salsa.debian.org/ruby-team/ruby-simple-navigation/commit/7fda448765e45051e22f846fc2aafe6a96e33cff

Its autopkgtest is currently failing with rails 5 and delaying rails 5
transition.

Its only reverse dependency is ruby-sinatra-simple-navigation which
should be removed as well (#918540).



signature.asc
Description: OpenPGP digital signature

Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7

[Neutron Soutmun]

Package: autopkgtest
Version: 5.7
Followup-For: Bug #916428

The 0001-qemu-close-sockets-after-being-done-with-them.patch solved the
issue for me also.

Cheers,
Neutron Soutmun


signature.asc
Description: PGP signature

Bug#918179: debci: configure error: undefined method `migrate'

[Pirate Praveen]

Control: reassign -1 debci

On Sun, 6 Jan 2019 20:12:58 +0100 Paul Gevers  wrote:
> The same can be seen in the CI logs [1] for debci (and other packages)
> that were triggered for rails/2:5.2.0+dfsg-2 [2]. The issue is caused by
> a new version of rails.

This should be fixed in debci. We are tracking the rails 5 transition here,

https://salsa.debian.org/ruby-team/rails/wikis/Transition-to-Rails-5.2-for-Debian-Buster



signature.asc
Description: OpenPGP digital signature

Bug#918141: [Pkg-samba-maint] Bug#918141: samba-common: samba-tool domain provision fails due to missing ad-schema files

[L . P . H . van Belle]

Hai, 

Can you verify that the packages "samba" is installed.

https://packages.debian.org/search?suite=buster&arch=any&mode=exactfilename&searchon=contents&keywords=Attributes_for_AD_DS__Windows_Server_2008_R2.ldf
 

Package samba contains : 
/usr/share/samba/setup/ad-schema/Attributes_for_AD_DS__Windows_Server_2008_R2.ldf
  


Greetz, 

Louis


> -Oorspronkelijk bericht-
> Van: Pkg-samba-maint 
> [mailto:pkg-samba-maint-bounces+belle=bazuin.nl@alioth-lists.d
> ebian.net] Namens Bowland
> Verzonden: donderdag 3 januari 2019 20:31
> Aan: Debian Bug Tracking System
> Onderwerp: [Pkg-samba-maint] Bug#918141: samba-common: 
> samba-tool domain provision fails due to missing ad-schema files
> 
> Package: samba-common
> Version: 2:4.9.4+dfsg-1
> Severity: normal
> 
> xxx@laptop:/usr/share/samba# samba-tool domain provision
> Realm:  domain.de
> Domain [domain]:  
> Server Role (dc, member, standalone) [dc]:  
> DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) 
> [SAMBA_INTERNAL]:  
> DNS forwarder IP address (write 'none' to disable forwarding) 
> [192.168.188.1]:  
> Administrator password: 
> Retype password: 
> Looking up IPv4 addresses
> Looking up IPv6 addresses
> ERROR(): uncaught exception - 
> [Errno 2] No such file or directory: 
> '/usr/share/samba/setup/ad-schema/Attributes_for_AD_DS__Window
> s_Server_2008_R2.ldf'
>   File 
> "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", 
> line 177, in _run
> return self.run(*args, **kwargs)
>   File 
> "/usr/lib/python2.7/dist-packages/samba/netcmd/domain.py", 
> line 538, in run
> backend_store=backend_store)
>   File 
> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py"
> , line 2218, in provision
> schemadn=names.schemadn, base_schema=base_schema)
>   File "/usr/lib/python2.7/dist-packages/samba/schema.py", 
> line 110, in __init__
> setup_path('ad-schema/%s' % Schema.base_schemas[base_schema][1]))
>   File "/usr/lib/python2.7/dist-packages/samba/ms_schema.py", 
> line 308, in read_ms_schema
> attr_ldif =  __parse_schema_file(attr_file, "attributeSchema")
>   File "/usr/lib/python2.7/dist-packages/samba/ms_schema.py", 
> line 294, in __parse_schema_file
> f = open(filename, "rU")
> 
> 
> -- Package-specific info:
> * /etc/samba/smb.conf present, and attached
> * /var/lib/samba/dhcp.conf present, and attached
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (1001, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 
> (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages samba-common depends on:
> ii  debconf [debconf-2.0]  1.5.69
> ii  dpkg   1.19.2
> ii  ucf3.0038+nmu1
> 
> Versions of packages samba-common recommends:
> ii  samba-common-bin  2:4.9.4+dfsg-1
> 
> samba-common suggests no packages.
> 
> -- debconf information:
>   samba-common/do_debconf: true
>   samba-common/title:
>   samba-common/workgroup: WORKGROUP
> * samba-common/dhcp: false
> ___
> Pkg-samba-maint mailing list
> pkg-samba-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-s
> amba-maint
> 

Bug#918138: qtox: Add AppArmor profile

[Yangfl]

Hi,

Do you have such profile now? I'm preparing the last release for
buster. If so, please submit asap since the freezing is approaching.

Vincas Dargis  于2019年1月6日周日 下午11:07写道：
>
> https://github.com/qTox/qTox/issues/5484

Bug#918542: chromium build depends on libsrtp-dev that is not in buster

[Adrian Bunk]

Source: chromium
Version: 72.0.3626.7-4
Severity: serious
Tags: ftbfs
Control: block 910292 by -1

chromium build depends on libsrtp-dev that is not in buster,
see #910292 for background.

Bug#918543: ring build depends on libsrtp-dev that is not in buster

[Adrian Bunk]

Source: ring
Version: 20180119.1.9e06f94~ds120181001.4.a99aaec~ds6-2
Severity: serious
Tags: ftbfs
Control: block 910292 by -1

ring build depends on libsrtp-dev that is not in buster,
see #910292 for background.

Bug#918544: python-numpy: Breaks on the wrong version of python-astropy

[Mattia Rizzolo]

Package: python-numpy
Version: 1:1.16.0~rc2-1
Severity: important
X-Debbugs-Cc: Ole Streicher 


Dear maintainer, whhile reviewing the situation here, I noticed that
following #918399 you added
Breaks: python-astropy (<< 2.0.9-1)
to the python-numpy package.  However, that's the wrong version, as that
version *is* broken.  In fact, there is not and there won't be a fixed
version of python-astropy, so a versionless Breaks is fine (but ISTR
lintian complains about it, to prevent that you can make up any higher
version or use <= which will be fine as long as no futher upload of
src:python-astropy happen before its removal from the archive).
Please note that the submitter of #918399 did use '<< 2.0.9-1+' in his
request.

-- 
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

Bug#917859: vim FTBFS building for armel,armhf on arm64

[Edmund Grimley Evans]

I'd guess this is a problem with the locale. In my case an unknown
locale adds 8, rather than 10, additional lines, but still:

$ LANG=C ./foo.pl
Global symbol "$foo" requires explicit package name at ./foo.pl line 3.
Execution of ./foo.pl aborted due to compilation errors.
$ LANG=sq ./foo.pl
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_GB:",
LC_ALL = (unset),
LC_COLLATE = "C",
LANG = "sq"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Global symbol "$foo" requires explicit package name at ./foo.pl line 3.
Execution of ./foo.pl aborted due to compilation errors.

Bug#900663: RFA: note -- small program managing notes from commandline

[eamanu15]

Control: retitle -1 ITA: note -- small program managing notes from
commandline
Control: owner -1 emmanuelaria...@gmail.com

Hello Simon!

I would like to adopt this package.

Thanks!
Regards

-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#916891: mirror submission for debian.mirrors.theom.nz

[Peter Palfrader]

On Sun, 06 Jan 2019, Theo Morra wrote:

> The issue I’m facing at the moment while everyone slowly returns to
> work is that the mirror service has 2 mirrors in the cluster that are
> public facing (so far). Both service debian.mirrors.theom.nz
>  but both will also return two
> different traces since they’re not perfectly in sync yet (such are the
> issues when running mirrors within ISPs).

If there are two mirrors that are not identical, always, then you can
submit both mirrors individually.


Also, 203.86.206.98 looks like it's some residential line somewhere.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#918394: proftpd-dfsg FTBFS with MariaDB 10.3

[Hilmar Preuße]

Am 05.01.2019 um 20:10 teilte Adrian Bunk mit:

Hi Adrian,

happy new year!


Source: proftpd-dfsg
Version: 1.3.6-3
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/proftpd-dfsg.html

"mysql_config --include" now prints two include dirs, AFAICT this is the 
root cause. I have a patch at hand, but I need to check if it breaks 
build w/ old libmariadb* packages.


Hilmar
--
#206401 http://counter.li.org

Bug#918384: dgit: typo suggestions in man pages

[Ian Jackson]

Paul Hardy writes ("Bug#918384: dgit: typo suggestions in man pages"):
> I trust that after you sent this you saw an email I sent beforehand
> mentioning that I would be unavailable today.  I hope you did not
> delay your dgit upload on my account.  I was not aware of the poor
> timing.

No problem.

> Did any of the man pages change in your version 8.3 upload from
> version 8.1?  If not, that will simplify my creating the modified
> patch.

Some have changed, but I think your rebase / cherry-pick should go
forward without difficulty.

You are using git for this, right ?

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#904518: Add support for SPDX-License-Identifier

[Dominique Dumont]

On Wed, 25 Jul 2018 02:30:03 +0200 Michael Biebl  wrote:
> it would be great if licensecheck would support SPDX-License-Identifier
> headers.

This would indeed be helpful. 

libtommath is now using SPDX-License-Identifier [1] 
and licensecheck extracts no useful information.

All the best

Dod

[1] 
https://github.com/libtom/libtommath/commit/18355de6259488dea58a2d608c9aa2fa1f3cbd58

Bug#911988: txtorcon: reintroduce fixed python2 package for rdepends

[Iain Learmonth]

tags 911988 + wontfix
kthxbye

Hi,

There are only two packages that depended on the python2 version, one of
which I have removed from the archive (ooniprobe).

The remaining package, foolscap, should be ported to Python 3.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature

Bug#918545: qtdeclarative-opensource-src: FTBFS on x32: mis-detected as having amd64 JIT

[Thorsten Glaser]

Source: qtdeclarative-opensource-src
Version: 5.11.3-2
Severity: important

See also: 
https://buildd.debian.org/status/fetch.php?pkg=qtdeclarative-opensource-src&arch=x32&ver=5.11.3-2&stamp=1545865790&raw=0

src/qml/jsruntime/qv4global_p.h line 94 always triggers,
because x32 is detected as amd64 (Q_PROCESSOR_X86 and
Q_PROCESSOR_X86_64 are defined and QT_POINTER_SIZE is 8)
by qtbase5-dev (src/corelib/global/qprocessordetection.h).

Changing qprocessordetection to set QT_POINTER_SIZE to 4
for x32 won’t help because src/qml/jsruntime/qv4global_p.h
line 91 would then misdetect it as i386. (It would still
be more correct, but I don’t know if that would break
things that work, for now.)

I fear the best we can do is to add something around line
116 (blacklist):

#if defined(__x86_64__) && defined(__ILP32__)
// explicitly disable on x32 (amd64ilp32)
#undef V4_ENABLE_JIT
#endif

Bug#917358: closed by Gianfranco Costamagna (Re: Bug#917358: borgbackup: Borg mount fails as fuse is not listed as dependancy in stable)

[Gianfranco Costamagna]

 Hello Andrew,the bug is "fixed" in testing, so closing it is the appropriate 
action.
Buster is getting released soon, I don't plan to do a stretch p-u, feel free to 
request one 
with release team, the debdiff is trivial (adding fuse runtime dependency to 
borgbackup debian/control file)
G.
Il sabato 5 gennaio 2019, 16:15:16 CET, Andrew Hunter 
 ha scritto:  
 
 Hi Gianfranco,
All of those versions of the package have a newer version of borg in addition 
to listing the fuse dependency. 

I don't think this bug report should be closed as functionality in the current 
stable version is broken due to a missing dependency in the packaging.  This 
strikes me as a suitable candidate for a proposed-update to stable. 

Sincerely,Andrew

On Sat, Jan 5, 2019 at 6:06 AM Debian Bug Tracking System 
 wrote:

This is an automatic notification regarding your Bug report
which was filed against the borgbackup package:

#917358: borgbackup: Borg mount fails as fuse is not listed as dependancy in 
stable

It has been closed by Gianfranco Costamagna .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Gianfranco Costamagna 
 by
replying to this email.


-- 
917358: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917358
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



-- Forwarded message --
From: Gianfranco Costamagna 
To: Debian Bug Tracking System , Andrew Hunter 
, "917358-d...@bugs.debian.org" 
<917358-d...@bugs.debian.org>
Cc: 
Bcc: 
Date: Sat, 5 Jan 2019 11:02:50 + (UTC)
Subject: Re: Bug#917358: borgbackup: Borg mount fails as fuse is not listed as 
dependancy in stable
 Hello, can you please confirm the bug is fixed in stretch-backports, sid and 
testing?
thanks!
G.

Il mercoledì 26 dicembre 2018, 17:21:14 CET, Andrew Hunter 
 ha scritto:  
 
 Package: borgbackup
Version: 1.0.9-1
Severity: normal

Dear Maintainer,

Please add fuse as a dependancy to the 1.0.9 version of borg in stable. Borg 
mount is a built in command that requires the fuse package. Fuse is listed a 
dependancy in both testing and stretch-backports.

  * What led up to the situation?

    $ borg mount  failed


  * What exactly did you do (or not do) that was effective (or
    ineffective)?

# apt install fuse

  * What was the outcome of this action?

$ borg mount suceeds

  * What outcome did you expect instead?



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

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

Versions of packages borgbackup depends on:
ii  libacl1                2.2.52-3+b1
ii  libc6                  2.24-11+deb9u3
ii  liblz4-1              0.0~r131-2+b1
ii  libssl1.1              1.1.0j-1~deb9u1
ii  python3                3.5.3-1
ii  python3-llfuse        1.2+dfsg-1
ii  python3-msgpack        0.4.8-1
ii  python3-pkg-resources  33.1.1-1

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information

  


-- Forwarded message --
From: Andrew Hunter 
To: Debian Bug Tracking System 
Cc: 
Bcc: 
Date: Wed, 26 Dec 2018 11:17:14 -0500
Subject: borgbackup: Borg mount fails as fuse is not listed as dependancy in 
stable
Package: borgbackup
Version: 1.0.9-1
Severity: normal

Dear Maintainer,

Please add fuse as a dependancy to the 1.0.9 version of borg in stable. Borg 
mount is a built in command that requires the fuse package. Fuse is listed a 
dependancy in both testing and stretch-backports.

   * What led up to the situation?

    $ borg mount  failed


   * What exactly did you do (or not do) that was effective (or
     ineffective)?

# apt install fuse

   * What was the outcome of this action?

$ borg mount suceeds

   * What outcome did you expect instead?



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

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

Versions of packages borgbackup depends on:
ii  libacl1                2.2.52-3+b1
ii  libc6                  2.24-11+deb9u3
ii  liblz4-1               0.0~r131-2+b1
ii  libssl1.1              1.1.0j-1~deb9u1
ii  python3                3.5.3-1
ii  python3-llfuse         1.2+dfsg-1
ii  python3-msgpack        0.4.8-1
ii  python3-pkg-resources  33.1.1-1

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- 

Bug#918546: RM: python-applicationinsights -- ROM; redundant dependency

[Iain R. Learmonth]

Package: ftp.debian.org
Severity: normal

Hi,

Originally packaged as part of the Azure tools but as these tools are
not maintained in Debian this is a redundant dependency.

Thanks,
Iain.

Bug#918547: RM: klein -- ROM; redundant dependency

[Iain R. Learmonth]

Package: ftp.debian.org
Severity: normal

Hi,

I packaged this originally to support the packaging of ooniprobe, which
has since been removed (and no longer uses klein in the upstream
anyway).

As such, keeping up with packaging this is not a useful use of time
unless something else were to come along depending on it. It is a
library not an end-user application and so without an application it is
redundant.

Thanks,
Iain.

Bug#918549: ITP: ruby-csv: CSV Reading and Writing

[Lucas Kanashiro]

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

* Package name    : ruby-csv
  Version : 3.0.2
  Upstream Author : Kouhei Sutou 
* URL : https://github.com/ruby/csv
* License : BSD-2-clause
  Programming Lang: Ruby
  Description : CSV Reading and Writing

The CSV library provides a complete interface to CSV files and data. It offers
tools to enable you to read and write to and from Strings or IO objects, as
needed.

This package will be maintained under the umbrella of the Debian Ruby team.

-- 
Lucas Kanashiro

Bug#918548: About possibility to translate AppArmor tunables

[Ian Jackson]

Package: apparmor
Version: 2.13.2-3
Severity: serious

Vincas, thanks for reporting this bug on the debian-i18n list.
I think it needs a much higher profile.

Vincas Dargis writes ("About possibility to translate AppArmor tunables"):
> Let's look at one tunable file example. Currently, Debian and
> upstream version of `/etc/apparmor.d/tunables/xdg-user-dirs` (from
> apparmor package) have these contents:
> 
> ```
> @{XDG_DESKTOP_DIR}="Desktop"
...
> The problem is that on my machine, "Desktop" is actually "Darbastalis",

I think you mean "in your account" ?  I mean, if you had several users
who used different languages, wouldn't their "Desktop" directory be
called different things ?

> ```
> @{XDG_DESKTOP_DIR}+="Darbastalis" #lt
> @{XDG_DESKTOP_DIR}+="Darbvirsma" #lv
> @{XDG_DOWNLOAD_DIR}+="Atsisiuntimai" #lt
> @{XDG_DOWNLOAD_DIR}+="Lejupielādes" #lv
> ...
> ```

These are interesting ideas.  I don't know enough to say if they would
work.

> Though I am not sure how that could be achieved, hence I ask this
> list for guidance.

I think this requires some technical input from the AppArmor folks.
I see you CC'd the uploader already but I think this is a bug and
should be tracked in the Debian BTS.


I have set the bug to `serious' because of this impact as described by
Vincas:

> if AppArmor profile for application "Foo" defines rule
> `@{XDG_DESKTOP_DIR}/** r,` to allow reading from desktop, it will
> not work for my localized desktop directory name.

That is phrased hypothetically but I imagine it is common.  That kind
of thing is after all what these rules are there fore.

To the AppArmor maintainers:

I have filed this as `serious' not to try to force you to fix this,
but because this bug seems like it will cause AppArmor to work badly
for many people and I felt you would want me to be sure you noticed.
So please adjust the severity as you like.

I hope everyone finds my intervention helpful.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#918525: r-base-core: library lapack.so shouldn't be linked to libopenblas.so.0

[Sébastien Villemot]

Dear Dirk and Jörg-Volker,

On Mon, 7 Jan 2019 08:54:22 +0100 Jörg-Volker Peetz  wrote:

> the problem I see, shows when inspecting /usr/lib/R/modules/lapack.so with
> 
> $ ldd /usr/lib/R/modules/lapack.so | grep blas
>   libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 
>(0x7f58c61b5000)
>   libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 
>(0x7f58c2dbb000)
> 
> Thus, lapack.so of package r-base-core is linked to libopenblas.so.0
> which means that r-base-core won't work without package libopenblas-base.
> And that is not intended AFAIU. 

As explained in <1546860281.3311.22.ca...@debian.org>, I think there is
no bug.

ldd lists libopenblas.so.0 as a dependency, but it is not actually
needed. I guess it's only listed because it's a *indirect* dependency
through libblas.so.3, when openblas is selected as the BLAS
alternative.

As a matter of fact, R runs fine without libopenblas-base installed.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


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

Bug#918550: ionit FTBFS with pylint 2.2.2-1

[Adrian Bunk]

Source: ionit
Version: 0.2-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ionit.html

...
Test: Run pylint on Python source code ... Running following command:
/usr/bin/python3.7 -m pylint --rcfile=/build/1st/ionit-0.2/tests/pylint.conf -- 
/build/1st/ionit-0.2/ionit tests ionit_plugin.py /build/1st/ionit-0.2/setup.py
FAIL

==
FAIL: test_pylint (tests.test_pylint.PylintTestCase)
Test: Run pylint on Python source code
--
Traceback (most recent call last):
  File "/build/1st/ionit-0.2/tests/test_pylint.py", line 68, in test_pylint
self.fail("\n".join(msgs))
AssertionError: pylint found issues:
* Module ionit
/build/1st/ionit-0.2/ionit.py:37:4: W0107: Unnecessary pass statement 
(unnecessary-pass)

--
Ran 26 tests in 12.723s

FAILED (failures=1)
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/build/1st/ionit-0.2/.pybuild/cpython3_3.7/build; python3.7 -m unittest 
discover -v -s /build/1st/ionit-0.2
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
make: *** [debian/rules:6: build] Error 25

Bug#918551: ebtables-nft does not know -t broute

[Wolfgang Walter]

Package: iptables
Version: 1.8.2-3
Severity: important

After upgrading the ebtables packet our routers broke. Reason is that the 
ebtables command now defaults to ebtables-nft which seems not to support the 
table broute.

Therefor the following command fails:

ebtables -t broute -A BROUTING --protocol 802_1Q -j DROP

Probably the default should remain the ebtables command provided by the 
ebtables packet until the ebtables-nft is fully compatible.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Bug#918553: libparse-debianchangelog-perl: [INTL:de] updated German po file translation

[Helge Kreutzmann]

Package: libparse-debianchangelog-perl
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for 
libparse-debianchangelog-perl
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Copyright (C) 2005 Frank Lichtenheld
# This file is distributed under the same license as the Parse::DebianChangelog 
package.
# Hendrik Knackstedt , 2013.
#
msgid ""
msgstr ""
"Project-Id-Version: libparse-debianchangelog-perl\n"
"Report-Msgid-Bugs-To: fr...@lichtenheld.de\n"
"POT-Creation-Date: 2005-10-13 02:10+0200\n"
"PO-Revision-Date: 2013-06-01 20:36+0200\n"
"Last-Translator: Hendrik Knackstedt \n"
"Language-Team: Deutsch \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n!=1);\n"

#: ../bin/parsechangelog:146
#, perl-format
msgid "changelog format %s not supported"
msgstr "Format %s für das Changelog wird nicht unterstützt."

#: ../bin/parsechangelog:151
msgid "ignored option -L"
msgstr "Option -L wurde ignoriert."

#: ../bin/parsechangelog:159
#, perl-format
msgid "output format %s not supported"
msgstr "Das Ausgabeformat %s wird nicht unterstützt."

#: ../bin/parsechangelog:168
msgid "Copyright (C) 2005 by Frank Lichtenheld\n"
msgstr "Copyright © 2005 von Frank Lichtenheld\n"

#: ../bin/parsechangelog:169
msgid ""
"This is free software; see the GNU General Public Licence version 2 or later "
"for copying conditions. There is NO warranty."
msgstr ""
"Dieses Programm ist freie Software. Sie können es unter den Bedingungen der "
"GNU General Public License, wie von der Free Software Foundation "
"veröffentlicht, weitergeben und/oder modifizieren, entweder gemäß Version 2 "
"der Lizenz oder (nach Ihrer Option) jeder späteren Version. Es gibt KEINE "
"Garantie."

#: ../bin/parsechangelog:200
msgid "too many arguments"
msgstr "Zu viele Argumente"

#: ../bin/parsechangelog:204
#, perl-format
msgid "more than one file specified (%s and %s)"
msgstr "Mehr als eine Datei angegeben (%s und %s)"

#: ../bin/parsechangelog:216 ../bin/parsechangelog:220
#, perl-format
msgid "fatal error occured while parsing %s"
msgstr "Fataler Fehler beim Auswerten von %s"

#: ../lib/Parse/DebianChangelog.pm:219
#, perl-format
msgid ""
"WARN: %s(l%s): %s\n"
"LINE: %s\n"
msgstr ""
"WARNUNG: %s(l%s): %s\n"
"ZEILE: %s\n"

#: ../lib/Parse/DebianChangelog.pm:221
#, perl-format
msgid "WARN: %s(l%s): %s\n"
msgstr "WARNUNG: %s(l%s): %s\n"

#: ../lib/Parse/DebianChangelog.pm:232
#, perl-format
msgid "FATAL: %s"
msgstr "FATALER FEHLER: %s"

#: ../lib/Parse/DebianChangelog.pm:279
#, perl-format
msgid "can't open file %s: %s"
msgstr "Datei %s kann nicht geöffnet werden: %s"

#: ../lib/Parse/DebianChangelog.pm:284
#, perl-format
msgid "can't lock file %s: %s"
msgstr "Datei %s kann nicht gesperrt werden: %s"

#: ../lib/Parse/DebianChangelog.pm:291
#, perl-format
msgid "can't load IO::String: %s"
msgstr "IO::String kann nicht geladen werden: %s"

#: ../lib/Parse/DebianChangelog.pm:298
msgid "no changelog file specified"
msgstr "Keine Changelog-Datei angegeben"

#: ../lib/Parse/DebianChangelog.pm:319
#, perl-format
msgid "found start of entry where expected %s"
msgstr "Beginn eines Eintrags gefunden, wo %s erwartet wurde"

#: ../lib/Parse/DebianChangelog.pm:343
#, perl-format
msgid "bad key-value after `;': `%s'"
msgstr "Ungültiger Schlüsselwert nach »;«: %s"

#: ../lib/Parse/DebianChangelog.pm:347
#, perl-format
msgid "repeated key-value %s"
msgstr "Wiederholter Schlüsselwert %s"

#: ../lib/Parse/DebianChangelog.pm:351
msgid "badly formatted urgency value"
msgstr "Falsch formatierter »Urgency«-Wert"

#: ../lib/Parse/DebianChangelog.pm:362
#, perl-format
msgid "unknown key-value key %s - copying to XS-%s"
msgstr "Unbekannter Schlüssel %s – wird nach XS-%s kopiert"

#: ../lib/Parse/DebianChangelog.pm:393
msgid "badly formatted heading line"
msgstr "Falsch formatierte Kopfzeile"

#: ../lib/Parse/DebianChangelog.pm:397
#, perl-format
msgid "found trailer where expected %s"
msgstr "Nachspann gefunden, aber %s erwartet"

#: ../lib/Parse/DebianChangelog.pm:401 ../lib/Parse/DebianChangelog.pm:416
msgid "badly formatted trailer line"
msgstr "Ungültig formatierte Zeile im Nachspann"

#: ../lib/Parse/DebianChangelog.pm:410
#, perl-format
msgid "couldn't parse date %s"
msgstr "Datum %s konnte nicht ausgewertet werden"

#: ../lib/Parse/DebianChangelog.pm:425 ../lib/Parse/DebianChangelog.pm:440
#, perl-format
msgid "found change data where expected %s"
msgstr "Änderungsdaten statt des erwarteten %s gefunden"

#: ../lib/Parse/DebianChangelog.pm:458
#, perl-format
msgid "found blank line where expected %s"
msgstr "Leerzeile statt des erwarteten %s gefunden"

#: ../lib/Parse/DebianChangelog.pm:462 ../lib/Parse/DebianChangelog.pm:477
msgid "unrecognised line"
msgstr 

Bug#776450: Xen PVH support for grub-xen in Buster

[Colin Watson]

On Mon, Jan 07, 2019 at 08:44:50AM +, Colin Watson wrote:
> On Mon, Jan 07, 2019 at 01:58:19AM +0100, Hans van Kranenburg wrote:
> > Ok great. Since I'm not using (and probably not going to use) the
> > multi-stage multiboot things, this is harder for me to help with.
> 
> With any luck I should be able to work that bit out myself, since I
> think stable's Xen has backported PVH support.

So it seems it doesn't quite have enough PVH support.  I get:

  xc: error: panic: xc_dom_core.c:702: xc_dom_find_loader: no loader found: 
Invalid kernel
  libxl: error: libxl_dom.c:638:libxl__build_dom: xc_dom_parse_image failed: No 
such file or directory
  libxl: error: libxl_create.c:1223:domcreate_rebuild_done: cannot (re-)build 
domain: -3
  libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 8
  libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy guest 
with domid 8
  libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 8 failed

(I get the same with your recipe based on upstream master, so I don't
think it's a bug in my backport.)

I can upgrade this host to buster at some point in the nearish future,
but not quite right now.

Would you mind trying out the temporary pvh branch of
https://salsa.debian.org/grub-team/grub ?  I'd like to know whether the
resulting grub-xen-host binary package does the right thing, when built
in the ordinary way (I've test-built this branch using sbuild).

-- 
Colin Watson   [cjwat...@debian.org]

Bug#918552: lombok FTBFS: The import org.eclipse.jdt.internal.corext.refactoring.SearchResultGroup cannot be resolved

[Adrian Bunk]

Source: lombok
Version: 1.16.22-5
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/lombok.html

...
Compile errors: 
--
46. ERROR in 
/build/1st/lombok-1.16.22/src/eclipseAgent/lombok/launch/PatchFixesHider.java 
(at line 64)
import org.eclipse.jdt.internal.corext.refactoring.SearchResultGroup;
   ^
The import org.eclipse.jdt.internal.corext.refactoring.SearchResultGroup cannot 
be resolved
--
47. ERROR in 
/build/1st/lombok-1.16.22/src/eclipseAgent/lombok/launch/PatchFixesHider.java 
(at line 597)
public static SearchResultGroup[] 
createFakeSearchResult(SearchResultGroup[] returnValue,
  ^
SearchResultGroup cannot be resolved to a type
--
48. ERROR in 
/build/1st/lombok-1.16.22/src/eclipseAgent/lombok/launch/PatchFixesHider.java 
(at line 597)
public static SearchResultGroup[] 
createFakeSearchResult(SearchResultGroup[] returnValue,
 
^
SearchResultGroup cannot be resolved to a type
--
49. ERROR in 
/build/1st/lombok-1.16.22/src/eclipseAgent/lombok/launch/PatchFixesHider.java 
(at line 611)
return new SearchResultGroup[] 
{new SearchResultGroup(null, new SearchMatch[1])};
   ^
SearchResultGroup cannot be resolved to a type
--
50. ERROR in 
/build/1st/lombok-1.16.22/src/eclipseAgent/lombok/launch/PatchFixesHider.java 
(at line 611)
return new SearchResultGroup[] 
{new SearchResultGroup(null, new SearchMatch[1])};

^
SearchResultGroup cannot be resolved to a type
--

BUILD FAILED
/build/1st/lombok-1.16.22/build.xml:251: Compilation not successful

Total time: 10 seconds
make[1]: *** [debian/rules:9: override_dh_auto_build] Error 1

Bug#871019: sshfs: Please update to 3.x

[Fabio Pedretti]

Il giorno lun 7 gen 2019 alle ore 03:43 Mo Zhou  ha
scritto:

> On Sun, Jan 06, 2019 at 07:56:11PM +0100, Fabio Pedretti wrote:
> > I don't think a transition is needed, now that fuse and fuse3 are
> > co-installable. The packages that can migrate to fuse3 could do, the
> others
>
> Source of "co-installable"???
> I just installed fuse3, then apt removed gnome-core and fuse. And if I'm
> going to reverse it:
>
> ~ ❯❯❯ sudo apt install fuse
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages were automatically installed and are no longer
> required:
> [...]
> Use 'sudo apt autoremove' to remove them.
> The following packages will be REMOVED:
>   fuse3 sshfs sshfs-dbgsym
> The following NEW packages will be installed:
>   fuse
> 0 upgraded, 1 newly installed, 3 to remove and 2 not upgraded.
> Need to get 0 B/72.0 kB of archives.
> After this operation, 243 kB disk space will be freed.
> Do you want to continue? [Y/n]
>
> How are they "co-installable"???
>

Thanks for the feedback. Since recently released fuse3 3.4.1-1 this issue
should be fixed, this bug has more info:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912528

Are you using 3.4.1-1? If so maybe this issue was not entirely addressed.

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 

Bug#918438: orig tarball components with uppercase letters

[Andrey Rahmatullin]

On Sun, Jan 06, 2019 at 01:05:34PM +, Ian Jackson wrote:
> > > This allows the possibility of uppercase letters [1].  But of course
> > > distinguishing case of letters is troublesome for some computers.
> > 
> > Can you please explain why is this a problem for us?
> 
> People should be able to convey Debian packages (including source
> packages) across such computers.  There are all sorts of situations
> where a user may for whatever reason have to do so.
I'm mostly interested in real examples of such "some computers".

> Note that even Debian systems sometimes mishandle this: ISO9660
> (without Rock Ridge) and VFAT filesystems, both of which we commonly
> use for distributing our own software, are case-insensitive.
From these two at least VFAT, while case-insensitive, is case-preserving.
ISO9660 without both Rock Ridge and Joliet is, I suspect, already
unsupported.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#918554: libodb-api-dev: missing dependency on libodb-api-bin

[Adrian Bunk]

Package: libodb-api-dev
Version: 0.18.1-2
Severity: serious
Control: affects -1 src:magics++

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/magics++.html

...
-- [eccodes] (2.10.0)
--ECCODES_INCLUDE_DIRS : [/usr/lib/include /usr/include 
/usr/lib/python3/dist-packages/numpy/core/include /usr/include/openjpeg-2.1]
--ECCODES_LIBRARIES : [eccodes eccodes_f90 
/usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so 
/usr/lib/x86_64-linux-gnu/libaec.so /usr/lib/x86_64-linux-gnu/libm.so 
/usr/lib/x86_64-linux-gnu/libopenjp2.so]
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/odb_api/odb_api-targets.cmake:97 
(message):
  The imported target "ecml_test" references the file

 "/usr/bin/ecml_test"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/x86_64-linux-gnu/cmake/odb_api/odb_api-targets.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/odb_api/odb_api-config.cmake:78 (include)
  cmake/ecbuild_find_package.cmake:208 (find_package)
  cmake/ecbuild_use_package.cmake:307 (ecbuild_find_package)
  cmake/ecbuild_add_option.cmake:229 (ecbuild_use_package)
  CMakeLists.txt:43 (ecbuild_add_option)


-- Configuring incomplete, errors occurred!

Bug#918525: r-base-core: library lapack.so shouldn't be linked to libopenblas.so.0

[Dirk Eddelbuettel]

On 7 January 2019 at 12:29, Sébastien Villemot wrote:
| Dear Dirk and Jörg-Volker,
| 
| On Mon, 7 Jan 2019 08:54:22 +0100 Jörg-Volker Peetz  wrote:
| 
| > the problem I see, shows when inspecting /usr/lib/R/modules/lapack.so with
| > 
| > $ ldd /usr/lib/R/modules/lapack.so | grep blas
| > libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 
(0x7f58c61b5000)
| > libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 
(0x7f58c2dbb000)
| > 
| > Thus, lapack.so of package r-base-core is linked to libopenblas.so.0
| > which means that r-base-core won't work without package libopenblas-base.
| > And that is not intended AFAIU. 
| 
| As explained in <1546860281.3311.22.ca...@debian.org>, I think there is
| no bug.
| 
| ldd lists libopenblas.so.0 as a dependency, but it is not actually
| needed. I guess it's only listed because it's a *indirect* dependency
| through libblas.so.3, when openblas is selected as the BLAS
| alternative.
| 
| As a matter of fact, R runs fine without libopenblas-base installed.

Thank you. I had not seen your "in-flight" message when I replied here and on
debian-science.

We agree. And there may well be something "unusual to the untrained eye" but
this has worked since way pretty much since the 1990s thanks to some really
clever and novel work done mostly by Camm Maguire. We still take advantage of
it now.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#918538: [Pkg-freeipa-devel] Bug#918538: Please fully switch to python3

[Timo Aaltonen]

On 7.1.2019 11.14, Laurent Bigonville wrote:
> Source: dogtag-pki
> Version: 10.6.8-2
> Severity: normal
> 
> Hi,
> 
> Are there any reasons why part of the generated packages are still
> using python2?

Yes, py2 version of dogtag is needed for freeipa, which can't switch
over to py3 before everything it depends on is ported, and the last
remaining bit is samba (which then needs talloc ported)


-- 
t

Bug#918555: shellcheck: manpage wrongly documents long-options with single dash

[Jonas Smedegaard]

Package: shellcheck
Version: 0.5.0-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

"man shellcheck" documents single-dash for long-options,
e.g. "-shell=shell".

What actually works is to use double-dash, e.g. "--shell=shell".

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwzQKcACgkQLHwxRsGg
ASGnbhAAiTcaCwKu27S2WU8LUQ3Ypr1C1R96UZh+8cgvU+vOPkeWjh6Y/aoztFQy
5zp9UjJaBx9cfJ206wBE1/4PSA5D0sphtI/9MDNZD8VX+CW9UcgNT4vlKOMukKCw
RaknCjV2exeXSRSPi/6PmDpYDyQOkzG1OU99uRL5nlpKw7uYx4rIOK07dtzbaH65
nPdAlLtwgTkywb/1bq5kumvH3IFVn170zgXtdoKvl0QBwhDl9zHiqvdIF2k0yCaX
JL/oH5xTbKUef+rjNWL/AlnbcCWjOnd6pgCkK4vehiKAxjFRwS7tWZQwG+O6jizK
3jBGoQt2eqMvw9XriKI6bAkhSey57CY6qX8GIeT22bm+cqRRIZICzY/CA2OkBU2/
P1xkoe5WXxCh/xXQl9SVWegzO7I7SqBjS52T0Qbb4gS5s+WkEnY9nguQRKPU3Nf9
O54hNO8cmkCauYmT6nlJwIhyQUerTYjhhSRTAM9iYFC5rG3hfzFxxzwkGWjlo1O2
fcgfzQG4Ymqhl1l1Zp9T7FJwwz+7/8W4eAvNpkk11s1ZgC7r/2D8KX8oP+Ke3TzR
KYtfJ4Y73l+4RCTyAr9dq8X6gbH4JT8cyAiKOaQ1Uz9EpVxLh8183dmet5N5ZYV2
5RUk2RKLPxoY1nI8YExn0dpBwRdAvvqoaD2gGu98Spg3/q2PWOA=
=0a31
-END PGP SIGNATURE-

Bug#918294: marked as done (openstreetmap-carto build depends on node-carto that is currently not in buster)

[Sebastiaan Couwenberg]

On 1/7/19 11:45 AM, Debian Bug Tracking System wrote:
> node-carto is back in buster.

But it is not compatible with the new mapnik-reference:

 carto project.mml > style.xml
 /usr/lib/nodejs/carto/lib/carto/tree/reference.js:19
 if (mapnik_reference.version.hasOwnProperty(version)) {
 ^

 TypeError: Cannot read property 'hasOwnProperty' of undefined
 at Object.ref.setVersion
(/usr/lib/nodejs/carto/lib/carto/tree/reference.js:19:34)
 at /usr/lib/nodejs/carto/lib/carto/tree/reference.js:209:5
 at Object.
(/usr/lib/nodejs/carto/lib/carto/tree/reference.js:213:3)
 at Module._compile (internal/modules/cjs/loader.js:689:30)
 at Object.Module._extensions..js
(internal/modules/cjs/loader.js:700:10)
 at Module.load (internal/modules/cjs/loader.js:599:32)
 at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
 at Function.Module._load (internal/modules/cjs/loader.js:530:3)
 at Module.require (internal/modules/cjs/loader.js:637:17)
 at require (internal/modules/cjs/helpers.js:22:18)

Newer version of node-carto require unpackaged dependencies:

 npm2deb depends carto
 Dependencies:
 NPM   Debian
 carto (1.1.0) node-carto (0.9.5-2)
 ├─ chroma-js (~1.3.3) None
 ├─ hsluv (~0.0.1) None
 ├─ js-yaml (~3.12.0)  node-js-yaml (3.11.0+dfsg-1)
 ├─ lodash (~4.17.10)  node-lodash (4.17.11+dfsg-1)
 ├─ mapnik-reference (~8.9.1)  None
 ├─ semver (~5.5.0)node-semver (5.5.1-1)
 └─ yargs (~12.0.1)node-yargs (10.0.3-2)

 Build dependencies:
 NPM   Debian
 coveralls (~3.0.0)node-coveralls (3.0.2-1)
 istanbul (~0.4.5) node-istanbul (0.4.5+ds-2)
 mocha (~5.2.0)node-mocha (4.1.0+ds3-1)
 mocha-eslint (^4.0.0) None
 sax (~1.2.1)  sax.js (1.2.4-2)

This has prevented updating node-carto, and by extension
openstreetmap-carto, for quite a while now.

If this situation doesn't change during the bullseye development cycle,
the openstreetmap-carto package will be removed from Debian.

Kind Regards,

Bas

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

Bug#918556: ITP: welle.io -- DAB/DAB+ Software Radio

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: welle.io
  Version : 2.0-beta1
  Upstream Authors: Albrecht Lohofener 
* URL : https://www.welle.io/
* License : GPL 2+
  Description : DAB/DAB+ Software Radio
 This is an open source DAB and DAB+ software defined radio (SDR) with 
support
 for rtl-sdr (RTL2832U) and airspy. It supports high DPI and touch 
displays and
 it runs even on cheap computers like Raspberry Pi 2/3 and 100€ China 
Windows

 10 tablets.

Package is availabe at http://phd-sid.ethz.ch/debian/welle.io/

Bug#918162: Broken with Thunderbird 60

[W. Martin Borgert]

Quoting Moritz Muehlenhoff :
The plugin is broken with Thunderbird 60 in stretch and sid, after  
installation
it's disabled and only prints "External Editor is incompatible with  
Thunderbird 60.4".


Yes, the package needs an update to version 1.0.3.
Will do ASAP! And many thanks for reminding me!

TB 60 was uploaded to stretch over two months ago (and three months  
ago to sid), given
that noone filed a bug so far, it makes me wonder whether this  
package is used

at all...


Not surprising to me! I'm using the package every (working) day, but
as probably a lot of users, I have thunderbird on hold at version
1:52.9.1-1~deb9u1. After that version a lot of breakage happened, not
only to this extension, but also to calendar-exchange-provider
(#906730) and enigmail (#909000).

It is very unfortunate, that we are not able to prevent major package
breakage during a "stable" release cycle, but I'll at least try reduce
the impact by trying to get a new version into proposed-updates.

Cheers

Bug#918557: virt-manager FTBFS: FAIL: test_dir_searchable (tests.xmlconfig.TestXMLMisc)

[Adrian Bunk]

Source: virt-manager
Version: 1:2.0.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=virt-manager&arch=all&ver=1%3A2.0.0-1&stamp=1546794809&raw=0

...
==
FAIL: test_dir_searchable (tests.xmlconfig.TestXMLMisc)
--
Traceback (most recent call last):
  File "/<>/tests/xmlconfig.py", line 215, in test_dir_searchable
self.assertTrue(not bool(fixlist))
AssertionError: False is not true

--
Ran 440 tests in 18.049s

FAILED (failures=1, skipped=2)
make[1]: *** [debian/rules:12: override_dh_auto_test] Error 1

Bug#918559: octave-geometry FTBFS: dh_dwz returned exit code 1

[Adrian Bunk]

Source: octave-geometry
Version: 3.0.0-8
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=octave-geometry&suite=sid

...
   dh_dwz -a -O--buildsystem=octave
dh_dwz: dwz -q -- 
debian/octave-geometry/usr/lib/aarch64-linux-gnu/octave/packages/geometry-3.0.0/aarch64-unknown-linux-gnu-api-v52/clipper.mex
 returned exit code 1
make: *** [debian/rules:5: binary-arch] Error 1

Bug#866523: instance generator

[Tino Mettler]

Hi,

I found another issue regarding the new openvpn-server and openvpn-client
template services. The old openvpn@.service unit has a generator[1] that
looks for config files in /etc/openvpn/ and creates instances if needed.
The openvpn-server@.service and openvpn-client@.service templates are
not handled by a generator, the user has to enable the instances
manually.

I think this difference should be either fixed or documented.

[1] /lib/systemd/system-generators/openvpn-generator

Bug#918558: mercurial: autopkgtest regression

[Graham Inggs]

Source: mercurial
Version: 4.8-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 4.8-2, mercurial has been failing its own 
autopkgtests [1] with the following error:


test-logtoprocess.t
test-logtoprocess.t ... # Test test-logtoprocess.t
# Running sh "/tmp/hgtests.s_8dj9/child502/test-logtoprocess.t.sh"

--- 
/tmp/autopkgtest-lxc.rxoc9c5k/downtmp/build.kuZ/src/tests/test-logtoprocess.t
+++ 
/tmp/autopkgtest-lxc.rxoc9c5k/downtmp/build.kuZ/src/tests/test-logtoprocess.t.err

@@ -119,6 +119,7 @@
   > commandfinish=$TESTTMP/wait-output.sh
   > EOF
   $ hg version -q --pager=always
+  missing pager command 'less', skipping pager
   Mercurial Distributed SCM (version *) (glob)
   $ touch $TESTTMP/wait-for-touched
   $ sleep 0.2

ERROR: test-logtoprocess.t output changed
!# Ret was: 0 (test-l

Regards
Graham


[1] https://ci.debian.net/packages/m/mercurial/unstable/amd64/

Bug#918560: csound-manual FTBFS: IndexError: tuple index out of range

[Adrian Bunk]

Source: csound-manual
Version: 1:6.12.0~dfsg-1
Severity: serious
Tags: ftbfs

Some recent change in unstable makes csound-manual FTBFS:

https://tests.reproducible-builds.org/debian/history/csound-manual.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/csound-manual.html

...
Traceback (most recent call last):
  File "csd2docbook.py", line 373, in 
CsoundScoreLexer.tokens['root'][3] = (stateTuple[0], Token.Name.Builtin, 
stateTuple[2])
IndexError: tuple index out of range
make[2]: *** [Makefile:699: examples-xml/stamp] Error 1

Bug#906330: bmake: debhelper plugin's exists_make_target() misbehaves when -j is in $MAKEFLAGS

[Andrej Shadura]

On Fri, 17 Aug 2018 10:05:31 + Damyan Ivanov  wrote:
> Package: bmake
> Version: 20160220-2+b1
> Severity: normal
> Tags: patch
> 
> Hi,
> 
> While rebuilding some packages that were using bmake, I stumbled on a couple 
> failures, which were only triggered when `-j X` was passed to sbuild. Even 
> `-j 
> 1` caused failure.
> 
> The failure looks like:
> 
>  dh_auto_test -O--buildsystem=bmake
>   bmake test VERBOSE=1
>   bmake[1]: bmake[1]: don't know how to make test. Stop
> 
>   bmake[1]: stopped in /<>
>   dh_auto_test: bmake test VERBOSE=1 returned exit code 2
> 
> This seems to be caused by an oddity in bmake, which changes its output when 
> `-j` is used:
> 
> An example is the udfclient package:
> 
> Compare:
> 
>  $ bmake -s -n test 2>/dev/null
> 
>  bmake: stopped in /home/dam/w/tmp/udfclient-0.8.8
>  $
> 
> with
> 
>  $ bmake -s -n -j 1 test 2>/dev/null
>  `test' was not built (made 3, flags 2049, type 200)!
>  $
> 
> The check in bmake.pm¹ uses the first line of STDOUT as an indicator whether 
> the given target exists and is fooled by the diagnostic output when -j is 
> used.
> 
>  ¹ https://sources.debian.org/src/bmake/20160220-2/debian/bmake.pm/#L32
> 
> Adding a call to clean_jobserver_flags() doesn't help, because that routine 
> only acts when a job server is used² (--jobserver-... present in $MAKEFLAGS)
> 
>  ² 
> https://sources.debian.org/src/debhelper/11.3.5/lib/Debian/Debhelper/Dh_Lib.pm/#L2166
> 
> My tests show that temporarily removing MAKEFLAGS from the environment in 
> bmake.pm/exists_make_target() works around the problem.
> 
> A proper fix may be to direct the diagnostic output of bmake to STDERR, or to 
> add an empty line before it to make it similar to the non-`-j` case, but I 
> guess that's an upstream decision to make.
> 
> 
> BTW, that bug report could have been accompanied by a merge request if the 
> packaging of bmake was available on salsa.debian.org :)

Thanks for your report. bmake is in fact at salsa:
https://salsa.debian.org/salsa/bmake

-- 
Cheers,
  Andrej

Bug#918563: camomile FTBFS on ppc64{,el}: camomilelocaledef got signal SEGV

[Adrian Bunk]

Source: camomile
Version: 1.0.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=camomile

...
camomilelocaledef Camomile/locales/zh__PINYIN.mar (got signal SEGV)
(cd _build/default/Camomile && tools/camomilelocaledef.exe --file 
locales/zh__PINYIN.txt locales)
make[1]: *** [debian/rules:52: override_dh_auto_build] Error 1

Bug#918562: camomile FTBFS on ocaml bytecode architectures: Fatal error: exception Stack overflow

[Adrian Bunk]

Source: camomile
Version: 1.0.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=camomile

...
camomilelocaledef Camomile/locales/zh__PINYIN.mar (exit 2)
(cd _build/default/Camomile && tools/camomilelocaledef.exe --file 
locales/zh__PINYIN.txt locales)
Fatal error: exception Stack overflow
make[1]: *** [debian/rules:52: override_dh_auto_build] Error 1

Bug#918561: python-click: please package new upstream release 7.0

[Jonas Smedegaard]

Package: python-click
Version: 6.7+git20180829-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream has release new major release 7.0.

Please consider packaging that.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwzRt4ACgkQLHwxRsGg
ASEX5RAAoTAQ3HvKvXakd6PYqde/8Eg4G9PNkCFs025ldcbK1f7UfqpbNdp6L+Lf
TY53K8YzrHUMeLRjSPmFsCdFDN/Hm0JjKLnX/1sP7NrcqeXJgDwIX5c+T5BswBkx
L1jZqAl71SYKlCZs0Bkz8OqDejpxmPiG5/IODzo2AdAGWw8PVYDjSTgaVd/t31Pz
BLb/CyWIdeLCpkYU9KRtzO3/2mSpUkc5mC2E2p4O3SzcyNISJNo+hHnqWspOGIRN
2F5dy6rMX4P6n8sKd8gLEhGyf82eimFiqmSCaofPsR+ZID02Pzsx6pLewZlpCv+V
nwaTKzKop4ANmo3EIgjf+4vDsZP3c5eoh1sGJGMkLVvyUsidMW+hbQ8jt5FXrU0x
ACJf6w7/b4Le5CY36sU6l4FIGyymotegT7+RmfxkNUhFbTNWaVth6ar5mmtD0CiS
WXYft9Sb+nxAvJ1ocadHVP6fQTyL4Zn/ETgA4wJ7vf7ytlxm1ViUBwvD1dLF9Uzl
tLj10IMuHMAGOGyU/cQ2ZkN8NQOYMVoRJzjHrSCyg/0ILq2wQ8boOBwxaxW4H36h
MpM+tJOkuVgSwOcJ4UoXYZH/PGZgsFl2gYZT8cqpVRTnJueXyLTFNnlCtAMUIC/q
GkwBTU/zf8qMXmU7J5qL/FtPtTjxOhRvOAt6PX+GpFU00lHTSIg=
=XFo5
-END PGP SIGNATURE-

Bug#918564: Real libparse-pidl-perl version number is different from its source package

[Andrius Merkys]

Package: libparse-pidl-perl

Hello,

binary package libparse-pidl-perl is built from source package samba, however 
its version number (0.02, as in pidl/lib/Parse/Pidl.pm in unstable as of now) 
is different from the source package (4.9.4). This might result in confusion:

andrius@amalas:~$ dpkg -s libparse-pidl-perl | grep ^Version
Version: 2:4.9.4+dfsg-1
andrius@amalas:~$ perl -le 'use Parse::Pidl; print $Parse::Pidl::VERSION'
0.02

Moreover, this mismatch causes nontrivial translation of CPAN dependencies 
(where the most recent version is 0.02) to Debian ones. A solution would be to 
split off the source of libparse-pidl-perl from samba to preserve the 
upstream's version number.

Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#918438: orig tarball components with uppercase letters

[Bill Allombert]

On Mon, Jan 07, 2019 at 04:55:11PM +0500, Andrey Rahmatullin wrote:
> From these two at least VFAT, while case-insensitive, is case-preserving.
> ISO9660 without both Rock Ridge and Joliet is, I suspect, already
> unsupported.

Could you define what you mean by unsupported ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#918565: python3-asgi-redis is not installable

[Adrian Bunk]

Package: python3-asgi-redis
Version: 1.4.3-1
Severity: serious

The following packages have unmet dependencies:
 python3-asgiref : Breaks: python3-asgi-redis (< 2) but 1.4.3-1 is to be 
installed

Bug#918475: mercurial fails to fetch clone bundles from bitbucket.org (SSL error)

[Julien Cristau]

Control: tag -1 moreinfo unreproducible

On 1/6/19 1:46 PM, Nicolas Braud-Santoni wrote:
> Package: mercurial
> Version: 4.8.1-2
> Severity: important
> 
> Dear maintainers,
> 
> I just installed mercurial on my buster system, and it fails to clone
> repositories from bitbucket.org:
> 
>> $ hg clone https://bitbucket.org/pypy/pypy
>>
>> destination directory: pypy
>> applying clone bundle from 
>> https://api.media.atlassian.com/file/ade8a479-34db-4526-9823-6bd33d7703fa/binary?client=b64ca8e6-e703-4cb9-8f30-cae44f70ea24&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhY2Nlc3MiOnsidXJuOmZpbGVzdG9yZTpmaWxlOmFkZThhNDc5LTM0ZGItNDUyNi05ODIzLTZiZDMzZDc3MDNmYSI6WyJyZWFkIl19LCJleHAiOjE1NDY3Nzg3NDAsImlzcyI6ImI2NGNhOGU2LWU3MDMtNGNiOS04ZjMwLWNhZTQ0ZjcwZWEyNCIsIm5iZiI6MTU0Njc3ODMyMH0.DyHo3Ft-mk_ixHgL1Q6LXGJ1grzALRLarTtXJKD91rk
>> error fetching bundle: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert 
>> handshake failure (_ssl.c:727)
>> abort: error applying bundle
>> (if this error persists, consider contacting the server operator or disable 
>> clone bundles via "--config ui.clonebundles=false")
> 
> 
> Accessing the bundle URL with a different HTTP client (in my case, Firefox
> nightly) works without issue, so this is unlikely to be a server-side issue.
> 
> The suggested workaround (--config ui.clonebundles=false) works, but 
> performance
> is abysmal on large repositories (such as the PyPy repo I was trying to 
> clone).
> 
I can't reproduce.  And it shouldn't use sslv3 so that bit seems fishy.

Cheers,
Julien

Bug#916468: dune: /usr/bin/dune is already provided by the whitedune package

[Stéphane Glondu]

reassign 916468 whitedune 0.30.10-2.1
thanks

Le 14/12/2018 à 20:24, Andreas Beckmann a écrit :
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
> 
>   Selecting previously unselected package dune.
>   Preparing to unpack .../dune_1.6.2-1_amd64.deb ...
>   Unpacking dune (1.6.2-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/dune_1.6.2-1_amd64.deb (--unpack):
>trying to overwrite '/usr/bin/dune', which is also in package whitedune 
> 0.30.10-2.1+b2
>   Errors were encountered while processing:
>/var/cache/apt/archives/dune_1.6.2-1_amd64.deb
> 
> 
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
> 
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
> 
>   usr/bin/dune
>   usr/share/man/man1/dune.1.gz

As discussed on debian-devel, I propose that the whitedune package drops
 /usr/bin/dune, which is a symlink to whitedune.

Cheers,

-- 
Stéphane

Bug#918438: orig tarball components with uppercase letters

[Andrey Rahmatullin]

On Mon, Jan 07, 2019 at 01:35:01PM +0100, Bill Allombert wrote:
> On Mon, Jan 07, 2019 at 04:55:11PM +0500, Andrey Rahmatullin wrote:
> > From these two at least VFAT, while case-insensitive, is case-preserving.
> > ISO9660 without both Rock Ridge and Joliet is, I suspect, already
> > unsupported.
> 
> Could you define what you mean by unsupported ?
Unsupported as a medium for transferring Debian files (in this case
packages).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#776450: Xen PVH support for grub-xen in Buster

[Hans van Kranenburg]

On 1/7/19 12:48 PM, Colin Watson wrote:
> On Mon, Jan 07, 2019 at 08:44:50AM +, Colin Watson wrote:
>> On Mon, Jan 07, 2019 at 01:58:19AM +0100, Hans van Kranenburg wrote:
>>> Ok great. Since I'm not using (and probably not going to use) the
>>> multi-stage multiboot things, this is harder for me to help with.
>>
>> With any luck I should be able to work that bit out myself, since I
>> think stable's Xen has backported PVH support.

Well, I can help testing of course if you have instructions about what
to do.

> So it seems it doesn't quite have enough PVH support.  I get:
> 
>   xc: error: panic: xc_dom_core.c:702: xc_dom_find_loader: no loader found: 
> Invalid kernel
>   libxl: error: libxl_dom.c:638:libxl__build_dom: xc_dom_parse_image failed: 
> No such file or directory
>   libxl: error: libxl_create.c:1223:domcreate_rebuild_done: cannot (re-)build 
> domain: -3
>   libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 8
>   libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy guest 
> with domid 8
>   libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 8 failed
> 
> (I get the same with your recipe based on upstream master, so I don't
> think it's a bug in my backport.)

Yeah, you'll need Xen 4.10 or newer.

And Linux 4.17 or newer for PVH and 4.20 for PVH+grub (or Debian 4.19
which has the patches).

Here's what I run on Stretch in production, if you want to run Xen 4.11:
https://salsa.debian.org/xen-team/debian-xen/tree/stretch-backports

Just build it with pbuilder or something, and the output will be this:
https://packages.mendix.com/debian/pool/main/x/xen/

> I can upgrade this host to buster at some point in the nearish future,
> but not quite right now.

Here's the 4.19 domU kernel that I use on Stretch:

https://packages.mendix.com/debian/pool/main/l/linux/linux-image-4.19.0-0.mxbp.1-cloud-amd64_4.19.9-1~mxbp9%2B1_amd64.deb

It's built from:
https://salsa.debian.org/knorrie-guest/linux/tree/debian/4.19.9-1_mxbp9+1

> Would you mind trying out the temporary pvh branch of
> https://salsa.debian.org/grub-team/grub ?  I'd like to know whether the
> resulting grub-xen-host binary package does the right thing, when built
> in the ordinary way (I've test-built this branch using sbuild).

Sure. I'll have a look at it today.

Hans

Bug#913567: fixed in python-numpy 1:1.16.0~rc2-1)

[Jörg-Volker Peetz]

Package: python-numpy
Version: 1:1.16.0~rc2-1

Hi Sandro,

please, forget my previous e-mail, everything is o.k.

As I just learned, I was misled by the output of the ldd command.
The right command is

$ readelf -d
/usr/lib/python2.7/dist-packages/numpy/linalg/lapack_lite.x86_64-linux-gnu.so |

So everything is fine with numpy now. Many thanks again.

Regards,
Jörg.

Bug#918566: mash FTBFS on big endian: test failures

[Adrian Bunk]

Source: mash
Version: 2.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=mash

...
diff test/genomes.dist test/ref/genomes.dist
1,3c1,3
< genome1.fna   reads   0.12827 1.02947e-18035/1000
< genome2.fna   reads   0.1296046.13708e-17534/1000
< genome3.fna   reads   0.12827 1.02332e-18035/1000
---
> genome1.fna   reads   0.12101 4.48626e-21441/1000
> genome2.fna   reads   0.12827 2.61074e-18035/1000
> genome3.fna   reads   0.12101 4.45454e-21441/1000
make[1]: *** [Makefile:98: testDist] Error 1
make[1]: *** Waiting for unfinished jobs
diff test/genomes.json test/ref/genomes.json
18,1017c18,1017
<   2755981392628,
<   3189583257792,
<   9584077549833,
<   12718262031724,
<   17482074590444,
<   23032165717400,
...

Bug#888400: RFA: python-cassandra-driver

[Hector Oron]

Hello,

On Wed, Nov 28, 2018 at 10:48:11AM -0300, eamanu15 wrote:
> Control: retitle -1 ITA: python-cassandra-driver
> 
> Control: owner -1 emmanuelaria...@gmail.com
> 
> Hello,
> 
> I am interest on adopt this package.
> 
> I upload a new version(3.16.0-1) to mentors.d.o
> https://mentors.debian.net/package/python-cassandra-driver

Since this package has RC bugs is not part of Buster, and it is needed
for new `salt` packages. I plan to sponsor Emmanuel package into Debian,
in the hope to allow newer `salt` into Buster.

Regards


signature.asc
Description: PGP signature

Bug#918543: ring build depends on libsrtp-dev that is not in buster

[Bernhard Schmidt]

Am 07.01.19 um 10:56 schrieb Adrian Bunk:
> Source: ring
> Version: 20180119.1.9e06f94~ds120181001.4.a99aaec~ds6-2
> Severity: serious
> Tags: ftbfs
> Control: block 910292 by -1
> 
> ring build depends on libsrtp-dev that is not in buster,
> see #910292 for background.
> 

According to the buildlog it builds an embedded copy of libsrtp, and the
resulting binary does not depend on libsrtp. So I guess the build-dep
can be dropped.

OTOH it would probably make sense to have the embedded libpjproject use
the system libsrtp2.

Bernhard

Bug#918567: dlib: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Package: src:dlib
Version: 19.10-2
Severity: serious
Tags: ftbfs patch

Dear maintainer:

I tried to build this package in buster with "dpkg-buildpackage -A" but it 
failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=cmake
   dh_update_autotools_config -i -O--buildsystem=cmake
   dh_autoreconf -i -O--buildsystem=cmake
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -Bconfig_shared -- -DDLIB_NO_GUI_SUPPORT=ON 
-DBUILD_SHARED_LIBS=ON
cd config_shared && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DDLIB_NO_GUI_SUPPORT=ON 
-DBUILD_SHARED_LIBS=ON ..
-- The C compiler identification is GNU 8.2.0

[... snipped ...]

-- Installing: 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/dlib/dlib.cmake
-- Installing: 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/dlib/dlib-none.cmake
-- Installing: 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/dlib/dlibConfig.cmake
-- Installing: 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/dlib/dlibConfigVersion.cmake
-- Installing: 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/dlib-1.pc
make[2]: Leaving directory '/<>/config_shared'
# Remove empty directories
find /<>/debian/tmp/usr/include/dlib -type d -empty -delete
make[1]: Leaving directory '/<>'
   dh_install -i -O--buildsystem=cmake
   dh_installdocs -i -O--buildsystem=cmake
   dh_installchangelogs -i -O--buildsystem=cmake
   dh_installexamples -i -O--buildsystem=cmake
   dh_installinit -i -O--buildsystem=cmake
   dh_perl -i -O--buildsystem=cmake
   dh_link -i -O--buildsystem=cmake
   dh_strip_nondeterminism -i -O--buildsystem=cmake
   dh_compress -i -O--buildsystem=cmake
   debian/rules override_dh_fixperms
make[1]: Entering directory '/<>'
dh_fixperms
# Fix wrong permissions in examples/
chmod 644 
debian/libdlib19/usr/share/doc/libdlib19/examples//max_cost_assignment_ex.cpp
chmod: cannot access 
'debian/libdlib19/usr/share/doc/libdlib19/examples//max_cost_assignment_ex.cpp':
 No such file or directory
make[1]: *** [debian/rules:49: override_dh_fixperms] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:19: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The usual recipe here is to split override_dh_fixperms into 
override_dh_fixperms-arch
and override_dh_fixperms-indep.

In this case I believe the (untested) patch below will work. To be sure, please
try both "dpkg-buildpackage -A" and "dpkg-buildpackage -B".

Also, please consider uploading in source-only form (dpkg-buildpackage -S)
so that these kind of bugs never propagate to testing.

Thanks.

--- a/debian/rules
+++ b/debian/rules
@@ -43,7 +43,7 @@ override_dh_auto_install:
# Remove empty directories
find $(CURDIR)/debian/tmp/usr/include/dlib -type d -empty -delete
 
-override_dh_fixperms:
+override_dh_fixperms-arch:
dh_fixperms
# Fix wrong permissions in examples/
chmod 644 $(EXAMPLES_PATH)/max_cost_assignment_ex.cpp

Bug#918568: gst-plugins-base1.0: Please update symbols file for kbsd

[Mattia Rizzolo]

Source: gst-plugins-base1.0
Version: 1.14.4-1
Severity: important
Tags: ftbfs patch

Dear maintainer, gst-plugins-base1.0 has been failing to build on kbsd
recently because of symbols mismatch.

--- debian/libgstreamer-gl1.0-0.symbols 
(libgstreamer-gl1.0-0_1.14.4-1_kfreebsd-amd64)
+++ dpkg-gensymbolsYugCbI   2018-10-05 06:32:39.741785000 +
@@ -7,8 +7,8 @@
  gst_context_get_gl_display@Base 1.14.0
  gst_context_set_gl_display@Base 1.14.0
  gst_egl_get_error_string@Base 1.14.0
- (arch=linux-any)gst_egl_image_export_dmabuf@Base 1.14.0
- (arch=linux-any)gst_egl_image_from_dmabuf@Base 1.14.0
+ gst_egl_image_export_dmabuf@Base 1.14.0
+ gst_egl_image_from_dmabuf@Base 1.14.0
  gst_egl_image_from_texture@Base 1.14.0
  gst_egl_image_get_image@Base 1.14.0
  gst_egl_image_get_type@Base 1.14.0
dh_makeshlibs: failing due to earlier errors


I don't know why those symbols appears on kbsd, but please update the
file to match those.
Given that they aren't present on hurd, I suppose you use either
arch=linux-any kfreebsd-any
or
arch=!hurd-any
(I personally prefer the former, but your choice.)

Thank you in advance.

-- 
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

Bug#871019: sshfs: Please update to 3.x

[Mo Zhou]

On Mon, Jan 07, 2019 at 12:48:32PM +0100, Fabio Pedretti wrote:
> ~ ❯❯❯ sudo apt install fuse
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages were automatically installed and are no longer
> required:
> [...]
> Use 'sudo apt autoremove' to remove them.
> The following packages will be REMOVED:
>   fuse3 sshfs sshfs-dbgsym
> The following NEW packages will be installed:
>   fuse
> 0 upgraded, 1 newly installed, 3 to remove and 2 not upgraded.
> Need to get 0 B/72.0 kB of archives.
> After this operation, 243 kB disk space will be freed.
> Do you want to continue? [Y/n]
> 
> How are they "co-installable"???
> 
> Thanks for the feedback. Since recently released fuse3 3.4.1-1 this issue
> should be fixed, this bug has more info:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912528
> 
> Are you using 3.4.1-1? If so maybe this issue was not entirely addressed.

Yes. The sshfs package as shown above is built by myself[1]

~ ❯❯❯ apt list libfuse\* --installed
Listing... Done
libfuse2/unstable,unstable,unstable,now 2.9.8-2 amd64 [installed,automatic]
libfuse3-3/unstable,unstable,unstable,now 3.4.1-1 amd64 [installed,automatic]
libfuse3-dev/unstable,unstable,unstable,now 3.4.1-1 amd64 [installed]
~ ❯❯❯ apt list fuse\* --installed
Listing... Done
fuse3/unstable,unstable,unstable,now 3.4.1-1 amd64 [installed,automatic]
~ ❯❯❯ apt list sshfs\* --installed
Listing... Done
sshfs-dbgsym/now 3.5.1-1 amd64 [installed,local]
sshfs/now 3.5.1-1 amd64 [installed,local]

[1] https://salsa.debian.org/lumin/sshfs-fuse

Bug#910292: transition: libsrtp0-rm

[Mattia Rizzolo]

On Thu, Jan 03, 2019 at 07:12:38PM +0100, Bernhard Schmidt wrote:
> FTR, kopete is fixed and I've filed Bug#918136 for the removal of
> src:srtp from testing.

Which is now done.

However, I still don't see a RC bug against src:resiprocate.
For gst-plugins-bad1.0, I suspect #918568 will fix the kbsd binaries,
but for hurd it's much more convoluted, so I guess breaking those is the
only way forward.

I think you should file the RM bug after filing the new RC bug for
resiprocate, ack breaking those two packages.

-- 
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

Bug#918545: qtdeclarative-opensource-src: FTBFS on x32: mis-detected as having amd64 JIT

[Lisandro Damián Nicanor Pérez Meyer]

Hi Thorsten!

El lun., 7 ene. 2019 08:18, Thorsten Glaser  escribió:

> Source: qtdeclarative-opensource-src
> Version: 5.11.3-2
> Severity: important
>
> See also:
> https://buildd.debian.org/status/fetch.php?pkg=qtdeclarative-opensource-src&arch=x32&ver=5.11.3-2&stamp=1545865790&raw=0
>
> src/qml/jsruntime/qv4global_p.h line 94 always triggers,
> because x32 is detected as amd64 (Q_PROCESSOR_X86 and
> Q_PROCESSOR_X86_64 are defined and QT_POINTER_SIZE is 8)
> by qtbase5-dev (src/corelib/global/qprocessordetection.h).
>
> Changing qprocessordetection to set QT_POINTER_SIZE to 4
> for x32 won’t help because src/qml/jsruntime/qv4global_p.h
> line 91 would then misdetect it as i386. (It would still
> be more correct, but I don’t know if that would break
> things that work, for now.)
>

I would prefer doing the right thing here, ie, wether further patching is
needed before jumping to disabling JIT.

>

Bug#918566: [Debian-med-packaging] Bug#918566: mash FTBFS on big endian: test failures

[Fabian Klötzl]

mash internally uses MurmurHash 3 which is sensitive to the endianess. 
There is a note in the source [1], but no preventive measures are taken. 
I will forward this upstream and might even have a go at this myself.


(In theory this should not be a big issue expect for slightly 
inaccurate/different results.)


Fabian

1: 
https://github.com/marbl/Mash/blob/aabd5925e7cfc097a8d89e2d8691ac4af5b95d37/src/mash/MurmurHash3.cpp#L52

Bug#918569: Could not find 'activerecord' (~> 4.2) - did find: [activerecord-5.2.0]

[Pirate Praveen]

Package: schleuder
Version: 3.3.0-6
Severity: serious
Control: forwarded -1 https://0xacab.org/schleuder/schleuder/issues/372

Currently rails 5.2 is in unstable and schleuder autopkgtest is failing
(it is causing a delay in rails 5 migration to buster). Please fix it so
we can get rails 5 into buster.

Thanks
Praveen



signature.asc
Description: OpenPGP digital signature

Bug#916192: defoma ftbfs from source

[Adrian Bunk]

Control: tags -1 patch

On Tue, Dec 11, 2018 at 09:32:32AM +0100, Matthias Klose wrote:
> Package: src:defoma
> Version: 1:0.9.18+r243-4
> Severity: serious
> 
> defoma ftbfs from source, at least on armhf and s390x (also on amd64 and i386 
> in
> Ubuntu with the same failure):
> 
> see https://buildd.debian.org/status/package.php?p=foma
> 
> gcc -g -O2 -fdebug-prefix-map=/<>/foma-0.9.18+r243=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -D_GNU_SOURCE
> -std=c99 -fvisibility=hidden -fPIC -Wl,-z,relro -c regex.c -o regex.o
> gcc -g -O2 -fdebug-prefix-map=/<>/foma-0.9.18+r243=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -D_GNU_SOURCE
> -std=c99 -fvisibility=hidden -fPIC -Wl,-z,relro -c foma.c -o foma.o
> regex.c: In function 'yyparse':
> regex.c:2779:3: error: unterminated comment
>/* User semantic actions sometimes alter yychar, and that requires
>^
>...

This is a parallel build error.

The best option would be to fix the Makefile,
but sufficient to fix this bug is also the workaround

--- debian/rules.old2019-01-07 13:35:37.541340870 +
+++ debian/rules2019-01-07 13:36:02.249340635 +
@@ -7,7 +7,7 @@
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:
-   dh $@ --fail-missing
+   dh $@ --fail-missing --no-parallel
 
 override_dh_auto_configure:
touch NEWS


cu
Adrian

-- 

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

Bug#882878: openfoam: new version 5.0 available

[Daniel Baumann]

retitle 882878 new upstream (6.x)
thanks

Hi,

in the meanwhile, openfoam 6.x is current. do you need help?

Regards,
Daniel

Bug#918570: python3-sklearn-lib: dependency on libblas3 | libblas.so.3 instead of libatlas3-base?

[Jörg-Volker Peetz]

Package: python3-sklearn-lib
Version: 0.20.1+dfsg-1
Severity: important

Dear Science-Team,

some libraries of this package are linked to libcblas.so.3.
Could this be replaced by linking to libblas.so?
Could this package depend on libblas3 | libblas.so.3 instead of
libatlas3-base?

Regards,
Jörg.


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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python3-sklearn-lib depends on:
ii  libatlas3-base  3.10.3-7+b1
ii  libc6   2.28-2
ii  libgcc1 1:8.2.0-13
ii  libstdc++6  8.2.0-13
ii  python3 3.7.1-3
ii  python3-numpy [python3-numpy-abi9]  1:1.16.0~rc2-1

python3-sklearn-lib recommends no packages.

python3-sklearn-lib suggests no packages.

Bug#918438: orig tarball components with uppercase letters

[Ian Jackson]

Andrey Rahmatullin writes ("Re: Bug#918438: orig tarball components with 
uppercase letters"):
> From these two at least VFAT, while case-insensitive, is case-preserving.
> ISO9660 without both Rock Ridge and Joliet is, I suspect, already
> unsupported.

Err, I think you're right about ISO9660 without either Rock Ridge or
Joliet.  But ISO9660 with Joliet but not RR is case-insensitive and
case-preserving.

The main problem is that case-insensitive but case-preserving is not
sufficient, since the current spec makes it possible for two different
files to have names which are the same when case-smashed.

So what I think is needed is to come up with some rule which
(i) prevents two different files with case-insensitively-identical
names (ii) can actually somehow be assured to be true.

The simplest such rule is to forbid uppercase letters completely.  It
is not necessarily the most convenient now because that involves a
change, but it is a small change which should be easy to incorprate
into everyone's workflow eventually, and I think we aren't in a hurry
because this is right now a theoretical problem.

That is the only rule violations of which can be spotted locally,
without some kind of context or database or something.

More complex rules are possible.  For example, (i) no single package
may contain multiple case-insensitively-identical orig components plus
(ii) a similar condition on different uploads of the same (package,
orig-version).  The condition (ii) would have to be clearly stated and
then implemented in dak and reprepro and launchpad (at least).

Does that make sense ?

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#918499: libreoffice: fails with 'ERROR 4 forking process'

[Tunggul Arif Siswoyo]

On Mon, 7 Jan 2019 07:25:51 +0100 Rene Engelhard  wrote:
> On Sun, Jan 06, 2019 at 08:21:36PM -0500, David Zelinsky wrote:
> > > No, you didn't.
> > 
> > Yes, I did.  If you think something may have gone wrong with it, then
> > you might tell me that.  But if you think I'm lying, you're wrong.
> 
> I just said you didn't do a upgrade _recently_ because, see
> below - purely based on looking at your versions.
> 
> > And yet, when I do 'apt upgrade libreoffice' it tells me this is most
> > recent version.
> 
> 1:6.1.3-2? Impossible. Testing got 1:6.1.4-1 long ago, and now has
> 1:6.1.4-3.
> 
> See https://packages.qa.debian.org/libr/libreoffice.html
> 
> Similar with other old versions of yours.
> 
> Maybe out of date mirror?
> 
> > >> libreoffice worked fine, but now fails to start.  From the menu,
> > >
> > > My laptop is runnig testing, too and this worked and works.
> > 
> > OK.  Are you saying you're having trouble replicating my problem?
> 
> Yes. No problem at all for weeks.
> 
> > >> nothing happens.  From command line, it fails with the subject error:
> > >> 
> > >>   % libreoffice
> > >
> > > And this works fine.
> > 
> > Riffing on your first comment, if a package works for one person, that
> > is not necessarily proof that it doesn't have a problem.  Again, I was
> 
> True, but given how long these versios are in testing as of now if it
> was a general or a problem experienced often problem the report would
> have come far sooner..
> 
> > I have no idea what this means.  I did not explictly put OpenJDK 8 "in
> > the config".  As I said, I'm not a Debian developer, and I don't spend
> > all my time looking at all the config files on my system (though I do
> > look at a number of them).
> 
> OK, but LO uses Java at parts. (It looks for /usr/bin/java.
> 
> Here:
> 
> rene@frodo:~/.config/libreoffice$ grep -r java *
> 4/user/config/javasettings_Linux_X86_64.xml: xmlns="http://openoffice.org/2004/java/framework/1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 4/user/config/javasettings_Linux_X86_64.xml: vendorUpdate="2013-05-02" autoSelect="true">
> 4/user/config/javasettings_Linux_X86_64.xml:file:///usr/lib/jvm/java-11-openjdk-amd64
> 4/user/config/javasettings_Linux_X86_64.xml:
> 4/user/config/javasettings_Linux_X86_64.xml:


Hello,
I also use testing and encounter same problem. Couple days ago I'm
upgrading libreoffice from 6.1.3 to 6.1.4-3 (latest in testing). After
upgrade, everytime I start libreoffice it failed with "ERROR 4 forking
process" 

Please advise if there's any additional info I can provide to solve
this.

Thank you

--
tunggul

-- Package-specific info:
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----===
un  libreoffice-gtk2   (no description available)
ii  libreoffice-gtk3 1:6.1.4-3amd64office productivity suite -- 
GTK+ 3 integration
un  libreoffice-kde5   (no description available)

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

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

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.1-1
ii  fonts-opensymbol  2:102.10+LibO6.1.2-1
ii  libboost-date-time1.67.0  1.67.0-11
ii  libboost-locale1.67.0 1.67.0-11
ii  libc6 2.28-2
ii  libcairo2 1.15.12-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.8-5
ii  libcurl3-gnutls   7.61.0-1
ii  libdbus-1-3   1.12.12-1
ii  libdbus-glib-1-2  0.110-3
ii  libdconf1 0.30.0-1
ii  libeot0   0.01-5
ii  libepoxy0 1.5.2-0.3
ii  libexpat1 2.2.6-1
ii  libexttextcat-2.0-0   3.4.5-1
ii  libfontconfig12.13.1-1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-13
ii  libglib2.0-0  2.58.1-2
ii  libgpgmepp6   1.12.0-4
ii  libgraphite2-31.3.12-1
ii  libharfbuzz-icu0  1.9.0-1
ii  libharfbuzz0b 1.9.0-1
ii  libhunspell-1.7-0 1.7.0-2
ii  libhyphen02.8.8-5
ii  libice6   2:1.0.9-2
ii  libicu63

Bug#918571: RFS: python-gphoto2/1.9.0-1

[Herbert Fortes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "python-gphoto2" as
  I am without my key and access to Salsa

 * Package name: python-gphoto2
   Version : 1.9.0-1
   Upstream Author : Jim Easterbrook 
 * URL : https://github.com/jim-easterbrook/python-gphoto2
 * License : GPL-3+
   Section : python

  It builds those binary packages:

python-gphoto2-doc - Python interface to libgphoto2 (common documentation)
python3-gphoto2 - Python interface to libgphoto2 (Python 3)

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

  https://mentors.debian.net/package/python-gphoto2


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-gphoto2/python-gphoto2_1.9.0-1.dsc

  More information about python-gphoto2 can be obtained from 
https://www.example.com.

  Changes since the last upload:

  * New upstream version 1.9.0
  * debian/control:
  - Bump Standards-Version from 4.2.1 to .4.3.0
  * debian/copyright:
  - Update year for myself



Regards,
Herbert

Bug#918566: [Debian-med-packaging] Bug#918566: mash FTBFS on big endian: test failures

[Fabian Klötzl]

forwarded 918566 https://github.com/marbl/Mash/issues/106
thanks

Bug#918566: [Debian-med-packaging] Bug#918566: mash FTBFS on big endian: test failures

[Sascha Steinbiss]

Hi,

FYI I have already opened an issue upstream for something that might be
related:

  https://github.com/marbl/Mash/issues/104

I suspect that some of these failures are connected to the update of
Cap'n Proto to 0.7.0, the issues only started after the dependency was
upgraded in in unstable.

Cheers
Sascha

On 1/7/19 2:14 PM, Adrian Bunk wrote:
> Source: mash
> Version: 2.1-1
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/package.php?p=mash
> 
> ...
> diff test/genomes.dist test/ref/genomes.dist
> 1,3c1,3
> < genome1.fna reads   0.12827 1.02947e-18035/1000
> < genome2.fna reads   0.1296046.13708e-17534/1000
> < genome3.fna reads   0.12827 1.02332e-18035/1000
> ---
>> genome1.fna  reads   0.12101 4.48626e-21441/1000
>> genome2.fna  reads   0.12827 2.61074e-18035/1000
>> genome3.fna  reads   0.12101 4.45454e-21441/1000
> make[1]: *** [Makefile:98: testDist] Error 1
> make[1]: *** Waiting for unfinished jobs
> diff test/genomes.json test/ref/genomes.json
> 18,1017c18,1017
> < 2755981392628,
> < 3189583257792,
> < 9584077549833,
> < 12718262031724,
> < 17482074590444,
> < 23032165717400,
> ...
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

Bug#918574: FATAL gnome-shell loops on boot filling up syslog

[Robert Stone]

Package: gnome-shell

Version: 3.30.1-2


Testing 4.19.0-1 (buster amd64)

Cannot boot my laptop. gnome-shell fills up syslog with these messages.

There may be some typo's as I had to write this down and go to the
local library.


gnome-shell[1458]: failed to bind to /tmp/.X11-unix/X1024: No such
file or directory

gnome-shell[1458]: failed to bind to /tmp/.X11-unix/X1025: No such
file or directory

These repeat with the X number increasing by one until I remove the
battery and then restart in recovery mode. The last lines are as
follows:-

gnome-shell[1458]: failed to bind to /tmp/.X11-unix/X120805: No such
file or directory

gnome-shell[1458]: failed to bind to /tmp/.X11-unix/X120806: No such
file or directory

kernel:[   134.986875] do.trap: 14 callbacks suppressed

kernel:[   134.986878] traps: gnome-shell[1458] trap int3
ip:7fe777dd4be5 sp:7ffdcca78120 error:0 in
libglib-2.0.so.5800.2[7fe777d9c000+7e00]

gnome-shell[1458]: failed to bind to /tmp/.X11-unix/X120807: No such
file or directory

gnome-shell[1458]: failed to bind to /tmp/.X11-unix/X120809: No such
file or directory

gnome-shell[1458]: failed to write pid to lock file /tmp/.X120810-lock

gnome-shell[1458]: Failed to create an X lock file

gnome-shell[1458]: Failed to start X Wayland


Please fix this ASAP. My laptop is dead in the water.


TIA,

Robert

Bug#914568: emacs25: Please build with xwidget support

[David Bremner]

Dato Simó  writes:


>   1. have a separate emacs-xwidgets _source_ package, confined to 
>  unstable.
>
>   2. ‘abuse’ the experimental suite, and re-upload there every 
>  unstable version verbatim, with xwidgets support
>
>  2.a: ... in a separate emacs-xwidgets package, OR
>  2.b: ... in the main emacs package
>
> (2.a) would need checking with ftpmaster, just to be sure they're 
> okay; (2.b) is simpler but misleading (upgrading from experimental 
> to a higher version in unstable will _lose_ you features). (1) is 
> typically frowned upon.

FWIW, I would not be enthusiastic about 2.b. I think the converse issue
of people upgrading to xwidgets support would not necessarily be
desirable.

d

Bug#918572: check FTBFS on ppc*: test failure

[Adrian Bunk]

Source: check
Version: 0.12.0-0.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=check

...
FAIL: check_check_export
FAIL: check_check
PASS: test_output.sh
PASS: test_check_nofork.sh
PASS: test_check_nofork_teardown.sh
PASS: test_xml_output.sh
PASS: test_log_output.sh
PASS: test_set_max_msg_size.sh
PASS: test_tap_output.sh

   Check 0.12.0: tests/test-suite.log


# TOTAL: 9
# PASS:  7
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0



(powerpcspe builds with nocheck)

Bug#918573: Automate or document all the changes needed in the website when a new year starts

[Laura Arjona Reina]

Package: www.debian.org
Severity: normal
User: debian-...@lists.debian.org
Usertags: script

Hello all
Happy new year 2019!
When a new year starts there are several website section that expect
$(CUR_YEAR) folders to be there in order to build ok.
It would be nice to document or even automate the creation of all the
needed folders and files, and, if possible, their corresponding
translations.

The wiki team have, for example, this page:
https://wiki.debian.org/Year

we could have a similar webpage to start with, but I'm not sure where to
place it (https://wiki.debian.org/Teams/Webmaster/Year?).

For now, I'm listing the sections having a 2018 folder and thus probably
needed to be taken into account when a new year starts:

english/News
english/News/weekly/
english/partners/
english/security/
english/vote

For English I guess it's enough to copy the former year folder and
adjust the year (e.g. 2018 -> 2019 and 18->19 in every place).

For the translations it's important to remember to update the git hashes
too (to point to the commit that was adding the new year files in
English folder).

Cheers
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Bug#918575: abyss FTBFS on 32bit big endian: test failures

[Adrian Bunk]

Source: abyss
Version: 2.1.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=abyss

...

FAIL: common_kmer
=

Running main() from gtest_main.cc
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from Kmer
[ RUN  ] Kmer.canonicalize
Common/KmerTest.cpp:18: Failure
Value of: kmer
  Actual: AGGC
Expected: canonical
Which is: ATGC
Common/KmerTest.cpp:30: Failure
Value of: kmer
  Actual: TTCGG
Expected: oddLengthCanonical
Which is: CGAGC
[  FAILED  ] Kmer.canonicalize (0 ms)
[--] 1 test from Kmer (1 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (1 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] Kmer.canonicalize

 1 FAILED TEST
FAIL common_kmer (exit status: 1)

FAIL: BloomFilter
=

Running main() from gtest_main.cc
[==] Running 8 tests from 2 test cases.
[--] Global test environment set-up.
[--] 6 tests from BloomFilter
[ RUN  ] BloomFilter.base
Konnector/BloomFilter.cc:30: Failure
Value of: x[b]
  Actual: false
Expected: true
Konnector/BloomFilter.cc:31: Failure
Value of: x[Bloom::hash(b) % x.size()]
  Actual: false
Expected: true
Konnector/BloomFilter.cc:34: Failure
Value of: x[c]
  Actual: false
Expected: true
Konnector/BloomFilter.cc:35: Failure
Value of: x[Bloom::hash(c) % x.size()]
  Actual: false
Expected: true
[  FAILED  ] BloomFilter.base (0 ms)
[ RUN  ] BloomFilter.serialization
Konnector/BloomFilter.cc:55: Failure
Value of: origBloom[b]
  Actual: false
Expected: true
Konnector/BloomFilter.cc:56: Failure
Value of: origBloom[c]
  Actual: false
Expected: true
Konnector/BloomFilter.cc:73: Failure
Value of: copyBloom[b]
  Actual: false
Expected: true
Konnector/BloomFilter.cc:74: Failure
Value of: copyBloom[c]
  Actual: false
Expected: true
[  FAILED  ] BloomFilter.serialization (1 ms)
[ RUN  ] BloomFilter.union_
Konnector/BloomFilter.cc:92: Failure
Value of: bloom2[b]
  Actual: false
Expected: true
Konnector/BloomFilter.cc:109: Failure
Value of: unionBloom[b]
  Actual: false
Expected: true
[  FAILED  ] BloomFilter.union_ (0 ms)
[ RUN  ] BloomFilter.intersect
Konnector/BloomFilter.cc:132: Failure
Value of: bloom2[b]
  Actual: false
Expected: true
[  FAILED  ] BloomFilter.intersect (0 ms)
[ RUN  ] BloomFilter.windowSerialization
[   OK ] BloomFilter.windowSerialization (0 ms)
[ RUN  ] BloomFilter.windowUnion
[   OK ] BloomFilter.windowUnion (0 ms)
[--] 6 tests from BloomFilter (1 ms total)

[--] 2 tests from CascadingBloomFilter
[ RUN  ] CascadingBloomFilter.base
Konnector/BloomFilter.cc:178: Failure
Value of: 2U
  Actual: 2
Expected: x.popcount()
Which is: 1
Konnector/BloomFilter.cc:179: Failure
Value of: x[b]
  Actual: false
Expected: true
Konnector/BloomFilter.cc:180: Failure
Value of: x[Bloom::hash(b) % x.size()]
  Actual: false
Expected: true
Konnector/BloomFilter.cc:182: Failure
Value of: 3U
  Actual: 3
Expected: x.popcount()
Which is: 1
Konnector/BloomFilter.cc:183: Failure
Value of: x[c]
  Actual: false
Expected: true
[  FAILED  ] CascadingBloomFilter.base (1 ms)
[ RUN  ] CascadingBloomFilter.window
[   OK ] CascadingBloomFilter.window (0 ms)
[--] 2 tests from CascadingBloomFilter (1 ms total)

[--] Global test environment tear-down
[==] 8 tests from 2 test cases ran. (2 ms total)
[  PASSED  ] 3 tests.
[  FAILED  ] 5 tests, listed below:
[  FAILED  ] BloomFilter.base
[  FAILED  ] BloomFilter.serialization
[  FAILED  ] BloomFilter.union_
[  FAILED  ] BloomFilter.intersect
[  FAILED  ] CascadingBloomFilter.base

 5 FAILED TESTS
FAIL BloomFilter (exit status: 1)

FAIL: Konnector_DBGBloomAlgorithms
==

Running main() from gtest_main.cc
[==] Running 8 tests from 2 test cases.
[--] Global test environment set-up.
[--] 4 tests from GetStartKmerPosTest
[ RUN  ] GetStartKmerPosTest.FullReadMatch
[   OK ] GetStartKmerPosTest.FullReadMatch (0 ms)
[ RUN  ] GetStartKmerPosTest.FullReadMismatch
[   OK ] GetStartKmerPosTest.FullReadMismatch (1 ms)
[ RUN  ] GetStartKmerPosTest.NumMatchesThreshold
Konnector/DBGBloomAlgorithmsTest.cpp:85: Failure
Value of: getStartKmerPos(testRead, k, FORWARD, g, numMatchesThreshold)
  Actual: 3
Expected: 5U
Which is: 5
[  FAILED  ] GetStartKmerPosTest.NumMatchesThreshold (1 ms)
[ RUN  ] GetStartKmerPosTest.EqualLengthMatchRegions
Konnector/DBGBloomAlgorithmsTest.cpp:126: Failure
Value of: getStartKmerPos(testRead, k, FORWARD, g, numMatchesThreshold)
  Actual: 1
Expected: 4U
Which is: 4
[  FAILED  ] GetStartKmerPosTest.EqualLengthMatchRegions (0 ms)
[--] 4 tests from GetStartKmerPosTest (2 ms total)

[--] 4 tests from CorrectSingleBaseErrorTest
[ RUN  ] CorrectSingleBaseErrorTest.SingleError
Konnector/DBGBloomAlgorithmsTest.cpp:166: Failure
Value of: success
  

Bug#918576: MySQL Reference Manual may be installed locally

[積丹尼 Dan Jacobson]

Package: mysql-client-core-5.7
Version: 5.7.24-2
Severity: wishlist
File: /usr/share/man/man1/mysql.1.gz

$ man mysql says
SEE ALSO
   For more information, please refer to the MySQL Reference Manual,
   which may already be installed locally and which is also
   available online at http://dev.mysql.com/doc/.

Perhaps it could packaged so Debian users could read it locally.

Bug#918384: dgit: typo suggestions in man pages

[Paul Hardy]

On Mon, Jan 7, 2019 at 2:44 AM Ian Jackson
 wrote:
> ..
> You are using git for this, right ?

Yes.  That is how I generated the git format-patch file.

If you can give me a couple of days I will look over the 8.3 man page
changes as well.

Thanks,


Paul Hardy

Bug#918577: xfce4-terminal: `Zoom In` shortcut is `Ctrl+Shift++` (not `Ctrl++`)

[vassil]

Package: xfce4-terminal
Version: 0.8.7.4-2
Severity: normal

Dear Maintainer,

Thanks for your work on xfce4-terminal!

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

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

Versions of packages xfce4-terminal depends on:
ii  exo-utils   0.12.3-1
ii  libc6   2.28-2
ii  libcairo2   1.16.0-2
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-7
ii  libglib2.0-02.58.1-2
ii  libgtk-3-0  3.24.2-3
ii  libpango-1.0-0  1.42.4-6
ii  libutempter01.1.6-3
ii  libvte-2.91-0   0.54.2-2
ii  libx11-62:1.6.7-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3

Versions of packages xfce4-terminal recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1

xfce4-terminal suggests no packages.

-- no debconf information