Bug#918848: Really bad regression

[Nye Liu]

https://github.com/systemd/systemd/issues/11502

Bug#918841: Really bad regression

[Nye Liu]

https://github.com/systemd/systemd/issues/11502 

Bug#919002: Really bad regression

[Nye Liu]

https://github.com/systemd/systemd/issues/11502

Bug#918854: [Pkg-rust-maintainers] Bug#918854: segfault updating crates.io index

[Ximin Luo]

Control: severity -1 important
Control: tag -1 + moreinfo unreproducible

I can't reproduce this, can you install cargo-dbgsym rustc-dbgsym rust-gdb 
libstd-rust-1.31-dbgsym libllvm7-dbgsym libc6-dbg and provide a backtrace?

X

Josh Triplett:
> Package: cargo
> Version: 0.31.1-1
> Severity: grave
> 
> Any time I try to update the crates.io index with the currently packaged
> version of cargo, I get a segfault:
> 
> $ cargo update
> Updating crates.io index
> Segmentation fault
> 
> I can reproduce this in a brand new project (`cargo new foo`) by adding
> any dependency to `Cargo.toml` (e.g. `strsim = "*"`) and then running
> `cargo update`.
> 
> libgit2 was just updated recently; that might potentially be related.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages cargo depends on:
> ii  binutils2.31.1-11
> ii  gcc 4:8.2.0-2
> ii  gcc-7 [c-compiler]  7.4.0-2
> ii  gcc-8 [c-compiler]  8.2.0-14
> ii  libc6   2.28-4
> ii  libcurl3-gnutls 7.62.0-1
> ii  libgcc1 1:8.2.0-14
> ii  libgit2-27  0.27.7+dfsg.1-0.1
> ii  libssh2-1   1.8.0-2
> ii  libssl1.1   1.1.1a-1
> ii  rustc   1.31.0+dfsg1-2
> ii  zlib1g  1:1.2.11.dfsg-1
> 
> cargo recommends no packages.
> 
> Versions of packages cargo suggests:
> pn  cargo-doc  
> ii  python33.7.1-3
> 
> -- no debconf information
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


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

Bug#919064: scala FTBFS: java.lang.NoClassDefFoundError: com/tonicsystems/jarjar/asm/commons/ModuleHashesAttribute

[Andreas Tille]

Hi Java team,

I realised that there is no comment on this bug yet.  Since several of
my packages got a "removal from testing warning": Can I help somehow?
Not that I had the slightest idea what to do about this bug but may be
you have some idea I could test?  I've seen that there is a new upstream
version (2.12.8) - may be I should give it a try but I have no idea
about consequences of exchanging a package that has lots or rdepends
currently and whether this would qualify as "transition".

Any ideas?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#919856: gpg-agent: agent refuses operation again

[Norbert Preining]

On Sun, 20 Jan 2019, Norbert Preining wrote:
> Any suggestions how to debug this?

Enabling logging for gpg-agent I see:

2019-01-20 15:44:08 gpg-agent[25582] gpg-agent (GnuPG) 2.2.12 starting in 
supervised mode.
2019-01-20 15:44:08 gpg-agent[25582] using fd 3 for browser socket 
(/run/user/1000/gnupg/S.gpg-agent.browser)
2019-01-20 15:44:08 gpg-agent[25582] using fd 4 for ssh socket 
(/run/user/1000/gnupg/S.gpg-agent.ssh)
2019-01-20 15:44:08 gpg-agent[25582] using fd 5 for extra socket 
(/run/user/1000/gnupg/S.gpg-agent.extra)
2019-01-20 15:44:08 gpg-agent[25582] using fd 6 for std socket 
(/run/user/1000/gnupg/S.gpg-agent)
2019-01-20 15:44:08 gpg-agent[25582] listening on: std=6 extra=5 browser=3 ssh=4

the default was pinentry-gnome3:

2019-01-20 15:44:30 gpg-agent[25582] failed to unprotect the secret key: No 
passphrase given
2019-01-20 15:44:30 gpg-agent[25582] failed to read the secret key
2019-01-20 15:44:30 gpg-agent[25582] ssh sign request failed: No passphrase 
given 

then I switched to pinentry-gtk-2, same

2019-01-20 15:47:18 gpg-agent[25582] failed to unprotect the secret key: No 
passphrase given
2019-01-20 15:47:18 gpg-agent[25582] failed to read the secret key
2019-01-20 15:47:18 gpg-agent[25582] ssh sign request failed: No passphrase 
given 


After switching to pinentry-qt it started to work ...

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#919856: gpg-agent: agent refuses operation again

[Norbert Preining]

Package: gpg-agent
Version: 2.2.12-1
Severity: important

Hi all


some recent changes (not sure whether this is gpg, X, systemd, or some
other player like dbus) broke ssh functionality for gpg.

Whenever I try to connect somewhere, I get:
sign_and_send_pubkey: signing failed: agent refused operation
(actually multiple times, once for my plugged in yubikey, once for my
ssh key in ~/.ssh).

ssh-add -l lists the keys.

systemctl --user lists:
dirmngr.socketloaded active listening GnuPG network certificate
gpg-agent-browser.socket  loaded active running   GnuPG cryptographic agent
gpg-agent-extra.socketloaded active running   GnuPG cryptographic agent
gpg-agent-ssh.socket  loaded active running   GnuPG cryptographic agent
gpg-agent.socket  loaded active running   GnuPG cryptographic agent


settings in my shell
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh

nothing specific in the .xsession-errors file.

Any suggestions how to debug this?

Thanks

Norbert


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

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

Versions of packages gpg-agent depends on:
ii  gpgconf 2.2.12-1
ii  libassuan0  2.5.2-1
ii  libc6   2.28-5
ii  libgcrypt20 1.8.4-4
ii  libgpg-error0   1.33-3
ii  libnpth01.6-1
ii  pinentry-gnome3 [pinentry]  1.1.0-1+b1
ii  pinentry-gtk2 [pinentry]1.1.0-1+b1

Versions of packages gpg-agent recommends:
ii  gnupg  2.2.12-1

Versions of packages gpg-agent suggests:
ii  dbus-user-session  1.12.12-1
ii  libpam-systemd 240-4
ii  pinentry-gnome31.1.0-1+b1
ii  scdaemon   2.2.12-1

-- no debconf information

Bug#919855: s390x executables crash

[Ben Hutchings]

Source: klibc
Version: 2.0.5-1
Severity: serious

While investigating some test failures on klibc upstream, I found that
the new Debian version crashes on s390x.  It looks like this is due to
an address collision between the build ID in the shared library and
the code in the executables.  The addition of build IDs is not (yet)
part of an upstream release.

Ben.

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

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

Bug#759130: Urgent translation update for camlidl

[Helge Kreutzmann]

Hello Américo,
you provided a man page translation for camlidl some time ago. I'm
intending to update camlidl to include your translation. Unfortunately
the man page does not build as your translation is out of date.

I attached the current pt.po to this e-mail. If you update the file by
2019-01-31 I can include it in the next upload and it will hit Debian
before the freeze.

I appologize for the short notice.

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/
# Translation of camlidl's manpage to European Portuguese
# Copyright (C) 2014 Free Software Foundation, Inc.
#
# Américo Monteiro , 2014.
msgid ""
msgstr ""
"Project-Id-Version: camlidl 1.05-14\n"
"POT-Creation-Date: 2019-01-20 06:58+0100\n"
"PO-Revision-Date: 2019-01-20 07:17+0100\n"
"Last-Translator: Américo Monteiro \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: ENCODINGLanguage: pt\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Lokalize 1.4\n"

#. type: Content of the debian entity
#: debian/xml-man/en/camlidl.xml:4 debian/xml-man/en/license.xml:4
msgid "Debian GNU/Linux"
msgstr "Debian GNU/Linux"

#. type: Content of the dhprg entity
#: debian/xml-man/en/camlidl.xml:5
msgid "camlidl"
msgstr "camlidl"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:38
msgid "CAMLIDL"
msgstr "CAMLIDL"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:39
msgid "1"
msgstr "1"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:43
msgid "camlidl"
msgstr "camlidl.pt"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:45
msgid "A stub code generator for OCaml"
msgstr "Um gerador de código stub para o OCaml"

# type: Content of: 
#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:50
#, fuzzy
#| msgid ""
#| " -I dir -D "
#| "symbol -cpp -nocpp "
#| "-prepro cmd -header "
#| "-no-include -prefix-all-labels -keep-labels -help"
msgid ""
" -I dir -D "
"symbol -cpp -nocpp "
"-prepro cmd -header -"
"no-include -prefix-all-labels -keep-labels -"
"help  -v --version   file.idl "
msgstr ""
" -I directório -D "
"símbolo -cpp -nocpp "
"-prepro comando -header "
"-no-include -prefix-all-labels -keep-labels "
"-help"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:72
msgid "DESCRIPTION"
msgstr "DESCRIÇÃO"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:74
msgid "This manual page documents briefly the  command."
msgstr "Este manual documenta brevemente o comando ."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:76
msgid ""
"This manual page was written for the  distribution because the "
"original program does not have a manual page."
msgstr ""
"Este manual foi escrito para a distribuição  porque o programa "
"original não tem um manual."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:79
msgid ""
" is a program that generates stub code for interfacing Caml with C "
"from an IDL description of the C functions."
msgstr ""
" é um programa que gera código stub (esboço) para servir de interface "
"entre Caml e C a partir de uma descrição IDL das funções de C."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:85
msgid "OPTIONS"
msgstr "OPÇÕES"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:87
msgid "A summary of options is included below."
msgstr "Está incluído em baixo um resumo das opções."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:89
msgid "Options for "
msgstr "Opções para o "

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:94
msgid "-I dir"
msgstr "-I directório"

#. type: Content of: 

#: debian/xml-man/en/camlidl.xml:97
msgid "Add directory to search path."
msgstr "Adiciona um directório ao caminho de busca."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:102
msgid "-D symbol"
msgstr "-D símbolo"

#. type: Content of: 

#: debian/xml-man/en/camlidl.xml:105
#, fuzzy
#| msgid "-Dsymbol"
msgid ""
"Pass -Dsymbol to the C "
"preprocessor."
msgstr "-Dsímbolo"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:111
msgid "-cpp"
msgstr "-cpp"

#. type: Content of: 

#: debian/xml-man/en/camlidl.xml:114
msgid ""
"Pass the .idl files through the C preprocessor. This is "
"the default behavior."
msgstr ""
"Passa os ficheiros .idl através do pré-processador de "
"C. Este é o comportamento predefinido."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:120
msgid "-nocpp"
msgstr "-nocpp"

#. type: Content of: 

#: debian/xml-man/en/camlidl.xml:123
msgid ""
"Do not pass the .idl files through the C preprocessor."
msgstr ""
"Não passa os ficheiros .idl através do pré-processador "
"de C."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:129
msgid "-prepro cmd"
msgstr "-prepro comando"

#. type: Content 

Bug#863533: Urgent translation update for camlidl

[Helge Kreutzmann]

Hello Chris,
you provided a man page translation for camlidl some time ago. I'm
intending to update camlidl to include your translation. Unfortunately
the man page does not build as your translation is out of date.

I attached the current de.po to this e-mail. If you update the file by
2019-01-31 I can include it in the next upload and it will hit Debian
before the freeze.

I appologize for the short notice.

Greetings

  Helge

P.S. I suggest you file in the language team as well.

-- 
  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/
# German translation of the camlidl manpage.
# Copyright © Xavier Leroy .
# This file is distributed under the same license as the camlidl package.   
 package.
# Copyright of this file © 2017 Chris Leick .
#
msgid ""
msgstr ""
"Project-Id-Version: camolidl 1.05-15.1\n"
"Report-Msgid-Bugs-To: debian-ocaml-ma...@lists.debian.org\n"
"POT-Creation-Date: 2019-01-20 06:58+0100\n"
"PO-Revision-Date: 2019-01-20 07:16+0100\n"
"Last-Translator: Chris Leick \n"
"Language-Team: German\n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. type: Content of the debian entity
#: debian/xml-man/en/camlidl.xml:4 debian/xml-man/en/license.xml:4
msgid "Debian GNU/Linux"
msgstr "Debian GNU/Linux"

#. type: Content of the dhprg entity
#: debian/xml-man/en/camlidl.xml:5
msgid "camlidl"
msgstr "camlidl"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:38
msgid "CAMLIDL"
msgstr "CAMLIDL"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:39
msgid "1"
msgstr "1"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:43
msgid "camlidl"
msgstr "camlidl.de"

# https://de.wikipedia.org/wiki/Stub_(Programmierung)
#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:45
msgid "A stub code generator for OCaml"
msgstr "ein Stub-Codeerzeuger für OCaml"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:50
#, fuzzy
#| msgid ""
#| " -I dir -D "
#| "symbol -cpp -nocpp "
#| "-prepro cmd -header "
#| "-no-include -prefix-all-labels -keep-labels -help"
msgid ""
" -I dir -D "
"symbol -cpp -nocpp "
"-prepro cmd -header -"
"no-include -prefix-all-labels -keep-labels -"
"help  -v --version   file.idl "
msgstr ""
" -I Verzeichnis -D "
"Symbol -cpp -nocpp "
"-prepro Befehl -header "
"-no-include -prefix-all-labels -keep-labels "
"-help"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:72
msgid "DESCRIPTION"
msgstr "BESCHREIBUNG"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:74
msgid "This manual page documents briefly the  command."
msgstr "Diese Handbuchseite dokumentiert kurz den Befehl ."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:76
msgid ""
"This manual page was written for the  distribution because the "
"original program does not have a manual page."
msgstr ""
"Diese Handbuchseite wurde für die Debian-Distribution geschrieben, da das "
"Originalprogramm keine Handbuchseite hat."

# IDL = Interface Definition Language
#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:79
msgid ""
" is a program that generates stub code for interfacing Caml with C "
"from an IDL description of the C functions."
msgstr ""
" ist ein Programm, das Stub-Code zum Koppeln von Caml mit C aus einer "
"IDL-Beschreibung der C-Funktionen erzeugt."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:85
msgid "OPTIONS"
msgstr "OPTIONEN"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:87
msgid "A summary of options is included below."
msgstr "Es folgt eine Zusammenfassung der Optionen."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:89
msgid "Options for "
msgstr "Optionen für "

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:94
msgid "-I dir"
msgstr "-I Verzeichnis"

#. type: Content of: 

#: debian/xml-man/en/camlidl.xml:97
msgid "Add directory to search path."
msgstr "fügt das Verzeichnis dem Suchpfad hinzu."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:102
msgid "-D symbol"
msgstr "-D Symbol"

#. type: Content of: 

#: debian/xml-man/en/camlidl.xml:105
#, fuzzy
#| msgid "-Dsymbol"
msgid ""
"Pass -Dsymbol to the C "
"preprocessor."
msgstr "-DSymbol"

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:111
msgid "-cpp"
msgstr "-cpp"

#. type: Content of: 

#: debian/xml-man/en/camlidl.xml:114
msgid ""
"Pass the .idl files through the C preprocessor. This is "
"the default behavior."
msgstr ""
"lässt die .idl-Dateien durch den C-Präprozessor laufen. "
"Dies ist das Standardverhalten."

#. type: Content of: 
#: debian/xml-man/en/camlidl.xml:120
msgid "-nocpp"
msgstr "-nocpp"

#. type: Content of: 

#: debian/xml-man/en/camlidl.xml:123
msgid ""
"Do not 

Bug#913027: ITP: hblock -- Improve your security and privacy by blocking ads, tracking and malware domains

[蔡昆宏]

Control: retitle -1 ITP: hblock -- Improve your security and privacy by
blocking ads, tracking and malware domains
Control: owner -1 Kun-Hung Tsai (蔡昆宏) 

Thanks!

To Héctor,

Hi Héctor, I am intending to package this good work.
Is it OK to reference files you create for debian package
under resources/deb?

Thank you so much.

Kun-Hung

Bug#919853: debhelper: should strip lead/trail white space when parsing a list of filenames

[Ben Finney]

On 20-Jan-2019, Ben Finney wrote:
> Tags: patch
> 
> […]
> Instead, the ‘Debian::Debhelper::Dh_Lib::filedoublearray’ function
> should strip leading/trailing white space from each input line, and
> only then decude whether to skip the input line::
> 
>   # …
>   while () {
>   chomp;
>   s/^\s+|\s+$//g;
>   if (not $x)  {
>   next if /^#/ || /^$/;
>   }
>   # …

I have created a merge request to make this change
https://salsa.debian.org/debian/debhelper/merge_requests/20>.

-- 
 \ “Anyone can do any amount of work provided it isn't the work he |
  `\  is supposed to be doing at the moment.” —Robert Benchley |
_o__)  |
Ben Finney 

Bug#919853: debhelper: should strip lead/trail white space when parsing a list of filenames

[Ben Finney]

Package: debhelper
Version: 12
Severity: normal
Tags: patch

When parsing a list of filenames from a config file, Debhelper should
strip leading/trailing white space from each input line before
deciding whether to skip that line.

The current function ‘Debian::Debhelper::Dh_Lib::filedoublearray’
begins processing each input line with this code fragment::

# …
while () {
chomp;
if (not $x)  {
next if /^#/ || /^$/;
}
# …

That fails when there is leading/trailing white space on the input
line (such as a separator line containing only the white space
character U+000C; or a comment line with leading white space).

The resulting input line is not empty (it still contains leading
and/or trailing white space), so it matches neither of the regex
patterns in the conditional. So the function attempts to parse
meaningful content from it; but the line is semantically empty, so
that fails. The return value does not contain a filename, which leads
to hard-to-understand errors later in execution::

Use of uninitialized value $fn in substitution (s///) at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 780.
Use of uninitialized value $fn in substitution (s///) at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 781.
Use of uninitialized value in concatenation (.) or string at 
/usr/bin/dh_bash-completion line 67.
Use of uninitialized value $name in concatenation (.) or string at 
/usr/bin/dh_bash-completion line 67.

Instead, the ‘Debian::Debhelper::Dh_Lib::filedoublearray’ function
should strip leading/trailing white space from each input line, and
only then decude whether to skip the input line::

# …
while () {
chomp;
s/^\s+|\s+$//g;
if (not $x)  {
next if /^#/ || /^$/;
}
# …

-- 
 \   “Kissing a smoker is like licking an ashtray.” —anonymous |
  `\   |
_o__)  |
Ben Finney

Bug#919721: [Pkg-fonts-devel] Bug#919721: fonts-firacode: looks broken on at least kitty and hexchat

[Antonio Terceiro]

Em 19 de janeiro de 2019 17:43:20 BRST, Fabian Greffrath  
escreveu:
>Control: severity -1 normal
>
>Hi Antonio,
>
>thanks for the report, but I fail to see how a change in vertical
>spacing could justify grave severity for a font package.

Well this issue does make the package unusable, and that severity would prevent 
this broken version from entering testing.

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Ying-Chun Liu (PaulLiu)]

Santiago Vila 於 2019/1/20 上午1:35 寫道:
> Package: src:libjstun-java
> Version: 0.7.3+dfsg-1
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> dh build-indep --with javahelper
>dh_update_autotools_config -i
>jh_linkjars -i
>jh_build -i
> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> /usr/lib/jvm/default-java/bin/javac -g -cp 
> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
>  -d debian/_jh_build.libjstun-java -source 1.7 -target 1.7 -encoding ISO8859-1
> warning: [options] bootstrap class path not set in conjunction with -source 7
> Note: src/de/javawi/jstun/test/demo/ice/ICENegociator.java uses unchecked or 
> unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 warning
> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
> /usr/share/doc/default-jdk-doc/api -link 
> /usr/share/doc/default-jre-headless/api -classpath 
> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
>  -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp 
> -source 1.7
> Creating destination directory: "debian/_jh_build.javadoc/api/"
> javadoc: error - The code being documented uses packages in the unnamed 
> module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are 
> in named modules.
> javadoc: error - The code being documented uses packages in the unnamed 
> module, but the packages defined in /usr/share/doc/default-jre-headless/api/ 
> are in named modules.
> 2 errors
> make: *** [debian/rules:11: build-indep] Error 123
> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> status 2
> 
> 
> (The above is just how the builds ends and not necessarily the most relevant 
> part)
> 
> The build was made in my autobuilder with "dpkg-buildpackage -A"
> and it also fails here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libjstun-java.html
> 
> where you can get a full build log if you need it.
> 
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the BTS web page for this package.
> 
> Thanks.
> 

Hi Santiago,

It seems to me that this line causes the problem.
find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0
/usr/lib/jvm/default-java/bin/javadoc -locale en_US -link
/usr/share/doc/default-jdk-doc/api -link
/usr/share/doc/default-jre-headless/api -classpath
/usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
-d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp
-source 1.7

