Bug#942901:

[Jorge Moraleda]

The solution given by Paul Wise worked for me after restarting app armor:
systemctl restart apparmor

Bug#750607: gnome-terminal: will not start with non-utf-8 locale

[Stephen Samuel]

The problem is that gnome-terminal-server
is not starting:
  root@hpre:~# locate gnome-terminal-server
  /usr/lib/gnome-terminal/gnome-terminal-server
the reason is that LANG or LC and/or LC_ALL are defined badly.  The
question is *where* are these variables ill-defined.  locally or globally.

One quick thing to do is create a new user and see if Gnome-terminal will
start there.  If it does, then the problem is with your account
definitions. (e.g. .bashrc or .profile )
what I would suggest is:
   egrep 'LANG|LC[_=]' .??* 2> /dev/null  | less
check the output...
other places to look for global causes are /etc/default/locale, /etc/rc ,
/etc/bash.bashrc  and /etc/profile*

-- 
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641  grows when you give it away

Bug#943872: RM: fontypython -- ROM; No longer active upstream, Python 2 only

[Kartik Mistry]

Package: ftp.debian.org
Severity: normal

fontypython currently depends on Python2 and has RC bug which upstream
has no time to fix and upstream no longer active as per our last
discussion.

Please remove fontypython. When upstream or someone takes over
maintenance, I can reintroduce package if needed.

Thanks.

-- 
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com

Bug#943871: wordwarvi FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: wordwarvi
Version: 1.00+dfsg1-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wordwarvi fails to cross build from source, because the upstream
Makefile hard codes the build architecture pkg-config. Please consider
applying the attached patch to make it substitutable.

Helmut
--- wordwarvi-1.00+dfsg1.orig/Makefile
+++ wordwarvi-1.00+dfsg1/Makefile
@@ -2,6 +2,7 @@
 DATADIR=${PREFIX}/share/wordwarvi
 MANDIR?=${PREFIX}/share/man
 MANPAGEDIR=${MANDIR}/man6
+PKG_CONFIG?=pkg-config
 
 SCREENSAVERFLAG=
 #SCREENSAVERFLAG=-DDO_INHIBIT_SCREENSAVER
@@ -12,8 +13,8 @@
 # WITHAUDIO=no
 
 ifeq (${WITHAUDIO},yes)
-SNDLIBS=`pkg-config --libs portaudio-2.0 vorbisfile`
-SNDFLAGS=-DWITHAUDIOSUPPORT `pkg-config --cflags portaudio-2.0`
+SNDLIBS=`$(PKG_CONFIG) --libs portaudio-2.0 vorbisfile`
+SNDFLAGS=-DWITHAUDIOSUPPORT `$(PKG_CONFIG) --cflags portaudio-2.0`
 OGGOBJ=ogg_to_pcm.o
 else
 SNDLIBS=
@@ -44,13 +45,13 @@
 
 HAS_PORTAUDIO_2_0:
 ifeq (${WITHAUDIO},yes)
-	pkg-config --print-errors --exists portaudio-2.0
+	$(PKG_CONFIG) --print-errors --exists portaudio-2.0
 else
 endif
 
 HAS_VORBISFILE:
 ifeq (${WITHAUDIO},yes)
-	pkg-config --print-errors --exists vorbisfile
+	$(PKG_CONFIG) --print-errors --exists vorbisfile
 else
 endif
 
@@ -58,17 +59,17 @@
 	$(CC) ${DEBUG} ${PROFILE_FLAG} ${OPTIMIZE_FLAG} -pthread -Wall -c joystick.c
 
 ogg_to_pcm.o:	ogg_to_pcm.c ogg_to_pcm.h Makefile
-	$(CC) ${DEBUG} ${PROFILE_FLAG} ${OPTIMIZE_FLAG} `pkg-config --cflags vorbisfile` \
+	$(CC) ${DEBUG} ${PROFILE_FLAG} ${OPTIMIZE_FLAG} `$(PKG_CONFIG) --cflags vorbisfile` \
 		-pthread -Wall -c ogg_to_pcm.c
 
 wwviaudio.o:	wwviaudio.c wwviaudio.h ogg_to_pcm.h my_point.h Makefile
 	$(CC) -Wall ${DEBUG} ${PROFILE_FLAG} ${OPTIMIZE_FLAG} \
 		${DEFINES} \
-		-pthread `pkg-config --cflags vorbisfile` \
+		-pthread `$(PKG_CONFIG) --cflags vorbisfile` \
 		-c wwviaudio.c
 
 rumble.o:	rumble.c rumble.h Makefile
-	$(CC) ${DEBUG} ${PROFILE_FLAG} ${OPTIMIZE_FLAG} `pkg-config --cflags vorbisfile` \
+	$(CC) ${DEBUG} ${PROFILE_FLAG} ${OPTIMIZE_FLAG} `$(PKG_CONFIG) --cflags vorbisfile` \
 		-pthread -Wall -c rumble.c
 
 wwvi_font.o:	wwvi_font.c wwvi_font.h my_point.h Makefile
@@ -87,7 +88,7 @@
 		${OGGOBJ} \
 		wwviaudio.o \
 		wordwarvi.c -o wordwarvi -lm ${SNDLIBS} \
-		`pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0 gthread-2.0`
+		`$(PKG_CONFIG) --cflags gtk+-2.0` `$(PKG_CONFIG) --libs gtk+-2.0 gthread-2.0`
 	/bin/rm stamp.h
 
 wordwarvi.6.gz:	wordwarvi.6

Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2

[Wolfgang Silbermayr]

On 10/30/19 10:34 PM, Adam D. Barratt wrote:
> On Wed, 2019-10-30 at 21:16 +0100, Wolfgang Silbermayr wrote:
>> The rust-crossbeam-utils-0.5 package is no longer in use. All reverse
>> dependencies either migrated to a non-semver-suffixed version of
>> rust-
>> crossbeam-utils or don't depend on it anymore at all.
>> The only remaining dependency as of now is rust-crossbeam-epoch-0.5
>> for which I
>> asked the maintainer to file a RM request as well.
> 
> Are you requesting removal from unstable?

Yes, that's correct.

I selected that in `reportbug`, seems it didn't get pre-filled or I
accidentially deleted it.

I initially attempted to report that bug against the `ftp.debian.org`
pseudo-package, selecting RoM from unstable as described in the
developers reference section 5.9.2, but it showed a final dialog telling
that I should report the bug against `release.debian.org`. Sorry if
that's the wrong pseudo-package.

Best regards,
Wolfgang.

Bug#943870: auralquiz: FTBFS: undefined reference to `Phonon::phononVersion()'

[Steve Langasek]

Source: auralquiz
Version: 1.0.0-2
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal

Dear maintainers,

I noticed that the auralquiz package has been failing to build in Ubuntu. 
Testing in Debian unstable shows that it fails to build the same way:

[...]
g++ -Wl,-z,relro -Wl,-z,now -o auralquiz main.o auralwindow.o optionsdialog.o 
answerbox.o ranking.o musicanalyzer.o qrc_auralquiz.o moc_auralwindow.o 
moc_optionsdialog.o moc_answerbox.o moc_ranking.o moc_musicanalyzer.o   -ltag 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so /usr/lib/x86_64-linux-gnu/libQt5Core.so 
/usr/lib/x86_64-linux-gnu/libGL.so -lpthread   
/usr/bin/ld: auralwindow.o: in function `AuralWindow::showAbout()':
./src/auralwindow.cpp:1152: undefined reference to `Phonon::phononVersion()'
/usr/bin/ld: auralwindow.o: in function `AuralWindow::nextSongLoaded()':
./src/auralwindow.cpp:1343: undefined reference to `Phonon::MediaObject::play()'
/usr/bin/ld: ./src/auralwindow.cpp:1344: undefined reference to 
`Phonon::MediaObject::pause()'
/usr/bin/ld: auralwindow.o: in function 
`AuralWindow::playerStateChanged(Phonon::State, Phonon::State)':
[...]

  (https://launchpad.net/ubuntu/+source/auralquiz/1.0.0-2)

The undefined references are clearly because the binary uses libphonon but
is not being linked against it.  I do not know why it is not linking against
libphonon.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#943869: screenshot

[sergio]

See screenshot attached.

-- 
sergio.

Bug#943869: maint-guide: both bg and fg colors should be explicitly defined

[sergio]

Package: maint-guide
Version: 1.2.43
Severity: normal

Dear Maintainer,

Both bg and fg colors should be explicitly defined.

Please add "color: #00;" to the body style in debian.css

--- debian.css.orig 2019-10-31 06:23:52.145586832 +0300
+++ debian.css  2019-10-31 06:23:21.061793201 +0300
@@ -22,6 +22,7 @@
 /* global style of the page */
 body {
 background-color: #EE;
+color: #00;
 border: 40px solid #EE;
 margin: 0;
 padding: 0 10px;

Bug#943851: inn2 FTCBFS: IOV_MAX check doesn't work for cross

[Russ Allbery]

Helmut Grohne  writes:

> inn2 fails to cross build from source, because its check for IOV_MAX
> doesn't work during cross compilation. The check actually tries to do
> two things in one check: 1. Figure out whether IOV_MAX is defined. 2.
> Figure out a suitable value for IOV_MAX in case it isn't defined. The
> second part cannot be easily ported to cross compilation, but luckily
> our C library does provide IOV_MAX, so using AC_CHECK_DECL avoids the
> need for our cause. The attached patch adapts the check. Please consider
> applying it.

Thank you!  I applied a somewhat different version of this patch upstream
(fixing a few other long-standing coding style problems at the same
time).

--- m4/iov-max.m4   (revision 10350)
+++ m4/iov-max.m4   (revision 10351)
@@ -38,12 +38,9 @@
   FILE *f = fopen ("conftestval", "w");
   if (f == NULL)
 return 1;
-#ifdef IOV_MAX
-  fprintf (f, "set in limits.h\n");
+#ifdef UIO_MAXIOV
+  fprintf (f, "%d\n", UIO_MAXIOV);
 #else
-# ifdef UIO_MAXIOV
-  fprintf (f, "%d\n", UIO_MAXIOV);
-# else
   fd = open ("/dev/null", O_WRONLY, 0666);
   if (fd < 0)
 return 1;
@@ -60,25 +57,31 @@
 }
 }
   fprintf (f, "1024\n");
-# endif /* UIO_MAXIOV */
-#endif /* IOV_MAX */
+#endif /* UIO_MAXIOV */
   return 0;
 }
 ]])])
 
+dnl Headers to use for checking for an IOV_MAX definition.
+define([_INN_MACRO_IOV_MAX_HEADERS],
+[AC_INCLUDES_DEFAULT
+#ifdef HAVE_LIMITS_H
+# include 
+#endif
+])
+
 dnl Do the actual check.
 AC_DEFUN([INN_MACRO_IOV_MAX],
-[AC_CACHE_CHECK([value of IOV_MAX],
-[inn_cv_macro_iov_max],
-[AC_RUN_IFELSE([_INN_MACRO_IOV_MAX_SOURCE],
-inn_cv_macro_iov_max=`cat conftestval`,
-inn_cv_macro_iov_max=error,
-16)
- if test x"$inn_cv_macro_iov_max" = xerror ; then
- AC_MSG_WARN([probe failure, assuming 16])
- inn_cv_macro_iov_max=16
- fi])
- if test x"$inn_cv_macro_iov_max" != x"set in limits.h" ; then
-AC_DEFINE_UNQUOTED(IOV_MAX, $inn_cv_macro_iov_max,
-   [Define to the max vectors in an iovec.])
- fi])
+[AC_CHECK_DECL([IOV_MAX], [],
+[AC_CACHE_CHECK([value of IOV_MAX],
+[inn_cv_macro_iov_max],
+[AC_RUN_IFELSE([_INN_MACRO_IOV_MAX_SOURCE],
+inn_cv_macro_iov_max=`cat conftestval`,
+inn_cv_macro_iov_max=error,
+16)
+ AS_IF([test x"$inn_cv_macro_iov_max" = xerror],
+[AC_MSG_WARN([probe failure, assuming 16])
+ inn_cv_macro_iov_max=16])])
+ AC_DEFINE_UNQUOTED([IOV_MAX], [$inn_cv_macro_iov_max],
+ [Define to the max vectors in an iovec.])],
+[_INN_MACRO_IOV_MAX_HEADERS])])

-- 
Russ Allbery (r...@debian.org)  

Bug#935994: [Debichem-devel] Bug#935994: nwchem: NWChem compiled with long int lapack/blas interface?

[Mo Zhou]

Hi NWChem maintainers,

blas/lapack lib maintainer here.

> I don't follow it closely, are you saying that both the refblas/lapack
> packages now provide a 64bit int interface, and MKL? Or just MKL?

both. We additionally compiled a 64bit-indexing version of src:lapack,
namely libblas64-dev and liblapack64-dev.

Once built against the standard implementaiton, users could switch
the underlying blas64/lapack64 with the update-alternatives mechanism.
https://wiki.debian.org/DebianScience/LinearAlgebraLibraries

e.g libopenblas64-0 (still in exp), libblis64-2,
libmkl-rt (need to export MKL_INTERFACE_LAYER=ILP64 when actually using)

However I don't recommend compiling debian packages with the
  -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -lmkl_blacs_openmpi_ilp64 ...
way as it would drive the package into contrib.

> Unless there are considerable downsides (are there?) I would not mind
> switching the nwchem packaging to a 64bit int build using blas/lapack
> libraries from main.

There is no known downside for the 32-bit indexing to 64-bit one switch.
According to the user demand, I think keeping a 32-bit indexing version
would not be quite useful, as the same functionality has been delivered
by the 64bit version.

> Regarding mkl, my current, initial opinion is that we would welcome
> patches to make it possible to rebuild nwchem for MKL without source
> changes (via some DEB_BUILD_OPTIONS or other external flags), but
> building nwchem twice and once for MKL would (I believe) mean the source
> package would have to move into contrib as it build-depended on a
> non-free package.

as explained above.

Bug#943868: rust-chrono: issues in d/copyright

[Sean Whitton]

Source: rust-chrono
Version: 0.4.7-1
Severity: serious

Dear maintainer,

There are some inaccuracies in d/copyright.  I'm filing this bug at RC
severity because the MIT license requires all copyright claims to be
collated in d/copyright.

(The package is dual-licensed under Apache-2.0, which the FTP team
considers a license which does not require that all claims of copyright
be collated in d/copyright, but it seems easier to just fix d/copyright
rather than try to rely on the dual-licensing...)

- `Files: *` stanza has incorrect copyright information.  It should be
  "Kang Seonghoon and contributors" not just "Kang Seonghoon".

- `Files: ./src/div.rc` stanza looks to be copyright both Kang
  Seonghoon and contributors, and also the Rust Project Developers.

