Bug#784512: [Python-modules-team] Bug#784512: Remove pyside?

[Felix Zielcke]

Am Freitag, den 01.03.2019, 14:32 -0300 schrieb Lisandro Damián Nicanor
Pérez Meyer:
> 
> removing it also means removing python-ghost, yubikey-piv-manager and
> yubioath-desktop
> 

Hi,

the version of yubioath-desktop in sid is very old.
Current upstream version uses pyotherside which has been salvaged by me
for this reason.
There's already #886810 filed against yubioath-desktop but it seems
that it currently doestn't have any active maintainers.

Regards
Felix

Bug#923633: can appstream-util be marked Multi-Arch: foreign?

[Helmut Grohne]

Package: appstream-util
Version: 0.7.14-1
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:gnome-power-manager

gnome-power-manager fails to cross build from source, because it fails
running appstream-util with an Exec format error. Usually, that
indicates that appstream-util was installed for the host architecture
when it was needed for the build architecture. There are multiple ways
to achieve that and one of them is marking appstream-util Multi-Arch:
foreign. Whenever that is the right thing to do, it is preferred.

The interesting question is whether doing so is correct. Multi-Arch:
foreign says that the interface of the package is independent of the
package architecture. Since appstream-util primarily contains programs,
this is at least possible. The manual pages are not very helpful for
finding out what these programs do however. It seems that part of their
job is dealing with XML, which is a textual (and thus
architecture-independent) format. What the other formats are is unclear
to me.

Thus I seek your help with understanding what appstream-util does and
whether we can mark it. Do you know any invocation where the observable
behaviour varies with the architecture of the appstream-util package?

Thanks for your help

Helmut

Bug#923626: debhelper: CFLAGS variable doesn't pass to configure script

[Niels Thykier]

On Sun, 03 Mar 2019 06:08:33 +0300 "Arthur D."  wrote:
> Package: debhelper
> Version: 10.2.5
> Severity: normal
> 
> Dear Maintainer,
> 

Hi,

Thanks for filing the report.

Unfortunately, we cannot solve the root cause at the moment, so I will
have to point you to a "work around".

In Debian packages using dh, you can use the DEB__APPEND and
DEB__STRIP flags to control the value of the  (where 
is CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, etc.).  Mind you, you will have
to *export* those variables.

So you would  use something like:

"""
ifeq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
DEB_CPPFLAGS_APPEND += -DG_DEBUG_DISABLE
else
DEB_CFLAGS_APPEND += -O0
endif

export DEB_CPPFLAGS_APPEND
export DEB_CFLAGS_APPEND
"""

(Here I have been "pedantic" and put the -DG_DEBUG_DISABLE in CPPFLAGS
because it looks like an option for the C Pre-processor; though that
assumes the upstream build system respects CPPFLAGS and handles it
correctly)

> * What led up to the situation?
> 
>   I've written simple debian/rules and added some conditional CFLAGS+=
>   statements. After I ran dpkg-buildpackage I found the flags were not
>   in place.
> 

I suspect you would have seen them if you had exported CFLAGS.  But it
would have neutered all the default flags.

The difference occurs inside an override target because it is a
recursive call to make and the Debian default CFLAGS is already exported
here (making your change to it visible to dh_auto_configure).

> [...]
> 
> I'm not sure why, but with this override_dh_auto_configure it works.
> It's probably needed to document this behaviour or fix it shomehow.
> 
> [...]

Can you tell a bit about where you expected this to be documented?  I.e.
where would you have found it if it had been documented?

Thanks,
~Niels

Bug#923631: reportbug: Crashes when filing a cruft RM request for a non-existent package (after confirmed that the user intended for it to be unknown)

[Niels Thykier]

Package: reportbug
Version: 7.5.2
Severity: minor

Hi,

I can reproduce a crash in reportbug when asking to file a bug against
ftp.debian.org asking to remove a non-existent package (e.g. if you
list multiple binaries or cheat an use "-*").

Just before the crash, reportbug asks you to confirm that the
non-existant package is deliberate and that we should continue anyway.

Below is an example flow with the crash.

"""
$ reportbug ftp.debian.org
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'Niels Thykier ' as your from address.
Will send report to Debian (per lsb_release).
What sort of request is this? (If none of these things mean anything to you, or 
you are trying to report a bug in an existing package, please press Enter to 
exit
reportbug.)

 1 ANAIS Package removal - Architecture Not Allowed In Source.
 2 ICE   Package removal - Internal Compiler Error.
 3 NBS   Package removal - Not Built [by] Source.
 4 NPOASRPackage removal - Never Part Of A Stable Release.
 5 NVIU  Package removal - Newer Version In Unstable.
 6 ROM   Package removal - Request Of Maintainer.
 7 ROP   Package removal - Request of Porter.
 8 RoQA  Package removal - Requested by the QA team.
 9 other Not a package removal request, report other problems.
10 override  Change override request.

Choose the request type: 3
Please enter the name of the package (either source of binary package): foo
Checking status database...
W: Unable to locate package foo
This package doesn't appear to exist; continue? [y|N|?]? y
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2285, in 
main()
  File "/usr/bin/reportbug", line 1115, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1705, in user_interface
self.options.http_proxy)
  File "/usr/bin/reportbug", line 543, in special_prompts
return pkgprompts(package, bts, ui, fromaddr, timeout, online, http_proxy)
  File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 265, in 
handle_debian_ftp
section, priority = info[16], info[10]
IndexError: list index out of range
"""

Thanks,
~Niels

Bug#923630: RFP: node-eslint-plugin-react -- React specific linting rules for ESLint

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-eslint-plugin-react
  Version : 7.9.1
  Upstream Author : Yannick Croissant 
* URL : 
https://notabug.org/makenotabuggreatagain/eslint-plugin-react
* License : MIT
  Programming Lang: javascript
  Description : React specific linting rules for ESLint

React is a popular javascript UI library.  It is currently in RFP/WNPP at 
#805376

Lint, or a linter, is a tool that analyzes source code to flag programming 
errors, 
bugs, stylistic errors, and suspicious constructs.

ESLint is a linter for ECMAScript, the javascript standard

This package is a plugin for exporting a recommended configuration that 
enforces 
React good practices.

It is a dependency of node-gulp-print ( #916097 )

Bug#923629: RM: ruby-rails-assets-chartjs -- ROM; replaced by node-chart.js, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of gitlab, which no longer require 
it. All packages depending on its binary libjs-chartjs switched to 
libjs-chart.js.

It is also affected by rc bug #922288 

No other reverse dependencies.




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

Bug#910035: disregard

[Jeffrey Cliff]

ah disregard that, I'm not set up for that by the looks (I'll work on
getting access to a sid box in the meanwhile), sorry for getting all
your hopes up
jeff

Bug#923628: RFS: pekka-kana-2/1.2.2-1 [ITP] -- 2D Oldschool platform game where you control a rooster

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "pekka-kana-2"

 * Package name: pekka-kana-2
   Version : 1.2.2-1
   Upstream Author : Janne Kivilahti (Piste Gamez) 
 * URL : https://pistegamez.net/game_pk2.html
 * License : BSD-2-Clause
   Section : games

  It builds those binary packages:

  pekka-kana-2 - 2D Oldschool platform game where you control a rooster
  pekka-kana-2-data - 2D Oldschool platform game where you control a rooster 
(data file)

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

  https://mentors.debian.net/package/pekka-kana-2

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pekka-kana-2/pekka-kana-2_1.2.2-1.dsc

  More information about pekka-kana-2 can be obtained from 
https://gitlab.com/coringao/pekka-kana-2.

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#923627: antennavis FTCBFS: many reasons

[Helmut Grohne]

Source: antennavis
Version: 0.3.1-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

antennavis fails to cross build from source. It starts with not passing
--host to ./configure and thus performing a native build.
dh_auto_configure fixes that. Then, it fails to propagate the compiler
detected by ./configure to the Makefile. Further down, the Makefile's
install stage does not honour INSTALL_PROGRAM and strips unconditionally
- with the wrong strip. It is best to not strip at all during make
install as doing otherwise breaks generation of -dbgsym packages in
addition to breaking cross building. The attached patch fixes all of
that. Please consider applying it.

Helmut
diff --minimal -Nru antennavis-0.3.1/debian/changelog 
antennavis-0.3.1/debian/changelog
--- antennavis-0.3.1/debian/changelog   2015-06-27 17:54:02.0 +0200
+++ antennavis-0.3.1/debian/changelog   2019-03-03 06:12:49.0 +0100
@@ -1,3 +1,14 @@
+antennavis (0.3.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_configure pass --host to ./configure.
++ cross.patch: Propagate CC from configure to make.
++ cross.patch: Honour INSTALL_PROGRAM.
++ Defer all stripping to dh_strip.
+
+ -- Helmut Grohne   Sun, 03 Mar 2019 06:12:49 +0100
+
 antennavis (0.3.1-4) unstable; urgency=medium
 
   * Fix rotational symmetry bug. Thanks Bohumir Jelinek
diff --minimal -Nru antennavis-0.3.1/debian/patches/cross.patch 
antennavis-0.3.1/debian/patches/cross.patch
--- antennavis-0.3.1/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ antennavis-0.3.1/debian/patches/cross.patch 2019-03-03 06:12:49.0 
+0100
@@ -0,0 +1,31 @@
+--- antennavis-0.3.1.orig/Makefile.in
 antennavis-0.3.1/Makefile.in
+@@ -26,10 +26,12 @@
+ ## Please do not edit "makefile", as it is auto-generated
+ ## by ./configure from makefile.in  Edit makefile.in instead.
+ ##
++CC := @CC@
+ CFLAGS := @CFLAGS@
+ CPPFLAGS := @CPPFLAGS@
+ LIBS := @LIBS@ -lX11 -lm
+ LDFLAGS := @LDFLAGS@
++INSTALL_PROGRAM ?= install
+ 
+ prefix = @prefix@
+ exec_prefix = @exec_prefix@
+@@ -86,11 +88,11 @@
+   autoconf
+ 
+ install: TkAnt
+-  install -s TkAnt $(bindir)
+-  install antenna.tcl $(bindir)/antennavis
++  $(INSTALL_PROGRAM) -s TkAnt $(bindir)
++  $(INSTALL_PROGRAM) antenna.tcl $(bindir)/antennavis
+   mkdir -p $(mandir)/man1
+-  install -m 0644 antennavis.1 $(mandir)/man1
+-  install -m 0644 TkAnt.1 $(mandir)/man1
++  $(INSTALL_PROGRAM) -m 0644 antennavis.1 $(mandir)/man1
++  $(INSTALL_PROGRAM) -m 0644 TkAnt.1 $(mandir)/man1
+ 
+ uninstall:
+   -rm -f $(bindir)/TkAnt
diff --minimal -Nru antennavis-0.3.1/debian/patches/series 
antennavis-0.3.1/debian/patches/series
--- antennavis-0.3.1/debian/patches/series  2015-06-27 17:53:34.0 
+0200
+++ antennavis-0.3.1/debian/patches/series  2019-03-03 06:12:49.0 
+0100
@@ -1,3 +1,4 @@
 00binutils-gold.patch
 01configure-ac.patch
 02rotational_symmetry.patch
+cross.patch
diff --minimal -Nru antennavis-0.3.1/debian/rules antennavis-0.3.1/debian/rules
--- antennavis-0.3.1/debian/rules   2013-10-06 13:43:32.0 +0200
+++ antennavis-0.3.1/debian/rules   2019-03-03 06:12:49.0 +0100
@@ -14,22 +14,18 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -g
-INSTALL_PROGRAM = install
 
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
 else
CFLAGS += -O2
 endif
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   INSTALL_PROGRAM += -s
-endif
 
 configure: configure-stamp
 configure-stamp:
dh_testdir
# Add here commands to configure the package.
-   CFLAGS="$(CFLAGS)" ./configure --prefix=/usr --mandir=/usr/share/man
+   CFLAGS="$(CFLAGS)" dh_auto_configure
touch configure-stamp
 
 build: build-arch build-indep
@@ -60,9 +56,8 @@
dh_testroot
 #  dh_clean -k 
dh_installdirs 
-   echo $(INSTALL_PROGRAM)
# Add here commands to install the package into debian/antennavis.
-   $(MAKE) INSTALL_PROGRAM="$(INSTALL_PROGRAM)" 
prefix=$(CURDIR)/debian/antennavis/usr \
+   $(MAKE) INSTALL_PROGRAM='install --strip-program=true' 
prefix=$(CURDIR)/debian/antennavis/usr \
mandir=$(CURDIR)/debian/antennavis/usr/share/man  install
 
 

Bug#923532: cups-bsd: spool directory fills up

[Helge Kreutzmann]

Hello Brian,
On Sat, Mar 02, 2019 at 01:14:29PM +, Brian Potkin wrote:
> Thank you for your report, Helge.

Thanks for the quick reply.

> On Fri 01 Mar 2019 at 15:30:48 +0100, Helge Kreutzmann wrote:
> > By chance I noted that the spool directory fills up over time,
> > currently:
> > root@samd:/var/spool/cups# lpq -a
> > Keine Einträge
> > root@samd:/var/spool/cups# du -hs .
> > 166M.
> > root@samd:/var/spool/cups# ls -lh | wc -l
> > 621
> > 
> > The oldest files are from 2017. There are two types of file, some
> > short text files which seem to describe the print job and pdf and
> > postscript files, which appear to be the print jobs themselves.
> 
> c (control or history) files and d (document) files. They should get
> cleared with 'cancel -a -x' but might need to be removed with 'rm'.

Thanks for the pointer. I usually use "lprm" and always thought that
removing a job also removes all spool files. I did not know about the
command cancel, whose name does not lead to beeing printing specific
(neither starts with cups nor with lp).

Do you think implying "-x" with with lprm would be a worthwile
wishlist bug for upstream?

> > Some files / queues on my system do not print 
> > so I have to abort the jobs with lprm. If these files are really
> > (only) this use case I don't know.
> > 
> > If I should run some tests (I currently have an unprintable file at
> > hand) please tell me.
> > 
> > As a band aid a cron job could be added which deletes files there
> > older let's say than a week.
> 
> cupsd.conf(5) explains the PreserveJobFiles and PreserveJobHistory
> directives. If you put "PreserveJobFiles 30" in cupsd.conf, does it
> work for you?

Neither are currently explicitly set. But the man page says that
PreserveJobFiles has a default value of 1 day and PreserveJobHistory
is yes. Maybe PreserveJobFiles only applies to sucessfully printed
jobs?

> You may, of course, alter the default PreserveJobHistory value too
> but are then likely to hit Bug#921741. Knowing how much of Emin Kaya's
> issue you can replicate would be useful.

Just to be clear: I should first try out PreserveJobHistory? And after
a day all spool files should be gone (if it works)?

Greetings

   Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#914794: libmspack fails tests on big endian architectures (s390x, mips)

[duck]

Quack,

On 2018-12-04 19:02, Stuart Caie wrote:


This is fixed in the repository, it just hasn't been released. I'll
release it in the near future.


I was myself busy and we missed the Debian freeze deadline. Maybe there 
is still some hope to convince the release team for an exception, as 
long as we push fixes only. Any plan to release shortly?


\_o<

--
Marc Dequènes

Bug#780706: progress elsewhere

[Kashif Shah]

Hi All,

Great to see all the progress being made over in salsa.  I sent a request
to join the project as I can do some testing and possibly some bug fixing /
maintenance help.

Have you all seen https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923220
?  The reported provided a script to automatically create a .deb package
from the .tar.xz on arduino.cc

Best regards,
Kashif

On Wed, 21 Mar 2018 17:06:01 +0100 Geert Stappers 
wrote:
> On Wed, Mar 21, 2018 at 12:27:15PM -0300, Ignacio Losiggio wrote:
> > Before all this work i need to get running the package. I've forgot
that i
> > was removing unused files before building (macos/windows support). I
know
> > that having this in the debian/rules is really hackish.
> > What's the correct way of removing a file from upstream? (compiling them
> > generates unneeded dependencies and over-complicates the packaging).
>
> Seen the good question.
> Further follow-up will be outside this bugreport.
>
>
> Cheers
> Geer Stappers
> Who never told before that he uses the BR for status updates
>
>

Bug#923220: ITP: arduino-package -- Utility for creating Arduino Debian packages

[Kashif Shah]

Hello Phillip,

For what it is worth, I was able to clone from your git repo, build the
application, and create a .deb for Arduino IDE 1.8.8 without issue.

Is there any chance that you could import that repo into salsa.debian.org
so that the folks at https://salsa.debian.org/electronics-team/arduino can
take a look?

Best regards,
Kashif

On Mon, 25 Feb 2019 16:18:30 +0100 Philipp Meisberger 
wrote:
> Hello Carsten,
>
> as I see the arduino-builder is for a completely different task.
> arduino-package is for downloading Arduino IDE as ZIP file and
> automatically building a Debian package (very similar to java-package).
>
> I try to contact the maintainers of arduino-builder.
>
> Regards,
> Philipp
> Am 25.02.19 um 11:59 schrieb Carsten Schoenert:
> > Hello Phillip,
> >
> > Am 25.02.19 um 09:12 schrieb Philipp Meisberger:
> >> Package: wnpp
> >> Severity: wishlist
> >> Owner: Philipp Meisberger 
> >>
> >> * Package name: arduino-package
> >>   Version : 1.0
> >>   Upstream Author : Philipp Meisberger 
> >> * URL :
https://github.com/philippmeisberger/arduino-package
> >> * License : D-FSL
> >>   Programming Lang: Shell
> >>   Description : Utility for creating Arduino Debian packages
> >>
> >> This package provides the capability to build a Debian package from
> >> an Arduino binary distribution by running make-arduinopkg  >> archive file>. Download the archive file from https://www.arduino.cc
> >>
> >> This package is a good addition to Debian since there seems no such
> >> application. I often use it. The package is no dependency for other
> >> packages. I am looking for a sponsor.
> > there exists already a package arduino-builder within the Electronics
> > team which does mostly the same as you probably intended to solve by
> > your package.
> >
> > https://salsa.debian.org/electronics-team/arduino/arduino-builder
> >
> > I suggest to get in contact with the people which do currently
> > maintaining this existing package.
> >
>

Bug#896844: Please consider fixing #896844

[Manilone Mike]

Dear maintainer,

I'm extremely frustrated after upgrading to buster only to find preview
doesn't work anymore. I spent some time searching the Internet and
reached here. I understand you might be busy these days, but I do hope
you can consider fixing this bug and make it to buster.

Thanks!

Bug#923626: debhelper: CFLAGS variable doesn't pass to configure script

[Arthur D.]

Package: debhelper
Version: 10.2.5
Severity: normal

Dear Maintainer,

   * What led up to the situation?

 I've written simple debian/rules and added some conditional CFLAGS+=
 statements. After I ran dpkg-buildpackage I found the flags were not
 in place.

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

 I've written debian/rules file, ran dpkg-buildpackage two times:
 1) dpkg-buildpackage -b
 2) DEB_BUILD_OPTIONS=debug dpkg-buildpackage -b

   * What was the outcome of this action?

 CFLAGS value of Makefile was the same for both cases, so the
 package was built without CFLAGS pointed by debian/rules file.

   * What outcome did you expect instead?

 Makefile's CFLAGS value should honor the value from debian/rules