But if remove "-link /usr/share/doc/default-jdk-doc/api -link
/usr/share/doc/default-jre-headless/api", then it will pass.

I'm wondering if javahelper needs to call javadoc in different way.

Yours,
Paul

-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature

Bug#198507: debhelper: fails if file name containing spaces are referenced in config files

[Ben Finney]

Control: retitle -1 debhelper: fails if file name containing spaces are 
referenced in config files

On 23-Jun-2018, Niels Thykier wrote:
> retitle 198507 debhelper: config files cannot reference files with spaces

That's a little ambiguous (spaces in the file contents, is one
reasonable way to interpret that title). Re-titling to be clear this
is about file *names*.

-- 
 \   “Two hands working can do more than a thousand clasped in |
  `\   prayer.” —Anonymous |
_o__)  |
Ben Finney 

Bug#919852: python-skimage-doc: broken symlink: /usr/share/doc/python-skimage-doc/html/_static/css/bootstrap-responsive.css -> ../../../../../javascript/bootstrap/css/bootstrap-responsive.css

[Andreas Beckmann]

Package: python-skimage-doc
Version: 0.14.1-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m33.2s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-skimage-doc/html/_static/css/bootstrap-responsive.css 
-> ../../../../../javascript/bootstrap/css/bootstrap-responsive.css 
(python-skimage-doc)


cheers,

Andreas


python-skimage-doc_0.14.1-3.log.gz
Description: application/gzip

Bug#919850: python3-link-grammar: broken symlink: /usr/lib/python3.7/site-packages/linkgrammar/_clinkgrammar.so -> _clinkgrammar.so.5.5.1

[Andreas Beckmann]

Package: python3-link-grammar
Version: 5.5.1-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

1m41.0s ERROR: FAIL: Broken symlinks:
  /usr/lib/python3.7/site-packages/linkgrammar/_clinkgrammar.so -> 
_clinkgrammar.so.5.5.1 (python3-link-grammar)

But there is 

  /usr/lib/python3/dist-packages/linkgrammar/_clinkgrammar.so.5.5.1

so this seems to be a site-packages/dist-packages mixup.


cheers,

Andreas


python3-link-grammar_5.5.1-5.log.gz
Description: application/gzip

Bug#919851: reproducible: re-deploy jtx1c

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: normal

jtx1c-armhf-rb.debian.net had a disk failure, and thus needed to be
re-installed.

It has now been reinstalled, awaiting configuration.

New ssh keys:

256 SHA256:V8CIP3rzxgTHDjzhhVFPbTcfB+hHwppvcjbhQEfFTGQ root@jtx1c (ECDSA)
256 SHA256:PsPIxakEQwWdCxNR9WGICtDFRRaQJhco3Q8KqZjYOxQ root@jtx1c (ED25519)
2048 SHA256:nlxrEZhjN9jbj8QztoJPUW7tsp1bT3gu74hIO7RVg5c root@jtx1c (RSA)

All other settings should basically be the same, and I don't think it's
been removed from jenkins git yet, but let me know if you have
difficulties re-enabling.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#919849: salt-doc: broken symlinks: /usr/share/doc/salt/html/_static/*/bootstrap* -> ../../../../../twitter-bootstrap/files/*/bootstrap*

[Andreas Beckmann]

Package: salt-doc
Version: 2018.3.3+dfsg1-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m29.8s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/salt/html/_static/js/vendor/bootstrap.min.js -> 
../../../../../../twitter-bootstrap/files/js/bootstrap.min.js (salt-doc)
  /usr/share/doc/salt/html/_static/js/vendor/bootstrap.js -> 
../../../../../../twitter-bootstrap/files/js/bootstrap.js (salt-doc)
  /usr/share/doc/salt/html/_static/css/bootstrap.min.css -> 
../../../../../twitter-bootstrap/files/css/bootstrap.min.css (salt-doc)
  /usr/share/doc/salt/html/_static/css/bootstrap-responsive.min.css -> 
../../../../../twitter-bootstrap/files/css/bootstrap-responsive.min.css 
(salt-doc)


Is salt-doc missing a Depends/Recommends/Suggests: libjs-twitter-bootstrap ?


cheers,

Andreas


salt-doc_2018.3.3+dfsg1-2.log.gz
Description: application/gzip

Bug#919848: tclxml-dev: broken symlink: /usr/lib/x86_64-linux-gnu/libtclxmlstub.a -> libtclxmlstub3.2.a

[Andreas Beckmann]

Package: tclxml-dev
Version: 1:3.2.7-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m28.5s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/libtclxmlstub.a -> libtclxmlstub3.2.a (tclxml-dev)

The static library does not seem to be available in any package in the archive.


cheers,

Andreas


tclxml-dev_1:3.2.7-2.log.gz
Description: application/gzip

Bug#919847: ruby-rails-assets-markdown-it: missing Depends: libjs-markdown-it

[Andreas Beckmann]

Package: ruby-rails-assets-markdown-it
Version: 8.4.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m28.5s ERROR: FAIL: Broken symlinks:
  
/usr/share/ruby-rails-assets-markdown-it/app/assets/javascripts/markdown-it/markdown-it.js
 -> ../../../../../javascript/markdown-it/markdown-it.js 
(ruby-rails-assets-markdown-it)


cheers,

Andreas


ruby-rails-assets-markdown-it_8.4.2-1.log.gz
Description: application/gzip

Bug#858855: gpodder: subscribing to https://requestforcomments.de/feed raises an ssl error

[tony mancill]

On Sat, Apr 15, 2017 at 10:18:27AM -0700, tony mancill wrote:
> On Fri, Apr 14, 2017 at 09:52:37PM +0200, Thomas Perl wrote:
> > This seems to be the following upstream bug:
> > https://github.com/gpodder/gpodder/issues/265
> > 
> > A fix would be to upgrade to Python 2.7.9, as indicated here:
> > https://github.com/gpodder/gpodder/issues/269
> 
> I'm able to reproduce the bug with later version of python shipped in
> Debian... :(
> 
> $ python2.7 --version
> Python 2.7.13

At this point, shortly before the release of buster, I am no longer able
to reproduce the originally reported behavior.  I am able to add the
feed without an SSL error, but gPodder doesn't find any episodes to
download.

Bug#821057:

[Fedor Uvarov]

Control: fixed -1 18.04.5-1

This bug seems to no longer occur in 18.04.5-1.

Bug#919846: ruby-rails-assets-highlightjs: missing Depends: libjs-highlight.js

[Andreas Beckmann]

Package: ruby-rails-assets-highlightjs
Version: 9.12.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m30.0s ERROR: FAIL: Broken symlinks:
  
/usr/share/ruby-rails-assets-highlightjs/app/assets/javascripts/highlightjs/highlight.pack.js
 -> ../../../../../javascript/highlight.js/highlight.min.js 
(ruby-rails-assets-highlightjs)


cheers,

Andreas


ruby-rails-assets-highlightjs_9.12.0-1.log.gz
Description: application/gzip

Bug#919845: python-mongoengine-doc: missing Depends: ${sphinxdoc:Depends}

[Andreas Beckmann]

Package: python-mongoengine-doc
Version: 0.15.3-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m27.5s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-mongoengine-doc/html/_static/js/theme.js -> 
../../../../../sphinx_rtd_theme/static/js/theme.js (python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/js/modernizr.min.js -> 
../../../../../sphinx_rtd_theme/static/js/modernizr.min.js 
(python-mongoengine-doc)
  
/usr/share/doc/python-mongoengine-doc/html/_static/fonts/fontawesome-webfont.woff2
 -> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2 
(python-mongoengine-doc)
  
/usr/share/doc/python-mongoengine-doc/html/_static/fonts/fontawesome-webfont.woff
 -> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff 
(python-mongoengine-doc)
  
/usr/share/doc/python-mongoengine-doc/html/_static/fonts/fontawesome-webfont.ttf
 -> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf 
(python-mongoengine-doc)
  
/usr/share/doc/python-mongoengine-doc/html/_static/fonts/fontawesome-webfont.svg
 -> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg 
(python-mongoengine-doc)
  
/usr/share/doc/python-mongoengine-doc/html/_static/fonts/fontawesome-webfont.eot
 -> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot 
(python-mongoengine-doc)
  
/usr/share/doc/python-mongoengine-doc/html/_static/fonts/RobotoSlab-Regular.woff2
 -> ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2 
(python-mongoengine-doc)
  
/usr/share/doc/python-mongoengine-doc/html/_static/fonts/RobotoSlab-Regular.ttf 
-> ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.ttf 
(python-mongoengine-doc)
  
/usr/share/doc/python-mongoengine-doc/html/_static/fonts/RobotoSlab-Bold.woff2 
-> ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2 
(python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/fonts/RobotoSlab-Bold.ttf 
-> ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.ttf 
(python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/fonts/Lato-Regular.woff2 
-> ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2 
(python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/fonts/Lato-Regular.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf 
(python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/fonts/Lato-Italic.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2 
(python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/fonts/Lato-Italic.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf 
(python-mongoengine-doc)
  
/usr/share/doc/python-mongoengine-doc/html/_static/fonts/Lato-BoldItalic.woff2 
-> ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2 
(python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/fonts/Lato-BoldItalic.ttf 
-> ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf 
(python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/fonts/Lato-Bold.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2 
(python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/fonts/Lato-Bold.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf 
(python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/css/theme.css -> 
../../../../../sphinx_rtd_theme/static/css/theme.css (python-mongoengine-doc)
  /usr/share/doc/python-mongoengine-doc/html/_static/css/badge_only.css -> 
../../../../../sphinx_rtd_theme/static/css/badge_only.css 
(python-mongoengine-doc)

As Dmitry Shachnev mentioned in #911069:

> These symlinks are generated by dh_sphinxdoc, so better to depend on
> ${sphinxdoc:Depends}.


cheers,

Andreas


python-mongoengine-doc_0.15.3-1.log.gz
Description: application/gzip

Bug#919844: changetrack: "find2perl" is missing and thus breaks filename patterns prefixed with "@"

[Lars Kruse]

Package: changetrack
Version: 4.7-5
Severity: normal
Tags: patch upstream

Dear Maintainer,

changetrack allows the specification of patterns for "find" to be used
in /etc/changetrack.  A use case is the exclusion of specific files
below /etc/ from the change tracking.

Example (excluding daily updated revocation lists):
 @/etc/ -type f ! -name 'foo*.crl'

The above pattern requires the tool "find2perl", which was shipped along
with perl.  In perl 5.22.0 the tool "find2perl" was removed, due to
being released separately via CPAN.
(see /usr/share/perl/5.28.1/pod/perl5220delta.pod)

Thus changetrack fails to work due to the absence of "find2perl" since
Stretch, if a filename pattern with the "@" prefix is configured.

The attached patch fixes the issue by using "find" instead of
"find2perl" (the latter was supposed to be a faster alternative to
"find").

Cheers,
Lars
--- /usr/bin/changetrack.orig   2016-12-30 01:58:25.0 +0100
+++ /usr/bin/changetrack2019-01-20 04:41:55.154600278 +0100
@@ -164,7 +164,7 @@
 my $rest = substr($filename,1);

 # execute as find command
-@files = split '\0', `find2perl $rest -print0 |perl`;
+@files = split '\0', `find $rest -print0`;
 }
 else
 {

Bug#894260: Abbiamo bisogno di Content writer

[Luca Agnello]

Buongiorno ,

non avendo ricevuto risposta alla precedente email, le forniamo qualche 
dettaglio sul nostro portale. ProntoPro è il primo sito per numero di utenti 
che mette in contatto domanda e offerta di lavoro professionale e artigianale. 
oltre 500'000 clienti hanno già usato ProntoPro e 200'000 sono i professionisti 
iscritti tra 500 categorie di servizi.

Abbiamo selezionato il suo profilo tra molti altri perché in base alle nostre 
ricerche è pienamente in linea con quello che i nostri clienti si aspettano per 
qualità e professionalità.

Per registrare la propria attività e cominciare a ricevere le richieste di 
lavoro bastano pochi secondi e qualche info lasciata a questo link:

www.prontopro/richieste 
(https://www.prontopro.it/signup/merchant/services?categoryId=12=82_source=ddemee_campaign=20190116ee6304_medium=email_term=Comunicazione+e+pubblicit%C3%A0)

 

Rimango a sua disposizione per eventuali dubbi o domande.

Buona giornata e buon lavoro,

Luca

 

 

Se desidera maggiori informazioni in merito a questa email scriva qui

Se non desidera più ricevere email da ProntoPro clicchi qui

Bug#919843: lirc-doc: broken symlinks: /usr/share/doc/lirc/lirc.org/* -> /build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/*

[Andreas Beckmann]

Package: lirc-doc
Version: 0.10.1-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m24.4s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/lirc/plugindocs/var -> /var/lib/lirc/plugins (lirc-doc)
  /usr/share/doc/lirc/plugindocs/lirc.css -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/html/lirc.css 
(lirc-doc)
  /usr/share/doc/lirc/lirc.org/images/marb18.jpg -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/images/marb18.jpg 
(lirc-doc)
  /usr/share/doc/lirc/lirc.org/images/lirc.gif -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/images/lirc.gif 
(lirc-doc)
  /usr/share/doc/lirc/lirc.org/images/favicon.ico -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/lirc.org/favicon.ico
 (lirc-doc)
  /usr/share/doc/lirc/lirc.org/images/diode.gif -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/images/diode.gif 
(lirc-doc)
  /usr/share/doc/lirc/lirc.org/images/atwf83.jpg -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/images/atwf83.jpg 
(lirc-doc)
  /usr/share/doc/lirc/lirc.org/html/table.html -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/html/table.html 
(lirc-doc)
  /usr/share/doc/lirc/lirc.org/html/plugins-index.html -> 
/var/lib/lirc/plugins/index.html (lirc-doc)
  /usr/share/doc/lirc/lirc.org/html/lirc.css -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/html/lirc.css 
(lirc-doc)
  /usr/share/doc/lirc/lirc.org/api-docs/html/search/variables_4.js -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/lirc.org/api-docs/html/search/all_5.js
 (lirc-doc)
  /usr/share/doc/lirc/lirc.org/api-docs/html/search/groups_4.js -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/lirc.org/api-docs/html/search/all_13.js
 (lirc-doc)
  /usr/share/doc/lirc/lirc.org/api-docs/html/search/functions_12.js -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/lirc.org/api-docs/html/search/all_15.js
 (lirc-doc)
  /usr/share/doc/lirc/lirc.org/api-docs/html/search/defines_a.js -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/lirc.org/api-docs/html/search/all_16.js
 (lirc-doc)
  /usr/share/doc/lirc/lirc.org/api-docs/html/search/classes_e.js -> 
/build/lirc-rOeUaU/lirc-0.10.1/debian/tmp/usr/share/doc/lirc/lirc.org/api-docs/html/search/all_14.js
 (lirc-doc)


The targets are absolute build-time paths ...


cheers,

Andreas


lirc-doc_0.10.1-5.log.gz
Description: application/gzip

Bug#919808: forensics-extra: please don't depend on pxz which shall be removed for buster

[Eriberto]

Em sáb, 19 de jan de 2019 às 16:58, Holger Levsen  escreveu:
>
> forensics-extra currently depends on pxz, however even xz in Stretch now
> supports parallel compression with the -T switch. Therefore I would like
> to remove pxz from Buster, which is only possible if forensics-extra
> (and freedom-maker) drop the depends on pxz. See #919616.
>
> Thanks for maintaining forensics-extra!
>
>
> --
> tschüß,
> Holger


Hi Holger!

I will fix the package now. Thanks!

Cheers,

Eriberto

Bug#919842: Jetson-tx1: successful, but required customized boot media

[Vagrant Cascadian]

Package: installation-reports
Severity: normal

Overall install went ok, but requires manually constructing an image
to boot as USB requires binary firmware blob.

Using UEFI images are limited as they do not support loading a .dtb
matching the kernel, and the device-tree passed by u-boot's EFI
implementation lacks some features (SMP, SATA).

Once booted with the USB firmware blob loaded and correct .dtb loaded,
the install worked fine.

live well,
  vagrant

-- Package-specific info:

Boot method: microSD
Image version: 
https://d-i.debian.org/daily-images/arm64/20190119-02:06/netboot/debian-installer/arm64/
Date: 2019-01-19 ~18:00 -0800

Machine: Jetson-tx1 (tegra210-p2371-2180)
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   1713500   0   1713500   0% /dev
tmpfs  tmpfs   3521604696347464   2% /run
/dev/mmcblk0p1 ext4  14384136 1330676  12303076  10% /
tmpfs  tmpfs  1760780   0   1760780   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs  1760780   0   1760780   0% /sys/fs/cgroup
tmpfs  tmpfs   352156   0352156   0% /run/user/1000

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

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

Comments/Problems:

I had to append the tegra210/xusb.bin firmware to the initrd, because
it's only shipped in firmware-misc-nonfree, and so assembled an image
by hand using the linux, initrd.gz and .dtb (tegra210-p2371-2180), as
described here:

  https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1

Instead of generating a boot script, I used an extlinux menu, and
generated an ext4 partition on an SD card, dropping linux, initrd.gz
(with the xusb.bin appended), and "dtb" symlinked to the device-tree
(as u-boot doesn't set $fdtfile).

default di
menu title Debian-Installer Menu
prompt 0

label di
menu label Debian Installer
linux /linux
initrd /initrd.gz
fdt /dtb

Once booted, it detected the network interface (which is on the USB
bus), and the install proceeded smoothly.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

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

==
Installer hardware-summary:
==
uname -a: Linux jtx1cx 4.19.0-1-arm64 #1 SMP Debian 4.19.13-1 (2018-12-30) 
aarch64 GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.19.0-1-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: xHCI Host Controller [1d6b:0003]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 03
usb-list:Manufacturer: Linux 4.19.0-1-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 02: USB 10/100/1000 LAN [0955:09ff]
usb-list:Level 01 Parent 01 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: Nvidia
usb-list:Interface 00: Class ff(vend.) Subclass ff Protocol 00 Driver r8152
lsmod: Module  Size  Used by
lsmod: dm_mod143360  7
lsmod: md_mod155648  0
lsmod: xfs  1273856  0
lsmod: jfs   196608  0
lsmod: btrfs1265664  0
lsmod: xor20480  1 btrfs
lsmod: zstd_decompress65536  1 btrfs
lsmod: zstd_compress 163840  1 btrfs
lsmod: xxhash 16384  2 zstd_compress,zstd_decompress
lsmod: raid6_pq  106496  1 btrfs
lsmod: libcrc32c  16384  2 btrfs,xfs
lsmod: vfat   24576  0
lsmod: fat81920  1 vfat
lsmod: ext4  659456  1
lsmod: crc16  16384  1 ext4
lsmod: mbcache16384  1 ext4
lsmod: jbd2 

Bug#919841: node-istanbul: broken symlinks: /usr/lib/nodejs/istanbul/lib/assets/vendor/prettify.{css,js} -> ../../../../../../share/javascript/prettify.{css,js}

[Andreas Beckmann]

Package: node-istanbul
Version: 0.4.5+ds-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

1m33.0s ERROR: FAIL: Broken symlinks:
  /usr/lib/nodejs/istanbul/lib/assets/vendor/prettify.js  -> 
../../../../../../share/javascript/prettify.js (node-istanbul)
  /usr/lib/nodejs/istanbul/lib/assets/vendor/prettify.css -> 
../../../../../../share/javascript/prettify.css (node-istanbul)

  ^^^

libjs-prettify would provide /usr/share/javascript/prettify/prettify.js
 

cheers,

Andreas


node-istanbul_0.4.5+ds-2.log.gz
Description: application/gzip

Bug#919834: libmono-btls-shared.so: undefined symbols: needs -pthread

[Jo Shields]

I'll try to get around to forwarding this upstream

As you guessed, it's not directly an issue because mono-btls-shared is a
plugin used by /usr/bin/mono-sgen, which is linked adequately.

On 19/01/2019 20:35, Paul Wise wrote:
> Package: mono-runtime-common
> Version: 5.18.0.240+dfsg-1
> Severity: minor
> File: /usr/lib/libmono-btls-shared.so
> User: debian...@lists.debian.org
> Usertags: undefined-symbol adequate
> 
> libmono-btls-shared.so needs to compile and link with -pthread, see the
> output of adequate, symtree and objdump below. I detected this on amd64
> but the Debian build log scanner also detected dpkg-buildpackage
> complaining about it on most architectures, see the w3m/getbuildlog
> output below. In addition dpkg-buildpackage detected underlinking in
> some other files.
> 
> I filed this bug at severity minor since I'm not sure if there are any
> programs using the libmono-btls-shared.so lib or if they already use
> the libpthread symbols and compile and link with -pthread or not.
> 
> This bug report brought to you by adequate:
> 
> http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
> 
> $ adequate mono-runtime-common
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_rdlock
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_init
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_getspecific
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_destroy
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_key_create
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_wrlock
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_once
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_setspecific
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_unlock
> 
> $ man adequate | grep -A4  undefined-symbol
>undefined-symbol
>The symbol has not been found in the libraries linked with the 
> binary.
>Either the binary either needs to be linked with an additional 
> shared library,
>or the dependency on the shared library package that provides this 
> symbol is too weak.
> 
>References: Debian Policy §3.5, §8.6, §10.2.
> 
> $ lddtree /usr/lib/libmono-btls-shared.so
> libmono-btls-shared.so => /usr/lib/libmono-btls-shared.so (interpreter => 
> none)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
> 
> $ symtree /usr/lib/libmono-btls-shared.so
> /usr/lib/libmono-btls-shared.so
> libc.so.6 => 
> socket,fflush,gmtime_r,gai_strerror,strncmp,__isoc99_sscanf,connect,ftell,strncpy,time,__stack_chk_fail,pthread_mutex_lock,realloc,abort,memchr,strdup,__assert_fail,feof,fgets,calloc,strlen,isxdigit,send,getaddrinfo,memset,__errno_location,fseek,read,memcmp,getsockopt,shutdown,__fprintf_chk,pthread_mutex_unlock,recv,fputs,lseek,memcpy,memcpy,fclose,__vsnprintf_chk,strtoul,setsockopt,malloc,strcasecmp,__ctype_b_loc,getenv,stderr,dup,__memset_chk,strncasecmp,fwrite,fread,gettimeofday,__memcpy_chk,close,open,strchr,qsort,__ctype_tolower_loc,__cxa_finalize,freeaddrinfo,fcntl,__xstat,isdigit,memmove,fopen64,__strcat_chk,strcmp,strerror,ferror,write,free
> WEAK => 
> _ITM_deregisterTMCloneTable,__gmon_start__,_ITM_registerTMCloneTable
> UNRESOLVED => 
> pthread_rwlock_rdlock,pthread_rwlock_init,pthread_getspecific,pthread_rwlock_destroy,pthread_key_create,pthread_rwlock_wrlock,pthread_once,pthread_setspecific,pthread_rwlock_unlock
> 
> $ objdump -T /lib/x86_64-linux-gnu/libpthdl.so.2 | grep -E "($(symtree 
> /usr/lib/x86_64-linux-gnu/libzvbi-chains.so.0.0.0 | sed -n 's/UNRESOLVED 
> => //p' | tr , '|'))$"
> libpthread-2.28.so  libpthread.so.0 
> 
> $ objdump -T /lib/x86_64-linux-gnu/libpthread.so.0 | grep -E "($(symtree 
> /usr/lib/libmono-btls-shared.so | sed -n 's/UNRESOLVED => //p' | tr , 
> '|'))$"
> ced0 gDF .text03cf  GLIBC_2.2.5 
> __pthread_rwlock_wrlock
> f330 gDF .text00ee  GLIBC_2.2.5 
> __pthread_setspecific
> f200 gDF .text0056  GLIBC_2.2.5 
> __pthread_key_create
> c9e0 gDF .text0003  GLIBC_2.2.5 
> __pthread_rwlock_destroy
> d780  w   DF .text01db  GLIBC_2.2.5 
> pthread_rwlock_unlock
> c9a0 gDF .text003a  GLIBC_2.2.5 
> __pthread_rwlock_init
> f2a0 gDF .text0083  GLIBC_2.2.5 
> __pthread_getspecific
> c9e0 gDF .text0003  GLIBC_2.2.5 
> pthread_rwlock_destroy
> f330  w   DF .text00ee  

Bug#919840: sqwebmail: leaves broken symlink after purge: /etc/apache2/conf-available/sqwebmail.conf -> ../../sqwebmail/apache24.conf

[Andreas Beckmann]

Package: sqwebmail
Version: 6.0.0+1.0.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m54.4s ERROR: FAIL: Broken symlinks:
  /etc/apache2/conf-available/sqwebmail.conf -> ../../sqwebmail/apache24.conf


cheers,

Andreas


sqwebmail_6.0.0+1.0.5-1.log.gz
Description: application/gzip

Bug#919839: lintian: package-contains-real-file-outside-usr false positives in /lib

[Andreas Beckmann]

Package: lintian
Version: 2.5.122
Severity: normal

X: mariadb-server-10.3: package-contains-real-file-outside-usr lib/systemd/
X: mariadb-server-10.3: package-contains-real-file-outside-usr 
lib/systemd/system/
X: mariadb-server-10.3: package-contains-real-file-outside-usr 
lib/systemd/system/mariadb.service
X: mariadb-server-10.3: package-contains-real-file-outside-usr 
lib/systemd/system/mariadb@.service
X: mariadb-server-10.3: package-contains-real-file-outside-usr 
lib/systemd/system/mariadb@bootstrap.service.d/
X: mariadb-server-10.3: package-contains-real-file-outside-usr 
lib/systemd/system/mariadb@bootstrap.service.d/use_galera_new_cluster.conf

What about real files in /bin, /etc, /lib, /sbin, /var ?

I don't like the tag name ... what about something like
  package-contains-real-file-outside-fhs-tree ?


Andreas

Bug#908783: ITP: firmware-microbit-micropython -- MicroPython runtime for the BBC micro:bit

[Nick Morrott]

On Sat, 19 Jan 2019 at 07:57, Petter Reinholdtsen  wrote:
>
> [Nick Morrott]
> > It is being reviewed at the moment.
>
> Very good.  Any estimate on when this part is done?

firmware-microbit-micropython is now in NEW, so hopefully the next
response you get from this ITP will be that it is closed :)

Thanks,
Nick

Bug#919838: supercollider-common: broken symlinks: /usr/share/SuperCollider/HelpSource/lib/codemirror*.min.js -> ../../../javascript/codemirror/*.js

[Andreas Beckmann]

Package: supercollider-common
Version: 1:3.10.0+repack-0.1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m29.1s ERROR: FAIL: Broken symlinks:
  /usr/share/SuperCollider/HelpSource/lib/codemirror-addon-simple-5.39.2.min.js 
-> ../../../javascript/codemirror/addon/mode/simple.js (supercollider-common)
  /usr/share/SuperCollider/HelpSource/lib/codemirror-5.39.2.min.js -> 
../../../javascript/codemirror/codemirror.js (supercollider-common)

Is supercollider-common missing a Depends/Recommends/Suggests: libjs-codemirror 
?


cheers,

Andreas


supercollider-common_1:3.10.0+repack-0.1.log.gz
Description: application/gzip

Bug#919837: libcamomile-ocaml-dev: broken symlinks: /usr/share/man/man1/camomile*.{byte,opt}.1.gz -> camomile*.1.gz

[Andreas Beckmann]

Package: libcamomile-ocaml-dev
Version: 1.0.1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m42.3s ERROR: FAIL: Broken symlinks:
  /usr/share/man/man1/camomilelocaledef.opt.1.gz -> camomilelocaledef.1.gz 
(libcamomile-ocaml-dev)
  /usr/share/man/man1/camomilelocaledef.byte.1.gz -> camomilelocaledef.1.gz 
(libcamomile-ocaml-dev)
  /usr/share/man/man1/camomilecharmap.opt.1.gz -> camomilecharmap.1.gz 
(libcamomile-ocaml-dev)
  /usr/share/man/man1/camomilecharmap.byte.1.gz -> camomilecharmap.1.gz 
(libcamomile-ocaml-dev)


cheers,

Andreas


libcamomile-ocaml-dev_1.0.1-1.log.gz
Description: application/gzip

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Pierre Ynard]

> That's not what my argument is -- what I mean, is that there's many
> more components that need to stick strictly to files not on /usr
> during that phase of the boot, sysv-rc being only a single one.
> Efforts to keep it working are a waste of time, not because you won't
> get to simplify things, but because you would need to override a
> number of other maintainers.

No. I think what you're saying is backwards. My opinion is that what
really creates a waste of time, is all the maintainers and packages
launching a deliberate effort to shift files around to serve the /usr
merge cause. Just don't break it in the first place, and then there will
be no waste of time trying to keep it unbroken.

Also, sysv-rc is not "only a single" component, it's a critical MAJOR
boot component.

> Simple setups still work in Buster, but it's easy to run into
> something that doesn't. That'd be a nasty surprise for the user, thus
> it's better to make the break faster and more obvious.

Oh, so you're explaining that a situation falling short of ideal is
nasty, and also breaking things is good, especially breaking things for
the sake of clearly driving the point that they're broken.

What was I saying earlier again?

> This is the classic systemd philosophy argument that if portability
> cannot be fully guaranteed, it is counterproductive and harmful and
> ought to be eliminated.

> Personally I think it's quite a perversion of common software
> standards to reach a point where portability efforts are frowned upon
> and discouraged.

> Just stop that self-fulfilling prophecy, and it will work better.

> just not choosing the one option that deliberately breaks more stuff
> for the sake of establishing clearly what is broken and what isn't
> according to a controversial ideology.

I rest my case. Clearly we have very different opinions about software
development standards and responsibility for your work and to your
users. I just hope Debian will continue to uphold the values for which
I've been with it.

> Then, pretty surely even such simple setups won't work in Bullseye.

Does that mean that there are already plans to expand for Bullseye the
scope and clarity of that breakage ideology?

> There's a cost to migrations like this: any move may break stuff.
> There's an easy way for Buster: just drop the move, it serves no need.

The files have already been moved again to /lib/init. Is there an
assumption that they will have to be moved again away from /lib after
Buster?

Once again, simple setups, or any kind of setup still working is good.
Freedom and possibilities for the users to tweak their software into
what they choose, and to fix and improve their software to suit their
needs, is good. Please don't say things that feel as if users and use
cases that don't conform to a given ideology are better off rooted out.

-- 
Pierre Ynard

Bug#919836: jupyter-sphinx-theme-common: broken symlinks: /usr/share/jupyter_sphinx_theme/jupyter/static/boots{trap,watch}-2

[Andreas Beckmann]

Package: jupyter-sphinx-theme-common
Version: 0.0.6+ds1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m30.4s ERROR: FAIL: Broken symlinks:
  /usr/share/jupyter_sphinx_theme/jupyter/static/bootswatch-2 -> 
../../../../lib/python2.7/dist-packages/sphinx_bootstrap_theme/bootstrap/static/bootswatch-2.3.2
 (jupyter-sphinx-theme-common)
  /usr/share/jupyter_sphinx_theme/jupyter/static/bootstrap-2 -> 
../../../../lib/python2.7/dist-packages/sphinx_bootstrap_theme/bootstrap/static/bootstrap-2.3.2
 (jupyter-sphinx-theme-common)

Since jupyter-sphinx-theme-common depends on python3-sphinx-bootstrap-theme,
the targets probably need to be adjusted to point into the python3 package
instead.


cheers,

Andreas


jupyter-sphinx-theme-common_0.0.6+ds1-4.log.gz
Description: application/gzip

Bug#917130: gimp: crashes at start: segmentation fault in g_slice_alloc() (memory corruption?)

[積丹尼 Dan Jacobson]

Thanks but one still must forbid
# aptitude search ~U
iFA libilmbase23
iFA libopenexr23
if gimp is to start on experimental.

Bug#919835: mgba; AppStream metadata isn't being used because of its license

[Jeremy Bicha]

Source: mgba
Version: 0.6.3+dfsg1-2
X-Debbugs-CC: sergio_...@yahoo.com.br

The AppStream metadata that was added to the Debian package isn't
being used because its metadata_license isn't on the short list of
approved licenses.

I encourage you to consider relicensing your metadata as CC0-1.0. From
what I can tell, CC0-1.0 is by far the most popular license for
AppStream metadata.

The AppStream metadata for libretro-mgba isn't very useful for
gnome-games-app without the .libretro file. It would be easier for me
to help with some of these issues if these projects used
https://salsa.debian.org . Please let me know if you would like my
help.

References

https://appstream.debian.org/sid/main/issues/libretro-mgba.html
https://github.com/ximion/appstream/blob/master/src/as-spdx.c#L449-L478
https://bugs.debian.org/911327
https://bugs.debian.org/872484

Thanks,
Jeremy Bicha

Bug#905415: libnode-dev: broken symlinks: /usr/include/nodejs/deps/uv/include/{uv,uv.h} -> ../../../../{uv,uv.h}

[Jérémy Lal]

Le dim. 20 janv. 2019 à 02:12, Andreas Beckmann  a écrit :

> Followup-For: Bug #905415
> Control: reopen -1
> Control: reassign -1 libnode-dev 10.15.0~dfsg-8
> Control: retitle -1 libnode-dev: broken symlinks:
> /usr/include/nodejs/deps/uv/include/{uv,uv.h} -> ../../../../{uv,uv.h}
>
> Hi,
>
> the package reorganisation changed th eissue but did not completely
> resolve it.
>
> From the attached log (scroll to the bottom...):
>
> 0m36.7s ERROR: FAIL: Broken symlinks:
>   /usr/include/nodejs/deps/uv/include/uv.h -> ../../../../uv.h
> (libnode-dev)
>   /usr/include/nodejs/deps/uv/include/uv -> ../../../../uv (libnode-dev)
>
> Is libnode-dev missing a Depends: libuv1-dev ?
>

Yes, it looks so it is missing libuv1-dev

Jérémy

Bug#919752: mu-editor: Explain better what is wrong when micropython firmware is missing?

[Nick Morrott]

The root cause of this issue rests with the way mu-editor is currently packaged.

Upstream, mu-editor contains not just the editor but also uflash and
the compiled MicroPython hex, so flashing the micro:bit works out of
the box.

In Debian, such bundling is not permitted, hence I have split out out
uflash and MicroPython into their own packages. The placeholder
firmware-microbit-micropython-dl package (provided by python3-uflash)
sits in contrib, so cannot be added as a hard dependency on mu-editor.

Once firmware-microbit-micropython is accepted into unstable (it is
now in NEW) I can update the dependencies to ensure it is installed
with the editor and avoid the issue you raise in this report.

Thanks,
Nick

Bug#919834: libmono-btls-shared.so: undefined symbols: needs -pthread

[Paul Wise]

Package: mono-runtime-common
Version: 5.18.0.240+dfsg-1
Severity: minor
File: /usr/lib/libmono-btls-shared.so
User: debian...@lists.debian.org
Usertags: undefined-symbol adequate

libmono-btls-shared.so needs to compile and link with -pthread, see the
output of adequate, symtree and objdump below. I detected this on amd64
but the Debian build log scanner also detected dpkg-buildpackage
complaining about it on most architectures, see the w3m/getbuildlog
output below. In addition dpkg-buildpackage detected underlinking in
some other files.

I filed this bug at severity minor since I'm not sure if there are any
programs using the libmono-btls-shared.so lib or if they already use
the libpthread symbols and compile and link with -pthread or not.

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ adequate mono-runtime-common
mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
pthread_rwlock_rdlock
mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
pthread_rwlock_init
mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
pthread_getspecific
mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
pthread_rwlock_destroy
mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
pthread_key_create
mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
pthread_rwlock_wrlock
mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
pthread_once
mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
pthread_setspecific
mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
pthread_rwlock_unlock

$ man adequate | grep -A4  undefined-symbol
   undefined-symbol
   The symbol has not been found in the libraries linked with the 
binary.
   Either the binary either needs to be linked with an additional 
shared library,
   or the dependency on the shared library package that provides this 
symbol is too weak.

   References: Debian Policy §3.5, §8.6, §10.2.

$ lddtree /usr/lib/libmono-btls-shared.so
libmono-btls-shared.so => /usr/lib/libmono-btls-shared.so (interpreter => none)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

$ symtree /usr/lib/libmono-btls-shared.so
/usr/lib/libmono-btls-shared.so
libc.so.6 => 
socket,fflush,gmtime_r,gai_strerror,strncmp,__isoc99_sscanf,connect,ftell,strncpy,time,__stack_chk_fail,pthread_mutex_lock,realloc,abort,memchr,strdup,__assert_fail,feof,fgets,calloc,strlen,isxdigit,send,getaddrinfo,memset,__errno_location,fseek,read,memcmp,getsockopt,shutdown,__fprintf_chk,pthread_mutex_unlock,recv,fputs,lseek,memcpy,memcpy,fclose,__vsnprintf_chk,strtoul,setsockopt,malloc,strcasecmp,__ctype_b_loc,getenv,stderr,dup,__memset_chk,strncasecmp,fwrite,fread,gettimeofday,__memcpy_chk,close,open,strchr,qsort,__ctype_tolower_loc,__cxa_finalize,freeaddrinfo,fcntl,__xstat,isdigit,memmove,fopen64,__strcat_chk,strcmp,strerror,ferror,write,free
WEAK => _ITM_deregisterTMCloneTable,__gmon_start__,_ITM_registerTMCloneTable
UNRESOLVED => 
pthread_rwlock_rdlock,pthread_rwlock_init,pthread_getspecific,pthread_rwlock_destroy,pthread_key_create,pthread_rwlock_wrlock,pthread_once,pthread_setspecific,pthread_rwlock_unlock

$ objdump -T /lib/x86_64-linux-gnu/libpthdl.so.2 | grep -E "($(symtree 
/usr/lib/x86_64-linux-gnu/libzvbi-chains.so.0.0.0 | sed -n 's/UNRESOLVED => 
//p' | tr , '|'))$"
libpthread-2.28.so  libpthread.so.0 

$ objdump -T /lib/x86_64-linux-gnu/libpthread.so.0 | grep -E "($(symtree 
/usr/lib/libmono-btls-shared.so | sed -n 's/UNRESOLVED => //p' | tr , 
'|'))$"
ced0 gDF .text  03cf  GLIBC_2.2.5 
__pthread_rwlock_wrlock
f330 gDF .text  00ee  GLIBC_2.2.5 
__pthread_setspecific
f200 gDF .text  0056  GLIBC_2.2.5 
__pthread_key_create
c9e0 gDF .text  0003  GLIBC_2.2.5 
__pthread_rwlock_destroy
d780  w   DF .text  01db  GLIBC_2.2.5 
pthread_rwlock_unlock
c9a0 gDF .text  003a  GLIBC_2.2.5 
__pthread_rwlock_init
f2a0 gDF .text  0083  GLIBC_2.2.5 
__pthread_getspecific
c9e0 gDF .text  0003  GLIBC_2.2.5 
pthread_rwlock_destroy
f330  w   DF .text  00ee  GLIBC_2.2.5 
pthread_setspecific
d780 gDF .text  01db  GLIBC_2.2.5 
__pthread_rwlock_unlock
f9d0  w   DF .text  0015  GLIBC_2.2.5 pthread_once
c9f0  w   DF .text  024b  GLIBC_2.2.5 
pthread_rwlock_rdlock
c9a0 gDF .text  003a  GLIBC_2.2.5 
pthread_rwlock_init
f2a0  w   DF .text  0083  GLIBC_2.2.5 
pthread_getspecific
ced0  w   DF 

Bug#919743: RFS: rumur/2019.01.12-1 [ITP]

[Adam Borowski]

On Fri, Jan 18, 2019 at 06:43:13PM -0800, Matthew Fernandez wrote:
> * Package name: rumur
>   Version : 2019.01.12-1

>   dget -x 
> https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2019.01.12-1.dsc

> Changes since the last upload:
> 
>  Initial release. Closes #919220.

The package is marked as "UNRELEASED" -- ie, marked as not meant for
uploading.  Generally, RFS bugs are requests for actual uploads, there's no
need to file a bug if all you want is review of a WIP state.  I guess the
marking was left accidentally...

The package fails to build:
.
In file included from /<>/librumur/src/parse.cc:10:
/<>/librumur/include/rumur/scanner.h:6:12: fatal error: 
FlexLexer.h: No such file or directory
   #include 
`
This looks like missing build-dependency on libfl-dev.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#919819: RFS: knowthelist/2.3.1