- Similarly `Files: ./src/format/parse.rs` is only /portions/
  copyrighted by John Nagle, so Kang Seonghoon and contributors would
  appear to hold copyright too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#943867: stressant: non-buildd binaries

[peter green]

Package: stressant
Version: 0.5.0
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#936704: python-colormap: Python2 removal in sid/bullseye

[peter green]

Severity 936704 serious
thanks

python-colormap depends on the python-easydev binary package which is no longer 
built by the python-easydev source package.

Bug#932978: snmpd postinst fails

[Adam Baker]

I hit this issue upgrading to Buster and can confirm setting VERBOSE=yes
in /etc/default/rcS worked round the issue (and hence I was unable to
gather any useful logging). Using sysvinit, not systemd.

Adam

Bug#943866: kdenlive: Crash when add an audio clip to the session

[wargreen]

Package: kdenlive
Version: 19.08.2-1
Severity: important

Dear Maintainer,

When add a new audio clip and scroll to it in the Project Source tab, Kdenlive
crash with this log

/// starting to add bin clips
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf5.kservice.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
/// found list
(QUrl("file:///tmp/PorcasForroResurg_premix_r1_2019-07-22.wav"))
/// creatclipsfromlist
(QUrl("file:///tmp/PorcasForroResurg_premix_r1_2019-07-22.wav")) true "-1"
/// createClipFromFile
"/tmp/PorcasForroResurg_premix_r1_2019-07-22.wav" "-1"
"/tmp/PorcasForroResurg_premix_r1_2019-07-22.wav" "audio/x-wav"
/// final xml "\n /tmp/PorcasForroResurg_premix_r1_2019-07-22.wav\n\n"
/// requestAddBinClip "-1"
/// found id "2"
/// constructed
/// added  true
/// creatclipsfromlist return true
### JOB finished 0
### loadjob COMMIT
### ProjectClip::setproducer
### ClipController::updateProducer
### ClipController::addmasterproducer
QPoint(0,8976)
MUTEX LOCK setmodel
MUTEX UNLOCK setmodel
MUTEX LOCK loadEffects:
### JOB finished 1
!!!

 WRONG CLIP TYPE

!!
fish : Tâche , 'kdenlive' terminée par le signal SIGFPE (Exception de virgule
flottante)



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

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

Versions of packages kdenlive depends on:
ii  ffmpeg 7:4.1.4-1+b3
ii  kded5  5.62.0-1
ii  kdenlive-data  19.08.2-1
ii  kinit  5.62.0-1
ii  kio5.62.1-2
ii  libc6  2.29-2
ii  libkf5archive5 5.62.0-1
ii  libkf5bookmarks5   5.62.0-1
ii  libkf5completion5  5.62.0-1
ii  libkf5configcore5  5.62.0-1
ii  libkf5configgui5   5.62.0-1
ii  libkf5configwidgets5   5.62.0-1
ii  libkf5coreaddons5  5.62.0-1
ii  libkf5crash5   5.62.0-1
ii  libkf5dbusaddons5  5.62.0-1
ii  libkf5declarative5 5.62.0-1
ii  libkf5filemetadata35.62.0-1
ii  libkf5guiaddons5   5.62.0-1
ii  libkf5i18n55.62.0-1
ii  libkf5iconthemes5  5.62.0-1
ii  libkf5itemviews5   5.62.0-1
ii  libkf5jobwidgets5  5.62.0-1
ii  libkf5kiocore5 5.62.1-2
ii  libkf5kiofilewidgets5  5.62.1-2
ii  libkf5kiowidgets5  5.62.1-2
ii  libkf5newstuff55.62.0-1
ii  libkf5notifications5   5.62.0-1
ii  libkf5notifyconfig55.62.0-1
ii  libkf5purpose-bin  5.62.0-2
ii  libkf5purpose5 5.62.0-2
ii  libkf5service-bin  5.62.0-1
ii  libkf5service5 5.62.0-1
ii  libkf5solid5   5.62.0-2
ii  libkf5widgetsaddons5   5.62.0-1
ii  libkf5xmlgui5  5.62.0-1+b1
ii  libmlt++3  6.16.0-7
ii  libmlt66.16.0-7
ii  libqt5concurrent5  5.12.5+dfsg-2
ii  libqt5core5a   5.12.5+dfsg-2
ii  libqt5dbus55.12.5+dfsg-2
ii  libqt5gui5 5.12.5+dfsg-2
ii  libqt5multimedia5  5.12.5-1
ii  libqt5network5 5.12.5+dfsg-2
ii  libqt5qml5

Bug#943865: src:mesa: Please build Mesa SWR rasterizer on amd64 and i386

[Witold Baryluk]

Package: src:mesa
Severity: normal

Dear Maintainer,

SWR is a new high performance rasterizer that is usually significantly
faster than softpipe or llvmpipe and is merged in upstream Mesa for
some time.

Adding these meson extra flags:

"-Dgallium-drivers=,swrast,swr" "-Dswr-arches=avx,avx2,knl,skx"

should build and install these files in lib/{x86_64,i386}-linux-gnu/

libswrAVX2.so
libswrAVX2.so.0
libswrAVX2.so.0.0.0
libswrAVX.so
libswrAVX.so.0
libswrAVX.so.0.0.0
libswrKNL.so
libswrKNL.so.0
libswrKNL.so.0.0.0
libswrSKX.so
libswrSKX.so.0
libswrSKX.so.0.0.0

dri/kms_swrast_dri.so(maybe)
dri/swrast_dri.so

It is probably worth packaging into separate package (with all arches
tho, no need to split it into 4 packages, mesa gallium loaader will
automatically determine best suitable version and load it dynamically).

Building on other archs might succeed (unlikely), but it is pointless as
SWR targets at the moment only x86 specific vector instructions so even if
it manages to be able to generate code at runtime (via LLVM) it will not be
able to run it anyway. Thus the request is only for i386 and amd64.

Adding x32 and kfreebsd-{amd64,i386} at your discretion.

Best regards,
Witold.





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

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

Bug#942229: Issue confirmed on Buster i386

[Sylvestre Ledru]

Hello

I added this patch 
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/ff4ed1bf4420079b647e2566f625e1280a16e501


to the 9 branch to manage the old-z3 issue.

Cheers

S

Le 27/10/2019 à 06:48, Jérémy Viès a écrit :

Hello,

I haven't find any solution for the llvm build on buster i386.

By the way, the -3 release from sid makes the backport further more 
complicated as now it draws z3, that needs a newer version of ocaml...
For now, I abandonned the idea to quickly backport mesa from sid to 
buster.


Best regards,
Jérémy

Le sam. 26 oct. 2019 à 19:41, Sylvestre Ledru > a écrit :


Hello

I just experienced it too and the cmake logs are useless.

Have you been able to find a fix for that? It is pretty confusing :/

Thanks

Sylvestre


Le 17/10/2019 à 19:29, Jérémy Viès a écrit :
> Hello,
>
> I'm following this bug as I try to do the same backport. I can
confirm
> the issue in a simple docker configuration, based on
i386/debian:buster
> with only the declared deps of llvm-toolchain installed.
>
> Best regards,
> Jérémy
>
> ___
> Pkg-llvm-team mailing list
> pkg-llvm-t...@alioth-lists.debian.net

>
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team


___
Pkg-llvm-team mailing list
pkg-llvm-t...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team

Bug#943845: syslinux-common: error messages with grml boot stick

[Lukas Schwaighofer]

On Wed, 30 Oct 2019 22:41:48 +0100
Sven Joachim  wrote:

> On 2019-10-30 21:03 +0100, Lukas Schwaighofer wrote:
> > I'm suspecting that there is somehow a mismatch between the version
> > of syslinux/extlinux used while installing (i.e. running `extlinux
> > -i`) and the c32 files installed on the medium.  
> 
> Indeed, this was the case.  While the version of syslinux installed in
> the boot sector was the one from Debian, the support files in the
> boot/syslinux directory came from the grml iso.  After replacing them
> with the files from /usr/lib/syslinux/modules/bios/ everything was
> fine.
> 
> > Can you check whether the c32 files installed on the medium
> > (probably in /boot/syslinux or /boot/extlinux) match the one
> > from /usr/lib/syslinux/modules/bios on the host system? If they do
> > match, can you re-run the syslinux installation from the host system
> > and then try again?  
> 
> They do not match, but I have a question: how would I get those files
> onto the boot medium with syslinux commands?  The naive command
> "syslinux -d boot/syslinux /dev/sdc1" (or whatever device instead of
> /dev/sdc1) does not do that, yet grml2usb apparently relies on it.

Unfortunately syslinux does not offer any "installer" to do that (nor
does the Debian package).  The admittedly poorly documented installation
procedure is more or less to run the installer and copy any modules you
need yourself to the correct folder.

`syslinux -d boot/syslinux /dev/sdc1` does not install any c32 modules.
This means any c32 modules present on your medium were copied by
grml2usb.  I don't know the details of how grml2usb installs syslinux,
but they need to make sure whatever is installed to the volume boot
record (`syslinux` or `extlinux` command) is consistent with the c32
modules.  Either both must come from the host system or both from the
installed medium.

Regards
Lukas

Bug#943864: gnuradio: Cannot start gnuradio-companion without also installing gir1.2-gtk-3.0

[Karl Sickendick]

Package: gnuradio
Version: 3.8.0.0-5
Severity: important

Dear Maintainer,
I installed a fresh Debian unstable in a docker container, followed by
gnuradio.  Upon starting gnuradio-companion I got the errors below.  I
resolved
it by installing gir1.2-gtk-3.0.  Perhaps it should be a dependency.

~$ gnuradio-companion
Traceback (most recent call last):
  File "/usr/bin/gnuradio-companion", line 59, in check_gtk
gi.require_version('Gtk', '3.0')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/gnuradio-companion", line 100, in 
 check_gtk()
  File "/usr/bin/gnuradio-companion", line 67, in check_gtk
die(err, "Failed to initialize GTK. If you are running over ssh, "
  File "/usr/bin/gnuradio-companion", line 41, in die
gi.require_version('Gtk', '3.0')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available



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

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



I previously reported this to "src:gnuradio" as bug #943778 - that was
unintentional.  For some reason reportbug thought I wanted to report it
there.

Bug#943778: Accidental bug report

[Karl Sickendick]

I'm sorry, I intended to send this to the gnuradio package, not the source
package.  I've realized my mistake (reportbug used the "source" option
instead of "package" and I didn't notice) and resubmitted over there.

-- 
-Karl

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Fri, Oct 25, 2019 at 09:27:48AM +1300, Olly Betts wrote:
> On Tue, Oct 22, 2019 at 08:58:42AM +1300, Olly Betts wrote:
> > * mrpt was updated but the build failed on mipsel due to running out of
> >   memory and it's now entangled in auto-opencv.  But it's due for AUTORM
> >   on 2019-10-28 so that should resolve itself within a week.
> 
> No change here.

The AUTORM happened for mrpt.

> However, checking with "dak rm" on coccia, I discovered four packages
> which build-depend on libwxgtk3.0-dev but without a resulting runtime
> dependency.  I've filed bugs against these and set them as blocking this
> bug.  They should at least be easy to address.

Fixes for these extra four have now been uploaded and checking again:

olly@coccia:~$ dak rm -Rn -b libwxgtk3.0-dev
[...]
# Broken Depends:
wxsvg: libwxsvg-dev
wxwidgets3.0: libwxgtk-media3.0-dev

# Broken Build-Depends:
amule: libwxgtk3.0-dev
codeblocks: libwxgtk3.0-dev
cubicsdr: libwxgtk3.0-dev
objcryst-fox: libwxgtk3.0-dev
pcsx2: libwxgtk3.0-dev
sooperlooper: libwxgtk3.0-dev
treesheets: libwxgtk3.0-dev
ucblogo: libwxgtk3.0-dev
wxsvg: libwxgtk3.0-dev

Which is just the packages which are only in unstable, so aren't
blockers.

The codeblocks maintainers never responded, but taffit is preparing an
update to the latest upstream release so that at least should be off the
list fairly soon.

I've uploaded wxwidgets3.0 dropping the GTK2 flavour packages, so I
think we can consider this transition complete.  I'll leave actually
closing this bug to someone on the release team in case I've missed
something.

Upstream wx are making noises about actually releasing 3.2 early next
year, so we may have another wx transition before bullseye.  We've
managed to prune many of the rdeps which are inactive upstream and
unmaintained in Debian, so the next one should hopefully be less work.

Cheers,
Olly

Bug#943863: neutron: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: neutron
Version: 2_15.0.0-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for neutron's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-

neutron_2_15.0.0-2_pt.po.gz
Description: application/gzip

Bug#943839: cockpit: New version available (205)

[Martin Pitt]

Hello jim_p,

jim_p [2019-10-30 18:34 +0200]:
> There has been a new version available from upstream since mid October.
> https://cockpit-project.org/blog/cockpit-205.html
> 
> Please update the package in the repo. Cockpit on debian usually gets updated
> the day it is released from upstream.

Yes, yes -- 205 had a bad regression, thus I didn't package it (and I forgot
about 205.1). I'm packaging 206 as we speak.

Martin

Bug#943862: gnucash-docs: yelp help omits Accounts and Transactions sections (Testing 3.7-2)

[Nate Bargmann]

Package: gnucash-docs
Version: 3.7-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

When comparing the yelp, HTML, and PDF versions of the Tutorial and Concepts
Guide, I find that the yelp version omits the Accounts and Transactions
sections.  In the HTML version these are sections 2.8 and 2.9 and in the PDF
version they begin on pages 29 and 37, respectively.

In the older documentation (Stable 3.4) these sections were separate chapters,
Chapters 3 and 4, respectively, although new chapters appear in this version.

- - Nate

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

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

gnucash-docs depends on no packages.

Versions of packages gnucash-docs recommends:
ii  yelp  3.34.0-1

Versions of packages gnucash-docs suggests:
ii  chromium [www-browser]  76.0.3809.100-1
ii  epiphany-browser [www-browser]  3.34.1-1+b1
ii  evince [pdf-viewer] 3.34.1-1
ii  firefox-esr [www-browser]   60.9.0esr-1~deb10u1
ii  gnucash 1:3.7-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iGsEARECACsWIQSC1k9rDmfNQfaJu6b7LFEw1VqIGQUCXboGgQ0cbjBuYkBuMG5i
LnVzAAoJEPssUTDVWogZEyYAoIcy7p+CKuOE1P4XWThqfHl2hhG/AJ456TnSlUI6
Yw7nFnfTazCUfYqSdQ==
=vGN1
-END PGP SIGNATURE-

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

[Thorsten Glaser]

Hi Felix,

>> Yes, it’s a direct Depends of lintian or one of its direct Depends.
>
>FTR, I only see it as recommended by libmoo-perl (which is required).

indeed, I misspoke as the script uses -o APT::Install-Recommends=true
to override the buildd default of false for installing lintian after
the build ONLY.