The contents of debian/rules:
#!/usr/bin/make -f
%:
dh $@

ifeq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -DG_DEBUG_DISABLE
else
CFLAGS += -O0
endif

To resolve the issue, I've written another debian/rules, which works
fine. Its contents:
#!/usr/bin/make -f
%:
dh $@

override_dh_auto_configure:
dh_auto_configure

ifeq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -DG_DEBUG_DISABLE
else
CFLAGS += -O0
endif

I'm not sure why, but with this override_dh_auto_configure it works.
It's probably needed to document this behaviour or fix it shomehow.

-- System Information:
Debian Release: 9.8
  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=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8),  
LANGUAGE=ru_RU:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.28-5
ii  dh-autoreconf14
ii  dh-strip-nondeterminism  0.034-1
ii  dpkg 1.18.25
ii  dpkg-dev 1.18.25
ii  file 1:5.30-1+deb9u2
ii  libdpkg-perl 1.18.25
ii  man-db   2.7.6.1-2
ii  perl 5.24.1-3+deb9u5
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information

Bug#923625: gsequencer: please update to latest version v2.1.64

[Joël Krähemann]

Source: gsequencer
Severity: wishlist

Dear Maintainer,

Please update to latest GSequencer version 2.1.64. Introduced changes
are described on debian multimedia mailing list:

https://lists.debian.org/debian-multimedia/2019/03/msg7.html

Version 2.1.64 was just merged to master then created a new branch
2.2.x of it. I as upstream expect that versioning is straight forward.

But in debian is still version 2.1.53 published. Further I wish latest
improvements and bug-fixes are included in debian.


by Joël Krähemann


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

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

Bug#923423: dpkg: Hangs for 19 mins installing texlive-fonts-extra

[Vincent Lefevre]

On 2019-03-03 00:15:13 +0100, Guillem Jover wrote:
> Did this start happening due to the new kernel version?

In March 2018, this was already slow, but much less:

[...]
2018-03-08 00:55:55 status unpacked texlive-fonts-extra:all 2017.20180225-1
2018-03-08 00:55:55 status half-installed texlive-fonts-extra:all 
2017.20180225-1
2018-03-08 01:02:55 status half-installed texlive-fonts-extra:all 
2017.20180225-1
2018-03-08 01:02:56 status unpacked texlive-fonts-extra:all 2017.20180305-2
2018-03-08 01:02:56 status unpacked texlive-fonts-extra:all 2017.20180305-2
[...]

I don't have older information.

> What filesystem are you using (say btrfs or similar?),

mount information:

/dev/mapper/zira--vg-root on / type ext4 (rw,relatime,errors=remount-ro)

> etc, can you reproduce on another system? I certainly can't. :)

No, on two of my other machines, it takes around 1 minute
(both for old and new versions). I assume that this is what
is expected.

> I guess attaching strace to the running dpkg might also give some more
> info on what's going on, or where it's stalling. Also if you can
> simply reproduce via «dpkg -i», then enabling all dpkg debug flags
> might also help.

With

  dpkg -i /var/cache/apt/archives/texlive-fonts-extra_2018.20190227-1_all.deb

GKrellM shows full disk activity for a bit less than 2 minutes, then
no activity, but dpkg is still running. Attaching strace against it
during this time shows lots of rename's:

[...]
rename("/usr/share/texlive/texmf-dist/fonts/tfm/arkandis/berenisadf/ybdr2cijw8y.tfm.dpkg-new",
 "/usr/share/texlive/texmf-dist/fonts/tfm/arkandis/berenisadf/ybdr2cijw8y.tfm") 
= 0
openat(AT_FDCWD, 
"/usr/share/texlive/texmf-dist/fonts/tfm/arkandis/berenisadf/ybdr2ciw8y.tfm.dpkg-new",
 O_WRONLY) = 11
fsync(11)   = 0
close(11)   = 0
rename("/usr/share/texlive/texmf-dist/fonts/tfm/arkandis/berenisadf/ybdr2ciw8y.tfm.dpkg-new",
 "/usr/share/texlive/texmf-dist/fonts/tfm/arkandis/berenisadf/ybdr2ciw8y.tfm") 
= 0
openat(AT_FDCWD, 
"/usr/share/texlive/texmf-dist/fonts/tfm/arkandis/berenisadf/ybdr2cj8c.tfm.dpkg-new",
 O_WRONLY) = 11
fsync(11)   = 0
close(11)   = 0
rename("/usr/share/texlive/texmf-dist/fonts/tfm/arkandis/berenisadf/ybdr2cj8c.tfm.dpkg-new",
 "/usr/share/texlive/texmf-dist/fonts/tfm/arkandis/berenisadf/ybdr2cj8c.tfm") = 0
openat(AT_FDCWD, 
"/usr/share/texlive/texmf-dist/fonts/tfm/arkandis/berenisadf/ybdr2cj8t.tfm.dpkg-new",
 O_WRONLY) = 11
fsync(11)   = 0
close(11)   = 0
[...]

> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable-debug
> >   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> > 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 4.19.0-3-amd64 (SMP w/8 CPU cores)
> > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> > TAINT_UNSIGNED_MODULE
> > Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
> > (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> 
> I see the kernel is tainted. Perhaps try to unload those and see? :)

That's the NVIDIA drivers (because nouveau is too broken).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#920462: libgl1-mesa-dri 18.3.2 breaks certain proprietary steam games

[Fanael Linithien]

I can confirm that mesa 18.3.4-2 fixes the issue.

Bug#919597: Acknowledgement (want gdr import-from-bare-debian)

[Sean Whitton]

Hello,

On Thu 17 Jan 2019 at 07:26PM +00, Ian Jackson wrote:

> Control: retitle -1 want gdr convert-from-bare-debian
>
> I have a preliminary implementation.
>
> A difficulty arises: the other convert-from-unapplied commands which
> consume an upstream commitish check that the upstream commitish makes
> sense: specifically, that it corresponds to HEAD.  With bare-debian
> packaging branches this is not possible.
>
> I can't think of anything sensible to do instead, so I propose to just
> skip that check in this case.
>
> I will check that the tree is indeed a bare-debian repo, ie that it
> has no files outside debian/.  If there are any I will treat it as a
> snag (and with -f delete them in favour of whatever the upstream tree
> has).

SGTM.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#890878: RFS: company-irony

[Nicholas D Steeves]

Hi Alberto,

It's been a long time without a reply to this RFS.  Would you please
provide a status update?

Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#908216: btrfs blocked for more than 120 seconds

[Nicholas D Steeves]

On Sat, Mar 02, 2019 at 05:12:42PM -0600, Russell Mosemann wrote:
>I used btrfs-progs (4.17-1~bpo9+1) from the backports repository, which
>does have zstd support. btrfs-check does need zstd support. Otherwise, it
>will error out with unsupported feature (10).
> 

Unfortunately official 4.17-1~bpo9+1 does not, because Zstd support
wasn't enabled in Debian's btrfs-progs until 4.19.1-2; however, kernel
support for zstd+btrfs first appeared in linux-4.14.

wget
http://ftp.debian.org/debian/pool/main/b/btrfs-progs/btrfs-progs_4.17-1~bpo9+1+b1_amd64.deb
mkdir unpacked && cd unpacked
dpkg -x ../btrfs-progs_4.17-1~bpo9+1+b1_amd64.deb .
ldd bin/btrfs

linux-vdso.so.1 (0x7ffc6abea000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7ff58fe6)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 
(0x7ff58fc1a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ff58fa0)
liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x7ff58f7de000)
#If libzstd.so.1 was linked in it would appear here.
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7ff58f5c1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ff58f222000)
/lib64/ld-linux-x86-64.so.2 (0x7ff59031d000)


Looking forward to the isolated writer test results!
Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#857490: [PATCH] dgit-maint-bpo(7): new manpage

[Sean Whitton]

control: tag 857490 +patch

Hello,

On Sun 06 Jan 2019 at 01:07PM +00, Ian Jackson wrote:

>> I also think that dgit could emit a recommendation to look at that
>> manpage in the kind of case that prompted me to file this bug.  It can
>> just look for ~bpoNN in the version number that is missing from
>> d/changelog, and output a hint.
>
> Are you volunteering to write the (7) manpage ? :-)

Here is a patch.

This does not completely resolve #898494, as I haven't modified dgit to
output the hint to look at the manpage.

-- 
Sean Whitton
From 3d3e6c7cf5448ae1c1dd74f1c18ea08ae514a9b6 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sat, 2 Mar 2019 17:53:39 -0700
Subject: [PATCH] dgit-maint-bpo(7): new manpage

Signed-off-by: Sean Whitton 
---
 Makefile |   3 +-
 dgit-maint-bpo.7.pod | 133 +++
 2 files changed, 135 insertions(+), 1 deletion(-)
 create mode 100644 dgit-maint-bpo.7.pod

diff --git a/Makefile b/Makefile
index 7d0c422f..3fce578c 100644
--- a/Makefile
+++ b/Makefile
@@ -42,7 +42,8 @@ MAN7PAGES=dgit.7\
 	dgit-maint-merge.7 dgit-maint-gbp.7	\
 	dgit-maint-debrebase.7  \
 	dgit-downstream-dsc.7			\
-	dgit-sponsorship.7
+	dgit-sponsorship.7			\
+	dgit-maint-bpo.7
 
 TXTDOCS=README.dsc-import
 PERLMODULES= \
diff --git a/dgit-maint-bpo.7.pod b/dgit-maint-bpo.7.pod
new file mode 100644
index ..ff879a45
--- /dev/null
+++ b/dgit-maint-bpo.7.pod
@@ -0,0 +1,133 @@
+=head1 NAME
+
+dgit - tips for maintaining official Debian backports
+
+=head1 INTRODUCTION
+
+This document describes elements of a workflow for using B to
+maintain an official Debian backport.  We do not assume that whoever
+uploads the package to Debian unstable is using B.
+
+=head1 TERMINOLOGY
+
+Let the I branch contain the packaging history uploaded to
+Debian unstable, and the I branch be where you prepare
+your uploads to the B suite.
+
+A B backports workflow means that each time an upload
+migrates to Debian testing and you want to prepare an upload to
+B, you do something like this:
+
+=over 4
+
+% git checkout buster-bpo
+% git merge master
+% dch --bpo
+% # any other changes needed for backporting
+% git commit -a
+% # try a build
+
+=back
+
+A B backports workflow means that you throw away the history
+of the I branch each time a new version migrates to Debian
+testing, something equivalent to this:
+
+=over 4
+
+% git checkout -B buster-bpo master
+% dch --bpo
+% # any other changes needed for backporting
+% git commit -a
+% # try a build
+
+=back
+
+If you use a merging backports workflow, your changelog contains
+entries for each previous upload to B; in a rebasing
+workflow, it contains only the latest.
+
+Whether you use a merging or rebasing backports workflow is, so far as
+the author of this manpage can tell, simply a matter of personal
+preference.  There are good arguments in favour of both workflows
+fitting the semantics of the B<*-backports> suites.
+
+=head1 TIPS FOR A MERGING WORKFLOW
+
+=head2 Use dgit's branches
+
+If you do not yourself upload the package to Debian unstable, it is
+usually easiest to use dgit's branches, and ignore the configured
+Vcs-Git repository.
+
+You would use
+
+=over 4
+
+% dgit clone foo bullseye
+
+=back
+
+for a new backport of package 'foo' to B, and then
+
+=over 4
+
+% dgit fetch bullseye
+% git merge dgit/dgit/bullseye
+
+=back
+
+when new versions migrate to Debian testing.
+
+=head1 TIPS FOR A REBASING WORKFLOW
+
+=head2 Use dgit's branches
+
+If you do not yourself upload the package to Debian unstable, it is
+usually easiest to use dgit's branches, and ignore the configured
+Vcs-Git repository.  For each new version from Debian testing, you
+would
+
+=over 4
+
+% dgit fetch bullseye
+% git checkout -B buster-bpo dgit/dgit/bullseye
+
+=back
+
+=head2 Overwriting
+
+B tries hard to prevent you from accidentally overwriting
+uploads that it thinks aren't represented in the git history you are
+trying to upload.  This is mainly to prevent accidentally overwriting
+NMUs.
+
+With a rebasing backports workflow, dgit will think that every upload
+of a new version from Debian testing might be accidentally overwriting
+uploads.  You will need to explicitly indicate the upload to
+B you wish to overwrite.
+
+Suppose that the last upload to B was versioned
+I<1.2.2-1~bpo10+1> and you have now prepared I<1.2.3-1~bpo10+1> for
+upload.  When you B, you will need to pass
+I<--overwrite=1.2.2-1~bpo10+1>.
+
+Alternatively, you can perform the pseudomerge that I<--overwrite>
+would have done yourself:
+
+=over 4
+
+% dgit fetch buster-backports
+% git merge -s ours dgit/dgit/buster-backports
+% dgit push-source
+
+=back
+
+=head1 SEE ALSO
+
+dgit(1), dgit(7), https://backports.debian.org/
+
+=head1 AUTHOR
+
+This manpage was written and is maintained by Sean Whitton
+.
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#923624: mandoc_char.7: "left" and "right" prefixes got mixed up

[Bjarni Ingi Gislason]

Package: mandoc
Version: 1.14.4-1
Severity: minor
Tags: patch

Dear Maintainer,

  the names of the strings '\*(lp' and '\*(rp' got interchanged.