[Adam Borowski]

On Sat, Jan 19, 2019 at 10:21:42PM +0100, Mario Stephan wrote:
> * Package name: knowthelist
>   Version : 2.3.1

>dget -x 
> https://mentors.debian.net/debian/pool/main/k/knowthelist/knowthelist_2.3.1.dsc

May I ask why did you convert the package to native?
* the upstream package is useful outside Debian
* the upstream package _exists_ (ie, doesn't come from Debian)
* the packaging hasn't been fully adapted to native

Generally, only stuff like debhelper makes sense as native, even if you're
upstream -- clear separation between upstream and packaging parts allows
other people to make non-maintainer uploads that can be reasonably
incorporated into your master repository.

(I haven't looked at other changes yet.)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#919833: 90% of shell scripts probably don't have a .sh extension

[積丹尼 Dan Jacobson]

Package: bash-completion
Version: 1:2.8-5
Severity: wishlist
File: /usr/share/bash-completion/completions/sh

I think 90% of shell scripts don't have a .sh extension.
Therefore
$ sh anyf
should still complete to
$ sh anyfile
Thanks.

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

Package: src:linux
Version: 4.19.12-1~bpo9+1
Severity: important
 
The only solution is to revert to 4.17.
 
Jan 19 18:14:35 vhost004 kernel: INFO: task btrfs-transacti:691 blocked for 
more than 120 seconds.
Jan 19 18:14:35 vhost004 kernel:   Tainted: G  I E 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Jan 19 18:14:35 vhost004 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 19 18:14:35 vhost004 kernel: btrfs-transacti D0   691  2 0x8000
Jan 19 18:14:35 vhost004 kernel: Call Trace:
Jan 19 18:14:35 vhost004 kernel:  ? __schedule+0x3f5/0x880
Jan 19 18:14:35 vhost004 kernel:  schedule+0x32/0x80
Jan 19 18:14:35 vhost004 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Jan 19 18:14:35 vhost004 kernel:  ? remove_wait_queue+0x60/0x60
Jan 19 18:14:35 vhost004 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Jan 19 18:14:35 vhost004 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Jan 19 18:14:35 vhost004 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Jan 19 18:14:35 vhost004 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Jan 19 18:14:35 vhost004 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Jan 19 18:14:35 vhost004 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Jan 19 18:14:35 vhost004 kernel:  kthread+0xf8/0x130
Jan 19 18:14:35 vhost004 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Jan 19 18:14:35 vhost004 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Jan 19 18:14:35 vhost004 kernel:  ret_from_fork+0x35/0x40
Jan 19 18:16:35 vhost004 kernel: INFO: task btrfs-transacti:691 blocked for 
more than 120 seconds.
Jan 19 18:16:35 vhost004 kernel:   Tainted: G  I E 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Jan 19 18:16:35 vhost004 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 19 18:16:35 vhost004 kernel: btrfs-transacti D0   691  2 0x8000
Jan 19 18:16:35 vhost004 kernel: Call Trace:
Jan 19 18:16:35 vhost004 kernel:  ? __schedule+0x3f5/0x880
Jan 19 18:16:35 vhost004 kernel:  schedule+0x32/0x80
Jan 19 18:16:35 vhost004 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Jan 19 18:16:35 vhost004 kernel:  ? remove_wait_queue+0x60/0x60
Jan 19 18:16:35 vhost004 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Jan 19 18:16:35 vhost004 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Jan 19 18:16:35 vhost004 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Jan 19 18:16:35 vhost004 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Jan 19 18:16:35 vhost004 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Jan 19 18:16:35 vhost004 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Jan 19 18:16:35 vhost004 kernel:  kthread+0xf8/0x130
Jan 19 18:16:35 vhost004 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Jan 19 18:16:35 vhost004 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Jan 19 18:16:35 vhost004 kernel:  ret_from_fork+0x35/0x40
Jan 19 18:16:37 vhost004 crmd[1539]:   notice: High CPU load detected: 55.71
Jan 19 18:17:01 vhost004 CRON[15470]: pam_unix(cron:session): session opened 
for user root by (uid=0)
Jan 19 18:17:01 vhost004 CRON[15471]: (root) CMD (   cd / && run-parts --report 
/etc/cron.hourly)
Jan 19 18:17:01 vhost004 CRON[15470]: pam_unix(cron:session): session closed 
for user root
Jan 19 18:17:07 vhost004 crmd[1539]:   notice: High CPU load detected: 41.509998
Jan 19 18:17:37 vhost004 crmd[1539]:   notice: High CPU load detected: 32.63
Jan 19 18:18:07 vhost004 crmd[1539]:   notice: High CPU load detected: 27.27
Jan 19 18:18:36 vhost004 kernel: INFO: task btrfs-transacti:691 blocked for 
more than 120 seconds.
Jan 19 18:18:36 vhost004 kernel:   Tainted: G  I E 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Jan 19 18:18:36 vhost004 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 19 18:18:36 vhost004 kernel: btrfs-transacti D0   691  2 0x8000
Jan 19 18:18:36 vhost004 kernel: Call Trace:
Jan 19 18:18:36 vhost004 kernel:  ? __schedule+0x3f5/0x880
Jan 19 18:18:36 vhost004 kernel:  schedule+0x32/0x80
Jan 19 18:18:36 vhost004 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Jan 19 18:18:36 vhost004 kernel:  ? remove_wait_queue+0x60/0x60
Jan 19 18:18:36 vhost004 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Jan 19 18:18:36 vhost004 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Jan 19 18:18:36 vhost004 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Jan 19 18:18:36 vhost004 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Jan 19 18:18:36 vhost004 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Jan 19 18:18:36 vhost004 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Jan 19 18:18:36 vhost004 kernel:  kthread+0xf8/0x130
Jan 19 18:18:36 vhost004 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Jan 19 18:18:36 vhost004 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Jan 19 

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

Package: src:linux
Version: 4.19.12-1~bpo9+1
Severity: important
 
Yes, the btrfs hung task problem still exists in the latest kernel.
 
 
Jan 19 18:40:41 vhost003 kernel: INFO: task btrfs-transacti:666 blocked for 
more than 120 seconds.
Jan 19 18:40:41 vhost003 kernel: Tainted: G I E 4.19.0-0.bpo.1-amd64 #1 Debian 
4.19.12-1~bpo9+1
Jan 19 18:40:41 vhost003 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 19 18:40:41 vhost003 kernel: btrfs-transacti D 0 666 2 0x8000
Jan 19 18:40:41 vhost003 kernel: Call Trace:
Jan 19 18:40:41 vhost003 kernel: ? __schedule+0x3f5/0x880
Jan 19 18:40:41 vhost003 kernel: schedule+0x32/0x80
Jan 19 18:40:41 vhost003 kernel: btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Jan 19 18:40:41 vhost003 kernel: ? remove_wait_queue+0x60/0x60
Jan 19 18:40:41 vhost003 kernel: btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Jan 19 18:40:41 vhost003 kernel: __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Jan 19 18:40:41 vhost003 kernel: btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Jan 19 18:40:41 vhost003 kernel: btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Jan 19 18:40:41 vhost003 kernel: ? start_transaction+0x8f/0x3e0 [btrfs]
Jan 19 18:40:41 vhost003 kernel: transaction_kthread+0x157/0x180 [btrfs]
Jan 19 18:40:41 vhost003 kernel: kthread+0xf8/0x130
Jan 19 18:40:41 vhost003 kernel: ? btrfs_cleanup_transaction+0x500/0x500 [btrfs]
Jan 19 18:40:41 vhost003 kernel: ? kthread_create_worker_on_cpu+0x70/0x70
Jan 19 18:40:41 vhost003 kernel: ret_from_fork+0x35/0x40

Jan 19 18:42:42 vhost003 kernel: INFO: task btrfs-transacti:666 blocked for 
more than 120 seconds.
Jan 19 18:42:42 vhost003 kernel:   Tainted: G  I E 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Jan 19 18:42:42 vhost003 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 19 18:42:42 vhost003 kernel: btrfs-transacti D0   666  2 0x8000
Jan 19 18:42:42 vhost003 kernel: Call Trace:
Jan 19 18:42:42 vhost003 kernel:  ? __schedule+0x3f5/0x880
Jan 19 18:42:42 vhost003 kernel:  schedule+0x32/0x80
Jan 19 18:42:42 vhost003 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Jan 19 18:42:42 vhost003 kernel:  ? remove_wait_queue+0x60/0x60
Jan 19 18:42:42 vhost003 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Jan 19 18:42:42 vhost003 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Jan 19 18:42:42 vhost003 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Jan 19 18:42:42 vhost003 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Jan 19 18:42:42 vhost003 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Jan 19 18:42:42 vhost003 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Jan 19 18:42:42 vhost003 kernel:  kthread+0xf8/0x130
Jan 19 18:42:42 vhost003 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Jan 19 18:42:42 vhost003 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Jan 19 18:42:42 vhost003 kernel:  ret_from_fork+0x35/0x40
Jan 19 18:44:43 vhost003 kernel: INFO: task btrfs-transacti:666 blocked for 
more than 120 seconds.
Jan 19 18:44:43 vhost003 kernel:   Tainted: G  I E 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Jan 19 18:44:43 vhost003 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 19 18:44:43 vhost003 kernel: btrfs-transacti D0   666  2 0x8000
Jan 19 18:44:43 vhost003 kernel: Call Trace:
Jan 19 18:44:43 vhost003 kernel:  ? __schedule+0x3f5/0x880
Jan 19 18:44:43 vhost003 kernel:  schedule+0x32/0x80
Jan 19 18:44:43 vhost003 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Jan 19 18:44:43 vhost003 kernel:  ? remove_wait_queue+0x60/0x60
Jan 19 18:44:43 vhost003 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Jan 19 18:44:43 vhost003 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Jan 19 18:44:43 vhost003 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Jan 19 18:44:43 vhost003 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Jan 19 18:44:43 vhost003 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Jan 19 18:44:43 vhost003 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Jan 19 18:44:43 vhost003 kernel:  kthread+0xf8/0x130
Jan 19 18:44:43 vhost003 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Jan 19 18:44:43 vhost003 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Jan 19 18:44:43 vhost003 kernel:  ret_from_fork+0x35/0x40

Jan 19 18:46:43 vhost003 kernel: INFO: task btrfs-transacti:666 blocked for 
more than 120 seconds.
Jan 19 18:46:43 vhost003 kernel:   Tainted: G  I E 
4.19.0-0.bpo.1-amd64 #1 Debian 4.19.12-1~bpo9+1
Jan 19 18:46:43 vhost003 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 19 18:46:43 vhost003 kernel: btrfs-transacti D0   666  2 0x8000
Jan 19 18:46:43 vhost003 kernel: Call Trace:
Jan 19 18:46:43 vhost003 kernel:  ? __schedule+0x3f5/0x880
Jan 19 18:46:43 vhost003 kernel:  schedule+0x32/0x80
Jan 19 18:46:43 vhost003 

Bug#905415: libnode-dev: broken symlinks: /usr/include/nodejs/deps/uv/include/{uv,uv.h} -> ../../../../{uv,uv.h}

[Andreas Beckmann]

Followup-For: Bug #905415
Control: reopen -1
Control: reassign -1 libnode-dev 10.15.0~dfsg-8
Control: retitle -1 libnode-dev: broken symlinks: 
/usr/include/nodejs/deps/uv/include/{uv,uv.h} -> ../../../../{uv,uv.h}

Hi,

the package reorganisation changed th eissue but did not completely
resolve it.

>From the attached log (scroll to the bottom...):

0m36.7s ERROR: FAIL: Broken symlinks:
  /usr/include/nodejs/deps/uv/include/uv.h -> ../../../../uv.h (libnode-dev)
  /usr/include/nodejs/deps/uv/include/uv -> ../../../../uv (libnode-dev)

Is libnode-dev missing a Depends: libuv1-dev ?


Andreas


libnode-dev_10.15.0~dfsg-8.log.gz
Description: application/gzip

Bug#660687: Update on ITA: xml-core

[Joseph Herlant]

Hi guys,

I haven't had much time to work on this over the last few weeks.
Other priorities have showed up.
I'll get back to this when I get more time. In the meantime if someone else 
wants to get on, take care of the bug
reports and adopt the package, go ahead. If not, I'll finish that later.

Thanks,
Joseph


signature.asc
Description: PGP signature

Bug#919832: gap-table-of-marks: broken symlink: /usr/share/doc/gap-table-of-marks/doc -> ../../gap/pkg/Tomlib/doc

[Andreas Beckmann]

Package: gap-table-of-marks
Version: 1.2.7-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + gap-libs

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

1m24.4s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/gap-table-of-marks/doc -> ../../gap/pkg/Tomlib/doc 
(gap-table-of-marks)
^
There is no directory Tomlib in any package in the archive.
You probably meant to target .../TomLib/...
^

cheers,

Andreas


gap-libs_4r10p0-6.log.gz
Description: application/gzip

Bug#919831: libcds-moc-java: FTBFS (The code being documented uses packages in the unnamed module)

[Santiago Vila]

Package: src:libcds-moc-java
Version: 5.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with javahelper
   dh_update_autotools_config -i
   jh_linkjars -i
   debian/rules override_jh_build
make[1]: Entering directory '/<>'
jh_build --javacopts="-encoding ISO-8859-15" --javadoc-opts="-encoding 
ISO-8859-15"
find cds -name *.java -and -type f -print0 | xargs -s 512000 -0 
/usr/lib/jvm/default-java/bin/javac -g -cp 
/usr/share/java/healpix.jar:debian/_jh_build.cds.moc -d 
debian/_jh_build.cds.moc -source 1.7 -target 1.7 -encoding ISO-8859-15
warning: [options] bootstrap class path not set in conjunction with -source 7
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
find cds -name *.java -and -type f -print0 | xargs -s 512000 -0 
/usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
/usr/share/doc/default-jdk-doc/api -link 
/usr/share/doc/default-jre-headless/api -classpath 
/usr/share/java/healpix.jar:debian/_jh_build.cds.moc -d 
debian/_jh_build.javadoc/api -quiet -notimestamp -source 1.7 -encoding 
ISO-8859-15
Creating destination directory: "debian/_jh_build.javadoc/api/"
javadoc: error - The code being documented uses packages in the unnamed module, 
but the packages defined in /usr/share/doc/default-jdk-doc/api/ are in named 
modules.
javadoc: error - The code being documented uses packages in the unnamed module, 
but the packages defined in /usr/share/doc/default-jre-headless/api/ are in 
named modules.
cds/moc/HealpixMoc.java:517: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:518: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:519: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:520: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:982: warning - invalid usage of tag <
cds/moc/HealpixMoc.java:982: warning - invalid usage of tag <
cds/moc/HealpixMoc.java:974: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:990: warning - invalid usage of tag <
cds/moc/HealpixMoc.java:307: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:307: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:377: warning - @param argument "npixs" is not a 
parameter name.
cds/moc/HealpixMoc.java:417: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:418: warning - @param argument "testHierarchy" is not a 
parameter name.
cds/moc/HealpixMoc.java:517: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:518: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:519: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:520: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:622: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:647: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:693: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:974: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:982: warning - invalid usage of tag <
cds/moc/HealpixMoc.java:982: warning - invalid usage of tag <
cds/moc/HealpixMoc.java:990: warning - invalid usage of tag <
cds/moc/IntArray.java:91: warning - invalid usage of tag >
cds/moc/IntArray.java:91: warning - invalid usage of tag >
cds/moc/LongArray.java:90: warning - invalid usage of tag >
cds/moc/LongArray.java:90: warning - invalid usage of tag >
cds/moc/MocIO.java:136: warning - invalid usage of tag &
cds/moc/MocIO.java:136: warning - invalid usage of tag &
cds/moc/MocIO.java:152: warning - invalid usage of tag >
cds/moc/ShortArray.java:92: warning - invalid usage of tag >
cds/moc/ShortArray.java:92: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:517: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:518: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:519: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:520: warning - invalid usage of tag >
cds/moc/IntArray.java:91: warning - invalid usage of tag >
cds/moc/LongArray.java:90: warning - invalid usage of tag >
cds/moc/ShortArray.java:92: warning - invalid usage of tag >
cds/moc/MocIO.java:136: warning - invalid usage of tag &
cds/moc/HealpixMoc.java:982: warning - invalid usage of tag <
cds/moc/HealpixMoc.java:982: warning - invalid usage of tag <
cds/moc/HealpixMoc.java:974: warning - invalid usage of tag >
cds/moc/HealpixMoc.java:990: warning - invalid usage of tag <
2 errors
45 warnings
make[1]: *** [debian/rules:10: override_jh_build] Error 123
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with 

Bug#919747: gnome-keysign: please package gnome-keysign 1.0.0

[Daniel Kahn Gillmor]

On Sat 2019-01-19 18:53:28 +0100, Sascha Steinbiss wrote:
> as you may not have noticed, I have prepared packaging for 1.0.0 in the
> gnome-keysign repo on Salsa [1]. It took some work because I had to
> switch everything to Python 3 due to dependency requirements (some
> Python modules newly required in 1.0.0 are only available for Python 3,
> and one even had to be vendored...).

I understand that it's a lot of work, but I'm very happy to see the move
to python3 -- thank you for doing that!

I'm assuming that "vendored" means "bundled with the gnome-keysign,
rather than shipped as an independent python3 module".

I didn't realize that any modules needed to be vendored though -- that
sounds like not a great outcome for debian.  Do you have more details
written down someplace about which module it is, and why vendoring is
necessary?

all the best,

--dkg


signature.asc
Description: PGP signature

Bug#919614: RFS: note/1.3.26-2 [ITA]

[eamanu15]

Hello Dmitry,


> Uploaded. There is some things you may want to address in next revision:
>
>  * debian/watch uses plain http. Any chance for https?
>  * there is a lot of spelling errors. Please fix them and submit patch
>upstream.
>  * /usr/share/perl5/NOTEDB/README is bad. Move it into documentation.
>

That observation are correct. I will work on that.

Thanks!



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

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Adam Borowski]

On Sat, Jan 19, 2019 at 07:34:26PM +, Dmitry Bogatov wrote:
> [2019-01-18 02:20] Adam Borowski 
> > That ship has long since sailed.  What's the point of making sysv-rc support
> > non-/usr early boot if the rest of the system doesn't?  It may still work on
> > some simple installs, but even that quite rapidly degrades as random
> > packages get changed to simplify this away.
> 
> The same argument could be applied to many other things: systemd,
> web-2.0, html emails, MS Office, GitLab/Hub. Still, I use runit init
> system, text browser, text mail client and still send patches via
> git-send-email.
> 
> I object when someone appears and try break my beautiful little
> paradise.  And I definitely do not want to come and break someone's
> else.

That's not what my argument is -- what I mean, is that there's many more
components that need to stick strictly to files not on /usr during that
phase of the boot, sysv-rc being only a single one.  Efforts to keep it
working are a waste of time, not because you won't get to simplify things,
but because you would need to override a number of other maintainers.

Simple setups still work in Buster, but it's easy to run into something that
doesn't.  That'd be a nasty surprise for the user, thus it's better to make
the break faster and more obvious.  Then, pretty surely even such simple
setups won't work in Bullseye.

> > >   Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will be
> > >   in 2.93-4 (due in few days). Sysvinit will *not* assume, that /usr is
> > >   mounted at /sbin/init invocation in Buster. I promise.
> > 
> > That's a waste of your time.  Both for and after Buster.
> 
> That is being responsible to my users. I do not consider it waste.

There's a cost to migrations like this: any move may break stuff.  For
example, it breaks that silly little init I used to have in my .sig (and
included in this mail), but people may refer to that file for reasons other
than mere fun.

There's an easy way for Buster: just drop the move, it serves no need.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start
⣾⠁⢰⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax
⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child:
⠈⠳⣄ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall

Bug#919830: ansible-doc: missing Depends: ${sphinxdoc:Depends}

[Andreas Beckmann]

Package: ansible-doc
Version: 2.7.5+dfsg-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m26.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/ansible-doc/html/_static/js/theme.js -> 
../../../../../sphinx_rtd_theme/static/js/theme.js (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/fontawesome-webfont.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2 
(ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/fontawesome-webfont.woff -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff 
(ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/fontawesome-webfont.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf 
(ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/fontawesome-webfont.svg -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg 
(ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/fontawesome-webfont.eot -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot 
(ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/RobotoSlab-Regular.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2 
(ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/RobotoSlab-Regular.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.ttf 
(ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/RobotoSlab-Bold.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2 (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/RobotoSlab-Bold.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.ttf (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/Lato-Regular.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2 (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/Lato-Regular.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/Lato-Italic.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2 (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/Lato-Italic.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/Lato-BoldItalic.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2 (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/Lato-BoldItalic.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/Lato-Bold.woff2 -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2 (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/fonts/Lato-Bold.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/css/theme.css -> 
../../../../../sphinx_rtd_theme/static/css/theme.css (ansible-doc)
  /usr/share/doc/ansible-doc/html/_static/css/badge_only.css -> 
../../../../../sphinx_rtd_theme/static/css/badge_only.css (ansible-doc)

As Dmitry Shachnev mentioned in #911069:

> These symlinks are generated by dh_sphinxdoc, so better to depend on
> ${sphinxdoc:Depends}.


cheers,

Andreas


ansible-doc_2.7.5+dfsg-2.log.gz
Description: application/gzip

Bug#919827: asterisk-espeak: FTBFS (Externally compiled modules must declare AST_MODULE_SELF_SYM)

[Santiago Vila]

Package: src:asterisk-espeak
Version: 5.0~1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules binary-arch
test -x debian/rules
dh_testroot
dh_prep 
dh_installdirs -A 
mkdir -p "."
/usr/bin/make -C . CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -pipe -fPIC -Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -D_REENTRANT 
-D_GNU_SOURCE" CXXFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security" 
CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" 
make[1]: Entering directory '/<>'
gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -pipe -fPIC -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wmissing-declarations -D_REENTRANT -D_GNU_SOURCE -g -O2 
-c -o app_espeak.o app_espeak.c
In file included from app_espeak.c:34:
/usr/include/asterisk.h:232:2: error: #error "Externally compiled modules must 
declare AST_MODULE_SELF_SYM."
 #error "Externally compiled modules must declare AST_MODULE_SELF_SYM."
  ^
In file included from app_espeak.c:43:
app_espeak.c: In function 'load_module':
app_espeak.c:414:9: error: 'AST_MODULE_SELF' undeclared (first use in this 
function); did you mean 'AST_MODULE_INFO'?
  return ast_register_application(app, espeak_exec, synopsis, descrip) ?
 ^~~~
app_espeak.c:414:9: note: each undeclared identifier is reported only once for 
each function it appears in
app_espeak.c:416:1: warning: control reaches end of non-void function 
[-Wreturn-type]
 }
 ^
make[1]: *** [Makefile:36: app_espeak.o] Error 1
make[1]: Leaving directory '/<>'
make: *** [/usr/share/cdbs/1/class/makefile.mk:77: debian/stamp-makefile-build] 
Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#919829: libatteanx-store-sparql-perl: FTBFS (failing tests)

[Santiago Vila]

Package: src:libatteanx-store-sparql-perl
Version: 0.010-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
test -x debian/rules
mkdir -p "."

Scanning upstream source for new/changed copyright notices...

set -e; LC_ALL=C.UTF-8 /usr/bin/licensecheck --check '.*' --recursive 
--copyright --deb-fmt --ignore 
'^(debian/(changelog|copyright(|_hints|_newhints)))$' --lines 0 * | 
/usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints
8 combinations of copyright and licensing found.
WARNING:New or changed notices discovered:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
License: Artistic-1.0 and/or GPL-1

To fix the situation please do the following:

[... snipped ...]

t/triplestore.t .. 
# Subtest: testing with main
# Subtest: get_triples
ok 1
ok 2
1..2
ok 1 - get_triples
# Subtest: count_triples
ok 1 - unexpected IRI
ok 2 - expected subject
ok 3 - expected predicate
ok 4 - expected object
ok 5 - expected object (2)
ok 6 - expected subject/object
ok 7 - expected predicate with variable
ok 8 - expected object with variable
ok 9 - expected object (2) with variable
ok 10 - expected subject/object with variable
ok 11 - count_triples_estimate
1..11
ok 2 - count_triples
# Subtest: size
ok 1
ok 2
ok 3
ok 4
1..4
ok 3 - size
1..3
ok 1 - testing with main
1..1
ok

Test Summary Report
---
t/plan.t   (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
Files=2, Tests=1,  7 wallclock secs ( 0.05 usr  0.01 sys +  5.78 cusr  0.51 
csys =  6.35 CPU)
Result: FAIL
Failed 1/2 test programs. 0/1 subtests failed.
make[1]: *** [Makefile:871: test_dynamic] Error 255
make[1]: Leaving directory '/<>'
make: *** [/usr/share/cdbs/1/class/makefile.mk:113: 
debian/stamp-makefile-check] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libatteanx-store-sparql-perl.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#919828: asterisk-opus: FTBFS (Externally compiled modules must declare AST_MODULE_SELF_SYM)

[Santiago Vila]

Package: src:asterisk-opus
Version: 13.7+20171009-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules binary-arch
test -x debian/rules
dh_testroot
dh_prep 
dh_installdirs -A 
mkdir -p "."
/usr/bin/make -C . CFLAGS="-g -O2 
-fdebug-prefix-map=/<>/asterisk-opus-13.7+20171009=. 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC" CXXFLAGS="-g 
-O2 -fdebug-prefix-map=/<>/asterisk-opus-13.7+20171009=. 
-fstack-protector-strong -Wformat -Werror=format-security" 
CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" 
make[1]: Entering directory '/<>/asterisk-opus-13.7+20171009'
gcc -o codecs/codec_opus_open_source.so  
-DAST_MODULE=\"codec_opus_open_source\" -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>/asterisk-opus-13.7+20171009=. 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC -g3 -O3 -lopus 
-shared -Wl,-z,relro codecs/codec_opus_open_source.c
In file included from codecs/codec_opus_open_source.c:39:
/usr/include/asterisk.h:232:2: error: #error "Externally compiled modules must 
declare AST_MODULE_SELF_SYM."
 #error "Externally compiled modules must declare AST_MODULE_SELF_SYM."
  ^
In file included from codecs/codec_opus_open_source.c:56:
codecs/codec_opus_open_source.c: In function 'load_module':
codecs/codec_opus_open_source.c:833:8: error: 'AST_MODULE_SELF' undeclared 
(first use in this function); did you mean 'AST_MODULE_INFO'?
  res = ast_register_translator();
^~~
codecs/codec_opus_open_source.c:833:8: note: each undeclared identifier is 
reported only once for each function it appears in
make[1]: *** [Makefile:50: codecs/codec_opus_open_source.so] Error 1
make[1]: Leaving directory '/<>/asterisk-opus-13.7+20171009'
make: *** [/usr/share/cdbs/1/class/makefile.mk:77: debian/stamp-makefile-build] 
Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#917482: jhove: FTBFS in buster at least since 2018-12-07

[tony mancill]

On Sat, Jan 19, 2019 at 04:51:02PM -0500, Abdelhakim Qbaich wrote:
> Hi,
> 
> I've attached a patch and made an upstream pull request.

Hello Abdelhakim Qbaich,

Thank you for the patch.  I have applied it and a few other misc
packaging changes and uploaded to the archive.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#919826: linux-image-4.19.0-1-arm64: Loading Linux 4.19.0-1-arm64 Loading initial ramdisk error: out of memory system panic

[Andy Simpkins]

Package: linux-image-4.19.0-1-arm64
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

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

   * What led up to the situation?
upgrading kernel in Buster from 4.18.0-3-arm64 via apt-get dist-upgrade

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
root@sally:~# uname -a
Linux sally 4.18.0-3-arm64 #1 SMP Debian 4.18.20-2 (2018-11-23) aarch64 
GNU/Linux
root@sally:~# ## update apt/sources to point to a mirror (was DVD)
root@sally:~# apt-get update
Hit:1 http://ftp.uk.debian.org/debian buster InRelease
Hit:2 http://security.debian.org/debian-security buster/updates InRelease
Reading package lists... Done 
root@sally:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  libhunspell-1.6-0 liblvm2app2.2 liblvm2cmd2.02 libpython3.6-minimal 
libpython3.6-stdlib python3.6 python3.6-minimal
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  apparmor firmware-linux-free irqbalance libaio1 libdns-export1104 
libhunspell-1.7-0 libisc-export1100 liblvm2cmd2.03 libnftables0 libnftnl11 
libnuma1
  libpython3.7-minimal libpython3.7-stdlib libuchardet0 
linux-image-4.19.0-1-arm64 nftables python3.7 python3.7-minimal
The following packages will be upgraded:
  adwaita-icon-theme apt apt-utils bash-completion bind9-host bsdutils dash 
dbus dbus-user-session dconf-gsettings-backend dconf-service dmeventd
  dmsetup e2fsprogs enchant fdisk file gcc-8-base gir1.2-atk-1.0 
gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-glib-2.0 gir1.2-gtk-3.0 
gir1.2-pango-1.0
  gir1.2-vte-2.91 glib-networking glib-networking-common 
glib-networking-services gpgv grep groff-base grub-common grub-efi-arm64 
grub-efi-arm64-bin
  grub-efi-arm64-signed grub2-common gtk-update-icon-cache gzip init 
init-system-helpers iproute2 iptables isc-dhcp-client isc-dhcp-common 
klibc-utils
  krb5-locales libapparmor1 libapt-inst2.0 libapt-pkg5.0 libatk1.0-0 
libatk1.0-data libbind9-161 libblkid1 libc-bin libc-l10n libc6 libcairo-gobject2
  libcairo2 libcap-ng0 libcom-err2 libcroco3 libcryptsetup12 libcups2 
libdbus-1-3 libdconf1 libdebconfclient0 libdevmapper-event1.02.1
  libdevmapper1.02.1 libdns1104 libedit2 libefiboot1 libefivar1 libelf1 
libenchant1c2a libext2fs2 libfdisk1 libfribidi0 libfstrm0 libfuse2 libgcc1
  libgcrypt20 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common 
libgirepository-1.0-1 libglib2.0-0 libglib2.0-data libgmp10 libgnutls30
  libgpg-error0 libgraphite2-3 libgssapi-krb5-2 libgtk-3-0 libgtk-3-bin 
libgtk-3-common libharfbuzz0b libhogweed4 libicu63 libip4tc0 libip6tc0 libiptc0
  libisc1100 libisccc161 libisccfg163 libjansson4 libjson-glib-1.0-0 
libjson-glib-1.0-common libk5crypto3 libklibc libkrb5-3 libkrb5support0
  libldap-2.4-2 libldap-common liblwres161 liblz4-1 libmagic-mgc libmagic1 
libmount1 libnettle6 libnghttp2-14 libpam-modules libpam-modules-bin
  libpam-runtime libpam-systemd libpam0g libpango-1.0-0 libpangocairo-1.0-0 
libpangoft2-1.0-0 libpangoxft-1.0-0 libperl5.28 libpixman-1-0 libpng16-16
  libproxy1v5 libpython3-stdlib libpython3.6-minimal libpython3.6-stdlib 
librsvg2-2 librsvg2-common libsemanage-common libsemanage1 libsmartcols1
  libsoup-gnome2.4-1 libsoup2.4-1 libsqlite3-0 libss2 libstdc++6 libsystemd0 
libudev1 libuuid1 libvte-2.91-0 libvte-2.91-common libxcb-render0
  libxcb-shm0 libxcb1 libxml2 libxtables12 libzstd1 linux-image-arm64 locales 
lvm2 man-db mount openssh-client openssh-server openssh-sftp-server
  os-prober perl perl-base perl-modules-5.28 publicsuffix python3 
python3-chardet python3-debianbts python3-gi python3-gi-cairo python3-minimal
  python3-pkg-resources python3-pycurl python3-pysimplesoap python3-six 
python3.6 python3.6-minimal rsyslog sed systemd systemd-sysv sysvinit-utils tar
  task-english task-ssh-server tasksel tasksel-data telnet tzdata ucf udev 
util-linux util-linux-locales vim-common vim-tiny wget xdg-user-dirs xxd
203 upgraded, 18 newly installed, 0 to remove and 0 not upgraded.
Need to get 144 MB of archives.
After this operation, 260 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

--- 8< ---
  
Get:207 http://ftp.uk.debian.org/debian buster/main arm64 
linux-image-4.19.0-1-arm64 arm64 4.19.12-1 [39.7 MB]
   
Get:208 http://ftp.uk.debian.org/debian buster/main arm64 linux-image-arm64 
arm64 4.19+101 [7,952 B]  

--- 8< ---

Processing triggers for systemd (240-4) ...
Setting up grub-efi-arm64 (2.02+dfsg1-10) ...
Installing for arm64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.19.0-1-arm64
Found initrd 

Bug#919758: [Pkg-xen-devel] Bug#919758: xen-hypervisor-4.8-amd64: Wrong examples provided in GRUB config file

[Hans van Kranenburg]

Hi Gergely,

On 1/19/19 9:32 AM, root wrote:
> Package: src:xen
> Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11
> Severity: minor
> 
> Dear Maintainer,
> 
> the GRUB configuration file /etc/defaults/grub.d/xen.cfg contains incorrect 
> examples:
> 
> 1. Bad syntax for dom0 memory allocation settings:
> 
>https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#list
> 
>Bad syntax (max value is ignored this way): 
> dom0_mem=[M]:max=[M]
>Correct syntax: dom0_mem=[M],max:[M]
> 
> 2. Bad syntax for earlyprintk usage:
> 
>
> https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt
> 
>Bad syntax: earlyprintk=xenboot
>Correct syntax: earlyprintk=xen
> 
> Please correct the examples to avoid confusion for users new to Xen (like 
> myself).
> 
> [...]
Thanks for the report. You are completely right.

I took some time today to update the examples in this file a bit.

Here's the result:

https://salsa.debian.org/xen-team/debian-xen/commit/d461dc6fbe180c564de4f514a4fe7266f02a8fea

Hans

Bug#919395: Heads up to release team about MariadB 10.3

[Andreas Beckmann]

On 2019-01-19 21:14, Andreas Beckmann wrote:
> Getting back to the current case: I assume this is caused by
> libmariadbclient-dev being turned into a virtual package provided by
> libmariadb-dev. I'll test whether reintroducing a transitional package
> would improve the situation. Might require a trip through NEW, though.
> A transitional package would also be needed to provide a smooth upgrade
> path for people that consciously installed libmariadbclient-dev in stretch.

That seems to work better with a transitional package.
@otto: you can find it in branch anbe/libmariadbclient-dev

Andreas

Bug#910627: closed by Louis-Philippe Véronneau (Bug#910627: fixed in nostalgy 0.2.36-1.1)

[Daniel Reichelt]

On 19.01.19 22:06, Debian Bug Tracking System wrote:
> It has been closed by Louis-Philippe Véronneau .

Thanks, Louis-Philippe,
one less package I have to take care about in a private repository.
Great work. Thanks so much!!!

Best,
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#919507: Reboot required patch for Debian policy

[Karl O. Pinc]

On Sat, 19 Jan 2019 11:10:09 -0700
Sean Whitton  wrote:

> On Fri 18 Jan 2019 at 12:04PM -0600, Karl O. Pinc wrote:

> > +Maintainer scripts can signal that a reboot is required to fully
> > apply +the changes to the system by touching
> > ``/run/reboot-required`` and +adding the package name to
> > ``/run/reboot-required.pkgs``. Maintainer +scripts should not add
> > the package name to +``/run/reboot-required.pkgs`` if it is already
> > present there.  
> 
> Are you sure that adding the package name to the .pkgs file is
> required? I've not seen that file on my system; it seems that only
> /run/reboot-required is used.  Balint said that the .pkgs is an Ubuntu
> thing; are you sure it has been upstreamed into Debian?

Yes:
https://sources.debian.org/src/unattended-upgrades/1.9/kernel/postinst.d/unattended-upgrades/#L10

I can't say what's _required_.  I'm following Balint's wording.

It is clear to me that a reboot will occur whenever
/var/run/reboot-required exists, regardless of the
state of /var/run/reboot-required.pkgs.

It is not clear to me where reboot-required.pkgs is used.
But see:
 https://codesearch.debian.net/search?q=run%2Freboot-required.pkgs

(Returns:
 lynis, unattended-upgrades, hobbit-plugins, reboot-notifier, kubernetes
)

I am adding some wording about the purpose of reboot-required.pkgs,
based on the results of the above search.

I'm also adding wording which says that the OS may or may not
actually reboot.

> > +
> > +The appropriate place to do this is expected to be when the
> > +``postinst`` script is called as ``postinst configure
> > +most-recently-configured-version``.
> > +
> > +Ordinary programs may manipulate these files to signal that a
> > reboot +is required.
> > +  
> 
> This is a bit awkward.  You describe this feature in terms of
> maintainer scripts and then say that programs can use it too.  It
> would be better to put it in ch. 9 or ch. 10, I think, and describe
> it in more general terms.

All right.  I'll put it in ch 9 at the bottom.  I think it belongs
there _and_ it won't mess with section numbering.

(I had had it in the middle of chapter 6 because it seemed
an appropriate place -- before all the details.)

Attached is reboot_required_v4.patch

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

P.S.  Never changing section numbering seems a hard row to hoe.

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 59c92ec..78d3136 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -1040,3 +1040,39 @@ Debian, so this section has been removed.
activate the trigger. In that case, it can be done by calling
``dpkg-trigger --no-await /usr/lib/mime/packages`` from the
maintainer script after creating, modifying, or removing the file.
+
+.. index::
+   pair: signaling; reboot
+
+.. _s-signalingreboot
+
+Signaling that a reboot is required
+---
+
+.. index::
+   single: reboot-required
+   single: reboot-required.pkgs
+
+Programs can signal that a reboot is required by ``touch``\ing
+``/run/reboot-required``.  To inform users as to which package(s)
+require a reboot, add the name of the package(s) requiring the reboot
+to ``/run/reboot-required.pkgs``. Programs should not add a package
+name to ``/run/reboot-required.pkgs`` if it is already present there.
+
+.. index:
+   single: postinst
+
+An expected time to signal that a reboot is required is upon
+installation or upgrade of a package.  Signaling is called for when a
+reboot is needed to fully apply the changes a package introduces.  The
+appropriate place to manipulate reboot related files is expected to be
+in the ``postinst`` maintainer script when it is called as ``postinst
+configure most-recently-configured-version`` because this is when it
+is known that the package successfully installed and configured.
+
+Note that the Operating System is not guaranteed to act on these
+files.  When, and whether, a reboot occurs is dependent upon the
+installation and configuration of a package which provides a reboot
+feature.  The same is true of user notifications involving reboot.
+
+

Bug#919824: [Pkg-opencl-devel] Bug#919824: clblas: under pocl-opencl-icd, aborts with !"PIC Level"

[Andreas Beckmann]

On 2019-01-20 00:16, Rebecca N. Palmer wrote:
> Source: pocl,clblas

Which version?
Which architecture?

If you suspect caching to be a problem, try something like this:

export POCL_CACHE_DIR=$(mktemp -d -p $(pwd))


Andreas

Bug#919824: clblas: under pocl-opencl-icd, aborts with !"PIC Level"

[Rebecca N. Palmer]

Source: pocl,clblas
(Probably really only one of them, but I don't know which.)

When using pocl-opencl-icd, clblas sometimes exits with

module flag identifiers must be unique (or of 'require' type)
!"PIC Level"
LLVM ERROR: Broken module found, compilation aborted!

The test suites of both libgpuarray and arrayfire seem to reliably 
trigger this, but exactly which test hits it seems to vary from run to 
run, suggesting that randomness and/or caching are involved.


Neither upstream's bug tracker lists this; I have not checked whether it 
exists upstream.


arrayfire run 1:
$ cmake ../arrayfire-3.3.2+dfsg1/test
$ make
$ CTEST_OUTPUT_ON_FAILURE=1 ctest --force-new-ctest-process -R "opencl" 
-E "large|dense"

[...]
  Start  10: Test_blas_opencl
10/96 Test  #10: Test_blas_opencl ***Failed8.30 sec
Running main() from /usr/src/gtest/src/gtest_main.cc
[==] Running 48 tests from 4 test cases.
[--] Global test environment set-up.
[--] 12 tests from MatrixMultiply/0, where TypeParam = float
[ RUN  ] MatrixMultiply/0.Square
[   OK ] MatrixMultiply/0.Square (1325 ms)
[ RUN  ] MatrixMultiply/0.NonSquare
[   OK ] MatrixMultiply/0.NonSquare (1153 ms)
[ RUN  ] MatrixMultiply/0.SquareVector
[   OK ] MatrixMultiply/0.SquareVector (380 ms)
[ RUN  ] MatrixMultiply/0.RectangleVector
[   OK ] MatrixMultiply/0.RectangleVector (1873 ms)
[ RUN  ] MatrixMultiply/0.Square_CPP
[   OK ] MatrixMultiply/0.Square_CPP (0 ms)
[ RUN  ] MatrixMultiply/0.NonSquare_CPP
[   OK ] MatrixMultiply/0.NonSquare_CPP (0 ms)
[ RUN  ] MatrixMultiply/0.SquareVector_CPP
[   OK ] MatrixMultiply/0.SquareVector_CPP (1 ms)
[ RUN  ] MatrixMultiply/0.RectangleVector_CPP
[   OK ] MatrixMultiply/0.RectangleVector_CPP (0 ms)
[ RUN  ] MatrixMultiply/0.MultiGPUSquare_CPP
[   OK ] MatrixMultiply/0.MultiGPUSquare_CPP (1 ms)
[ RUN  ] MatrixMultiply/0.MultiGPUNonSquare_CPP
[   OK ] MatrixMultiply/0.MultiGPUNonSquare_CPP (0 ms)
[ RUN  ] MatrixMultiply/0.MultiGPUSquareVector_CPP
[   OK ] MatrixMultiply/0.MultiGPUSquareVector_CPP (1 ms)
[ RUN  ] MatrixMultiply/0.MultiGPURectangleVector_CPP
[   OK ] MatrixMultiply/0.MultiGPURectangleVector_CPP (0 ms)
[--] 12 tests from MatrixMultiply/0 (4735 ms total)

[--] 12 tests from MatrixMultiply/1, where TypeParam = af::af_cfloat
[ RUN  ] MatrixMultiply/1.Square
[   OK ] MatrixMultiply/1.Square (1625 ms)
[ RUN  ] MatrixMultiply/1.NonSquare
[   OK ] MatrixMultiply/1.NonSquare (1386 ms)
[ RUN  ] MatrixMultiply/1.SquareVector
3 warnings generated.
[   OK ] MatrixMultiply/1.SquareVector (477 ms)
[ RUN  ] MatrixMultiply/1.RectangleVector
module flag identifiers must be unique (or of 'require' type)
!"PIC Level"
LLVM ERROR: Broken module found, compilation aborted!

arrayfire run 2:
$ CTEST_OUTPUT_ON_FAILURE=1 ctest --force-new-ctest-process -R "opencl" 
-E "large|dense"

[...]
10/96 Test  #10: Test_blas_opencl ***Failed0.75 sec
Running main() from /usr/src/gtest/src/gtest_main.cc
[==] Running 48 tests from 4 test cases.
[--] Global test environment set-up.
[--] 12 tests from MatrixMultiply/0, where TypeParam = float
[ RUN  ] MatrixMultiply/0.Square
[   OK ] MatrixMultiply/0.Square (439 ms)
[ RUN  ] MatrixMultiply/0.NonSquare
[   OK ] MatrixMultiply/0.NonSquare (224 ms)
[ RUN  ] MatrixMultiply/0.SquareVector
module flag identifiers must be unique (or of 'require' type)
!"PIC Level"
LLVM ERROR: Broken module found, compilation aborted!

libgpuarray (0.7.6) run 1:
$ DEVICE=opencl0:0 python3 -m nose -v pygpu
*** Testing for pthread-Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
mpi4py found: False
pygpu.test ... ..module flag identifiers must be unique (or of 
'require' type)

!"PIC Level"
LLVM ERROR: Broken module found, compilation aborted!

libgpuarray (0.7.6) run 2:
$ DEVICE=opencl0:0 python3 -m nose -v pygpu
*** Testing for pthread-Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
mpi4py found: False
pygpu.test ... ...module flag identifiers 
must be unique (or of 'require' type)

!"PIC Level"
LLVM ERROR: Broken module found, compilation aborted!

Bug#919765: dolphin not starting

[Ariel Molinuevo]

I just wanted to say that with the following updates

baloo-kf5:amd64 5.51.0-1
default-mysql-client-core:amd64 1.0.4
default-mysql-server-core:amd64 1.0.4
kio:amd64 5.51.0-1
kpackagetool5:amd64 5.51.0-1
kwayland-data:amd64 4:5.51.0-1
libkf5archive5:amd64 5.51.0-1
libkf5attica5:amd64 5.51.0-1
libkf5auth-data:amd64 5.51.0-1
libkf5auth5:amd64 5.51.0-1
libkf5baloo5:amd64 5.51.0-1
libkf5bookmarks-data:amd64 5.51.0-1
libkf5bookmarks5:amd64 5.51.0-1
libkf5calendarevents5:amd64 5.51.0-2
libkf5codecs-data:amd64 5.51.0-1
libkf5codecs5:amd64 5.51.0-1
libkf5completion-data:amd64 5.51.0-1
libkf5completion5:amd64 5.51.0-1
libkf5config-data:amd64 5.51.0-1
libkf5configcore5:amd64 5.51.0-1
libkf5configgui5:amd64 5.51.0-1
libkf5configwidgets-data:amd64 5.51.0-1
libkf5configwidgets5:amd64 5.51.0-1
libkf5coreaddons-data:amd64 5.51.0-1
libkf5coreaddons5:amd64 5.51.0-1
libkf5crash5:amd64 5.51.0-1
libkf5dbusaddons-data:amd64 5.51.0-1
libkf5dbusaddons5:amd64 5.51.0-1
libkf5declarative-data:amd64 5.51.0-2
libkf5doctools5:amd64 5.51.0-1
libkf5filemetadata-data:amd64 5.51.0-1
libkf5filemetadata3:amd64 5.51.0-1
libkf5globalaccel-bin:amd64 5.51.0-1
libkf5globalaccel-data:amd64 5.51.0-1
libkf5globalaccel5:amd64 5.51.0-1
libkf5guiaddons5:amd64 5.51.0-1
libkf5i18n-data:amd64 5.51.0-1
libkf5i18n5:amd64 5.51.0-1
libkf5i18n5:amd64 5.51.0-1
libkf5iconthemes-data:amd64 5.51.0-1
libkf5iconthemes5:amd64 5.51.0-1
libkf5idletime5:amd64 5.51.0-1
libkf5itemviews-data:amd64 5.51.0-1
libkf5itemviews5:amd64 5.51.0-1
libkf5jobwidgets-data:amd64 5.51.0-1
libkf5jobwidgets5:amd64 5.51.0-1
libkf5js5:amd64 5.51.0-1
libkf5kiocore5:amd64 5.51.0-1
libkf5kiofilewidgets5:amd64 5.51.0-1
libkf5kiowidgets5:amd64 5.51.0-1
libkf5kirigami2-5:amd64 5.51.0-1
libkf5newstuffcore5:amd64 5.51.0-1
libkf5notifications-data:amd64 5.51.0-1
libkf5notifications5:amd64 5.51.0-1
libkf5package-data:amd64 5.51.0-1
libkf5package5:amd64 5.51.0-1
libkf5parts-data:amd64 5.51.0-1
libkf5parts5:amd64 5.51.0-1
libkf5quickaddons5:amd64 5.51.0-2
libkf5service-bin:amd64 5.51.0-1
libkf5service-data:amd64 5.51.0-1
libkf5service5:amd64 5.51.0-1
libkf5solid5:amd64 5.51.0-3
libkf5solid5-data:amd64 5.51.0-3
libkf5sonnet5-data:amd64 5.51.0-1
libkf5sonnetcore5:amd64 5.51.0-1+b1
libkf5sonnetui5:amd64 5.51.0-1+b1
libkf5syntaxhighlighting-data:amd64 5.51.0-1
libkf5syntaxhighlighting5:amd64 5.51.0-1
libkf5textwidgets-data:amd64 5.51.0-1
libkf5textwidgets5:amd64 5.51.0-1
libkf5threadweaver5:amd64 5.51.0-1
libkf5wallet-bin:amd64 5.51.0-1
libkf5wallet-data:amd64 5.51.0-1
libkf5wallet5:amd64 5.51.0-1
libkf5waylandclient5:amd64 4:5.51.0-1
libkf5waylandserver5:amd64 4:5.51.0-1
libkf5widgetsaddons-data:amd64 5.51.0-1
libkf5widgetsaddons5:amd64 5.51.0-1
libkf5windowsystem-data:amd64 5.51.0-1
libkf5windowsystem5:amd64 5.51.0-1
libkf5xmlgui-data:amd64 5.51.0-1
libkf5xmlgui5:amd64 5.51.0-1+b1
libkwalletbackend5-5:amd64 5.51.0-1

now it's everything working fine.

Regards.

Ariel

Bug#900918: debian-installer: Please make the generated images reproducible

[Cyril Brulebois]

Control: tag -1 pending

Cyril Brulebois  (2019-01-19):
> The mini.iso has apparently other changes… I'm attaching the diffoscope
> output. Could this be because of missing tweaks to the xorriso calls in
> build/config/x86.cfg? (In which case build/config/arm.cfg might need an
> update as well.) Checking all MINIISO occurrences might also make sense
> I suppose?

FWIW, dropping all fontconfig-related bits (see attached patch) makes it
possible to confirm only mini.iso (regular and gtk ones) are showing
differences now:

installer-amd64/20190119/images/MD5SUMS
installer-amd64/20190119/images/netboot/gtk/mini.iso
installer-amd64/20190119/images/netboot/mini.iso
installer-amd64/20190119/images/SHA256SUMS


I had purged the pigz package during my experiments, just to be sure it
wouldn't interfere:

build/Makefile:gzip = $(shell which pigz >/dev/null 2>&1 && echo "pigz -n 
-T" || echo "gzip -n")

(Including lintian runtime, using pigz on a 8-way machine cuts real time
from 8m8s to 4m23s.)

Checking what happens, and forgetting about the aforementioned mini.iso
images temporarily, it seems successive builds with pigz lead to the
same results. But those aren't the same as the results generated with
gzip. I don't suppose this is going to be a particularly huge problem
though?


Anyway, summarizing: likely more work to be done on the xorriso front,
(on the debian-installer side) for the mini.iso images produced for
netbooting; and fontconfig needs to get fixed in some way at some point
(but I know it's been a long run as well…); but all the rest looks good.

Pushing once I have updated the changelog; marking as pending, thanks!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
From b1de326f8e97105e97beaf8b14c4af88894a62f0 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Sat, 19 Jan 2019 22:09:23 +
Subject: [PATCH] Remove unreproducible bits due to fontconfig.

---
 build/Makefile | 5 +
 1 file changed, 5 insertions(+)

diff --git a/build/Makefile b/build/Makefile
index 22abaac1d..2e6a0c76c 100644
--- a/build/Makefile
+++ b/build/Makefile
@@ -634,6 +634,11 @@ endif
 		fc-cache -s -y "$(TREE)"; \
 	fi
 
+	# Clean everything to check reproducibility:
+	@echo "HACK ALERT: fontconfig clean-up"
+	rm -v -rf "$(TREE)/var/cache/fontconfig"
+	find "$(TREE)" -name .uuid -print -delete
+
 	# Remove some unnecessary dpkg files.
 	set -e; \
 	for file in `find $(TREE)/var/lib/dpkg/info -name '*.md5sums' -o \
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#918366: FTBFS for armhf on arm64, fails some tests

[Yavor Doganov]

On Mon, 07 Jan 2019 21:10:31 +0200,
Steve McIntyre wrote:
> base/NSInvocation/general.m:
> Failed test: general.m:208 ... Can send/return NSRect

I tried to reproduce this on gcc117 (an AMD Opteron 1100 machine from
the GCC Compile Farm, which should be able to run 32-bit executables
according to one of your previous messages on the subject) with a
manually built cross-toolchain (pristine upstream binutils/2.31,
gcc/8.2.0, glibc/2.28 and libffi/3.2.1) but unfortunately the test
passes.

Am I missing something?  Or doing something wrong?

yavor@gcc117:~$ dpkg --print-architecture
arm64
yavor@gcc117:~$ dpkg --print-foreign-architectures
yavor@gcc117:~$ cat /etc/debian_version 
9.5
yavor@gcc117:~$ uname -a
Linux gcc117 4.9.0-5-arm64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) aarch64 
GNU/Linux
yavor@gcc117:~$ lscpu
Architecture:  aarch64
Byte Order:Little Endian
CPU(s):8
On-line CPU(s) list:   0-7
Thread(s) per core:1
Core(s) per socket:2
Socket(s): 4
Model: 2
BogoMIPS:  500.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32
yavor@gcc117:~$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/yavor/libexec/gcc/arm-linux-gnueabihf/8.2.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../configure --prefix=/home/yavor --disable-nls 
--disable-multilib --enable-languages=c,c++,objc --target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.2.0 (GCC)
yavor@gcc117:~$ ~/arm-linux-gnueabihf/lib/libc.so.6
GNU C Library (GNU libc) stable release version 2.28.
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 8.2.0.
libc ABIs: UNIQUE ABSOLUTE
For bug reporting instructions, please see:
.
yavor@gcc117:~$ file ~/arm-linux-gnueabihf/lib/libc-2.28.so 
/home/yavor/arm-linux-gnueabihf/lib/libc-2.28.so: ELF 32-bit LSB shared object, 
ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter 
/home/yavor/arm-linux-gnueabihf/lib/ld-linux.so.3, for GNU/Linux 3.2.0, not 
stripped

yavor@gcc117:~/src/gnustep-base-1.26.0$ file 
Source/obj/libgnustep-base.so.1.26.0 
Source/obj/libgnustep-base.so.1.26.0: ELF 32-bit LSB shared object, ARM, EABI5 
version 1 (SYSV), dynamically linked, not stripped
yavor@gcc117:~/src/gnustep-base-1.26.0$ grep NSRect Tests/tests.log
Passed test: general.m:208 ... Can send/return NSRect

I have no other idea except to retry the test with all Debian patches
to the toolchain packages applied.  If I'm still unable to reproduce,
I'd need some aid from people who have access to a machine that
exhibits the problem.

As a last resort we can disable the test, like Ubuntu.  I really don't
like this approach as it's just sweeping the problem under the rug.
There's a bug somewhere which ideally should be hunted down and fixed.

Bug#904657: voltron: fails to install with Python 3.7 (was: Re: update)

[Andreas Beckmann]

On 2019-01-19 21:55, Kienan Stewart wrote:
> I tested a proposed patch from the upstream github repository which allows 
> the package to build and run : https://github.com/snare/voltron/pull/243
> 
> I'm not sure if there are other side-effects to the patch, since the async 
> (now asynchronous) variable is not directly used but could be referred to 
> elsewhere.

voltron has no rdepends in the archive. So if that was the only "async"
in the package, this patch should be fine.


Andreas

PS: please try to use an informative subject, e.g. retain bug number and
bug title. Your subject and body did not provide any useful context for
a high volume bug reporter like me.  Even the content in my SPAM folder
usually has better subjects :-)

OTOH, if I had seen from the subject that this was one of these boring
python3.7 async bugs, I would not have looked in detail and replied at
all :-)

Bug#917161: pulseaudio: Pulseaudio takes longer to start than default systemd timeout (again)

[Mr riaas mokiem]

 
Thanks for letting me know. I just checked and I do have 240-4 installed now 
for udev (and libudev1). So i timed a restart of pulseaudio through systemd 
again and this is the result:
$ time systemctl --user restart pulseaudio.service real    0m1.660s
user    0m0.003s
sys 0m0.000s

So it seems like it's no longer timing out (again). When I reported this, I had 
version 240-1 installed for udev. If you think that this confirms that this 
problem was caused by udev, I guess this can be closed. I'll remove my manual 
timeout again and let you know if it happens again. Thanks for your help again.
On Friday, January 18, 2019, 7:10:21 PM GMT+1, Felipe Sateler 
 wrote:  
 
 

On Sun, Dec 23, 2018 at 10:48 AM Riaas Mokiem  wrote:

Package: pulseaudio
Version: 12.2-2
Severity: important

Dear Maintainer,

the problem previously reported in #910512 has appeared again. That bug went 
away by itself 
after a later system update. Now the problem has occurred again, again after a 
system update.
However, during this system update pulseaudio itself was not updated so the 
problem seems to
be related to how pulseaudio interacts with the system. The most noteworthy 
part of the 
update was the linux kernel upgrade from 4.18 to 4.19 and systemd from 239-15 
to 240-1. 


Have you tried again with udev 240-4? This could be caused by a bug solved in 
udev 240-4. -- 

Saludos,
Felipe Sateler  

Bug#919806: sbcl: FTBFS randomly (failing tests)

[Santiago Vila]

retitle 919806 sbcl: FTBFS randomly (failing tests)
severity 919806 important
thanks

The build does not always fail.

Thanks.

Bug#914466: RM: icu4j-49 -- ROM; Obsolete, no longer used

[Emmanuel Bourg]

Control: tags -1 - moreinfo

Le 27/11/2018 à 08:20, Scott Kitterman a écrit :

> Checking reverse dependencies...
> # Broken Build-Depends:
> lucene4.10: libicu4j-49-java

Good catch, thank you. It's now removed in lucene4.10/4.10.4+dfsg-4

Bug#916977: snoopy w/ ld preload enabled breaks "apt upgrade" jessie-to-buster

[Marcos Fouces]

Hello,

I use testing and updated hundreds of package without any trouble.

Please, could you give an example of a package that fails to upgrade?

Greetings,

Marcos.

On 11/1/19 18:52, Adrian Bunk wrote:
> On Thu, Dec 20, 2018 at 05:26:25PM -0500, deb...@mailinator.com wrote:
>> Package: snoopy
>> Version: 2.4.6-4
>> Severity: critical
>> Justification: breaks unrelated software
>>
>> Dear Maintainer,
>>
>> With snoopy installed and enabled on jessie, apt upgrade to buster will 
>> break the upgrade process, as the snoopy library goes missing while the ld 
>> preload setting persists.  This causes every command invocation to trigger 
>> an error message concerning the missing library.  
>> ...
> Hw did you upgrade from jessie to buster?
>
> Skipping a release when upgrading is not supported,
> only jessie -> stretch -> buster is supported.
>
> cu
> Adrian
>

Bug#919737: underscore: FTBFS (ERROR: `underscore.min.map` is not a supported option)

[Santiago Vila]

tags 919737 - unreproducible moreinfo
thanks

Based on the last message by Jonas, I'm removing those tags
which do not apply here.

Thanks.

Bug#919795: thunderbird: cannot save changes to addressbook

[Matija Nalis]

Few more data points (3rd being most important):

1) while I can't edit or create new contacts under "Personal Address Book", I:
  - can create new list - via "New List" button
  - can add/remove members on existing list by right clicking on the list, 
selecting "Edit List"
  - but can't add  member on existing list by right clicking on the list, and 
selecting "New contact"
(as that bring the same form as original "New Contact" button)

2) I've managed to find somewhat similar simptoms ("OK" buttons does
   not do anything, contact screen does not go away, and contact does not get
   added). But it's ten years old, on Windows XP, and shows additional error 
   messages so does not look too related unfortunately. Still, here it is:
   https://bugzilla.mozilla.org/show_bug.cgi?id=473966

3) Driven by desparation, I've used debootstrap to create chrooted
   minbase Stretch chroot, installed thunderbird inside it (via
   "chroot stretch_root apt-get install --no-install-recommends thunderbird")
   copied /etc/hosts, /etc/machine-id to it, done "adduser mnalis"
   and used "mount --bind" to include directories
   /home/mnalis /tmp /proc /dev /dev/pts /sys /run/shm inside chroot.

   Then I've run thunderbird in chrooted Stretch, and it worked 
   without problem (using same /home/mnalis/.thunderbird that
   original onn-chrooted Stretch system has problems with).
   But debootstrap installed thunderbird 1:60.2.1-2~deb9u1.
   
   After exiting chroot and starting regular thunderbird (with same
   profile in homedir), it again doesn't work. 

   Then in chroot I upgraded just thunderbird from Default Stretch
   main repo 1:60.2.1-2~deb9u1 to Security version 1:60.4.0-1~deb9u1
   and it stopped working in chroot too.
   Downgrading to 1:60.2.1-2~deb9u1 fixes addressbook again.
  
   So it seems that it is regression in the Stretch security upgrade
   from 1:60.2.1-2~deb9u1 to 1:60.4.0-1~deb9u1 that breaks
   addressbook functionality. 


-- 
Opinions above are GNU-copylefted.

Bug#919823: harp: FTBFS in sid (ERROR: CODA library and/or header file not found)

[Santiago Vila]

Package: src:harp
Version: 1.5+data-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
dh build-arch  --with python3
   dh_update_autotools_config -a
   dh_autoreconf -a
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' 
-o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec 
md5sum {} + -o -type l -printf "symlink  %p
" > debian/autoreconf.before
grep -q ^XDT_ configure.ac
autoreconf -f -i
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'

[... snipped ...]

checking for floor... yes
checking for pread... yes
checking for stat... yes
checking for memmove... yes
checking for bcopy... yes
checking for strerror... yes
checking for strdup... yes
checking for strcasecmp... yes
checking for strncasecmp... yes
checking for vsnprintf... yes
checking build IDL interface... no
checking build MATLAB interface... no
checking use HDF4... yes
checking for compress in -lz... yes
checking for jpeg_start_compress in -ljpeg... yes
checking for SZ_encoder_enabled in -lsz... yes
checking hdf.h usability... yes
checking hdf.h presence... yes
checking for hdf.h... yes
checking netcdf.h usability... yes
checking netcdf.h presence... yes
checking for netcdf.h... yes
checking mfhdf.h usability... yes
checking mfhdf.h presence... yes
checking for mfhdf.h... yes
checking for Hopen in -ldfalt... yes
checking for SDstart in -lmfhdfalt... yes
checking for HDF4 installation... yes
checking coda.h usability... yes
checking coda.h presence... yes
checking for coda.h... yes
checking for coda_init in -lcoda... no
checking for CODA installation... no
configure: error: 


ERROR: CODA library and/or header file not found.
Try setting the CODA_LIB and CODA_INCLUDE environment variables to the
location of your CODA library and include file.


make[1]: *** [debian/rules:19: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/<>/harp-1.5+data'
make: *** [debian/rules:7: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here with plain "dpkg-buildpackage":

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

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#900918: debian-installer: Please make the generated images reproducible

[Cyril Brulebois]

Cyril Brulebois  (2019-01-19):
> Back to d-i results: I'm seeing small differences in the generated
> -images tarball, that I'll try to investigate. I'll probably push the
> series anyway, as these patches are helping anyway. :)

Here are the differences I'm seeing by building multiple times in the
same sid devel chroot:

installer-amd64/20190119/images/cdrom/gtk/initrd.gz
installer-amd64/20190119/images/hd-media/boot.img.gz
installer-amd64/20190119/images/hd-media/gtk/initrd.gz
installer-amd64/20190119/images/MD5SUMS
installer-amd64/20190119/images/netboot/gtk/debian-installer/amd64/initrd.gz
installer-amd64/20190119/images/netboot/gtk/mini.iso
installer-amd64/20190119/images/netboot/gtk/netboot.tar.gz
installer-amd64/20190119/images/netboot/mini.iso
installer-amd64/20190119/images/SHA256SUMS

*SUMS are no-brainers due to changes in other files.

All gtk files have fontconfig-related cache/uuid changes…

Excluding those, remaining files are:

installer-amd64/20190119/images/hd-media/boot.img.gz
installer-amd64/20190119/images/netboot/mini.iso

The boot.img includes two initrds: initrd.gz and initrdg.gz; the latter
is the one with graphical support, which explains why it's also hit by
the fontconfig cache/uuid problem.

The mini.iso has apparently other changes… I'm attaching the diffoscope
output. Could this be because of missing tweaks to the xorriso calls in
build/config/x86.cfg? (In which case build/config/arm.cfg might need an
update as well.) Checking all MINIISO occurrences might also make sense
I suppose?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
--- d-i-8/extract/installer-amd64/20190119/images/netboot/mini.iso
+++ d-i-9/extract/installer-amd64/20190119/images/netboot/mini.iso
│┄ Format-specific differences are supported for this file format but none were detected (DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 240, 5376 sectors; partition 3 : ID=0x1, start-CHS (0x28,0,1), end-CHS (0x2d,63,32), startsector 81920, 12288 sectors)
@@ -21,25 +21,25 @@
 0140: 04b3 07cd 103c 0a75 f1cd 18f4 ebfd   .<.u
 0150:          
 0160:          
 0170:          
 0180:          
 0190:          
 01a0:          
-01b0: f015    bd2c ea2e  8000  .,..
+01b0: f015    f3a8 811b  8000  
 01c0: 0100 003f 2027   0040 0100 00fe  ...? '.@
 01d0:  effe  f000  0015    
 01e0: 0128 013f 202d 0040 0100 0030    .(.? -.@...0
 01f0:        55aa  ..U.
 0200: 4546 4920 5041 5254  0100 5c00   EFI PART\...
-0210: 6d39 8060   0100     m9.`
+0210: eaae c021   0100     ...!
 0220: ff3f 0100   2200     .?.."...
-0230: de3f 0100   e54d 5a45 8789 8e48  .?...MZE...H
-0240: 94f8 d8a5 4fef 9546 0200     O..F
-0250: 8000  8000  2e4a 6260    .Jb`
+0230: de3f 0100   c3d2 f8ef b4ab 7940  .?y@
+0240: bcb6 4ce6 6ef7 1afc 0200     ..L.n...
+0250: 8000  8000  a705 e2f2    
 0260:          
 0270:          
 0280:          
 0290:          
 02a0:          
 02b0:          
 02c0:          
@@ -59,23 +59,23 @@
 03a0:          
 03b0:          
 03c0:          
 03d0:          
 03e0:          
 03f0:          
 0400: a2a0 d0eb e5b9 3344 87c0 68b6 b726 99c7  ..3D..h..&..
-0410: 39a0 b199 1b8e 6243 b6c7 10a4 2fa5 da3f  9.bC/..?
+0410: 169b 0fd6 bf07 7441 9901 f113 33d4 9991  ..tA3...
 0420:     473f 0100    .

Bug#919737: underscore: FTBFS (ERROR: `underscore.min.map` is not a supported option)

[Kienan Stewart]

user debian-rele...@lists.debian.org
usertag 919737 + bsp-2019-01-ca-montreal
tags 919737 + unreproducible moreinfo
thank you

Hi,

I tried building this package (underscore-1.8.3~dfsg) in a clean buster chroot 
(with sbuild) and a clean unstable chroot (also with sbuild), and it worked in 
both cases.

Thanks,
Kienan


signature.asc
Description: PGP signature

Bug#901982: diffoscope: crash comparing ext4 filesystems: AttributeError: 'FsImageContainer' object has no attribute 'g'

[Cyril Brulebois]

Hi,

Paul Wise  (2018-06-21):
> $ diffoscope foo.ext4.initial foo.ext4.mount
> Traceback (most recent call 
> last):#|
>   100% ETA:  0:00:00 
>   File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 460, in main
> sys.exit(run_diffoscope(parsed_args))
>   File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 432, in 
> run_diffoscope
> difference = compare_root_paths(path1, path2)
>   File 
> "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", 
> line 68, in compare_root_paths
> difference = compare_files(file1, file2)
>   File 
> "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", 
> line 118, in compare_files
> return file1.compare(file2, source)
>   File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
> line 366, in compare
> difference = self._compare_using_details(other, source)
>   File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
> line 321, in _compare_using_details
> other.as_container, no_recurse=no_recurse))
>   File 
> "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
> line 131, in comparisons
> my_members = OrderedDict(self.get_adjusted_members_sizes())
>   File 
> "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
> line 127, in get_adjusted_members_sizes
> size = path_apparent_size(member.path)
>   File 
> "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/archive.py", 
> line 99, in path
> self._name, self._temp_dir.name)
>   File "/usr/lib/python3/dist-packages/diffoscope/comparators/fsimage.py", 
> line 74, in extract
> self.g.tar_out('/', dest_path)
> AttributeError: 'FsImageContainer' object has no attribute 'g'

FWIW I'm also seeing this in unstable when trying to compare two
boot.img.gz files produced as part of a debian-installer builder:

(sid-amd64-devel)kibi@wodi:~/debian-installer$ diffoscope 
d-i-[89]/extract/installer-amd64/20190119/images/hd-media/boot.img.gz
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 504, in 
main
sys.exit(run_diffoscope(parsed_args))
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 476, in 
run_diffoscope
difference = compare_root_paths(path1, path2)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
68, in compare_root_paths
difference = compare_files(file1, file2)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
118, in compare_files
return file1.compare(file2, source)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 
370, in compare
difference = self._compare_using_details(other, source)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 
325, in _compare_using_details
other.as_container, no_recurse=no_recurse))
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
line 179, in compare_pair
file1, file2, source=None, diff_content_only=no_recurse)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
118, in compare_files
return file1.compare(file2, source)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 
370, in compare
difference = self._compare_using_details(other, source)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 
325, in _compare_using_details
other.as_container, no_recurse=no_recurse))
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
line 131, in comparisons
my_members = OrderedDict(self.get_adjusted_members_sizes())
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
line 127, in get_adjusted_members_sizes
size = path_apparent_size(member.path)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/archive.py", line 
99, in path
self._name, self._temp_dir.name)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/fsimage.py", 
line 74, in extract
self.g.tar_out('/', dest_path)
AttributeError: 'FsImageContainer' object has no attribute 'g'

This is with diffoscope 108.


Interestingly, my host using stretch-backports's version (108~bpo9+1)

Bug#912087: reassign to systemd #912087 | openssh-server: Slow startup after the upgrade to 7.9p1

[Andy Simpkins]

Follow up report:

Bare metal install onto an APM Mustang board (see debian arm64 buildds)
of debian-buster-DI-alpha4-arm64-DVD-1.iso  [1]

sshd takes > 7 min to start [2]


This is clearly going to be a problem for Buster as things stand...

/Andy



[1] DI alpha4 uses kernel 4.18.20-2 (2018-11-23)
I am not updating the current Buster kernel (4.19.0-1-arm64) because
I am seeing a problem with it causing mustangs to panic during init
(this is the next bug I will report)

[2] root@sally:~# systemctl status ssh
ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor
   preset: enab
   Active: activating (start-pre) since Sat 2019-01-19 21:23:39 GMT;
   2min 16s ag
 Docs: man:sshd(8)
   man:sshd_config(5)
   Cntrl PID: 459 (sshd)
   Tasks: 1 (limit: 4915)
  Memory: 2.8M
  CGroup: /system.slice/ssh.service
  ��└��─459 /usr/sbin/sshd -t


   syslog extract:
 Jan 19 21:30:49 sally systemd[1]: Starting OpenBSD Secure Shell
 server...

 Jan 19 21:31:01 sally CRON[516]: (root) CMD (   test -x
 /etc/cron.daily/popularity-contest && /etc/cron.daily/popularity-
 contest --crond)

 Jan 19 21:31:58 sally kernel: [  442.940274] random: crng init done

 Jan 19 21:31:58 sally kernel: [  442.940280] random: 7 urandom
 warning(s) missed due to ratelimiting

 Jan 19 21:31:58 sally systemd[1]: Started OpenBSD Secure Shell
 server.









On Wed, 2 Jan 2019 14:45:18 +0100 Olaf van der Spek
 wrote:
> Op do 29 nov. 2018 om 14:58 schreef Olaf van der Spek :
> >
> > Op do 29 nov. 2018 om 14:54 schreef Sebastian Andrzej Siewior
> > :
> > >
> > > On 2018-11-28 13:43:07 [+0100], Olaf van der Spek wrote:
> > > > > > They might just as well install haveged or configure virtio-rng in 
> > > > > > such
> > > > > > a case.
> > > > >
> > > > > Right. Do you think, that it would necessary to add something to the
> > > > > release notes?
> > > >
> > > > I do. ;)
> > > > What's the workaround for VMware?
> > > >
> > > > Does it just take longer to start or do some services not start at all?
> > >
> > > It will take longer to start, it will start. Let me pass that workaround
> >
> > Are you sure?
> > I've had php-fpm not start due to this, I think:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906686
> 
> Today on a Digital Ocean VM:
> Jan  2 13:22:29 www systemd[1]: php7.3-fpm.service: Start operation
> timed out. Terminating.
> Jan  2 13:22:29 www systemd[1]: ssh.service: Start-pre operation timed
> out. Terminating.
> Jan  2 13:22:29 www systemd[1]: nginx.service: Start-pre operation
> timed out. Terminating.
> Jan  2 13:22:29 www systemd[1]: php7.3-fpm.service: Main process
> exited, code=killed, status=15/TERM
> Jan  2 13:22:29 www systemd[1]: php7.3-fpm.service: Failed with result
> 'timeout'.
> Jan  2 13:22:29 www systemd[1]: Failed to start The PHP 7.3 FastCGI
> Process Manager.
> Jan  2 13:22:29 www systemd[1]: nginx.service: Control process exited,
> code=killed, status=15/TERM
> Jan  2 13:22:29 www systemd[1]: nginx.service: Failed with result 'timeout'.
> Jan  2 13:22:29 www systemd[1]: Failed to start A high performance web
> server and a reverse proxy server.
> Jan  2 13:22:29 www systemd[1]: ssh.service: Control process exited,
> code=killed, status=15/TERM
> Jan  2 13:22:29 www systemd[1]: ssh.service: Failed with result 'timeout'.
> Jan  2 13:22:29 www systemd[1]: Failed to start OpenBSD Secure Shell server.
> Jan  2 13:22:29 www systemd[1]: Reached target Multi-User System.
> Jan  2 13:22:29 www systemd[1]: Starting Execute cloud user/final scripts...
> Jan  2 13:22:29 www systemd[1]: Reached target Graphical Interface.
> Jan  2 13:22:29 www systemd[1]: Starting Update UTMP about System
> Runlevel Changes...
> Jan  2 13:22:29 www kernel: [   97.513700] urandom_read: 3 callbacks 
> suppressed
> Jan  2 13:22:29 www kernel: [   97.513702] random: cloud-init:
> uninitialized urandom read (24 bytes read)
> Jan  2 13:22:29 www systemd[1]: systemd-update-utmp-runlevel.service: 
> Succeeded.
> Jan  2 13:22:29 www systemd[1]: Started Update UTMP about System
> Runlevel Changes.
> Jan  2 13:22:29 www systemd[1]: ssh.service: Service RestartSec=100ms
> expired, scheduling restart.
> Jan  2 13:22:29 www systemd[1]: ssh.service: Scheduled restart job,
> restart counter is at 1.

Bug#917482: jhove: FTBFS in buster at least since 2018-12-07

[Abdelhakim Qbaich]

Control: tags -1 +patch

On Sat, 19 Jan 2019 16:51:02 -0500
Abdelhakim Qbaich  wrote:

> Hi,
> 
> I've attached a patch and made an upstream pull request.
> 
> On Thu, 27 Dec 2018 22:52:58 + Santiago Vila 
> wrote:
> > Package: src:jhove
> > Version: 1.20.1-4
> > Severity: serious
> > 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
> > mh_patchpoms -pjhove --debian-build --keep-pom-version
> > --maven-repo=/<>/debian/maven-repo dh_auto_build -i
> > /usr/lib/jvm/default-java/bin/java -noverify
> > -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar
> > -Dmaven.home=/usr/share/maven
> > -Dmaven.multiModuleProjectDirectory=/<>
> > -Dclassworlds.conf=/etc/maven/m2-debian.conf
> > -Dproperties.file.manual=/<>/debian/maven.properties
> > org.codehaus.plexus.classworlds.launcher.Launcher
> > -s/etc/maven/settings-debian.xml
> > -Ddebian.dir=/<>/debian
> > -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode
> > package -DskipTests -Dnotimestamp=true -Dlocale=en_US WARNING: An
> > illegal reflective access operation has occurred WARNING: Illegal
> > reflective access by
> > com.google.inject.internal.cglib.core.$ReflectUtils$1
> > (file:/usr/share/maven/lib/guice.jar) to method
> > java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> > WARNING: Please consider reporting this to the maintainers of
> > com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use
> > --illegal-access=warn to enable warnings of further illegal
> > reflective access operations WARNING: All illegal access operations
> > will be denied in a future release [INFO] Scanning for projects...
> > 
> > [... snipped ...]
> > 
> > [INFO] JHOVE - JSTOR/Harvard Object Validation Environment  SUCCESS
> > [  0.009 s] [INFO] JHOVE
> > Core . SUCCESS [  4.465 s]
> > [INFO] JHOVE Validation Modules ... FAILURE
> > [  2.348 s] [INFO] JHOVE
> > Applications . SKIPPED [INFO]
> > 
> > [INFO] BUILD FAILURE [INFO]
> > 
> > [INFO] Total time:  7.061 s [INFO] Finished at: 2018-12-25T23:16:10Z
> > [INFO]
> > 
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile
> > (default-compile) on project jhove-modules: Compilation failure:
> > Compilation failure:
> > [ERROR] 
> > /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/BroadcastExtChunk.java:[13,22]
> > package javax.xml.bind does not exist
> > [ERROR] 
> > /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[13,22]
> > package javax.xml.bind does not exist
> > [ERROR] 
> > /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/BroadcastExtChunk.java:[216,29]
> > cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> > [ERROR]   location: class
> > edu.harvard.hul.ois.jhove.module.wave.BroadcastExtChunk
> > [ERROR] 
> > /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/BroadcastExtChunk.java:[219,29]
> > cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> > [ERROR]   location: class
> > edu.harvard.hul.ois.jhove.module.wave.BroadcastExtChunk
> > [ERROR] 
> > /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[261,21]
> > cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> > [ERROR]   location: class
> > edu.harvard.hul.ois.jhove.module.wave.FormatChunk
> > [ERROR] 
> > /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[265,21]
> > cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> > [ERROR]   location: class
> > edu.harvard.hul.ois.jhove.module.wave.FormatChunk
> > [ERROR] 
> > /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[269,21]
> > cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> > [ERROR]   location: class
> > edu.harvard.hul.ois.jhove.module.wave.FormatChunk
> > [ERROR] 
> > /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[273,21]
> > cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> > [ERROR]   location: class
> > edu.harvard.hul.ois.jhove.module.wave.FormatChunk
> > [ERROR] 
> > /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[277,21]
> > cannot find symbol
> 

Bug#919822: gitlab: CVE-2019-6240: Arbitrary repo read in Gitlab project import

[Salvatore Bonaccorso]

Source: gitlab
Version: 11.5.6+dfsg-1
Severity: grave
Tags: security upstream fixed-upstream
Justification: user security hole

Hi,

The following vulnerability was published for gitlab, and fixed in
11.6.4, 11.5.7, and 11.4.14.

CVE-2019-6240[0]:
RESERVED

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-6240
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6240
[1] 
https://about.gitlab.com/2019/01/16/critical-security-release-gitlab-11-dot-6-dot-4-released/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#917482: jhove: FTBFS in buster at least since 2018-12-07

[Abdelhakim Qbaich]

Hi,

I've attached a patch and made an upstream pull request.

On Thu, 27 Dec 2018 22:52:58 + Santiago Vila 
wrote:
> Package: src:jhove
> Version: 1.20.1-4
> Severity: serious
> 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
>   mh_patchpoms -pjhove --debian-build --keep-pom-version
> --maven-repo=/<>/debian/maven-repo dh_auto_build -i
>   /usr/lib/jvm/default-java/bin/java -noverify
> -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar
> -Dmaven.home=/usr/share/maven
> -Dmaven.multiModuleProjectDirectory=/<>
> -Dclassworlds.conf=/etc/maven/m2-debian.conf
> -Dproperties.file.manual=/<>/debian/maven.properties
> org.codehaus.plexus.classworlds.launcher.Launcher
> -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian
> -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode
> package -DskipTests -Dnotimestamp=true -Dlocale=en_US WARNING: An
> illegal reflective access operation has occurred WARNING: Illegal
> reflective access by
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> (file:/usr/share/maven/lib/guice.jar) to method
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of
> com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use
> --illegal-access=warn to enable warnings of further illegal
> reflective access operations WARNING: All illegal access operations
> will be denied in a future release [INFO] Scanning for projects...
> 
> [... snipped ...]
> 
> [INFO] JHOVE - JSTOR/Harvard Object Validation Environment  SUCCESS
> [  0.009 s] [INFO] JHOVE
> Core . SUCCESS [  4.465 s]
> [INFO] JHOVE Validation Modules ... FAILURE
> [  2.348 s] [INFO] JHOVE
> Applications . SKIPPED [INFO]
> 
> [INFO] BUILD FAILURE [INFO]
> 
> [INFO] Total time:  7.061 s [INFO] Finished at: 2018-12-25T23:16:10Z
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile
> (default-compile) on project jhove-modules: Compilation failure:
> Compilation failure:
> [ERROR] 
> /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/BroadcastExtChunk.java:[13,22]
> package javax.xml.bind does not exist
> [ERROR] 
> /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[13,22]
> package javax.xml.bind does not exist
> [ERROR] 
> /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/BroadcastExtChunk.java:[216,29]
> cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> [ERROR]   location: class
> edu.harvard.hul.ois.jhove.module.wave.BroadcastExtChunk
> [ERROR] 
> /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/BroadcastExtChunk.java:[219,29]
> cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> [ERROR]   location: class
> edu.harvard.hul.ois.jhove.module.wave.BroadcastExtChunk
> [ERROR] 
> /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[261,21]
> cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> [ERROR]   location: class
> edu.harvard.hul.ois.jhove.module.wave.FormatChunk
> [ERROR] 
> /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[265,21]
> cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> [ERROR]   location: class
> edu.harvard.hul.ois.jhove.module.wave.FormatChunk
> [ERROR] 
> /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[269,21]
> cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> [ERROR]   location: class
> edu.harvard.hul.ois.jhove.module.wave.FormatChunk
> [ERROR] 
> /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[273,21]
> cannot find symbol [ERROR]   symbol:   variable DatatypeConverter
> [ERROR]   location: class
> edu.harvard.hul.ois.jhove.module.wave.FormatChunk
> [ERROR] 
> /<>/jhove-modules/src/main/java/edu/harvard/hul/ois/jhove/module/wave/FormatChunk.java:[277,21]
> cannot find symbol

-- 
Abdelhakim Qbaich


javax
Description: Binary data

Bug#795442: (no subject)

[Thorsten Glaser]

Hi Tiago,

>So, waiting from upstream answer.

thanks for looking into this… I talked to upstream about this a
while ago and it ended with that they don’t have much interest
in the /etc/papersize thing, which is pretty distro-specific,
but would merge a patch if someone would write it.

I looked into it a bit but it turns out that it would need
quite some amount of code (also, it’s probably easier to do
it with*out* using libpapersize). I have it somewhat on my
radar but definitely not a priority, so won’t be writing the
supporting code any time soon.

It *is* documented in the manpage though:

BUGS
 MuseScore does not honour /etc/papersize.

bye,
//mirabilos (hat: Debian maintainer of musescore)
-- 
This space for rent.

https://paypal.me/mirabilos to support my work.

Bug#915856: sphinx: Failed cross building with Build-Depends on python3-sphinx

[Dmitry Shachnev]

Hi Kaliko!

Sorry that it took so long for me to reply. I was putting most of my Sphinx
time into preparing the Sphinx 1.8 transition for sid.

On Fri, Dec 07, 2018 at 11:42:09AM +0100, kaliko wrote:
> here is a follow up of a discussion started on irc:debian-devel with
> mitya57.
>
> I'm trying to cross build an "Architecture: any" package [0]
> (commit:52326679) using the following:
>
> sudo pbuilder create --host-arch armhf
> sudo pbuilder build --host-arch armhf ncmpc_0.33-1.dsc
>
> building failed on:
>
> "builddeps:/build/ncmpc_0.33-1.dsc:armhf : Depends: python3-sphinx:armhf but
> it is not installable"

In other packages this is usually being fixed by splitting the documentation
into a separate package that is Architecture: all.

Then Sphinx is not needed when cross-building at all — there is no sense in
cross-building Architecture: all packages, you can just build them natively.

To skip installing Sphinx on cross builds, you need to:

1) Move python3-sphinx build-dependency to Build-Depends-Indep.

2) After doing that, you can no longer use dh --with sphinxdoc, as dh will
not find sphinxdoc.pm. So you will need something like this instead:

override_dh_installdocs-indep:
dh_installdocs -i -A AUTHORS
dh_sphinxdoc

3) Also maybe you will need to pass --binary-indep to pbuilder, as it does
not automatically add that option for cross builds.


This was a solution that does not need changing or using Sphinx at all.
Now let’s talk about Sphinx. There is bug #818115 which discusses how to
make it possible to install Sphinx in cross-build environments.

Last discussion on that bug was in 2016, so I checked whether some
things described there are still actual. Found this thing:

> So maybe we can say that architectures don't matter for sphinx by
> marking it Multi-Arch: foreign? Unfortunately, no. python-sphinx
> transitively depends on python-markupsafe (via python-jinja2) and thus
> exposes it. Since python-markupsafe is an architecture dependent Python
> extension, python-sphinx exposes the architecture. This is the gist of
> the multiarch interpreter problem.

I looked at markupsafe code, and found out that the architecture-specific
part of it is optional:

https://github.com/pallets/markupsafe/blob/master/src/markupsafe/__init__.py#L320

So even if it is installed for a wrong architecture, it would still be
importable.

Maybe this means that python3-sphinx can be marked Multi-Arch: foreign.

However, I am not sure this is a safe thing to do. One potential issue may be
that Sphinx autodoc extension [1] imports arbitrary Python code, and that
code may be a compiled (for the host architecture) extension that will fail to
import with the build architecture interpreter.

Also, I wonder if just making src:sphinx binary packages Multi-Arch: foreign
will be enough, or we should also mark all its dependencies Multi-Arch:
foreign too.

I am Cc’ing Helmut Grohne who filed #818115 and who is a cross-building
expert. Dear Helmut, can you give me your opinion on this? Is my analysis
correct?

[1]: https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#919821: New upstream version available

[Joshua Knutson]

Package: amsynth 
Version: 1.6.4-2
Severity: wishlist

Hello, there seems to be a new version (1.8.0) for this software at 
amsynth.github.io

Would it be possible to update the package?

Thanks

Bug#919820: mysql-connector-python: CVE-2019-2435

[Salvatore Bonaccorso]

Source: mysql-connector-python
Version: 8.0.11-1
Severity: grave
Tags: security upstream
Control: found -1 2.1.6-1

Hi,

The following vulnerability was published for mysql-connector-python.

CVE-2019-2435[0]:
| Vulnerability in the MySQL Connectors component of Oracle MySQL
| (subcomponent: Connector/Python). Supported versions that are affected
| are 8.0.13 and prior and 2.1.8 and prior. Easily exploitable
| vulnerability allows unauthenticated attacker with network access via
| TLS to compromise MySQL Connectors. Successful attacks require human
| interaction from a person other than the attacker. Successful attacks
| of this vulnerability can result in unauthorized creation, deletion or
| modification access to critical data or all MySQL Connectors
| accessible data as well as unauthorized access to critical data or
| complete access to all MySQL Connectors accessible data. CVSS 3.0 Base
| Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector:
| (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-2435
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2435
[1] 
http://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html#CVE-2019-2435

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#919529: CVE-2019-6256

[Salvatore Bonaccorso]

Hey!

On Thu, Jan 17, 2019 at 12:00:13AM +0100, Sebastian Ramacher wrote:
> Control: found -1 2016.11.28-1
> 
> On 2019-01-16 23:19:45, Moritz Muehlenhoff wrote:
> > Source: liblivemedia
> > Severity: grave
> > Tags: security
> > 
> > Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6256
> > 
> > Cheers,
> > Moritz
> 
> Not sure if I'm missing something, but the PoC does not seem to work on
> buster/sid. On stretch I get segfaults, but only if I abort the PoC. So 
> marking
> as found in stable and closing for sid.

Not having a poc triggering does not necessarly mean the issue needs
to be fixed. Do we know something on the actual fix? Skimming (but
only superficial) in the git repository I have not found something
obvious, but possible I only missed it.

Regards,
Salvatore

Bug#919819: RFS: knowthelist/2.3.1

[Mario Stephan]

Package: sponsorship-requests
Severity: normal

 Dear mentors,

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

* Package name: knowthelist
  Version : 2.3.1
  Upstream Author : Mario Stephan 
* URL : http://knowthelist.github.io/knowthelist
* License : LGPL v3
  Section : sound

 It builds those binary packages:

   knowthelist - awesome party music player

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


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


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


   dget -x 
https://mentors.debian.net/debian/pool/main/k/knowthelist/knowthelist_2.3.1.dsc


 More information about knowthelist can be obtained from 
https://www.example.com.


 Changes since the last upload:

 * Switched from localsrc to uridecodebin (gstreamer) in players
 * Optimized VUMeter draw algorithm
 * Added a custom dial to have a unique look of the EQ dials
 * Auto formatted code
 * Bugfix playlist drag/drop, improvements AutoDJ
 * Corrected summarised count of AutoDJ
 * AutoDJ: save settings before reload
 * Added DJ label on main panel to show the name of the current AutoDJ


 Regards,
  Mario Stephan

Bug#910627: xul-ext-nostalgy: Please update to upstream 0.2.36 to be compatible with TB 60+

[Louis-Philippe Véronneau]

Hello from the Montreal BSP!

I tested the latest release of the upstream version (0.2.36) and it
worked fine for me on the latest Thunderbird in testing.

I migrated the nostalgy VCS from the Alioth archive to Salsa and updated
it to the latest release: https://salsa.debian.org/webext-team/nostalgy

After testing it, everything seems to work for me. I asked
anar...@debian.org to upload it to the archive.

Cheers!

-- 
  ,''`.
 : :'  : Louis-Philippe Véronneau
 `. `'`  po...@debian.org / veronneau.org
   `-

On Tue, 09 Oct 2018 00:22:01 +0200 Daniel Reichelt
 wrote:
> Package: xul-ext-nostalgy
> Version: 0.2.34-1
> Severity: important
> 
> Hi,
> 
> please update to the latest version available at [1] so it can be used again
> with the version of Thunderbird (60+) shipped in Stretch.
> 
> Thanks!
> Daniel
> 
> [1] https://addons.thunderbird.net/en-US/thunderbird/addon/nostalgy/
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#887750: pam-python: diff for NMU version 1.0.6-1.1

[anarcat]

Dear maintainer,

I've prepared an NMU for pam-python (versioned as 1.0.6-1.1) and
uploaded it to DELAYED/0. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
diff -Nru pam-python-1.0.6/debian/changelog pam-python-1.0.6/debian/changelog
--- pam-python-1.0.6/debian/changelog	2016-08-27 07:37:03.0 -0400
+++ pam-python-1.0.6/debian/changelog	2019-01-19 15:14:26.0 -0500
@@ -1,3 +1,11 @@
+pam-python (1.0.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build with glibc 2.26, thanks to Adrian Bunk (Closes: #887750).
+  * Fix build with GCC 8
+
+ -- Antoine Beaupré   Sat, 19 Jan 2019 15:14:26 -0500
+
 pam-python (1.0.6-1) unstable; urgency=low
 
   * New upstream.
diff -Nru pam-python-1.0.6/debian/patches/fix-function-types.patch pam-python-1.0.6/debian/patches/fix-function-types.patch
--- pam-python-1.0.6/debian/patches/fix-function-types.patch	1969-12-31 19:00:00.0 -0500
+++ pam-python-1.0.6/debian/patches/fix-function-types.patch	2019-01-19 15:14:26.0 -0500
@@ -0,0 +1,96 @@
+From 12869142411f7a85d438971792cd75095f140f28 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Sat, 19 Jan 2019 16:00:52 -0500
+Subject: [PATCH] fix build with -Wcast-function-type -Werror on gcc8
+
+New versions of gcc8 will fail to build from source on Python
+declarations because of the hairy cast we're doing there, example:
+
+pam_python.c:1355:19: error: cast between incompatible function types from 'PyObject * (*)(PyObject *, PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *, struct _object *)'} to 'PyObject * (*)(PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *)'} [-Werror=cast-function-type]
+
+This fix comes form the upstream cpython implementation:
+
+https://github.com/python/cpython/commit/62be74290aca26d16f3f55ece7ff6dad14e60e8d#diff-c3cf251f16d5a03a9e7d4639f2d6f998
+---
+ src/pam_python.c | 30 +++---
+ 1 file changed, 15 insertions(+), 15 deletions(-)
+
+diff --git a/src/pam_python.c b/src/pam_python.c
+index e01ee68..654f0aa 100644
+--- a/src/pam_python.c
 b/src/pam_python.c
+@@ -317,7 +317,7 @@ static PyMethodDef SyslogFile_Methods[] =
+ {
+   {
+ "write",
+-(PyCFunction)SyslogFile_write,
++(PyCFunction)(void(*)(void))SyslogFile_write,
+ METH_VARARGS|METH_KEYWORDS,
+ 0
+   },
+@@ -1349,16 +1349,16 @@ static PyObject* PamEnv_values(
+ 
+ static PyMethodDef PamEnv_Methods[] =
+ {
+-  {"__contains__",  (PyCFunction)PamEnv_has_key,METH_VARARGS|METH_KEYWORDS, 0},
+-  {"__getitem__",   (PyCFunction)PamEnv_getitem,METH_VARARGS|METH_KEYWORDS, 0},
+-  {"get",	(PyCFunction)PamEnv_get,	METH_VARARGS|METH_KEYWORDS, 0},
+-  {"has_key",	(PyCFunction)PamEnv_has_key,METH_VARARGS|METH_KEYWORDS, 0},
+-  {"items",	(PyCFunction)PamEnv_items,	METH_VARARGS|METH_KEYWORDS, 0},
+-  {"iteritems",	(PyCFunction)PamEnv_iteritems,METH_VARARGS|METH_KEYWORDS, 0},
+-  {"iterkeys",	(PyCFunction)PamEnv_iterkeys,METH_VARARGS|METH_KEYWORDS, 0},
+-  {"itervalues",(PyCFunction)PamEnv_itervalues,METH_VARARGS|METH_KEYWORDS, 0},
+-  {"keys",	(PyCFunction)PamEnv_keys,	METH_VARARGS|METH_KEYWORDS, 0},
+-  {"values",	(PyCFunction)PamEnv_values,	METH_VARARGS|METH_KEYWORDS, 0},
++  {"__contains__",  (PyCFunction)(void(*)(void))PamEnv_has_key,METH_VARARGS|METH_KEYWORDS, 0},
++  {"__getitem__",   (PyCFunction)(void(*)(void))PamEnv_getitem,METH_VARARGS|METH_KEYWORDS, 0},
++  {"get",	(PyCFunction)(void(*)(void))PamEnv_get,	METH_VARARGS|METH_KEYWORDS, 0},
++  {"has_key",	(PyCFunction)(void(*)(void))PamEnv_has_key,METH_VARARGS|METH_KEYWORDS, 0},
++  {"items",	(PyCFunction)(void(*)(void))PamEnv_items,	METH_VARARGS|METH_KEYWORDS, 0},
++  {"iteritems",	(PyCFunction)(void(*)(void))PamEnv_iteritems,METH_VARARGS|METH_KEYWORDS, 0},
++  {"iterkeys",	(PyCFunction)(void(*)(void))PamEnv_iterkeys,METH_VARARGS|METH_KEYWORDS, 0},
++  {"itervalues",(PyCFunction)(void(*)(void))PamEnv_itervalues,METH_VARARGS|METH_KEYWORDS, 0},
++  {"keys",	(PyCFunction)(void(*)(void))PamEnv_keys,	METH_VARARGS|METH_KEYWORDS, 0},
++  {"values",	(PyCFunction)(void(*)(void))PamEnv_values,	METH_VARARGS|METH_KEYWORDS, 0},
+   {0,0,0,0}	/* Sentinel */
+ };
+ 
+@@ -2029,7 +2029,7 @@ static PyMethodDef PamHandle_Methods[] =
+ {
+   {
+ "conversation",
+-(PyCFunction)PamHandle_conversation,
++(PyCFunction)(void(*)(void))PamHandle_conversation,
+ METH_VARARGS|METH_KEYWORDS,
+ MODULE_NAME "." PAMHANDLE_NAME "." "conversation(prompts)\n"
+ "  Ask the application to issue the prompts to the user and return the\n"
+@@ -2039,7 +2039,7 @@ static PyMethodDef PamHandle_Methods[] =
+   },
+   {
+ "fail_delay",
+-(PyCFunction)PamHandle_fail_delay,
++(PyCFunction)(void(*)(void))PamHandle_fail_delay,
+ METH_VARARGS|METH_KEYWORDS,
+ MODULE_NAME "." PAMHANDLE_NAME "." "fail_delay(micro_sec)\n"
+  

Bug#919818: ruby-net-ssh breaks test-kitchen autopkgtest

[Paul Gevers]

Source: ruby-net-ssh, test-kitchen
Control: found -1 ruby-net-ssh/1:5.1.0-1
Control: found -1 test-kitchen/1.23.2-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of ruby-net-ssh the autopkgtest of test-kitchen
fails in testing when that autopkgtest is run with the binary packages
of ruby-net-ssh from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
ruby-net-ssh   from testing1:5.1.0-1
test-kitchen   from testing1.23.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of ruby-net-ssh to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package? If needed, please change the
bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-net-ssh

https://ci.debian.net/data/autopkgtest/testing/amd64/t/test-kitchen/1734873/log.gz

Finished in 6.958238s, 317.6091 runs/s, 491.3600 assertions/s.

  1) Failure:
Kitchen::SSH::#wait#test_0001_logs to info for each retry
[/tmp/autopkgtest-lxc.z49qtfaj/downtmp/build.kGs/src/spec/kitchen/ssh_spec.rb:546]:
Expected: 2
  Actual: 0

2210 runs, 3419 assertions, 1 failures, 0 errors, 0 skips



signature.asc
Description: OpenPGP digital signature

Bug#919747: gnome-keysign: please package gnome-keysign 1.0.0

[Ludovico de Nittis]

Hi Sascha,

I was able to reproduce the error that you faced.
The wormhole test didn't import the required key, so it failed if the
testing private key wasn't already in the keyring.

I wrote a fix [1] and very soon (probably even tomorrow) we should
release a hotfix release 1.0.1 of gnome-keysign.

Thank you for your time.

Cheers,
Ludovico de Nittis

[1] https://github.com/gnome-keysign/gnome-keysign/pull/72

On Sat, 19 Jan 2019 18:53:28 +0100 Sascha Steinbiss  wrote:
> tags 919747 help
> thanks
>
> Hi Daniel,
>
> as you may not have noticed, I have prepared packaging for 1.0.0 in the
> gnome-keysign repo on Salsa [1]. It took some work because I had to
> switch everything to Python 3 due to dependency requirements (some
> Python modules newly required in 1.0.0 are only available for Python 3,
> and one even had to be vendored...).
>
> However, some tests in the Magic Wormhole functionality are still
> failing (see attachment) and I am struggling to find the free time to
> dig deeper into this issue. It might well be something trivial that just
> escapes my intuition right now -- if you can spot anything I'd be happy
> to pick up the trail.
>
> I'm tagging this as "help" and also cc'd this to upstream to get things
> moving ;)
> Tobias, is this something you've seen before?
>
> Cheers
> Sascha
>
> [1] https://salsa.debian.org/debian/gnome-keysign
>
> On 1/19/19 6:22 AM, Daniel Kahn Gillmor wrote:
> > Package: gnome-keysign
> > Version: 0.9.8-1
> > Severity: wishlist
> >
> > gnome-keysign 1.0.0 was released by upstream 11 days ago:
> >
> > https://github.com/gnome-keysign/gnome-keysign/releases/tag/1.0.0
> >
> > It would be great if we could have it in debian!
> >
> > thanks for maintaining gnome-keysign,
> >
> >--dkg
> >
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers testing-debug
> >   APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
> > 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 
> > 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages gnome-keysign depends on:
> > ii  avahi-daemon 0.7-4+b1
> > ii  gir1.2-glib-2.0  1.58.3-2
> > ii  gir1.2-gst-plugins-base-1.0  1.14.4-1
> > ii  gir1.2-gstreamer-1.0 1.14.4-1
> > ii  gir1.2-gtk-3.0   3.24.2-3
> > ii  gstreamer1.0-gtk31.14.4-1

Bug#919817: mysql-5.7: Security fixes from the January 2019 CPU

[Salvatore Bonaccorso]

Source: mysql-5.7
Version: 5.7.24-3
Severity: grave
Tags: security upstream
Justification: user security hole

Hi

Details at
https://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html#AppendixMSQL

Regards,
Salvatore

Bug#802211: sulogin --force patch for d-i

[Andreas Henriksson]

Hello,

FYI a completely untested patch for debian-installer component
"user-setup" now exists that should be able to add the needed
overrides to enable "sulogin --force" when installs are made
with root account locked. (Note: This needs systemd >= v240.)
(This doesn't take care of already existing installations that
upgraded, which will need to be handled in some other way. For now
people who want to use it are recommended to add the needed overrides
themselves manualy.)

If someone is willing to test this, then feedback would be appreciated!

See https://salsa.debian.org/ah/user-setup/commits/wip/rootpassword

Regards,
Andreas Henriksson

Bug#900918: debian-installer: Please make the generated images reproducible

[Cyril Brulebois]

Hi Chris,

Chris Lamb  (2019-01-19):
> >  * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
> >ordering only, but that's just the sort part
> 
> I've split this commit and it is much clearer now.

Perfect, thanks.

> >  * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1” as the
> >FAT volume ID; have you checked with people like debian-cd@
> >whether another constant might make more sense?
> 
> Clarified where this comes from in the commmit and in the code
> itself.

Thanks.

> >  * ea1a896181daa3b82c5a62ae31839b457a0dbe0b modifies BUILD_DATE,
> >adding a few characters (“:SS”); that ends up in various help
> >screens
> 
> In my tests, this did not break any visual text wrapping, etc.

Perfect.

> >  * f181b4fe90b9030f515c7e6129239b96131b3926 oh more en_GB, yay.
> 
> Fixed (use 'results' instead).

(I was genuinely happy to learn about the en_GB version; always
struggling to remember how to spell it in French vs. (American) English,
was happy to discover the British English version. :))

> §
> 
> Thank you again for your review. Let me know if you would require any
> further modifications before merging. :-)

That's looking good but I'm seeing new warnings because of gzip's being
unhappy about the GZIP environment variable. This seems to have been
deprecated in gzip 1.8:

gzip: warning: GZIP environment variable is deprecated; use an alias or 
script

I'm attaching the patch I've deployed locally, and it seems to me that
[1] might want an update.

 1. https://wiki.debian.org/ReproducibleBuilds/TimestampsInGzipHeaders

An other solution would be to use tar | gzip instead of passing -I to
tar, but I thought I'd learn about that option in the process. :)

Back to d-i results: I'm seeing small differences in the generated
-images tarball, that I'll try to investigate. I'll probably push the
series anyway, as these patches are helping anyway. :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature