Bug#930997: cmake: reprotest's 'setarch linux32 dh_auto_configure' on amd64 results in CMAKE_SYSTEM_PROCESSOR = i386

[Niels Thykier]

Control: reassign -1 reprotest
Control: tags -1 -moreinfo

Helmut Grohne:
> Hi Niels,
> 
> On Sat, Sep 14, 2019 at 06:08:00AM +, Niels Thykier wrote:
>> Is there any update on this?  At the moment, this bug is not actionable
>> and sprayed over three packages.
> 
> No. I don't think there are any news here. I had hoped that my previous
> mails would have made my position clear. Let me try to be more explicit:
> I think that running native amd64 builds in linux32 is broken and that
> any tool doing so (e.g. reprotest) is buggy.
> 
> Having debhelper pass CMAKE_SYSTEM_PROCESSOR is a nice idea, but doing
> so will break a fair number of packages in subtle ways. Therefore I
> recommend not doing that (other than for cross compilation).
> 
> This is basically repeating what I already said. If you concur, the
> logical next step is reassigning to reprotest.
> 
> Helmut
> 

Thanks for clarifying; I missed that part.

Reassigning to reprotest

Thanks,
~Niels

Bug#924716: cron: diff for NMU version 3.0pl1-134.1

[Christian Kastner]

Hi Laurent,