>> This fixes the issue for me when I hand-apply it in the chroot to
>> …/usr/share/perl5/Lintian/Collect/Binary.pm
>
>Thanks for testing the proposed fix. Please accept our apologies for
>the inconvenience.

No problem, and thanks for the quick fix!

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#943669: RFS: backintime 1.2.1-2 -- simple backup/snapshot system [closes RC bugs]

[Fabian Wolff]

Thank you for pointing this out to me - I was not aware of the GFDL-NIV short
name. I have now changed it to GFDL-NIV-1.1+ (because legal.xml says "Version
1.1 or any later version") and pushed the updated version to the Salsa
repository.

Thank you for sponsoring this upload!

On 10/30/19 9:48 PM, Dmitry Shachnev wrote:
> Hi Fabian!
> 
> On Sun, Oct 27, 2019 at 06:28:26PM +0100, Fabian Wolff wrote:
>> Dear mentors,
>>
>> I am looking for a sponsor for an upload of the 'backintime' package.
>> [...]
> 
> I would be happy to sponsor this, just please change one thing.
> 
> In debian/copyright, you specify license as “GFDL”. However, the copyright
> specification [1] says:
> 
> “Use GFDL-NIV instead if there are no Front-Cover or Back-Cover Texts or
> Invariant Sections.”
> 
> So can you please change the license short name to GFDL-NIV-1.3+?
> Then your comment would be not needed, however you may include the first
> paragraph of qt/docbook/en/legal.xml in the license text (before the
> “On Debian systems” part).
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name
> 
> --
> Dmitry Shachnev
> 

Bug#943861: gnucash-docs: The noun "gnucash" is not rendered in the Concepts Guide (Stable version 3.4-1)

[Nate Bargmann]

Package: gnucash-docs
Version: 3.4-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

When reading any of the yelp, HTML, or PDF versions of the Toturial and
Concepts Guide, I've noticed that "GnuCash" is not rendered in the text.
An example is the first line of text in Chapter 4, Transactions, where
the sentence should end with "GnuCash" but has an awkward period after a
space character.  It becomes evident that the term is not rendered in
several subsequent lines as well.

I have compared the Debian documentation to the PDF downloaded from the
GnuCash website to see the difference.  Also, this bug only appears to
affect the package version in Buster.

- - Nate

- -- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (500, '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
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

gnucash-docs depends on no packages.

Versions of packages gnucash-docs recommends:
ii  yelp  3.31.90-1

Versions of packages gnucash-docs suggests:
ii  chromium [www-browser]  76.0.3809.100-1~deb10u1
ii  epiphany-browser [www-browser]  3.32.1.2-3~deb10u1
ii  evince [pdf-viewer] 3.30.2-3
ii  firefox-esr [www-browser]   68.2.0esr-1~deb10u1
ii  gnucash 1:3.4-1+b10
ii  w3m [www-browser]   0.5.3-37

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQHBBAEBCgArFiEEG5vcSeqIHtMzWHg79yYl4u2+1ZgFAl26ANoNHG4wbmJAbjBu
Yi51cwAKCRD3JiXi7b7VmIh7C/9trbbpDKOMcdalmgVYy6bDoOCWf0S1Y0Ryymx+
LRr2t4MsyY6he6PrUXXL6cJ35xvdWjf24NSxi79N/J5QdZ1qIG9DNlVOA4PCzFfu
A+nmvNQ3d3Hh9H+qciUEk8tKrH9nB0+zD8WKVBNaQ/Dv/KP+7eqD/7/1j7wTQXR/
fPrd5SAWhJ0eKOTOpENrvj9bmIoZ/Nq4PqUk3VuZiLWX5kz6i74oh68Udi+9ocg5
NAWym8cPvViOPfqknF1dq0W7dOOcLnTMPW67YBceu9/j8y43JmvsZ69w1sPVr5FE
mGjvTKefG4pbRxTelB10Mk79t+mjyT+sWVf0XBUHu/1LS4Jz19yqiChr2ocYEk1+
l6cIP3PBcNzV4dp0bWtAgsNXujMS9j/t3yHl4Ri66TMmECyVzAJ4vYlOl5+YXLn6
+90h7QcfOQEbZMmj+VgFrk79SNoYaK/hcVyqqLx8esiKtD1p/nh0zjiRJR6GM0sZ
q2/DJKNrZa+D3r8yQYapaK5sy48=
=zn0r
-END PGP SIGNATURE-

Bug#903090: Want to spot source-only binaries-NEW upload to Debian

[Sean Whitton]

Hello,

On Sun 27 Oct 2019 at 12:22PM -07, Russ Allbery wrote:

> My thought process was more that since I've run dgit sbuild, there's a
> *.changes file that lists all the binary packages that the source builds.
> But there probably isn't any reasonable way for push-source to be able to
> use that *.changes file to know the binary package list, since it doesn't
> know that any *.changes file is from the same package that one is calling
> push-source on.

I see what you mean.

If there is a single pkg_*.changes containing binaries in the
build-products-dir, it is probably safe for dgit to use that to get a
list of the binary packages built by 'pkg'.  After all, this is only a
check to prevent mistakes, not a process which determines any of the
contents of uploads.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#943845: syslinux-common: error messages with grml boot stick

[Sven Joachim]

On 2019-10-30 21:03 +0100, Lukas Schwaighofer wrote:

> Control: tags -1 + moreinfo
>
> Hi Sven,
>
> thanks for your report!
>
> On Wed, 30 Oct 2019 18:58:12 +0100
> Sven Joachim  wrote:
>
>> Today I built myself a USB stick with grml on it (see #943838 for the
>> problems I had with that).  When booting an old 32-bit laptop with
>> this stick syslinux threw some error messages before its prompt:
>>
>> ,
>> | Undef symbol FAIL: x86_init_fpu
>> | Failed to load libcom32.c32
>> | Failed to load COM32 file vesamenu.c32
>> | boot:
>> `
>
> I'm unable to reproduce this at the moment using the syslinux version
> 3:6.04~git20190206.bf6db5b4+dfsg1-1 .
>
> I'm suspecting that there is somehow a mismatch between the version of
> syslinux/extlinux used while installing (i.e. running `extlinux -i`)
> and the c32 files installed on the medium.

Indeed, this was the case.  While the version of syslinux installed in
the boot sector was the one from Debian, the support files in the
boot/syslinux directory came from the grml iso.  After replacing them
with the files from /usr/lib/syslinux/modules/bios/ everything was fine.

> Can you check whether the c32 files installed on the medium
> (probably in /boot/syslinux or /boot/extlinux) match the one
> from /usr/lib/syslinux/modules/bios on the host system? If they do
> match, can you re-run the syslinux installation from the host system
> and then try again?

They do not match, but I have a question: how would I get those files
onto the boot medium with syslinux commands?  The naive command
"syslinux -d boot/syslinux /dev/sdc1" (or whatever device instead of
/dev/sdc1) does not do that, yet grml2usb apparently relies on it.

Cheers,
   Sven

Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2

[Adam D. Barratt]

On Wed, 2019-10-30 at 21:16 +0100, Wolfgang Silbermayr wrote:
> The rust-crossbeam-utils-0.5 package is no longer in use. All reverse
> dependencies either migrated to a non-semver-suffixed version of
> rust-
> crossbeam-utils or don't depend on it anymore at all.
> The only remaining dependency as of now is rust-crossbeam-epoch-0.5
> for which I
> asked the maintainer to file a RM request as well.

Are you requesting removal from unstable?

Regards,

Adam

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

[Felix Lechner]

Hi Thorsten,

On Wed, Oct 30, 2019 at 2:07 PM Thorsten Glaser  wrote:
>
> Yes, it’s a direct Depends of lintian or one of its direct Depends.

FTR, I only see it as recommended by libmoo-perl (which is required).
Until now, I ran Lintian without it.

> This fixes the issue for me when I hand-apply it in the chroot to
> …/usr/share/perl5/Lintian/Collect/Binary.pm

Thanks for testing the proposed fix. Please accept our apologies for
the inconvenience.

Kind regards,
Felix Lechner

Bug#910140: arp-scan: broken symlink: /usr/share/doc/arp-scan/README -> README.md

[Witold Baryluk]

Package: arp-scan
Version: 1.9.5-1
Followup-For: Bug #910140

Ping. Still not fixed.

arp-scan: broken-symlink /usr/share/doc/arp-scan/README -> README.md


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

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

Versions of packages arp-scan depends on:
ii  ieee-data   20180805.1
ii  libc6   2.29-2
ii  libpcap0.8  1.9.1-2

Versions of packages arp-scan recommends:
ii  libwww-perl  6.39-1

arp-scan suggests no packages.

-- no debconf information

Bug#864079: Status of this bug?

[Axel Beckert]

Hi,

Axel Beckert wrote:
> Yes, Jonathan Wiltshire (Cc'ed) pushed a packaging of it to
> https://salsa.debian.org/debian/backuppc-rsync
[...]
> Will work on this later on this week. Probably won't find time for it
> today.

Just noticed that Jonathan has put himself as maintainer so far and
don't want put in the BackupPC team without asking. :-/

Will nevertheless update the package in git a bit.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#943860: munin-plugins-core: ntp_states plugin is broken in current package release

[Jo-Jo]

Package: munin-plugins-core
Version: 2.0.49-1

Hello,

As I pointed out here[1] the ntp_states plugins accidentally doesn't
work in this release.

Upstream fixed it with this[2] commit.

Could you please ensure to have this fix in the package as soon as possible?

Thanks for the great work your doing!

Johannes

Refs:
[1] https://github.com/munin-monitoring/munin/issues/1244
[2] 
https://github.com/munin-monitoring/munin/commit/a1738b47356e7582ba96bf73a9e00b20f095611e

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

[Thorsten Glaser]

Felix Lechner dixit:

>Also, please let us know if your chroot or cowbuilder environment had
>libclass-xsaccessor-perl installed. (Note the XS in the name; there

Yes, it’s a direct Depends of lintian or one of its direct Depends.

>I also committed another fix, which I found more appropriate after
>discussing the issue with Moo's author. The commit message has more
>details and is replicated below.
>
>are other similar packages in the archive.)
>
>
> https://salsa.debian.org/lintian/lintian/commit/b951f0d4d83fa76286d1f4bd5836cf256038f31c

This fixes the issue for me when I hand-apply it in the chroot to
…/usr/share/perl5/Lintian/Collect/Binary.pm

Thanks,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#942861: linux-image-amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Witold Baryluk]

Package: linux-image-amd64
Version: 5.3.7-1
Followup-For: Bug #942861

Not just linux-image-amd64:

linux-perf: missing-copyright-file /usr/share/doc/linux-perf/copyright
linux-headers-amd64: missing-copyright-file 
/usr/share/doc/linux-headers-amd64/copyright
linux-image-amd64: missing-copyright-file 
/usr/share/doc/linux-image-amd64/copyright


user@debian:~$ ls -l /usr/share/doc/linux-perf/
total 0
user@debian:~$ ls -l /usr/share/doc/linux-headers-amd64/
total 0
user@debian:~$ ls -l /usr/share/doc/linux-image-amd64/
total 0
user@debian:~$ 


Cheers,
Witold

Bug#943859: rustc: broken-symlink /usr/bin/rust-lld -> lld-8

[Witold Baryluk]

Package: rustc
Version: 1.37.0+dfsg1-1
Severity: normal

adequate reports:

rustc: broken-symlink /usr/bin/rust-lld -> lld-8

Is this symlink really needed? Or should lld-8 be harder dependency?




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

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

Versions of packages rustc depends on:
ii  binutils  2.33.1-2
ii  gcc   4:9.2.1-3.1
ii  libc6 2.29-2
ii  libc6-dev [libc-dev]  2.29-2
ii  libgcc1   1:9.2.1-15
ii  libllvm8  1:8.0.1-3+b1
ii  libstd-rust-dev   1.37.0+dfsg1-1
ii  libstdc++69.2.1-15

Versions of packages rustc recommends:
ii  cargo 0.37.0-3
ii  rust-gdb  1.37.0+dfsg1-1

Versions of packages rustc suggests:
pn  lld-8 
pn  rust-doc  
pn  rust-src  

-- no debconf information

Bug#943858: obs-plugins: py-file-not-bytecompiled frontend-tools/scripts/url-text.py

[Witold Baryluk]

Package: obs-plugins
Version: 24.0.3+dfsg1-1
Severity: minor

adequiate reports:

obs-plugins:amd64: py-file-not-bytecompiled 
/usr/share/obs/obs-plugins/frontend-tools/scripts/url-text.py




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

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

Versions of packages obs-plugins depends on:
ii  libasound21.1.8-2
ii  libavcodec58  7:4.2.1-1
ii  libavdevice58 7:4.2.1-1
ii  libavformat58 7:4.2.1-1
ii  libavutil56   7:4.2.1-1
ii  libc6 2.29-2
ii  libcurl3-gnutls   7.66.0-1+b1
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc1   1:9.2.1-15
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjansson4   2.12-1
ii  libmbedcrypto32.16.3-1
ii  libmbedtls12  2.16.3-1
ii  libmbedx509-0 2.16.3-1
ii  libobs0   24.0.3+dfsg1-1
ii  libpulse0 13.0-3
ii  libqt5core5a  5.12.5+dfsg-2
ii  libqt5gui55.12.5+dfsg-2
ii  libqt5widgets55.12.5+dfsg-2
ii  libspeexdsp1  1.2~rc1.2-1.1
ii  libstdc++69.2.1-15
ii  libswscale5   7:4.2.1-1
ii  libudev1  242-7
ii  libv4l-0  1.18.0-1
ii  libx11-6  2:1.6.8-1
ii  libx264-155   2:0.155.2917+git0a84d98-2
ii  libxcb-randr0 1.13.1-2
ii  libxcb-shm0   1.13.1-2
ii  libxcb-xfixes01.13.1-2
ii  libxcb-xinerama0  1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxfixes31:5.0.3-1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages obs-plugins recommends:
ii  vlc  3.0.8-2+b2

obs-plugins suggests no packages.

-- no debconf information

Bug#943857: libradare2-dev: Missing dependency on libzip-dev

[Witold Baryluk]

Package: libradare2-dev
Version: 3.2.1+dfsg-5
Severity: normal

adequate reports this:

libradare2-dev: missing-pkgconfig-dependency r_io => libzip


Indeed:

$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/r_io.pc
prefix=/usr
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include

Name: r_io
Description: radare foundation libraries
Version: 3.2.1
Requires: r_util, r_socket
Requires.private: libzip
Libs: -L${libdir} -lr_io
Libs.private: -pthread -L${libdir} -lr2sdb -lr2bochs -lr2gdb -lr2windbg -lr2qnx 
-lr2ar -lptrace_wrap
Cflags: -I${includedir}/libr
$

But libzip-dev (which provides
/usr/lib/x86_64-linux-gnu/pkgconfig/libzip.pc) is not installed.

$ apt-cache show libradare2-dev | grep Depe
Depends: libradare2-3.2 (= 3.2.1+dfsg-5), libcapstone-dev, libmagic-dev, 
libuv1-dev, liblz4-dev
$

Doesn't look sufficent for me, and there are no Suggests or Recommends
for libradare2-dev.


Best regards,
Witold





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

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

Versions of packages libradare2-dev depends on:
ii  libcapstone-dev  4.0.1+really+3.0.5-1+b1
ii  liblz4-dev   1.9.1-2
ii  libmagic-dev 1:5.37-6
ii  libradare2-3.2   3.2.1+dfsg-5
ii  libuv1-dev   1.30.1-1

libradare2-dev recommends no packages.

libradare2-dev suggests no packages.

-- no debconf information

Bug#943669: RFS: backintime 1.2.1-2 -- simple backup/snapshot system [closes RC bugs]

[Dmitry Shachnev]

Hi Fabian!

On Sun, Oct 27, 2019 at 06:28:26PM +0100, Fabian Wolff wrote:
> Dear mentors,
>
> I am looking for a sponsor for an upload of the 'backintime' package.
> [...]

I would be happy to sponsor this, just please change one thing.

In debian/copyright, you specify license as “GFDL”. However, the copyright
specification [1] says:

“Use GFDL-NIV instead if there are no Front-Cover or Back-Cover Texts or
Invariant Sections.”

So can you please change the license short name to GFDL-NIV-1.3+?
Then your comment would be not needed, however you may include the first
paragraph of qt/docbook/en/legal.xml in the license text (before the
“On Debian systems” part).

[1]: 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#943811: perl:any is possible the following way and I suggest doing this

[Niko Tyni]

On Tue, Oct 29, 2019 at 11:05:27PM -0600, mdasoh kyaeppd wrote:
> Package: perl
> Version: 5.30.0-8
> Severity: important
> 
> Having seen perl:any wane in use, I suggest bringing it back with the 
> following measures:
> in perl's control stanza:
> Provides: perl:any (= 5.30.0-8)
> in perl-base's control stanza:
> Multi-Arch: foreign
> Provides: perl-base:any (= 5.30.0-8), perlapi-5.30.0:any
> in a package's control stanza which currently Depends: perl:any
> Multi-Arch: foreign
> Depends: perl:any (>= 5.30.0-8), perlapi-5.30.0:any
> 
> I have it working this way locally
> please respond with your thoughts or opinions.

I don't know what problem you are trying to solve and this doesn't make
much sense to me unfortunately.

In any case, depending on perlapi-5.30.0:any seems like a totally
wrong concept: perlapi-5.30.0 is about guaranteeing binary compatibility
between the perl interpreter and its plugins (compiled XS modules). Their
architectures must therefore always match.
-- 
Niko Tyni   nt...@debian.org

Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2

[Wolfgang Silbermayr]

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

The rust-crossbeam-utils-0.5 package is no longer in use. All reverse
dependencies either migrated to a non-semver-suffixed version of rust-
crossbeam-utils or don't depend on it anymore at all.
The only remaining dependency as of now is rust-crossbeam-epoch-0.5 for which I
asked the maintainer to file a RM request as well.

Bug#943856: dumpasn1 misindentifies some inputs as ASCII

[Eric Seppanen]

Package: dumpasn1
Version: 20170309-1
Severity: normal

Dear Maintainer,

There is a bug in the dumpasn1 program that prevents it from handling certain
(valid) files.  This bug is fixed in the upstream source:
https://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c

I'll include the comment from the fixed code since it describes the problem
better than I could:
> Special-case handling for situations that would produce a 
> false positive, items containing nested SEQUENCE (0x30)/SET 
> (0x31) of an appropriate length will look like ASCII since
> the encoding is 0x30 0xXX 0x30 0xXX 0x30 0xXX, e.g. "0g0e0c",
> so we check for the pattern [0|1] alnum [0|1] alnum ...

An example of an input that demonstrates the problem:

MHcwdTBOMEwwSjAJBgUrDgMCGgUABBRCRjDCJxnb3nDwj/xz5aZfZjgXvAQUmNH4bhDrz5vsYJ8Y
kBug630J/SsCEQDtf4ChN5MCVggAGQ3NoiMwITAfBgkrBgEFBQcwAQIEEgQQX7GnwCPaKaV9
xhaMpzjwbA==

The problem looks like this:
$ base64 < (input file above) >ocsp_req.der
$ dumpasn1 ocsp_req.der 
Error: This file appears to be a base64-encoded text file, not binary data.
   In order to display it you first need to decode it into its
   binary form.

That error message is wrong; the file is in its proper binary form.  The
expected output looks like this (using the upstream code):

$ ./dumpasn1 ocsp_req.der 
  0 119: SEQUENCE {
  2 117:   SEQUENCE {
  4  78: SEQUENCE {
  6  76:   SEQUENCE {
  8  74: SEQUENCE {
 10   9:   SEQUENCE {
 12   5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
 19   0: NULL
   : }
 21  20:   OCTET STRING
   : 42 46 30 C2 27 19 DB DE 70 F0 8F FC 73 E5 A6 5F
   : 66 38 17 BC



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

Kernel: Linux 4.15.0-66-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dumpasn1 depends on:
ii  libc6  2.29-2

dumpasn1 recommends no packages.

dumpasn1 suggests no packages.

-- no debconf information

Bug#943845: syslinux-common: error messages with grml boot stick

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Sven,

thanks for your report!

On Wed, 30 Oct 2019 18:58:12 +0100
Sven Joachim  wrote:

> Today I built myself a USB stick with grml on it (see #943838 for the
> problems I had with that).  When booting an old 32-bit laptop with
> this stick syslinux threw some error messages before its prompt:
> 
> ,
> | Undef symbol FAIL: x86_init_fpu
> | Failed to load libcom32.c32
> | Failed to load COM32 file vesamenu.c32
> | boot:
> `

I'm unable to reproduce this at the moment using the syslinux version
3:6.04~git20190206.bf6db5b4+dfsg1-1 .

I'm suspecting that there is somehow a mismatch between the version of
syslinux/extlinux used while installing (i.e. running `extlinux -i`)
and the c32 files installed on the medium.

Can you check whether the c32 files installed on the medium
(probably in /boot/syslinux or /boot/extlinux) match the one
from /usr/lib/syslinux/modules/bios on the host system? If they do
match, can you re-run the syslinux installation from the host system
and then try again? Is the image bootable when using `qemu-system-i386`?

If all of the above does not help narrow down the problem, can you
provide me with the necessary commands to build a similarly broken image
myself?

Thanks for your help
Lukas

Bug#941657: Needed too

[Peter Wienemann]

Hi Thomas,

On 27.10.19 09:10, Thomas Andrejak wrote:
> I'm also interested. I need it to bump version of Prewikka.

nice to hear.

> If you want, we can co-maintain the package

You are welcome as co-maintainer. I pushed what I have right now to
salsa such that you can get an idea what the present status is:

https://salsa.debian.org/python-team/modules/python-lark-parser

It seems that you are not yet a member of the Debian Python Modules
Team. Information on the team (including how to join) is available on

https://wiki.debian.org/Teams/PythonModulesTeam

Getting lark-parser into Debian requires more work than packaging
lark-parser itself. That is why this bug is blocked by #943783 which in
turn is blocked by #943785.

Progress on #943785 can be tracked here:

https://salsa.debian.org/python-team/modules/python-pyjsparser

My work on #943783 is presently slowed down by a problem with a js2py
unit test error [0]. After some necessary clean-up I will push my js2py
packaging work in progress to

https://salsa.debian.org/python-team/modules/python-js2py

Peter

[0] https://github.com/PiotrDabkowski/Js2Py/issues/185

Bug#943854: neutron [INTL:de] Updated German debconf translation

[Chris Leick]

Package: neutron
Version: 15.0.0
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the newest German debconf translation.

Kind regards,
Chris


de.po.gz
Description: application/gzip

Bug#943588: libllvm9 version differs between amd64 and i386

[Bernhard Übelacker]

Hello,
this seems to be caused by a build failure in 1:9.0.0-1
for i386 while amd64 succeeded.
The build failure seems related to #942864.

Next upload 1:9.0.0-2 succeeded for both architectures.

Kind regards,
Bernhard


https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-9=i386
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-9=amd64
https://bugs.debian.org/942864

Bug#943730: marked as done (RFS: cowsay/3.03+dfsg2-7 [ITA] -- configurable talking cow)

[Stephen Kitt]

On Wed, 30 Oct 2019 11:03:33 +0800, Paul Wise  wrote:
> On Wed, Oct 30, 2019 at 5:03 AM Stephen Kitt wrote:
> > I’ve pushed that to the games-team repository, and tagged the release.
> > Please register a guest account on Salsa if you don’t already have one:
> > https://signup.salsa.debian.org/
> > Then you’ll be able to request access to the cowsay repository and/or the
> > games team on https://salsa.debian.org/games-team  
> 
> Why not use the existing cowsay repository?
> 
> https://salsa.debian.org/debian/cowsay

Oops, sorry, yes, that’s the repo I used.

Regards,

Stephen


pgpIZdGGzfl7J.pgp
Description: OpenPGP digital signature

Bug#940116: [Debichem-devel] Bug#940116: cp2k: autopkgtest regression: missing versioned (test) depends?

[Paul Gevers]

Hi Michael,

On 28-10-2019 20:56, Michael Banck wrote:
> That has been fixed since in testing it seems, can we close this bug?

As I already said on IRC, I fine with that, although technically the bug
is still there. I mean, the *versioned* (test) dependency is not
properly declared. But alas.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#943790: www.debian.org: packages.debian.org partitions architectures into debports incorrectly

[Witold Baryluk]

Package: www.debian.org
Followup-For: Bug #943790

Yesterday it was showing:

sid (unstable) (libdevel): A library for atomic operations (development files)
7.6.10-1+b1: amd64
7.6.10-1 [ debports ]: alpha arm64 armel armhf hppa i386 m68k mips64el mipsel 
powerpcspe ppc64 ppc64el s390x sh4 sparc64 x32


Today it is showing:


sid (unstable) (libdevel): A library for atomic operations (development files)
7.6.10-1+b1: amd64
7.6.10-1: alpha arm64 armel armhf hppa i386 m68k mips64el mipsel powerpcspe 
ppc64 ppc64el s390x sh4 sparc64 x32



Still wrong, it should be:

sid (unstable) (libdevel): A library for atomic operations (development files)
7.6.10-1+b1: amd64
7.6.10-1: arm64 armel armhf i386 mips64el mipsel ppc64el s390x
7.6.10-1 [ debports ]: alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32


Best regards,
Witold

Bug#942676: mate-menu: Can't add MATE Advanced Menu to panel

[Alan McDonald]

Package: mate-menu
Version: 19.10.2-1
Severity: minor

Dear Maintainer,

I believe the problem is an unexpressed dependency in version 19.10.2-1.

This version of mate-menu requires package: python3-gi-cairo

Manual installation of that package resolved this issue for me on multiple 
physical and virtual machines.

Bug#930736: solstices and equinoxes are wrongly reported in the Russian calendar

[sergio]

If you look attentively at the output you'll see quite all equinox and
solstice in the same output:

% faketime '20 Jun 2019' calendar
...
Jun 20* Весеннее равноденствие (Summer Equinox)
...
Jun 21* Зимнее солнцестояние (Winter Solstice)
Jun 21* Летнее солнцестояние (Summer Solstice)
...
Jun 21* Summer Solstice
...


It's not just a translation error that thought to fix easily.


-- 
sergio.

Bug#943852: tstools FTCBFS: uses the build architecture ld

[Helmut Grohne]

Source: tstools
Version: 1.13~git20151030-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

tstools fails to cross build from source, because the upstream makefile
links with $(LD), which happens get default initialized to the build
architecture linker. Exporting it from dpkg's buildtools.mk makes
tstools cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru tstools-1.13~git20151030/debian/changelog 
tstools-1.13~git20151030/debian/changelog
--- tstools-1.13~git20151030/debian/changelog   2019-10-01 17:34:56.0 
+0200
+++ tstools-1.13~git20151030/debian/changelog   2019-10-30 20:06:41.0 
+0100
@@ -1,3 +1,9 @@
+tstools (1.13~git20151030-2) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Export a suitable LD. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 30 Oct 2019 20:06:41 +0100
+
 tstools (1.13~git20151030-1) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru tstools-1.13~git20151030/debian/rules 
tstools-1.13~git20151030/debian/rules
--- tstools-1.13~git20151030/debian/rules   2019-10-01 17:23:17.0 
+0200
+++ tstools-1.13~git20151030/debian/rules   2019-10-30 20:06:40.0 
+0100
@@ -10,6 +10,8 @@
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 include /usr/share/dpkg/default.mk
+-include /usr/share/dpkg/buildtools.mk
+export LD
 
 DEB_CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
 DEB_LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)

Bug#940136: aqbanking-tools: Transaction fails with 9075::Starke Kundenauthentifizierung notwendig.

[Micha Lenk]

Hi Achim,

thank you very much for the positive feedback on the new AqBanking 
versions. This helps a lot to move on with more confidence in pushing 
this foward.


On 29.10.19 10:29, Achim Weber wrote:

One problem remains on my environment:
The assignment of online (bank) account to gnucash account isn't stored
correctly. In aqbanking management (via gnucash) the assignment can be done but
next time I fetch accounting info I have to select (gnucash) account again


This is probably a bug in Gnucash. Do you mind to raise this on a 
Gnucash related mailing list, or even file it as a separate bug in the 
upstream bug tracker at https://bugs.gnucash.org/enter_bug.cgi? The 
upstream bug tracker should be the best place to track such issues down 
and work on a fix.


Best regards,
Micha

Bug#943598: linux-source-4.9: Func irq_remove_generic_chip is undefined .

[Ben Hutchings]

Control: tag -1 moreinfo

On Sun, 2019-10-27 at 09:10 +0100, Corcodel Marian wrote:
> Package: linux-source-4.9
> Severity: normal
> 
> Func irq_remove_generic_chip is undefined but when compile file suppress
> errors.Search func here:
>   https://elixir.bootlin.com/linux/v5.0-rc6/ident/irq_remove_generic_chip

What errors are you talking about?

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
 - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'




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

Bug#943851: inn2 FTCBFS: IOV_MAX check doesn't work for cross

[Helmut Grohne]

Source: inn2
Version: 2.6.3-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

inn2 fails to cross build from source, because its check for IOV_MAX
doesn't work during cross compilation. The check actually tries to do
two things in one check: 1. Figure out whether IOV_MAX is defined. 2.
Figure out a suitable value for IOV_MAX in case it isn't defined. The
second part cannot be easily ported to cross compilation, but luckily
our C library does provide IOV_MAX, so using AC_CHECK_DECL avoids the
need for our cause. The attached patch adapts the check. Please consider
applying it.

Helmut
--- inn2-2.6.3.orig/m4/iov-max.m4
+++ inn2-2.6.3/m4/iov-max.m4
@@ -38,9 +38,6 @@
   FILE *f = fopen ("conftestval", "w");
   if (f == NULL)
 return 1;
-#ifdef IOV_MAX
-  fprintf (f, "set in limits.h\n");
-#else
 # ifdef UIO_MAXIOV
   fprintf (f, "%d\n", UIO_MAXIOV);
 # else
@@ -61,14 +58,14 @@
 }
   fprintf (f, "1024\n");
 # endif /* UIO_MAXIOV */