--- mandoc_char.7   2018-08-08 14:51:51.0 +
+++ mandoc_char.new.7   2019-03-03 00:40:34.0 +
@@ -728,8 +728,8 @@ manual.
 .It \e*q Ta \*q Ta double-quote
 .It \e*(Rq   Ta \*(Rq   Ta right-double-quote
 .It \e*(Lq   Ta \*(Lq   Ta left-double-quote
-.It \e*(lp   Ta \*(lp   Ta right-parenthesis
-.It \e*(rp   Ta \*(rp   Ta left-parenthesis
+.It \e*(lp   Ta \*(lp   Ta left-parenthesis
+.It \e*(rp   Ta \*(rp   Ta right-parenthesis
 .It \e*(lq   Ta \*(lq   Ta left double-quote
 .It \e*(rq   Ta \*(rq   Ta right double-quote
 .It \e*(ua   Ta \*(ua   Ta up arrow

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

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

Versions of packages mandoc depends on:
ii  libc6   2.28-7
ii  zlib1g  1:1.2.11.dfsg-1

mandoc recommends no packages.

mandoc suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason

Bug#923623: jobs run from .bash_profile are appended to the wrong sub-tree

[積丹尼 Dan Jacobson]

Package: psmisc
Version: 23.2-1
File: /usr/bin/pstree

$ pstree -al
systemd
  |-nodm
  |   |-Xorg :0 -nolisten tcp vt7
  |   |   `-{Xorg}
  |   `-nodm
  |   `-bash /home/jidanni/.xsession
  |   |-bash /home/jidanni/.xsession
  |   |   `-sleep 4m
  |   |-icewm-session
  |   |   |-icewm --notify
  |   |   `-icewmbg
  |   `-ssh-agent /bin/bash /home/jidanni/.xsession

In reality nodm/icewm or whatever starts bash.
$ grep 4m .bash_profile
(cd ~/.icewm && sleep 4m && make -s preferences)&
And...
$ grep icew .xsession
icewm-session &

Well whatever. Anyways, sleep 4m is appended to the wrong sub-tree.

Bug#923476: webkit2gtk: FTBFS for unknown reasons (maybe Makefile bug)

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=195251

On Fri, Mar 01, 2019 at 10:32:40AM +0100, Santiago Vila wrote:

> > Thanks. Does it fail all the time then?
> 
> In my environment, yes. It failed every time I tried with each new
> Debian release since 2.22.0-2.

I confirm that it fails with make -j1, it seems that there's indeed no
rule to make JavaScriptCore-4.0.gir.

'make JavaScriptCore-4-gir' does work, so I suspect that there's a
missing/wrong rule in the CMake files.

Berto

Bug#923448: stunnel4: autopkgtest fails with new version of openssl: failed to set DH parameters at debian/tests/runtime line 295.

[gregor herrmann]

On Sat, 02 Mar 2019 22:47:44 +0200, Peter Pentchev wrote:

> I've fixed the problem in my Git repository for stunnel4; I shall upload
> it in a little while after some more testing.  I'll try to also change
> the libanyevent-perl default today.

Thanks for fixing both packages!

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#923619: coreutils: FTBFS on hppa - Unknown error 252

[John David Anglin]

On 2019-03-02 4:55 p.m., John David Anglin wrote:
> On 2019-03-02 4:22 p.m., Michael Stone wrote:
>> What happens if you rebuild -1?
> It fails in the same manner as -2 and -3.
The error doesn't occur if I do a simple "configure --prefix=somewhere", make 
and make install.

-- 
John David Anglin  dave.ang...@bell.net

Bug#923622: packaging-tutorial: Typo in Slide 49

[Leandro Pereira]

Package: packaging-tutorial
Version: 0.22
Severity: minor

Hi,

I'm a member of brazilian portuguese translation team and I have found a
typo in slide 49 where it says "Submit an ITP bug (Intend To Package) ..."
should be INTENT.

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#567071: what is the purpose of fstab-decode

[Jonathan de Boyne Pollard]

Dmitry Bogatov:
> Also, reference to fstab(5) and this particular paragraph may be useful:

Not as much as you would think.  The idiosyncratic encoding applies to 
more than just that 1 field, and encodes more than what is stated, but 
does not generalize to octal escaping as one might guess.

Bug#923423: dpkg: Hangs for 19 mins installing texlive-fonts-extra

[Guillem Jover]

Hi!

On Thu, 2019-02-28 at 01:06:28 +0100, Vincent Lefevre wrote:
> Package: texlive-fonts-extra
> Version: 2018.20190227-1
> Severity: serious

> Installation of texlive-fonts-extra 2018.20190227-1 hangs.

> 17m01s ago dpkg was started, at 2019-02-28T00:48:45+01:00.
> 1.5% has been its average CPU usage since then, or 15s/17m01s
> 
> Other processes started close to dpkg(5553):
>   [kworker/0:1-events](5351) was started 2m57s before dpkg(5553)
>   [kworker/u17:0-kcryptd](5540) was started 1.0s before dpkg(5553)
>   [kworker/4:2](5771) was started 2m19s after dpkg(5553)
>   [kworker/u16:1-events_unbound](5928) was started 4m21s after dpkg(5553)
>   [kworker/5:2-mm_percpu_wq](6068) was started 5m06s after dpkg(5553)

Thanks for all the info. This does look like a hardware or kernel
problem to me, though.

Did this start happening due to the new kernel version? What
filesystem are you using (say btrfs or similar?), etc, can you
reproduce on another system? I certainly can't. :)

I guess attaching strace to the running dpkg might also give some more
info on what's going on, or where it's stalling. Also if you can
simply reproduce via «dpkg -i», then enabling all dpkg debug flags
might also help.

> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-3-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

I see the kernel is tainted. Perhaps try to unload those and see? :)

> Versions of packages tex-common depends on:
> ii  dpkg  1.19.5

Thanks,
Guillem

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

I used btrfs-progs (4.17-1~bpo9+1) from the backports repository, which does 
have zstd support. btrfs-check does need zstd support. Otherwise, it will error 
out with unsupported feature (10).
 
--
Russell Mosemann

-Original Message-
From: "Nicholas D Steeves" 
Sent: Saturday, March 2, 2019 3:59pm
To: "Russell Mosemann" , 908...@bugs.debian.org
Subject: Re: Bug#908216: btrfs blocked for more than 120 seconds



Hi Russell,

The backport of btrfs-progs is old and doesn't have libzstd support,
and I'm still waiting for a sponsor (#922951), but if you'd like to
give it a try before it hits the archive:

 dget 
https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.20.1-2~bpo9+1.dsc

 cd btrfs-progs-4.20.1/
 dpkg-buildpackage -us -uc # will require the installation of build-deps
 cd ../
 sudo dpkg -i btrfs-progs_4.20.1-2~bpo9+1_amd64.deb \
 btrfs-tools_4.20.1-2~bpo9+1_amd64.deb \
 libbtrfs0_4.20.1-2~bpo9+1_amd64.deb \
 libbtrfsutil1_4.20.1-2~bpo9+1_amd64.deb \
 python3-btrfsutil_4.20.1-2~bpo9+1_amd64.deb

I will confess that I don't know if btrfs-check actually needs libzstd
support to check fs structures, or if --check-data-csum requires it,
but if this bug is forwarded then upstream will ask if btrfs-check
found anything using a recent version of btrfs-progs.

On Tue, Feb 26, 2019 at 11:29:25AM -0600, Russell Mosemann wrote:
> On Monday, February 25, 2019 10:17pm, "Nicholas D Steeves"
>  said:
> 
> > On Mon, Feb 25, 2019 at 12:33:51PM -0600, Russell Mosemann wrote:
> >
> 
> In every case, the btrfs partition is used exclusively as an archive for
> backups. In no circumstance is a vm or something like a database run on
> the partition. Consequently, it is not possible for CoW on CoW to happen.
> The partition is simply storing files.
>
[snip]
> >
> > It might be that >4.17 fixed some corner-case corruption issue, for
> > example by adding an additional check during each step of a backref
> > walk, and that this makes the timeout more frequent and severe. eg:
> > 4.17 works because it is less strict.
> >
> > By the way, is it your VM host that locks up, or your VM guests? Do[es]
> > they[it] recover if you leave it alone for many hours? I didn't see
> > any oopses or panics in your kernel logs.
> 
> 
> 
> It is the host that locks up. This does not involve vm's in any way. If
> vm's are present, they are running on different drives. Some of the vm's
> even use btrfs partitions themselves. None of the vm's experience issues
> with their btrfs volumes. None of the vm's are affected by the hung btrfs
> tasks on the host. That is because the issue exclusively involves the
> separate, dedicated, archive partition used by the host. For all practical
> purposes, vm's aren't part of this picture.
>

Right. This simplifies things. So:

1) VM images and backup target are on different volumes on the same
host.
2) VM images are copied between volumes using "cp --reflink"
 * IIRC the VM images are stored on a btrfs volume, on the host?
3) Because this is an inter-volume copy, "cp --reflink=always vhost002.img
/megaraid/backup" should emit a warning or fail.
 * please confirm that it warns or fails.

I think you said that the following two things will also produce a hang?

 cp --reflink /megaraid/backup/vhost002.img /megaraid/vhost002.img.0 ?

or

 rm /megaraid/backup/vhost002.img.44 # oldest backup ?

Yes, Btrfs struggles with large sparse files...and these limitations
are amplified by the 45 reflinked copies, amplified when using
deduplication (I'm assuming you're not using this, btw), and amplified
by transparent compression. If this class of bugs is at fault, then
tests will fail at (5) (see below).

> As far as I am aware, a hung task does not recover, even after many hours.
> A number of times, it has hung at night. When I check in the morning hours
> later, it is still hung. In many cases, the server must be forcibly
> rebooted, because the hung task hangs the reboot process.
>

Back in the linux-3.16 to 4.4 days btrfs hung tasks were often
triggered by desktop databases such as those used by Thunderbird or
Firefox, and were quite common. My laptop always recovered after
about 15-20 minutes...

[snipped info on counting fragments and references]
> This is useful information, but it doesn't seem directly related to the
> hung tasks. The btrfs tasks hang when a file is being copied into the
> btrfs partition. No references or vm's are involved in that process. It is
> a simple file copy.
>

If the source volume is btrfs then it will have to do the complex
backref work when reading a VM.img. Because it's an intervolume cp,
and cp defaults to "--sparse=auto" /megaraid/VM.img should be written
sparsely, in one go, and reading from the resulting copy should not
have the overhead of reading from the master copy VM.img (the backup
copy should not replicate the fragmentation of the master copy when
copied in this way). This can be confirmed by comparing the filefrag
output for_each_VM.img to 

Bug#915370: Please drop anacron from task-desktop

[Laurent Bigonville]

On Mon, 03 Dec 2018 09:44:05 +0100 Michael Biebl  wrote:

Hello,

>
> anacron was added to the desktop-task a long time ago.
> The changelog doesn't mention why it was added, but I assume it was to
> support systems which are not running 24/7 and to ensure that cron jobs
> have a chance to run.
>
> Nowadays, we have systemd .timer units, which handle this issue much
> nicer. I checked a default desktop installation, and all important cron
> jobs have a corresponding .timer unit.
> It thus seems safe to drop anacron from task-desktop.
>

I'm actually wondering if this is a good idea..

There are lot of other packages installing cronjobs and people, I would 
assume, expect that they will run.


I would personally revert his patch as long as all the cronjobs have not 
a corresponding systemd .timer


Any thoughts?

Kind regards,

Laurent Bigonville

Bug#906016: transition: gjs built with mozjs60

[Simon McVittie]

On Tue, 05 Feb 2019 at 10:16:56 +, Simon McVittie wrote:
> > > * Require task-gnome-desktop to be installable on s390x, but modify
> > >   meta-gnome3 so that on s390x, gnome-core installs something that is not
> > >   the full GNOME 3 desktop used on other architectures, for example
> > >   the GNOME-2-derived gnome-session-flashback

In the absence of other progress, I've staged this in git. I'll release
it soon if nobody else in the team gets there first. The resulting
metapackage appears to be installable on a s390x buster qemu VM with only
sid as an apt source (so, only able to see the version of gjs in sid that
we want to migrate, and not the one in buster that we want to supersede).

On Fri, 08 Feb 2019 at 18:10:01 +0100, Emilio Pozuelo Monfort wrote:
> My worry if I were to do that is that the installer would still offer to 
> install
> GNOME on s390x, and I don't know what would happen if one chose that (I 
> suppose
> apt would realise it's uninstallable and give a proper error, but maybe things
> would explode).
> 
> So if we're going to make task-gnome-desktop uninstallable there, maybe the
> installer shouldn't offer to install it, and that needs changes somewhere in
> tasksel or d-i.

Some questions whose answers I think might be relevant to determining
how much effort is justifiable here:

* Do s390x users install with debian-installer?
* If so, do they install desktop tasks that way?
* Does GNOME (the desktop, as opposed to individual apps) work on s390x
  in earlier Debian releases? (If, as I suspect, the answer is "we don't
  know, nobody has tried it" then that is itself useful information.)

Regards,
smcv

Bug#923619: coreutils: FTBFS on hppa - Unknown error 252

[John David Anglin]

On 2019-03-02 4:22 p.m., Michael Stone wrote:
> What happens if you rebuild -1?
It fails in the same manner as -2 and -3.

I've cc'd Helge as he did ENOTSUP change.

-- 
John David Anglin  dave.ang...@bell.net

Bug#908216: btrfs blocked for more than 120 seconds

[Nicholas D Steeves]

Hi Russell,

The backport of btrfs-progs is old and doesn't have libzstd support,
and I'm still waiting for a sponsor (#922951), but if you'd like to
give it a try before it hits the archive:

  dget 
https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.20.1-2~bpo9+1.dsc

  cd btrfs-progs-4.20.1/
  dpkg-buildpackage -us -uc  # will require the installation of build-deps
  cd ../
  sudo dpkg -i btrfs-progs_4.20.1-2~bpo9+1_amd64.deb \
btrfs-tools_4.20.1-2~bpo9+1_amd64.deb \
libbtrfs0_4.20.1-2~bpo9+1_amd64.deb \
libbtrfsutil1_4.20.1-2~bpo9+1_amd64.deb \
python3-btrfsutil_4.20.1-2~bpo9+1_amd64.deb

I will confess that I don't know if btrfs-check actually needs libzstd
support to check fs structures, or if --check-data-csum requires it,
but if this bug is forwarded then upstream will ask if btrfs-check
found anything using a recent version of btrfs-progs.

On Tue, Feb 26, 2019 at 11:29:25AM -0600, Russell Mosemann wrote:
>On Monday, February 25, 2019 10:17pm, "Nicholas D Steeves"
> said:
> 
>> On Mon, Feb 25, 2019 at 12:33:51PM -0600, Russell Mosemann wrote:
>>
> 
>In every case, the btrfs partition is used exclusively as an archive for
>backups. In no circumstance is a vm or something like a database run on
>the partition. Consequently, it is not possible for CoW on CoW to happen.
>The partition is simply storing files.
>
[snip]
>>
>> It might be that >4.17 fixed some corner-case corruption issue, for
>> example by adding an additional check during each step of a backref
>> walk, and that this makes the timeout more frequent and severe. eg:
>> 4.17 works because it is less strict.
>>
>> By the way, is it your VM host that locks up, or your VM guests? Do[es]
>> they[it] recover if you leave it alone for many hours? I didn't see
>> any oopses or panics in your kernel logs.
> 
> 
> 
>It is the host that locks up. This does not involve vm's in any way. If
>vm's are present, they are running on different drives. Some of the vm's
>even use btrfs partitions themselves. None of the vm's experience issues
>with their btrfs volumes. None of the vm's are affected by the hung btrfs
>tasks on the host. That is because the issue exclusively involves the
>separate, dedicated, archive partition used by the host. For all practical
>purposes, vm's aren't part of this picture.
>

Right.  This simplifies things.  So:

1) VM images and backup target are on different volumes on the same
host.
2) VM images are copied between volumes using "cp --reflink"
  * IIRC the VM images are stored on a btrfs volume, on the host?
3) Because this is an inter-volume copy, "cp --reflink=always vhost002.img
/megaraid/backup" should emit a warning or fail.
  * please confirm that it warns or fails.

I think you said that the following two things will also produce a hang?

  cp --reflink /megaraid/backup/vhost002.img /megaraid/vhost002.img.0 ?

or

   rm /megaraid/backup/vhost002.img.44 # oldest backup ?

Yes, Btrfs struggles with large sparse files...and these limitations
are amplified by the 45 reflinked copies, amplified when using
deduplication (I'm assuming you're not using this, btw), and amplified
by transparent compression.  If this class of bugs is at fault, then
tests will fail at (5) (see below).

>As far as I am aware, a hung task does not recover, even after many hours.
>A number of times, it has hung at night. When I check in the morning hours
>later, it is still hung. In many cases, the server must be forcibly
>rebooted, because the hung task hangs the reboot process.
>

Back in the linux-3.16 to 4.4 days btrfs hung tasks were often
triggered by desktop databases such as those used by Thunderbird or
Firefox, and were quite common.  My laptop always recovered after
about 15-20 minutes...

[snipped info on counting fragments and references]
>This is useful information, but it doesn't seem directly related to the
>hung tasks. The btrfs tasks hang when a file is being copied into the
>btrfs partition. No references or vm's are involved in that process. It is
>a simple file copy.
>

If the source volume is btrfs then it will have to do the complex
backref work when reading a VM.img.  Because it's an intervolume cp,
and cp defaults to "--sparse=auto" /megaraid/VM.img should be written
sparsely, in one go, and reading from the resulting copy should not
have the overhead of reading from the master copy VM.img (the backup
copy should not replicate the fragmentation of the master copy when
copied in this way).  This can be confirmed by comparing the filefrag
output for_each_VM.img to for_each_backup_copy.img

>> > using compression: Yes, compress-force=zstd
>> >
>>
>> If userspace CPU usage is already high then compression may introduce
>> additional latency and contribute to the >120sec warning.
> 
>There is more than plenty CPU. Depending on the server, 

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

On Fri, Mar 1, 2019 at 9:26 AM Reinhard Tartler  wrote:

> That sounds really promising. I wonder how to implement it for this
> package.
>
> The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz,
> which I would love to continue using. Unlike yquake2, this package doesn't
> combine two seperate git repositories, but both sources come from the same
> upstream repository. Also, I would like the component to be placed in the
> subdirectory vendor/github.com/docker/docker, but to it seems to me that
> "components" may not include the "/" (or I missed how the "/" gets
> mangled).
> In conclusion, this means that "components" may only be placed at the
> top-level source directory.
>
> I guess what I can (should?) do is adjust the debian/copyright
> Files-Excluded field
> to exclude all entries but vendor/github.com/docker/docker, and use
> declare
> a 'vendor' component. Then I probably can use mk-origtargz to
> create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz".
>
> That would, however, lead to a *very* elaborate Files-Excluded field.
>
>
I actually went ahead and implement this solution. The result can be seen at
https://salsa.debian.org/go-team/packages/golang-github-openshift-imagebuilder

comments / opinions welcome. I'll try using this package to build buildah
locally
before uploading to unstable.

best,
-rt
-- 
regards,
Reinhard

Bug#233723: dpkg: it leaves xfonts-base.alias.dpkg-new file.

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Tue, 2008-07-01 at 09:14:40 +0300, Guillem Jover wrote:
> On Thu, 2004-02-19 at 18:22:20 +0100, Michele Mencacci wrote:
> > Package: dpkg
> > Version: 1.10.18
> > Severity: minor

> > Upgrading from 4.2.1-15, ( working system) to 4.2.1-16 and now 4.3.0-1 I  
> > found the X server didn't find "fixed" font, and I found it's because  
> > the unpack procedure leaves in every /etc/X11/fonts/subdirectory  a file  
> > called xfonts-.alias.dpkg-new and the cmd update-fonts-alias
> > doesn't work with it.I don't know if the prob is dpkg or X packages.
> >
> >  I am using Debian GNU/Linux sid , kernel 2.6.2 plus some from  
> > experimental.
> 
> I know this happened long time ago, but do you happen to remember if
> you diverted those conffiles? Otherwise it could be that some other
> package diverted those, but that'd be a bit more difficult to research
> at this point in time.

Tagging this as moreinfo. For this report to be actionable, it would
require to dig those old versions and try to reproduce it, not sure
whether these are in snapshots.d.o, otherwise maybe generating them
from their source package, which might be challenging, could be an
option…

Regards,
Guillem

Bug#923619: coreutils: FTBFS on hppa - Unknown error 252

[Michael Stone]

On March 2, 2019 4:09:14 PM EST, John David Anglin  wrote:
>Source: coreutils
>Version: 8.30-3
>Severity: normal
>
>Dear Maintainer,
>
>Since 8.30-2, coreutils fails to build on hppa with following error:
>
>make[5]: Entering directory '/<>'
> /bin/mkdir -p '/<>/debian/coreutils/usr/bin'
>src/ginstall -c src/ginstall
>'/<>/debian/coreutils/usr/bin/./install'
>src/ginstall: setting permissions for
>'/<>/debian/coreutils/usr/bin/./install': Unknown error
>252
>make[5]: *** [Makefile:6524: install-binPROGRAMS] Error 1
>
>Error 252 used to be ENOTSUP but this error number is no longer used on
>hppa-linux.  ENOTSUP is now defined to be EOPNOTSUPP.
>
>I tried to debug the failing command to see if I could find how the
>error
>occurs.  However, src/ginstall doesn't fail when I run the command
>outside
>the build.  So, I'm probably not setting the environment correctly.
>
>Regards,
>Dave Anglin
>
>-- System Information:
>Debian Release: buster/sid
>  APT prefers buildd-unstable
>  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
>Architecture: hppa (parisc64)
>
>Kernel: Linux 4.14.104+ (SMP w/4 CPU cores)
>Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C
>(charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>
>-- no debconf information

What happens if you rebuild -1?
-- 
Michael Stone
(From phone, please excuse typos)

Bug#923621: fonts-noto-color-emoji: build is not verbose enough

[Santiago Vila]

Package: src:fonts-noto-color-emoji
Version: 0~20180810-1
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build -- PNGQUANT=/usr/bin/pngquant
make V=1 -j1 PNGQUANT=/usr/bin/pngquant
make[2]: Entering directory '/<>'
mkdir -p "build/emoji"
mkdir -p "build/quantized_pngs"
using zopflipng
mkdir -p "build/compressed_pngs"
cc waveflag.c -o waveflag -std=c99 -Wall -Wextra `pkg-config --cflags --libs 
cairo` -lm `pkg-config --libs cairo`
mkdir -p "build/flags"
mkdir -p "build/resized_flags"
mkdir -p "build/renamed_flags"
E: Build killed with signal TERM after 60 minutes of inactivity


This happens because the build is silent for more than 60 minutes, which is
already a lot of time, and sbuild believes that the build hang and aborts.

I could of course increase the timeout, but there should not be need
to do that, because Debian Policy already says the build should be verbose.

So: Please make the build more verbose.

Thanks.

Bug#923620: RFS: slurp/1.1.0-1

[Birger Schacht]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : slurp
  Version  : 1.1.0-1
  Upstream Author  : Simon Ser
* Url  : https://wayland.emersion.fr/slurp/
* Licenses : Expat
  Programming Lang : C
  Section  : x11

 slurp is a command-line utility to select a region from Wayland compositors
 which support the layer-shell protocol. It lets the user hold the
pointer to
 select, or click to cancel the selection.

It builds those binary packages:

  * slurp

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

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

Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/s/slurp/slurp_1.1.0-1.dsc
or checkout the packaging repository on
https://salsa.debian.org/bisco-guest/slurp

More information about slurp can be obtained from
https://wayland.emersion.fr/slurp/


Changes since last upload:

  * New upstream version
  * Bump standards version

Regards,
  Birger Schacht

Bug#923619: coreutils: FTBFS on hppa - Unknown error 252

[John David Anglin]

Source: coreutils
Version: 8.30-3
Severity: normal

Dear Maintainer,

Since 8.30-2, coreutils fails to build on hppa with following error:

make[5]: Entering directory '/<>'
 /bin/mkdir -p '/<>/debian/coreutils/usr/bin'
  src/ginstall -c src/ginstall 
'/<>/debian/coreutils/usr/bin/./install'
src/ginstall: setting permissions for 
'/<>/debian/coreutils/usr/bin/./install': Unknown error 252
make[5]: *** [Makefile:6524: install-binPROGRAMS] Error 1

Error 252 used to be ENOTSUP but this error number is no longer used on
hppa-linux.  ENOTSUP is now defined to be EOPNOTSUPP.

I tried to debug the failing command to see if I could find how the error
occurs.  However, src/ginstall doesn't fail when I run the command outside
the build.  So, I'm probably not setting the environment correctly.

Regards,
Dave Anglin

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

-- no debconf information

Bug#920042: lua-nvim: autopkgtest times out since 2019-01-10

[Santiago Vila]

severity 920042 serious
thanks

Hi.

My autobuilders (using sbuild) hang when trying to build this package:

[...]
[ RUN  ] test/session_spec.lua @ 116: Session using ChidProcessStream can 
receive errors from n
vim
[   OK ] test/session_spec.lua @ 116: Session using ChidProcessStream can 
receive errors from n
vim (15.91 ms)
[ RUN  ] test/session_spec.lua @ 130: Session using ChidProcessStream can 
break out of event lo
op with a timeout
[   OK ] test/session_spec.lua @ 130: Session using ChidProcessStream can 
break out of event lo
op with a timeout (55.66 ms)
[ RUN  ] test/session_spec.lua @ 35: Session using SocketStream 
[/tmp/nvim.socket-2705] can mak
e requests to nvim
E: Build killed with signal TERM after 60 minutes of inactivity


and the hang also happens in reproducible-builds.org, using pbuilder:

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

Since I believe this problem is essentially the same as the one that
was reported in this bug, I'm raising the severity to serious, because
this is now also a FTBFS bug.

Also, the dates where this started to happen seem to be consistent with my
build failures. This is my build history for buster:

Status: successful  lua-nvim_0.1.0-1-1_amd64-20181206T123743.563Z
Status: successful  lua-nvim_0.1.0-1-1_amd64-20181217T150250.689Z
Status: successful  lua-nvim_0.1.0-1-1_amd64-20181228T152601.873Z
Status: successful  lua-nvim_0.1.0-1-1_amd64-20190108T055211.916Z
Status: failed  lua-nvim_0.1.0-1-1_amd64-20190122T052126.135Z
Status: failed  lua-nvim_0.1.0-1-1_amd64-20190207T020505.729Z
Status: failed  lua-nvim_0.1.0-1-1_amd64-20190220T132416.611Z

Thanks.

Bug#923618: ITP: patiencediff -- Python implementation of the patiencediff algorithm

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: patiencediff
  Version : 0.0.3
  Upstream Author : Breezy Developers
* URL : https://github.com/breezy-team
* License : GPL
  Programming Lang: Python
  Description : Python implementation of the patiencediff algorithm

 This package provides a Python implementation of the ``patiencediff`` 
algorithm, as
 `first described `_ by Bram 
Cohen.

 Like Python's ``difflib``, this module provides both a convience 
``unified_diff``
 function for the generation of unified diffs of text files
 as well as a SequenceMatcher that can be used on arbitrary lists.

 (This will be a dependency for Breezy)

Bug#923616: RFP: node-os-timesync -- nodejs package to check whether NTP time sync is enabled in OS settings

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-os-timesync
  Version : 1.0.9
  Upstream Author : felix lange
* URL : https://salsa.debian.org/themusicgod1-guest/os-timesync
* License : MIT
  Programming Lang: javascript
  Description : nodejs package to check whether NTP time sync is enabled in 
OS settings

A cross platform nodejs package to make sure that the calling program can be 
sure
that NTP time sync is enabled, no matter where it is being run.

Unfortunately Debian/GNU/Linux support is...sketchy and part of packaging this 
is
probably going to involve actually making it work along more use-cases that 
involve Debian.

node-os-timesync is a dependency of mist ( #827314 ).

Bug#923617: vlevel FTCBFS: confuses CC vs. CXX

[Helmut Grohne]

Source: vlevel
Version: 0.5.1-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

vlevel's upstream Makefile observes that storing the C++ compiler in
$(CC) is an "evil hack". Indeed, this hack breaks cross compilation,
because dh_auto_build passes a C compiler there. Updating CC to a $(CXX)
fixes that part, but there is still a Makefile that hard codes the build
architecture pkg-config. The attached patch makes vlevel cross
buildable. Please consider applying it.

Helmut
diff --minimal -Nru vlevel-0.5.1/debian/changelog vlevel-0.5.1/debian/changelog
--- vlevel-0.5.1/debian/changelog   2019-01-02 07:30:04.0 +0100
+++ vlevel-0.5.1/debian/changelog   2019-03-02 21:47:15.0 +0100
@@ -1,3 +1,12 @@
+vlevel (0.5.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Upstream expects $(CC) to contain a C++ compiler.
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Sat, 02 Mar 2019 21:47:15 +0100
+
 vlevel (0.5.1-3) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --minimal -Nru vlevel-0.5.1/debian/patches/cross.patch 
vlevel-0.5.1/debian/patches/cross.patch
--- vlevel-0.5.1/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ vlevel-0.5.1/debian/patches/cross.patch 2019-03-02 21:47:15.0 
+0100
@@ -0,0 +1,18 @@
+--- vlevel-0.5.1.orig/vlevel-jack/Makefile
 vlevel-0.5.1/vlevel-jack/Makefile
+@@ -21,11 +21,12 @@
+ #
+ # This is evil, but it makes implicit link rules use g++, not gcc
+ CC = $(CXX)
++PKG_CONFIG ?= pkg-config
+ #LDFLAGS = -L/opt/local/lib
+-LDFLAGS += ` pkg-config --libs-only-L jack `
++LDFLAGS += ` $(PKG_CONFIG) --libs-only-L jack `
+ #LDLIBS = -ljack -lpthread -framework CoreAudio -framework CoreServices 
-framework AudioUnit
+-LDLIBS = ` pkg-config --libs-only-l jack `
+-CXXFLAGS += ` pkg-config --cflags jack `
++LDLIBS = ` $(PKG_CONFIG) --libs-only-l jack `
++CXXFLAGS += ` $(PKG_CONFIG) --cflags jack `
+ #CXXFLAGS= -I/opt/local/include -g -v
+ CFLAGS = $(CXXFLAGS)
+ 
diff --minimal -Nru vlevel-0.5.1/debian/patches/series 
vlevel-0.5.1/debian/patches/series
--- vlevel-0.5.1/debian/patches/series  2017-10-30 00:44:44.0 +0100
+++ vlevel-0.5.1/debian/patches/series  2019-03-02 21:47:15.0 +0100
@@ -1,2 +1,3 @@
 fix-hardcoded-makefile-variables.patch
 recursive-make-done-properly.patch
+cross.patch
diff --minimal -Nru vlevel-0.5.1/debian/rules vlevel-0.5.1/debian/rules
--- vlevel-0.5.1/debian/rules   2017-10-30 00:33:11.0 +0100
+++ vlevel-0.5.1/debian/rules   2019-03-02 21:47:13.0 +0100
@@ -6,6 +6,9 @@
 %:
dh $@
 
+override_dh_auto_build:
+   dh_auto_build -- 'CC=$$(CXX)'
+
 override_dh_auto_install:
dh_auto_install
mv -v debian/vlevel/usr/bin/vlevel-bin debian/vlevel/usr/bin/vlevel

Bug#923448: stunnel4: autopkgtest fails with new version of openssl: failed to set DH parameters at debian/tests/runtime line 295.

[Peter Pentchev]

Control: clone -1 -2
Control: reassign -2 libanyevent-perl
Control: severity -2 normal
Control: retitle -2 AnyEvent::TLS: create 2048-bit DH keys by default
Control: tag -2 + confirmed pending
Control: tag -1 + pending

On Fri, Mar 01, 2019 at 10:27:42PM +0100, gregor herrmann wrote:
> On Fri, 01 Mar 2019 22:16:39 +0100, Sebastian Andrzej Siewior wrote:
> 
> > On 2019-03-01 21:30:04 [+0100], gregor herrmann wrote:
> > > On Fri, 01 Mar 2019 21:18:37 +0100, Sebastian Andrzej Siewior wrote:
> > > 
> > > > The patch attached fixes the issue in libanyevent-perl by setting the
> > > > default DH value to 2048.
> > > There's also a new AnyEvent release but I saw the "INCOMPATIBLE
> > > CHANGE" in the changelog, and I don't think it changes what is
> > > affected here?
> 
> Here a link was missing:
> https://metacpan.org/diff/file?target=MLEHMANN/AnyEvent-7.15/=MLEHMANN%2FAnyEvent-7.14
>  
> > stunnel's autopkgtest (and everyone else using that API without using a
> > DH2048+key since now the API rejects smaller values properly).
> 
> Ok.
>  
> > > > Moving forward:
> > > > - apply the patch to libanyevent-perl and be done with it
> > > > - tell the stunnel4 testsuite to use 2048bit DH instead the default
> > > >   value.
> > > 
> > > Is this an alternative or are both steps needed?
> > 
> > Either/or. The last b release of openssl fixes the return code of one
> > function. Since that change, setting < 2048bit DH key fails (before that
> > it was also failed but with a success return value so everyone assumed
> > that it worked).
> > 
> > So either libanyevent-perl changes the default DH key to 2048 (like in
> > the patch attached) _or_ someome comes up with perl foo and makes sure 
> > debian/tests/runtime in the block around line 276 - 295 specifies a dh
> > with 2048 bits. My perl foo was enough to narrow it down to that area :)
> > 
> > I *think* that 2048bit DH keys should be default these days and this
> > would avoid errors like that in the future.
> 
> Thanks for the clarification.
> As roam offered to look into the issue earlier today in the bug log,
> I suggest to let him handle the question and fix it either in
> stunnel4 or libanyevent-perl (handy to involved in both areas :))

Thanks a lot to both of you for the analysis and the discussion!

I've fixed the problem in my Git repository for stunnel4; I shall upload
it in a little while after some more testing.  I'll try to also change
the libanyevent-perl default today.

Thanks again, and keep up the great work!

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#923614: rockdodger FTCBFS: uses build architecture build tools

[Helmut Grohne]

Source: rockdodger
Version: 1.1.3-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

rockdodger fails to cross build from source, because it uses build
architecture build tools. Since it does not use debhelper, we cannot use
dh_auto_build or dh_strip. Still, we can use dpkg's buildtools.mk to set
up CC and STRIP with the correct tool names. Thus the attached patch
makes rockdodger cross buildable. Please consider applying it or using
debhelper.

Helmut
diff --minimal -Nru rockdodger-1.1.3/debian/changelog 
rockdodger-1.1.3/debian/changelog
--- rockdodger-1.1.3/debian/changelog   2019-02-16 18:35:41.0 +0100
+++ rockdodger-1.1.3/debian/changelog   2019-03-02 21:32:31.0 +0100
@@ -1,3 +1,10 @@
+rockdodger (1.1.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply tools. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 02 Mar 2019 21:32:31 +0100
+
 rockdodger (1.1.3-2) unstable; urgency=low
 
   * Made build reproducible, fixed DEBIAN/md5sums.
diff --minimal -Nru rockdodger-1.1.3/debian/rules rockdodger-1.1.3/debian/rules
--- rockdodger-1.1.3/debian/rules   2019-02-16 18:35:19.0 +0100
+++ rockdodger-1.1.3/debian/rules   2019-03-02 21:32:29.0 +0100
@@ -1,8 +1,11 @@
 #!/usr/bin/make -f
 
+-include /usr/share/dpkg/buildtools.mk
+
 testdir  = test -f rocks.c && test -f debian/rules
 testroot = test x`whoami` = xroot
 
+STRIP ?= strip
 CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS   = $(shell dpkg-buildflags --get CFLAGS)
 LDFLAGS  = $(shell dpkg-buildflags --get LDFLAGS)
@@ -24,7 +27,7 @@
 
 build-stamp:
$(testdir)
-   $(MAKE) DESTDIR=$(CURDIR)/debian/tmp prefix=$(CURDIR)/debian/tmp/usr 
bindir=$(CURDIR)/debian/tmp/usr/games 
datarootdir=$(CURDIR)/debian/tmp/usr/share 
localstatedir=$(CURDIR)/debian/tmp/var
+   $(MAKE) 'CC=$(CC)' DESTDIR=$(CURDIR)/debian/tmp 
prefix=$(CURDIR)/debian/tmp/usr bindir=$(CURDIR)/debian/tmp/usr/games 
datarootdir=$(CURDIR)/debian/tmp/usr/share 
localstatedir=$(CURDIR)/debian/tmp/var
touch $@
 
 binary: binary-arch binary-indep
@@ -36,7 +39,7 @@
 
$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp 
prefix=$(CURDIR)/debian/tmp/usr bindir=$(CURDIR)/debian/tmp/usr/games 
datarootdir=$(CURDIR)/debian/tmp/usr/share 
localstatedir=$(CURDIR)/debian/tmp/var
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   strip --strip-unneeded -R .comment -R .note 
debian/tmp/usr/games/rockdodger
+   $(STRIP) --strip-unneeded -R .comment -R .note 
debian/tmp/usr/games/rockdodger
 endif
rm debian/tmp/var/games/rockdodger.scores
 

Bug#923613: sip-tester FTCBFS: configure.ac hard codes pkg-config

[Helmut Grohne]

Source: sip-tester
Version: 1:3.5.2-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

sip-tester fails to cross build from source, because configure.ac hard
codes the build architecture pkg-config. Switching it to
PKG_CHECK_MODULES fixes the problem, but one has to ensure that the
macro is conditionalized with AS_IF rather than plain if, because it
uses AC_REQUIRE. The attached patch implements that and makes sip-tester
cross buildable. Please consider applying it.

Helmut
--- sip-tester-3.5.2.orig/configure.ac
+++ sip-tester-3.5.2/configure.ac
@@ -88,9 +88,7 @@
 
 #  checks for libraries =
 
-if test "$have_pkgconfig" = "yes"; then
-# Use pkg-config when available
-PKG_PROG_PKG_CONFIG()
+AS_IF([test "$have_pkgconfig" = "yes"],[
 PKG_CHECK_MODULES([ncurses], [ncurses],
 LIBS="$LIBS $ncurses_LIBS",
 [PKG_CHECK_MODULES([curses], [curses],
@@ -100,11 +98,11 @@
 AC_ERROR([Missing (n)curses library]))]
 )]
 )
-else
+],[
 # Olden ways
 AC_SEARCH_LIBS([initscr], [ncurses curses],,AC_ERROR([Missing (n)curses library]))
 AC_SEARCH_LIBS([stdscr], [tinfo ncurses curses],,AC_ERROR([Missing (n)curses/tinfo library]))
-fi
+])
 
 AC_CHECK_LIB(pthread, pthread_mutex_init, THREAD_LIBS="-lpthread",
 AC_MSG_ERROR(pthread library needed!))
@@ -194,7 +192,7 @@
 AM_CONDITIONAL(HAVE_RTP, test "$rtp" = "yes")
 
 # Conditional build with gsl
-if test "$gsl" = "yes"; then
+AS_IF([test "$gsl" = "yes"],[
 if test "$have_pkgconfig" != "yes" ; then
 AC_MSG_ERROR([Please install pkg-config to use the gsl libraries])
 fi
@@ -205,15 +203,12 @@
 AC_CHECK_LIB([gslcblas], [cblas_dgemm])
 AC_CHECK_LIB([gsl], [gsl_rng_alloc],
  [
-  GSL_CFLAGS=`pkg-config gsl --cflags`
-  GSL_CXXFLAGS=`pkg-config gsl --cflags`
-  GSL_LIBS=`pkg-config gsl --libs`
-  AC_SUBST([GSL_CFLAGS])
+		  PKG_CHECK_MODULES([GSL],[gsl])
+		  GSL_CXXFLAGS=$GSL_CFLAGS
   AC_SUBST([GSL_CXXFLAGS])
-  AC_SUBST([GSL_LIBS])
   ]
  ,[AC_MSG_ERROR([gsl library missing])])
-fi
+])
 # For Makefile.am
 AM_CONDITIONAL(HAVE_GSL, test "$gsl" = "yes")
 

Bug#923607: openblas: FTBFS if CPU is not detected

[Santiago Vila]

> Still there seems to be an issue with your specific build environment,
> and of course this is a bug (but maybe not an RC one, since you are the
> first to report such a build failure after many years). Could you give
> more details about the hardware you are using?

I'm currently using Scaleway 1-XS and 1-S instances. On both types of
instances the package always fail to build. I didn't find a way to
move the "unbuildability property" to a non-failing machine (for
example, by taking /proc/cpuinfo in the failing machine and using
bind-mount on the non-failing machine), so I decided to report it anyway
without a "recipe to reproduce it" but with an offer to ssh into a failing
machine instead.

Thanks.

Bug#923612: grub-pc: grub-install failure leaves package in unrecoverable broken state

[Uoti Urpala]

Package: grub-pc
Version: 2.02+dfsg1-11
Severity: normal

>From logs, the following events seem to have happened:

grub-pc was upgraded under unattended-upgrades. This was when the udev
bug changed disk path. Grub-pc appears to have tried installing in the
old nonexistent path; I assume this part depended on unattended-
upgrades not allowing it to use debconf to ask for a new path. Apt logs
only show "grub-install: error: cannot find a GRUB drive for ...".
After this, no core.img file existed on the machine. grub-pc.postinst
uses the existence of a core.img file to determine the kind of
installation the machine has; with it absent, the package entered a
permanently broken state where further upgrades or dpkg-reconfigure did
nothing.

There are at least two things here which can be considered bugs:

1. If there is no interactive debconf frontend available, the package
goes ahead and calls grub-install with known incorrect arguments.

2. Using the existence of core.img to determine the type of install is
too fragile when this file can be erased by a failed grub-install call,
and after this happens the package state can not be recovered by normal
means (I used a manual grub-install call to restore the file).


I haven't tried reproducing problem 1. Bug 2 can be mostly reproduced
by manually running "grub-install /dev/wtf"; after running that, you
can see that "dpkg-reconfigure grub-pc" no longer works.


BTW the grub-install manual page lists most options, then repeats the
"Install GRUB on your drive." description, and lists the same options
again.

Bug#923609: libgdbm6: binary incompatibility with old databases on at least i386

[Niko Tyni]

On Sat, Mar 02, 2019 at 09:34:49PM +0200, Niko Tyni wrote:

> # ls -l *.gdbm
> -rw-r- 1 root root 12294 Mar  2 19:04 perl-stretch.gdbm
> -rw-r--r-- 1 root root 12294 Mar  2 19:04 py2-stretch.gdbm
> -rw-r--r-- 1 root root 12294 Mar  2 19:04 py3-stretch.gdbm

These are all bit-by-bit identical; I'm attaching the file
in case that helps.
-- 
Niko Tyni   nt...@debian.org


perl-stretch-i386.gdbm
Description: Binary data

Bug#923611: wireshark: CVE-2019-9208 CVE-2019-9209 CVE-2019-9214

[Salvatore Bonaccorso]

Source: wireshark
Version: 2.6.6-1
Severity: important
Tags: security upstream
Control: found -1 2.6.5-1~deb9u1

Hi,

The following vulnerabilities were published for wireshark.

CVE-2019-9208[0]:
| In Wireshark 2.4.0 to 2.4.12 and 2.6.0 to 2.6.6, the TCAP dissector
| could crash. This was addressed in epan/dissectors/asn1/tcap/tcap.cnf
| by avoiding NULL pointer dereferences.

CVE-2019-9209[1]:
| In Wireshark 2.4.0 to 2.4.12 and 2.6.0 to 2.6.6, the ASN.1 BER and
| related dissectors could crash. This was addressed in
| epan/dissectors/packet-ber.c by preventing a buffer overflow associated
| with excessive digits in time values.

CVE-2019-9214[2]:
| In Wireshark 2.4.0 to 2.4.12 and 2.6.0 to 2.6.6, the RPCAP dissector
| could crash. This was addressed in epan/dissectors/packet-rpcap.c by
| avoiding an attempted dereference of a NULL conversation.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9208
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9208
[1] https://security-tracker.debian.org/tracker/CVE-2019-9209
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9209
[2] https://security-tracker.debian.org/tracker/CVE-2019-9214
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9214

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#923610: mount: umount Bash tab completion does not escape spaces in mount points

[Matthew Kraai]

Package: mount
Version: 2.33.1-0.1
Severity: minor

Dear Maintainer,

umount's Bash tab completion doesn't escape spaces in mount points, so
I have to manually escape them.

For example, if the mount point is
`/media/kraai/Seagate Backup Plus Drive` and I type `umount /media`
and then press tab, it is expanded to

```
umount /media/kraai/Seagate Backup Plus Drive
```

I would like it to be expanded to

```
umount /media/kraai/Seagate\ Backup\ Plus\ Drive
```

This is how the tab completion for `cd` escapes the spaces.

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

Kernel: Linux 4.19.0-2-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mount depends on:
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-8
ii  libmount1  2.33.1-0.1
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.33.1-0.1
ii  util-linux 2.33.1-0.1

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

-- no debconf information

Bug#923609: libgdbm6: binary incompatibility with old databases on at least i386

[Niko Tyni]

Package: libgdbm6
Version: 1.18.1-3
Severity: serious
Control: block 923238 with -1

GDBM databases created on stretch (gdbm 1.8.3-14) are not
compatible with libgdbm in sid/buster (1.18.1-3) on at least
the i386 (32-bit x86) architecture, probably also armhf.

This means that any local user databases will break on upgrade from
stretch to buster. It also breaks a few Debian packages that use GDBM
files (known affected are libmarc-charset-perl and command-not-found).

Bug #910911 discussed a similar problem that applied to all architectures.
It seems probable that the fix for that never worked on i386 but this
was just not detected earlier. The incompatibility was reported recently
in bug #923238 and was found because Ubuntu has a better architecture
coverage on their autopkgtest setup.

Below are steps to reproduce, testing with Python 2, Python 3, and Perl.
We make a trivial GDBM database with each, containing just one key "foo"
with the value "bar". After upgrading to buster on i386, none of these
databases can be read and "Malformed database file header" is reported.
On amd64, everything works fine after the upgrade.

# start from stretch
# apt install python-gdbm python3-gdbm perl

python - <<'EOF'
import gdbm   
gdbm.open("py2-stretch.gdbm", "c")["foo"] = "bar"
EOF

python3 <<'EOF'
import dbm.gnu
dbm.gnu.open("py3-stretch.gdbm", "c")["foo"] = "bar"
EOF

perl <<'EOF'
use GDBM_File;
tie %h,  q(GDBM_File), "perl-stretch.gdbm", _WRCREAT, 0640
  or die "opening GDBM file failed: $!";
$h{foo} = "bar"
EOF

# ls -l *.gdbm
-rw-r- 1 root root 12294 Mar  2 19:04 perl-stretch.gdbm
-rw-r--r-- 1 root root 12294 Mar  2 19:04 py2-stretch.gdbm
-rw-r--r-- 1 root root 12294 Mar  2 19:04 py3-stretch.gdbm

# upgrade to buster
# sed -i s/stretch/buster/ /etc/apt/sources.list && apt update && apt 
dist-upgrade && apt install gdbmtool

# test with gdbmtool
# gdbmtool py2-stretch.gdbm fetch foo
gdbmtool: stdin:1.1-10: cannot open database py2-stretch.gdbm: Malformed 
database file header
# gdbmtool py3-stretch.gdbm fetch foo
gdbmtool: stdin:1.1-10: cannot open database py3-stretch.gdbm: Malformed 
database file header
# gdbmtool perl-stretch.gdbm fetch foo
gdbmtool: stdin:1.1-10: cannot open database perl-stretch.gdbm: Malformed 
database file header

# similar results with any of these:

perl <<'EOF'
use GDBM_File;
 tie %h,  q(GDBM_File), "perl-stretch.gdbm", _READER, 0640
  or die "opening GDBM file failed: $!";
print $h{foo}, "\n";
EOF

python <<'EOF'
import gdbm
print(gdbm.open("py2-stretch.gdbm", "r")["foo"])
EOF

python3 <<'EOF'
import dbm.gnu 
print(dbm.gnu.open("py3-stretch.gdbm", "r")["foo"])
EOF

-- 
Niko Tyni   nt...@debian.org

Bug#923607: openblas: FTBFS if CPU is not detected

[Sébastien Villemot]

Dear Santiago,

Le samedi 02 mars 2019 à 18:11 +, Santiago Vila a écrit :
> Package: src:openblas
> Version: 0.3.5+ds-2
> Severity: serious
> Tags: ftbfs
> 
> I tried to build this package in buster but it failed:

[…]
> make[2]: *** [Makefile.prebuild:66: getarch_2nd] Error 1
> Makefile:135: *** OpenBLAS: Detecting CPU failed. Please set TARGET 
> explicitly, e.g. make TARGET=your_cpu_target. Please read README for the 
> detail..  Stop.
> make[2]: Leaving directory '/<>/openblas-0.3.3+ds'
> make[1]: *** [debian/rules:77: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<>/openblas-0.3.3+ds'
> make: *** [debian/rules:74: binary-arch] Error 2
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2
> 
> 
> The error message says it all: Please set TARGET explicitly.
> 
> The fact that this package tries to detect the CPU is probably the
> reason the executables built in buildd.debian.org do not work
> everywhere:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743490
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781998
> 
> which in addition to the FTBFS bug, it's also a baseline violation.

As mentioned in the package description, on amd64, arm64 and i386, the
binary contains specialized kernels for many different micro-
architectures, and the selection  of the kernel is done at runtime. So
the design is correct and there is no baseline violation.

Still there seems to be an issue with your specific build environment,
and of course this is a bug (but maybe not an RC one, since you are the
first to report such a build failure after many years). Could you give
more details about the hardware you are using?

Thanks,

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


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

Bug#829417: dosemu: *** stack smashing detected ***: /usr/bin/xdosemu terminated

[felix]

Applying the attached patch should help.

Also, please consider switching the upstream source of this package to 
. It's theoretically still unstable, 
but it's more actively maintained than the SourceForge repository, and 
by the same person (to my knowledge). It has an analogous patch already 
applied: 
.


--
--fIndex: dosemu-1.4.0.7+20130105+b028d3f/src/arch/linux/async/signal.c
===
--- dosemu-1.4.0.7+20130105+b028d3f.orig/src/arch/linux/async/signal.c
+++ dosemu-1.4.0.7+20130105+b028d3f/src/arch/linux/async/signal.c
@@ -225,7 +225,7 @@ int check_fix_fs_gs_base(unsigned char p
 /* init_handler puts the handler in a sane state that glibc
expects. That means restoring fs and gs for vm86 (necessary for
2.4 kernels) and fs, gs and eflags for DPMI. */
-__attribute__((no_instrument_function))
+__attribute__((no_instrument_function,optimize("no-stack-protector")))
 void init_handler(struct sigcontext_struct *scp)
 {
   /*
@@ -309,7 +309,7 @@ void init_handler(struct sigcontext_stru
 
 /* this cleaning up is necessary to avoid the port server becoming
a zombie process */
-__attribute__((no_instrument_function))
+__attribute__((no_instrument_function,optimize("no-stack-protector")))
 static void cleanup_child(struct sigcontext_struct *scp)
 {
   int status;
@@ -322,7 +322,7 @@ static void cleanup_child(struct sigcont
   }
 }
 
-__attribute__((no_instrument_function))
+__attribute__((no_instrument_function,optimize("no-stack-protector")))
 static void leavedos_signal(int sig)
 {
   init_handler(NULL);
@@ -804,7 +804,7 @@ static void sigalrm(struct sigcontext_st
   }
 }
 
-__attribute__((no_instrument_function))
+__attribute__((no_instrument_function,optimize("no-stack-protector")))
 static void sigasync0(int sig, struct sigcontext_struct *scp)
 {
   init_handler(scp);
@@ -813,7 +813,7 @@ static void sigasync0(int sig, struct si
   dpmi_iret_setup(scp);
 }
 
-__attribute__((no_instrument_function))
+__attribute__((no_instrument_function,optimize("no-stack-protector")))
 static void sigasync(int sig, siginfo_t *si, void *uc)
 {
   sigasync0(sig, (struct sigcontext_struct *)
Index: dosemu-1.4.0.7+20130105+b028d3f/src/arch/linux/async/sigsegv.c
===
--- dosemu-1.4.0.7+20130105+b028d3f.orig/src/arch/linux/async/sigsegv.c
+++ dosemu-1.4.0.7+20130105+b028d3f/src/arch/linux/async/sigsegv.c
@@ -37,7 +37,7 @@ void print_exception_info(struct sigcont
 
 /*
  * All of the functions in this module need to be declared with
- *   __attribute__((no_instrument_function))
+ *   __attribute__((no_instrument_function,optimize("no-stack-protector")))
  * so that they can safely handle signals that occur in DPMI context when
  * DOSEMU is built with the "-pg" gcc flag (which enables instrumentation for
  * gprof profiling).
@@ -62,7 +62,7 @@ void print_exception_info(struct sigcont
  * DANG_END_FUNCTION
  */
 
-__attribute__((no_instrument_function))
+__attribute__((no_instrument_function,optimize("no-stack-protector")))
 int dosemu_fault1(
 #ifdef __linux__
 int signal, struct sigcontext_struct *scp
@@ -380,7 +380,7 @@ bad:
   }
 }
 
-__attribute__((no_instrument_function))
+__attribute__((no_instrument_function,optimize("no-stack-protector")))
 static void dosemu_fault0(int signal, struct sigcontext_struct *scp)
 {
   int retcode;
@@ -448,7 +448,7 @@ static void dosemu_fault0(int signal, st
 }
 
 #ifdef __linux__
-__attribute__((no_instrument_function))
+__attribute__((no_instrument_function,optimize("no-stack-protector")))
 void dosemu_fault(int signal, siginfo_t *si, void *uc)
 {
   dosemu_fault0(signal, (struct sigcontext_struct *)
@@ -465,7 +465,7 @@ void dosemu_fault(int signal, siginfo_t
  * DANG_END_FUNCTION
  *
  */
-__attribute__((no_instrument_function))
+__attribute__((no_instrument_function,optimize("no-stack-protector")))
 void print_exception_info(struct sigcontext_struct *scp)
 {
   int i;

Bug#922554: network-manager: NetworkManager continuously spinning, probably while checking for connectivity

[Dominique Dumont]

On Mon, 18 Feb 2019 01:45:12 +0100 Jiri Palecek  wrote:
> exe->curl_multi_socket_action(0x15c4900, 24, 2, 0xbfb0bd88)   
>   
> = 0
> exe->curl_multi_info_read(0x15c4900, 0xbfb0bd80, 2, 0xbfb0bd88)   
>   
> = 0

Looks related to 
https://bugs.archlinux.org/index.php?do=details=details.addvote_id=61688

where they suggest to downgrade curl (or libcurl in our case)

HTH

Bug#923608: debsign: signing fails randomly for some packages built with sbuild on hppa

[John David Anglin]

On 2019-03-02 1:24 p.m., Mattia Rizzolo wrote:
> That looks very likely a gpg problem.  Or a problem of whatever is > supposed 
> to launch the agent in your setup. The agent is running...

buildd@mx3210:~$ ps -ef|grep gpg
buildd   12622 1  0 Mar01 ?    00:00:30 gpg-agent --homedir 
/home/buildd/.gnupg --use-standard-socket --daemon

Dave
-- 
John David Anglin  dave.ang...@bell.net

Bug#923608: debsign: signing fails randomly for some packages built with sbuild on hppa

[John David Anglin]

On 2019-03-02 1:24 p.m., Mattia Rizzolo wrote:
> Mhhh, never heard of such things.
I guess I should mention that this problem has been seen on several hppa 
buildds (Helge Deller)
and sparc64 (John Paul Adrian Glaubitz).

The annoying part of the problem is the uploader sends an email about the 
missing signature
every 15 minutes.

Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#923608: debsign: signing fails randomly for some packages built with sbuild on hppa

[Mattia Rizzolo]

Control: reassign -1 gpg

On Sat, Mar 02, 2019 at 01:18:05PM -0500, John David Anglin wrote:
> I don't know if this is a problem in debsign or not but signing fails
> randomly for some packages.  I have a feeling that the failure occurs
> mostly for packages that don't take much time to build.

Mhhh, never heard of such things.
However:

> Finished at 2019-03-02T17:27:55Z
> Build needed 00:03:52, no disk space
> Signature with key 'E04E8E9D23705BB511E05D6382583F4A818EA3F9' requested:
>  signfile buildinfo /home/buildd/build/metar_20190227.1-1_hppa.buildinfo 
> E04E8E9D23705BB511E05D6382583F4A818EA3F9
> gpg: can't connect to the agent: IPC connect call failed
> gpg: keydb_search failed: No agent running
> gpg: skipped "E04E8E9D23705BB511E05D6382583F4A818EA3F9": No agent running
> gpg: /tmp/debsign.lU8FaRy9/metar_20190227.1-1_hppa.buildinfo: clear-sign 
> failed: No agent running
> debsign: gpg error occurred!  Aborting

That looks very likely a gpg problem.  Or a problem of whatever is
supposed to launch the agent in your setup.

-- 
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#923608: debsign: signing fails randomly for some packages built with sbuild on hppa

[John David Anglin]

Package: devscripts
Version: 2.19.3
Severity: normal

Dear Maintainer,

I don't know if this is a problem in debsign or not but signing fails
randomly for some packages.  I have a feeling that the failure occurs
mostly for packages that don't take much time to build.

Here is an example from a recent metar build:
https://buildd.debian.org/status/fetch.php?pkg=metar=hppa=20190227.1-1=1551547714=0

+--+
| Summary  |
+--+

Build Architecture: hppa
Build Type: any
Build-Space: n/a
Build-Time: 47
Distribution: sid
Host Architecture: hppa
Install-Time: 69
Job: metar_20190227.1-1
Machine Architecture: hppa
Package: metar
Package-Time: 232
Source-Version: 20190227.1-1
Space: n/a
Status: successful
Version: 20190227.1-1

Finished at 2019-03-02T17:27:55Z
Build needed 00:03:52, no disk space
Signature with key 'E04E8E9D23705BB511E05D6382583F4A818EA3F9' requested:
 signfile buildinfo /home/buildd/build/metar_20190227.1-1_hppa.buildinfo 
E04E8E9D23705BB511E05D6382583F4A818EA3F9
gpg: can't connect to the agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "E04E8E9D23705BB511E05D6382583F4A818EA3F9": No agent running
gpg: /tmp/debsign.lU8FaRy9/metar_20190227.1-1_hppa.buildinfo: clear-sign 
failed: No agent running
debsign: gpg error occurred!  Aborting

I did a give-back and metar was successfully signed:
https://buildd.debian.org/status/fetch.php?pkg=metar=hppa=20190227.1-1=1551549881=0

The problem started around Dec. 15, 2018.  The hppa buildds generally run
current software from sid.

Regards,
Dave Anglin

-- Package-specific info:

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

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

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.5
ii  fakeroot  1.23-1
ii  file  1:5.35-3
ii  gnupg 2.2.12-1
ii  gnupg22.2.12-1
ii  gpgv  2.2.12-1
ii  libc6 2.28-7
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-4
ii  python3   3.7.2-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.0~rc4
ii  at  3.1.23-1
ii  curl7.64.0-1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.02.25
ii  dupload 2.9.4
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.5
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.16-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.9.1
ii  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.3
ii  python3-debian  0.1.34
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-5
ii  strace  4.15-2
ii  unzip   6.0-22
ii  wget1.20.1-1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
pn  adequate  
ii  autopkgtest   5.10
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.6
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 12.1.1
pn  devscripts-el 
pn  diffoscope
pn  disorderfs
pn  dose-extra
pn  duck  
ii  faketime  

Bug#923607: openblas: FTBFS if CPU is not detected

[Santiago Vila]

Package: src:openblas
Version: 0.3.5+ds-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules binary-arch
dh binary-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
   dh_auto_configure -a
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/openblas-0.3.3+ds'
/usr/bin/make NO_LAPACKE=1 NO_AFFINITY=1 USE_OPENMP=0 NO_WARMUP=1 
CFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>/openblas-0.3.3+ds=. -fstack-protector-strong 
-Wformat -Werror=format-security" FFLAGS="-g -O2 
-fdebug-prefix-map=/<>/openblas-0.3.3+ds=. -fstack-protector-strong" 
COMMON_OPT= FCOMMON_OPT=-frecursive NUM_THREADS=64 DYNAMIC_ARCH=1 
DYNAMIC_OLDER=1
make[2]: Entering directory '/<>/openblas-0.3.3+ds'
getarch_2nd.c: In function 'main':
getarch_2nd.c:12:35: error: 'SGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("SGEMM_UNROLL_M=%d\n", SGEMM_DEFAULT_UNROLL_M);
   ^~
   XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:12:35: note: each undeclared identifier is reported only once for 
each function it appears in
getarch_2nd.c:13:35: error: 'SGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
 printf("SGEMM_UNROLL_N=%d\n", SGEMM_DEFAULT_UNROLL_N);
   ^~
   XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:14:35: error: 'DGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("DGEMM_UNROLL_M=%d\n", DGEMM_DEFAULT_UNROLL_M);
   ^~
   XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:15:35: error: 'DGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
 printf("DGEMM_UNROLL_N=%d\n", DGEMM_DEFAULT_UNROLL_N);
   ^~
   XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:19:35: error: 'CGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("CGEMM_UNROLL_M=%d\n", CGEMM_DEFAULT_UNROLL_M);
   ^~
   XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:20:35: error: 'CGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
 printf("CGEMM_UNROLL_N=%d\n", CGEMM_DEFAULT_UNROLL_N);
   ^~
   XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:21:35: error: 'ZGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("ZGEMM_UNROLL_M=%d\n", ZGEMM_DEFAULT_UNROLL_M);
   ^~
   XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:22:35: error: 'ZGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
 printf("ZGEMM_UNROLL_N=%d\n", ZGEMM_DEFAULT_UNROLL_N);
   ^~
   XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:69:50: error: 'SGEMM_DEFAULT_Q' undeclared (first use in this 
function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("#define SLOCAL_BUFFER_SIZE\t%ld\n", (SGEMM_DEFAULT_Q * 
SGEMM_DEFAULT_UNROLL_N * 4 * 1 *  sizeof(float)));
  ^~~
  XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:70:50: error: 'DGEMM_DEFAULT_Q' undeclared (first use in this 
function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("#define DLOCAL_BUFFER_SIZE\t%ld\n", (DGEMM_DEFAULT_Q * 
DGEMM_DEFAULT_UNROLL_N * 2 * 1 *  sizeof(double)));
  ^~~
  XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:71:50: error: 'CGEMM_DEFAULT_Q' undeclared (first use in this 
function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("#define CLOCAL_BUFFER_SIZE\t%ld\n", (CGEMM_DEFAULT_Q * 
CGEMM_DEFAULT_UNROLL_N * 4 * 2 *  sizeof(float)));
  ^~~
  XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:72:50: error: 'ZGEMM_DEFAULT_Q' undeclared (first use in this 
function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("#define ZLOCAL_BUFFER_SIZE\t%ld\n", (ZGEMM_DEFAULT_Q * 
ZGEMM_DEFAULT_UNROLL_N * 2 * 2 *  sizeof(double)));
  ^~~

Bug#923606: beancount: FTBFS randomly (gpg-related race condition)

[Santiago Vila]

Package: src:beancount
Version: 2.2.0-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules binary-indep
dh binary-indep --with python3,elpa --buildsystem pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython3_3.7/build/beancount

[... snipped ...]

is_dir = False
if is_dir:
try:
dirfd = os.open(entry.name, os.O_RDONLY, dir_fd=topfd)
except OSError:
onerror(os.open, fullname, sys.exc_info())
else:
try:
if os.path.samestat(orig_st, os.fstat(dirfd)):
_rmtree_safe_fd(dirfd, fullname, onerror)
try:
os.rmdir(entry.name, dir_fd=topfd)
except OSError:
onerror(os.rmdir, fullname, sys.exc_info())
else:
try:
# This can only happen if someone replaces
# a directory with a symlink after the call to
# os.scandir or stat.S_ISDIR above.
raise OSError("Cannot call rmtree on a symbolic 
"
  "link")
except OSError:
onerror(os.path.islink, fullname, 
sys.exc_info())
finally:
os.close(dirfd)
else:
try:
>   os.unlink(entry.name, dir_fd=topfd)
E   FileNotFoundError: [Errno 2] No such file or directory: 
'S.gpg-agent.browser'

/usr/lib/python3.7/shutil.py:447: FileNotFoundError
=== warnings summary ===
/usr/lib/python3/dist-packages/bottle.py:87
  /usr/lib/python3/dist-packages/bottle.py:87: DeprecationWarning: Using or 
importing the ABCs from 'collections' instead of from 'collections.abc' is 
deprecated, and in 3.8 it will stop working
from collections import MutableMapping as DictMixin

.pybuild/cpython3_3.7/build/beancount/ingest/regression_test.py::TestImporterTestGenerators::test_compare_sample_files__no_directory
  /tmp/TestImporterTestGenerators.wuw61umy:170: DeprecationWarning: Call to 
deprecated function compare_sample_files: Use 
beancount.ingest.regression_pytest instead

-- Docs: https://docs.pytest.org/en/latest/warnings.html
== 1 failed, 1632 passed, 22 skipped, 2 xfailed, 2 warnings in 137.49 seconds ==
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.7/build; python3.7 -m pytest -v
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned 
exit code 13
make: *** [debian/rules:13: binary-indep] Error 25
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit 
status 2


The above is just how the build ends and not necessarily the most relevant part,
so I've put a bunch of failed build logs here:

https://people.debian.org/~sanvila/build-logs/beancount/

The failure happens randomly. Sometimes it happens, sometimes it does not,
but the failure rate is so high that we can't really say that the package
"builds from source and without failure".

This failure is similar to another one which I reported before in another 
package:

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

but I'm not really sure if that helps.

If you need a test machine where this happens almost all the time, please 
contact me
privately and I will gladly offer ssh access.

Thanks.

Bug#923605: ITP: dhcpoptinj -- DHCP option injector

[Andreas Misje]

Package: dhcpoptinj
Severity: wishlist
Owner: Andreas Misje 

* Package name: dhcpoptinj
  Version : 0.4.2
  Upstream author : Andreas Misje 
* URL : https://github.com/misje/dhcpoptinj
* Licence : GPL-3.0
* Description : a simple utility for injecting DHCP options into
DHCP packets

I would like to package a project I have developed. It can be found at
https://github.com/misje/dhcpoptinj. The licence is GPL-3.0, but I am
open to change the licence to another permissive licence if need be.

The source already contains all files needed to produce a package with bash
completion and a man page, with no resulting Lintian errors. However, I am sure
it needs to be converted to non-native format. I'll do that once I get a little
bit of guidance on how to. My initial question is where to put the Debian
files. In a repo of its own? If so, where should such a repository live? On
salsa.debian.org?


Best regards,
-- 
Andreas Misje

Bug#921625: [Pkg-javascript-devel] Bug#921625: node-gyp install fails

[Jérémy Lal]

Le sam. 2 mars 2019 à 18:21, Paolo Greppi  a écrit :

> I got the same error on amd64 while running yarnpkg in root of vscode
> source:
>
> git clone https://github.com/Microsoft/vscode
> cd vscode
> yarnpkg
> ...
> [4/4] Building fresh packages...
> [1/14] ⠠ gc-signals
> [2/14] ⠠ keytar
> [3/14] ⠠ native-is-elevated
> [4/14] ⠐ native-keymap
> error /root/vscode/node_modules/gc-signals: Command failed.
> Exit code: 7
> Command: node-gyp rebuild
> Arguments:
> Directory: /root/vscode/node_modules/gc-signals
> Output:
> gyp info it worked if it ends with ok
> gyp info using node-gyp@3.8.0
> gyp info using node@10.15.1 | linux | x64
> gyp http GET
> https://atom.io/download/electron/v3.1.3/iojs-v3.1.3-headers.tar.gz
> gyp http 200
> https://atom.io/download/electron/v3.1.3/iojs-v3.1.3-headers.tar.gz
> gyp ERR! UNCAUGHT EXCEPTION
> gyp ERR! stack TypeError: Cannot read property 'substring' of undefined
> gyp ERR! stack at Unpack.isValid [as filter]
> (/usr/share/node-gyp/lib/install.js:160:30)
> gyp ERR! stack at Unpack.[consumeHeader]
> (/usr/lib/nodejs/tar/lib/parse.js:134:48)
> gyp ERR! stack at Unpack.[consumeChunkSub]
> (/usr/lib/nodejs/tar/lib/parse.js:385:30)
> gyp ERR! stack at Unpack.[consumeChunk]
> (/usr/lib/nodejs/tar/lib/parse.js:362:30)
> gyp ERR! stack at Unpack.write
> (/usr/lib/nodejs/tar/lib/parse.js:309:25)
> gyp ERR! stack at Gunzip.ondata (_stream_readable.js:667:20)
> gyp ERR! stack at Gunzip.emit (events.js:189:13)
> gyp ERR! stack at addChunk (_stream_readable.js:284:12)
> gyp ERR! stack at readableAddChunk (_stream_readable.js:265:11)
> gyp ERR! stack at Gunzip.Readable.push (_stream_readable.js:220:10)
> gyp ERR! System Linux 4.19.0-2-amd64
> gyp ERR! command "/usr/bin/node" "/usr/bin/node-gyp" "rebuild"
> gyp ERR! cwd /root/vscode/node_modules/gc-signals
> gyp ERR! node -v v10.15.1
> gyp ERR! node-gyp -v v3.8.0
>
> The strange thing is that if I cd /root/vscode/node_modules/gc-signals
> then:
> node-gyp rebuild
>
> it works fine.
>

There is indeed an issue here:
upstream node-gyp did not merge
https://github.com/nodejs/node-gyp/commit/5f924ce62c9bca9ab9c2e547bfb87b9a391271ed
into node-gyp branch 3.8, and thus is not compatible with node-tar 4.

Am going to fix that asap.

Jérémy


> Paolo
>
>

Bug#923604: RM: ruby-fog-radosgw -- ROM; not required, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of ruby-fog, which is now 
removed.

No other reverse dependencies.

Bug#923603: Drop continuity cli to reduce the Build-Depends

[Shengjing Zhu]

Source: continuity
Severity: wishlist

Hi Arnaud and team,

I want to know if you object to drop the continuity cli from this package.

IIUC, continuity is packaged to build containerd, and containerd only
needs the -dev package.

And the cli provided by continuity seems not useful to end users.

By not building the cli, this package can drop the dependency of:

+ golang-bazil-fuse-dev
+ golang-github-dustin-go-humanize-dev
+ golang-github-spf13-cobra-dev

Especially golang-github-spf13-cobra-dev brings lots of new dependencies.


-- 
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#222047: --configure should process essential packages first

[Guillem Jover]

Control: retitle -1 dpkg: Provide an interface for bootstrapping an installation

Hi!

On Sun, 2003-11-23 at 16:44:37 +0100, Koblinger Egmont wrote:
> Package: dpkg
> Version: 1.10.18

> Currently if more unconfigured packages are being configured, their
> ordered is determined by the Depends fields of the packages, however, the
> Essential field is not taken into account, hence it might (and actually
> does) occur that a non-essential package is configured earlier than an
> essential one.
> 
> This behaviour is against the policy that AFAIK essential packages
> required by a certain package do not need to be explicitely mentioned in
> the Depends field. Just one example: on a Debian 3.0 system nscd only
> depends on libc6, even if its startup script requires bash, shellutils
> (uname), grep and dpkg (start-stop-daemon), but these are all essential
> packages.
> 
> On a dpkg based (but not Debian) system I have a script that builds up a
> chroot system: it unpacks all the required .deb files to a directory, and
> later it runs "dpkg --root=... --configure -a". In most of the cases it
> runs perfectly. However, I've met the following interesting situation:
> building up the chroot failed if I put postgresql-server amongst the
> packages. postgresql-server invokes a "su -c command otheruser" command in
> its postinst script. However, su requires valid basic configuration, which
> isn't available as long as shadow (and possibly some other essential)
> packages are unconfigured (e.g. /etc/shells might not yet be present). The
> "dpkg --configure -a" step just randomly chose to configure
> postgresql-server earlier than shadow, and hence it failed. Obviously
> making postgresql-server depend on shadow solved the problem, but since
> shadow is an essential package, I expect that it shouldn't be necessary to
> mention it in postgresql-server's Depends field, I think the postinst
> script of a non-essential package could expect that essential packages are
> already configured.
> 
> So whenever more packages are being configured, essential ones should be
> processed first, before any non-essential ones.

As Santiago mentioned, you are describing here an installation
bootstrapping problem, so the problem you encounter should only ever
happen when the system is not yet in place, and the Essential semantics
have no meaning yet (because the Essential packages have never been
configured once). This is all in a different realm where the behavior
is currently unspecified. Also your proposal is not general enough, as
that does not cover implicit dependencies between Essential packages,
before they have been bootstrapped.

A proposed solution to this can be found at
.

Thanks,
Guillem

Bug#923599: RM: ruby-fog-riakcs -- ROM; not required, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of ruby-fog, which is now 
removed.

No other reverse dependencies.

Bug#923598: RM: ruby-azure-core -- ROM; not required, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of ruby-azure, which is 
now removed.

No other reverse dependencies.

Bug#923597: RM: ruby-fog-softlayer -- ROM; not required, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of ruby-fog, which is now 
removed.

No other reverse dependencies.

Bug#923596: RM: ruby-fog-serverlove -- ROM; not required, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of ruby-fog, which is now 
removed.

No other reverse dependencies.

Bug#921625: [Pkg-javascript-devel] Bug#921625: node-gyp install fails

[Paolo Greppi]

I got the same error on amd64 while running yarnpkg in root of vscode source:

git clone https://github.com/Microsoft/vscode
cd vscode
yarnpkg
...
[4/4] Building fresh packages...
[1/14] ⠠ gc-signals
[2/14] ⠠ keytar
[3/14] ⠠ native-is-elevated
[4/14] ⠐ native-keymap
error /root/vscode/node_modules/gc-signals: Command failed.
Exit code: 7
Command: node-gyp rebuild
Arguments:
Directory: /root/vscode/node_modules/gc-signals
Output:
gyp info it worked if it ends with ok
gyp info using node-gyp@3.8.0
gyp info using node@10.15.1 | linux | x64
gyp http GET https://atom.io/download/electron/v3.1.3/iojs-v3.1.3-headers.tar.gz
gyp http 200 https://atom.io/download/electron/v3.1.3/iojs-v3.1.3-headers.tar.gz
gyp ERR! UNCAUGHT EXCEPTION
gyp ERR! stack TypeError: Cannot read property 'substring' of undefined
gyp ERR! stack at Unpack.isValid [as filter] 
(/usr/share/node-gyp/lib/install.js:160:30)
gyp ERR! stack at Unpack.[consumeHeader] 
(/usr/lib/nodejs/tar/lib/parse.js:134:48)
gyp ERR! stack at Unpack.[consumeChunkSub] 
(/usr/lib/nodejs/tar/lib/parse.js:385:30)
gyp ERR! stack at Unpack.[consumeChunk] 
(/usr/lib/nodejs/tar/lib/parse.js:362:30)
gyp ERR! stack at Unpack.write (/usr/lib/nodejs/tar/lib/parse.js:309:25)
gyp ERR! stack at Gunzip.ondata (_stream_readable.js:667:20)
gyp ERR! stack at Gunzip.emit (events.js:189:13)
gyp ERR! stack at addChunk (_stream_readable.js:284:12)
gyp ERR! stack at readableAddChunk (_stream_readable.js:265:11)
gyp ERR! stack at Gunzip.Readable.push (_stream_readable.js:220:10)
gyp ERR! System Linux 4.19.0-2-amd64
gyp ERR! command "/usr/bin/node" "/usr/bin/node-gyp" "rebuild"
gyp ERR! cwd /root/vscode/node_modules/gc-signals
gyp ERR! node -v v10.15.1
gyp ERR! node-gyp -v v3.8.0

The strange thing is that if I cd /root/vscode/node_modules/gc-signals then:
node-gyp rebuild

it works fine.

Paolo

Bug#343578: dpkg: delete available-new when 'No space left on device'

[Guillem Jover]

Hi!

On Fri, 2005-12-16 at 11:42:02 +0100, A Mennucc wrote:
> Package: dpkg
> Version: 1.13.11.0.1
> Severity: normal

> did you ever ran out of disk space while installing/upgrading packages?
> When the dreaded message  "dpkg: . No space left on device" appears,
> you readily know it is time for a coffe and 25 minutes of messy
> hacking in your Debian box.
> 
> apt-get (and aptitude for that matter) are no help: they will
> stubbornly insist on reinstalling the last package that failed ("hey
> APT, guess what...  since it failed, it will not succeed next time
> around" ; unfortunately Super Cows do not have good ears :-) )
> 
> While you are cursing APT and the relatives, dpkg is not helping
> either: whenever it fails, it will leave two nice huge files around,
> /var/lib/dpkg/status-new and /var/lib/dpkg/available-new . Those two
> files are carefully designed to fill out your / device up to the last
> byte, so that any following command you issue will fail choking.
> 
> So here is my letter to Santa Bug: dear Santa, I promise I will be a
> better hacker next year (yes, I know I should not replace obnoxious
> sounds into my wife favourite videogames); but, pleeease, when 'dpkg'
> fails while writing /var/lib/dpkg/status-new and
> /var/lib/dpkg/available-new , could it also delete them?

dpkg does not write to these files by default anymore for some time
now. Some commands use it because that's their entire purpose, others
can be told to optionally use it (such as dpkg-query).

I don't think removing the -new file is a good idea, as that's
required to generate the new available file. If you are so short on
disk that this fails, and the available file is required then you
really need to free up space in the system.

What I can do, though I stop generating a backup for the available
file, as that's information that should be easy to regenerate and
there's no big loss if the available file gets damaged or disappears.
Targetting this change for 1.20.x.

Thanks,
Guillem

Bug#906322: [Pkg-pascal-devel] Bug#906322: fpc dependencies are too complex, confusing apt solver

[Abou Al Montacir]

Hi,
On Sun, 2018-08-19 at 08:19 +0200, Paul Gevers wrote:
> Hi,
> 
> On 17-08-18 16:54, Paul Gevers wrote:
> > > This means that while the packages are versioned, they
> > > are not co-installable, rendering the versioning useless.
> > 
> > I hope I reasoned why this is not useless. Co-installability is not our
> > worries here.
> 
> I think I wrote this too quickly. co-installability was of course the
> reason for the versioned packages (that you suggested to get rid of).
> The idea is that upgrades leave behind the old versioned packages (and I
> have seen that happening), so you can still compile your programs with
> the older versions if you want to. So I don't understand why apt tries
> to remove the old packages. Do you know why? Because of course it is
> possible that we made some mistake in the dependencies. Or could it be
> that this behavior of apt changed sometime in the last years, or that
> this behavior depends on an apt option?
I do have machines with more than one FPC versions and upgrades are just smooth.
Sometimes, old code doe not compile with a new compiler due to soem non backward
evolutions, then users may want to keep old compiler until they port their code
to the new version.

Also the breaks are only added when a substantial change in packages are made
and this happened only a few times.
So stating that 
fpc-$foo-3.0.4 Breaks fpc (<= 3.0.4)
is a quick deduction I assume.

Can you please check with recent apt and let us know what exact upgrade scenario
is failing?
-- 
Cheers,
Abou Al Montacir



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

Bug#923594: [Tts-project] Bug#923594: speech-dispatcher fails with PulseAudio

[Samuel Thibault]

Hello,

Alex Bernier, le sam. 02 mars 2019 15:18:16 +0100, a ecrit:
> (I do not exactly know if the problem described below is related to Speech 
> Dispatcher or PulseAudio.)
> 
> Speech Dispatcher doesn't start anymore; every modules I can test is 
> concerned and fails with the same error :
> 
> pulse.c: pa_simple_new() failed: Connection refused

Do other applications using pulseaudio work?

Samuel

Bug#874950: src:keepassx: port to Qt 5

[John Scott]

Package: src:keepassx
Followup-For: Bug #874950
Control: tags -1 fixed-upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Though I can't find a single statement upstream,
it seems that KeePassX moved a while ago [1]. No
new release has been made yet, but master builds
on my system and runs, though I didn't test it
more.

The wiki [2] seemed to imply that KeePassXC would
replace it after the Qt 4 removal. Upstream has
been active keeping it working with recent Qt [3],
so it's my intent to clarify that.

[1] https://dev.keepassx.org/issues/394
[2] https://github.com/keepassx/keepassx
[3] 
https://github.com/keepassx/keepassx/commit/1682ab90243ef93449a981eb7b8046b629720488

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEAXEkn09uX7g8Tv8W3qerYfa4vJcFAlx6tf4ACgkQ3qerYfa4
vJfuwQf/fqxGpQpDCTbJDo6Rx34fW79dnNawGr7GIh6bo3W5jKxhsSAhv52GSwFd
vrrGdwbi9OgTk+JILKuYQwGYILLdnAJsTUJo2+YrPtCA9lUMjxGHLLVuDXNpu/Um
vyOHhGSL+aQsgqIlrXvrUJ4/9GOiBX9bqwW1kG7X3VRozeBPvCNvJS3K4cs47fH3
iXfFLZ3+jB9Ko2YWP3919cZgWzMpRvR9ZwfowTEDvCeclodhyGHsKVx3NAUAEEvd
DH3MNK2RyFZzjh44lEoagf4pBPxjVo/8A4RI/mQMet0sRUUeCvt3bm/mIOnPWQwM
qJGnbAc74DLGiIs6QXwIuthxO9JnZA==
=XKkS
-END PGP SIGNATURE-

Bug#923595: electrum: Electrum branch containing critical vulnerability should be updated

[Michael S]

Package: electrum
Version: 3.1.3-1~bpo9+1
Severity: important

Dear Maintainer,

Having the fact that all versions of Electrum older than 3.3.3 are vulnerable 
to a phishing attack (https://github.com/spesmilo/electrum/issues/4968 also 
warning on http://electrum.org), where malicious servers ask users to download 
bitcoin-stealing malware, why are we still on 3.1.3 branch on Debian Stable?

I think Electrum packages on all Debian versions should be updated urgently. 
It's almost impossible to use this software, because every time we try to make 
a transaction, a phinshing server asks us to download a fresh version of 
electrum from a fake domain.

Please consider moving to 3.3.4 on Debian Stable and Sid, since it's not a 
software that requires compilation, it shouldn't be a big mess to upgrade.

-- System Information:
Debian Release: 9.8
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'trusty-security'), (500, 'stable-updates')
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 electrum depends on:
ii  python3   3.5.3-1
ii  python3-electrum  3.1.3-1~bpo9+1

Versions of packages electrum recommends:
ii  python3-pyqt5  5.7+dfsg-5

Versions of packages electrum suggests:
pn  python3-btchip  
pn  python3-trezor  
pn  python3-zbar

-- no debconf information

Bug#923594: speech-dispatcher fails with PulseAudio

[Alex Bernier]

Package: speech-dispatcher
Version: 0.9.0-5
Severity: normal

Dear Maintainer,

(I do not exactly know if the problem described below is related to Speech 
Dispatcher or PulseAudio.)

Speech Dispatcher doesn't start anymore; every modules I can test is concerned 
and fails with the same error :


pulse.c: pa_simple_new() failed: Connection refused

Two precisions :
* On the LightDM login screen, Speech Dispatcher starts correctly
* After login, Speech Dispatcher does not start and Orca does not detect it (in 
the Orca settings, the TTS list does not appear anymore)

Alex



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

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

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


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

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

Versions of packages speech-dispatcher depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-7
ii  libdotconf0  1.3-0.3
ii  libglib2.0-0 2.58.3-1
ii  libltdl7 2.4.6-9
ii  libsndfile1  1.0.28-5
ii  libspeechd2  0.9.0-5
ii  lsb-base 10.2018112800
ii  speech-dispatcher-audio-plugins  0.9.0-5

Versions of packages speech-dispatcher recommends:
ii  pulseaudio   12.2-4
ii  sound-icons  0.1-6
ii  speech-dispatcher-espeak-ng  0.9.0-5

Versions of packages speech-dispatcher suggests:
pn  espeak  
ii  libttspico-utils1.0+git20130326-9
pn  mbrola  
pn  speech-dispatcher-cicero
pn  speech-dispatcher-doc-cs
pn  speech-dispatcher-espeak
pn  speech-dispatcher-festival  
pn  speech-dispatcher-flite 

-- no debconf information

Bug#923593: grub-common: update-grub creates menu entries for gpg detached signatures of kernels

[Matt Patey]

Package: grub-common
Version: 2.02+dfsg1-12
Severity: normal
Tags: patch

Dear Maintainer,

When `check_signatures` is set to enforce, grub looks for and verifies detached
GPG signatures for the kernels before loading them. These signatures have the
extension .sig.

When detached signatures are present `update-grub` mistakenly identifies them
as kernels and creates invalid menu entries for them.


Expected behaviour:

  admin@lpad:~$ sudo update-grub
  Generating grub configuration file ...
  Found background image: .background_cache.png
  Found linux image: /boot/vmlinuz-4.19.0-2-amd64
  Found initrd image: /boot/initrd.img-4.19.0-2-amd64
  Found linux image: /boot/vmlinuz-4.19.0-1-amd64
  Found initrd image: /boot/initrd.img-4.19.0-1-amd64
  done

Observed behaviour:

  admin@lpad:~$ sudo update-grub
  Generating grub configuration file ...
  Found background image: .background_cache.png
  Found linux image: /boot/vmlinuz-4.19.0-2-amd64.sig
  Found initrd image: /boot/initrd.img-4.19.0-2-amd64.sig
  Found linux image: /boot/vmlinuz-4.19.0-2-amd64
  Found initrd image: /boot/initrd.img-4.19.0-2-amd64
  Found linux image: /boot/vmlinuz-4.19.0-1-amd64.sig
  Found initrd image: /boot/initrd.img-4.19.0-1-amd64.sig
  Found linux image: /boot/vmlinuz-4.19.0-1-amd64
  Found initrd image: /boot/initrd.img-4.19.0-1-amd64
  done

I've attached a patch to /usr/share/grub-mkconfig_lib that fixes this.




-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/matrix-rootvol / ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/matrix-homevol /home ext4 rw,relatime 0 0
/dev/sda2 /boot ext4 rw,relatime 0 0
/dev/mapper/matrix-optvol /opt ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 
--hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  
c25115c2-53f1-4eba-a73e-48c932fa7168
else
  search --no-floppy --fs-uuid --set=root c25115c2-53f1-4eba-a73e-48c932fa7168
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_GB
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 
--hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  
c25115c2-53f1-4eba-a73e-48c932fa7168
else
  search --no-floppy --fs-uuid --set=root c25115c2-53f1-4eba-a73e-48c932fa7168
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-02a861cb-d2c1-4358-8132-8dedd88fb6d0' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy 

Bug#921840: the patch / Re: Fwd: Re: Upload necessary before March 2nd (Buster hard freeze), Bug #921840 NOAA URL -> https

[Joost van Baal-Ilić]

Hi Kees,

Attached is the work I did to create metar_20190227.1-1 : the diff with
what's in https://github.com/keesL/metar/tree/master/debian now.

Bye,

Joost




On Sat, Mar 02, 2019 at 03:34:59PM +0100, Joost van Baal-Ilić wrote:
> Hi Kees,
> 
> I took the liberty to upload metar_20190227.1-1, based upon what's currently
> in the github repository.  Because of the time contrains I took some
> shortcuts.
> 
> I'll mail you the relevant patch soonish: it'd be helpful
> if you could keep it in your repository.
> 
> Thanks, Bye,
> 
> Joost



diff -durN debian/changelog /home/joostvb/git/metar/debian/changelog
--- debian/changelog	2019-03-02 14:24:30.413309514 +
+++ /home/joostvb/git/metar/debian/changelog	2019-03-01 06:12:52.022987249 +
@@ -1,24 +1,14 @@
-metar (20190227.1-1) unstable; urgency=medium
-
-  [ Kees Leune ]
-  * New upstream release (Closes: #921840, thanks Sven Paulus)
-  - Merge pull request #5 from subsven.  This fixes the URL change at
-NOAA from HTTP to HTTPS.
+metar (20190227.1-1.1) unstable; urgency=medium
 
-  [ Joost van Baal-Ilić ]
-  * debian/source/format: explicitly set to modern 3.0 (quilt).
-  * debian/rules: for now give up updating config.{guess,sub} since it
-breaks generating a source package.
-  * debian/control: fix Homepage url.
-  * debian/control: add myself to Uploaders, after discussing with Kees.
+  * Updated default URL to NOAAs new https URL
 
- -- Joost van Baal-Ilić   Sat, 02 Mar 2019 13:56:49 +
+ -- Kees Leune   Wed, 27 Feb 2019 19:07:51 -0500
 
 metar (20170329.1-1) unstable; urgency=low
 
   * Added mps as wind unit
 
- -- Kees Leune   Mon, 29 May 2017 14:41:25 -0400
+ -- Kees Leune  Mon, 29 May 2017 14:41:25 -0400
 
 metar (20161013.1-1) unstable; urgency=low
 
diff -durN debian/control /home/joostvb/git/metar/debian/control
--- debian/control	2019-03-02 14:22:33.050648918 +
+++ /home/joostvb/git/metar/debian/control	2019-03-01 06:12:52.022987249 +
@@ -2,10 +2,9 @@
 Section: utils
 Priority: optional
 Maintainer: Kees Leune 
-Uploaders: Joost van Baal-Ilić 
 Standards-Version: 3.9.6
 Build-Depends: libcurl4-openssl-dev, debhelper (>=9)
-Homepage: http://github.com/keesL/metar
+Homepage: http://github.com/keesl/metar
 
 Package: metar
 Architecture: any
diff -durN debian/files /home/joostvb/git/metar/debian/files
--- debian/files	1970-01-01 00:00:00.0 +
+++ /home/joostvb/git/metar/debian/files	2019-03-01 06:12:52.022987249 +
@@ -0,0 +1 @@
+metar_20161013.1-1_amd64.deb utils optional
diff -durN debian/rules /home/joostvb/git/metar/debian/rules
--- debian/rules	2019-03-02 14:17:05.319237651 +
+++ /home/joostvb/git/metar/debian/rules	2019-03-01 06:12:52.022987249 +
@@ -62,12 +62,12 @@
 	rm -f build-stamp 
 
 	[ ! -f Makefile ] || $(MAKE) distclean
-#ifneq "$(wildcard /usr/share/misc/config.sub)" ""
-#	cp -f /usr/share/misc/config.sub config.sub
-#endif
-#ifneq "$(wildcard /usr/share/misc/config.guess)" ""
-#	cp -f /usr/share/misc/config.guess config.guess
-#endif
+ifneq "$(wildcard /usr/share/misc/config.sub)" ""
+	cp -f /usr/share/misc/config.sub config.sub
+endif
+ifneq "$(wildcard /usr/share/misc/config.guess)" ""
+	cp -f /usr/share/misc/config.guess config.guess
+endif
 
 
 	dh_clean 
diff -durN debian/source/format /home/joostvb/git/metar/debian/source/format
--- debian/source/format	2019-03-02 14:03:39.653459425 +
+++ /home/joostvb/git/metar/debian/source/format	1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-3.0 (quilt)


signature.asc
Description: Digital signature

Bug#712451: Please support AppArmor network rules

[Paolo Greppi]

I looked at the status of this on buster:

uname -a
Linux localhost.localdomain 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) 
x86_64 GNU/Linux

and the issue still can be reproduced (in the sense that telnet.netkit network 
access will not be blocked after enforcing the rule).

Except it is worse because this command:
sudo apparmor_parser -vr  /etc/apparmor.d/usr.bin.telnet.netkit
does not show anymore the message "network rules not enforced".

Should this be documented in /usr/share/doc/apparmor/README.Debian ?

This currently refers to: https://wiki.debian.org/AppArmor but there is no 
mention of this limitation in there.

Paolo

Bug#923447: openssl breaks r-cran-openssl autopkgtest

[Sébastien Villemot]

Le samedi 02 mars 2019 à 17:17 +0100, Sebastian Andrzej Siewior a écrit :
> On 2019-03-02 11:54:54 [+0100], Sébastien Villemot wrote:
> > Le samedi 02 mars 2019 à 11:26 +0100, Sebastian Andrzej Siewior a écrit :
> > > 
> > > So if the bug is really in libssl1.1 then I don't see why you should do
> > > something. I will try to backport that commit then and make a new
> > > upload.
> > 
> > Note that the bug has already been fixed in Debian (r-cran-openssl
> > 1.2.2+dfsg-1), so no need for a new upload.
> 
> Now I am confused. It is either a bug in openssl and should be fixed or
> it is a bug in r-cran-openssl and should be fixed there.
> So which one is it?

From Debian's point of view, it is now both, since the bug has been
cloned: #923447 for r-cran-openssl (which is now fixed), and #923516
for openssl (still open).

There is nothing left to do for r-cran-openssl now, at least for
buster.

For openssl, it's up to its maintainers to decide what to do now.

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


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

Bug#923447: openssl breaks r-cran-openssl autopkgtest

[Sebastian Andrzej Siewior]

On 2019-03-02 11:54:54 [+0100], Sébastien Villemot wrote:
> Le samedi 02 mars 2019 à 11:26 +0100, Sebastian Andrzej Siewior a écrit :
> > 
> > So if the bug is really in libssl1.1 then I don't see why you should do
> > something. I will try to backport that commit then and make a new
> > upload.
> 
> Note that the bug has already been fixed in Debian (r-cran-openssl
> 1.2.2+dfsg-1), so no need for a new upload.

Now I am confused. It is either a bug in openssl and should be fixed or
it is a bug in r-cran-openssl and should be fixed there.
So which one is it?

> Thanks,
> 

Sebastian

Bug#657730: Confirmed in 3.39.1+dfsg-2 (buster)

[Johan Haggi]

Nicholas D Steeves wrote 9 Feb 2019:
> This bug refers to an old (or ancient!) version of Calibre. [...]
> [...]
> Alternatively, if you're running buster/sid, please confirm if 
> 3.39.1+dfsg-1 is affected.


I have an old machine ( dir /lost+found = Jan 9 2012) and calibre has
always worked, last use was 2 or 3 weeks ago, last ugrade were:
2019-01-03: calibre-bin:amd64 (3.35.0+dfsg-1, 3.35.0+dfsg-1+b1)
2019-02-24: calibre-bin:amd64 (3.35.0+dfsg-1+b1, 3.39.1+dfsg-2
calibre:amd64 (3.35.0+dfsg-1, 3.39.1+dfsg-2)

Today I have the same error (crash before starting) in buster (calibre
3.39.1+dfsg-2).

with calibre
Traceback (most recent call last):
  File "/usr/bin/calibre", line 20, in 
sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 73, in calibre
from calibre.gui2.main import main
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 22, in 
from calibre.utils.date import UNDEFINED_DATE
  File "/usr/lib/calibre/calibre/utils/date.py", line 15, in 
from calibre.utils.iso8601 import utc_tz, local_tz, UNDEFINED_DATE
  File "/usr/lib/calibre/calibre/utils/iso8601.py", line 9, in 
from dateutil.tz import tzlocal, tzutc, tzoffset
  File "/usr/lib/python2.7/dist-packages/dateutil/tz/__init__.py", line 2, in 

from .tz import *
  File "/usr/lib/python2.7/dist-packages/dateutil/tz/tz.py", line 19, in 

from six.moves import _thread
ImportError: cannot import name _thread

with ebook-viewer
Traceback (most recent call last):
  File "/usr/bin/ebook-viewer", line 20, in 
sys.exit(ebook_viewer())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 81, in ebook_viewer
from calibre.gui2.viewer.main import main
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 22, in 
from calibre.utils.date import UNDEFINED_DATE
  File "/usr/lib/calibre/calibre/utils/date.py", line 15, in 
from calibre.utils.iso8601 import utc_tz, local_tz, UNDEFINED_DATE
  File "/usr/lib/calibre/calibre/utils/iso8601.py", line 9, in 
from dateutil.tz import tzlocal, tzutc, tzoffset
  File "/usr/lib/python2.7/dist-packages/dateutil/tz/__init__.py", line 2, in 

from .tz import *
  File "/usr/lib/python2.7/dist-packages/dateutil/tz/tz.py", line 19, in 

from six.moves import _thread
ImportError: cannot import name _thread

I use the suggested trick of purge calibre calibre-bin and I have this
dpkg warning:

Rimozione di calibre (3.39.1+dfsg-2)...
[...] directory "/usr/lib/calibre/calibre/library" è risultata non vuota e non 
viene rimossa
[...] directory "/usr/lib/calibre/calibre/gui2/dialogs" è risultata non vuota e 
non viene rimossa
[...] directory "/usr/lib/calibre/calibre/ebooks/metadata/sources" è risultata 
non vuota e non viene rimossa
[...] directory "/usr/lib/calibre/calibre/devices" è risultata non vuota e non 
viene rimossa
Rimozione di calibre-bin (3.39.1+dfsg-2)...
[...] directory "/usr/lib/calibre/calibre" è risultata non vuota e non viene 
rimossa

  (in english: directory ... is non empty and it is not removed)

  After the purge:

ls /usr/lib/calibre/
calibre  html5lib  six.pycls
   (calibre and html5lib were directory, six.pyc was a file)

dpkg -S /usr/lib/calibre
dpkg-query: nessun percorso corrispondente a /usr/lib/calibre
   (English: no path for /usr/lib/calibre)

rm -rv /usr/lib/calibre
'/usr/lib/calibre/calibre/gui2/dialogs/confirm_delete_ui.pyc' rimosso
'/usr/lib/calibre/calibre/gui2/dialogs/search_ui.pyc' rimosso
removed directory '/usr/lib/calibre/calibre/gui2/dialogs'
'/usr/lib/calibre/calibre/gui2/shortcuts_ui.pyc' rimosso
removed directory '/usr/lib/calibre/calibre/gui2'
'/usr/lib/calibre/calibre/devices/apple/__init__.pyc' rimosso
'/usr/lib/calibre/calibre/devices/apple/driver.pyc' rimosso
removed directory '/usr/lib/calibre/calibre/devices/apple'
'/usr/lib/calibre/calibre/devices/bambook/__init__.pyc' rimosso
'/usr/lib/calibre/calibre/devices/bambook/driver.pyc' rimosso
'/usr/lib/calibre/calibre/devices/bambook/libbambookcore.pyc' rimosso
removed directory '/usr/lib/calibre/calibre/devices/bambook'
removed directory '/usr/lib/calibre/calibre/devices'
'/usr/lib/calibre/calibre/library/server/__init__.pyc' rimosso
removed directory '/usr/lib/calibre/calibre/library/server'
removed directory '/usr/lib/calibre/calibre/library'
'/usr/lib/calibre/calibre/ebooks/metadata/sources/isbndb.pyc' rimosso
removed directory '/usr/lib/calibre/calibre/ebooks/metadata/sources'
removed directory '/usr/lib/calibre/calibre/ebooks/metadata'
removed directory '/usr/lib/calibre/calibre/ebooks'
removed directory '/usr/lib/calibre/calibre'
'/usr/lib/calibre/six.pyc' rimosso
'/usr/lib/calibre/html5lib/constants.pyc' rimosso
'/usr/lib/calibre/html5lib/treebuilders/etree.pyc' rimosso
'/usr/lib/calibre/html5lib/treebuilders/_base.pyc' rimosso
'/usr/lib/calibre/html5lib/treebuilders/etree_lxml.pyc' rimosso
'/usr/lib/calibre/html5lib/treebuilders/__init__.pyc' rimosso
removed directory '/usr/lib/calibre/html5lib/treebuilders'

Bug#923446: m2crypto: autopkgtest with new version of openssl: Connection refused

[Sebastian Andrzej Siewior]

control: tags -1 patch

On 2019-03-01 23:27:47 [+0100], To Paul Gevers wrote:
> debugging on openssl side gives me the same result as in #923448 which
No. I've been testing the wrong package…

So m2crypto fails due to openssl commit 1c31fe7eb093:
|Author: Sam Roberts 
|Date:   Mon Nov 26 13:58:52 2018 -0800
|
|Ignore cipher suites when setting cipher list
|
|set_cipher_list() sets TLSv1.2 (and below) ciphers, and its success or
|failure should not depend on whether set_ciphersuites() has been used to
|setup TLSv1.3 ciphers.
|
|Reviewed-by: Paul Dale 
|Reviewed-by: Ben Kaduk 
|Reviewed-by: Matt Caswell 
|(Merged from https://github.com/openssl/openssl/pull/7759)
|
|(cherry picked from commit 3c83c5ba4f6502c708b7a5f55c98a10e312668da)

The thing is that m2ctypto uses TLS1.3 cipher but uses the -cipher
option instead of -ciphersuites which is for TLS1.3:
|$ openssl s_server --help 2>&1 |grep -- -cipher
| -cipher valSpecify TLSv1.2 and below cipher list to be used
| -ciphersuites val  Specify TLSv1.3 ciphersuites to be used

The patch attached against m2crypto fixes the testsuite issue.

Sebastian
>From 862167880780c1b1219b6be3864ba587f0bdddba Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Sat, 2 Mar 2019 17:08:39 +0100
Subject: [PATCH] tests/test_ssl: use -ciphercuites for TLS1.3 cipher in
 openssl1.1

The -cipher can not be used in OpenSSL 1.1.b+ for TLS1.3 cipher since
openssl upstream commit 1c31fe7eb093a ("Ignore cipher suites when
setting cipher list").

Use -ciphersuites for TLS1.3 cipher as documented.

Signed-off-by: Sebastian Andrzej Siewior 
---
 tests/test_ssl.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/test_ssl.py b/tests/test_ssl.py
index a3e2a318c315..925d365a5810 100644
--- a/tests/test_ssl.py
+++ b/tests/test_ssl.py
@@ -460,9 +460,10 @@ sleepTime = float(os.getenv('M2CRYPTO_TEST_SSL_SLEEP', '1.5'))
 def test_cipher_ok(self):
 if OPENSSL111:
 TCIPHER = 'TLS_AES_256_GCM_SHA384'
+self.args = self.args + ['-ciphersuites', TCIPHER]
 else:
 TCIPHER = 'AES128-SHA'
-self.args = self.args + ['-cipher', TCIPHER]
+self.args = self.args + ['-cipher', TCIPHER]
 
 pid = self.start_server(self.args)
 try:
-- 
2.20.1

Bug#923591: It would be nice to have a keyboard shortcut to restore window in featherpad

[shirish शिरीष]

Package: featherpad
Version: 0.9.3-1
Severity: wishlist

Dear Maintainer,

Currently there is no way to have a keyboard shortcut for restoring
window. I looked at the shortcuts and didn't find a way. Could you
please see if such an option is also available, instead of just using
the mouse.


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

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

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

Versions of packages featherpad recommends:
ii  libglib2.0-bin  2.58.3-1

featherpad suggests no packages.

-- no debconf information


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

Bug#923590: there is no documentation about featherpad

[shirish शिरीष]

Package: featherpad
Version: 0.9.3-1
Severity: normal

Dear Maintainer,

There is no documentation about featherpad. It would be nice if it had
a man page.

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

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

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

Versions of packages featherpad recommends:
ii  libglib2.0-bin  2.58.3-1

featherpad suggests no packages.

-- no debconf information


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

Bug#923589: lintian: Add check to complain about filename in debian/watch

[Hilko Bengen]

Package: lintian
Version: 2.9.1
Severity: normal

Dear Maintainer,

dh_make generates the following template for Github-based projects:

# GitHub hosted projects
#opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%-$1.tar.gz%" \
#   https://github.com//#PACKAGE#/tags \
#   (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate

I just came across a package where the "" bit had not been
edited. I can't think of anybody who wants filenames consisting of shell
metacharacters appearing in his working directories, so there might as
well be a Lintian check for that.

Cheers,
-Hilko

Bug#923588: libifd-cyberjack6 is outdated

[David Haller]

Package: libifd-cyberjack6
Version: 3.99.5final.sp09-1.1

Hello there,

the pcsc-cyberjack driver is highly outdated (sp09, current upstream is
sp13). This is relevant for users of the "cyberJack komfort" card reader
and the German eID card (Personalausweis), as driver versions sp12 and
older cause pcscd to crash when used with that specific card reader. The
bug has been fixed with version sp13.

See: https://bugzilla.redhat.com/show_bug.cgi?id=1554806#c4

I suggest to update the package to the new version.

Best regards,
David Haller

Bug#923364: FTBS: Can't build against bouncy-castle build with newer jdk

[Markus Koschany]

Control: tags -1 moreinfo

On Tue, 26 Feb 2019 23:07:43 +0100 Sjoerd Simons  wrote:
> Package: libitext-java
> Version: 2.1.7-12
> Severity: serious
> Tags: patch
> 
> Hey,
> 
> When rebuilding bouncy-castle the jar doesn't seem to have the same classpath

Hello, I guess you meant libitext-java?

> built-in as older builds did; specifically comparing a rebuild with an old
> debian build the MANIFEST.MF has the following diff (among other bits):
>   -Class-Path: bcprov.jar bcpkix.jar javax.mail.jar
>   +Class-Path: /usr/share/java/javax.mail.jar

I have just successfully rebuilt libitext-java and installed it. The
MANIFEST file of itext.jar looks normal to me:

Class-Path: /usr/share/java/bcprov.jar /usr/share/java/bcmail.jar /usr/s
 hare/java/bcpkix.jar

The classpath is defined in debian/libitext-java.classpath

Could you elaborate on why this is a bug in libitext-java and how this
is connected to bouncycastle?



signature.asc
Description: OpenPGP digital signature

Bug#923444: bacula: autopkgtest regressed in buster

[Carsten Leonhardt]

Hi,

maybe using a trigger can help us:

In bacula-director-psql/mysql postinst, pseudo code:

1 if (database server is being installed in the same run)
2   then (install trigger to postpone database setup)
3   else (setup database now)
4 if triggered: (setup database now)

Thoughts/explanations:
Step 1: I haven't researched yet if it's possible to reliably detect
that
Step 3: set up now as we won't get triggered later
Step 4: But what to trigger on exactly? 


An simple but stupid and unelegant alternative would be to generate meta
packages "bacula-director-local-psql/mysql" that _depend_ on the database
server packages.

 - Carsten

Bug#921840: Fwd: Re: Upload necessary before March 2nd (Buster hard freeze), Bug #921840 NOAA URL -> https

[Joost van Baal-Ilić]

Hi Kees,

I took the liberty to upload metar_20190227.1-1, based upon what's currently
in the github repository.  Because of the time contrains I took some
shortcuts.

I'll mail you the relevant patch soonish: it'd be helpful
if you could keep it in your repository.

Thanks, Bye,

Joost

On Fri, Mar 01, 2019 at 02:54:58PM -0500, Kees Leune wrote:
> Ok!
> 
> On Fri, Mar 1, 2019 at 2:49 PM Joost van Baal-Ilić 
> wrote:
> 
> > Hoi Kees,
> >
> > ( @ bugs.debian.org: sorry for speaking dutch here )
> >
> > Of ben je anders van plan een .tar.gz release te maken?
> > Volgens je eigen instructies gaat dat met"
> >
> > 0. Assign a new version number in VERSION.m4, commit, push
> > 1. Clone the repository from github
> > 2. Remove .git/
> > 3. rename the repository directory as metar-newversion-1
> > 4. create a new tarball
> > tar c --exclude debian -zf metar_newversion-1.origin.tar.gz
> >
> >
> > Kun je die .tar.gz dan op github in "releases" zetten?  Of zet hem
> > anders ergens op https://leune.org/ ter download, dat kan ook.
> >
> > Dan kan ikzelf wel voor de debian packaging zorgen.
> >
> > Groeten,
> >
> > Joost
> >
> >
> > On Thu, Feb 28, 2019 at 08:05:28PM +0100, Joost van Baal-Ilić wrote:
> > > Hoi hoi,
> > >
> > > OK, ik wacht ongeveer 24 uur af; daarna ga ikzelf wel aan de slag.
> > Verwacht
> > > dat we op die manier de deadline wel gaan halen :)
> > >
> > > Heel hartelijk bedankt iig!
> > >
> > > Groeten,
> > >
> > > Joost
> > >
> > > On Thu, Feb 28, 2019 at 01:51:43PM -0500, Kees Leune wrote:
> > > > Hallo!
> > > >
> > > > Ik ben gisteren begonnen aan het package; kennelijk zijn de packaging
> > rules
> > > > weer veranderd en moet ik het hele ding naar nieuwe standaarden brengen
> > > > voordat ik een schone linitian krijg. Dat kost (misschien) meer tijd
> > dan ik
> > > > heb, maar ik zal het proberen.
> > > >
> > > >
> > > > On Thu, Feb 28, 2019 at 6:13 AM Joost van Baal-Ilić <
> > joos...@debian.org>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Yes, I could invest one hour in getting this solved.
> > > > >
> > > > > Kees: laat me maar weten wat je nodig hebt.  (En hoe is t verder?)
> > > > >
> > > > > Groeten, Bye, Tschüß,
> > > > >
> > > > > Joost
> > > > >
> > > > >
> > > > > On Thu, Feb 28, 2019 at 11:43:04AM +0100, Daniel Lange wrote:
> > > > > > Hi Joost,
> > > > > >
> > > > > > we need an upload of a fixed metar before March 2nd to fix bug
> > #921840.
> > > > > > Kees will prepare that and I would have uploaded it today but my
> > internet
> > > > > > connection has been cut earlier today and will need 1-2 days for
> > fixing.
> > > > > So
> > > > > > I'm using the phone to tether. No builds that way.
> > > > > >
> > > > > > So could you kindly jump in and co-ordinate with Kees to get metar
> > > > > uploaded?
> > > > > >
> > > > > > Kind regards,
> > > > > > Daniel
> > > > > >
> > > > > >
> > > > > >  Weitergeleitete Nachricht 
> > > > > > Betreff:  Re: Upload necessary before March 2nd (Buster hard
> > > > > freeze), Bug
> > > > > > #921840 NOAA URL -> https
> > > > > > Datum:Wed, 27 Feb 2019 09:51:41 -0500
> > > > > > Von:  Kees Leune 
> > > > > > An:   Daniel Lange 
> > > > > >
> > > > > >
> > > > > >
> > > > > > The process was very different back then ;) Joost van Baal did my
> > initial
> > > > > > uploads.
> > > > > >
> > > > > > I'll take care of this later today!
> > > > > >
> > > > > > On Wed, Feb 27, 2019 at 9:16 AM Daniel Lange  > > > > > > wrote:
> > > > > >
> > > > > > Hi Kees,
> > > > > >
> > > > > > Am 27.02.19 um 15:07 schrieb Kees Leune:
> > > > > >  > No problem. How do I upload?
> > > > > >
> > > > > > You seem to have been able to upload yourself in the past (at
> > least
> > > > > > until 2007):
> > > > > > https://tracker.debian.org/pkg/metar
> > > > > > Or may be the process was vastly different back then from
> > today.
> > > > > >
> > > > > > In any case you can upload to https://mentors.debian.net/
> > > > > > and I or somebody else can grab it and upload for you.
> > > > > >
> > > > > > Kind regards,
> > > > > > Daniel
> > > > > >
> > > > > > --
> > > > > > https://www.leune.org/about
> > > > >
> > > >
> > > >
> > > > --
> > > > https://www.leune.org/about
> >
> -- 
> https://www.leune.org/about

Bug#923587: Please give back radare2-cutter on armhf, mipsel

[Hilko Bengen]

Package: release.debian.org
Severity: normal

radare2-cutter could not be built against radare2 between 3.2.1+dfsg-2
and 3.2.1+dfsg-5 due to missing build-dependencies (#923341).

  gb radare-cutter_1.7.4-2 . armhf mipsel

Thank you.

Cheers,
-Hilko

Bug#923586: matrix-synapse: hard to troubleshoot server's name left blank

[sergio]

Package: matrix-synapse
Version: 0.99.0-1~bpo9+3
Severity: normal

It's extremely hard to understand what's wrong if the "Name of the
server" was accidentally left blank during the installation process.
Daemon just won't start. Not output will be produced. Moreover the exit
status will be 0! The log file is absent.

# service matrix-synapse start && echo OK
OK
# /etc/init.d/matrix-synapse start && echo OK
OK
# invoke-rc.d matrix-synapse start && echo OK
OK


The only way to understand what's wrong is to run it directly:

# python3 -m "synapse.app.homeserver" --config-path 
/etc/matrix-synapse/homeserver.yaml

Missing mandatory `server_name` config option.

Bug#923573: PermissionError: [Errno 13] Permission denied: '/etc/matrix-synapse/homeserver.signing.key'

[sergio]

On 02/03/2019 16:55, Andrej Shadura wrote:

Well, not with sysvinit. You cannot expect the init script to undo all 
possible combinations of settings the user might set.



% grep -R umask /etc/init.d
/etc/init.d/ferm:   umask 0077
/etc/init.d/bootlogd:   umask 027
/etc/init.d/sysstat:umask 022
/etc/init.d/urandom:umask 077
/etc/init.d/urandom:umask 022
/etc/init.d/urandom:umask 077
/etc/init.d/deluged:  --chuid $USER --umask $MASK --test > /dev/null \
/etc/init.d/deluged:  --chuid $USER --umask $MASK -- $DAEMON_ARGS \
/etc/init.d/rc: umask 022
/etc/init.d/ssh:umask 022
/etc/init.d/umountfs:   umask 022


--
sergio.

Bug#923358: libdist-inkt-perl: Stuffs full path into tarball

[Jonas Smedegaard]

Quoting Niko Tyni (2019-03-02 14:44:38)
> On Sat, Mar 02, 2019 at 01:45:19PM +0100, Jonas Smedegaard wrote:
> > reassign -1 perl
> > retitle -1 perl: breaks libdist-inkt-perl
> > thanks
> 
> I don't think this worked. Presumably you forgot to bcc
> control@bdo.

Yes.


> But never mind that, I think it's libdist-inkt-perl that needs
> to change. See below.

Oh, ok.  I'll cancel my composing a "bts" command, then :-)


> > Quoting Jonas Smedegaard (2019-02-26 22:41:00)
> > > The command distinkt-dist is completely useless: Produces tarballs 
> > > containing full path (not paths relative to build dir), and then 
> > > fails.
> > > 
> > > Upstream bug: https://github.com/tobyink/p5-dist-inkt/issues/3
> > 
> > Seems to be a bug not in libdist-inkt-perl but in recent perl - or one 
> > of the libraries upgraded in lockstep with perl.
> > 
> > Testsuite does not reveal the bug (it is quite minimal).  The following, 
> > however, should prove that the bug is not in libdist-inkt-perl itself, 
> > as it succeeds on stretch but fails on buster:
> > 
> > apt install libfile-chdir-perl libpath-finddev-perl libmoose-perl 
> > liblist-moreutils-perl libtype-tiny-perl libtypes-path-tiny-perl 
> > libpath-iterator-rule-perl libnamespace-autoclean-perl libdata-dump-perl 
> > libsoftware-license-perl libmodule-cpanfile-perl libtext-sprintfn-perl 
> > libcpan-changes-perl librdf-doap-lite-perl
> > dget 
> > http://deb.debian.org/debian/pool/main/libd/libdist-inkt-perl/libdist-inkt-perl_0.024-4.dsc
> > cd libdist-inkt-perl-0.024/examples/p5-acme-example-dist/
> > PERL5LIB=../../lib perl ../../script/distinkt-dist
> 
> It looks like this is due to this Archive-Tar change:
> 
>   2.28  08/06/2018 (madroach, ARC, OCBNET, ppisar)
>   - allow archiving with absolute pathnames - fixes 97748

Yes, that matches my finding that Dist::Inkt breaks with the commit 
https://github.com/jib/archive-tar-new/commit/a00e0 which landed in 2.28 
and has a commit messages smelling like it is above change indeed.


> Dist::Inkt::BuildTarball() puts absolute file names in the generated
> archive, then renames them to relative ones.
> 
>   $tar->add_files($abs);
>   $tar->rename(substr("$abs", 1), "$pfx/".$abs->relative($root));
> 
> This is relying on Archive::Tar having removed the first slash,
> which is no longer a valid assumption.
> 
> I expect Dist::Inkt needs to adapt. Once that is done, we should
> probably add a Breaks on the perl side for older versions. Please
> file a separate bug about that.

Thanks for the very helpful hints.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#923573: PermissionError: [Errno 13] Permission denied: '/etc/matrix-synapse/homeserver.signing.key'

[Andrej Shadura]

On Sat, 2 Mar 2019, 14:45 sergio,  wrote:

>
> >> And yes, my umask is 027.
> >
> > Well, you shouldn’t be running init scripts directly if your
> > environment is non-standard. You need to use invoke-rc.d or service.
> > Better yet, switch over to systemd, that guarantees the correct
> > environment.
>
> It doesn't matter how I start it. invoke-rc.d or service will also give
> the same error. Correct environment is the init script responsibility,
> not a user.
>

Well, not with sysvinit. You cannot expect the init script to undo all
possible combinations of settings the user might set.

Andrej

Bug#923358: libdist-inkt-perl: Stuffs full path into tarball

[Niko Tyni]

On Sat, Mar 02, 2019 at 01:45:19PM +0100, Jonas Smedegaard wrote:
> reassign -1 perl
> retitle -1 perl: breaks libdist-inkt-perl
> thanks

I don't think this worked. Presumably you forgot to bcc
control@bdo.

But never mind that, I think it's libdist-inkt-perl that needs
to change. See below.

> Quoting Jonas Smedegaard (2019-02-26 22:41:00)
> > The command distinkt-dist is completely useless: Produces tarballs 
> > containing full path (not paths relative to build dir), and then 
> > fails.
> > 
> > Upstream bug: https://github.com/tobyink/p5-dist-inkt/issues/3
> 
> Seems to be a bug not in libdist-inkt-perl but in recent perl - or one 
> of the libraries upgraded in lockstep with perl.
> 
> Testsuite does not reveal the bug (it is quite minimal).  The following, 
> however, should prove that the bug is not in libdist-inkt-perl itself, 
> as it succeeds on stretch but fails on buster:
> 
> apt install libfile-chdir-perl libpath-finddev-perl libmoose-perl 
> liblist-moreutils-perl libtype-tiny-perl libtypes-path-tiny-perl 
> libpath-iterator-rule-perl libnamespace-autoclean-perl libdata-dump-perl 
> libsoftware-license-perl libmodule-cpanfile-perl libtext-sprintfn-perl 
> libcpan-changes-perl librdf-doap-lite-perl
> dget 
> http://deb.debian.org/debian/pool/main/libd/libdist-inkt-perl/libdist-inkt-perl_0.024-4.dsc
> cd libdist-inkt-perl-0.024/examples/p5-acme-example-dist/
> PERL5LIB=../../lib perl ../../script/distinkt-dist

It looks like this is due to this Archive-Tar change:

  2.28  08/06/2018 (madroach, ARC, OCBNET, ppisar)
  - allow archiving with absolute pathnames - fixes 97748

Dist::Inkt::BuildTarball() puts absolute file names in the generated
archive, then renames them to relative ones.

  $tar->add_files($abs);
  $tar->rename(substr("$abs", 1), "$pfx/".$abs->relative($root));

This is relying on Archive::Tar having removed the first slash,
which is no longer a valid assumption.

I expect Dist::Inkt needs to adapt. Once that is done, we should
probably add a Breaks on the perl side for older versions. Please
file a separate bug about that.
-- 
Niko Tyni   nt...@debian.org

Bug#923585: debian-installer-netboot-images: Built against openssl1.0 and ttf-freefontfrom stable (neither are in sid/testing atm.)

[Niels Thykier]

Source: debian-installer-netboot-images
Version: 20190118
Severity: serious

Hi,

The "Built-Using" field of debian-installer-netboot-images references
openssl1.0/1.0.2q-1~deb9u1 and ttf-freefont/20100919-1, neither of
which are in unstable nor testing at the moment.  The former was
removed very recently and the other was removed in 2018-06.

Thanks,
~Niels