sorry for the delay. I changed something in my bug subscription mails,
and never saw this bug (probably because I'm "only" in Uploaders).

On 13.09.19 16:49, Laurent Bigonville wrote:
> Control: tags 924716 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for cron (versioned as 3.0pl1-134.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.

No need to NMU -- I'll upload a fix today.

Thank you both for your work on the patches!

Regards,
Christian

> 
> Regards.
> 
> diff -u cron-3.0pl1/debian/changelog cron-3.0pl1/debian/changelog
> --- cron-3.0pl1/debian/changelog
> +++ cron-3.0pl1/debian/changelog
> @@ -1,3 +1,10 @@
> +cron (3.0pl1-134.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Stop using obsolete SELinux API (Closes: #924716)
> +
> + -- Laurent Bigonville   Fri, 13 Sep 2019 16:27:42 +0200
> +
>  cron (3.0pl1-134) unstable; urgency=medium
>  
>* Increase maximum crontab length to 10,000 lines.
> diff -u cron-3.0pl1/user.c cron-3.0pl1/user.c
> --- cron-3.0pl1/user.c
> +++ cron-3.0pl1/user.c
> @@ -31,8 +31,6 @@
>  #ifdef WITH_SELINUX
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  
>  static int get_security_context(char *name, int crontab_fd, 
> security_context_t
> @@ -108,13 +106,35 @@
>   * permission check for this purpose.
>   */
>  
> + security_class_t tclass = string_to_security_class("file");
> + if (!tclass) {
> + log_it(name, getpid(), "Failed to translate security class 
> file", tabname);
> + freeconary(context_list);
> + if (security_deny_unknown() == 0) {
> + return 0;
> + } else {
> + return -1;
> + }
> + }
> +
> + access_vector_t bit = string_to_av_perm(tclass, "entrypoint");
> + if (!bit) {
> + log_it(name, getpid(), "Failed to translate av perm 
> entrypoint", tabname);
> + freeconary(context_list);
> + if (security_deny_unknown() == 0) {
> + return 0;
> + } else {
> + return -1;
> + }
> + }
> +
>   for (i = 0; i < list_count; i++) {
>   retval = security_compute_av(context_list[i],
>file_context,
> -  SECCLASS_FILE,
> -  FILE__ENTRYPOINT,
> +  tclass,
> +  bit,
>&avd);
> - if (!retval && ((FILE__ENTRYPOINT & avd.allowed) == 
> FILE__ENTRYPOINT)) {
> + if(!retval && ((bit & avd.allowed) == bit)) {
>   *rcontext = strdup(context_list[i]);
>   freecon(file_context);
>   freeconary(context_list);
> 

Bug#940279: wham-align: FTBFS with GCC 9: undefined reference to `pthread_create'

[Graham Inggs]

Source: wham-align
Version: 0.1.5-1
Severity: serious
Tags: bullseye sid
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-9

Hi Maintainer

As can be seen on reproducible builds [1], wham-align FTBFS with GCC 9.


Regards
Graham


[1]



g++ -lpthread -o wham sequence.o hash.o embedhash.o main.o aligner.o
interval.o edit_distance.o error.o short.o hitset.o model.o
perfcounters.o writer.o
g++ -lpthread -o wham-build sequence.o hash.o embedhash.o builder.o
aligner.o interval.o edit_distance.o error.o short.o hitset.o model.o
perfcounters.o writer.o
/usr/bin/ld: main.o: in function `align(char*, AlignInfo*, char*, int)':
./main.cpp:466: undefined reference to `pthread_create'
/usr/bin/ld: ./main.cpp:466: undefined reference to `pthread_create'
/usr/bin/ld: ./main.cpp:475: undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
make[1]: *** [makefile:19: wham] Error 1
make[1]: Leaving directory '/build/1st/wham-align-0.1.5'
dh_auto_build: make -j16 "INSTALL=install --strip-program=true"
returned exit code 2

Bug#940279: wham-align: FTBFS with GCC 9: undefined reference to `pthread_create'

[Graham Inggs]

Sorry, copy/paste error and ended sending the mail unfinished.

On Sun, 15 Sep 2019 at 09:25, Graham Inggs  wrote:
> As can be seen on reproducible builds [1], wham-align FTBFS with GCC 9.

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-9/porting_to.html

GCC 9 also passes the linker option --as-needed by default; typical
build issues are passing libraries before object files to the linker,
or underlinking of convenience libraries built from the same source.

What I hope is the relevant part of the log, is at the end of my
previous message.


[1] https://tests.reproducible-builds.org/debian/rb-pkg/wham-align.html

Bug#931551: transition: llvm-defaults to 8

[Shengjing Zhu]

Hi,

On Sun, Jul 07, 2019 at 04:29:31PM +0200, Sylvestre Ledru wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello
> 
> Now that we release buster, I would like to move llvm-defaults to 
> llvm-toolchain-8.
> 
> Thanks,
> Sylvestre
> 
> Ben file:
> 
> title = "llvm-defaults";
> 
> Affected: .depends ~ /(clang|llvm)1?-?[345678]/
> Good: .depends ~ /(clang|llvm)1?-?[8]/
> Bad: .depends ~ /(clang|llvm)1?-?[34567]/
> 

I recently package ccls, which depends on libllvm[1].
I'm curious why this ben file doesn't include libllvm?
And should I rebuild ccls manually? Or it will be handled by RT.
I don't see ccls is on [2].

[1] https://tracker.debian.org/pkg/ccls
[2] https://release.debian.org/transitions/html/llvm-defaults.html

Thanks
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#940280: spoa: FTBFS with GCC 9: some symbols or patterns disappeared

[Graham Inggs]

Source: spoa
Version: 3.0.0-1
Severity: serious
Tags: bullseye sid
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-9

Hi Maintainer

As can be seen on reproducible builds [1], spoa FTBFS with GCC 9.

Common build failures are new warnings resulting in build failures
with -Werror turned on, or new/dropped symbols in Debian symbols
files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-9/porting_to.html

GCC 9 also passes the linker option --as-needed by default; typical
build issues are passing libraries before object files to the linker,
or underlinking of convenience libraries built from the same source.

I've include what I think is the relevant part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/spoa.html


dpkg-gensymbols: warning: some new symbols appeared in the symbols
file: see diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libspoa3/DEBIAN/symbols doesn't match
completely debian/libspoa3.symbols
--- debian/libspoa3.symbols (libspoa3_3.0.0-1_amd64)
+++ dpkg-gensymbolsVs0TTc 2019-09-01 18:18:56.118394192 -1200
@@ -68,7 +68,8 @@
  _ZNK4spoa5Graph8subgraphEjjRSt6vectorIiSaIiEE@Base 1.1.3
  
_ZNK4spoa5Graph9print_dotERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
1.1.5
  _ZNKSt5ctypeIcE8do_widenEc@Base 1.1.5
- 
_ZNSt10_HashtableIjjSaIjENSt8__detail9_IdentityESt8equal_toIjESt4hashIjENS1_18_Mod_range_hashingENS1_20_Default_ranged_hashENS1_20_Prime_rehash_policyENS1_17_Hashtable_traitsILb0ELb1ELb121_M_insert_unique_nodeEmmPNS1_10_Hash_nodeIjLb0EEEm@Base
1.1.3
+#MISSING: 3.0.0-1#
_ZNSt10_HashtableIjjSaIjENSt8__detail9_IdentityESt8equal_toIjESt4hashIjENS1_18_Mod_range_hashingENS1_20_Default_ranged_hashENS1_20_Prime_rehash_policyENS1_17_Hashtable_traitsILb0ELb1ELb121_M_insert_unique_nodeEmmPNS1_10_Hash_nodeIjLb0EEEm@Base
1.1.3
+ 
_ZNSt10_HashtableIjjSaIjENSt8__detail9_IdentityESt8equal_toIjESt4hashIjENS1_18_Mod_range_hashingENS1_20_Default_ranged_hashENS1_20_Prime_rehash_policyENS1_17_Hashtable_traitsILb0ELb1ELb19_M_rehashEmRKm@Base
3.0.0-1
  _ZNSt11_Deque_baseIjSaIjEE17_M_initialize_mapEm@Base 1.1.3
  _ZNSt11_Deque_baseIjSaIjEED1Ev@Base 1.1.3
  _ZNSt11_Deque_baseIjSaIjEED2Ev@Base 1.1.3
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:13: binary] Error 255
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2

Bug#940281: inputlirc: does not start because /run/lirc missing

[Stefan Zechner]

Package: inputlirc
Version: 30-1
Severity: important

Dear Maintainer,

I'm using inputlirc without any other lirc packages: dpkg -l|grep lirc
ii  inputlirc 30-1  
 amd64Zeroconf LIRC daemon using input event devices
ii  liblirc-client0:amd64 0.10.1-5.2
 amd64infra-red remote control support - client library

But service is not starting after reboot: systemctl status inputlirc
● inputlirc.service - Zeroconf LIRC daemon using input event devices
   Loaded: loaded (/lib/systemd/system/inputlirc.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-09-15 10:27:36 CEST; 45s 
ago
 Docs: man:inputlircd(8)
  Process: 628 ExecStart=/usr/sbin/inputlircd -f $OPTIONS $EVENTS (code=exited, 
status=71)
 Main PID: 628 (code=exited, status=71)

Sep 15 10:27:36 glotz inputlircd[628]: inputlircd: /dev/input/event5 does not 
support EV_KEY events
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event4 3
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event3 3
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event5 does not support 
EV_KEY events
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event2 17
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event1 1f
Sep 15 10:27:36 glotz inputlircd[628]: /dev/input/event0 120013
Sep 15 10:27:36 glotz inputlircd[628]: Unable to bind AF_UNIX socket to 
/run/lirc/lircd: No such file or directory
Sep 15 10:27:36 glotz systemd[1]: inputlirc.service: Main process exited, 
code=exited, status=71/OSERR
Sep 15 10:27:36 glotz systemd[1]: inputlirc.service: Failed with result 
'exit-code'.

I have to manually create /run/lirc and: systemctl restart inputlirc 

Any idea what is missing?

Regards,
Stefan


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (900, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 inputlirc depends on:
ii  libc6  2.28-10

inputlirc recommends no packages.

Versions of packages inputlirc suggests:
ii  input-utils  1.0-1.1+b1
pn  lirc 

-- no debconf information

Bug#884516: python-bayespy: FTBFS and Debci failure on several architectures

[Graham Inggs]

Control: severity -1 important

Arch:all packages are only required to build on amd64.
There are still autopkgtest failures on several architectures, which
are reproducible on the porterboxes, so downgrading the severity, but
leaving the bug open.

Bug#940282: lintian: False positive library-not-linked-against-libc on Octave add-ons

[Rafael Laboissière]

Package: lintian
Version: 2.21.0
Severity: normal
Tags: patch

Checking the octave-stk package against the current version of Lintian 
in unstable (2.21.0), yields several errors like this one:


E: octave-stk: library-not-linked-against-libc 
usr/lib/x86_64-linux-gnu/octave/packages/stk-2.6.0/x86_64-pc-linux-gnu-api-v52/__stk_dist_matrixx__.mex

I believe that these are false positives.  The *.mex files (like *.oct 
files) are dynamically linked objects that are loaded at runtime by 
Octave and contains extensions that add functionality to the program 
(like add-ons).


These files are produced by mkoctfile, which is called by the 
dh-octave insfrastructure, on which most of the packages providing 
Octave add-ons build-depend.  These *.mex and *.oct are never 
underlinked, as itcan be checked running, for instance:


ldd -r __stk_dist_matrixx__.mex

I proposed a very simplistic patch for fixing the problem as a merge 
request against the Lintian Git repository at salsa.d.o:


https://salsa.debian.org/lintian/lintian/merge_requests/258

My knowledge on the internals of Lintian are very limited, so I 
apologize in advance if this patch is not appropriate.


Best,

Rafael Laboissière

Bug#940283: Removing python-testtools breaks many packages

[Jelmer Vernooij]

Package: src:python-testtools
Version: 2.3.0-6
Severity: serious

The current upload drops the python 2 packages, which are still used by e.g. 
bzr and python-subunit, python-fixtures, python-testscenarios, python-daemon, 
python-fastimport.

Bug#940284: autogeneration of ssl key in ssl server mode of ncat is broken

[Stefan Baur]

Package: ncat
Version: 7.70+dfsg1-6

When calling ncat 7.70 like so:

ncat --ssl -l -p 4223 -v

It reports:

Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Generating a temporary 1024-bit RSA key. Use --ssl-key and
--ssl-cert to use a permanent one.
Ncat: SHA-1 fingerprint: 0EE7 DDAD 7284 7826 D49D 9277 B456 371D 1652 C887
Ncat: SSL_CTX_use_certificate(): error:140AB18F:SSL
routines:SSL_CTX_use_certificate:ee key too small. QUITTING.

... and quits.

Expected behavior, as displayed by ncat 7.60:

Ncat: Version 7.60 ( https://nmap.org/ncat )
Ncat: Generating a temporary 1024-bit RSA key. Use --ssl-key and
--ssl-cert to use a permanent one.
Ncat: SHA-1 fingerprint: 88D6 3917 08F9 A7A2 555A A97F 9567 D863 DC4F C6EF
Ncat: Listening on :::4223
Ncat: Listening on 0.0.0.0:4223

Note that the actual cause might be the OpenSSL version being different
as well. Buster has OpenSSL 1.1.1c, if I'm not mistaken; while the
system where I tried out ncat 7.60 has OpenSSL 1.1.1 (without the "c").

However, if OpenSSL by default requires a minimum key length larger than
1024 bits, then ncat should either default to a larger key length or
offer a commandline parameter to specify an arbitrary key length.

It seems to be fixed in ncat 7.80, which defaults to a 2048-bit key now:

Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Generating a temporary 2048-bit RSA key. Use --ssl-key and
--ssl-cert to use a permanent one.
Ncat: SHA-1 fingerprint: 7612 C7AD 2B90 48DD 6932 2745 A324 F590 3361 16C3
Ncat: Listening on :::4223
Ncat: Listening on 0.0.0.0:4223

Would be possible to either get 7.80 into Buster, or to backport the
particular change into the 7.70 we have in Buster?

I am aware that it is possible to specify a key and cert file; but that
is only acceptable as a workaround, not as a solution.

Kind Regards,
Stefan Baur

Bug#887122: python2.7

[Pavlo Boiko]

In may case the error was provoked by switching to python3.7 by default. 
So I changed the first line of obamenu to ensure that the script is 
executed by python2.7

Bug#940285: segmentation fault at start

[Arturo Borrero Gonzalez]

Package: gimp
Version: 2.10.8-2+b1
Severity: important
Tags: upstream

Hi,

thanks for your work on this package, is really appreciated.

Today I was trying to open a jpeg in gimp and saw this segfault when starting 
it:

```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-multiarch --disable-werror 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa 
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6) 

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```
/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7f8865565f98]
gimp-2.10(+0xd1590)[0x5614c6c77590]
gimp-2.10(+0xd19b8)[0x5614c6c779b8]
gimp-2.10(+0xd2029)[0x5614c6c78029]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13510)[0x7f8864a9d510]
gimp-2.10(gimp_gegl_mask_is_empty+0x91)[0x5614c7062411]
gimp-2.10(+0x3b7810)[0x5614c6f5d810]
gimp-2.10(+0x42ec18)[0x5614c6fd4c18]
gimp-2.10(+0x3d5b50)[0x5614c6f7bb50]
gimp-2.10(+0x42f2aa)[0x5614c6fd52aa]
gimp-2.10(gimp_drawable_set_buffer_full+0x1cb)[0x5614c6f7a9bb]
gimp-2.10(gimp_drawable_set_buffer+0x11d)[0x5614c6f7af9d]
gimp-2.10(gimp_drawable_new+0x106)[0x5614c6f7b296]
gimp-2.10(gimp_layer_new+0x90)[0x5614c6fd84d0]
gimp-2.10(+0x3319cc)[0x5614c6ed79cc]
gimp-2.10(gimp_procedure_execute+0x237)[0x5614c6f10577]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x5614c6f09a39]
gimp-2.10(gimp_plug_in_handle_message+0x216)[0x5614c6f14626]
gimp-2.10(+0x36cf91)[0x5614c6f12f91]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7f8864c43898]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4ec88)[0x7f8864c43c88]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7f8864c43f82]
gimp-2.10(gimp_plug_in_manager_call_run+0x5fc)[0x5614c6f2435c]
gimp-2.10(+0x376dbe)[0x5614c6f1cdbe]
gimp-2.10(gimp_procedure_execute+0x237)[0x5614c6f10577]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x5614c6f09a39]
gimp-2.10(gimp_pdb_execute_procedure_by_name+0x3cd)[0x5614c6f09efd]
gimp-2.10(file_open_image+0x33d)[0x5614c700a6fd]
gimp-2.10(file_open_with_proc_and_display+0x29d)[0x5614c700b64d]
gimp-2.10(file_open_from_command_line+0x1b4)[0x5614c700beb4]
gimp-2.10(app_run+0x304)[0x5614c6c76d14]
gimp-2.10(main+0x36e)[0x5614c6c7664e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f88648eebbb]
gimp-2.10(_start+0x2a)[0x5614c6c767da]

```


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.8-2
ii  libc62.29-1
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9

Bug#940230: ircd-hybrid: use after free and crash

[Dominic Hargreaves]

Control: tags -1 + moreinfo

On Sat, Sep 14, 2019 at 11:54:53AM +0200, Julien Cristau wrote:
> Package: ircd-hybrid
> Version: 1:8.2.24+dfsg.1-1
> Severity: grave
> 
> Hi,
> 
> I just upgraded to buster and ircd keeps crashing.
> One case with a segfault in strcmp, other times with glibc aborts.

Does this happen with a default config file? If not, could you share your
configuration? (feel free to email it to me privately if you don't want
it to be public).

And although I suspect it's not the same problem, could you check whether
you have a dhparam.pem file created where your config file refers to it?
See 

Cheers,
Dominic.

Bug#940286: golang-github-anacrolix-missinggo-dev has circular Depends on golang-github-anacrolix-tagflag-dev

[Bill Allombert]

Package: golang-github-anacrolix-missinggo-dev
Version: 2.1.0-4
Severity: important

Hello Debian Go Packaging Team,

There is a circular dependency between golang-github-anacrolix-missinggo-dev 
and golang-github-anacrolix-tagflag-dev:

golang-github-anacrolix-missinggo-dev   :Depends: 
golang-github-anacrolix-tagflag-dev
golang-github-anacrolix-tagflag-dev :Depends: 
golang-github-anacrolix-missinggo-dev

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should strive to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940287: pki-base has circular Depends on python3-pki-base

[Bill Allombert]

Package: pki-base
Version: 10.7.3-3
Severity: important

Hello Debian FreeIPA Team,

There is a circular dependency between pki-base and python3-pki-base:

pki-base:Depends: python3-pki-base
python3-pki-base:Depends: pki-base (= 10.7.3-3)

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should strive to avoid them.

See threads 
http://lists.debian.org/debian-devel/2005/06/msg02111.html
http://lists.debian.org/debian-devel/2005/11/msg01101.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940289: goaccess: not built with --with-openssl

[Simon]

Package: goaccess
Version: 1:1.2-4+b10
Severity: normal

Dear Maintainer,

Package is not built with --with-openssl so it is not possible to serve
the realtime html over a tls connection as the WebSocket does not have support.

Trying to pass ssl parameters on the command line gives errors message
goaccess: unrecognized option '--ssl-cert='

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

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

Versions of packages goaccess depends on:
ii  libbz2-1.01.0.6-9.2~deb10u1
ii  libc6 2.28-10
ii  libgeoip1 1.6.12-1
ii  libncurses6   6.1+20181013-2+deb10u1
ii  libtinfo6 6.1+20181013-2+deb10u1
ii  libtokyocabinet9  1.4.48-12
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages goaccess recommends:
ii  geoip-database20181108-1
pn  geoip-database-extra  

goaccess suggests no packages.

-- no debconf information

Bug#940290: q2-types: triangular dependency with q2-types, q2cli

[Bill Allombert]

Package: q2-types
Version: 2019.7.0-1
Severity: important

Hello Debian Med Packaging Team,

There is a trianglar dependency between q2-types, q2cli and qiime:

q2-types :Depends: qiime
q2cli:Depends: qiime
qiime:Depends: q2cli, q2-types

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940288: less: with a pipe, the line numbers can artificially be turned off after Ctrl-C

[Vincent Lefevre]

Package: less
Version: 551-1
Severity: normal

Run the following command:

  ( trap '' INT; while true; do echo foo; done; ) | less

Then type /w [Return] to search for "w" (there isn't any match).
And type Ctrl-C to abort. One gets:

  Pattern not found  (press RETURN)

Then type [End] to go to the end, but since this is an infinite loop
here[*], this will hang. Type Ctrl-C to abort. One gets:

  Line numbers turned off  (press RETURN)

while there is no reason to turn the line numbers off. For instance,
one does not get this issue with just several aborted searches or with
just several aborted [End].

I can also reproduce this bug with less 481 (Debian/stretch) and 487.

[*] In practice, this can just be a command with a lot of output, but
which hasn't finished yet.

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

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

Versions of packages less depends on:
ii  libc6  2.29-1
ii  libtinfo6  6.1+20190803-1

less recommends no packages.

less suggests no packages.

-- no debconf information

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

Bug#939178: release-notes: Describe name selection rules in the "Migrating from legacy network interface names" section

[Justin B Rye]

Here's a patch for the Release Notes adding another common corner-case
to the list of things to beware of, plus an updated set of external
links including "https://wiki.debian.org/NetworkInterfaceNames";.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index 3105a90f..524f2650 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -150,8 +150,7 @@ information mentioned in .
 
  The alternative is to switch to a supported mechanism for enforcing
  the old naming scheme, such as a systemd .link
- file (see 
- systemd.link(5)).
+ file (see systemd.link(5)).
  The net.ifnames=0 kernel commandline option might
  also work for systems with only one network interface (of a given type).
 
@@ -173,9 +172,10 @@ $ udevadm test-builtin net_id /sys/class/net/eth0 2>/
 
 
   This should give enough information to devise a migration plan. (If the
-  udevadm output includes an onboard
-  name, that takes priority; MAC-based names are normally treated as a
-  fallback, but may be needed for USB network hardware.)
+  udevadm output includes an onboard or
+  slot name, that takes priority; MAC-based names are
+  normally treated as a fallback, but may be needed for USB network
+  hardware.)
 
 
   Once you are ready to carry out the switch, disable
@@ -194,9 +194,9 @@ $ sudo update-initramfs -u
  names. Adjust any remaining configuration files, and test your system.
 
 
- See the
- https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/";>upstream
- documentation and the udev
+ See the wiki, https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html";>upstream
+ documentation, and the udev
  README.Debian for further information.
 
   

Bug#940292: golang-golang-x-net-dev: circular dependency hell

[Bill Allombert]

Package: golang-golang-x-net-dev
Version: 1:0.0+git20190811.74dc4d7+dfsg-1
Severity: important

Hello Debian Go Packaging Team,

There is a circular dependency between golang-golang-x-net-dev,
golang-golang-x-text-dev and golang-golang-x-tools-dev:

golang-golang-x-net-dev :Depends: golang-golang-x-text-dev (>= 0.3.0~)
golang-golang-x-text-dev:Depends: golang-golang-x-tools-dev
golang-golang-x-tools-dev   :Depends: golang-golang-x-net-dev

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940291: ruby-jekyll-feed has circular Depends on jekyll

[Bill Allombert]

Package: ruby-jekyll-feed
Version: 0.12.1-3
Severity: important

Hello Debian Ruby Extras Maintainers,

There is a circular dependency between ruby-jekyll-feed and jekyll:

ruby-jekyll-feed:Depends: jekyll (<< 5~), jekyll (>= 3.7)
jekyll  :Depends: ruby-jekyll-feed

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should try to avoid them.

See threads 
http://lists.debian.org/debian-devel/2005/06/msg02111.html
http://lists.debian.org/debian-devel/2005/11/msg01101.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#931950: transition: libgeotiff

[Adam D. Barratt]

On Sun, 2019-09-15 at 08:27 +0200, Sebastiaan Couwenberg wrote:
> On 9/10/19 8:11 AM, Sebastiaan Couwenberg wrote:
> > libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1)
> > cannot
> > be removed from testing due to gnudatalanguage, which I don't
> > understand. But this should be resolved when the package get
> > autoremoved
> > on the 14th.
> 
> gnudatalanguage was not removed yesterday, it's still marked for
> removal on 14 September.

It was removed in the 10:00 run on the 15th, which was the first run
after it was in the auto-removals hint list. You just need a little
more patience.

> Version 0.9.9-10+b1 of the gnudatalanguage binary packages is in
> testing,

Not any longer.

Regards,

Adam

Bug#940293: less: with a pipe, [End] + Ctrl-C sends back to the beginning of the file

[Vincent Lefevre]

Package: less
Version: 551-1
Severity: normal

Run the following command:

  ( trap '' INT; while true; do echo foo; done; ) | less -M

Then type one or a few [PageDown], and type [End] to go to the end,
but since this is an infinite loop here[*], this will hang. Type
Ctrl-C to abort. One is back to the beginning of the file, at line 1
(less shows something like "lines 1-59") instead of remaining at
the same position (or going to some higher position). In case of
interrupted [End], less should never go backward.

I can also reproduce this bug with less 481 (Debian/stretch) and 487.

[*] In practice, this can just be a command with a lot of output, but
which hasn't finished yet.

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

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

Versions of packages less depends on:
ii  libc6  2.29-1
ii  libtinfo6  6.1+20190803-1

less recommends no packages.

less suggests no packages.

-- no debconf information

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

Bug#940294: ITP: r-cran-propclust -- Propensity Clustering and Decomposition

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-propclust -- Propensity Clustering and Decomposition
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-propclust
  Version : 1.4
  Upstream Author : John Michael O Ranola
* URL : https://cran.r-project.org/package=PropClust
* License : GPL-2+
  Programming Lang: GNU R
  Description : Propensity Clustering and Decomposition
 Implementation of propensity clustering and decomposition as described
 in Ranola et al. (2013) . Propensity
 decomposition can be viewed on the one hand as a generalization of the
 eigenvector-based approximation of correlation networks, and on the
 other hand as a generalization of random multigraph models and conformity-
 based decompositions.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-propclust

Bug#940295: libeclipse-compare-java: circular dependency hell

[Bill Allombert]

Package: libeclipse-compare-java
Version: 3.7.600+eclipse4.12-1
Severity: important

Hello Debian Java Maintainers,

There is a circular dependency between libeclipse-compare-java, 
libeclipse-ui-editors-java and libeclipse-ui-workbench-texteditor-java:

libeclipse-compare-java :Depends: libeclipse-ui-editors-java, 
libeclipse-ui-workbench-texteditor-java
libeclipse-ui-editors-java  :Depends: 
libeclipse-ui-workbench-texteditor-java
libeclipse-ui-workbench-texteditor-java :Depends: 
libeclipse-compare-java

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940241: RFS: backintime 1.2.1-1 -- simple backup/snapshot system

[Adam Borowski]

On Sat, Sep 14, 2019 at 03:16:01PM +0200, Fabian Wolff wrote:
> I am looking for a sponsor for an upload of the 'backintime' package.

>   backintime (1.2.1-1) unstable; urgency=medium
> 
> * Add myself as co-maintainer in debian/control.
> * New upstream release (Closes: #930589, #935341, #879611).
> * Upgrade to Standards-Version 4.4.0 (no changes).
> * Upgrade to debhelper compat level 12.
> * Remove debian/patches (all fixed upstream).
> * Introduce new backintime-qt package, because upstream moved from
>   Qt 4 to Qt 5. Make backintime-qt4 a transitional package.
> * Drop the transitional backintime-{gnome,kde} packages
>   (Closes: #939139, #939140).
> 
>-- Fabian Wolff   Sat, 14 Sep 2019 14:36:13 +0200

Alas, it dies on start for me, with no error message given when starting
from a GUI.  The crash is:

─
[/tmp]$ backintime

Back In Time
Version: 1.2.1

Back In Time comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type `backintime --license' for details.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 177, in 
activate_name_owner
return self.get_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 363, in get_name_owner
's', (bus_name,), **keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 653, in 
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could 
not get owner of name 'net.launchpad.backintime.serviceHelper': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/backintime/common/backintime.py", line 1165, in 
startApp()
  File "/usr/share/backintime/common/backintime.py", line 521, in startApp
return getConfig(args, False)
  File "/usr/share/backintime/common/backintime.py", line 669, in getConfig
cfg = config.Config(config_path = args.config, data_path = args.share_path)
  File "/usr/share/backintime/common/config.py", line 279, in __init__
self.setupUdev = tools.SetupUdev()
  File "/usr/share/backintime/common/tools.py", line 1715, in __init__
conn = bus.get_object(SetupUdev.CONNECTION, SetupUdev.OBJECT)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 243, in get_object
follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 250, in __init__
self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 182, in 
activate_name_owner
self.start_service_by_name(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 280, in 
start_service_by_name
'su', (bus_name, flags)))
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 653, in 
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: 
Launch helper exited with unknown return code 1
─


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#884956: HiDPI scaling is still broken with libqt5core5a 5.10.1+dfsg-6

[Vincent Lefevre]

Control: found 884956 5.11.3+dfsg1-4
Control: tags 884956 fixed-upstream

On 2018-11-13 15:49:24 +0300, Dmitry Shachnev wrote:
> Hi Vincent and all!
> 
> On Sun, May 06, 2018 at 11:09:09AM +0200, Vincent Lefevre wrote:
> > Control: reopen -1
> > Control: found -1 5.10.1+dfsg-6
> >
> > The bug is still there. The upgrade of the qtbase-opensource-src
> > packages to 5.10.1+dfsg-6 had no effect.
> 
> Can you please check if this is still an issue with qtbase 5.11.2+dfsg-4?

Sorry for the last reply. After unsetting QT_AUTO_SCREEN_SCALE_FACTOR,
the bug still occurs in Debian/unstable.

The bug has been fixed upstream a couple of days ago, but I haven't
tested.

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

Bug#940296: teamviewer: Respect "disable" setting and don't override administrator

[Ben Wiederhake]

Package: teamviewer
Version: 14.5.5819
Severity: normal

Dear Maintainer,

I have teamviewer disabled by default, and stopped, to save resources.  My
intention is to only enable teamviewer when I need to give support to my
friends.

Steps to reproduce:
1. Disable and stop teamviewer:
$ systemctl disable teamviewer && systemctl stop teamviewer
2. Update teamviewer.  (Reinstallation probably triggers the same bug.)

Expected behavior:
Teamviewer is disabled and stopped, and should stay that way.

Actual behavior:
Teamviewer actively goes against being disabled, enables itself, and starts the
daemon.

This is incredibly annoying as I have to manually disable and stop teamviewer
on every update.
Also, it undermines the typical authority structure:  "The admin is right."
If your daemon is disabled, it should *stay* disabled.

Please remove that "feature", thanks.

Cheers,
Ben Wiederhake



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

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

Versions of packages teamviewer depends on:
ii  libc62.29-1
ii  libdbus-1-3  1.12.16-1
ii  libqt5dbus5  5.11.3+dfsg1-4
ii  libqt5gui5   5.11.3+dfsg1-4
ii  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5webkit55.212.0~alpha2-21
ii  libqt5widgets5   5.11.3+dfsg1-4
ii  libqt5x11extras5 5.11.3-2
ii  qml-module-qtquick-controls  5.11.3-2
ii  qml-module-qtquick-dialogs   5.11.3-2
ii  qml-module-qtquick-layouts   5.11.3-4
ii  qml-module-qtquick-window2   5.11.3-4
ii  qml-module-qtquick2  5.11.3-4

Versions of packages teamviewer recommends:
ii  fonts-liberation  1:1.07.4-10

teamviewer suggests no packages.

-- no debconf information

Bug#940297: ca-certificates-java: circular dependency hell

[Bill Allombert]

Package: ca-certificates-java
Version: 20190909
Severity: important

Hello Debian Java Maintainers,

There is a circular dependency between ca-certificates-java, 
default-jre-headless and openjdk-11-jre-headless:

ca-certificates-java:Depends: default-jre-headless
default-jre-headless:Depends: openjdk-11-jre-headless
openjdk-11-jre-headless :Depends: ca-certificates-java (>= 20190405~)

Complex circular dependencies are known to cause problems during upgrade, so we
should try to get rid of them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#824192: wine: please add new wine-gecko source package

[Jens Reyer]

Hi

> I was wondering if somebody is working on this

AFAIK noone on wine-gecko (but I'd be happy to be wrong).  For wine-mono
there was some work half a year ago, but I haven't seen any results.


> In the
> past the wine in Debian would at least try to download wine gecko from 
> official
> binary files at winehq.org, and now even that is gone
Downloading from a 3rd party (including upstream) is exactly what we
want to prevent.  Did I miss something, or are you confusing something here?


> I know it is know (and documented in README.Debian.gz), but I couldn't find 
> exact
> details what are the current blockers to build it in Debian using debian
> libraries. Is it because it is somehow forked vesion of Gecko? It is fully
> understandable tho, and can be considered a separate project, as it provides
> completly different functionality than gecko. Is it a security support?
> Or some other reasons?

I guess the main reason is just time, or generally a person who is
willing to work on this.  One of the main blockers in the past afaik was
handling the copyright.

The good news is that upstream recently fixed the build with python3 and
current gcc - so if these were blockers now is a good time to start again.

In the mean time, if you can't help on packaging, the best option
probably is to download the installers manually to your user's
.cache/wine.  Then Wine will check the correct version and checksum of
the installer and install it automatically.  For wine 4.0 this is:

cd ~/.cache/wine
wget http://dl.winehq.org/wine/wine-gecko/2.47/wine_gecko-2.47-x86.msi
wget http://dl.winehq.org/wine/wine-gecko/2.47/wine_gecko-2.47-x86_64.msi
wget http://dl.winehq.org/wine/wine-mono/4.7.5/wine-mono-4.7.5.msi

Greets
jre

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

[Patrick Schleizer]

Happy to report that both invocations of grml-debootstrap and pbuilder /
cowbuilder are compatible with mmdebstrap.

Johannes Schauer:
> you seem to claim that mmdebstrap does not support the --arch argument. But it
> does. It does so by configuring Getopt::Long with auto_abbrev. This means that
> a long option like --architectures can also be written with less characters. 
> It
> works on my system. It does not on yours? Also from the man page:
> 
>  Long options require a double dash and may be abbreviated to uniqueness.


Magic. :)

Works for me. :)

>> Using a file
>> /home/user/Whonix/build_sources/debian_stable_current_clearnet.list
>> which contains both, Debian "standard" repository as well as Debian
>> security repository.
>>
>> This is to make use of mmdebstrap excellent security feature to
>> bootstrap from two repositories at once. If the APT version in Debian
>> "standard" repository had a vulnerability, then the vulnerable version
>> would be installed first before vulnerable APT would be used to upgrade
>> in a later step from Debian security repository.
>>
>> "Incompatibility" is perhaps a far stretched term. How do we "teach"
>> grml-debootstrap, cowbuilder (or pbuilder?) "use both, Debian "standard"
>> repository and Debian security repository when using mmdebstrap"?
>>
>> It's like "the ecosystem does not take advantage of mmdebstrap" yet.
> 
> Okay, but as far as I can see there is nothing that can be done in mmdebstrap
> about this, right?


Maybe not.

I guess the problem indeed isn't mmdebstrap but how other tools are
invoking $DEBOOTSTRAP.

Do you think you could contact pbuilder / cowbuilder / grml-debootstrap
to see how invocation of debootstrap (single repository) vs mmdebstrap
(Debian "standard" repository + Debian security repository) invocation
could be sorted out?

Not sure how crazy would it be to have mmdebstrap auto inject the Debian
security repository? Perhaps keep mmdebstrap as is but have a wrapper
mmdebstrap-sec-repo (or so) that injects it?

>> Not sure anymore why I added:
>> --include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer
>>
>> apt-transport-https might be required to support https repositories in
>> sources list.
> 
> Yes, old apt versions (1.4.9 and earlier) require that package. It is since a
> dummy package.


Yay.

>> apt-transport-tor might be required to support tor+https and .onion in
>> sources list.
> 
> Yes, but mmdebstrap auto-detects tor URLs and adds the package. This behaviour
> is also documented in its man page.


Magic. :)

#

When mmdebstrap finished, there is still a leftover.

/etc/apt/apt.conf.d/99mmdebstrap

My apt options are good during build (apt cache etc.) but bad in the
final VM image.

Should this file be deleted?

#

mmdebstrap fails when /etc/hostname is missing. An empty /etc/hostname
works for me. Sometimes it's not wanted to leak any host files into the
folder (reproducible builds, privacy, and whatnot). Could you please
have mmdebstrap handle non-existing /etc/hostname (and other system
files (/etc/host /etc/resolv.conf?) gracefully?

#

minor:

>From home folder (in a Qubes Debian VM):

./mmdebstrap --include=apt --variant=buildd --force-check-gpg buster
./test https://deb.debian.org/debian

I: The option --force-check-gpg is a no-op. It only exists for
compatibility with some debootstrap wrappers.
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
mkdir /home/user/test: Permission denied at ./mmdebstrap line 992.

ls -la

drwxr-xr-x  2 10 10   4096 Sep 15 06:07 test

#

minor:

> I: The option --force-check-gpg is a no-op. It only exists for
compatibility with some debootstrap wrappers.


Not sure that implies insecurity. I know gpg signatures are verified but
could confuse others. Perhaps just drop that option from output. Keep it
in man page / command line help only. Users / wrappers using
--force-check-gpg get what they expect anyhow. No need to notify.

Cheers,
Patrick

Bug#940301: mono-runtime: circular dependency hell

[Bill Allombert]

Package: mono-runtime
Version: 5.18.0.240+dfsg-5
Severity: important

Hello Debian Mono Group,

There is a circular dependency between mono-runtime, libmono-corlib4.5-cil, 
libmono-security4.0-cil, libmono-system-configuration4.0-cil, 
libmono-system-core4.0-cil, libmono-system-numerics4.0-cil, 
libmono-system-security4.0-cil, libmono-system-xml4.0-cil, 
libmono-system4.0-cil, mono-4.0-gac, mono-gac, mono-runtime-common and 
mono-runtime-sgen:

mono-runtime:Depends: mono-runtime-sgen (= 5.18.0.240+dfsg-5)
libmono-corlib4.5-cil   :Depends: mono-runtime (>= 5.18.0.240), mono-runtime 
(<< 5.18.0.241)
libmono-security4.0-cil :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system4.0-cil (>= 5.18.0.240)
libmono-system-configuration4.0-cil :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system-security4.0-cil (>= 5.18.0.240), 
libmono-system-xml4.0-cil (>= 4.6.1.3), libmono-system4.0-cil (>= 5.18.0.240), 
mono-runtime (>= 5.18.0.240), mono-runtime (<< 5.18.0.241)
libmono-system-core4.0-cil  :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system4.0-cil (>= 5.18.0.240), mono-runtime-common (>= 
5.18.0.240+dfsg)
libmono-system-numerics4.0-cil  :Depends: libmono-corlib4.5-cil (>= 5.18.0.240)
libmono-system-security4.0-cil  :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system-core4.0-cil (>= 5.18.0.240), 
libmono-system-numerics4.0-cil (>= 5.16.0.220), libmono-system-xml4.0-cil (>= 
4.6.1.3), libmono-system4.0-cil (>= 5.18.0.240)
libmono-system-xml4.0-cil   :Depends: libmono-corlib4.5-cil (>= 
5.18.0.240), libmono-system-configuration4.0-cil (>= 4.0.0~alpha1), 
libmono-system4.0-cil (>= 5.18.0.240)
libmono-system4.0-cil   :Depends: libmono-corlib4.5-cil (>= 5.18.0.240), 
libmono-security4.0-cil (>= 4.6.1.3), libmono-system-configuration4.0-cil (>= 
4.0.0~alpha1), libmono-system-core4.0-cil (>= 5.18.0.240), 
libmono-system-xml4.0-cil (>= 4.6.1.3), mono-runtime (>= 5.18.0.240), 
mono-runtime-common (>= 5.18.0.240+dfsg), mono-runtime (<< 5.18.0.241)
mono-4.0-gac:Depends: libmono-corlib4.5-cil (>= 5.18.0.240), 
libmono-security4.0-cil (>= 4.6.1.3), libmono-system-security4.0-cil (>= 
5.18.0.240), libmono-system4.0-cil (>= 5.18.0.240)
mono-gac:Depends: mono-4.0-gac (= 5.18.0.240+dfsg-5)
mono-runtime-common :Depends: mono-gac (= 5.18.0.240+dfsg-5)
mono-runtime-sgen   :Depends: mono-runtime-common (= 5.18.0.240+dfsg-5)

Complex circular dependencies are known to cause problems during upgrade, so we
should try to get rid of them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940298: debhelper: Should we use meson --native-file ?

[Niels Thykier]

Package: debhelper
Version: 12.5.4
Severity: important

Hi,

I think it is time for a reboot of #919117, comment #20 if we want this for 
bullseye:

"""
On Sun, Jan 13, 2019 at 12:42 AM Helmut Grohne  wrote:

> I think this discrepancy is a design bug in Meson. Meson should either
> use environment variables or not. For native compilation, you can simply
> use a native file. Artificially handling things differently just makes
> cross compilation unnecessarily hard.

Using only native and cross files is exactly the thing that we want to
do and are working towards. Sadly it is likely that we will never be
able to get rid of the envvar support. For all the gory details see
for example:

https://github.com/mesonbuild/meson/issues/4664
"""

AFAICT, it would just be a question of doing:

"""
/usr/share/meson/debcrossgen -a"$DEB_BUILD_ARCH" -o"$DIR/meson-native-file.conf"
/usr/share/meson/debcrossgen -a"$DEB_HOST_ARCH" -o"$DIR/meson-cross-file.conf"
meson --native-file "$DIR/meson-native-file.conf" --cross-file 
"$DIR/meson-cross-file.conf" ...
"""

OR does it need a special case for cross-building vs. native?

"""
/usr/share/meson/debcrossgen -a"$DEB_BUILD_ARCH" -o"$DIR/meson-native-file.conf"
if (is_cross_compiling()) {
  /usr/share/meson/debcrossgen -a"$DEB_HOST_ARCH" -o"$DIR/meson-cross-file.conf"
  meson --native-file "$DIR/meson-native-file.conf" --cross-file 
"$DIR/meson-cross-file.conf" ...
} else {
  meson --native-file "$DIR/meson-native-file.conf" ...
}
"""

@Helmut, @Jussi:

 * Do we agree on the above approach?

 * Do you see any issues with this approach?

AFAIUI, the advantage is that we will use the same code path for
native and cross-building plus the meson upstream prefer this approach
over status-quo.

Thanks,
~Niels

Bug#940300: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream

[Julien Puydt]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm


The newer versions of the minetest game have better than what it provides

It's abandoned upstream.

This package has no rdeps.

I'm the package maintainer (within the Debian Games Team), and I'm
proposing to drop it off Debian testing (and unstable, with another bug
report).

JP

Bug#940299: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream

[Julien Puydt]

Package: ftp.debian.org

The newer versions of the minetest game have better than what it provides

It's abandoned upstream.

This package has no rdeps.

I'm the package maintainer (within the Debian Games Team), and I'm
proposing to drop it off Debian unstable (and testing, with another bug
report).

JP

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

[Jonas Smedegaard]

Quoting Johannes Schauer (2019-09-14 18:26:57)
> Hi,
> 
> Quoting Patrick Schleizer (2019-09-14 08:00:00)
> > cowbuilder (or pbuilder?) calls debootstrap with:
> > 
> > + args='--include=apt --variant=buildd --force-check-gpg buster 
> > /var/cache/pbuilder/base.cow_amd64 http://HTTPS///deb.debian.org/debian'
> > 
> > I.e. it is possible to pass an apt repository URI through command line
> > (above last argument).
> > 
> > However, I am translating that in the wrapper to:
> > 
> > --verbose --architectures=amd64
> > --aptopt=/home/user/whonix_binary/aptgetopt.conf
> > --include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer
> > buster /var/cache/pbuilder/base.cow_amd64
> > /home/user/Whonix/build_sources/debian_stable_current_clearnet.list
> > 
> > Using a file
> > /home/user/Whonix/build_sources/debian_stable_current_clearnet.list
> > which contains both, Debian "standard" repository as well as Debian
> > security repository.
> > 
> > This is to make use of mmdebstrap excellent security feature to
> > bootstrap from two repositories at once. If the APT version in Debian
> > "standard" repository had a vulnerability, then the vulnerable version
> > would be installed first before vulnerable APT would be used to upgrade
> > in a later step from Debian security repository.
> > 
> > "Incompatibility" is perhaps a far stretched term. How do we "teach"
> > grml-debootstrap, cowbuilder (or pbuilder?) "use both, Debian "standard"
> > repository and Debian security repository when using mmdebstrap"?
> > 
> > It's like "the ecosystem does not take advantage of mmdebstrap" yet.
> 
> Okay, but as far as I can see there is nothing that can be done in 
> mmdebstrap about this, right?

If mmdebstrap were to support curl-style URL expansion, then current 
wrappers for debootstrap supporting only a single string could be abused 
to pass an expandable set of strings, like this:

Perhaps mmdebstrab could support curl-style glob expansion of URLs + 
suite splitting, to allow passing multiple apt lines through wrappers 
which expects only a single base URL, like this:

  
https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}

expanding to this:

  https://deb.debian.org/debian buster
  https://deb.debian.org/debian buster-updates
  https://security.debian.org/debian-security buster/updates

Here's a quick one-line that maybe better explains what I mean:

echo 
'https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}'
 | perl -MFile::Glob=:bsd_glob -nE 'say map { s,/dists/, ,r } bsd_glob($_, 
GLOB_BRACE | GLOB_NOMAGIC )'


 - Jonas

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

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


signature.asc
Description: signature

Bug#940302: dmeventd has circular Depends on liblvm2cmd2.03

[Bill Allombert]

Package: dmeventd
Version: 2:1.02.155-3
Severity: important

Hello Debian LVM Team,

There is a circular dependency between dmeventd and liblvm2cmd2.03:

dmeventd:Depends: liblvm2cmd2.03 (>= 2.03.02)
liblvm2cmd2.03  :Depends: dmeventd

Circular dependencies involving shared libraries are known to cause problems
during upgrade between stable releases, so we should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940303: libreoffice-common: circular dependency hell

[Bill Allombert]

Package: libreoffice-common
Version: 1:6.3.1-1
Severity: important

Hello Debian LibreOffice Maintainers,

There is a circular dependency between libreoffice-common,
libreoffice-style-colibre and libreoffice-style-tango:

libreoffice-common  :Depends: libreoffice-style-colibre, 
libreoffice-style-tango
libreoffice-style-colibre   :Depends: libreoffice-common (= 1:6.3.1-1)
libreoffice-style-tango :Depends: libreoffice-common (= 1:6.3.1-1)

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940298: debhelper: Should we use meson --native-file ?

[Niels Thykier]

(Forgot to X-Debugs-CC Helmut and Jussi)

Niels Thykier:
> Package: debhelper
> Version: 12.5.4
> Severity: important
> 
> Hi,
> 
> I think it is time for a reboot of #919117, comment #20 if we want this for 
> bullseye:
> 
> """
> On Sun, Jan 13, 2019 at 12:42 AM Helmut Grohne  wrote:
> 
>> I think this discrepancy is a design bug in Meson. Meson should either
>> use environment variables or not. For native compilation, you can simply
>> use a native file. Artificially handling things differently just makes
>> cross compilation unnecessarily hard.
> 
> Using only native and cross files is exactly the thing that we want to
> do and are working towards. Sadly it is likely that we will never be
> able to get rid of the envvar support. For all the gory details see
> for example:
> 
> https://github.com/mesonbuild/meson/issues/4664
> """
> 
> AFAICT, it would just be a question of doing:
> 
> """
> /usr/share/meson/debcrossgen -a"$DEB_BUILD_ARCH" 
> -o"$DIR/meson-native-file.conf"
> /usr/share/meson/debcrossgen -a"$DEB_HOST_ARCH" -o"$DIR/meson-cross-file.conf"
> meson --native-file "$DIR/meson-native-file.conf" --cross-file 
> "$DIR/meson-cross-file.conf" ...
> """
> 
> OR does it need a special case for cross-building vs. native?
> 
> """
> /usr/share/meson/debcrossgen -a"$DEB_BUILD_ARCH" 
> -o"$DIR/meson-native-file.conf"
> if (is_cross_compiling()) {
>   /usr/share/meson/debcrossgen -a"$DEB_HOST_ARCH" 
> -o"$DIR/meson-cross-file.conf"
>   meson --native-file "$DIR/meson-native-file.conf" --cross-file 
> "$DIR/meson-cross-file.conf" ...
> } else {
>   meson --native-file "$DIR/meson-native-file.conf" ...
> }
> """
> 
> @Helmut, @Jussi:
> 
>  * Do we agree on the above approach?
> 
>  * Do you see any issues with this approach?
> 
> AFAIUI, the advantage is that we will use the same code path for
> native and cross-building plus the meson upstream prefer this approach
> over status-quo.
> 
> Thanks,
> ~Niels
> 

Bug#940304: ITP: r-cran-randomglm -- Random General Linear Model Prediction

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-randomglm -- Random General Linear Model Prediction
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-randomglm
  Version : 1.02
  Upstream Author : Lin Song
* URL : https://cran.r-project.org/package=randomGLM
* License : GPL-2+
  Programming Lang: GNU R
  Description : Random General Linear Model Prediction
 The package implements a bagging predictor based on
 general linear models

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-randomglm

Bug#940305: debian-edu-artwork has circular Depends on debian-edu-artwork-buster|debian-edu-artwork-lines|debian-edu-artwork-softwaves

[Bill Allombert]

Package: debian-edu-artwork
Version: 2.10.5-2
Severity: important

Hello Debian Edu Developers,

There is a circular dependency between debian-edu-artwork and 
debian-edu-artwork-buster|debian-edu-artwork-lines|debian-edu-artwork-softwaves:

debian-edu-artwork  :Depends: debian-edu-artwork-buster | 
debian-edu-artwork-softwaves | debian-edu-artwork-lines
debian-edu-artwork-buster   :Depends: debian-edu-artwork
debian-edu-artwork-lines:Depends: debian-edu-artwork
debian-edu-artwork-softwaves:Depends: debian-edu-artwork

Circular dependencies are known to cause problems during upgrade,
so we should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940306: uscan: Missing argument in sprintf at /usr/share/perl5/Devscripts/MkOrigtargz.pm

[Yann Dirson]

Package: devscripts
Version: 2.19.5+deb10u1
Severity: normal

In the case where a .tar url does not really point to a tarfile, uscan
does report the problem, but only after a printf error.

Additionally, it does not keep the downloaded file, which forces manual
re-download to check what really happenned.

yann@home:jam-2.6$ uscan
uscan: Newest version of jam on remote site is 2.6.1, local version is
2.6
uscan:=> Newer package available from
  
https://swarm.workshop.perforce.com/projects/perforce_software-jam/files/main/jam-2.6.1.tar
Missing argument in sprintf at /usr/share/perl5/Devscripts/MkOrigtargz.pm line 
575.
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
uscan: error: tar --list --auto-compress --file ../jam_2.6.1.orig.tar.
subprocess returned exit status 2
yann@home:jam-2.6$ file jam-2.6.1.tar
jam-2.6.1.tar: cannot open `jam-2.6.1.tar' (No such file or directory)
yann@home:jam-2.6$ wget 
https://swarm.workshop.perforce.com/projects/perforce_software-jam/files/main/jam-2.6.1.tar
--2019-09-15 13:26:56-- 
https://swarm.workshop.perforce.com/projects/perforce_software-jam/files/main/jam-2.6.1.tar
Resolving swarm.workshop.perforce.com (swarm.workshop.perforce.com)...
107.1.244.153
Connecting to swarm.workshop.perforce.com
(swarm.workshop.perforce.com)|107.1.244.153|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘jam-2.6.1.tar’

jam-2.6.1.tar   [ <=> ]   8.72K  --.-KB/s   
 in 0.001s

2019-09-15 13:26:57 (16.9 MB/s) - ‘jam-2.6.1.tar’ saved [8932]

yann@home:jam-2.6$ file jam-2.6.1.tar
jam-2.6.1.tar: HTML document, ASCII text, with very long lines




-- Package-specific info:

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

--- ~/.devscripts ---
DEBSIGN_KEYID=74AF05DDD92027F5F0C3CDD50D85F29625A3F9FD
DGET_UNPACK=no
DEBDIFF_SHOW_MOVED=yes

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (900, 'testing'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

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

Versions of packages devscripts recommends:
ii  apt 1.8.2
ii  at  3.1.23-1
ii  curl7.64.0-4
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.02.25
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.16-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.15.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-3+deb10u1
ii  python3-apt 1.8.4
ii  python3-debian  0.1.35
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-23+deb10u1
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate 0.15.2
ii  autopkgtest  5.10
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1
ii  build-essential  12.6
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.1.1
ii  devscripts-el40.3
ii  diffoscope   113
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.2.6+df

Bug#940307: libevent - excessive-priority-for-library-package

[Bastian Blank]

Source: libevent
Severity: normal

The library package libevent-2.1-6 (and the newly uploaded
libevent-2.1-7) have exessive priority defined.  Please change to
"normal".  I've overriden it while accepting from NEW.

See https://lintian.debian.org/tags/excessive-priority-for-library-package.html

Regards,
Bastian

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

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

Bug#940303: libreoffice-common: circular dependency hell

[Rene Engelhard]

reassign 940303 
libreoffice-common,libreoffice-style-colibre,libreoffice-style-tango
severity 940303 normal
retitle 940303 libreoffice-common: circular dependency between -common
and -style-{colibre,tango}
tag 940303 + wontfix
thanks

Hi,

can you use some sane title instead of just accusing people directly
there?

On Sun, Sep 15, 2019 at 01:33:05PM +0200, Bill Allombert wrote:
> Package: libreoffice-common
> Version: 1:6.3.1-1
> Severity: important

No.

> There is a circular dependency between libreoffice-common,
> libreoffice-style-colibre and libreoffice-style-tango:
> 
> libreoffice-common:Depends: libreoffice-style-colibre, 
> libreoffice-style-tango

Of course it does. LO needs icons.

> libreoffice-style-colibre :Depends: libreoffice-common (= 1:6.3.1-1)
> libreoffice-style-tango   :Depends: libreoffice-common (= 1:6.3.1-1)

And of couse the icons need LO to make sense, and far more important,
due to dh_linkdocs to save space -common is even needed to have
/usr/share/doc (and that one is mandated by policy).

> Complex circular dependencies are known to cause problems during upgrade, so 
> we
> should try to avoid them.

If you need stuff during the upgrade. You don't need icons during
a upgrade. And when the upgrade is done you have a consistent thing.

Please file bugs on stuff really having a problem with this. This one
does not.

Regards,

Rene

Bug#940286: golang-github-anacrolix-missinggo-dev has circular Depends on golang-github-anacrolix-tagflag-dev

[Drew Parsons]

Package: golang-github-anacrolix-missinggo-dev
Version: 2.1.0-4
Followup-For: Bug #940286

That's correct, the circular dependency is in fact present in the two
packages.

In missinggo,  cmd/filecache/main.go and cmd/http-file-server/main.go
use tagflag.Parse.

In tagflag, parser.go and usage.go use missinggo/slices.

The situation is uncomfortable, but I do not anticipate it will cause
problems in practice.  tagflag is source-only, missinggo only needs it
to be present in the GOPATH, and vice versa.

There is no operational circular dependency in the actual files
involved, i.e. missinggo/slices (required by tagflags) is not the part
of missinggo that depends on tagflags.

missinggo is a collection of various miscellaneous functions, not a
library with a specific capability.  Not all functions are related to
one other.

The alternative is to patch missinggo/slices into tagflag.  This is
easy to do with Go using vendor directories.  This is how I bootstrapped
tagflag.  But now that missinggo itself is available, it doesn't seem
constructive to continue the vendor bootstrap.  It's a worse option
than tolerating the circular dependency, I think.

Bug#940309: tmux: Random segfaults

[Kamil Jonca]

Package: tmux
Version: 2.9a-3
Severity: important

At random moments tmux segfaults, destroying all sessions.
in dmesg we have:

[173131.642689] tmux: server[3258]: segfault at e1 ip 56262a6221a4 sp 
7ffccc134c30 error 6 in tmux[56262a5eb000+6]
[173131.642703] Code: 48 c7 85 30 01 00 00 00 00 00 00 89 45 00 41 8b 47 1c 48 
c1 e0 04 48 03 47 18 bf 01 00 00 00 48 8b 50 08 48 89 95 38 01 00 00 <48> 89 2a 
48 8d 95 30 01 00 00 48 89 50 08 e8 79 55 02 00 8b 55 08

KJ

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

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

Versions of packages tmux depends on:
ii  libc6   2.29-1
ii  libevent-2.1-6  2.1.8-stable-4
ii  libtinfo6   6.1+20190803-1
ii  libutempter01.1.6-3+b1

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

Bug#940308: picard: new release 2.2

[Cord Beermann]

Package: picard
Version: 2.1.3-2
Severity: wishlist

New release available. 

https://picard.musicbrainz.org/changelog/

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-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)
LSM: AppArmor: enabled

Versions of packages picard depends on:
ii  libc6 2.29-1
ii  libchromaprint-tools  1.4.3-3
ii  python3   3.7.3-1
ii  python3-libdiscid 1.0-5
ii  python3-mutagen   1.40.0-2
ii  python3-pyqt5 5.12.3+dfsg-2

picard recommends no packages.

Versions of packages picard suggests:
ii  hicolor-icon-theme  0.17-2

-- debconf-show failed

Bug#940303: libreoffice-common: circular dependency hell

[Bill Allombert]

On Sun, Sep 15, 2019 at 01:51:38PM +0200, Rene Engelhard wrote:
> can you use some sane title instead of just accusing people directly
> there?

Hello Rene!

I did not plan to accuse anybody. 
Are you objecting to the vocable 'dependency hell' ?

> > libreoffice-style-colibre   :Depends: libreoffice-common (= 1:6.3.1-1)
> > libreoffice-style-tango :Depends: libreoffice-common (= 1:6.3.1-1)
> 
> And of couse the icons need LO to make sense, and far more important,
> due to dh_linkdocs to save space -common is even needed to have
> /usr/share/doc (and that one is mandated by policy).

Policy allows to use separate
/usr/share/doc/libreoffice-common
/usr/share/doc/libreoffice-style-colibre and
/usr/share/doc/libreoffice-style-tango
directories which are not symlinks and copy the copyright file instead
and this way you do not have to add an unnecessary dependency.

The provision for the symlink in policy should not be seen as a
justification for unnecessary dependencies.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

[Johannes Schauer]

Quoting Patrick Schleizer (2019-09-15 13:16:00)
> Happy to report that both invocations of grml-debootstrap and pbuilder /
> cowbuilder are compatible with mmdebstrap.

Cool!

> >> Using a file
> >> /home/user/Whonix/build_sources/debian_stable_current_clearnet.list which
> >> contains both, Debian "standard" repository as well as Debian security
> >> repository.
> >>
> >> This is to make use of mmdebstrap excellent security feature to
> >> bootstrap from two repositories at once. If the APT version in Debian
> >> "standard" repository had a vulnerability, then the vulnerable version
> >> would be installed first before vulnerable APT would be used to upgrade
> >> in a later step from Debian security repository.
> >>
> >> "Incompatibility" is perhaps a far stretched term. How do we "teach"
> >> grml-debootstrap, cowbuilder (or pbuilder?) "use both, Debian "standard"
> >> repository and Debian security repository when using mmdebstrap"?
> >>
> >> It's like "the ecosystem does not take advantage of mmdebstrap" yet.
> > 
> > Okay, but as far as I can see there is nothing that can be done in 
> > mmdebstrap
> > about this, right?
> Maybe not.
> 
> I guess the problem indeed isn't mmdebstrap but how other tools are
> invoking $DEBOOTSTRAP.
> 
> Do you think you could contact pbuilder / cowbuilder / grml-debootstrap
> to see how invocation of debootstrap (single repository) vs mmdebstrap
> (Debian "standard" repository + Debian security repository) invocation
> could be sorted out?
> 
> Not sure how crazy would it be to have mmdebstrap auto inject the Debian
> security repository? Perhaps keep mmdebstrap as is but have a wrapper
> mmdebstrap-sec-repo (or so) that injects it?

Maybe I'm not understanding the problem yet. Mmdebstrap currently does
automatically inject the updates and security mirrors if you specify "stable"
or a stable release name on the command line. If you specify a sources.list
file, then it will not do so automatically because then presumably you want to
take full control yourself. Why would you want a wrapper? Do you need to create
your own sources.list file? Why?

> #
> 
> When mmdebstrap finished, there is still a leftover.
> 
> /etc/apt/apt.conf.d/99mmdebstrap
> 
> My apt options are good during build (apt cache etc.) but bad in the
> final VM image.
> 
> Should this file be deleted?

You probably added some custom --aptopt options in your mmdebstrap invocation?
That file contains all your custom options. Are you suggesting to name that
file differently? If you delete that file, then you also loose the apt options
you passed.

> #
> 
> mmdebstrap fails when /etc/hostname is missing. An empty /etc/hostname
> works for me. Sometimes it's not wanted to leak any host files into the
> folder (reproducible builds, privacy, and whatnot). Could you please
> have mmdebstrap handle non-existing /etc/hostname (and other system
> files (/etc/host /etc/resolv.conf?) gracefully?

That's a very good point! I pushed a new commit which will only copy
/etc/hostname and /etc/resolv.conf if they exist. /etc/host isn't used.

> #
> 
> minor:
> 
> From home folder (in a Qubes Debian VM):
> 
> ./mmdebstrap --include=apt --variant=buildd --force-check-gpg buster
> ./test https://deb.debian.org/debian
> 
> I: The option --force-check-gpg is a no-op. It only exists for
> compatibility with some debootstrap wrappers.
> I: automatically chosen mode: unshare
> I: chroot architecture amd64 is equal to the host's architecture
> mkdir /home/user/test: Permission denied at ./mmdebstrap line 992.
> 
> ls -la
> 
> drwxr-xr-x  2 10 10   4096 Sep 15 06:07 test

This is weird. Resolving this could be more complex. I suspect some weird
interaction between your VM and unshare. Maybe you should open a specific bug
about this issue because I need to know more details.

> #
> 
> minor:
> 
> > I: The option --force-check-gpg is a no-op. It only exists for
> compatibility with some debootstrap wrappers.
> 
> 
> Not sure that implies insecurity. I know gpg signatures are verified but
> could confuse others. Perhaps just drop that option from output. Keep it
> in man page / command line help only. Users / wrappers using
> --force-check-gpg get what they expect anyhow. No need to notify.

I don't understand where the confusion is here? Could you elaborate?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#940303: libreoffice-common: circular dependency hell

[Rene Engelhard]

Hi,

On Sun, Sep 15, 2019 at 02:14:39PM +0200, Bill Allombert wrote:
> On Sun, Sep 15, 2019 at 01:51:38PM +0200, Rene Engelhard wrote:
> > can you use some sane title instead of just accusing people directly
> > there?
> 
> Hello Rene!
> 
> I did not plan to accuse anybody. 
> Are you objecting to the vocable 'dependency hell' ?

Yes.

> > > libreoffice-style-colibre :Depends: libreoffice-common (= 
> > > 1:6.3.1-1)
> > > libreoffice-style-tango   :Depends: libreoffice-common (= 1:6.3.1-1)
> > 
> > And of couse the icons need LO to make sense, and far more important,
> > due to dh_linkdocs to save space -common is even needed to have
> > /usr/share/doc (and that one is mandated by policy).
> 
> Policy allows to use separate
> /usr/share/doc/libreoffice-common
> /usr/share/doc/libreoffice-style-colibre and
> /usr/share/doc/libreoffice-style-tango
> directories which are not symlinks and copy the copyright file instead
> and this way you do not have to add an unnecessary dependency.

True.
But this is done for all other _all packages and a exception just for
those can get confusing.

> The provision for the symlink in policy should not be seen as a
> justification for unnecessary dependencies.

And what are you going to do with icons without the rest of LO?

OK; I could recommend it...

Regards,

Rene

Bug#938804: vtk6: Python2 removal in sid/bullseye

[peter green]

severity 938804 serious
thanks

python-vtk6 depends on the python-autobahn binary package which has already 
been dropped by the python-autobahn source package.

Bug#935526: pulseaudio: Pulseaudio no longer recognizes USB devices

[Guus Sliepen]

On Mon, Sep 09, 2019 at 08:53:46PM -0300, Felipe Sateler wrote:

> Could you please attach a verbose log of pulseaudio, both versions?
> https://wiki.ubuntu.com/PulseAudio/Log

Attached are the logs from both versions. Let me know if I need to
provide any other information.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


pulseverbose-12.2-4.log.gz
Description: application/gzip


pulseverbose-12.99.2-1.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#940312: /etc/issue: /etc/issue is being updated by Debian when it doesn't need to

[Ben Wong]

Package: base-files
Version: 10.3+deb10u1
Severity: normal
File: /etc/issue
Tags: patch

Dear Maintainer,

When upgrading to Debian Buster, I noticed that Debian had updated
/etc/issue to include the version number ("Debian GNU/Linux 10").
There is no reason for this since that data is already included in
/etc/os-release.

$ cat /etc/os-release

  PRETTY_NAME="Debian GNU/Linux 10 (buster)"
  NAME="Debian GNU/Linux"
  VERSION_ID="10"
  VERSION="10 (buster)"
  VERSION_CODENAME=buster
  ID=debian
  HOME_URL="https://www.debian.org/";
  SUPPORT_URL="https://www.debian.org/support";
  BUG_REPORT_URL="https://bugs.debian.org/";


Here is a version of /etc/issue which will show the "PRETTY_NAME":

\S \n \l


Please use that instead of hardcoding it to a specific release. That
way, those of us who like to customize our /etc/issue won't get
conflict errors next time we upgrade.

Thank you.




-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-9-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 base-files depends on:
ii  gawk [awk]  1:4.1.4+dfsg-1
ii  mawk [awk]  1.3.3-17+b3

base-files recommends no packages.

base-files suggests no packages.

-- Configuration Files:
/etc/issue changed:
\S (\r)
Welcome to \n.\O \l@\b \t

-- no debconf information
--- issue.dpkg-dist 2019-08-30 05:31:26.0 -0700
+++ issue   2019-09-15 05:47:19.463694363 -0700
@@ -1,2 +1,2 @@
-Debian GNU/Linux 10 \n \l
+\S \n \l
 

Bug#940310: merge with lockdown / security-misc?

[Patrick Schleizer]

Package: lockdown
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Let's join forces before we independently reinvent everything. :)

* https://packages.debian.org/buster/lockdown
* https://packages.debian.org/buster/hardening-runtime
* https://github.com/Whonix/security-misc

Bug#940311: merge with lockdown / security-misc?

[Patrick Schleizer]

Package: hardening-runtime
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

We now have (at least) three very similar packages.

* https://packages.debian.org/buster/lockdown
* https://packages.debian.org/buster/hardening-runtime
* https://github.com/Whonix/security-misc

Let's join forces before we independently reinvent everything. :)

Cheers,
Patrick

Bug#940234: debian-policy: add a section about source reproducibility

[Holger Levsen]

On Sat, Sep 14, 2019 at 11:57:43PM +0200, Guillem Jover wrote:
> > >> I haven't checked how many packages do not fulfill this condition
> > > please do check. last (and only) time we (=r-b) looked, it wasn't
> > > practical at all. this was around 5 years ago, but I don't remember any
> > > work done on improving this.
> Back when we were fixing the binary package reproducible problems
> within dpkg, I also checked the source side, and fixed a few
> problematic cases. Assuming the same tools installed as defined in
> the .buildinfo file, and the same content in the unpacked source
> tree, dpkg-source should be producing the same output source packages.

oh, cool, thanks for this spreading this information!

> If this does not hold, I'd consider it a bug to be fixed.

great!

so now someone just needs to do something^wa rebuild of say 1000 source
packages and share the stats...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#940313: python3-osprofiler fails to install

[peter green]

Package: python3-osprofiler
Version: 2.6.0-1
Severity: grave

python3-osprofiler fails to install, I first noticed this in an autopkgtest, 
but I was able to reproduce it in a local sid chroot too.


Setting up python3-osprofiler (2.6.0-1) ...
update-alternatives: error: alternative path /usr/bin/python3-osprofiler 
doesn't exist
dpkg: error processing package python3-osprofiler (--configure):
  installed python3-osprofiler package post-installation script subprocess 
returned error exit status 2

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

[Johannes Schauer]

Hi,

Quoting Jonas Smedegaard (2019-09-15 13:18:18)
> If mmdebstrap were to support curl-style URL expansion, then current 
> wrappers for debootstrap supporting only a single string could be abused 
> to pass an expandable set of strings, like this:
> 
> Perhaps mmdebstrab could support curl-style glob expansion of URLs + 
> suite splitting, to allow passing multiple apt lines through wrappers 
> which expects only a single base URL, like this:
> 
>   
> https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}
> 
> expanding to this:
> 
>   https://deb.debian.org/debian buster
>   https://deb.debian.org/debian buster-updates
>   https://security.debian.org/debian-security buster/updates
> 
> Here's a quick one-line that maybe better explains what I mean:
> 
> echo 
> 'https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}'
>  | perl -MFile::Glob=:bsd_glob -nE 'say map { s,/dists/, ,r } bsd_glob($_, 
> GLOB_BRACE | GLOB_NOMAGIC )'
> 

what I still don't understand is why this would be needed.

Currently, if you do:

mmdebstrap buster ./output-directory

Then the resulting sources.list will be equal to what you wrote above.

Maybe I'm just dumb here but could either of you please go back to the start
and try to explain precisely what it is, that you think is missing from
mmdebstrap and why you need it?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#940028: launching d-i on multiple consoles doesn't play well with preseeding

[Cyril Brulebois]

Hi Sergio,

Sergio Gelato  (2019-09-11):
> This seems to be new behaviour since stretch, introduced in version 1.128 of
> package rootskel.

From the rest of your mail I'm assuming you meant buster here.

> I suspect that the two debian-installer instances are racing each
> other. To confirm this, I unpacked initrd.gz, made a simple change to
> sbin/reopen-console (adding inittab entries only for cons in
> $preferred instead of for cons in $consoles), repacked, and run an
> installation again with much better results (no more questions from
> localechooser).
> 
> I do appreciate that for interactive d-i use it's nice to have it show
> up on all consoles; but not at the expense of breaking fully automated
> installation.

Agreed. You're not the only one reporting such issues, and I'd really
like feature authors to fix the regression they introduced. That's not
the first time steal-ctty appears in bug report.


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


signature.asc
Description: PGP signature

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

[Jonas Smedegaard]

Quoting Johannes Schauer (2019-09-15 14:58:55)
> Quoting Jonas Smedegaard (2019-09-15 13:18:18)
> > If mmdebstrap were to support curl-style URL expansion, then current 
> > wrappers for debootstrap supporting only a single string could be 
> > abused to pass an expandable set of strings, like this:
> > 
> > Perhaps mmdebstrab could support curl-style glob expansion of URLs + 
> > suite splitting, to allow passing multiple apt lines through 
> > wrappers which expects only a single base URL, like this:
> > 
> >   
> > https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}
> > 
> > expanding to this:
> > 
> >   https://deb.debian.org/debian buster
> >   https://deb.debian.org/debian buster-updates
> >   https://security.debian.org/debian-security buster/updates
> > 
> > Here's a quick one-line that maybe better explains what I mean:
> > 
> > echo 
> > 'https://{deb.debian.org/debian/dists/{buster,buster-updates},security.debian.org/debian-security/dists/buster/updates}'
> >  | perl -MFile::Glob=:bsd_glob -nE 'say map { s,/dists/, ,r } bsd_glob($_, 
> > GLOB_BRACE | GLOB_NOMAGIC )'
> > 
> 
> what I still don't understand is why this would be needed.
> 
> Currently, if you do:
> 
> mmdebstrap buster ./output-directory
> 
> Then the resulting sources.list will be equal to what you wrote above.
> 
> Maybe I'm just dumb here but could either of you please go back to the 
> start and try to explain precisely what it is, that you think is 
> missing from mmdebstrap and why you need it?

Builtin default of mmdebstrap is nice.

Various debootstrap wrappers exist which supports replacing debootstrap 
with an alternative command (e.g. cdebootstrap) but they commonly do not 
support passing arbitrary commandline arguments.

What I (and we, I guess) want is that the nice default be overridable, 
not only by passing options different from debootstrap but also in a way 
supported by these pre-existing debootstrap wrappers.

Example: Bootstrapping a system omitting security updates e.g. because 
an updated linux kernel is broken on my special setup.

Example: Bootstrapping a system additionally including backports.d.o.

Example: Bootstrapping a system additionally including my custom addons.


 - Jonas

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

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


signature.asc
Description: signature

Bug#874907: [hydrogen] Future Qt4 removal from Buster

[Jonas Smedegaard]

[sent again, avoiding UTF-8 mail header upsetting Debian mailhost]

Quoting Lisandro Damián Nicanor Pérez Meyer (2019-09-12 23:54:32)
> On Thu, 12 Sep 2019 at 17:37, Lisandro Damián Nicanor Pérez Meyer
>  wrote:
> >
> > On Mon, 30 Jul 2018 19:01:50 +0200 Reiner Herrmann  
> > wrote:
> > > Control: tags -1 + fixed-upstream
> > >
> > > The current upstream beta release supports Qt5.
> > > https://github.com/hydrogen-music/hydrogen/releases/tag/1.0.0-beta1
> >
> > I'll see if I can tackle it during the weekend.
> 
> Uuups, it uses cdbs. I'll prepare the NMU switching to dh. If this is
> not wanted please say so as soon as possible :-)

Thanks for the offer, but please don't if not familiar with CDBS.

I want to migrate to short-form dh but want to to it cautiously.


 - Jonas

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

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


signature.asc
Description: signature

Bug#940314: neo, needs a source-only upload to migrate to testing.

[peter green]

Package: neo
Version: 0.7.2-1
Severity: serious

The release team have decreed that non-buildd binaries can no longer migrate to 
testing. Please make a source-only upload so your package can migrate.

Bug#940315: zope.testrunner autopkgtest failure.

[peter green]

Package: zope.testrunner
Version: 4.4.9-3
Severity: serious


autopkgtest [06:13:47]: test all-2: [---
bash: /tmp/autopkgtest-lxc.v65a_j_9/downtmp/build.cMu/src/debian/tests/all-2: 
/usr/bin/python: bad interpreter: No such file or directory
autopkgtest [06:13:47]: test all-2: ---]
autopkgtest [06:13:47]: test all-2:  - - - - - - - - - - results - - - - - - - 
- - -
all-2FAIL non-zero exit status 126
autopkgtest [06:13:47]: test all-2:  - - - - - - - - - - stderr - - - - - - - - 
- -
bash: /tmp/autopkgtest-lxc.v65a_j_9/downtmp/build.cMu/src/debian/tests/all-2: 
/usr/bin/python: bad interpreter: No such file or directory

It looks like while the package has dropped python2 support, some of the 
autopkgtest stuff is still trying to use it.

Bug#940316: zope.testing autopkgtest failure.

[peter green]

Package: zope.testing
Version: 4.6.2-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/z/zope.testing/2966135/log.gz


autopkgtest [06:13:32]: test all: [---
Traceback (most recent call last):
   File "/usr/bin/zope-testrunner", line 9, in 
 load_entry_point('zope.testrunner==4.4.9', 'console_scripts', 
'zope-testrunner')()
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/__init__.py", line 
27, in run
 failed = run_internal(defaults, args, script_parts=script_parts, cwd=cwd)
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/__init__.py", line 
44, in run_internal
 runner.run()
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/runner.py", line 159, 
in run
 feature.global_setup()
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 479, 
in global_setup
 tests = find_tests(self.runner.options, self.runner.found_suites)
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 168, 
in find_tests
 for suite in found_suites:
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 179, 
in find_suites
 for fpath, package in find_test_files(options):
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 238, 
in find_test_files
 for f, package in find_test_files_(options):
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 266, 
in find_test_files_
 for (p, package) in test_dirs(options, {}):
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 321, 
in test_dirs
 p = import_name(p)
   File "/usr/lib/python2.7/dist-packages/zope/testrunner/find.py", line 395, 
in import_name
 __import__(name)
ImportError: No module named testing



It looks like while the package has dropped python2 support, some of the 
autopkgtest stuff is still trying to use it.

Bug#925518: Sponsored Post Collaboration - planet.ubuntu.com

[Jason Turner]

Hello,

Jason here from Source Global Media  - We are a reputed Digital Marketing
Agency working with variety of clients from UK, USA,  France, Greece,
Finland, Germany and Spain

We are interested in developing partnerships with companies / webmaster
such as yourself to check if you can publish sponsored content for our
clients on your website i.e. - planet.ubuntu.com

If you can publish sponsored content on  planet.ubuntu.com  , please email
us information with prices.

Looking forward to start the business with you.

Best regards,



[image: beacon]

Bug#940309: tmux: Random segfaults

[Romain Francoise]

Hi,

On Sun, Sep 15, 2019 at 2:12 PM Kamil Jonca  wrote:
> At random moments tmux segfaults, destroying all sessions.
> in dmesg we have: [...]

Thanks for the report. Can you try with 3.0-rc4 from experimental?

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

[peter green]

> tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))

Thanks to this hint

This hint was *wrong*, it will introduce garbage into the string and the 
"rotor" code is clearly designed to work with byte strings, not unicode strings.

Change it to

"tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )"

Bug#891993: syrthes-gui uses obsolete libs Qt4 and Python2

[Gilles Filippini]

Hi,

Moritz Mühlenhoff a écrit le 13/09/2019 à 23:18 :
> On Mon, Aug 19, 2019 at 02:12:35AM -0400, Scott Kitterman wrote:
>> On Sat, 03 Mar 2018 21:16:22 +0100 Andreas Beckmann  wrote:
>>> Source: syrthes
>>> Version: 4.3.0-dfsg1-2
>>> Severity: serious
>>> Tags: sid buster
>>> Justification: blocks python-qwt5-qt4 removal
>>> Control: block 886779 with -1
>>>
>>> Hi,
>>>
>>> src:syrthes Build-Depends on python-qwt5-qt4 which is scheduled for
>>> removal (#886779). Please switch to a Qt5 solution or drop the
>>> (Build-)Dependency altogether.
>>>
>>>
>>> Andreas
>>
>> These (along with python-qwt5-qt4) are being removed this cycyle.  Upstream 
>> does not have a Qt5/Python3 release yet.  If the Python3/Qt4 requirements 
>> are 
>> confined to the gui, maybe just that part can be dropped until upstream 
>> releases a version we can support.
> 
> Hi Gilles,
> syrthes is the only remaining packages blocking the removal of pyqwt5. Are
> you planning to port the GUI yourself, should we (temporarily, until fixed)
> drop the syrthes-gui package or if that's not an option, should syrthes be
> (temporarily) removed altogether?

Syrthes' upstream is quite unresponsive. A version 5 should be on its
way but there is no place to download it from and the preview I had more
than one year ago brought many dependencies with unclear licensing.

I think the best option for now would be to just drop syrthes-gui.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#940224: lambda-term: FTBFS with new zed

[Stéphane Glondu]

Le 14/09/2019 à 09:51, Gianfranco Costamagna a écrit :
> Hello, looks like the new zed made the package FTBFS
> [...]
> can you please have a look?

There is a new upstream release of lambda-term presumably fixing that.
Unfortunately, the new lambda-term depends on lwt >= 4 which depends on
ocaml >= 4.08 (unless some compatibility package is introduced which I'd
like to avoid).

This will be fixed during the transition to OCaml >= 4.08.


Cheers,

-- 
Stéphane

Bug#939961: FTBFS with OCaml 4.08.0 (safe strings)

[Stéphane Glondu]

Le 14/09/2019 à 23:12, Andy Li a écrit :
> You package haxe FTBFS with OCaml 4.08.0 because -safe-string is now
> the default. Full log:
> 
>   https://ocaml.debian.net/transitions/ocaml-4.08.0/pool/haxe.log
> 
> 
> The link returns ERR_NAME_NOT_RESOLVED for me. Is it down?

No. But it is IPv6 only.

> Please fix your package so that it compiles with -safe-string. This is
> possible with the version of OCaml currently in unstable (4.05.0).
> 
> 
> The upcoming version of Haxe (4.0.0) will be safe-string compatible, but
> the current version will remain incompatible (difficult to patch).
> I will just add "OCAMLPARAM=safe-string=0,_" as a workaround. Is that okay?

If that works and is temporary, OK.


Cheers,

-- 
Stéphane

Bug#940317: hplip: No more printing

[Nicolas Patrois]

Package: hplip
Version: 3.19.8+dfsg0-1
Severity: important

Dear Maintainer,

I can’t print anymore, neither with a Photosmart 4780 nor with an Envy 5534 (.
Both used to work.
In fact, the jobs seem frozen in the queue.

I send the jobs and immediately, I’m informed that the job has been completed.
It has not been printed.
I checked hp-check and it crashes (see log). Maybe Python 2 to 3 went wrong.
Yet, before crashing, hp-check shows two errors:

 error: gsGhostScript - PostScript and PDF language interpreter and
previewer REQUIRED7.059.28MISSING'gs needs
to be installed'

But gs is installed.

 error: libnetsnmp-devel libnetsnmp-devel - SNMP networking library development
files REQUIRED5.0.9   -   MISSING'libnetsnmp-
devel needs to be installed'

This library seems no more to exist: I can’t find it with apt-cache, apt-file,
aptitude nor dpkg.

n.



-- Package-specific info:
Saving output in log file: /home/nicolas/hp-check.log

HP Linux Imaging and Printing System (ver. 3.19.8)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling 
the HPLIP supplied  
tarball (.tar.gz or .run) to determine if the proper dependencies are installed 
to successfully  
compile HPLIP.  
 
2. Run-time check mode (-r or --run): Use this mode to determine if a distro 
supplied package
(.deb, .rpm, etc) or an already built HPLIP supplied tarball has the proper 
dependencies 
installed to successfully run.  
 
3. Both compile- and run-time check mode (-b or --both) (Default): This mode 
will check both of  
the above cases (both compile- and run-time dependencies).  
 

Check types:
 
a. EXTERNALDEP - External Dependencies  
 
b. GENERALDEP - General Dependencies (required both at compile and run time)
 
c. COMPILEDEP - Compile time Dependencies   
 
d. [All are run-time checks]
 
PYEXT SCANCONF QUEUES PERMISSION
 

Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

Gtk-Message: 16:08:22.387: Failed to load module "atk-bridge"
warning: debian-bullseye/sid version is not supported. Using debian-10.0 
versions dependencies to verify and install...

---
| SYSTEM INFO |
---

 Kernel: 4.17.0-3-686-pae #1 SMP Debian 4.17.17-1 (2018-08-18) GNU/Linux
 Host: nicolas.home
 Proc: 4.17.0-3-686-pae #1 SMP Debian 4.17.17-1 (2018-08-18) GNU/Linux
 Distribution: debian bullseye/sid
 Bitness: 32 bit


---
| HPLIP CONFIGURATION |
---

HPLIP-Version: HPLIP 3.19.8
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for debian 
distro  bullseye/sid version 

Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf.  Generated from hplip.conf.in by configure.

[hplip]
version=3.19.8

[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip
html=/usr/share/doc/hplip-doc
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv
bin=/usr/bin
apparmor=/etc/apparmor.d
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=no
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=yes
foomatic-drv-install=yes
foomatic-ppd-install=no
foomatic-rip-hplip-install=no
hpcups-install=yes
cups-drv-install=yes
cups-ppd-install=no
internal-tag=3.19.8
restricted-build=no
ui-toolkit=qt5
qt3=no
qt4=no
qt5=yes
policy-kit=yes
lite-build=no
udev_sysfs_rules=no
hpcups-only-build=no
hpijs-only-build=no
apparmor_build=no
class-driver=no


Current contents of '/var/lib/hp/hplip.state' file:
[plugin]
installed = 1
eula = 1
version = 3.14.6



Current contents of '~/.hplip/hplip.conf' file:
[commands]
scan = /usr/bin/simple-scan %SANE_URI%

[fax]
email_address = 
voice_phone = 

[last_used]
device_uri = "hp:/net/ENVY_5530_series?hostname=HPD0BF9CAFD037.local"
printer_name = HP-ENVY-5530-series
work

Bug#940318: ITP: lwt-log -- Lwt-friendly logging library

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: lwt-log
  Version : 1.1.1
  Upstream Author : Shawn Wagner and Jérémie Dimino
* URL : https://github.com/ocsigen/lwt_log
* License : LGPL-2.0+
  Programming Lang: OCaml
  Description : Lwt-friendly logging library

 Lwt_log is a Lwt-friendly logging library. The library is split into
 two ocamlfind packages. The "basic" lwt_log includes Unix log
 destination support, such as files and syslog, and
 Lwt_daemon. lwt_log.core is the pure-OCaml part of lwt_log, suitable
 for targeting JavaScript in the browser, or elsewhere where Unix is
 not available.

This is a new dependency of lambda-term and obus.

It will be maintained in ocaml-team.

Bug#935443: [PATCH] dgit-maint-bpo(7): Mention occasional need for --new

[Sean Whitton]

Hello,

On Sat 14 Sep 2019 at 08:25PM +01, Ian Jackson wrote:

>> >   dgit-push-adoption(7)
>> > ?
>>
>> What else would go there?
>
> I'm not sure but I get the feeling that people feel it's hard to get
> from where they are now to wher we are advertising that it would be
> nice for them to be.  I'm too sleepy right now to make much sense on
> this point.

Fair enough, let's keep the idea in mind.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#940284: autogeneration of ssl key in ssl server mode of ncat is broken

[Hilko Bengen]

Control: fixed -1 7.80+dfsg1-1
Control: tag -1 fixed-upstream

Hi,

thanks for reporting this bug. This bug has been fixed upstream between
NMAP 7.70 and 7.80. We should get this fixed via proposed-updates and,
eventually, the next buster point release.

Cheers,
-Hilko

Bug#935973: Acknowledgement (debian-installer: cryptsetup-initramfs will not be installed even when using full-disk encryption.)

[Mad Horse]

This issue is confirmed to exist in the testing weekly build generated
on Sep. 2nd 2019.

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

[Johannes Schauer]

Hi,

Quoting Jonas Smedegaard (2019-09-15 15:14:13)
> > what I still don't understand is why this would be needed.
> > 
> > Currently, if you do:
> > 
> > mmdebstrap buster ./output-directory
> > 
> > Then the resulting sources.list will be equal to what you wrote above.
> > 
> > Maybe I'm just dumb here but could either of you please go back to the 
> > start and try to explain precisely what it is, that you think is 
> > missing from mmdebstrap and why you need it?
> 
> Builtin default of mmdebstrap is nice.
> 
> Various debootstrap wrappers exist which supports replacing debootstrap 
> with an alternative command (e.g. cdebootstrap) but they commonly do not 
> support passing arbitrary commandline arguments.
> 
> What I (and we, I guess) want is that the nice default be overridable, 
> not only by passing options different from debootstrap but also in a way 
> supported by these pre-existing debootstrap wrappers.

I agree that it's important to allow defaults be overridable.

But even if mmdebstrap would add more options, as you already point out:
wrappers do not allow passing additional options. I guess that's where the idea
of mmdebstrap-sec-repo came from?

> Example: Bootstrapping a system omitting security updates e.g. because 
> an updated linux kernel is broken on my special setup.

You have multiple options:

$ mmdebstrap stable ./output-directory http://deb.debian.org/debian
$ mmdebstrap stable ./output-directory "deb http://deb.debian.org/debian 
stable main"
$ mmdebstrap stable ./output-directory /path/to/sources.list
$ mmdebstrap stable ./output-directory - < /path/to/sources.list

I have added some new entries to the man page that list these to avoid
confusion in the future.

> Example: Bootstrapping a system additionally including backports.d.o.

Just add a "deb http://..."; line to mmdebstrap.

> Example: Bootstrapping a system additionally including my custom addons.

Just add a "deb http://..."; line to mmdebstrap.

I guess the problem then is, that wrappers don't allow to pass additional
debootstrap options?

I see two ways forward:

 1. file wishlist bugs against the wrappers, asking them to allow passing
additional options to their $DEBOOTSTRAP invocation

 2. create any number of mmdebstrap wrappers that you need which do exactly
what you want

What do you think?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#940319: backintime: run test suite during build

[Jonathan Wiltshire]

Source: backintime
Version: 1.2.1-1
Severity: wishlist

In 1.2 upstream added a test suite. We should run it during build
(cd common && $(MAKE) test) but it needs to be able to write to the home
directory, which is disabled on Debian auto-builders. Need to find
a solution to that.

-- System Information:
Debian Release: 10.1
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#940320: matplotlib2 build-depends on package that is cruft in unstable and gone in testing.

[peter green]

Package: matplotlib2
Version: 2.2.4-1
Severity: serious

matplotlib2 build-depends on python-cxx-dev, this package is no longer built by 
the pycxx source package. It is still present in unstable as a cruft package, 
but is completely gone from testing.

Bug#940295: libeclipse-compare-java: circular dependency hell

[Jochen Sprickerhof]

Hi Bill,

thanks for the report. This was added in:

https://salsa.debian.org/java-team/eclipse-platform-text/commit/13e5456276b4159db659c1e603e085adbaa8fe66

I guess due to:

https://salsa.debian.org/java-team/eclipse-platform-text/blob/master/org.eclipse.ui.genericeditor/META-INF/MANIFEST.MF#L18

@Emmanuel: would it make sense to model the 'resolution:=optional' as
Recommends? Would that help?

Cheers Jochen


signature.asc
Description: PGP signature

Bug#940283: Done

[Thomas Goirand]

Hi,

So, I've uploaded python-fixtures with Python 2 support removed.

Now, it looks like python-fastimport is part of a dependency chain for
BZR. Since, as I wrote, BZR is probably going to be removed from Debian,
I'm not sure if we should fix python-fastimport or just get it removed
from Debian as well (I'd vote for the later).

So, now we still have the problem to fix with python-daemon, which has,
as reverse dependency:

- bcfg2 doesn't seem to have Python 3 support upstream, neither the
Debian package.
- mini-buildd in Experimental has been converted to Python 3, while the
version in Sid is still Python 2.
- nss-pam-ldapd isn't Python 3 ready upstream. Note that the debian
maintainer the same person as upstream.
- There's been zero upstream work on this repository:
https://github.com/Yubico/python-pyhsm
so the package has no change to be Python 3 ready anytime soon.
- lavapdu-daemon should be upgraded to latest upstream release to have
Python 3 support.
- I haven't been able to tell for lava-coordinator.

I suppose we could raise the severity to serious for the Python 2
removal bug of these packages, and get the work done for python-daemon,
which is otherwise useful (in Python 3).

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Bug#931568:

[Spielwarenkontor]

Same here in Debian stable - just upgraded from stable stretch to the
new stable buster and broke production fetchmail system.

client
Sep 15 18:14:01 boark fetchmail[4250]: OpenSSL berichtete:
error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small

server
Sep 15 18:18:01 example.com dovecot: imap-login: Disconnected (no auth
attempts in 0 secs): user=<>, rip=10.0.0.1, lip=192.168.1.1., TLS
handshaking: SSL_accept() failed: error:14094410:SSL
routines:SSL3_READ_BYTES:sslv3 alert handshake failure: SSL alert
number 40

Please escalate this bug. 

Bug#931568:

[Spielwarenkontor]

Ok, could temp solve it bydowngrade fetchmail to stretch version.

vi /etc/apt/sources.list
#add 
deb http://ftp.de.debian.org/debian/ stretch main non-free contrib
deb-src http://ftp.de.debian.org/debian/ stretch main non-free contrib

apt-get update
apt-get install fetchmail/stretch

Bug#940321: gawk.1: Fix some warnings from "test-groff"

[Bjarni Ingi Gislason]

Package: gawk
Version: 1:4.2.1+dfsg-1.1
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

  Running "test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z gawk.1"

  [ "test-groff" is a developmental version of "groff" ]

  which output:

:237 (macro IR): only 1 argument, but more are expected
:510 (macro BI): only 1 argument, but more are expected
:513 (macro BI): only 1 argument, but more are expected
:1145 (macro BR): only 1 argument, but more are expected
troff: :1267: warning: can't find font 'n'
:1292 (macro IR): only 1 argument, but more are expected

###

  Line 1267 shows the Debian bug #911759.

  Also add the italic corrections to that line.



  Patch:

--- gawk.1  2019-07-08 09:19:40.0 +
+++ gawk.1.new  2019-09-15 16:10:56.0 +
@@ -234,7 +234,7 @@ Enable debugging of \*(AK programs.
 By default, the debugger reads commands interactively from the keyboard
 (standard input).
 The optional
-.IR file
+.I file
 argument specifies a file with a list
 of commands for the debugger to execute non-interactively.
 .TP
@@ -507,10 +507,10 @@ Disable
 default optimizations upon the internal representation of the program.
 .TP
 .PD 0
-.BI \-S
+.B \-S
 .TP
 .PD
-.BI \-\^\-sandbox
+.B \-\^\-sandbox
 Run
 .I gawk
 in sandbox mode, disabling the
@@ -1142,7 +1142,7 @@ system call.
 The value of
 .IR errno (3)
 when
-.BR ERRNO
+.B ERRNO
 is set to the associated error message.
 .TP
 \fBPROCINFO["euid"]\fP
@@ -1264,7 +1264,7 @@ behavior:
 \fBPROCINFO["NONFATAL"]\fR
 If this exists, then I/O errors for all redirections become nonfatal.
 .TP
-\fBPROCINFO["\fname\fB", "NONFATAL"]\fR
+\fBPROCINFO["\,\fIname\/\fB", "NONFATAL"]\fR
 Make I/O errors for
 .I name
 be nonfatal.
@@ -1289,7 +1289,7 @@ and this array entry exists, then
 .B getline
 returns \-2 instead of following the default behavior of returning \-1
 and configuring
-.IR input
+.I input
 to return no further data.
 An I/O error that may be retried is one where
 .IR errno (3)




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

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

Versions of packages gawk depends on:
ii  libc6 2.29-1
ii  libgmp10  2:6.1.2+dfsg-4
ii  libmpfr6  4.0.2-1
ii  libreadline8  8.0-3
ii  libsigsegv2   2.12-2

gawk recommends no packages.

Versions of packages gawk suggests:
ii  gawk-doc  4.2.1-1

-- no debconf information

-- 
Bjarni I. Gislason

Bug#935928: RFS: assaultcube-data/1.2.0.2.1-4 -- data files and documentation for AssaultCube

[Tobias Frost]

Control: tags -1 moreinfo

Hi Carlos,

(After your last mail I'm not sure if you are still working in the
package, if not please let us know to get the metadata right)

Nethertheless, as assaultcube-data is now in a limbo state, and needs an
upload so that the package can be actually be used, a review:

d/changelog:
 - debian revisions -3 was never uploaded, it cannot be marked as
   uploaded to sid. So you have now two options
   - join the entries for -3 and -4 and release them as -3
   - mark the entries for -3 as UNRELEASED.
  (The first option is preferred.)
 - the changelog entry for -4… There is no change on the "Suggests"
   part?

Regarding #935669… I don't thnk your update of the breaks/replaces stancas
will fix this. First, the bug is because the (non-free) package has been
uploaded source only, second, the breaks/replace's purpose is a
different one:
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages
It was likely introduced because of that, but the version is so old that
it could be removed now. (As said, #935669 is a different issue)
To ensure that assaultcube is also updated, a simple Breaks:
assaultcube ( << 1.2.0.2) should do it, but the games packages I've checked
do not bother with that, so probably it can be left as it; It just needs
to be properly uploaded or marked as builddable on the buildds.

d/watch does not point to upsteam but to your own gitlab clone.
Please don't do that. You are NOT upstream and repacking is not a valid
reason to fork a project. (FTR, upstream is here:
https://github.com/assaultcube/AC)
This remark is also true for e.g. d/copyright and d/source/metadata)

-- 
tobi



signature.asc
Description: PGP signature

Bug#939787: RFS: assaultcube/1.2.0.2.1-3 [ITA] -- realistic first-person-shooter

[Tobias Frost]

On Thu, Sep 12, 2019 at 09:12:30PM -0300, Carlos Donizete Froes wrote:
> Hi Tobias,
> 
> > This changelog entry does not really make sense / completly unclear.
> > Please be more concise. For the breaks+replace:
> > the changelog entry should answer the question "Why" not "what", it is
> > completly unclear what you want to archieve.
> 
> I forgot to complement when I was testing and correcting the package.
> 
> The reason for adding Breaks+Replaces is that in the previous package it was:
> 
> Breaks: assaultcube-data (<< 1.1.0.4+repack1)
> Replaces: assaultcube-data (<< 1.1.0.4+repack1)

(See #935928 why I think is likely not what you wanted)

> As the latest version of the package was "1.1.0.4+repack1-2.1",the 
> assaultcube-data "1.2.0.2.1-2" package was not found in my tests.
> 
> > the mentioned bug is the ITA, you should have closed that with the
> > previous upload. It is wrong to close it now, you need to close it with
> > interacting with the BTS.
> 
> I understand, this is my first package I want to adopt.

Understood, but you still need to interact with the BTS to close that bug…
Hint: You need to manually close the bug and set the fixed version
manually. See bts(1) and the BTS documentation.

> Thanks!
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
> ⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
> ⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
> ⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

Bug#931568: [Pkg-openssl-devel] Bug#931568:

[Kurt Roeckx]

On Sun, Sep 15, 2019 at 06:23:42PM +0200, Spielwarenkontor wrote:
> 
> Same here in Debian stable - just upgraded from stable stretch to the
> new stable buster and broke production fetchmail system.
> 
> client
> Sep 15 18:14:01 boark fetchmail[4250]: OpenSSL berichtete:
> error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small

This is clearly a different issue than the original bug report.
The problem here is that you're trying to connect to an insecure
server. See /usr/share/doc/libssl1.1/NEWS.Debian.gz for more
information.


Kurt

Bug#940311: merge with lockdown / security-misc?

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2019-09-15 at 12:48 +, Patrick Schleizer wrote:
> Package: hardening-runtime
> Severity: wishlist
> X-Debbugs-CC: whonix-de...@whonix.org
> 
> We now have (at least) three very similar packages.
> 
> * https://packages.debian.org/buster/lockdown
> * https://packages.debian.org/buster/hardening-runtime
> * https://github.com/Whonix/security-misc
> 
Hi,

I'm not sure what security-misc exactly is but we try some coordination with
lockdown when I first filed an ITP (see #919226) but it didn't really go
anywhere.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1+cXMACgkQ3rYcyPpX
RFttNggAh7R+0+mnu9lEJH8IzqXpSxB30gnueRPrjVbxDyiThIoLVd/44hyJAi4f
8IK9sKPfIomu4pXb6FK1Smp92dEpnG7Fg+AhkPHxxkAtSFS4kop2AFh/lmS0f5yz
1g+DVMpr0HvToShKAL8H8CQjAbUxjPI4A9DbE/cUnvm0rUfXq2t8i5VyfQDK9JmS
7+Sxt9aUMUxp1eBUw9WNh/pA8/K5gJGvRHCW1bYPIqS54ITQIrDE1ZFkNHSQUq9p
x9pKHAsnAFjGGONqqe+KusgI6v/UfhDfM+fl5LHItYHhEE/Ui466GUB4tt5q3rn6
evcAFCIYDNAf6nd/NcC2aoOD71fFBg==
=PPny
-END PGP SIGNATURE-

Bug#925518: Bug#932817: Sponsored Post Collaboration - planet.ubuntu.com

[Thomas Dettbarn]

 
 
  
   Yeah.. i am looking for a sponsor for my awesome package that us gathering dust at mentors.devian.net...  
  
  
   
  
  
   ;)
  
  
   
  
  
   https://mentors.debian.net/package/dmagnetic
   
  
  
   
  
  
   Who else?
  
  
   Jason Turner  hat am 15. September 2019 um 15:35 geschrieben: 
   
   
   
Hello,
Jason here from Source Global Media  - We are a reputed Digital Marketing Agency working with variety of clients from UK, USA,  France, Greece, Finland, Germany and Spain
We are interested in developing partnerships with companies / webmaster such as yourself to check if you can publish sponsored content for our clients on your website i.e. - planet.ubuntu.com
If you can publish sponsored content on  planet.ubuntu.com  , please email us information with prices.
Looking forward to start the business with you.
Best regards,


 
  
   

  
 

   
  
 

   
   
  
  
    
   
 

Bug#940190: gegl: FTBFS on mips64el and mipsel while it did built before

[Bernhard Übelacker]

Hello,
I have created a new upstream issue:
https://gitlab.gnome.org/GNOME/gegl/issues/206

Kind regards,
Bernhard

Bug#940322: picard: should recommend libraries to enable builtin mediaplayer

[Jonas Smedegaard]

Package: picard
Version: 2.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

A new feature of Picard 2.2 is an optional builtin media player.

Starting Picard now emits this:

W: 19:41:42,741 /usr/lib/picard/picard/ui/playertoolbar.__init__:98: Internal 
player: unavailable, cannot import name 'QtMultimedia' from 'PyQt5' 
(/usr/lib/python3/dist-packages/PyQt5/__init__.py)

Installing python3-pyqt5.qtmultimedia makes that warning go away, but
instead emits this:

defaultServiceProvider::requestService(): no service found for - 
"org.qt-project.qt.mediaplayer"
W: 19:43:41,364 /usr/lib/picard/picard/ui/playertoolbar.__init__:94: Internal 
player: unavailable, service is missing

With libqt5multimedia5-plugins also installed, Picard starts without
warnings and the builtin player is available.

Please have picard recommend both python3-pyqt5.qtmultimedia and
libqt5multimedia5-plugins

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl1+eoUACgkQLHwxRsGg
ASEe4A//V7x+lG9MsDchjisCzRm9XvyZCeBn9jxqysefzp/86OoiGowI9PjnE06G
jd3Jc23Todp7XqnDlh4Bj8s2G6ZTGkp5dPwomzTtfGo32N6WBlCJnUsxdswqVzsM
x90IadSn1FblGO22kur/k5MUrqrxNbGnwBtggi2NqlhTC+BF3ptROSpNTUVtFpMR
u1/Lb586NyALFc26D4AehJbuiPYLhY+OvMWkiwuJ8AwJ5TeO9Hh+Q39plPUO1YV2
B1GJwQvEu7BEf3ILGS7YP5edZtKqepfp1NyM00iSIBljBc6EbfJtfIwrKh+X+ivv
fWBWWt455xCXLNf9RHkTLV6kcna8f58SU3LRK+iBo0uCECqIufsyT9uWoBmHidBO
0xA3D/cxAKEg/Ze2dYGYyees1zGh+2BIWsRRSiAOJgu2gu8TmhnJ8K6fLMI39usM
QVK9LDG+oLrneePNAAaHDJmYHMSX/wF9LXJGBGy9Pi/1V2u52Rw/qrmGFO+FlAJ1
BMMfpxw4G5OTkeKpdKH0Hb54rt31fJdqdOasNQw2XOLeKK8nG8ERfjQxR65CART3
jQWbVZDeviGCO1BdFW+aSzXOl85U4/cd9yy4wwgQiOIvqgkC/bwmOdzK3YGClhdC
5sTxWkUWRLoxCNUd8jVjGvWGB+VaIDTTaUjJb8cXVO1q72X9HBA=
=MEAB
-END PGP SIGNATURE-

Bug#874907: [hydrogen] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El dom., 15 sep. 2019 09:49, Jonas Smedegaard  escribió:

> Quoting Lisandro Damián Nicanor Pérez Meyer (2019-09-12 23:54:32)
> > On Thu, 12 Sep 2019 at 17:37, Lisandro Damián Nicanor Pérez Meyer
> >  wrote:
> > >
> > > On Mon, 30 Jul 2018 19:01:50 +0200 Reiner Herrmann 
> wrote:
> > > > Control: tags -1 + fixed-upstream
> > > >
> > > > The current upstream beta release supports Qt5.
> > > > https://github.com/hydrogen-music/hydrogen/releases/tag/1.0.0-beta1
> > >
> > > I'll see if I can tackle it during the weekend.
> >
> > Uuups, it uses cdbs. I'll prepare the NMU switching to dh. If this is
> > not wanted please say so as soon as possible :-)
>
> Thanks for the offer, but please don't if not familiar with CDBS.
>
> I want to migrate to short-form dh but want to to it cautiously.



Perfect! Please do not hesitate in asking for help if needed.

Bug#918375: Info received (dockerd segfaults can be repeated)

[Hans Freitag]

I migrated one of my problematic servers over to buster + docker-ce it
looks very promising:

My mastodon service is running for over 2  hours including its
healthchecks enabled. It never made that much.


So to sum things up: there is something differnt with  the docker.io
package's swarm mode

that causing dockerd to segfault.


regards

 Hans



pEpkey.asc
Description: application/pgp-keys

Bug#937677: python-css-parser: Python2 removal in sid/bullseye

[Nicholas D Steeves]

Control: affects 936270 + src:python-css-parser
Control: user debian-pyt...@lists.debian.org , usertags -1 py2keep
Justification: popcon of 4249

Hi Mattias,

On Fri, Aug 30, 2019 at 07:38:00AM +, Matthias Klose wrote:
> Package: src:python-css-parser
> Version: 1.0.4-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>

Would you please not use maintonly?  I didn't receive an email for
this bug, even though I'm subscribed to the team mailing list listed
as the maintainer, and I believe being purposefully cut out of the
loop like this will provoke drama with other maintainers.  There have
already been a few such threads (eg: didn't receive a notification
until my package was removed from unstable).  Best to avoid having
people feel like they're being manipulated and/or covertly bullied, I
think.  We're supposed to be the "good guys" after all ;-)

> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
> 
>   This is the least preferred option.
>

This package was packaged as a dep for Calibre.  I will hope for
Calibre's upstream success in the 2to3 migration.  BTW, it sounds like
Python 3 is planned for installtion to /usr/bin/python.  Is that the
case?


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#939549: sdaps: diff for NMU version 1.9.7-0.2

[Boyuan Yang]

Package: sdaps
Version: 1.9.7-0.1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for sdaps (versioned as 1.9.7-0.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru sdaps-1.9.7/debian/changelog sdaps-1.9.7/debian/changelog
--- sdaps-1.9.7/debian/changelog2019-09-03 11:00:23.0 -0400
+++ sdaps-1.9.7/debian/changelog2019-09-15 14:04:29.0 -0400
@@ -1,3 +1,14 @@
+sdaps (1.9.7-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Replace old build-dependency
+texlive-generic-recommended with texlive-plain-generic.
+(Closes: #940119)
+  * debian/patches: Add patch 0001 to make the build
+reproducible. (Patch already merged upstream) (Closes: #939549)
+
+ -- Boyuan Yang   Sun, 15 Sep 2019 14:04:29 -0400
+
 sdaps (1.9.7-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sdaps-1.9.7/debian/control sdaps-1.9.7/debian/control
--- sdaps-1.9.7/debian/control  2019-08-20 14:31:23.0 -0400
+++ sdaps-1.9.7/debian/control  2019-09-15 14:00:36.0 -0400
@@ -25,7 +25,7 @@
  python3-setuptools,
  python3-zbar,
  texlive,
- texlive-generic-recommended,
+ texlive-plain-generic,
  texlive-latex-extra,
  texlive-latex-recommended,
  texlive-science,
@@ -54,7 +54,7 @@
  python3-pil,
  python3-reportlab,
  texlive,
- texlive-generic-recommended,
+ texlive-plain-generic,
  texlive-latex-extra,
  texlive-latex-recommended,
  texlive-science,
diff -Nru sdaps-1.9.7/debian/patches/0001-Make-the-build-reproducible.patch
sdaps-1.9.7/debian/patches/0001-Make-the-build-reproducible.patch
--- sdaps-1.9.7/debian/patches/0001-Make-the-build-reproducible.patch   1969-
12-31 19:00:00.0 -0500
+++ sdaps-1.9.7/debian/patches/0001-Make-the-build-reproducible.patch   2019-
09-15 14:04:22.0 -0400
@@ -0,0 +1,35 @@
+From: Chris Lamb 
+Date: Fri, 6 Sep 2019 09:28:51 +0100
+Subject: Make the build reproducible
+
+Whilst working on the Reproducible Builds effort [0] we noticed
+that sdaps could not be built reproducibly.
+
+This is because its "setup.py" iterated over the keys of a dictionary
+(to generate translations), an operation which, in Python, is
+nondeterministic.
+
+This was originally filed in Debian as #939549 [1].
+
+ [0] https://reproducible-builds.org/
+ [1] https://bugs.debian.org/939549
+
+Applied-Upstream: https://github.com/sdaps/sdaps/pull/182
+Signed-off-by: Chris Lamb 
+---
+ setup.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/setup.py b/setup.py
+index 018f632..9562ef4 100755
+--- a/setup.py
 b/setup.py
+@@ -132,7 +132,7 @@ class sdaps_build_i18n(build_i18n.build_i18n):
+ f.write('%\n\n')
+ f.write('\\ProvidesDictionary{translator-sdaps-
dictionary}{%s}\n\n' % name)
+ 
+-for key in keys:
++for key in sorted(keys):
+ if lang is not None:
+ k = "%s[%s]" % (key, lang)
+ else:
diff -Nru sdaps-1.9.7/debian/patches/series sdaps-1.9.7/debian/patches/series
--- sdaps-1.9.7/debian/patches/series   1969-12-31 19:00:00.0 -0500
+++ sdaps-1.9.7/debian/patches/series   2019-09-15 14:03:33.0 -0400
@@ -0,0 +1 @@
+0001-Make-the-build-reproducible.patch


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

Bug#940300: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream

[Paul Gevers]

Control: tags -1 moreinfo

Hi Julien,

On 15-09-2019 13:16, Julien Puydt wrote:
> I'm the package maintainer (within the Debian Games Team), and I'm
> proposing to drop it off Debian testing (and unstable, with another bug
> report).

Did you already file that bug? Than we can close this bug as testing
follows unstable automatically. If you haven't filed the bug, we can
reassign it to ftp.debian.org.

Paul

Bug#940323: mark opam-doc Multi-Arch: foreign

[Helmut Grohne]

Package: opam-doc
Version: 2.0.5-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:eliom src:fieldslib src:js-build-tools src:ocaml-atd 
src:ocaml-qtest src:ocaml-rope src:ppx-core src:ppx-driver src:ppx-optcomp 
src:ppx-sexp-conv src:ppx-type-conv src:react src:reactivedata src:sexplib310 
src:variantslib

The affected packages fail to satisfy their cross Build-Depends, because
their transitive dependency on opam-doc is unsatisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch foreign or annotated :native. In this case, the
foreign marking is sensible, because opam-doc essentially is a data
package. It only contains documentation in portable file formats and
lacks dependencies or maintainer scripts. It should also be considered
whether opam really needs to depend on opam-doc. Maybe a recommendation
would suffice. Please consider applying the attached patch.

Helmut
diff --minimal -Nru opam-2.0.5/debian/changelog opam-2.0.5/debian/changelog
--- opam-2.0.5/debian/changelog 2019-08-17 17:37:02.0 +0200
+++ opam-2.0.5/debian/changelog 2019-09-15 20:16:38.0 +0200
@@ -1,3 +1,10 @@
+opam (2.0.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark opam-doc Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 15 Sep 2019 20:16:38 +0200
+
 opam (2.0.5-1) unstable; urgency=medium
 
   * New upstream version 2.0.5
diff --minimal -Nru opam-2.0.5/debian/control opam-2.0.5/debian/control
--- opam-2.0.5/debian/control   2019-08-17 17:37:02.0 +0200
+++ opam-2.0.5/debian/control   2019-09-15 20:16:36.0 +0200
@@ -79,6 +79,7 @@
 
 Package: opam-doc
 Architecture: all
+Multi-Arch: foreign
 Section: doc
 Depends:
  ${ocaml:Depends},

Bug#940325: convert libgmm++-dev to Architecture: any

[Helmut Grohne]

Package: libgmm++-dev
Version: 5.2+dfsg1-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:csound src:freefem++ src:gmsh

The affected packages fail to satisfy their cross Build-Depends, because
their dependency on libgmm++-dev is unsatisfiably. In general,
Architecture: all packages can never satisfy cross build dependencies
unless marked Multi-Arch: foreign or annotated :native. In this case,
such a marking or annotation would be fatally wrong, because
libgmm++-dev exposes its dependency libmumps-dev and that would discard
the architecture constraint. This is known as the "multiarch interpreter
problem". In such cases, the package must be converted to Architecture:
any. Please consider applying the attached patch.

Helmut
diff --minimal -Nru getfem++-5.2+dfsg1/debian/changelog 
getfem++-5.2+dfsg1/debian/changelog
--- getfem++-5.2+dfsg1/debian/changelog 2018-05-30 12:57:00.0 +0200
+++ getfem++-5.2+dfsg1/debian/changelog 2019-09-15 20:26:49.0 +0200
@@ -1,3 +1,10 @@
+getfem++ (5.2+dfsg1-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert libgmm++-dev to Architecture: any. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 15 Sep 2019 20:26:49 +0200
+
 getfem++ (5.2+dfsg1-7) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru getfem++-5.2+dfsg1/debian/control 
getfem++-5.2+dfsg1/debian/control
--- getfem++-5.2+dfsg1/debian/control   2018-05-30 12:56:00.0 +0200
+++ getfem++-5.2+dfsg1/debian/control   2019-09-15 20:26:49.0 +0200
@@ -28,7 +28,7 @@
 Section: libdevel
 Depends: libboost-dev,
  libgetfem5++ (= ${binary:Version}),
- libgmm++-dev (= ${source:Version}),
+ libgmm++-dev (= ${binary:Version}),
  libmuparser-dev [!hurd-i386],
  libsuperlu-dev,
  ${misc:Depends}
@@ -52,7 +52,7 @@
  and for arbitrary dimension.
 
 Package: libgmm++-dev
-Architecture: all
+Architecture: any
 Section: libdevel
 Depends: libmumps-dev,
  ${misc:Depends},

Bug#940324: mark libfizmo-common Multi-Arch: foreign

[Helmut Grohne]

Package: libfizmo-common
Version: 0.7.15-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:fizmo-console src:fizmo-ncursesw src:fizmo-sdl2 
src:libdrilbo src:libmonospaceif src:libsndifsdl2 src:libpixelif

The affected packages fail to satisfy their cross Build-Depends, because
their transitive dependency on libfizmo-common is unsatisfiable. In
general, Architecture: all packages can never satisfy cross build
dependencies unless marked Multi-Arch: foreign or annotated :native. In
this case, the foreign marking is reasonable, because libfizmo-common
essentially is a data package. It doesn't have any maintainer scripts
nor dependencies and only contains textual files. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru libfizmo-0.7.15/debian/changelog 
libfizmo-0.7.15/debian/changelog
--- libfizmo-0.7.15/debian/changelog2017-09-12 21:40:00.0 +0200
+++ libfizmo-0.7.15/debian/changelog2019-09-15 20:21:48.0 +0200
@@ -1,3 +1,10 @@
+libfizmo (0.7.15-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libfizmo-common Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 15 Sep 2019 20:21:48 +0200
+
 libfizmo (0.7.15-2) unstable; urgency=low
 
   * Switched priority from "extra" to "optional".
diff --minimal -Nru libfizmo-0.7.15/debian/control 
libfizmo-0.7.15/debian/control
--- libfizmo-0.7.15/debian/control  2017-09-12 21:40:00.0 +0200
+++ libfizmo-0.7.15/debian/control  2019-09-15 20:21:46.0 +0200
@@ -17,6 +17,7 @@
 Breaks: fizmo-common (<= 0.7.13)
 Replaces: fizmo-common (<= 0.7.13)
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: Provides localization data for libfizmo
  This package is required by all packages which are using libfizmo. It contains

Bug#939541: sbcl: Please include patch to fix minor issue on alpha

[John Paul Adrian Glaubitz]

Package: src:sbcl
Followup-For: Bug #939541

Hi!

Attaching an updated patch for Alpha. Will try to send it upstream.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Index: sbcl-1.5.6/src/runtime/linux-mman.c
===
--- sbcl-1.5.6.orig/src/runtime/linux-mman.c
+++ sbcl-1.5.6/src/runtime/linux-mman.c
@@ -3,9 +3,27 @@
 #include 
 
 #include "genesis/config.h"
+#include "genesis/constants.h"
+#include "globals.h"
 #include "os.h"
 #include "interr.h"
 
+#ifdef LISP_FEATURE_ALPHA
+/* The Alpha is a 64 bit CPU.  SBCL is a 32 bit application.  Due to all
+ * the places that assume we can get a pointer into a fixnum with no
+ * information loss, we have to make sure it allocates all its ram in the
+ * 0-2Gb region.  */
+
+static void * under_2gb_free_pointer;
+os_set_cheneygc_spaces(uword_t space0_start, uword_t space1_start)
+{
+uword_t max;
+max = (space1_start > space0_start) ? space1_start : space0_start;
+under_2gb_free_pointer = max + dynamic_space_size;
+}
+
+#endif
+
 os_vm_address_t
 os_validate(int movable, os_vm_address_t addr, os_vm_size_t len)
 {
Index: sbcl-1.5.6/src/runtime/linux-os.c
===
--- sbcl-1.5.6.orig/src/runtime/linux-os.c
+++ sbcl-1.5.6/src/runtime/linux-os.c
@@ -333,23 +333,6 @@ int os_preinit(char *argv[], char *envp[
 return 0;
 }
 
-
-#ifdef LISP_FEATURE_ALPHA
-/* The Alpha is a 64 bit CPU.  SBCL is a 32 bit application.  Due to all
- * the places that assume we can get a pointer into a fixnum with no
- * information loss, we have to make sure it allocates all its ram in the
- * 0-2Gb region.  */
-
-static void * under_2gb_free_pointer;
-os_set_cheneygc_spaces(uword_t space0_start, uword_t space1_start)
-{
-uword_t max;
-max = (space1_start > space0_start) ? space1_start : space0_start;
-under_2gb_free_pointer = max + dynamic_space_size;
-}
-
-#endif
-
 void
 os_protect(os_vm_address_t address, os_vm_size_t length, os_vm_prot_t prot)
 {