-#endif /* IOV_MAX */
   return 0;
 }
 ]])])
 
 dnl Do the actual check.
 AC_DEFUN([INN_MACRO_IOV_MAX],
-[AC_CACHE_CHECK([value of IOV_MAX],
+[AC_CHECK_DECL([IOV_MAX],[],
+  [AC_CACHE_CHECK([value of IOV_MAX],
 [inn_cv_macro_iov_max],
 [AC_RUN_IFELSE([_INN_MACRO_IOV_MAX_SOURCE],
 inn_cv_macro_iov_max=`cat conftestval`,
@@ -78,7 +75,18 @@
  AC_MSG_WARN([probe failure, assuming 16])
  inn_cv_macro_iov_max=16
  fi])
- if test x"$inn_cv_macro_iov_max" != x"set in limits.h" ; then
 AC_DEFINE_UNQUOTED(IOV_MAX, $inn_cv_macro_iov_max,
[Define to the max vectors in an iovec.])
- fi])
+ ],[
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef HAVE_UNISTD_H
+# include 
+#endif
+#ifdef HAVE_LIMITS_H
+# include 
+#endif
+])])

Bug#943849: geoipupdate does not create the database directory

[Etienne Dechamps]

Package: geoipupdate
Version: 4.0.6-1

After installing geoipupdate, the bundled cron job fails with:

# /usr/bin/geoipupdate
Error preparing to update: database directory is not available: stat
/var/lib/GeoIP: no such file or directory

Workaround:

# mkdir /var/lib/GeoIP

Seems like that command should be run as part of package installation.

Bug#943850: python3-python-qt-binding: missing Breaks+Replaces: python-qt-binding

[Andreas Beckmann]

Package: python3-python-qt-binding
Version: 0.3.6-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

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

  Preparing to unpack .../python3-python-qt-binding_0.3.6-2_all.deb ...
  Unpacking python3-python-qt-binding (0.3.6-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-python-qt-binding_0.3.6-2_all.deb (--unpack):
   trying to overwrite '/usr/share/pkgconfig/python_qt_binding.pc', which is 
also in package python-qt-binding 0.3.4-2
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-python-qt-binding_0.3.6-2_all.deb


cheers,

Andreas


python-qt-binding=0.3.4-2_python3-python-qt-binding=0.3.6-2.log.gz
Description: application/gzip

Bug#943848: Should depend on gir1.2-soup-2.4

[Sven Bartscher]

Package: lollypop
Version: 1.2.1-1
Severity: important

After installing lollypop and trying to start it through the
application menu, nothing happened. Lollypop didn't start as
expected. Trying to start it on the terminal revealed the following
error message:

$ lollypop
Traceback (most recent call last):
  File "/usr/bin/lollypop", line 45, in 
from lollypop.application import Application
  File "/usr/lib/python3/dist-packages/lollypop/application.py", line 40, in 

from lollypop.art import Art
  File "/usr/lib/python3/dist-packages/lollypop/art.py", line 18, in 
from lollypop.art_album import AlbumArt
  File "/usr/lib/python3/dist-packages/lollypop/art_album.py", line 26, in 

from lollypop.helper_task import TaskHelper
  File "/usr/lib/python3/dist-packages/lollypop/helper_task.py", line 14, in 

gi.require_version("Soup", "2.4")
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in 
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Soup not available

Installig fir1.2-soup-2.4 fixed the issue. Apparently lollypop needs a
dependency on that package.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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)
LSM: AppArmor: enabled

Versions of packages lollypop depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  gir1.2-gst-plugins-base-1.0  1.16.1-1
ii  gir1.2-gstreamer-1.0 1.16.1-1
ii  gir1.2-secret-1  0.19.1-1
ii  gir1.2-totemplparser-1.0 3.26.3-1
ii  gstreamer1.0-libav   1.16.1-1
ii  python3  3.7.5-1
ii  python3-bs4  4.8.0-2
ii  python3-gi   3.34.0-1
ii  python3-pil  6.2.0-1
ii  python3-pylast   3.1.0-1

lollypop recommends no packages.

lollypop suggests no packages.

-- no debconf information

Bug#943395: runit: Minor fixes to invoke-run

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-35
Followup-For: Bug #943395

patch refreshed

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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.29-2
ii  sysuser-helper  1.3.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-35

runit suggests no packages.

-- Configuration Files:
/etc/default/runit changed [not included]
/etc/runit/3 changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/runit/invoke-run (from runit package)
debsums: changed file /sbin/update-service (from runit package)
>From 9d24842ffdb859894f47142925663d2aee748643 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Wed, 30 Oct 2019 19:32:37 +0100
Subject: [PATCH] Minor improvements to invoke-run

* be verbose about uninstalled binary
* redirect output of {$initscripts} stop to /dev/null (it goes to
  service log otherwise); it is confusing to see a stop message during
  service startup

Closes: #943395
---
 debian/contrib/lib/invoke-run | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/contrib/lib/invoke-run b/debian/contrib/lib/invoke-run
index 2a11306..5a9b4c6 100755
--- a/debian/contrib/lib/invoke-run
+++ b/debian/contrib/lib/invoke-run
@@ -38,6 +38,7 @@ if [ -f "/etc/sv/${service}/.meta/installed" ] ; then
# uninstalled, but not purged. See #929693 and commit [4c485b]
# in dh-runit repository.
if ! [ -f "${installed}" ] ; then
+   echo "runsv: $NAME binary not installed"
sv down "${service}"
exit 0
fi
@@ -69,7 +70,7 @@ if [ -x "${initscript}" ] ; then
exit 0
fi
fi
-   "${initscript}" stop
+   "${initscript}" stop >/dev/null
 fi
 
 if [ -d "/etc/sv/${service}/conf" ] ; then
-- 
2.24.0.rc1

Bug#943847: python3-sardana: missing Breaks+Replaces: python-sardana

[Andreas Beckmann]

Package: python3-sardana
Version: 3.0.0a+3.f4f89e+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../python3-sardana_3.0.0a+3.f4f89e+dfsg-1_all.deb ...
  Unpacking python3-sardana (3.0.0a+3.f4f89e+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-sardana_3.0.0a+3.f4f89e+dfsg-1_all.deb 
(--unpack):
   trying to overwrite '/usr/bin/MacroServer', which is also in package 
python-sardana 2.6.2+dfsg-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-sardana_3.0.0a+3.f4f89e+dfsg-1_all.deb


cheers,

Andreas


python-sardana=2.6.2+dfsg-1_python3-sardana=3.0.0a+3.f4f89e+dfsg-1.log.gz
Description: application/gzip

Bug#942789: libbio-{db-{biofetch,gff,seqfeature},searchio-hmmer,tools-run-remoteblast}-perl: missing Breaks+Replaces: libbio-perl-perl (<< 1.7.3)

[Michael Crusoe]

All of those have been submitted, but were rejected due to my lack of
uploader privileges.

Any DD can allow me to upload the fixed packages via the following command


dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow ${srcpackage}


--
Michael R. Crusoe

On Wed, Oct 30, 2019, 19:09 Andreas Beckmann  wrote:

> Followup-For: Bug #942789
>
> There are some more related Breaks+Replaces needed:
>
>   Unpacking libbio-db-gff-perl (1.7.3-1) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/libbio-db-gff-perl_1.7.3-1_all.deb (--unpack):
>trying to overwrite '/usr/bin/bp_bulk_load_gff', which is also in
> package bioperl 1.7.2-3
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>
>   Preparing to unpack .../libbio-db-seqfeature-perl_1.7.3-1_all.deb ...
>   Unpacking libbio-db-seqfeature-perl (1.7.3-1) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/libbio-db-seqfeature-perl_1.7.3-1_all.deb
> (--unpack):
>trying to overwrite '/usr/bin/bp_seqfeature_delete', which is also in
> package bioperl 1.7.2-3
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>
> i.e. both libbio-db-gff-perl and libbio-db-seqfeature-perl need
> an additional Breaks+Replaces: bioperl (<< 1.7.3)
>
>
> Andreas
>

Bug#943744: caja: Cannot move file to Trash, do you want to delete immediately?

[scott092707]

Update:

Having given myself ownership and permissions to ~/.local/share/Trash[/*],
I am now able to trash items that are in my system / partition (including items 
that
are in /home/scott that are NOT in the bind-mounted personal data directories)
with no complaint from Caja.

scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha .local/share
drwxrwx---  4 scott scott 4.0K Mar 16  2019 Trash 

scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha .local/share/Trash  




   
total 16K   




   
drwxrwx---  4 scott scott 4.0K Mar 16  2019 .   




   
drwxr-xr-x 19 scott scott 4.0K Oct 29 23:50 ..  




   
drwxrwx---  2 scott scott 4.0K Mar 16  2019 files   




   
drwxrwx---  2 scott scott 4.0K Mar 16  2019 info

However, I am still not able to trash files in my bind-mounted directories.

In looking at the terminal output for the trash directory for /data (see above),
I noted that although I had ownership of the directory, only the owner had 
permissions for "Create and delete".

I fixed that...
scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha /data/.Trash-1000   




   
total 4.0M  




   
drwxrwx---   5 scott scott 4.0K Feb 28  2014 .  




   
drwxrwxr-x  10 scott scott 4.0K Oct 28 20:15 .. 




   
drwxrwx---   2 scott scott  16K Feb 28  2014 expunged   




   

Bug#943846: buster-pu: package python-cryptography/2.6.1-3+deb10u2

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

(This is a followup update on top of the +deb10u1 already in s-p-u,
I've reached out to Tristan beforehand)

Attached debdiff fixes a memory leak in python-cryptography, which
was noticed in an ACME-related service 
(https://wikitech.wikimedia.org/wiki/Acme-chief)
running on Buster. It has been verified that the updated packages
fix the memory leak (and are otherwise working fine as well).

Debdiff below.

Cheers,
Moritz

diff -Nru python-cryptography-2.6.1/debian/changelog 
python-cryptography-2.6.1/debian/changelog
--- python-cryptography-2.6.1/debian/changelog  2019-09-30 20:55:00.0 
+0200
+++ python-cryptography-2.6.1/debian/changelog  2019-10-18 16:08:59.0 
+0200
@@ -1,3 +1,13 @@
+python-cryptography (2.6.1-3+deb10u2) buster; urgency=medium
+
+  * Cherrypick 92241410b5b0591d849443b3023992334a4be0a2 and
+9a22851fab924fd58482fdad3f8dd23dc3987f91 from upstream which
+addresses a memory leak triggerable when parsing x509
+certificate extensions like AIA, thanks to Valentin
+Gutierrez for the report (Closes: #941413)
+
+ -- Moritz Mühlenhoff   Fri, 18 Oct 2019 16:08:59 +0200
+
 python-cryptography (2.6.1-3+deb10u1) buster; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch 
python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
--- python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
1970-01-01 01:00:00.0 +0100
+++ python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
2019-10-18 16:08:35.0 +0200
@@ -0,0 +1,94 @@
+From 92241410b5b0591d849443b3023992334a4be0a2 Mon Sep 17 00:00:00 2001
+From: Paul Kehrer 
+Date: Thu, 11 Apr 2019 20:57:13 +0800
+Subject: [PATCH] fix a memory leak in AIA parsing (#4836)
+
+* fix a memory leak in AIA parsing
+
+* oops can't remove that
+---
+ src/_cffi_src/openssl/x509v3.py   |  3 +++
+ .../hazmat/backends/openssl/decode_asn1.py|  9 +++-
+ tests/hazmat/backends/test_openssl_memleak.py | 21 ++-
+ 3 files changed, 31 insertions(+), 2 deletions(-)
+
+diff --git a/src/_cffi_src/openssl/x509v3.py b/src/_cffi_src/openssl/x509v3.py
+index 193d2e233b..5968120652 100644
+--- a/src/_cffi_src/openssl/x509v3.py
 b/src/_cffi_src/openssl/x509v3.py
+@@ -177,6 +177,7 @@
+ typedef void (*sk_GENERAL_NAME_freefunc)(GENERAL_NAME *);
+ typedef void (*sk_DIST_POINT_freefunc)(DIST_POINT *);
+ typedef void (*sk_POLICYINFO_freefunc)(POLICYINFO *);
++typedef void (*sk_ACCESS_DESCRIPTION_freefunc)(ACCESS_DESCRIPTION *);
+ """
+ 
+ 
+@@ -228,6 +229,8 @@
+ Cryptography_STACK_OF_ACCESS_DESCRIPTION *, int
+ );
+ void sk_ACCESS_DESCRIPTION_free(Cryptography_STACK_OF_ACCESS_DESCRIPTION *);
++void sk_ACCESS_DESCRIPTION_pop_free(Cryptography_STACK_OF_ACCESS_DESCRIPTION 
*,
++  sk_ACCESS_DESCRIPTION_freefunc);
+ int sk_ACCESS_DESCRIPTION_push(Cryptography_STACK_OF_ACCESS_DESCRIPTION *,
+ACCESS_DESCRIPTION *);
+ 
+diff --git a/src/cryptography/hazmat/backends/openssl/decode_asn1.py 
b/src/cryptography/hazmat/backends/openssl/decode_asn1.py
+index 773189d4f8..75d5844bc1 100644
+--- a/src/cryptography/hazmat/backends/openssl/decode_asn1.py
 b/src/cryptography/hazmat/backends/openssl/decode_asn1.py
+@@ -379,7 +379,14 @@ def _decode_authority_key_identifier(backend, akid):
+ 
+ def _decode_authority_information_access(backend, aia):
+ aia = backend._ffi.cast("Cryptography_STACK_OF_ACCESS_DESCRIPTION *", aia)
+-aia = backend._ffi.gc(aia, backend._lib.sk_ACCESS_DESCRIPTION_free)
++aia = backend._ffi.gc(
++aia,
++lambda x: backend._lib.sk_ACCESS_DESCRIPTION_pop_free(
++x, backend._ffi.addressof(
++backend._lib._original_lib, "ACCESS_DESCRIPTION_free"
++)
++)
++)
+ num = backend._lib.sk_ACCESS_DESCRIPTION_num(aia)
+ access_descriptions = []
+ for i in range(num):
+diff --git a/tests/hazmat/backends/test_openssl_memleak.py 
b/tests/hazmat/backends/test_openssl_memleak.py
+index ed22b5db9e..f9ae1c46b9 100644
+--- a/tests/hazmat/backends/test_openssl_memleak.py
 b/tests/hazmat/backends/test_openssl_memleak.py
+@@ -210,7 +210,7 @@ class TestOpenSSLMemoryLeaks(object):
+ @pytest.mark.parametrize("path", [
+ "x509/PKITS_data/certs/ValidcRLIssuerTest28EE.crt",
+ ])
+-def test_x509_certificate_extensions(self, path):
++def test_der_x509_certificate_extensions(self, path):
+ assert_no_memory_leaks(textwrap.dedent("""
+ def func(path):
+ from cryptography import x509
+@@ -226,6 +226,25 @@ def func(path):
+ cert.extensions
+ """), [path])
+ 
++@pytest.mark.parametrize("path", [
++"x509/cryptography.io.pem",
++])
++def test_pem_x509_certificate_extensions(self, path):
++

Bug#942803: No Sound HDMI with linux-image-5.3.0-1-amd64

[Gustavo Castro]

Dear Maintainer,

I have no sound on the HDMI output, and the speekers run out of sound when
entering the laptop in screen protection mode

lspci -k
00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series
SoC Transaction Register (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series SoC Transaction Register
Kernel driver in use: iosf_mbi_pci
00:02.0 VGA compatible controller: Intel Corporation Atom Processor
Z36xxx/Z37xxx Series Graphics & Display (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series Graphics & Display
Kernel driver in use: i915
Kernel modules: i915
00:13.0 SATA controller: Intel Corporation Atom Processor E3800 Series SATA
AHCI Controller (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor E3800 Series SATA
AHCI Controller
Kernel driver in use: ahci
Kernel modules: ahci
00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx,
Celeron N2000 Series USB xHCI (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx,
Celeron N2000 Series USB xHCI
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
00:1a.0 Encryption controller: Intel Corporation Atom Processor
Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series Trusted Execution Engine
00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx Series
High Definition Audio Controller (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series High Definition Audio Controller
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI
Express Root Port 1 (rev 0e)
Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI
Express Root Port 2 (rev 0e)
Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI
Express Root Port 4 (rev 0e)
Kernel driver in use: pcieport
00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series
Power Control Unit (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx
Series Power Control Unit
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.3 SMBus: Intel Corporation Atom Processor E3800 Series SMBus
Controller (rev 0e)
Subsystem: ASUSTeK Computer Inc. Atom Processor E3800 Series SMBus
Controller
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network
Adapter (rev 01)
Subsystem: AzureWave AW-NE186H
Kernel driver in use: ath9k
Kernel modules: ath9k
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5286
PCI Express Card Reader (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. RTS5286 PCI Express Card
Reader
Kernel driver in use: rtsx_pci
Kernel modules: rtsx_pci
03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI
Express Fast Ethernet controller (rev 06)
Subsystem: ASUSTeK Computer Inc. RTL810xE PCI Express Fast Ethernet
controller
Kernel driver in use: r8169
Kernel modules: r8169

aplay -l
 List of PLAYBACK Hardware Devices 
card 0: PCH [HDA Intel PCH], device 0: ALC270 Analog [ALC270 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

lsmod | grep snd
snd_hda_codec_realtek   126976  1
snd_hda_codec_generic94208  2 snd_hda_codec_realtek
ledtrig_audio  16384  2 snd_hda_codec_generic,snd_hda_codec_realtek
snd_hda_intel  49152  2
snd_hda_codec 159744  3
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_realtek
snd_hda_core  102400  4
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_hwdep  16384  1 snd_hda_codec
snd_pcm   118784  3 snd_hda_intel,snd_hda_codec,snd_hda_core
snd_timer  40960  1 snd_pcm
snd98304  11
snd_hda_codec_generic,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
soundcore  16384  1 snd

add the file / etc / modprobe.d / snd-hda-intel.conf with the
following statement and the problem was not resolved

options snd-hda-intel model=asus-laptop

regards

Bug#942789: libbio-{db-{biofetch,gff,seqfeature},searchio-hmmer,tools-run-remoteblast}-perl: missing Breaks+Replaces: libbio-perl-perl (<< 1.7.3)

[Andreas Beckmann]

Followup-For: Bug #942789

There are some more related Breaks+Replaces needed:

  Unpacking libbio-db-gff-perl (1.7.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libbio-db-gff-perl_1.7.3-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/bp_bulk_load_gff', which is also in package 
bioperl 1.7.2-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

  Preparing to unpack .../libbio-db-seqfeature-perl_1.7.3-1_all.deb ...
  Unpacking libbio-db-seqfeature-perl (1.7.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libbio-db-seqfeature-perl_1.7.3-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/bp_seqfeature_delete', which is also in 
package bioperl 1.7.2-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

i.e. both libbio-db-gff-perl and libbio-db-seqfeature-perl need
an additional Breaks+Replaces: bioperl (<< 1.7.3)


Andreas

Bug#943845: syslinux-common: error messages with grml boot stick

[Sven Joachim]

Package: syslinux-common
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-1
Severity: important

Today I built myself a USB stick with grml on it (see #943838 for the
problems I had with that).  When booting an old 32-bit laptop with this
stick syslinux threw some error messages before its prompt:

,
| Undef symbol FAIL: x86_init_fpu
| Failed to load libcom32.c32
| Failed to load COM32 file vesamenu.c32
| boot:
`

There was supposed to be a nice boot menu, but since vesamenu.c32 failed
to load it was not displayed.  TAB completion at the boot prompt and
actually booting worked, though.

This may be related to #918915, although that bug is already archived.


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

Kernel: Linux 5.3.8-nouveau (SMP w/2 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)

-- no debconf information

Bug#895649: inkscape: Segfault closing dialog after importing PDF

[Omari Stephens]

I just ran into (and resolved) this.  It appears to be a packaging / 
dynamic-linking problem.  Fundamentally, it seems that inkscape is not 
compatible with having multiple versions of libpoppler present and 
usable.  This also explains why this issue is so consistent for the 
people who encounter it, but never occurs for the people who don't 
encounter it.


My first thought, on seeing the ldd output in this bug, was "isn't it 
weird that inkscape is picking up two different versions of the same 
library?"  This turned out to be the fundamental issue.


My ldd output looked like this when I was experiencing the crash:
$ldd /usr/bin/inkscape | grep poppler
    libpoppler.so.82 => /usr/lib/x86_64-linux-gnu/libpoppler.so.82 
(0x7f09b1c4b000)
    libpoppler-glib.so.8 => 
/usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 (0x7f09b19ef000)
    libpoppler.so.72 => /usr/lib/x86_64-linux-gnu/libpoppler.so.72 
(0x7f09a8e74000)


I then checked to see which versions of libpoppler were installed.  It 
was a whole bunch of them:

15:20:51> [xsdg{angular}@/usr/lib/x86_64-linux-gnu]
$dpkg -S libpoppler*
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0
libpoppler-cpp-dev:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.3.0
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.3.0
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.3.0
libpoppler-glib-dev: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68.0.0
libpoppler-dev:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72.0.0
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82.0.0
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74.0.0
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64.0.0
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64.0.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68.0.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68.0.0
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72.0.0
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72.0.0
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74.0.0
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74.0.0
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80.0.0
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82.0.0

I uninstalled all of the deprecated versions and upgraded to the latest:
(excerpt from /var/log/aptitude):
[REMOVE (PURGE)] libpoppler64:amd64 0.48.0-2
[REMOVE (PURGE)] libpoppler68:amd64 0.57.0-2
[REMOVE (PURGE)] libpoppler72:amd64 0.61.1-2
[REMOVE (PURGE)] libpoppler73:amd64 0.62.0-2
[REMOVE (PURGE)] libpoppler74:amd64 0.63.0-2
[REMOVE (PURGE)] libpoppler80:amd64 0.69.0-2
[UPGRADE] gir1.2-poppler-0.18:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-cpp-dev:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-cpp0v5:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-dev:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-glib-dev:amd64 0.61.1-2 -> 0.71.0-6

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Simon McVittie]

On Wed, 30 Oct 2019 at 15:45:19 +0100, Gunnar Hjalmarsson wrote:
> Seeing that you included quite a few patches in this update, I have a
> question as regards the stable releases. Are the commits included in
>  a standalone set
> of commits which would be sufficient for patching the stable releases in
> order to fix the IBus/Qt issue? I'm asking with my Ubuntu glasses on at
> first hand (in Ubuntu 16.04 we have glib2.0 2.48...), but the question does
> reasonably apply to Debian too.

I was hoping to let glib2.0 get some testing in unstable before
backporting anything. A build of GLib with amd64, i386, build-time tests,
autopkgtest and piuparts takes about an hour, and I have to do my actual
job as well, so I can't iterate on this particularly rapidly.

How do the security team want to handle this - as a stable update, or
as a DSA? It isn't a security fix in its own right, but it fixes what
is effectively a regression triggered by fixing CVE-2019-14822 in ibus
(#940267, DSA-4525-1).

The functionally important patches for this particular bug are:

* d/p/credentials-Invalid-Linux-struct-ucred-means-no-informati.patch
* d/p/GDBus-prefer-getsockopt-style-credentials-passing-APIs.patch

The first of those might need minor adjustment to apply in the absence
of d/p/gcredentialsprivate-Document-the-various-private-macros.patch, or
we could just apply that one too - it only adds documentation.

The test in d/p/Add-a-test-for-GDBusServer-authentication.patch would
be reassuring to have, but it is known to fail on non-Linux kernels
(a fix is pending review upstream and included in the 2.62.2-2 Debian
package), and might depend on other, less critical GDBus fixes. For what
it's worth, upstream didn't include it in the initial backport of !1176
to the 2.62.x branch.

smcv

Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150

[Daniel James]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1
Severity: important
File: nouveau

Dear Maintainer,

[Message prepared by reportbug 7.5.3-de10u1 but mailed from Thunderbird 
on a different system]


In Debian 10 "Buster" the Nouveau driver does not start correctly unless 
the "nomodeset" kernel parameter is supplied.


Without "nomodeset" the system boots to a full-screen graphical login 
screen. Login credentials can be entered, but the screen then flashes 
off (black) for a fraction of a second and returns to the login dialog.


With "nomodeset" Debian starts but the screen resolution is not optimal, 
and cannot be changed. The system boots to a graphical login screen with 
the edges black -- apparently a 1280x1024 displayed full-height but 
narrower than the screen. When login credentials are entered the system 
boots but still only shows a 1280x1024 desktop. Attempts to change the 
resolution (e.g. using xrandr to add a new mode and switch to it fail).


The system uses an Asus M2NPV-VM motherboard with NForce 430 chipset and 
GeForce 61500 onboard graphics. The monitor is a Dell U2410 which has a 
native resolution of 1920x1200 pixels.


On Debian 9 "Stretch" it was not necessary to specify "nomodeset", and 
the full screen resolution was used.


This bug report is being prepared from a text console after booting 
WITHOUT "nomodeset". The errors ("EE") at 45.875 seem to be crucial. I 
have compared /var/log/Xorg.0.log files from this system when booting 
Buster and when booting Stretch, and (apart from minor details like 
module version numbers and the time field) the logs are identical up to 
this point.



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51PV 
[GeForce 6150] [10de:0240] (rev a2)


/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)


Xorg X server log files on system:
--
-rw-r--r-- 1 daniel daniel 33547 Oct 13 15:34 
/home/daniel/.local/share/xorg/Xorg.0.log

-rw-r--r-- 1 root   root   26008 Oct 29 16:57 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[45.542]
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[45.542] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[45.542] Current Operating System: Linux welly-buster 4.19.0-6-amd64 
#1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64
[45.542] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64 
root=UUID=4abd25ab-9425-42ee-8612-75c0164d13d5 ro noapic

[45.542] Build Date: 05 March 2019  08:11:12PM
[45.542] xorg-server 2:1.20.4-1 (https://www.debian.org/support)
[45.542] Current version of pixman: 0.36.0
[45.542]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[45.542] Markers: (--) probed, (**) from config file, (==) default 
setting,

(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[45.543] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Oct 29 
16:57:10 2019

[45.543] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[45.543] (==) No Layout section.  Using the first Screen section.
[45.543] (==) No screen section available. Using defaults.
[45.543] (**) |-->Screen "Default Screen Section" (0)
[45.543] (**) |   |-->Monitor ""
[45.544] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[45.544] (==) Automatically adding devices
[45.544] (==) Automatically enabling devices
[45.544] (==) Automatically adding GPU devices
[45.544] (==) Max clients allowed: 256, resource mask: 0x1f
[45.545] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
exist.

[45.545]Entry deleted from font path.
[45.545] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[45.545] (==) ModulePath set to "/usr/lib/xorg/modules"
[45.545] (II) The server relies on udev to provide the list of input 
devices.

If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[45.545] (II) Loader magic: 0x562deaa57e20
[45.545] (II) Module ABI 

Bug#943595: virtualbox-guest-additions-iso: New upstream version available: 6.0.14

[Holger Schröder]

I also wonder why the additions are no longer up to date. It's been that
way at 6.0.12, too.

...

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Michael" == Michael Biebl  writes:

Michael> On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
Michael>  wrote:

>> The bulk of the bug is a discussion about the general approach to
>> allowing Debian users to choose between systemd and elogind (and,
>> therefore, allowing them to run desktoppy kind of software
>> without systemd).  As discussed it seems that this C/R/P is
>> needed to implement the approach which was agreed between the
>> elogind and systemd maintainers.


Michael> I very much disagree with this summary.

Michael> In [1] I clearly expressed that I did not like this
Michael> approach of having a libelogind0 which replaces
Michael> libsystemd0.

That's actually not how I read that discussion.

I read you as grumblingly accepting the necessity of libelogind0 after
Mark explained that it was necessary because of the upstream design.

I suspect I'm not the only one who honestly read what you said as
accepting elogind0 even though it was not your preference.
Michael> I think the best option is still the one I outlined in [1],
Michael> i.e. getting rid of libelogind0 completely in Debian and
Michael> simply ensure that elogind works in combination with
Michael> libsystemd0.

That's inconsistent with the design of elogind.
Mark explored doing that in this bug and outlined why that doesn't work.

Summarizing for those less familiar with libsystemd0 than Michael:
libsystemd0 splits its interface to systemd across a number of things.
A lot of it is in a dbus API.
However, it also assumes a certain structure of how cgroups are layed
out.

Elogind does implement the dbus APIs in question.
However elogind lays out cgroups differently.
So key functionality does not actually work if you use libsystemd0 iwth
elogind.
Asking the Debian elogind maintainer to redesign elogind seems like kind
of a tall ask.

I agree that using libsystemd0 only would be a great option *if it
worked*

Bug#943843: mailutils-doc: missing Breaks+Replaces: mailutils (<< 1:3.7)

[Andreas Beckmann]

Package: mailutils-doc
Version: 1:3.7-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../mailutils-doc_1%3a3.7-1_all.deb ...
  Unpacking mailutils-doc (1:3.7-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/mailutils-doc_1%3a3.7-1_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/mailutils/AUTHORS', which is also in 
package mailutils 1:3.5-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/mailutils-doc_1%3a3.7-1_all.deb


cheers,

Andreas


mailutils=1:3.5-3_mailutils-doc=1:3.7-1.log.gz
Description: application/gzip

Bug#926191: zlib1g-dbg: please mark zlib1g-dbg as Multi-Arch: same

[Witold Baryluk]

Package: zlib1g-dbg
Version: 1:1.2.11.dfsg-1+b1
Followup-For: Bug #926191

Any update on this?

It still is buggy:

$ sudo apt-get install -V zlib1g-dbg:amd64 zlib1g-dbg:i386
Reading package lists... Done
Building dependency tree   
Reading state information... Done
zlib1g-dbg is already the newest version (1:1.2.11.dfsg-1+b1).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 zlib1g-dbg : Conflicts: zlib1g-dbg:i386 but 1:1.2.11.dfsg-1+b1 is to be 
installed
 zlib1g-dbg:i386 : Conflicts: zlib1g-dbg but 1:1.2.11.dfsg-1+b1 is to be 
installed
E: Unable to correct problems, you have held broken packages.
$


I wish zlib migrated to automatic debug packages with `-dbgsym` support
too.

I do need both 32-bit and 64-bit debug packages, as I am debugging some
Mesa issues.

Thanks.




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

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

Versions of packages zlib1g-dbg depends on:
ii  zlib1g  1:1.2.11.dfsg-1+b1

zlib1g-dbg recommends no packages.

zlib1g-dbg suggests no packages.

-- no debconf information

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Michael Biebl]

On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
 wrote:

> The bulk of the bug is a discussion about the general approach to
> allowing Debian users to choose between systemd and elogind (and,
> therefore, allowing them to run desktoppy kind of software without
> systemd).  As discussed it seems that this C/R/P is needed to
> implement the approach which was agreed between the elogind and
> systemd maintainers.


I very much disagree with this summary.

In [1] I clearly expressed that I did not like this approach of having a
libelogind0 which replaces libsystemd0.

My feedback was ignored though, at which point I stopped engaging further.

And since the fallout from the decision to go with this approach
(despite my recommendation not to) was so tiresome and caused so much
friction, this will most likely be my only message regarding this topic.


> I think that it is appropriate that, if possible, the approach taken
> should be one that is agreeable to both sets of maintainers.  That
> makes for the least interpersonal friction (and of course the
> respective sets of maintainers are best placed to foresee issues and
> judge the merits and (in)elegance of possible approaches).
> 
> So my starting point is that it doesn't seem to me to have been
> particularly fruitful to reopen this decision via this bug in this
> way.  But in any case, the decision has been discussed at some length
> here.  It doesn't appear that other options are better.

I think the best option is still the one I outlined in [1], i.e. getting
rid of libelogind0 completely in Debian and simply ensure that elogind
works in combination with libsystemd0.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923244#10
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#943842: RFS: notepadqq/2.0.0~beta1-1 [ITP] -- Notepad++-like editor for Linux

[Alessandro Grassi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: notepadqq
   Version : 2.0.0~beta1-1
   Upstream Author : Daniele Di Sarli 
 * URL : http://notepadqq.altervista.org
 * License : GPL-3+
 * Vcs : https://github.com/notepadqq/notepadqq
   Section : editors

It builds those binary packages:

  notepadqq - Notepad++-like editor for Linux

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/notepadqq/notepadqq_2.0.0~beta1-1.dsc

Changes since the last upload:

   [ Alessandro Grassi ]
   * Initial release. Closes: #740809

Regards,

--
  Alessandro Grassi

Bug#936307: claws-mail: Python2 removal in sid/bullseye

[Matthias Klose]

Control: tags -1 - moreinfo
Control: severity -1 serious

No need for more info. According to
https://lists.debian.org/debian-gtk-gnome/2019/10/msg1.html
pygtk will be removed in bullseye.

Bug#943838: grml2usb: check_for_fat() always fails

[Sven Joachim]

Control: tags -1 + patch
Control: forwarded -1 https://github.com/grml/grml2usb/pull/24

On 2019-10-30 17:09 +0100, Sven Joachim wrote:

> Package: grml2usb
> Version: 0.16.7
> Severity: grave
>
> The check_for_fat() function always fails, no matter what:
>
> ,
> | # file -s /dev/sdc2
> | /dev/sdc2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID
> | "mkfs.fat", sectors/cluster 64, reserved sectors 64, root entries
> | 1024, Media descriptor 0xf8, sectors/FAT 256, sectors/track 32,
> | heads 64, hidden sectors 27265024, sectors 3512319 (volumes > 32
> | MB), serial number 0xadbb, unlabeled, FAT (16 bit)
> | # sudo grml2usb grml96-full_2018.12.iso /dev/sdc2
> | Executing grml2usb version 0.16.7
> | Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
> (Use --fat16 or run mkfs.vfat /dev/sdc2)
> | # grml2usb --fat16 grml96-full_2018.12.iso /dev/sdc2
> | Executing grml2usb version 0.16.7
> | Are you sure you want to format the specified partition with fat16? y/N y
> | Note: you can skip this question using the option --force
> | Formating partition with fat16 filesystem
> | mkfs.fat 4.1 (2017-01-24)
> | Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
> (Use --fat16 or run mkfs.vfat /dev/sdc2)
> `
>
> I am not really a Python expert, but AFAICS the problem is that by
> default Subprocess.open() opens file objects in binary mode, so the
> "filesystem" variable is an array of bytes, and comparing it to a string
> always yields false.

So that was indeed the case, but after fixing it I immediately ran into
another "strings vs bytes" problem in check_boot_flag().  Fortunately
that was the last issue, and now I have a USB stick with GRML on it. :-)
Have not tested whether it actually boots yet, though.

I have sent a pull request on GitHub.

Cheers,
   Sven

Bug#937452: Bug#936307: claws-mail: Python2 removal in sid/bullseye

[Matthias Klose]

Control: tags -1 - moreinfo
Control: severity -1 serious

No need for more info. According to
https://lists.debian.org/debian-gtk-gnome/2019/10/msg1.html
pygtk will be removed in bullseye.

Bug#943840: python3-rrdtool-dbg: missing Breaks+Replaces: rrdtool-dbg

[Andreas Beckmann]

Package: python3-rrdtool-dbg
Version: 1.7.2-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../python3-rrdtool-dbg_1.7.2-2_amd64.deb ...
  Unpacking python3-rrdtool-dbg:amd64 (1.7.2-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-rrdtool-dbg_1.7.2-2_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/python3/dist-packages/rrdtool.cpython-37dm-x86_64-linux-gnu.so', 
which is also in package rrdtool-dbg:amd64 1.7.2-1+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-rrdtool-dbg_1.7.2-2_amd64.deb


cheers,

Andreas


rrdtool-dbg=1.7.2-1+b1_python3-rrdtool-dbg=1.7.2-2.log.gz
Description: application/gzip

Bug#937452: Bug#936307: claws-mail: Python2 removal in sid/bullseye

[Matthias Klose]

On 30.10.19 17:41, Matthias Klose wrote:

Control: tags -1 - moreinfo
Control: severity -1 serious

No need for more info. According to
https://lists.debian.org/debian-gtk-gnome/2019/10/msg1.html
pygtk will be removed in bullseye.


that last email went to the wrong bug report, but no harm done. Just wanted to 
add the link to https://lists.debian.org/debian-gtk-gnome/2019/10/msg1.html

Bug#943841: desktopnova: Depends on gconf

[Yavor Doganov]

Source: desktopnova
Version: 0.8.1-1.2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid bullseye patch

This package build-depends on libgconf2-dev and src:gconf2 will be
removed from Debian soon.

Attached is a patch to move away from GConf, using the same approach
as done with the gnome-shell module.  It is probably a good idea to
update the package description and mention that MATE is also
supported.
Description: Move away from GConf.
Author: Yavor Doganov 
Forwarded: no
Last-Update: 2019-10-30
---

--- desktopnova-0.8.1.orig/src/modules/CMakeLists.txt
+++ desktopnova-0.8.1/src/modules/CMakeLists.txt
@@ -7,7 +7,7 @@
SET_TARGET_PROPERTIES(desktopnova-module-gnome
  PROPERTIES PREFIX ""
 OUTPUT_NAME module_gnome)
-   TARGET_LINK_LIBRARIES(desktopnova-module-gnome ${GCONF2_LIBRARIES})
+   TARGET_LINK_LIBRARIES(desktopnova-module-gnome ${DCONF_LIBRARIES})
SET(TARGETS ${TARGETS} desktopnova-module-gnome)
 ENDIF(ENABLE_MODULE_GNOME)
 
--- desktopnova-0.8.1.orig/src/modules/module_gnome.c
+++ desktopnova-0.8.1/src/modules/module_gnome.c
@@ -16,7 +16,7 @@
 */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -59,14 +59,14 @@
 
 void module_change_wallpaper(const gchar * filename)
 {
-   GConfClient * gconf_client = gconf_client_get_default();
-   if (gconf_client != NULL)
+   DConfClient * client = dconf_client_new();
+   if (dconf_client_is_writable(client, 
"/org/mate/desktop/background/picture-filename"))
{
-   gconf_client_set_string(gconf_client,
-   
"/desktop/gnome/background/picture_filename",
-   filename, NULL);
-   g_object_unref(gconf_client);
+   GVariant *value = g_variant_new("s", filename);
+   if (!dconf_client_write_sync(client, 
"/org/mate/desktop/background/picture-filename", value, NULL, NULL, NULL))
+   g_critical("gnome-module: Failed to set background to 
\"%s\"", filename);
}
+   g_object_unref(client);
 }
 
 #undef _
--- desktopnova-0.8.1.orig/CMakeLists.txt
+++ desktopnova-0.8.1/CMakeLists.txt
@@ -77,9 +77,6 @@
 IF(ENABLE_DBUS)
PKG_CHECK_MODULES(GTHREAD2 REQUIRED gthread-2.0)
 ENDIF(ENABLE_DBUS)
-IF(ENABLE_MODULE_GNOME)
-   PKG_CHECK_MODULES(GCONF2 REQUIRED gconf-2.0)
-ENDIF(ENABLE_MODULE_GNOME)
 IF(ENABLE_MODULE_XFCE_XFCONF)
PKG_CHECK_MODULES(XFCONF REQUIRED libxfconf-0)
 ENDIF(ENABLE_MODULE_XFCE_XFCONF)

Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

[Matthias Klose]

On 27.10.19 17:59, Neil Williams wrote:

Package: python3
Version: 3.7.5-1
Severity: normal

As discussed on IRC and alongside the post to debian-devel-announce, please
review and include this amendment to the Debian Python Policy to cover
the removal of the Python 2 stack as outlined at 
https://wiki.debian.org/Python/2Removal


thanks for doing that.  I think we should make it more clear that there will no 
python binary package, and no python command in bullseye.  You adjusted the 
names, but are still talking about "should" in some place.  If we end up with 
some remaining python 2 packages, then these must depend on python2, 
python2-dbg, and must use the python2 command.

Bug#943838: grml2usb: check_for_fat() always fails

[Sven Joachim]

Package: grml2usb
Version: 0.16.7
Severity: grave

The check_for_fat() function always fails, no matter what:

,
| # file -s /dev/sdc2
| /dev/sdc2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", 
sectors/cluster 64, reserved sectors 64, root entries 1024, Media descriptor 
0xf8, sectors/FAT 256, sectors/track 32, heads 64, hidden sectors 27265024, 
sectors 3512319 (volumes > 32 MB), serial number 0xadbb, unlabeled, FAT (16 
bit)
| # sudo grml2usb grml96-full_2018.12.iso /dev/sdc2
| Executing grml2usb version 0.16.7
| Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
(Use --fat16 or run mkfs.vfat /dev/sdc2)
| # grml2usb --fat16 grml96-full_2018.12.iso /dev/sdc2
| Executing grml2usb version 0.16.7
| Are you sure you want to format the specified partition with fat16? y/N y
| Note: you can skip this question using the option --force
| Formating partition with fat16 filesystem
| mkfs.fat 4.1 (2017-01-24)
| Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
(Use --fat16 or run mkfs.vfat /dev/sdc2)
`

I am not really a Python expert, but AFAICS the problem is that by
default Subprocess.open() opens file objects in binary mode, so the
"filesystem" variable is an array of bytes, and comparing it to a string
always yields false.


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

Kernel: Linux 5.3.8-nouveau (SMP w/2 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)

Versions of packages grml2usb depends on:
ii  grub-pc-bin 2.04-3
ii  grub2-common2.04-3
ii  kmod26-3
ii  mtools  4.0.23-1+b1
ii  python3 3.7.5-1
ii  python3-parted  3.11.2-11
ii  rsync   3.1.3-8
ii  syslinux3:6.04~git20190206.bf6db5b4+dfsg1-1

Versions of packages grml2usb recommends:
ii  genisoimage 9:1.1.11-3+b2
ii  syslinux3:6.04~git20190206.bf6db5b4+dfsg1-1
pn  syslinux-utils  

grml2usb suggests no packages.

-- no debconf information

Bug#936307: claws-mail: Python2 removal in sid/bullseye

[Matthias Klose]

Control: tags -1 + moreinfo

The python-gtk2 dependency has an RC issue now. https://bugs.debian.org/937452
It looks like nobody wants to step up to maintain that. What are you planning 
to do?

Bug#864079: Thank you for the update

[sixerjman]

Thanks for continuing to stay on top of this. I realize it is kind of
complicated with the split out
of the BackupPC software into 3 clients with shifting dependencies, but
next to the operating
system and attendant major subsystems (i.e. networking), the backup
software is the most important subsystem
IMO. As upstream BackupPC continues to release bug fix / enhancement
updates, it is a priority to
continue to track it closely. Again, thank you for your work and attention
to this matter.

Bug#943839: cockpit: New version available (205)

[jim_p]

Package: cockpit
Severity: normal
Tags: upstream

Dear Maintainer,

There has been a new version available from upstream since mid October.
https://cockpit-project.org/blog/cockpit-205.html

Please update the package in the repo. Cockpit on debian usually gets updated
the day it is released from upstream.



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

Kernel: Linux 5.3.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cockpit depends on:
pn  cockpit-bridge  
pn  cockpit-system  
pn  cockpit-ws  

Versions of packages cockpit recommends:
pn  cockpit-dashboard   
pn  cockpit-networkmanager  
pn  cockpit-packagekit  
pn  cockpit-storaged

Versions of packages cockpit suggests:
pn  cockpit-doc   
pn  cockpit-docker
pn  cockpit-machines  
pn  cockpit-pcp   
ii  xdg-utils 1.1.3-1

Bug#923009: fixed 923009 seafile/7.0.2-1

[Salvatore Bonaccorso]

Hi Moritz,

On Wed, Oct 30, 2019 at 11:27:34AM +0100, Moritz Schlarb wrote:
> fixed 923009 seafile/7.0.2-1

I guess I have lost some context here. Can you clarify the following
before I proceed to mark the fixed version for the CVE as well in the
security-tracker?

The question is following: 923009, respective CVE-2013-7469 is
associated with upstream issue
https://github.com/haiwen/seafile/issues/350 . But there ws o closure
of this issue. In the previous BTS message you mentioned that the CVE
assignment was inaccurate, is the issue fixed with the new 0003 patch?

Were you able to reach out to MITRE (via the webform) to have the
references and description updated?

Regards,
Salvatore

Bug#940186: [texlive-latex-recommended] Newfloat conflicts wrapfig and rotating

[Hilmar Preuße]

Am 13.09.2019 um 18:13 teilte Спицын Андрей mit:

Hi,

> --- Please enter the report below this line. ---
> Newfloat conflicts with wrapfig and rotating packages. See upstream issues
> https://gitlab.com/axelsommerfeldt/caption/issues/60
> https://gitlab.com/axelsommerfeldt/caption/issues/61
> 
> Upstream patch is available.
> 
Is that solves in latest upload (made today)?

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



signature.asc
Description: OpenPGP digital signature

Bug#943837: viewnior: Version 1.7 available upstream

[Simon]

Package: viewnior
Version: 1.6-1+b1
Severity: normal

Dear Maintainer,

Version 1.7 is available upstream but Debian repositories still host version
1.6. Can you please update the package?
Thanks.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (450, 'testing'), (400, 'unstable'), (350, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages viewnior depends on:
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libexiv2-14  0.25-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgcc1  1:9.2.1-8
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libglib2.0-0 2.62.2-1
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libstdc++6   9.2.1-8

viewnior recommends no packages.

viewnior suggests no packages.

-- no debconf information

Bug#943836: dependency on python-all-dev?

[Matthias Klose]

Package: src:claws-mail
Version: 3.17.4-1

claws-mail-python-plugin depends on python-all-dev, why a dev package, why all? 
I think python2 would be the right dependency here.

Bug#943835: kwartz-client: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: kwartz-client
Version: 1.1-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for kwartz-client's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-

kwartz-client_1.1-1_pt.po.gz
Description: application/gzip

Bug#943834: 404 error on https://piuparts.d.o/doc/ files

[Santiago R.R.]

Package: piuparts.debian.org
Severity: normal

Different doc-related links seem to be broken:
https://piuparts.debian.org/doc/README.html
https://piuparts.debian.org/doc/piuparts.1.html
http://piuparts.debian.org/doc/README_server.html

Referer to those URLs are https://piuparts.debian.org/
and https://wiki.debian.org/piuparts/piuparts.debian.org

I cannot say if the solution would be to fix those links to point
somewhere else, or to provide piuparts.d.o/doc/

Cheers,

 -- Santiago

Bug#941738: buster-pu: package network-manager/1.14.6-2+deb10u1

[Michael Biebl]

retitle 941738 buster-pu: package network-manager/1.14.6-2+deb10u1
thanks

Am 04.10.19 um 15:20 schrieb Michael Biebl:
> Am 04.10.19 um 15:09 schrieb Michael Biebl:
>> +network-manager (1.14.6-3) stable; urgency=medium
> 
> 1.14.6-3 is unused so far, but I guess it would be better us use
> 1.14.6-2+deb10u1 instead?

I guess the latter is more in line with current practice, so retitling
the bug report accordingly. Updated debdiff attached.


Please let me know if I can proceed with the upload.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/debian/changelog b/debian/changelog
index 7cb171e5a..13658c1c3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+network-manager (1.14.6-2+deb10u1) stable; urgency=medium
+
+  * core: fix file permissions for "/var/lib/NetworkManager/secret_key"
+Patch cherry-picked from upstream.
+  * Fix permissions of /var/lib/NetworkManager/secret_key on upgrades.
+The file mode is supposed to be 0600. (Closes: #941609)
+  * Install directories as created by upstream build system.
+Drop network-manager.dirs and instead use the directories created by the
+upstream build system. Fix permissions of /var/lib/NetworkManager to be
+0700 as it contains possibly sensitive data and should not be
+world-readable.
+  * d/gbp.conf: Set debian-branch to buster
+
+ -- Michael Biebl   Fri, 04 Oct 2019 15:03:20 +0200
+
 network-manager (1.14.6-2) unstable; urgency=medium
 
   * supplicant: fix setting pmf when the supplicant doesn't advertise support
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 478d845ce..3c81df87a 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,4 @@
 [DEFAULT]
 pristine-tar = True
 patch-numbers = False
-debian-branch = master
+debian-branch = buster
diff --git a/debian/network-manager.dirs b/debian/network-manager.dirs
deleted file mode 100644
index e09403be4..0
--- a/debian/network-manager.dirs
+++ /dev/null
@@ -1,10 +0,0 @@
-etc/NetworkManager/conf.d/
-etc/NetworkManager/dispatcher.d/no-wait.d/
-etc/NetworkManager/dispatcher.d/pre-down.d/
-etc/NetworkManager/dispatcher.d/pre-up.d/
-etc/NetworkManager/dnsmasq.d/
-etc/NetworkManager/dnsmasq-shared.d/
-etc/NetworkManager/system-connections/
-usr/lib/NetworkManager/conf.d/
-usr/lib/NetworkManager/VPN/
-var/lib/NetworkManager/
diff --git a/debian/network-manager.install b/debian/network-manager.install
index 0f1e82ae5..3f94d7a46 100644
--- a/debian/network-manager.install
+++ b/debian/network-manager.install
@@ -2,10 +2,7 @@ usr/sbin/NetworkManager
 usr/bin/nm-online
 usr/bin/nmcli
 usr/bin/nmtui*
-usr/lib/NetworkManager/nm-dhcp-helper
-usr/lib/NetworkManager/nm-iface-helper
-usr/lib/NetworkManager/nm-dispatcher
-usr/lib/NetworkManager/nm-initrd-generator
+usr/lib/NetworkManager/
 usr/lib/*/NetworkManager/*/libnm-settings-plugin-ifupdown.so
 usr/lib/*/NetworkManager/*/libnm-device-plugin-*.so
 usr/lib/*/NetworkManager/*/libnm-ppp-plugin.so
@@ -18,7 +15,8 @@ usr/share/dbus-1/system.d/org.freedesktop.NetworkManager.conf
 usr/share/dbus-1/system.d/nm-dispatcher.conf
 usr/share/polkit-1/
 usr/share/bash-completion/
-etc/NetworkManager/dispatcher.d/
+etc/NetworkManager/
+var/lib/NetworkManager/
 lib/udev/rules.d/*.rules
 lib/systemd/system/NetworkManager.service
 lib/systemd/system/NetworkManager-dispatcher.service
diff --git a/debian/network-manager.postinst b/debian/network-manager.postinst
index 0f95087f8..7f0589da6 100644
--- a/debian/network-manager.postinst
+++ b/debian/network-manager.postinst
@@ -24,6 +24,9 @@ case "$1" in
 # org.freedesktop.NetworkManager.settings.modify.system without prior 
authentication
 addgroup --quiet --system netdev
 
+# This directory can contain sensitive data and should not be 
world-readable
+chmod 0700 /var/lib/NetworkManager
+
 NIF=/etc/network/interfaces
 if [ -z "$2" ] && [ -f $NIF ]; then
 ifaces=`grep -v '^#' $NIF | awk '/iface/ {print $2}' | sort -u | 
sed -e 's/lo//' -e '/^$/d' -e 's/^/- /'`
@@ -44,6 +47,12 @@ case "$1" in
 ln -sf  /run/NetworkManager/resolv.conf /etc/resolv.conf
 fi
 fi
+
+if dpkg --compare-versions "$2" lt-nl "1.14.6-3"; then
+if [ -f /var/lib/NetworkManager/secret_key ]; then
+chmod 0600 /var/lib/NetworkManager/secret_key
+fi
+fi
 ;;
 
 abort-upgrade|abort-deconfigure|abort-remove)
diff --git 
a/debian/patches/core-fix-file-permissions-for-var-lib-NetworkManager-secr.patch
 
b/debian/patches/core-fix-file-permissions-for-var-lib-NetworkManager-secr.patch
new file mode 100644
index 0..8e51fa6a4
--- /dev/null
+++ 
b/debian/patches/core-fix-file-permissions-for-var-lib-NetworkManager-secr.patch
@@ -0,0 +1,40 @@
+From: Thomas Haller 
+Date: Tue, 14 May 2019 13:55:41 +0200
+Subject: core: fix file permissions for 

Bug#943833: [src:x11vnc] Drop bundled libvncserver/libvncclient

[Mike Gabriel]

Package: src:x11vnc
Version: 0.9.13-6
Severity: wishlist

Dear maintainer(s) of x11vnc,

I am currently working on a security audit of all VNC related packages  
in Debian and identified packages that partially or completely bundle  
libvncserver and/or libvncclient. Esp. with VNC code, people have  
copy+pasted code fragments into various projects and now ship  
custom-patched and non-security-patched versions of those code files.


For x11vnc, I discovered that the libvncserver and libvncclient shared  
libraries are bundled in upstream's orig tarball, but not used at  
build time. If that is the case, could you please drop those two  
folders from x11vnc with one of the next uploads?


While this is not a functionality improvement, it helps with security  
audits. Please consider removing the libvncclient/ and libvncserver/  
folders from the x11vnc orig tarball. Thanks!


light+love
Mike Gabriel


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp7z0aeAB5kY.pgp
Description: Digitale PGP-Signatur

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Gunnar Hjalmarsson]

Thanks for your work with this, Simon!

Seeing that you included quite a few patches in this update, I have a 
question as regards the stable releases. Are the commits included in 
 a standalone 
set of commits which would be sufficient for patching the stable 
releases in order to fix the IBus/Qt issue? I'm asking with my Ubuntu 
glasses on at first hand (in Ubuntu 16.04 we have glib2.0 2.48...), but 
the question does reasonably apply to Debian too.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#931488: Fixed upstream in jack2 1.9.13

[Joseph Yasi]

This was fixed upstream in jack2 1.9.13. Pushing a new release will
take care of this.

Bug#931332: xserver-xorg-core: X crash on keyboard remapping

[Samuel Thibault]

Just for the record: the patch is commited in master for 1.21, and in
server-1.20-branch for 1.20.6.

Samuel

Bug#864079: Status of this bug?

[Axel Beckert]

Hi,

sixerjman wrote:
> I would like to know if anybody is working on this.

Yes, Jonathan Wiltshire (Cc'ed) pushed a packaging of it to
https://salsa.debian.org/debian/backuppc-rsync

We also had a small Debian-BackupPC-Team meeting at MiniDebConf
Vaumarcus last weekend.

Jonathan wrote, that he's also working on the BackupPC 4 packaging.
But he doesn't seem to have pushed it to Salsa yet.

I though couldn't reach him by mail or IRC recently. (Tried to reach
him twice in the past two weeks, also because of our small team
meeting.) I assume, he's currently on vacation or so.

At the small team meeting we decided to wait a little bit more for his
work on BackupPC.

But I assume that we probably won't do much double work if we check
now what's left for getting backuppc-rsync through the NEW queue.
Especially if it helps wrt. to automatic BinNMUs. Thanks for this
hint. It didn't come to me that this might be an issue.

Will work on this later on this week. Probably won't find time for it
today.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

[Felix Lechner]

Hi,

I also committed another fix, which I found more appropriate after
discussing the issue with Moo's author. The commit message has more
details and is replicated below.

Also, please let us know if your chroot or cowbuilder environment had
libclass-xsaccessor-perl installed. (Note the XS in the name; there
are other similar packages in the archive.)


https://salsa.debian.org/lintian/lintian/commit/b951f0d4d83fa76286d1f4bd5836cf256038f31c

Kind regards,
Felix Lechner

* * *

Clarify boolean return value in Collect::Binary->is_pkg_class. (Closes: #943724)

According to Moo's author haarg, Moo optionally looks for
Class::XSAccessor,  which in turn requires a argument to be passed to a
writer.

The undef return value is interpreted as providing the wrong number of
arguments. Moo's behavior is documented here:

https://metacpan.org/pod/Moo#MOO-AND-CLASS::XSACCESSOR

The availability of Class::XSAccessor determines who sees the bug. The
module was probably installed automatically in the chroot and
cowbuilder environments that gave gise to the bug report.

This can be tested: The error also occurs in logrotate/3.15.1-1 in
Debian stable when libclass-xsaccessor-perl is installed.

Thank you to intrigeri for shedding light on the issue and for
putting forward this merge request:

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

Contrary to the fix proposed there, which forces the value returned to
a scalar in the consuming package, this commit causes ->is_pkg_class
to return 0 instead of undef (which evaluates to an empty list in list
context).

The undef return value is interpreted as providing the wrong number of
arguments in the mechanics behind the accessor _set_is_dummy.

Thanks to ilmari on #perl-help for identifing the proper fix and for
explaining the issue.

As an aside, installing libclass-xsaccessor-perl has another effect in
Lintian. It causes the style tests for POD coverage to fail:

===(   15295;22  33/?  34/?  159/?  97/?  67/?   4/19  0/?  0/?
... )===#   Failed test 'Lintian::Lab is covered'
#   at t/scripts/pod-coverage.t line 52.
# Coverage for Lintian::Lab is 50.0%, with 2 naked subroutines:
#   basedir
#   keep
#   Failed test 'Lintian::Processable::Group is covered'
#   at t/scripts/pod-coverage.t line 52.
# Coverage for Lintian::Processable::Group is 66.7%, with 7 naked
subroutines:
#   binary
#   buildinfo
#   changes
#   lab
#   name
#   source
#   udeb
#   Failed test 'Lintian::Processable::Pool is covered'
#   at t/scripts/pod-coverage.t line 52.
# Coverage for Lintian::Processable::Pool is 66.7%, with 3 naked
subroutines:
#   groups
#   lab
#   unpacker
# Looks like you failed 3 tests of 19.
t/scripts/pod-coverage.t ... Dubious, test
returned 3 (wstat 768, 0x300)
Failed 3/19 subtests

The error that gave rise to the original bug report was:

Usage: Lintian::files::empty_package::_set_is_dummy(self,
newvalue) at /usr/share/lintian/checks/files/empty-package.pm line 42.
internal error: cannot run files check on package
binary:logrotate/3.15.1-1/amd64
warning: skipping check of binary:logrotate/3.15.1-1/amd64

Clarifies the boolean return type to avoid problems with Moo attribute
accessors.