Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd

[Norbert Preining]

Hi Hilmar,

On Fri, 26 Jul 2019, Hilmar Preuße wrote:
> > Should we rewrite the history? Or leave it like it is?
> > 
> Leave it.

Ok.

> I can't promise that I'll have a result soon. As Hurd is not a release
> arch I don't see that as a show stopper. We could fix that in -1+x (with
> x >= 1).

Ok.

We still need to do the replace stuff ... I might be able to look into
it tomorrow, but today my time is running out.

We need for sure replaces: texlive-binaries <= the current version in
sid. Then we disable it for the next upload in tl-binaries.

I am not sure about support files, though.

Probably the only thing necessary

Best

Norbert

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

Bug#933053: libncurses6: Ncurses-based Terminal UI Programs Broken in Debian Buster

[WHR]

Package: libncurses6
Version: 6.1+20181013-2
Severity: important
Tags: a11y

Hello.
Most TUI programs that based on ncurses in Debian buster seem broken.
Affecting programs aptitude(8), cfdisk(8), iftop(8), nano(1), nmon(1) and 
nload(1).
Some screenshots are attached.
May related to bug #905247.
Tested with xfce4-terminal 0.8.3 and libvte-2.90-0.36.
Also tested with CDE 2.3.0 dtterm(1) and this issue dosen't seems affect 
dtterm(1).

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

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

Versions of packages libncurses6 depends on:
ii  libc6  2.28-10
ii  libtinfo6  6.1+20181013-2

Versions of packages libncurses6 recommends:
ii  libgpm2  1.20.7-5

libncurses6 suggests no packages.

-- no debconf information

Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd

[Hilmar Preuße]

On 26.07.19 07:24, Norbert Preining wrote:

Hi Norbert,

> On Thu, 25 Jul 2019, Hilmar Preuße wrote:
>>> hille@debian-amd64-sid
>>>
>> Solved...hopefully. Sorry, missed that.
> 
> Should we rewrite the history? Or leave it like it is?
> 
Leave it.

>> We're lintian clean. Do you have to chance to test the package in a
>> pbuilder chroot (didn't do so yet)? If that works OK, we're ready for
>> "new" I guess.
> 
> Python and ghostscript were missing for the tests. I added them, now it
> builds fine in a clean chroot
> 
Great, thanks!

>> dvisvgm build (and links) fine on Hurd. We have a failure in the test
>> suite. I'll care about that later on.
> 
> Ok, please check that
> 
I can't promise that I'll have a result soon. As Hurd is not a release
arch I don't see that as a show stopper. We could fix that in -1+x (with
x >= 1).

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



signature.asc
Description: OpenPGP digital signature

Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd

[Norbert Preining]

Hi Hilmar,

On Thu, 25 Jul 2019, Hilmar Preuße wrote:
> > hille@debian-amd64-sid
> > 
> Solved...hopefully. Sorry, missed that.

Should we rewrite the history? Or leave it like it is?

> Statical "linking" the md5 calculation code solved the problem.

Thanks

> Have to re-learn that... ;-( Do I have to create the pristine-tar branch
> manually?

That is a bit a pain since you started the way you did. What I did for
your info:

git checkout cdeec9bc651861b682bcd68e871f0a99fc919150
git checkout -b upstream
git checkout master
pristine-tar commit ./dvisvgm_2.7.3.orig.tar.gz

That should do it, since dvisvgm original upstream sources were commited
first into the repo at cdeec9.

> re-create the build tree every time I do a re-build. Patch created and
> committed.

Thanks

> We're lintian clean. Do you have to chance to test the package in a
> pbuilder chroot (didn't do so yet)? If that works OK, we're ready for
> "new" I guess.

Python and ghostscript were missing for the tests. I added them, now it
builds fine in a clean chroot

> dvisvgm build (and links) fine on Hurd. We have a failure in the test
> suite. I'll care about that later on.

Ok, please check that

Thanks for all your work!

Norbert

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

Bug#933052: systemd: Garbled outputs for terminal from systemctl(1)

[WHR]

Package: systemd
Version: 241-5
Severity: normal

Hello.
I found the systemctl(1) command outputs are garbled in my terminal, if auto
terminal paging is disabled.
A screenshot is attached, or it is also available from
http://mygnuos.tk/test/systemctl-terminal-garbled.png
The outputs look normal when auto terminal paging is enable as default
(without the SYSTEMD_PAGER environment variable); however I don't want auto-
paging, and this garbled output has a little affecting on my reading.


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-5
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-5

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 241-5

-- no debconf information

Bug#933051: Updating the mlterm Uploaders list

[Tobias Frost]

Source: mlterm
Version: 3.8.8-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

kmuto has retired, so can't work on
the mlterm package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd

[Hilmar Preuße]

Am 25.07.2019 um 23:53 teilte Hilmar Preuße mit:

Am 25.07.2019 um 20:53 teilte Norbert Preining mit:


Hi,


- I did not push the orig.tar.gz to pristine-tar branch yet, it is on
   [1], please push the code.


Ok, please do so at some point.


Have to re-learn that... ;-( Do I have to create the pristine-tar branch
manually?

hille@debian-amd64-sid:~/devel/build/dvisvgm$ pristine-tar commit
../dvisvgm_2.7.3.orig.tar.gz
pristine-tar: failed to find ref using: git show-ref upstream


I noticed that we don't have neither an pristine-tar nor an upstream
branch. I've committed everything into master. Is it possible to fix the
situation or do we have to re-create the repo from scratch?
Please be so kind to fix it, I'll commit the orig.tar.gz then.

dvisvgm build (and links) fine on Hurd. We have a failure in the test
suite. I'll care about that later on.

ColorTest.cpp:207: Failure
Expected equality of these values:
  uint32_t(color)
Which is: 1717068
  0x1a334du
Which is: 1717069
[  FAILED  ] ColorTest.set (0 ms)
[--] 11 tests from ColorTest (0 ms total)

[--] Global test environment tear-down
[==] 11 tests from 1 test case ran. (10 ms total)
[  PASSED  ] 10 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] ColorTest.set

 1 FAILED TEST
FAIL ColorTest (exit status: 1)

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

Bug#933049: emacspeak FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: emacspeak
Version: 49.0+dfsg-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

emacspeak fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that - using
dh_auto_build - makes emacspeak cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru emacspeak-49.0+dfsg/debian/changelog 
emacspeak-49.0+dfsg/debian/changelog
--- emacspeak-49.0+dfsg/debian/changelog2019-02-10 20:51:25.0 
+0100
+++ emacspeak-49.0+dfsg/debian/changelog2019-07-26 06:18:51.0 
+0200
@@ -1,3 +1,10 @@
+emacspeak (49.0+dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 26 Jul 2019 06:18:51 +0200
+
 emacspeak (49.0+dfsg-3) unstable; urgency=medium
 
   * Add dont-break-on-vm-cruft.patch to avoid installation failure
diff --minimal -Nru emacspeak-49.0+dfsg/debian/rules 
emacspeak-49.0+dfsg/debian/rules
--- emacspeak-49.0+dfsg/debian/rules2019-02-10 20:51:25.0 +0100
+++ emacspeak-49.0+dfsg/debian/rules2019-07-26 06:18:31.0 +0200
@@ -20,7 +20,7 @@
dh  $@
 
 override_dh_auto_build-arch:
-   $(MAKE) TCL_VERSION="" --directory servers/linux-espeak
+   dh_auto_build --sourcedirectory=servers/linux-espeak -- TCL_VERSION=""
 
 override_dh_auto_build-indep:
echo $(DEB_VERSION) > debian_version

Bug#933048: lziprecover FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: lziprecover
Version: 1.21-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lziprecover fails to cross build from source, because it builds for the
build architecture. While dh_auto_configure passes --host, the hand
written ./configure does not recognize that. Instead, one is supposes to
supply a CXX= assignment. Please consider applying the attached patch.

Helmut
diff --minimal -Nru lziprecover-1.21/debian/changelog 
lziprecover-1.21/debian/changelog
--- lziprecover-1.21/debian/changelog   2019-07-16 18:28:30.0 +0200
+++ lziprecover-1.21/debian/changelog   2019-07-26 06:22:15.0 +0200
@@ -1,3 +1,10 @@
+lziprecover (1.21-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Supply CXX to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 26 Jul 2019 06:22:15 +0200
+
 lziprecover (1.21-4) unstable; urgency=medium
 
   * Uploading to sid.
diff --minimal -Nru lziprecover-1.21/debian/rules lziprecover-1.21/debian/rules
--- lziprecover-1.21/debian/rules   2019-07-06 21:20:05.0 +0200
+++ lziprecover-1.21/debian/rules   2019-07-26 06:22:14.0 +0200
@@ -1,8 +1,13 @@
 #!/usr/bin/make -f
 
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh ${@}
 
+override_dh_auto_configure:
+   dh_auto_configure -- 'CXX=$(CXX)'
+
 override_dh_auto_install:
dh_auto_install -- DESTDIR=$(CURDIR)/debian/lziprecover
 

Bug#933050: asmon FTCBFS: hard codes the build architecture compiler

[Helmut Grohne]

Source: asmon
Version: 0.71-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

asmon fails to cross build from source, because the upstream Makefile
hard codes the build architecture compiler gcc. Please consider applying
the attached patch to fix that.

Helmut
diff -u asmon-0.71/asmon/Makefile asmon-0.71/asmon/Makefile
--- asmon-0.71/asmon/Makefile
+++ asmon-0.71/asmon/Makefile
@@ -12,10 +12,10 @@
../wmgeneral/list.o
 
 .c.o:
-   gcc -c -std=gnu89 -Wall $(SOLARIS) $< -o $*.o
+   $(CC) -c -std=gnu89 -Wall $(SOLARIS) $< -o $*.o
 
 asmon: $(OBJS)
-   gcc -o asmon $(OBJS) $(LIBDIR) $(LIBS)
+   $(CC) -o asmon $(OBJS) $(LIBDIR) $(LIBS)
 
 clean::
for i in $(OBJS) ; do \
diff -u asmon-0.71/debian/changelog asmon-0.71/debian/changelog
--- asmon-0.71/debian/changelog
+++ asmon-0.71/debian/changelog
@@ -1,3 +1,12 @@
+asmon (0.71-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Make gcc substituable.
++ Let dh_auto_build pass cross tools to make.
+
+ -- Helmut Grohne   Fri, 26 Jul 2019 06:25:16 +0200
+
 asmon (0.71-6) unstable; urgency=medium
 
   * Correct help synopsis misspelling (Closes: #773002)
diff -u asmon-0.71/debian/rules asmon-0.71/debian/rules
--- asmon-0.71/debian/rules
+++ asmon-0.71/debian/rules
@@ -14,7 +14,7 @@
 build-stamp:
dh_testdir
 
-   $(MAKE) -C asmon
+   dh_auto_build --sourcedirectory=asmon
 
touch build-stamp
 

Bug#932404: firefox-esr, FTBFS "possible zip bomb".

[Adler, Mark]

All,

Thank you Santiago for the report and David for the diagnosis. Though this is 
not a valid zip file, there are in fact no overlapping structures and so there 
should not be a bomb alert.

I have added a commit that initializes the cover with the actual spans of the 
central directory, the Zip64 end of central directory record if present, and 
the end of central directory record (the latter of which may include the Zip64 
end of central directory locator). unzip then processes the funky omni.ja file 
without a bomb alert.

See:


https://github.com/madler/unzip/commit/6d351831be705cc26d897db44f878a978f4138fc

Mark


> On Jul 19, 2019, at 9:53 AM, David Fifield  wrote:
> 
> On Fri, Jul 19, 2019 at 08:30:32AM +0900, Mike Hommey wrote:
>> Download 
>> http://ftp.mozilla.org/pub/firefox/releases/68.0.1/linux-x86_64/en-US/firefox-68.0.1.tar.bz2
>> Extract it
>> Unzip omni.ja
>> 
>> The file *is* funky, but afaik it does not have overlapping components.
> 
> I think I know what's going on here--the Firefox omni.ja file uses an
> unusual zip layout, specific to Firefox, that puts the central directory
> at the *beginning* of the file, rather than the end. This is meant to
> allow for better disk caching when unpacking omni.ja, or something.
> https://bugzilla.mozilla.org/show_bug.cgi?id=559961
> https://bugzilla.mozilla.org/show_bug.cgi?id=589368
> 
> You can see in this code sample, first Firefox looks for the central
> directory at offset 4, then falls back to the usual EOCD search.
> https://hg.mozilla.org/mozilla-central/file/af29567ecdba/modules/libjar/nsZipArchive.cpp#l597
> https://hg.mozilla.org/mozilla-central/file/af29567ecdba/modules/libjar/nsZipArchive.cpp#l638
> 
> You can see this in the output of "zipinfo" as well; the central
> directory is at offset 4, and it shows warning relating to the unusual
> layout. (I'm using zipinfo 6.0-21+deb9u1 from Buster, which hasn't been
> patched yet.)
>   $ zipinfo -v /usr/lib/firefox-esr/omni.ja
> The central directory is 111932 (0001B53Ch) bytes long,
> and its (expected) offset in bytes from the beginning of the zipfile
> is 4 (0004h).
> 
>   warning [/usr/lib/firefox-esr/omni.ja]:  16789751 extra bytes at 
> beginning or within zipfile
> (attempting to process anyway)
>   error [/usr/lib/firefox-esr/omni.ja]:  reported length of central 
> directory is
> -16789751 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
> zipfile?).  Compensating...
> 
> The unzip patch starts by initializing a cover that extends from the
> beginning of the central directory to the end of the file. In the case
> of the Firefox layout, that's the *entire* file, except for the first 4
> bytes. So while none of the file overlap each other, they all appear to
> overlap the central directory.
> https://github.com/madler/unzip/commit/47b3ceae397d21bf822bc2ac73052a4b1daf8e1c#diff-42593f5e58d2da2cb6b6a937a04e16ddR496
> 
> The Firefox layout has also caused problems with 7-Zip:
> https://sourceforge.net/tracker/?func=detail=3065694_id=14481=114481
> 
> One possible solution is to adjust the bomb-cover patch so it only
> covers the actual length of the central directory (and the EOCD)
> separately. In almost all normal zip files, these two structures will be
> adjacent, so the effect will be the same as now.

Bug#932781: gnome-shell crashed on laptop lid close

[Vasudev Kamath]

Simon McVittie  writes:

> Control: tags -1 + moreinfo
>
> On Tue, 23 Jul 2019 at 10:36:59 +0530, Vasudev Kamath wrote:
>> Closing laptop lid normally puts laptop sleep and I get back my session on 
>> reopen. But after recent update
>> I see that I get logged out and closer inspection revealed that gnome-shell 
>> is crashing with following error
>> 
>> [  746.169795] gnome-shell[13847]: segfault at 2300022 ip 
>> 7f3718787e04 sp 7ffd56a0f0b0 error 4 in 
>> libwayland-server.so.0.1.0[7f3718787000+7000]
>
> This looks like the same thing as .
>
>> I managed to get the coredump and backtrace of the same.
>
> To confirm, please could you install libwayland-server-0-dbgsym and
> libmutter-3-0-dbgsym and check this backtrace again?

OK Managed to reproduce same crash and attaching the full backtrace of
the same.

>
>> #2  0x7f9198e77ede in send_xdg_output_events
>> (resource=0x7f9184fc4000, 
>> wayland_output=wayland_output@entry=0x55fa9018cd90, 
>> logical_monitor=logical_monitor@entry=0x55fa926ac9e0, 
>> need_all_events=need_all_events@entry=0, 
>> pending_done_event=pending_done_event@entry=0x7ffca0e09144) at 
>> wayland/meta-wayland-outputs.c:553
>
> If you can type
>
> p *resource

(gdb) p *resource
$1 = {object = {interface = 0x7f5877a155d0, implementation = 0x3c, id = 0}, 
destroy = 0x0, link = {prev = 0x1a0001,
next = 0x7f587831ae60 }, 
deprecated_destroy_signal = {listener_list = {prev = 0x0, next = 
0x564d86380ba0}},
  client = 0x564d85937b40, data = 0x0, version = 0, dispatcher = 
0x7f5808115a10, destroy_signal = {listener_list = {prev = 0x0, next = 0x0}, 
emit_list = {
  prev = 0x0, next = 0x0}}}


Cheers,


[sudo] password for vasudeva.sk:
TIMEPID   UID   GID SIG COREFILE  EXE
Thu 2019-07-25 21:38:01 IST4422  1000  1001  11 present   
/usr/bin/gnome-shell
Fri 2019-07-26 09:15:41 IST   15400  1000  1001   6 present   /usr/bin/emacs-gtk
 vasudeva.sk@bhrigu  ~  sudo coredumpctl gdb 4422 
   ✔  1018  09:16:19
   PID: 4422 (gnome-shell)
   UID: 1000 (vasudeva.sk)
   GID: 1001 (vasudeva.sk)
Signal: 11 (SEGV)
 Timestamp: Thu 2019-07-25 21:37:59 IST (11h ago)
  Command Line: /usr/bin/gnome-shell
Executable: /usr/bin/gnome-shell
 Control Group: /user.slice/user-1000.slice/session-73.scope
  Unit: session-73.scope
 Slice: user-1000.slice
   Session: 73
 Owner UID: 1000 (vasudeva.sk)
   Boot ID: dd6e4472cdef44c284b155d24dafe3e6
Machine ID: feb451d304064b3f8706c8703a20adfd
  Hostname: bhrigu
   Storage: 
/var/lib/systemd/coredump/core.gnome-shell.1000.dd6e4472cdef44c284b155d24dafe3e6.4422.156407087900.lz4
   Message: Process 4422 (gnome-shell) of user 1000 dumped core.

Stack trace of thread 4422:
#0  0x7f5874d53e04 wl_resource_post_event 
(libwayland-server.so.0)
#1  0x7f5877763ede zxdg_output_v1_send_logical_size 
(libmutter-3.so.0)
#2  0x7f58777646fb wayland_output_update_for_output 
(libmutter-3.so.0)
#3  0x7f587776488f on_monitors_changed (libmutter-3.so.0)
#4  0x7f5878318e8d g_closure_invoke (libgobject-2.0.so.0)
#5  0x7f587832c555 signal_emit_unlocked_R 
(libgobject-2.0.so.0)
#6  0x7f58783354ae g_signal_emit_valist 
(libgobject-2.0.so.0)
#7  0x7f5878335b6f g_signal_emit (libgobject-2.0.so.0)
#8  0x7f58776d731f 
meta_monitor_manager_notify_monitors_changed (libmutter-3.so.0)
#9  0x7f58776d9557 meta_monitor_manager_rebuild 
(libmutter-3.so.0)
#10 0x7f584ac6 
meta_monitor_manager_kms_apply_monitors_config (libmutter-3.so.0)
#11 0x7f58776d736c 
meta_monitor_manager_apply_monitors_config (libmutter-3.so.0)
#12 0x7f58776d8334 meta_monitor_manager_ensure_configured 
(libmutter-3.so.0)
#13 0x7f587831b00e g_cclosure_marshal_VOID__BOOLEANv 
(libgobject-2.0.so.0)
#14 0x7f58783190c6 _g_closure_invoke_va 
(libgobject-2.0.so.0)
#15 0x7f587833557d g_signal_emit_valist 
(libgobject-2.0.so.0)
#16 0x7f5878335b6f g_signal_emit (libgobject-2.0.so.0)
#17 0x7f58776c42fd upower_properties_changed 
(libmutter-3.so.0)
#18 0x7f587661e8ee ffi_call_unix64 (libffi.so.6)
#19 0x7f587661e2bf ffi_call (libffi.so.6)
#20 0x7f5878319682 g_cclosure_marshal_generic 
(libgobject-2.0.so.0)
#21 0x7f5878318e8d g_closure_invoke (libgobject-2.0.so.0)
#22 0x7f587832c555 signal_emit_unlocked_R 
(libgobject-2.0.so.0)
#23 0x7f58783354ae g_signal_emit_valist 
(libgobject-2.0.so.0)
   

Bug#933047: RM: libosl -- RoQA; RoQA, RoM, dead upstream

[Tobias Frost]

Package: ftp.debian.org
Severity: normal

Dear ftp-masters,

please remove libosl on request of the maintainer:

> From: Daigo Moriwaki 
> To: Tobias Frost 
> Subject: Re: Fwd: Re: Orphaning packagesy

> Tobias,

> Sorry for the late reply.

> I should have mentioned libosl as well.

> Definitely, libosl is only used by gpsshogi. The upstream, gpsshogi and
> libosl, has no update. It would surely be obsolete.
> I am ok to orphan or remove them from the Debian.

> Thank you for you assistance in advance.

> Best regards,
> Daigo

Cheers, tobi (MIA Team)

Bug#920772: Why is this bug unclassified instead of confirmed

[kts yvuv]

I verify this bug on Debian Buster KDE.  It's reproducible.
So it should be marked as confirmed.  What criteria does a bts bug need to
be listed as confirmed.

Bug#932866: RFS: elpy/1.29.1+40.gb929013-1 -- Emacs Python Development Environment

[Chris Lamb]

tags 932866 + pending
thanks

Hi Nicholas,

> I tagged a new upstream snapshot which included my spelling fix, and
> defends against broken tests that upcoming parso/jedi updates will
> cause (78aea0e).

Neat; uploaded.

> The new grammar and spelling errors will be resolved in the next
> Debian upload based off of a stable upstream release.

Sure thing. Would seem a poor use of one's efforts to patch these
locally, after all...


Best wishes,

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

Bug#932866: RFS: elpy/1.29.1+40.gb929013-1 -- Emacs Python Development Environment

[Nicholas D Steeves]

Control: retitle -1 RFS: elpy/1.29.1+40.gb929013-1 -- Emacs Python Development 
Environment

On Thu, Jul 25, 2019 at 02:17:56PM -0300, Chris Lamb wrote:
> Nicholas D Steeves wrote:
> 
> > > I have commented on mentors.debian.net.
> >
> > Replied :-)
> 
> As have I...
> 

I tagged a new upstream snapshot which included my spelling fix, and
defends against broken tests that upcoming parso/jedi updates will
cause (78aea0e).  I then confirmed the pkg was Policy 4.4.0 compliant
and declared this, and reuploaded.

The new grammar and spelling errors will be resolved in the next
Debian upload based off of a stable upstream release.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#933046: needrestart: restart things in override_rc (libvirtd, gdm, ModemManager etc) when it is safe to do so

[Paul Wise]

Package: needrestart
Version: 3.4-5
Severity: wishlist

Some of the items in override_rc are safe to restart some of the time
but unsafe to restart most of the time. It would be nice to have
mechanisms for services to be queried about whether or not it is safe
to restart them at the current time and then restart them if so.

For example:

Restarting gdm/getty logs user sessions out but if there are no users
logged in then it is perfectly safe to restart them.

Restarting libvirtd probably restarts guest VMs? If there are no
running guest VMs then it is probably fine to restart it.

Restarting NetworkManager or ModemManager probably restarts networking.
If there are no networks of the kind managed by them, then it is
probably fine to restart them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#914151: dlz-ldap-enum FTBFS with bind9 9.11.5

[peter green]

Tags 914151 +patch
Thanks

This turned out to be a simple case of a missing include, a debdiff can be 
found at 
https://debdiffs.raspbian.org/main/d/dlz-ldap-enum/dlz-ldap-enum_1.1.0-1%2Brpi1.debdiff
 . No intent to NMU in Debian.

Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time

[Chris Lamb]

Hi Paul,

> it will take time before it does, as python-django can not migrate
> before reverse dependencies are fixed or removed. The latter isn't very
> nice for your reverse dependencies if you didn't give them proper
> heads-up. The former isn't nice for the python-django users of testing.

Mmm and I see that now. As in, please be assured that I didn't
override those feelings out of a lack of care or concern for the
reverse dependencies and their maintainers; it merely didn't really
occur to me, perhaps in a frenzy of post-Buster release motivation.

What do you suggest going forward regarding this CVE, at least?


Regards,

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

Bug#933045: [Pkg-rust-maintainers] Bug#933045: release.debian.org: rustc can only be cross-compiled on mips; please override "Not built on buildd" blocker

[Ximin Luo]

Control: retitle -1 rustc can only be built for 32-bit mips* by 
cross-compiling; please override "Not built on buildd" blocker

Fixing badly-worded title.

Ximin Luo:
> Package: release.debian.org
> Severity: normal
> 
> Hi, rustc is currently blocked from migration: 
> 
> https://qa.debian.org/excuses.php?package=rustc
> 
>  no, the issue is
>  Not built on buildd: arch mips binaries uploaded by infinity0
>  Not built on buildd: arch mipsel binaries uploaded by infinity0
>  if in doubt → https://release.debian.org/britney/excuses.yaml look for 
> source: rustc and verdicts for that stanza.
> 
>  is that a recent change in policy?
>  it was announced on dda
>  in the most recent release team post there (the one just after release)
> 
>  i see ok. the reason i do this is because rustc mips builds run 
> out of memory
>  they can't be built natively on a mips machine, they have to be 
> cross-built
>  how do you guys think i should proceed?
>  i tried asking buildd a while ago to support cross builds but 
> they were reluctant to do it
>  infinity0: please file a bug against release.debian.org to discuss 
> this
>  not promising anything but that is probably a reason for an exception
>  apparently not everybody agrees...
> 
> <_rene_> infinity0: can't you make it not built with -g or do -g1 or disable 
> some features on mipsen?
> * _rene_ does the -g1 thingy too, for LO
> <_rene_> for anything except amd64 (and i386, but I probably should make it 
> for i386, too, given I also ignore test suite failures there by now...)
>  _rene_: i've already tried all of those things
> <_rene_> mmh, ok
>  and various other llvm options, it's detailed in some thread on 
> pkg-rust-maintainers
> 
> https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-January/004844.html
> https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-January/004887.html
> https://github.com/rust-lang/rust/issues/56888
> 
> X
> 
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), 
> (1, 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 

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

Bug#933045: release.debian.org: rustc can only be cross-compiled on mips; please override "Not built on buildd" blocker

[Ximin Luo]

Package: release.debian.org
Severity: normal

Hi, rustc is currently blocked from migration: 

https://qa.debian.org/excuses.php?package=rustc

 no, the issue is
 Not built on buildd: arch mips binaries uploaded by infinity0
 Not built on buildd: arch mipsel binaries uploaded by infinity0
 if in doubt → https://release.debian.org/britney/excuses.yaml look for 
source: rustc and verdicts for that stanza.

 is that a recent change in policy?
 it was announced on dda
 in the most recent release team post there (the one just after release)

 i see ok. the reason i do this is because rustc mips builds run out 
of memory
 they can't be built natively on a mips machine, they have to be 
cross-built
 how do you guys think i should proceed?
 i tried asking buildd a while ago to support cross builds but they 
were reluctant to do it
 infinity0: please file a bug against release.debian.org to discuss this
 not promising anything but that is probably a reason for an exception
 apparently not everybody agrees...

<_rene_> infinity0: can't you make it not built with -g or do -g1 or disable 
some features on mipsen?
* _rene_ does the -g1 thingy too, for LO
<_rene_> for anything except amd64 (and i386, but I probably should make it for 
i386, too, given I also ignore test suite failures there by now...)
 _rene_: i've already tried all of those things
<_rene_> mmh, ok
 and various other llvm options, it's detailed in some thread on 
pkg-rust-maintainers

https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-January/004844.html
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-January/004887.html
https://github.com/rust-lang/rust/issues/56888

X


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), 
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#933042: python3-sleekxmpp: TLSv1.0-only is incompatible with modern servers

[Gerald Turner]

Control: tags -1 patch

Attached is a trivial patch.

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D
Fix bug #933042 allowing TLS to interoperate with modern servers
Index: sleekxmpp-1.3.3/sleekxmpp/xmlstream/xmlstream.py
===
--- sleekxmpp-1.3.3.orig/sleekxmpp/xmlstream/xmlstream.py
+++ sleekxmpp-1.3.3/sleekxmpp/xmlstream/xmlstream.py
@@ -122,7 +122,7 @@ class XMLStream(object):
 #:
 #: import ssl
 #: xmpp.ssl_version = ssl.PROTOCOL_SSLv23
-self.ssl_version = ssl.PROTOCOL_TLSv1
+self.ssl_version = ssl.PROTOCOL_TLS
 
 #: The list of accepted ciphers, in OpenSSL Format.
 #: It might be useful to override it for improved security


signature.asc
Description: PGP signature

Bug#933044: dgit: should not require --overwrite when debian/changelog contains the version in unstable

[Felipe Sateler]

Package: dgit
Version: 9.6
Severity: normal

Hi,

--overwrite does not trust debian/changelog. If debian/changelog says it
contains version 1.2.3-1, then dgit should trust it and do the fake
merge if required.

Or maybe rephrase this as a question: why doesn't dgit consider the
debian/changelog information authoritative?


As things currently stand, --overwrite is required for most upload
operations, since (a) dgit is not that popular yet, and (b) most
packages use the patches-unapplied layout.


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

Kernel: Linux 4.19.0-5-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:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit depends on:
ii  apt 1.8.2
ii  ca-certificates 20190110
ii  coreutils   8.30-3
ii  curl7.65.1-1
ii  devscripts  2.19.6
ii  dpkg-dev1.19.7
ii  dput-ng [dput]  1.28
ii  git [git-core]  1:2.22.0-1
ii  git-buildpackage0.9.14
pn  libdigest-sha-perl  
ii  libdpkg-perl1.19.7
ii  libjson-perl4.02000-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblocale-gettext-perl  1.07-3+b4
ii  libtext-glob-perl   0.10-1
ii  libtext-iconv-perl  1.7-6
ii  libwww-curl-perl4.17-5
ii  perl5.28.1-6

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:8.0p1-3

Versions of packages dgit suggests:
ii  cowbuilder  0.88
ii  pbuilder0.230.4
ii  sbuild  0.78.1-2

-- no debconf information

Bug#933030: netatalk: Question mark instead of rackmac's icon under macOs

[Jonas Smedegaard]

Hi Laurent,

Quoting maclol (2019-07-25 17:28:51)
> I create a share directory with netatalk (3.1.12~ds-3) installed on BUSTER 
> server.
> I can access to this directory from macOs client like sierra or Mojave.
> But there is a question mark instead of rackmac's icon as indicate in 
> afp.conf file.
> See this capture:
> 
> I commented line 'mimic model = RackMac' and restart service to see if It 
> change something but it doesn't.
> I've created a netatalk server (compiled from sources 3.1.12) under STRETCH 
> and it work very well. The rackmac icon appears in finder.
> I was thinking that the problem could be macOs version, but this is the same 
> in Sierra.
> I know this is not a critical bug.
> Can you make icon of shared directory back ?.

Assuming the configuration of your buster and stretch instances are 
identical, one thing that might vary is if you compiled the Stretch 
build with libssl linkage.  I don't know why that should affect icon but 
just trying to help identify what might be different...


Thanks for reporting,

 - jonas

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

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


signature.asc
Description: signature

Bug#933043: nmu: petsc_3.10.5+dfsg1-1

[Drew Parsons]

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

Hypre 2.16.0 is uploaded to unstable so we need binNMUs for a small
transition.

nmu petsc_3.10.5+dfsg1-1 . ANY . unstable . -m "rebuild against hypre 2.16.0"

After petsc is done, slepc and sundials will need rebuilding

nmu slepc_3.10.2+dfsg1-1 . ANY . unstable . -m "rebuild against hypre 2.16.0"
nmu 3.1.2+dfsg-3 . ANY . unstable . -m "rebuild against hypre 2.16.0"

The small transition tracker is
https://release.debian.org/transitions/html/auto-hypre.html


p.s. Hypre 2.17.0 is being prepared for experimental, but does not build yet.

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

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

Bug#933042: python3-sleekxmpp: TLSv1.0-only is incompatible with modern servers

[Gerald Turner]

Package: python3-sleekxmpp
Version: 1.3.3-4
Severity: normal

Dear Maintainer,

After having upgraded an XMPP server (ejabberd on Debian buster)
connections from python3-sleekxmpp are failing.

ejabberd.log:

  2019-07-25 16:23:06.078 [warning] 
<0.627.0>@ejabberd_c2s:process_terminated:285 (tls|<0.627.0>) Failed to secure 
c2s connection: TLS failed: SSL_do_handshake failed: error:14209102:SSL 
routines:tls_early_post_process_client_hello:unsupported protocol

Code within the sleekxmpp is explicitly setting TLS parameters:

  xmlstream.py line 119:

#: Most XMPP servers support TLSv1, but OpenFire in particular
#: does not work well with it. For OpenFire, set
#: :attr:`ssl_version` to use ``SSLv23``::
#:
#: import ssl
#: xmpp.ssl_version = ssl.PROTOCOL_SSLv23
self.ssl_version = ssl.PROTOCOL_TLSv1

According to Python documentation, this probably ought to be set to
ssl.PROTOCOL_TLS (sans -v1) for widest range of compatibility, see table
at:

  https://docs.python.org/3/library/ssl.html#ssl.SSLContext

Initially I had thought about opening a bug with ejabberd since I cannot
seem to coerce it into allowing TLSv1.0 connections anymore.  However I
suppose that since it's 2019, it's time to heed these deprecation
warnings in the Python docs ;-)


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (601, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages python3-sleekxmpp depends on:
ii  libjs-sphinxdoc 1.8.4-1
ii  python3 3.7.3-1
ii  python3-dnspython   1.16.0-1
ii  python3-pyasn1  0.4.2-3
ii  python3-pyasn1-modules  0.2.1-0.2

Versions of packages python3-sleekxmpp recommends:
ii  python3-dateutil  2.7.3-3
pn  python3-gnupg 
pn  python3-socks | python3-socksipy  

python3-sleekxmpp suggests no packages.

-- no debconf information

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D


signature.asc
Description: PGP signature

Bug#932981: [Freedombox-pkg-team] Bug#932981: Please remove Python 2 support for this package

[Sunil Mohan Adapa]

On 25/07/19 5:40 am, Thomas Goirand wrote:
> Source: django-ranged-response
> Version: 0.2.0-1
> Severity: serious
> Tags: patch
> 
> Hi,
> 
> Attached is a patch to remove Python 2 support for this package,
> needed since the upload of Django 2.2 in Sid.
> 
> Please apply and upload.

Thank you for the patch. I have contacted Federico for the upload. The
attached patches make some further changes.

-- 
Sunil
>From bc757ed3b45e5259fb1c55237d6d31d7c72298a1 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 25 Jul 2019 16:38:00 -0700
Subject: [PATCH 3/3] Ensure that test database is not part of final .deb

Signed-off-by: Sunil Mohan Adapa 
---
 debian/patches/0001-complete-the-test-suite.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/patches/0001-complete-the-test-suite.patch b/debian/patches/0001-complete-the-test-suite.patch
index 4c321e5..9763828 100644
--- a/debian/patches/0001-complete-the-test-suite.patch
+++ b/debian/patches/0001-complete-the-test-suite.patch
@@ -8,7 +8,7 @@
 +settings.configure(DATABASES={
 +'default': {
 +'ENGINE': 'django.db.backends.sqlite3',
-+'NAME': 'db.sqlite3',
++'NAME': 'test/db.sqlite3',
 +}
 +})
 --- a/test/test_response.py
-- 
2.20.1

>From 06ab5066a5c71cb6d22240dbcd762981926585b5 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 25 Jul 2019 16:12:26 -0700
Subject: [PATCH 2/3] Update standards version to 4.4.0

No changes are needed.

Signed-off-by: Sunil Mohan Adapa 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 02657ff..b8deccf 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Build-Depends:
  python3-all,
  python3-django,
  python3-setuptools
-Standards-Version: 4.1.3
+Standards-Version: 4.4.0
 Homepage: https://pypi.python.org/pypi/django-ranged-response/
 Vcs-Browser: https://salsa.debian.org/freedombox-team/django-ranged-response
 Vcs-Git: https://salsa.debian.org/freedombox-team/django-ranged-response.git
-- 
2.20.1

>From 2c5f4e03d9d16a4e32ea53c3406e004bfd70b080 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 25 Jul 2019 15:37:22 -0700
Subject: [PATCH 1/3] Drop auto pkg tests for python2

Signed-off-by: Sunil Mohan Adapa 
---
 debian/tests/control | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index 9bb1757..01e030b 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,5 +1,2 @@
-Test-Command: set -e ; for py in $(pyversions -r 2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import ranged_response; print ranged_response" ; done
-Depends: python-all, python-django-ranged-response
-
 Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import ranged_response; print(ranged_response)" ; done
 Depends: python3-all, python3-django-ranged-response
-- 
2.20.1

Bug#933041: ITP: erlang-metrics -- generic interface to different metrics systems in Erlang

[James Valleroy]

Package: wnpp
Owner: James Valleroy 
Severity: wishlist

* Package name: erlang-metrics
  Version : 2.5.0
  Upstream Author : Benoît Chesneau 
* URL : https://github.com/benoitc/erlang-metrics
* License : BSD-3-clause
  Programming Lang: Erlang
  Description : generic interface to different metrics systems in Erlang

A generic interface to folsom, exometer, grapherl or any compliant
interface. It allows one to set a backend, register a new metric, and
update a metric.

erlang-metrics is a dependency of pleroma (#895050). I plan to maintain
it within erlang-team.



signature.asc
Description: OpenPGP digital signature

Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd

[Gerald Turner]

Package: ejabberd
Version: 18.12.1-2
Severity: normal

Dear Maintainer,

I have been running a Debian ejabberd server since Debian squeeze and
every dist-upgrade since.  In 2014 I setup a private CA using GnuTLS and
had configured ejabberd (version 2.1.5 at the time) to use these
certificates.  Subsequent upgrades through wheezy, jessie, and stretch,
these certificates continued to work, until buster...

  2019-07-21 17:02:14.904 [warning] <0.406.0>@ejabberd_pkix:log_warnings:397 
Invalid certificate in /etc/ssl/certs/unzane/nyarlathotep-rsa-cert.pem: at line 
1: certificate was not signed by its issuer certificate

This message isn't true - if I inspect the certificates using GnuTLS
certtool or OpenSSL x509 tools, the CA signatures are in place.
Furthermore these same certificate files are used by apache2, which had
no trouble with the buster upgrade.  Additionally, when I use OpenSSL's
s_client tool and compare output between port 443 (apache2) and 5223
(ejabberd), they both present the full chain of trust (root CA,
intermediate CA, and host certificates), however ejabberd does something
wicked with the host certificate fingerprint - it's been recomputed to
some random value (doesn't match the PEM file).

After a few days of frustration and every imaginable tweak to
ejabberd.yml, I decided to experiment with re-issuing a certificate
using OpenSSL tools.  This worked, however I cannot commit to using this
experimental process until I abandon my private CA setup.

Attached is a shell script which runs GnuTLS certtool to create a root
CA, intermediate CA, and host certificates in a manner closely
resembling the certificates I had been using since 2014.  The script
depends on four template files, and there is also a log attached showing
what running it looks like (including certificate info dumps).

The resulting certificates can be added to ejabberd.yml and exhibit the
broken signature behavior:

  certfiles:
- "/etc/ejabberd/ejabberd-cert.pem"
- "/etc/ejabberd/ejabberd-key.pem"
- "/etc/ejabberd/private-int-cert.pem"
- "/etc/ejabberd/private-ca-cert.pem"

Then run a command like OpenSSL's s_client and see the signature error:

  $ openssl s_client \
-CAfile private-ca-cert.pem \
-connect ejabberd.example.com:5223 \
-showcerts < /dev/null
  ...
  Verify return code: 7 (certificate signature failure)
  ...

Furthermore the fingerprint seen on the wire is different than what is
in the ejabberd-cert.pem file.

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (701, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages ejabberd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  erlang-asn11:21.2.6+dfsg-1
ii  erlang-base [erlang-abi-17.0]  1:21.2.6+dfsg-1
ii  erlang-base64url   1.0-3
ii  erlang-crypto  1:21.2.6+dfsg-1
ii  erlang-goldrush0.2.0-1
ii  erlang-inets   1:21.2.6+dfsg-1
ii  erlang-jiffy   0.14.11+dfsg-4
ii  erlang-jose1.9.0-1
ii  erlang-lager   3.6.8-1
ii  erlang-mnesia  1:21.2.6+dfsg-1
ii  erlang-odbc1:21.2.6+dfsg-1
ii  erlang-os-mon  1:21.2.6+dfsg-1
ii  erlang-p1-cache-tab1.0.17-1
ii  erlang-p1-eimp 1.0.9-1
ii  erlang-p1-iconv1.0.10-1
ii  erlang-p1-pkix 1.0.0-3
ii  erlang-p1-stringprep   1.0.14-1
ii  erlang-p1-tls  1.0.26-1
ii  erlang-p1-utils1.0.13-1
ii  erlang-p1-xml  1.1.34-1
ii  erlang-p1-xmpp 1.2.8-1
ii  erlang-p1-yaml 1.0.17-1
ii  erlang-p1-zlib 1.0.4-3
ii  erlang-public-key  1:21.2.6+dfsg-1
ii  erlang-ssl 1:21.2.6+dfsg-1
ii  erlang-syntax-tools1:21.2.6+dfsg-1
ii  erlang-xmerl   1:21.2.6+dfsg-1
ii  lsb-base   10.2019051400
ii  openssl1.1.1c-1
ii  ucf3.0038+nmu1

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
ii  apparmor 2.13.2-10
ii  apparmor-utils   2.13.2-10
ii  ejabberd-contrib 0.2018.12.10~dfsg0-3
pn  erlang-luerl 
ii  erlang-p1-mysql  1.0.8-1
pn  erlang-p1-oauth2 
ii  erlang-p1-pam1.0.4-3
ii  erlang-p1-pgsql  1.1.6-2
ii  erlang-p1-sip1.0.27-1
pn  erlang-p1-sqlite3
ii  erlang-p1-stun   1.0.26-1
pn  erlang-redis-client

Bug#932995: Weird having the "daily" preferences clean timer run hourly

[Francesco Poli]

On Thu, 25 Jul 2019 17:11:36 -0400 Anthony DeRobertis wrote:

> First off, thank you for the clear and detailed response.

You're welcome!   :-)

> I've cut it 
> below, because it requires some thought & experimentation (I've also had 
> "fun" with network-online.target)

Exactly...

> — so quickly responding to only the 
> easy part for now. Anyway, the easy part:
> 
> On 7/25/19 4:57 PM, Francesco Poli wrote:
> > I honestly thought that "Daily apt-listbugs preferences cleanup" could
> > fit, but I am not an English native speaker, and I would be happy to
> > get a suggestion for a better wording.
> I'd suggest just strike the word "Daily". Just use "apt-listbugs 
> preferences cleanup" (or put something like "Scheduled" or "Routine" in 
> front if you want to avoid starting with a lowercase letter.

This is funny, because I thought that the word "daily" could be useful
*exactly* to inform/reassure the user that the cleanup is actually
performed (at most) once a day, appearances aside.

But maybe it turns out to be a bit confusing, I don't know...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpBVTnnlF6RZ.pgp
Description: PGP signature

Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd

[Hilmar Preuße]

Am 25.07.2019 um 20:53 teilte Norbert Preining mit:

Hi,


a few things:
- your email is not configured for git, git lists
hille@debian-amd64-sid
   as email.


Solved...hopefully. Sorry, missed that.


E: dvisvgm: possible-gpl-code-linked-with-openssl


That is still open.


Statical "linking" the md5 calculation code solved the problem.


- I did not push the orig.tar.gz to pristine-tar branch yet, it is on
   [1], please push the code.


Ok, please do so at some point.


Have to re-learn that... ;-( Do I have to create the pristine-tar branch
manually?

hille@debian-amd64-sid:~/devel/build/dvisvgm$ pristine-tar commit
../dvisvgm_2.7.3.orig.tar.gz
pristine-tar: failed to find ref using: git show-ref upstream


- you can't build the package twice using debuild. The reason is that
   make distclean deletes the manual page, which is not re-created during
   build. I've opened [2] for now.


So what, that is not a requirement. I have several packages with similar
problems.


I'm aware of this. However I find it very convenient if I don't have to
re-create the build tree every time I do a re-build. Patch created and
committed.

We're lintian clean. Do you have to chance to test the package in a
pbuilder chroot (didn't do so yet)? If that works OK, we're ready for
"new" I guess.

Date: Fri, 26 Jul 2019 03:53:10 +0900
-> Is that your normal working time?

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

Bug#932995: Weird having the "daily" preferences clean timer run hourly

[Anthony DeRobertis]

First off, thank you for the clear and detailed response. I've cut it 
below, because it requires some thought & experimentation (I've also had 
"fun" with network-online.target) — so quickly responding to only the 
easy part for now. Anyway, the easy part:


On 7/25/19 4:57 PM, Francesco Poli wrote:

I honestly thought that "Daily apt-listbugs preferences cleanup" could
fit, but I am not an English native speaker, and I would be happy to
get a suggestion for a better wording.
I'd suggest just strike the word "Daily". Just use "apt-listbugs 
preferences cleanup" (or put something like "Scheduled" or "Routine" in 
front if you want to avoid starting with a lowercase letter.

Bug#932847: libbinutils: Can no longer link to Qt provided amd64 libraries - "error adding symbols: bad value"

[Pierre]

On Thursday, July 25, 2019 11:19:37 PM CEST you wrote:
> Control: tags -1 + moreinfo
> 
> On 23.07.19 22:35, Pierre Ducroquet wrote:
> > Package: libbinutils
> > Version: 2.32.51.20190707-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > After upgrading from 2.31.1-16 to 2.32.51.20190707-1, linking to Qt-
provided QtWebEngine fails with the following error:
> >> g++- -Wl,-rpath,/home/snoopy/Qt/5.12.3/gcc_64/lib
> >> -Wl,-rpath-link,/home/snoopy/Qt/5.12.3/gcc_64/lib  -o my-app *.o
> >> -L/usr/lib/ -l:libstlink.so.1 -lusb-1.0
> >> -L/home/snoopy/Qt/5.12.3/gcc_64/lib -lQt5QuickControls2 -lQt5WebEngine
> >> -lQt5WebEngineCore -lQt5Quick -lQt5Gui -lQt5WebChannel -lQt5Qml
> >> -lQt5Network -lQt5Positioning -lQt5Test -lQt5Sql -lQt5SerialPort
> >> -lQt5Core -lGL -lpthread> 
> > /usr/bin/ld: /home/snoopy/Qt/5.12.3/gcc_64/lib/libQt5WebEngineCore.so:
> > error adding symbols: bad value
> please could you provide the object files used for that link, or tell me
> which package you are trying to build?

Hello

The whole procedure to reproduce is as follow (with the Qt-provided 'official' 
5.12.3 amd64 build from www.qt.io installed in ~/Qt/5.12.3):

$ mkdir /tmp/hello-crash
$ cd /tmp/hello-crash
$ echo "int main (int, char**) { return 0; }" > main.cpp
$ ~/Qt/5.12.3/gcc_64/bin/qmake -project
$ echo "QT += webengine" >> hello-crash.pro 
$ mkdir build
$ cd build
$ ~/Qt/5.12.3/gcc_64/bin/qmake ..
Info: creating stash file /tmp/hello-crash/build/.qmake.stash
$ make -j 8
…
/usr/bin/ld: /home/snoopy/Qt/5.12.3/gcc_64/lib/libQt5WebEngineCore.so: error 
adding symbols: bad value
collect2: error: ld returned 1 exit status
make: *** [Makefile:249: hello-crash] Error 1

Regards

 Pierre


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

Bug#933038: Orca causes shutdown process to hang

[thomasw]

Package: Orca

Sometimes when shutting down the machine with Orca running, it takes a long 
time to shut down with a countdown about  a stop job running. I think the 
problem is that at-spi registry daemon is killed before Orca which prevents 
Orca from responding to the signal to stop running but I am not sure.

Bug#933039: RM: nagios2mantis -- RoQA; unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove nagios2mantis. It's RC-buggy since 2016, has missed
two stable releases and the last maintainer upload was in 2014.

Also, mantis was also removed from Debian.

Cheers,
Moritz

Bug#933037: RM: hg-fast-export -- RoQA; unmaintained, broken with mercurial 4.6

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove hg-fast-export. It's unmaintained, noone adopted it since 2014
and the version in the archive is incompatible with current Mercurial (#900375)

Cheers,
Moritz

Bug#919059: ensymble: Time to retire

[Moritz Mühlenhoff]

On Sat, Jan 12, 2019 at 12:12:46PM +, Dominic Hargreaves wrote:
> Source: ensymble
> Version: 0.29-1
> Severity: serious
> Justification: maintainer
> 
> I'm going to hazard a guess and say that there is absolutely nobody
> using this in Debian. Certainly popcon indicates that way. As far as
> I can see there is no active development upstream since 2010 and now
> active VCS (it's on Google Code archive).
> 
> Whilst the package might still work, I have no easy way to test this.
> 
> So let's not release it any more. If anyone reading this disagrees,
> let me know! 

Noone stepped forward for half a year, seems safe to remove it, it appears.

Cheers,
Moritz

Bug#933036: buster-pu: package postgresql-common/200+deb10u2

[Christoph Berg]

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

Please consider postgresql-common 200+deb10u2 for buster. It fixes a
critical problem when pg_upgradecluster is used *twice* on the same
cluster. (The first upgrade is ok, but the second upgrade will
maneuver the system into a state where pg_dropcluster will delete the
data of the wrong cluster.) #931635.

The actual update is small (don't update postgresql.auto.conf, and
when postgresql.auto.conf is already bad, don't read data_directory
from it), but the diff also includes test coverage for the problem.

Debdiff:

No differences were encountered between the control files

diff -Nru postgresql-common-200+deb10u1/debian/changelog 
postgresql-common-200+deb10u2/debian/changelog
--- postgresql-common-200+deb10u1/debian/changelog  2019-04-12 
14:32:52.0 +0200
+++ postgresql-common-200+deb10u2/debian/changelog  2019-07-25 
23:04:54.0 +0200
@@ -1,3 +1,21 @@
+postgresql-common (200+deb10u2) buster; urgency=high
+
+  DATA LOSS WARNING: pg_upgradecluster from postgresql-common 200,
+  200+deb10u1, 201, and 202 will corrupt the data_directory setting when used
+  *twice* to upgrade a cluster (e.g. 9.6 -> 10 -> 11). This update fixes the
+  original problem, and also heals affected clusters on the next upgrade. No
+  additional steps are required.
+
+  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931635
+
+  * pg_upgradecluster: Don't accidentally set (the wrong!) data_directory in
+postgresql.auto.conf. (Closes: #931635)
+  * PgCommon.pm: Ignore data_directory when set in postgresql.auto.conf.
+  * pg_upgradecluster: Delete data_directory from postgresql.auto.conf in new
+cluster.
+
+ -- Christoph Berg   Thu, 25 Jul 2019 23:04:54 +0200
+
 postgresql-common (200+deb10u1) unstable; urgency=medium
 
   * When upgrading from stretch to buster, all text indexes need to be
diff -Nru postgresql-common-200+deb10u1/PgCommon.pm 
postgresql-common-200+deb10u2/PgCommon.pm
--- postgresql-common-200+deb10u1/PgCommon.pm   2019-03-01 15:17:21.0 
+0100
+++ postgresql-common-200+deb10u2/PgCommon.pm   2019-07-25 23:00:10.0 
+0200
@@ -210,6 +210,7 @@
 my $data_directory = cluster_data_directory($version, $cluster, 
\%conf);
 my %auto_conf = read_conf_file "$data_directory/postgresql.auto.conf";
 foreach my $guc (keys %auto_conf) {
+next if ($guc eq 'data_directory'); # defend against 
pg_upgradecluster bug in 200..202
 $conf{$guc} = $auto_conf{$guc};
 }
 }
diff -Nru postgresql-common-200+deb10u1/pg_upgradecluster 
postgresql-common-200+deb10u2/pg_upgradecluster
--- postgresql-common-200+deb10u1/pg_upgradecluster 2019-04-12 
14:32:49.0 +0200
+++ postgresql-common-200+deb10u2/pg_upgradecluster 2019-07-25 
23:00:10.0 +0200
@@ -67,7 +67,12 @@
 };
 
 # adapt paths to configuration files
-$set->('data_directory', $newinfo{'pgdata'});
+if ($configfile eq 'postgresql.conf') {
+$set->('data_directory', $newinfo{'pgdata'});
+} else {
+# fix bug in pg_upgradecluster 200..202
+$deprecate->(\%c, 'data_directory', 'not valid in 
postgresql.auto.conf');
+}
 for my $guc (qw(hba_file ident_file external_pid_file 
stats_temp_directory)) {
 next unless (defined $c{$guc});
 my $val = $c{$guc};
@@ -154,7 +159,7 @@
 if ($newversion >= '9.4') {
 $deprecate->(\%c, 'krb_srvname', 'native krb5 authentication 
deprecated in favor of GSSAPI');
 # grab dsmt from the new config just written by initdb
-unless ($c{dynamic_shared_memory_type}) {
+if (not $c{dynamic_shared_memory_type} and $configfile eq 
'postgresql.conf') {
 $set->('dynamic_shared_memory_type', 
($newinfo{config}->{dynamic_shared_memory_type} || 'mmap'));
 }
 }
diff -Nru postgresql-common-200+deb10u1/t/040_upgrade.t 
postgresql-common-200+deb10u2/t/040_upgrade.t
--- postgresql-common-200+deb10u1/t/040_upgrade.t   2019-04-12 
14:32:49.0 +0200
+++ postgresql-common-200+deb10u2/t/040_upgrade.t   2019-07-25 
23:00:10.0 +0200
@@ -11,7 +11,7 @@
 use TestLib;
 use PgCommon;
 
-use Test::More tests => (@MAJORS == 1) ? 1 : 115 * 3;
+use Test::More tests => (@MAJORS == 1) ? 1 : 121 * 3;
 
 if (@MAJORS == 1) {
 pass 'only one major version installed, skipping upgrade tests';
@@ -113,9 +113,12 @@
 is_program_out 'postgres', "pg_conftool $MAJORS[0] upgr set log_statement all",
 0, '', 'set postgresql.conf parameter';
 SKIP: {
-skip 'postgresql.auto.conf not supported before 9.4', 2 if ($MAJORS[0] < 
9.4);
+skip 'postgresql.auto.conf not supported before 9.4', 6 if ($MAJORS[0] < 
9.4);
+is_program_out 'postgres', "psql -qc \"ALTER SYSTEM SET ident_file = 
'/etc/postgresql/$MAJORS[0]/upgr/pg_ident.conf'\"",
+0, '', 'set ident_file in postgresql.auto.conf';
 is_program_out 'postgres', 

Bug#933035: dmtcp: Should this package be removed?

[Moritz Muehlenhoff]

Source: dmtcp
Severity: serious

The last upload was in 2014 and it's RC-buggy for a long time, it missed two
stable releases already.

Cheers,
Moritz

Bug#933032: Add Salsa-CI integration

[Emmanuel Bourg]

Le 25/07/2019 à 22:45, Otto Kekäläinen a écrit :

> Could you please add Salsa-CI integration?
> This add confidence that everything works and makes it easier to test
> for regressions before upload.
> 
> MR available at
> https://salsa.debian.org/java-team/mariadb-connector-java/merge_requests/1
> Additionally you also need to activate the CI from the project settings.
> 
> See 
> https://www.slideshare.net/ottokekalainen/how-mariadb-packaging-uses-salsaci-to-ensure-smooth-upgrades-and-avoid-regressions#5

Hi Otto,

What will that do exactly? I looked at the slides but I'm not sure to
understand.

Note that when I update the package I push the changes to Salsa just
once after I uploaded it, so I don't know what benefit this CI would bring.

Emmanuel Bourg

Bug#930228: partman-crypto: cryptsetup's initramfs integration was moved to a separate package

[Ben Hutchings]

On Thu, 2019-07-25 at 01:02 -0300, Guilhem Moulin wrote:
> Control: severity -1 normal
> 
> On Sat, 08 Jun 2019 at 22:05:42 +0200, Guilhem Moulin wrote:
> > Our (cryptsetup maintaining team) plan is to rename ‘cryptsetup-run’ to
> > ‘cryptsetup’ once Buster is released, hence this bug should be RC at
> > this point: with `apt-install cryptsetup` the initramfs integration
> > won't be installed anymore.
> 
> Since 2:2.1.0-6 we reclaimed the name ‘cryptsetup’:
> 
> Package: cryptsetup
> Recommends: cryptsetup-initramfs, cryptsetup-run
> Description: disk encryption support - startup scripts
> 
> Package: cryptsetup-initramfs
> Depends: cryptsetup
> Description: disk encryption support - initramfs integration
> 
> Package: cryptsetup-run
> Depends: cryptsetup
> Description: transitional dummy package for cryptsetup
> 
> Thanks to the Recommends: d-i will automatically pull the initramfs
> integration, at least on systems where APT::Install-Recommends hasn't
> been turned off by preseeding.  (The Recommends: cryptsetup-run is there
> to improve the upgrade path, cf. #932625.)  I'm therefore only raising
> the severity to ‘normal’.

APT::Install-Recommends is only enabled after the base-installer phase.
of installation.  I don't know what stage cryptsetup is installed at,
but I suggest it's worth checking that this assumption is correct.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source




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

Bug#930846: partman-auto-lvm: debconf show guided_size during auto install

[Holger Wansing]

Hi,

Laura Arjona Reina  wrote:
> Hi all
> 
> El 15/7/19 a las 12:36, Holger Wansing escribió:
> > Hi,
> > 
> > Steve McIntyre  wrote:
> >> On Sat, Jun 22, 2019 at 01:05:01PM +0200, Baptiste BEAUPLAT wrote:
> >>> Tags: patch
> >>>
> >>> Added patch:
> >>> https://salsa.debian.org/installer-team/installation-guide/merge_requests/7
> >>
> >> Merged, thanks for your contribution!
> > 
> > This has been fixed in the installation-guide package, version 20190622
> > (currently in stable) has the fix.
> > However, https://www.debian.org/releases/buster/example-preseed.txt
> > still does not have it.
> > 
> > So CC'ing debian-www for assistance
> > 
> 
> I've had a look at the www-master.debian.org
> I see that the installation guide has been generated on 20190623 but the 
> example-preseed.txt file has date 20190324.
> 
> I guess something went wrong with that file, and since there has not been 
> changes in the installation guide since then, the build has not been retried.
> 
> In our cron job, I've temporarily removed the part where it checks if we need 
> to 
> build or not the guide, to force a rebuild today, and thus have logs to see 
> what 
> happens to that file.
> 
> I'll have a look later today to the logs and will update the bug.

Sadly, that did not fix the problem ...


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#932847: libbinutils: Can no longer link to Qt provided amd64 libraries - "error adding symbols: bad value"

[Matthias Klose]

Control: tags -1 + moreinfo

On 23.07.19 22:35, Pierre Ducroquet wrote:
> Package: libbinutils
> Version: 2.32.51.20190707-1
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading from 2.31.1-16 to 2.32.51.20190707-1, linking to Qt-provided 
> QtWebEngine fails with the following error:
>> g++- -Wl,-rpath,/home/snoopy/Qt/5.12.3/gcc_64/lib 
>> -Wl,-rpath-link,/home/snoopy/Qt/5.12.3/gcc_64/lib  -o my-app *.o -L/usr/lib/ 
>> -l:libstlink.so.1 -lusb-1.0 -L/home/snoopy/Qt/5.12.3/gcc_64/lib 
>> -lQt5QuickControls2 -lQt5WebEngine -lQt5WebEngineCore -lQt5Quick -lQt5Gui 
>> -lQt5WebChannel -lQt5Qml -lQt5Network -lQt5Positioning -lQt5Test -lQt5Sql 
>> -lQt5SerialPort -lQt5Core -lGL -lpthread   
> /usr/bin/ld: /home/snoopy/Qt/5.12.3/gcc_64/lib/libQt5WebEngineCore.so: error 
> adding symbols: bad value

please could you provide the object files used for that link, or tell me which
package you are trying to build?

Bug#933034: binary all packages need manual decrufting

[Matthias Klose]

Package: ftp.debian.org
Severity: important

binary all packages need manual decrufting.  This came up preparing the python2
removal work, where we likely have some hundred packages which will need 
removal.

Filing this issue to be able to reference from the python side, after chatting
with Luca today.

Bug#933033: maptransfer: Should this package be removed?

[Boyuan Yang]

Package: maptransfer
Version: 0.3-2
Severity: important
X-Debbugs-CC: diese-a...@funzt-halt.net

Dear maptransfer maintainers,

With the proposed Qt4 and Python2 removal, maptransfer is affected since it is
using python-qt4. Since its upstream is inactive since 2010, it looks like
maptransfer will not be migrated to python3 and Qt5 in the near future. As a
result, I propose to remove this package from Debian archive.

Please let me know if there's any thoughts. I will proceed to file the removal
request to the FTP Masters 28 days later.

Thanks,
Boyuan Yang


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

Bug#932995: Weird having the "daily" preferences clean timer run hourly

[Francesco Poli]

Control: severity -1 wishlist
Control: tags -1 + moreinfo


On Thu, 25 Jul 2019 12:51:03 -0400 Anthony DeRobertis wrote:

> Package: apt-listbugs
> Version: 0.1.30
> Severity: minor
> File: /lib/systemd/system/apt-listbugs.timer

Hello Anthony,
nice to read you! Thanks for your bug report.

> 
> I noticed in my logs that systemd is running "Daily apt-listbugs
> preferences cleanup" once per hour, which of course looks like a bug.

Well, it may *look* like a bug, but, actually, it is intentional!

> 
> It seems like what is actually happening is the timer fires hourly and
> then the script that is ultimately run has some logic to check if its
> been a day or not. I imagine this is for cron compatability (I guess on
> systems without anacron?)...

It all began when lintian suggested me to create a systemd timer to
replace the cron job on boxes using systemd as PID 1, see bug [#928041].

[#928041]: 

Since there seems to be no "official" recommended way to create systemd
timers equivalent to cron jobs, I had to cook my own solution.
The current implementation has been developed with a fair amount of
thinking and experimentation.

I am open to suggestions on how to improve/simplify the timer, but
please take into account that there are multiple requirements to meet:

 • the cleaning script should be run similarly on machines with systemd
   as PID 1 and on machines with other init systems (such as sysvinit):
   this means that the timer should run the cleaning script in a way
   similar to a cron.daily job executed by cron or anacron

   → at most once a day

   → catching up missed executions, if the machine is not always up and
 running

   → early in the morning, if the machine is up and running at that time

   → sending the output to root via local mail, if any output is
 produced

 • the cleaning script run should be attempted when the Internet link
   is on and working, if possible (in order to allow apt-listbugs to
   talk to the Debian BTS)

> 
> systemd timers can just do all that, though, with the Persistent=
> option.

I tried the Persistent=true option multiple times: the main problem
with a Persistent=true daily timer is that the catch up happens
immediately after the timer is reactivated.
This can mean that the Internet link is not yet on and working (imagine
a laptop which is booted once a day or less and is not immediately
online, because the user has to log in and connect to a wireless
LAN...) and we miss the only chance to correctly do the cleaning!

Please note that "After=network.target network-online.target" does not
seem to actually guarantee that the Internet link is on and working,
when the catch up happens.

> That'd have a couple advantages, like being easier for the admin
> to understand, easier to customize (e.g., maybe 7am isn't a good time),
> and I suppose probably save a barely measurable amount of electricity.

Please note that anacron also fires up hourly (on machines with systemd
as PID 1) to check whether the daily jobs are to be run or have already
been completed: /lib/systemd/system/anacron.timer

> 
> Anyway, I'm filing this as minor, but feel free to downgrade to
> wishlist.

Done.

> Though I suggest striking the word "daily" in the timer
> Description= if you do.

Which description would you suggest for an apt-listbugs preferences
cleanup activity which is *attempted* hourly (as well as once after each
boot), but *run* at most once a day?

I honestly thought that "Daily apt-listbugs preferences cleanup" could
fit, but I am not an English native speaker, and I would be happy to
get a suggestion for a better wording.


Thanks for your interest in improving apt-listbugs!

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpwoQzuZ_Yhu.pgp
Description: PGP signature

Bug#933032: Add Salsa-CI integration

[Otto Kekäläinen]

Package: mariadb-connector-java

Hello!

Could you please add Salsa-CI integration?
This add confidence that everything works and makes it easier to test
for regressions before upload.

MR available at
https://salsa.debian.org/java-team/mariadb-connector-java/merge_requests/1
Additionally you also need to activate the CI from the project settings.

See 
https://www.slideshare.net/ottokekalainen/how-mariadb-packaging-uses-salsaci-to-ensure-smooth-upgrades-and-avoid-regressions#5

Bug#933030: netatalk: Question mark instead of rackmac's icon under macOs

[maclol]

Package: netatalk
Version: 3.1.12~ds-3
Severity: minor

Dear Maintainer,

I create a share directory with netatalk (3.1.12~ds-3) installed on BUSTER 
server.
I can access to this directory from macOs client like sierra or Mojave.
But there is a question mark instead of rackmac's icon as indicate in afp.conf 
file.
See this capture:

I commented line 'mimic model = RackMac' and restart service to see if It 
change something but it doesn't.
I've created a netatalk server (compiled from sources 3.1.12) under STRETCH and 
it work very well. The rackmac icon appears in finder.
I was thinking that the problem could be macOs version, but this is the same in 
Sierra.
I know this is not a critical bug.
Can you make icon of shared directory back ?.

Thanks for your time and work. have a good day.

Laurent

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

Kernel: Linux 4.19.0-5-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 netatalk depends on:
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libavahi-client3 0.7-4+b1
ii  libavahi-common3 0.7-4+b1
ii  libc62.28-10
ii  libdb5.3 5.3.28+dfsg1-0.5
ii  libdbus-1-3  1.12.16-1
ii  libdbus-glib-1-2 0.110-4
ii  libgcrypt20  1.8.4-5
ii  libglib2.0-0 2.58.3-2
ii  libldap-2.4-22.4.47+dfsg-3
ii  libpam-modules   1.3.1-5
ii  libpam0g 1.3.1-5
ii  libtalloc2   2.1.14-2
ii  libtdb1  1.3.16-2+b1
ii  libtracker-sparql-2.0-0  2.1.8-2
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400
ii  netbase  5.6
ii  perl 5.28.1-6


Versions of packages netatalk recommends:
ii  avahi-daemon  0.7-4+b1
ii  dbus  1.12.16-1
ii  lsof  4.91+dfsg-1
ii  procps2:3.3.15-2
ii  python3   3.7.3-1
ii  python3-dbus  1.2.8-3
ii  tracker   2.1.8-2

Versions of packages netatalk suggests:
pn  quota  

-- Configuration Files:
/etc/netatalk/afp.conf changed:
;
; Netatalk 3.x configuration file
;
[Global]
; Global server settings
spotlight = no
vol preset = default_for_all_vol
log file = /var/log/netatalk.log
uam list = uams_dhx.so,uams_dhx2_passwd.so
save password = yes
mimic model = RackMac
afp listen = 192.168.1.250
hostname = neo
zeroconf = yes
[default_for_all_vol]
cnid scheme = dbd
[afpNeo]
path = /srv/raid/afp
valid users = userafp


-- no debconf information

Bug#933031: pristine-tar: unable to unpack some deltas of version 2

[Коля Гурьев]

Package: pristine-tar
Version: 1.46
Severity: important

pristine-tar of version 1.46 available in Debian Unstable can't unpack
deltas of versions 2 generated by pristine-tar 1.33 from Ubuntu Xenial.

I've committed a tarball for the rlottie package into my Git repository
using pristine-tar 1.33. Then I try to regenerate the tarball inside
Debian chroot and get the next error.

$ pristine-tar --debug --verbose checkout 
../rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz
pristine-tar: git archive --format=tar 9fed0d3da5cfa7eabd4fa8c2590dd86e5b1442e1 
| (cd '/tmp/pristine-tar.2a5pcCDc3n' && tar x)
pristine-tar: tar xf /tmp/pristine-tar.cBbx8nKDp6/tmpin -C 
/tmp/pristine-tar.Dvxlxlx8Qn
pristine-tar: set subdir to rlottie
pristine-tar: subdir is rlottie
pristine-tar: mkdir /tmp/pristine-tar.o0lKEjWozz/workdir
pristine-tar: mv /tmp/pristine-tar.2a5pcCDc3n 
/tmp/pristine-tar.o0lKEjWozz/workdir/rlottie
pristine-tar: rlottie/example/resource/360\302\272_degree.json is listed in the 
manifest but may not be present in the source directory
pristine-tar: creating missing rlottie/example/resource/360\302\272_degree.json
pristine-tar: doing full tree sweep to catch missing files
pristine-tar: tar cf /tmp/pristine-tar.o0lKEjWozz/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.o0lKEjWozz/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.o0lKEjWozz/manifest
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.o0lKEjWozz/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.o0lKEjWozz/recreatetarball) of 
length 12779520 bytes
pristine-tar: tar cf /tmp/pristine-tar.o0lKEjWozz/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.o0lKEjWozz/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.o0lKEjWozz/manifest
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.o0lKEjWozz/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.o0lKEjWozz/recreatetarball) of 
length 12779520 bytes
pristine-tar: set subdir to rlottie
pristine-tar: subdir is rlottie
pristine-tar: mkdir /tmp/pristine-tar.4XNCSF8pDG/workdir
pristine-tar: mv /tmp/pristine-tar.o0lKEjWozz/workdir/rlottie 
/tmp/pristine-tar.4XNCSF8pDG/workdir/rlottie
pristine-tar: tar cf /tmp/pristine-tar.4XNCSF8pDG/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.4XNCSF8pDG/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.4XNCSF8pDG/manifest -H gnu
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.4XNCSF8pDG/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.4XNCSF8pDG/recreatetarball) of 
length 12779520 bytes
pristine-tar: set subdir to rlottie
pristine-tar: subdir is rlottie
pristine-tar: mkdir /tmp/pristine-tar.SY9ZY0yfKg/workdir
pristine-tar: mv /tmp/pristine-tar.4XNCSF8pDG/workdir/rlottie 
/tmp/pristine-tar.SY9ZY0yfKg/workdir/rlottie
pristine-tar: tar cf /tmp/pristine-tar.SY9ZY0yfKg/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.SY9ZY0yfKg/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.SY9ZY0yfKg/manifest -H posix
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball) of 
length 12779520 bytes
pristine-tar: tar cf /tmp/pristine-tar.SY9ZY0yfKg/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.SY9ZY0yfKg/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.SY9ZY0yfKg/manifest
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball) of 
length 12779520 bytes
pristine-tar: Failed to reproduce original tarball. Please file a bug report.
pristine-tar: failed to generate tarball

You'll find problematic delta in the repository of the rlottie package
under the mymedia/weird-delta tag. Steps to reproduce:

git clone https://salsa.debian.org/debian/rlottie.git
git branch pristine-tar mymedia/weird-delta
pristine-tar checkout ../rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz

Here is version numbers of dependencies of both programs.

Name Version  Architecture Description

Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time

[Paul Gevers]

Hi Luke,

On 25-07-2019 22:14, Luke Faraone wrote:
> On 25/07/2019 15:45, Paul Gevers wrote:
> That is just the excuses script's auto-generated output, I think you
> might be reading too much into it. It is a true statement that when the
> package makes it into testing, that bug will be fixed, unless I am
> misunderstanding something.

No, it's not "just the excuses script" output. It shows all relevant
differences between unstable and testing.

> The migration happened in a previous upload[1]:
>  python-django (2:2.2.3-2) unstable; urgency=medium
> * Upload (Python 3.x-only) branch to unstable after the release of
>  Debian "buster".
>* Update debian/gbp.conf to refer to debian/sid after merge.
> 
> … so we did not drop Python3 just for a security update, despite this
> bug's title.

Yes, it's true that all this didn't happen in one upload, but there are
a whole lot of upload of python-django that didn't make it into testing
yet, so this changelog is also relevant:

python-django (1:1.11.22-1) unstable; urgency=medium

  * New upstream security release.

(Closes: #931316)

 -- Chris Lamb   Mon, 01 Jul 2019 17:09:52 -0300

>> The latter isn't very
>> nice for your reverse dependencies if you didn't give them proper
>> heads-up. The former isn't nice for the python-django users of testing.

[...]

> Note that testing is explicitly not recommended for those that care
> about security support[2][3].

Yes, I know very well, but that doesn't mean we shouldn't try or care.

In this case I think the current situation could have been avoided by
letting 1:1.11.22-1 migrate before the upload of the version with the
Python 2 drop. Probably a day would have been enough.

As Moritz just noted this CVE isn't particularly severe, so you can just
bit the bullet. But please inform your reverse dependencies ASAP, so
that everyone can start working on doing the required work. In my
opinion reverting to the pre 2 version for a well defined time to enable
others to do their work isn't so bad socially.

Paul

Bug#519716: at: use nice levels starting from 0

[Jose M Calhariz]

On Thu, Jul 25, 2019 at 08:19:20PM +0200, Christoph Berg wrote:
> Re: Jose M Calhariz 2019-07-18 <20190718145028.pfd7ib2wwvgy7...@calhariz.com>
> > I have been working on a new release of at and took the decision to
> > implement your request.  Are you still interested in this feature?
> > Do you want to review it?
> 
> Hi Jose,
> 
> TBH I can't remember anything about this patch, so please just go
> ahead implementing it.
> 
> Christoph
> 

It is now done, you can check the new version of at daemon from
http://software.calhariz.com/at or check my blog
http://blog.calhariz.com about it.

Kind regards
Jose M Calhariz


-- 
--
O programa D-Base só deve ser acionado com o Windows fechado.


signature.asc
Description: PGP signature

Bug#933029: argus-clients ftbfs in unstable

[Matthias Klose]

Package: src:argus-clients
Version: 1:3.0.8.2-3
Severity: serious
Tags: sid bullseye

seen on all architectures.

[...]
   debian/rules override_dh_systemd_enable
make[1]: Entering directory '/<>'
# Do not enable the file by default on purpose.
# The user should enable it only after making sure the configuration is
# appropriate for his/her computer.
make[1]: Leaving directory '/<>'
   debian/rules override_dh_installinit
make[1]: Entering directory '/<>'
dh_installinit --noscripts --name=rasplit
dh_installinit: --name=rasplit option specified, but init script not found
make[1]: *** [debian/rules:19: override_dh_installinit] Error 255
make[1]: Leaving directory '/<>'
make: *** [debian/rules:9: binary-arch] Error 2

Bug#931413: [debian-edu-commits] [Git][debian-edu/debian-edu-config][master] debian/debian-edu-config.fetch-ldap-cert: Retrieve TJENER's PKI server...

[Holger Levsen]

hi, please include the bug in further mails on this topic and many
thanks for all your work on it! Thanks!

On Thu, Jul 25, 2019 at 03:08:05PM +0200, Wolfgang Schweer wrote:
> On Wed, Jul 24, 2019 at 06:41:42PM +0200, Wolfgang Schweer wrote:
> > > Capturing curl issues by grepping for a 404 is IMHO incomplete. (Turn of
> > > Apache2 and you won't get the 404 and curl | grep ends in some untested
> > > realm).
> > 
> > Good point; this should definitly be improved.
> 
> See my proposal in the revised fetch-ldap-cert script, also attached.
>  
> > > Furthermore, you operate on the bundle certificate file still for
> > > buster<->buster setups.
> > > 
> > > Have you tested with distributing just the rootCA file to the clients?
> > 
> > Yes, works like expected. But then, one more change needs to get into 
> > 10.1 (share/debian-edu-config/tools/create-debian-edu-certs) and it 
> > won't be easy to handle this change upon upgrades.
> 
> The complete diff for all required changes (also for upgrading), fetch 
> script included. Don't know if this is suitable for 10.1, though:
> 
> diff --git a/cf3/cf.finalize b/cf3/cf.finalize
> index 5f3ee1b9..a4185128 100644
> --- a/cf3/cf.finalize
> +++ b/cf3/cf.finalize
> @@ -66,6 +66,8 @@ files:
>  copy_from => local_cp("/etc/ssl/certs/debian-edu-server.crt");
>  "/opt/ltsp/$(default_arch)/etc/ssl/certs/debian-edu-bundle.crt"
>  copy_from => local_cp("/etc/ssl/certs/debian-edu-bundle.crt");
> +"/opt/ltsp/$(default_arch)/etc/ssl/certs/Debian-Edu_rootCA.crt"
> +copy_from => local_cp("/etc/ssl/certs/Debian-Edu_rootCA.crt");
>  
>  commands:
>  
> @@ -124,12 +126,21 @@ commands:
>  
># Adjust certificate rights to make them accessible.
>  
> +  debian.server.installation::
> +
> +"/bin/chmod 0644 /etc/debian-edu/www/Debian-Edu_rootCA.crt"
> +  contain => in_shell;
> +
>debian.ltspclient.installation::
>  
>  "/bin/chmod 0644 /etc/ssl/certs/debian-edu*.crt"
>contain => in_shell;
> +"/bin/chmod 0644 /etc/ssl/certs/Debian-Edu_rootCA.crt"
> +  contain => in_shell;
>  "/bin/chmod 0644 /opt/ltsp/*/etc/ssl/certs/debian-edu*.crt"
>contain => in_shell;
> +"/bin/chmod 0644 /opt/ltsp/*/etc/ssl/certs/Debian-Edu_rootCA.crt"
> +  contain => in_shell;
>  
># Note that 'ltsp-update-image --config-nbd' is needed to generate the 
> image and
># to configure NBD; adjust rights to make the image available for the NBD 
> server.
> diff --git a/cf3/cf.workarounds b/cf3/cf.workarounds
> index 716ed817..671459af 100644
> --- a/cf3/cf.workarounds
> +++ b/cf3/cf.workarounds
> @@ -33,6 +33,12 @@ files:
>link_from => ln_s("/usr/share/debian-edu-config/edu-firefox-nfs"),
>move_obstructions => "true";
>  
> +  # Provide Debian Edu RootCA pub key as download.
> +
> +  debian.server.installation::
> +"/etc/debian-edu/www/Debian-Edu_rootCA.crt"
> +copy_from => local_cp("/etc/ssl/certs/Debian-Edu_rootCA.crt");
> +
>  commands:
>  
>debian.xfce.(ltspclient|ltspserver).installation::
> diff --git a/debian/debian-edu-config.fetch-ldap-cert 
> b/debian/debian-edu-config.fetch-ldap-cert
> index dfec40da..1ee84443 100755
> --- a/debian/debian-edu-config.fetch-ldap-cert
> +++ b/debian/debian-edu-config.fetch-ldap-cert
> @@ -23,14 +23,15 @@ set -e
>  
>  CERTFILE=/etc/ssl/certs/debian-edu-server.crt
>  BUNDLECRT=/etc/ssl/certs/debian-edu-bundle.crt
> +ROOTCACRT=/etc/ssl/certs/Debian-Edu_rootCA.crt
>  
>  do_start() {
>  # Locate LDAP server
>  LDAPSERVER=$(debian-edu-ldapserver)
> -
> +LDAPPORT=636 # ldaps
>  ERROR=false
> -if [ -f /etc/nslcd.conf ] &&
> -   grep -q /etc/ssl/certs/debian-edu-server.crt /etc/nslcd.conf ; then
> +if [ ! -f $CERTFILE ] &&  [ -f /etc/nslcd.conf ] &&
> +grep -q /etc/ssl/certs/debian-edu-server.crt /etc/nslcd.conf ; then
>   if [ -z "$LDAPSERVER" ] ; then
>   msg="Failed to locate LDAP server"
>   log_action_begin_msg "$msg"
> @@ -39,18 +40,43 @@ do_start() {
>   return 1
>   fi
>   [ "$VERBOSE" != no ] && log_action_begin_msg "Fetching LDAP SSL 
> certificate."
> - if curl -f -k https://www.intern/debian-edu-bundle.crt > $BUNDLECRT ; 
> then
> - gnutls-cli --x509cafile $BUNDLECRT --save-cert=$CERTFILE.new 
> ldap.intern < /dev/null
> + if echo | openssl s_client -connect "$LDAPSERVER:$LDAPPORT" 2>/dev/null 
> | grep RootCA ; then
> + if curl -sfk --head -o /dev/null https://www.intern ; then
> + if curl -k https://www.intern/Debian-Edu_rootCA.crt > 
> $ROOTCACRT && \
> + grep -q CERTIFICATE $ROOTCACRT ; then
> + gnutls-cli --x509cafile $ROOTCACRT 
> --save-cert=$CERTFILE.new $LDAPSERVER < /dev/null
> + logger -t fetch-ldap-cert "Fetched rootCA certificate 
> from www.intern."
> + else
> + rm -f $ROOTCACRT
> + if curl -k https://www.intern/debian-edu-bundle.crt > 

Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time

[Moritz Mühlenhoff]

On Thu, Jul 25, 2019 at 08:45:48PM +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Chris,
> 
> On 25-07-2019 18:51, Chris Lamb wrote:
> >> PS: I failed to spot bugs against (some of) those packages communication
> >> the removal, I think that would be nice for those maintainers.
> > 
> > This might have been justifiably and fairly missed as it was dicussed
> > quite some time, possibly years, ago. Not your fault, possibly ours…
> > However, as Brian mentions we do really have no option but to use the
> > 2.x branch of Django these days and, unfortunately, this means that
> > Python 2.x support is accordingly dropped.
> 
> It's OK to move on and it's very OK to do that at the beginning of a
> release cycle. However I expect you to coordinate this with your reverse
> dependencies and *I* didn't see that so far (but of course it's easy for
> me to miss stuff).
> 
> > The packages you list may thus need to be updated or removed. (I'm
> > afraid I haven't looked into the specifics...)
> 
> Sure. Contacting the maintainers, and they can help as well, I guess.
> 
> >> Your package is trying to fix a CVE
> > 
> > Can you elaborate? I'm a little distracted by DebConf stuff but I
> > can't seem to grok what you mean here specifically.
> 
> https://qa.debian.org/excuses.php?package=python-django says this upload
> will fix bug #931316 in testing. That bug is about CVE-2019-12781.
> Testing has not seen the fix yet, and due to the dropping of Python 2,
> it will take time before it does, as python-django can not migrate
> before reverse dependencies are fixed or removed. The latter isn't very
> nice for your reverse dependencies if you didn't give them proper
> heads-up. The former isn't nice for the python-django users of testing.

As mentioned on IRC the scope of CVE-2019-12781 seems acceptable and there's
hardly a month which would better? This seems like a fine tradeoff to me.

If there's something earth-shattering in 1.11, it would still be possible
to fix that one via a targeted 1.11 upload to testing, I assume?

Cheers,
 Moritz

Bug#931832: If you need sponsoring please talk to me

[Andreas Tille]

Hi,

I'd like to help fixing #932457 which is blocked by #931832.  So I'd
love to sponsor rlottie and thus I did

   gbp clone https://salsa.debian.org/mymedia-guest/rlottie

Unfortunately I can not find a debian/ dir in the debian/master branch.
Please explain your Git layout and how I can build it using gbp if you
want to be sponsored.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#933025: ldtp: Porting to python3, or removing?

[Paul Gevers]

Hi Samuel,

On 25-07-2019 21:49, Samuel Thibault wrote:
> python2 is being phased out, so something needs to be done for ldtp. The
> upstream mailing list has been very inactive for a long time. Will there
> really be interest in porting it to python3? Or should we just remove
> ldtp from Debian? (it has no rdep)

While this is true, Debian will carry Python 2 in bullseye if needed,
see https://bugs.debian.org/931659#17. So don't remove it just yet (but
investigating if it's worth porting is very valuable of course).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time

[Luke Faraone]

On 25/07/2019 15:45, Paul Gevers wrote:
>> Can you elaborate? I'm a little distracted by DebConf stuff but I
>> can't seem to grok what you mean here specifically.
> 
> https://qa.debian.org/excuses.php?package=python-django says this
upload
> will fix bug #931316 in testing. That bug is about CVE-2019-12781.
> Testing has not seen the fix yet, and due to the dropping of Python 2,
> it will take time before it does, as python-django can not migrate
> before reverse dependencies are fixed or removed.

That is just the excuses script's auto-generated output, I think you
might be reading too much into it. It is a true statement that when the
package makes it into testing, that bug will be fixed, unless I am
misunderstanding something.

The migration happened in a previous upload[1]:
 python-django (2:2.2.3-2) unstable; urgency=medium
* Upload (Python 3.x-only) branch to unstable after the release of
 Debian "buster".
   * Update debian/gbp.conf to refer to debian/sid after merge.

… so we did not drop Python3 just for a security update, despite this
bug's title.

> The latter isn't very
> nice for your reverse dependencies if you didn't give them proper
> heads-up. The former isn't nice for the python-django users of testing.

I do recall the discussion Chris mentioned, although I admit I can't
find the thread at the moment. (I'm also a bit busy with DebConf)

Note that testing is explicitly not recommended for those that care
about security support[2][3].

[1]:
https://tracker.debian.org/news/1042323/accepted-python-django-2223-2-source-all-into-unstable/
[2]: https://www.debian.org/security/faq#testing
[3]: https://wiki.debian.org/DebianTesting#Considerations

Cheers,
Luke Faraone



signature.asc
Description: OpenPGP digital signature

Bug#933028: emacs: gnus not finding gnutls-cli for use connecting to a pop3s server

[Russell Senior]

Source: emacs
Severity: important

Dear Maintainer,

   * What led up to the situation?

Was on stretch, upgraded to buster, this broke my Gnus configuration, and could 
no longer fetch mail from a dovecot pop3s server.

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

Reverting to stretch (which uses emacs-24) fixed it.

With a .gnus.el file:

   (require 'cl)
   (require 'tramp)
   (require 'gnutls)

   (setq gnus-select-method '(nnml "" (nnml-inhibit-expiry t)))
   (setq mail-sources '((pop :server "mail.foo.com" :port 995 :user 
"username")))


On buster:

$ dpkg -l emacs-nox
||/ Name   Version  Architecture Description
+++-==---==
ii  emacs-nox  1:26.1+1-3.2 amd64GNU Emacs editor (without GUI 
support)

On the dovecot server side, I see:

   Jul 22 13:00:06 dodson dovecot[24176]: pop3-login: Disconnected (no auth 
attempts in 0 secs): user=<>, rip=192.168.x.y, lip=192.168.x.z, TLS: 
read(size=429) failed: Connection reset by peer, session=<4ry/hUqO4qnAqFAE>

On the emacs side, I see a message:

   Mail source (pop :server mail.foo.com :port 995 :user russell) error 
(Process POP not running).  Continue? (yes or no)

Tracing the emacs executable with strace, I never see an execve of gnutls-cli.

8828  13:00:54 execve("/usr/bin/emacs", ["emacs"], 0x7fff802bd1c8 /* 19 vars 
*/) = 0
8829  13:01:00 execve("/usr/bin/movemail", ["/usr/bin/movemail", "--version"], 
0x7ffd990890c0 /* 19 vars */ 
8830  13:01:01 execve("/usr/bin/openssl", ["/usr/bin/openssl", "version"], 
0x7ffd99087890 /* 19 vars */ 


On stretch (it works):

$ dpkg -l emacs-nox
||/ Name   Version  
Architecture Description
+++-==---==
ii  emacs-nox  46.1 
all  GNU Emacs editor (metapackage, without X support)

On the dovecot server side, I see:

   Jul 24 23:50:59 server dovecot[24176]: pop3-login: Login: user=, 
method=PLAIN, rip=192.168.x.y, lip=192.168.x.z, mpid=622, TLS, 
session=

Tracing the emacs executable with strace, I see execve's:

2961  12:56:55 execve("/usr/bin/emacs", ["emacs"], [/* 17 vars */]) = 0
2963  12:56:59 execve("/usr/bin/openssl", ["/usr/bin/openssl", "version"], [/* 
17 vars */] 
2964  12:56:59 execve("/usr/bin/gpg", ["/usr/bin/gpg", "--with-colons", 
"--list-config"], [/* 17 vars */] 
2965  12:57:05 execve("/bin/bash", ["/bin/bash", "-c", "gnutls-cli --x509cafile 
/etc/ssl/certs/ca-certificates.crt -p 995 mail.foo.com"], [/* 18 vars */] 

2965  12:57:05 execve("/usr/bin/gnutls-cli", ["gnutls-cli", "--x509cafile", 
"/etc/ssl/certs/ca-certificates.crt", "-p", "995", "mail.foo.com"], [/* 18 vars 
*/]) = 0


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
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#932993: mailscripts: add email-extract-openpgp-certs

[Daniel Kahn Gillmor]

Hi Sean--

On Thu 2019-07-25 18:22:14 +0100, Sean Whitton wrote:
> On Thu 25 Jul 2019 at 12:44PM -04, Daniel Kahn Gillmor wrote:
>
>> The attached patch supplies a python3 script for extracting OpenPGP
>> certificates from an rfc822/message input stream.  I wrote it (with some
>> guidance from anarcat and others), and i offer it (and the accompanying
>> documentation under the GPLv3 for wider distribution with the
>> mailscripts package.
>>
>> Thanks for maintaining mailscripts!
>
> Thank you, I'm looking forward to looking through this and getting it
> into the archive.
>
> Could you look at DEVELOPER-CERTIFICATE in the repository and add the
> appropriate Signed-off-by line, please?

There are no other Signed-off-by: lines in DEVELOPER-CERTIFICATE.  I've
read it and i agree to it though :P Do you want me to modify it?  or do
you just want a Signed-off-by: in the git-formatted patch?

If it's the latter, I've attached another revision of the patch here,
and it can also be found on the master branch at
https://salsa.debian.org/dkg/mailscripts.git

Let me know if you need anything else.

Thanks for mailscripts!

--dkg

From ae2f662d2200fb7edc4f5cfff90e29e41bd5046f Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Thu, 25 Jul 2019 12:38:52 -0400
Subject: [PATCH] offer email-extract-openpgp-certs

---
 Makefile  |  1 +
 debian/copyright  |  1 +
 email-extract-openpgp-certs   | 99 +++
 email-extract-openpgp-certs.1.pod | 57 ++
 4 files changed, 158 insertions(+)
 create mode 100755 email-extract-openpgp-certs
 create mode 100644 email-extract-openpgp-certs.1.pod

diff --git a/Makefile b/Makefile
index 220aa6f..48cb2fa 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,6 @@
 MANPAGES=mdmv.1 mbox2maildir.1 \
 	notmuch-slurp-debbug.1 notmuch-extract-patch.1 maildir-import-patch.1 \
+	email-extract-openpgp-certs.1 \
 	notmuch-import-patch.1
 
 all: $(MANPAGES)
diff --git a/debian/copyright b/debian/copyright
index b3d860e..d891ffd 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -3,6 +3,7 @@ Collection of scripts for manipulating e-mail on Debian
 
 Copyright (C)2017 Aurelien Aptel
 Copyright (C)2017-2019 Sean Whitton
+Copyright (C)2019 Daniel Kahn Gillmor
 
 These programs are free software: you can redistribute it and/or
 modify it under the terms of the GNU General Public License as
diff --git a/email-extract-openpgp-certs b/email-extract-openpgp-certs
new file mode 100755
index 000..dfe6138
--- /dev/null
+++ b/email-extract-openpgp-certs
@@ -0,0 +1,99 @@
+#!/usr/bin/python3
+
+'''Extract all OpenPGP certificates from an e-mail message
+
+This is a simple script that is designed to take an e-mail
+(rfc822/message) on standard input, and produces a series of
+ASCII-armored OpenPGP certificates on standard output.
+
+It currently tries to find OpenPGP certificates based on MIME types of
+attachments (application/pgp-keys), and by pulling out anything that
+looks like an Autocrypt: or Autocrypt-Gossip: header (see
+https://autocrypt.org).
+
+'''
+
+import email
+import sys
+import base64
+import binascii
+import codecs
+from typing import Optional, Generator
+
+# parse email from stdin
+message = email.message_from_binary_file(sys.stdin.buffer)
+
+def openpgp_ascii_armor_checksum(data: bytes) -> bytearray:
+'''OpenPGP ASCII-armor checksum
+
+(see https://tools.ietf.org/html/rfc4880#section-6.1)'''
+
+init = 0xB704CE
+poly = 0x1864CFB
+crc = init
+for b in data:
+crc ^= b << 16
+for i in range(8):
+crc <<= 1
+if crc & 0x100:
+crc ^= poly
+val = crc & 0xFF
+out = bytearray(3)
+out[0] = (val >> 16) & 0xFF
+out[1] = (val >> 8) & 0xFF
+out[2] = val & 0xFF
+return out
+
+def enarmor_certificate(data: bytes) -> str:
+'''OpenPGP ASCII-armor
+
+(see https://tools.ietf.org/html/rfc4880#section-6.2)'''
+
+cksum = openpgp_ascii_armor_checksum(data)
+key = codecs.decode(base64.b64encode(data), 'ascii')
+linelen = 64
+key = '\n'.join([key[i:i+linelen] for i in range(0, len(key), linelen)])
+return '-BEGIN PGP PUBLIC KEY BLOCK-\n\n' +\
+key + \
+'\n=' + codecs.decode(base64.b64encode(cksum), 'ascii') +\
+'\n-END PGP PUBLIC KEY BLOCK-\n'
+
+def get_autocrypt_keys(m: email.message.Message) -> Generator[str, None, None]:
+'''Extract all Autocrypt headers from message
+
+Note that we ignore the addr= property.
+'''
+hdrs = m.get_all('Autocrypt')
+if hdrs is None: # the email.get_all() api is kindn of sad.
+hdrs = []
+ghdrs = m.get_all('Autocrypt-Gossip')
+if ghdrs is None: # the email.get_all() api is kindn of sad.
+ghdrs = []
+for ac in hdrs + ghdrs:
+# parse the base64 part
+try:
+keydata = str(ac).split('keydata=')[1].strip()
+keydata = keydata.replace(' ', '').replace('\t', 

Bug#933027: vdr-plugin-vnsiserver FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: vdr-plugin-vnsiserver
Version: 1:1.8.0-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

vdr-plugin-vnsiserver fails to cross build from source, because it hard
codes the build architecture pkg-config in the upstream Makefile. It
needs to be made substitutable and available for all targets (not just
via dh_auto_build) to become cross buildable. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru vdr-plugin-vnsiserver-1.8.0/debian/changelog 
vdr-plugin-vnsiserver-1.8.0/debian/changelog
--- vdr-plugin-vnsiserver-1.8.0/debian/changelog2019-07-20 
11:05:44.0 +0200
+++ vdr-plugin-vnsiserver-1.8.0/debian/changelog2019-07-25 
21:57:39.0 +0200
@@ -1,3 +1,10 @@
+vdr-plugin-vnsiserver (1:1.8.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the host architecture pkg-config. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 25 Jul 2019 21:57:39 +0200
+
 vdr-plugin-vnsiserver (1:1.8.0-2) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --minimal -Nru vdr-plugin-vnsiserver-1.8.0/debian/patches/cross.patch 
vdr-plugin-vnsiserver-1.8.0/debian/patches/cross.patch
--- vdr-plugin-vnsiserver-1.8.0/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ vdr-plugin-vnsiserver-1.8.0/debian/patches/cross.patch  2019-07-25 
21:57:28.0 +0200
@@ -0,0 +1,12 @@
+--- vdr-plugin-vnsiserver-1.8.0.orig/Makefile
 vdr-plugin-vnsiserver-1.8.0/Makefile
+@@ -16,7 +16,8 @@
+ ### The directory environment:
+ 
+ # Use package data if installed...otherwise assume we're under the VDR source 
directory:
+-PKGCFG = $(if $(VDRDIR),$(shell pkg-config --variable=$(1) 
$(VDRDIR)/vdr.pc),$(shell pkg-config --variable=$(1) vdr || pkg-config 
--variable=$(1) ../../../vdr.pc))
++PKG_CONFIG ?= pkg-config
++PKGCFG = $(if $(VDRDIR),$(shell $(PKG_CONFIG) --variable=$(1) 
$(VDRDIR)/vdr.pc),$(shell $(PKG_CONFIG) --variable=$(1) vdr || $(PKG_CONFIG) 
--variable=$(1) ../../../vdr.pc))
+ LIBDIR ?= $(call PKGCFG,libdir)
+ LOCDIR = $(call PKGCFG,locdir)
+ PLGCFG = $(call PKGCFG,plgcfg)
diff --minimal -Nru vdr-plugin-vnsiserver-1.8.0/debian/patches/series 
vdr-plugin-vnsiserver-1.8.0/debian/patches/series
--- vdr-plugin-vnsiserver-1.8.0/debian/patches/series   1970-01-01 
01:00:00.0 +0100
+++ vdr-plugin-vnsiserver-1.8.0/debian/patches/series   2019-07-25 
21:57:00.0 +0200
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru vdr-plugin-vnsiserver-1.8.0/debian/rules 
vdr-plugin-vnsiserver-1.8.0/debian/rules
--- vdr-plugin-vnsiserver-1.8.0/debian/rules2019-07-20 11:05:44.0 
+0200
+++ vdr-plugin-vnsiserver-1.8.0/debian/rules2019-07-25 21:57:39.0 
+0200
@@ -6,6 +6,9 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 
+-include /usr/share/dpkg/buildtools.mk
+export PKG_CONFIG ?= pkg-config
+
 PLG_PACKAGE = $(filter-out %-dbg, $(shell dh_listpackages))
 DBG_PACKAGE = $(filter %-dbg, $(shell dh_listpackages))
 

Bug#933026: RFS: budgie-extras/0.9.0-1

[David Mohammed]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "budgie-extras"

 * Package name: budgie-extras
   Version : 0.9.0-1
Upstream Author : Ubuntu Budgie Developers
 * URL : https://github.com/ubuntubudgie/budgie-extras
 * License : GPL-3+
   Section : misc

  It builds those binary packages:

budgie-extras-common - Shared component of budgie-extras applets
budgie-hotcorners-applet - Applet providing hotcorners capabilities
for the Budgie Desktop
budgie-trash-applet - Applet allows access to trash capabilities for
the Budgie Desktop
budgie-quicknote-applet - Applet providing simple notes capability for
the Budgie Desktop
budgie-recentlyused-applet - Applet displays files recently accessed
for the Budgie Desktop
budgie-previews-applet - Applet providing window previews capabilities
for the Budgie Desktop
budgie-workspace-overview-applet - Applet providing quick access to
workspaces for the Budgie Desktop
budgie-workspace-wallpaper-applet - Applet providing per workspace wallpaper
budgie-window-mover-applet - Applet allows moving windows between
workspaces for the Budgie Desktop
budgie-showtime-applet - Applet displaying date and time on the Budgie Desktop
budgie-countdown-applet - Applet providing a countdown capability on
the Budgie Desktop
budgie-keyboard-autoswitch-applet - Applet adding the ability to set a
different keyboard layout per application
budgie-rotation-lock-applet - Applet to lock or unlock the screen rotation
budgie-clockworks-applet - Applet to display clock across multiple time zones
budgie-dropby-applet - Applet to popup when a USB device is connected
budgie-kangaroo-applet - Applet to allow quick file-browsing
budgie-app-launcher-applet - Applet to provide an alternative means to
launch applications
budgie-weathershow-applet - Applet to display the weather and forecast
budgie-takeabreak-applet - Applet to prompt when to take-a-break for a
set period of time
budgie-extras-daemon - Extras daemon for budgie-extras capabilities
budgie-quickchar - GUI to find and choose locale characters
budgie-workspace-stopwatch-applet - Workspace usage tracker for the
budgie desktop
budgie-fuzzyclock-applet - Show the time in a fuzzy way
budgie-brightness-controller-applet - Applet to control the brightness
of the screen

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

  https://mentors.debian.net/package/budgie-extras


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

dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-extras/budgie-extras_0.9.0-1.dsc

Notes:
I am the Debian maintainer for this source package - this mentors
request is due to the new/changed binaries which is not part of my
upload rights

lintiian -i -I --pedantic run as part of the sbuild for unstable and
is lintian free
check-all-the-things run on the source and corrections made to the source
debian/copyright double checked to ensure no  additional/modifications
required due to new binaries and other updates

This upload introduces new built binaries to be authorised by
archive-admins via the NEW queue:
- budgie-takeabreak-applet
- budgie-workspace-stopwatch-applet
- budgie-fuzzyclock-applet
- budgie-brightness-controller-applet
- budgie-extras-daemon
- budgie-quickchar

  Changes since the last upload:

* New release
- See ChangeLog
  * Packaging Changes
- Control: add libwnck-3-dev, libkeybinder-3.0-dev,
  gnome-settings-daemon-dev as build dependencies
- Control: swap python dependencies for ShowTime to vala based
  dependencies, architecture changed to any
- Control: Add packaging for takeabreak applet,
  Workspace Stopwatch applet, Fuzzy Clock applet, Brightness
  Controller applet, Budgie Extras Daemon, Budgie Quickchar
- Drop all patches since they have been incorporated
  in the new release
- Control/Compat update for debhelper 12
- Bump StandardsVersion: no changes required

  Regards,
   David Mohammed

Bug#933024: crac FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: crac
Version: 2.5.2+dfsg-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

crac fails to cross build from source, because it uses the build
architecture pkg-config in its Makefile.am files. Doing so is an
anti-pattern. You should never call pkg-config from a Makefile.am.
Instead such checks should be performed at configure time. The attached
patch implements that and makes crac cross buildable. Please consider
applying it.

Helmut
--- crac-2.5.2+dfsg.orig/configure.ac
+++ crac-2.5.2+dfsg/configure.ac
@@ -282,6 +282,7 @@
 [with_libProgressBar_prefix=""])
 
 dnl Check if we need included ProgressBar library.
+PKG_CHECK_MODULES([PROGRESSBAR],[libProgressBar])
 PB_OK=0
 AS_IF([test "x$with_included_ProgressBar" == "xcheck"],
   [AS_IF([test "x$with_libProgressBar_prefix" != "x"],
@@ -315,6 +316,7 @@
 AC_CHECK_LIB([hts], [hts_hopen], ,
  [AC_MSG_ERROR([htslib not found, see http://www.htslib.org/])])
 
+PKG_CHECK_MODULES([GKARRAYS],[libGkArrays])
 GK_OK=1
 AS_IF([test "x$with_included_GkArrays" != "xyes"],
   [AC_CHECK_LIB([GkArrays],
--- crac-2.5.2+dfsg.orig/src/Makefile.am
+++ crac-2.5.2+dfsg/src/Makefile.am
@@ -149,11 +149,11 @@
 endif
 
 if INCLUDED_GKARRAYS
-  AM_LDFLAGS += `pkg-config --libs libGkArrays`
-  AM_CPPFLAGS += `pkg-config --cflags libGkArrays`
+  AM_LDFLAGS += $(GKARRAYS_LIBS)
+  AM_CPPFLAGS += $(GKARRAYS_CFLAGS)
 if INCLUDED_PROGRESSBAR
-  AM_LDFLAGS += `pkg-config --libs libProgressBar`
-  AM_CPPFLAGS += `pkg-config --cflags libProgressBar`
+  AM_LDFLAGS += $(PROGRESSBAR_LIBS)
+  AM_CPPFLAGS += $(PROGRESSBAR_CFLAGS)
 endif
 endif
 
--- crac-2.5.2+dfsg.orig/src/libReadsInfo/Makefile.am
+++ crac-2.5.2+dfsg/src/libReadsInfo/Makefile.am
@@ -124,7 +124,7 @@
 
 libReadsInfo_a_CPPFLAGS = -I@abs_top_srcdir@ -I@abs_top_srcdir@/src -I@abs_top_srcdir@/src/libSSA 
 if INCLUDED_GKARRAYS
-  libReadsInfo_a_CPPFLAGS += `pkg-config --cflags libGkArrays`
+  libReadsInfo_a_CPPFLAGS += $(GKARRAYS_CFLAGS)
 endif
 
 
--- crac-2.5.2+dfsg.orig/src/libSSA/Makefile.am
+++ crac-2.5.2+dfsg/src/libSSA/Makefile.am
@@ -101,7 +101,7 @@
 bin_PROGRAMS = crac-index
 crac_index_SOURCES = cracIndex.cpp cracIndex.h
 
-AM_CPPFLAGS = -I@abs_top_srcdir@ -I@abs_srcdir@/karkkainen_bwt `pkg-config --cflags libGkArrays`
+AM_CPPFLAGS = -I@abs_top_srcdir@ -I@abs_srcdir@/karkkainen_bwt $(GKARRAYS_CFLAGS)
 AM_LDFLAGS = -lm -lpthread -lSSA -L@abs_builddir@/
 LDADD = libSSA.a
 

Bug#933023: bmusb FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: bmusb
Version: 0.7.4-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

bmusb fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. After making it
substitutable, bmusb cross builds successfully. Please consider applying
the attached patch.

Helmut
--- bmusb-0.7.4.orig/Makefile
+++ bmusb-0.7.4/Makefile
@@ -1,5 +1,6 @@
-CXXFLAGS := -std=gnu++14 -O2 -Wall -I. -g $(shell pkg-config libusb-1.0 --cflags) -pthread
-LDFLAGS := $(shell pkg-config libusb-1.0 --libs) -pthread
+PKG_CONFIG ?= pkg-config
+CXXFLAGS := -std=gnu++14 -O2 -Wall -I. -g $(shell $(PKG_CONFIG) libusb-1.0 --cflags) -pthread
+LDFLAGS := $(shell $(PKG_CONFIG) libusb-1.0 --libs) -pthread
 AR := ar
 LN := ln
 RANLIB := ranlib

Bug#933022: kxmlrpcclient FTCBFS: missing Build-Depends: qttools5-dev

[Helmut Grohne]

Source: kxmlrpcclient
Version: 5.54.0-1
Tags: pending

kxmlrpcclient fails to cross build from source. This is fixed in git:
https://salsa.debian.org/qt-kde-team/kde/kxmlrpcclient/commit/7ca1fcdcdb4d827c336332c619bd507b425dfc94
Please close this bug with the next upload to trigger a qa rebuild.

Helmut

Bug#933025: ldtp: Porting to python3, or removing?

[Samuel Thibault]

Source: ldtp
Version: 3.5.0-2
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: py2leaf, py3noport

Hello,

python2 is being phased out, so something needs to be done for ldtp. The
upstream mailing list has been very inactive for a long time. Will there
really be interest in porting it to python3? Or should we just remove
ldtp from Debian? (it has no rdep)

Samuel

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

Kernel: Linux 5.2.0 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)

Bug#933021: sagemath ftbfs in unstable (too many test failures)

[Matthias Klose]

Package: src:sagemath
Version: 8.6-6
Severity: serious
Tags: sid bullseye

the builds show too many test failures on all architectures.

[...]
otal time for all tests: 5258.7 seconds
cpu time: 13588.0 seconds
cumulative wall time: 19677.1 seconds
make[2]: Entering directory '/<>'
Error: 22979 tests failed, up to 50 failures are tolerated
make[2]: *** [debian/rules:252: had-few-failures] Error 1
make[2]: Leaving directory '/<>'
make[2]: Entering directory '/<>'
Checking number of failed tests to determine whether to rerun tests in series...
No: 22979 tests failed, up to 100 failures are tolerated for rerun
make[2]: *** [debian/rules:265: had-not-too-many-failures] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:289: override_dh_auto_test-arch] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:73: binary-arch] Error 2

Bug#933020: libvirt ftbfs in unstable (configure fails)

[Matthias Klose]

Package: src:
Version: 5.0.0-4
Severity: serious
Tags: sid bullseye

seen on all architectures.

[...]
checking rbd/librbd.h usability... yes
checking rbd/librbd.h presence... yes
checking for rbd/librbd.h... yes
checking for rbd_get_features... yes
configure: error: Need glusterfs (libgfapi) for gluster storage driver

Bug#933019: bareos ftbfs in unstable

[Matthias Klose]

Package: src:bareos
Version: 17.2.7-2
Severity: serious
Tags: sid bullseye

seen on all architectures.

[...]
/<>/libtool --silent --tag=CXX --mode=link /usr/bin/g++
-Wl,-z,relro -Wl,-z,now -shared autoxflate-sd.lo -o
autoxflate-sd.la -rpath /usr/lib/bareos/plugins -module -export-dynamic
-avoid-version -L../../lib -lbareos
gfapi_device.c: In member function ‘virtual bool 
gfapi_device::d_truncate(DCR*)’:
gfapi_device.c:550:34: error: too few arguments to function ‘int
glfs_ftruncate(glfs_fd_t*, off_t, glfs_stat*, glfs_stat*
)’
   if (glfs_ftruncate(m_gfd, 0) != 0) {
  ^
In file included from ../backends/gfapi_device.h:31,
 from gfapi_device.c:34:
/usr/include/glusterfs/api/glfs.h:768:1: note: declared here
 glfs_ftruncate(glfs_fd_t *fd, off_t length, struct glfs_stat *prestat,
 ^~
make[2]: *** [Makefile:217: gfapi_device.lo] Error 1
make[2]: Leaving directory '/<>/src/stored/backends'
make[1]: *** [GNUmakefile:167: src/stored/backends] Error 2

Bug#933018: ubuntu-dev-tools: `reverse-depends -b' ends with a traceback

[gregor herrmann]

Package: ubuntu-dev-tools
Version: 0.169
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since the last update finding reverse build dependencies seems
broken:

% reverse-depends -b libjson-xs-perl
Reverse-Build-Depends-Indep
===
Traceback (most recent call last):
  File "/usr/bin/reverse-depends", line 224, in 
main()
  File "/usr/bin/reverse-depends", line 157, in main
display_verbose(package, result)
  File "/usr/bin/reverse-depends", line 203, in display_verbose
rdep['Architectures'],
KeyError: 'Architectures'


% reverse-depends -a source libjson-xs-perl:(
Reverse-Build-Depends-Indep
===
Traceback (most recent call last):
  File "/usr/bin/reverse-depends", line 224, in 
main()
  File "/usr/bin/reverse-depends", line 157, in main
display_verbose(package, result)
  File "/usr/bin/reverse-depends", line 203, in display_verbose
rdep['Architectures'],
KeyError: 'Architectures'


% reverse-depends -a Source libjson-xs-perl:(
reverse-depends: Error: 

500 Internal Server Error

Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator at 
 ad...@ubuntuwire.com to inform them of the time this error occurred,
 and the actions you performed just before this error.
More information about this error may be available
in the server error log.

Apache/2.4.18 (Ubuntu) Server at qa.ubuntuwire.org Port 80





Cheers,
gregor


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages ubuntu-dev-tools depends on:
ii  binutils   2.32.51.20190707-1
ii  dctrl-tools2.24-3
ii  devscripts 2.19.6
ii  diffstat   1.62-1
ii  distro-info0.21
ii  dpkg-dev   1.19.7
ii  lsb-release10.2019051400
ii  perl   5.28.1-6
ii  python 2.7.16-1
ii  python-apt 1.8.4
ii  python-debian  0.1.35
ii  python-distro-info 0.21
ii  python-httplib20.11.3-2
ii  python-launchpadlib1.10.7-1
ii  python-lazr.restfulclient  0.14.2-1
ii  python-ubuntutools 0.169
ii  sensible-utils 0.0.12
ii  sudo   1.8.27-1

Versions of packages ubuntu-dev-tools recommends:
ii  brz3.0.1-1
ii  bzr2.7.0+bzr6622-15
pn  bzr-builddeb | brz-debian  
ii  ca-certificates20190110
ii  cowbuilder 0.88
ii  debian-archive-keyring 2019.1
ii  debian-keyring 2019.06.25
ii  debootstrap1.0.115
ii  dput   1.0.3
ii  genisoimage9:1.1.11-3+b2
ii  libwww-perl6.39-1
ii  lintian2.16.0
ii  patch  2.7.6-5
ii  pbuilder   0.230.4
ii  python-dns 2.3.6-4
ii  python-soappy  0.12.22-1
ii  quilt  0.65-3
ii  raspbian-archive-keyring [debian-archive-keyring]  20120528.2
ii  reportbug  7.5.2
ii  sbuild 0.78.1-2
ii  ubuntu-keyring [ubuntu-archive-keyring]2018.09.18.1-5

Versions of packages ubuntu-dev-tools suggests:
ii  python 2.7.16-1
ii  python-simplejson  3.16.0-2
ii  qemu-user-static   1:3.1+dfsg-8

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl06APpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZssxAAqud6bZ+OagVIHt6kYpbzSDBHvayeqR6OcGyMzeh72ckjVn3XI1QTFQwX
oKxZjw4c28/XrRVn4r5d6HHbiJ1efLUhhGYoWC/HfDpmyil5sRUnSBOsL+73IBG3
Wc9vrx2w2L3kAR0cWwfIx0G5UGUscZfoR3DqoNSheAcuoWtpvHD71KqQYyt2kCRe
MkkiKrkVA8ZZ9kqpAfyNDOzwwbFS+ww1Wjp3xAMMlvZIJyjbkXPOq9zxwZI/qk1E

Bug#933016: [Pkg-rust-maintainers] Bug#933016: rustc: status of nightly toolchains

[Ximin Luo]

Try setting RUSTC_BOOTSTRAP=1.

A long-term goal is to package rustup so you can then do `apt install rustup`.

X

Dmitry Bogatov:
> 
> Source: rustc
> Severity: wishlist
> 
> Dear Maintainer,
> 
> are there any plans to add into Debian version of Rust compiler, that
> supports #![feature]?
> 
> Currently, to compile project I am interested in, I am forced to use
> `curl | sh` installation, which is quite creepy.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
> (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
> to en_US.utf8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
> en_US.utf8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: runit (via /run/runit.stopit)
> LSM: AppArmor: enabled
> 
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 

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

Bug#840356: initscripts: mountkernfs.sh does not mount configfs

[Dmitry Bogatov]

control: tags -1 +patch

[ Sorry for late response ]

[2017-03-30 12:36] Harald Dunkel 
> PS: Attached you can find a suggested fix.
>
> part 2 text/x-patch   334
> diff --git a/init.d/mountkernfs.sh b/init.d/mountkernfs.sh
> index e95cac3..56df7f9 100755
> --- a/init.d/mountkernfs.sh
> +++ b/init.d/mountkernfs.sh
> @@ -60,6 +60,7 @@ case "$1" in
>   mount_filesystems mount_noupdate
>   ;;
>start)
> + modprobe configfs || echo ignored
>   mount_filesystems mount_noupdate
>   ;;
>restart|reload|force-reload)

This patch loads `configfs' module, unconditionally. I find it
unfortunate.

I'd prefer to mount `configfs' after `kmod', if 'configfs' was loaded by
/etc/init.d/kmod; something like following. Opinions?

From 66fc843dc2c852fc47fe9cf1b671cf55d37ea62f Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Thu, 25 Jul 2019 06:28:29 +
Subject: [PATCH] Attempt to mount /sys/kernel/config after `kmod'

Currently, /etc/init.d/mountkernfs attempts to mount `configfs' before
apporiate kernel module could be loaded by `kmod' script.  As such,
`configfs' is only mounted on systems where kernel module is loaded
by initramfs.

With this change `configfs' mount is tried in separate script after
`kmod'.

Closes: #840356
---
 debian/initscripts.conffiles  |  1 +
 debian/initscripts.postinst   |  2 +-
 debian/initscripts.postrm |  2 +-
 .../src/initscripts/etc/init.d/mount-configfs | 34 +++
 .../src/initscripts/etc/init.d/mountkernfs.sh |  4 ---
 5 files changed, 37 insertions(+), 6 deletions(-)
 create mode 100644 debian/src/initscripts/etc/init.d/mount-configfs

diff --git a/debian/initscripts.conffiles b/debian/initscripts.conffiles
index 381e9f66..6d3fa7ec 100644
--- a/debian/initscripts.conffiles
+++ b/debian/initscripts.conffiles
@@ -22,6 +22,7 @@
 /etc/init.d/umountnfs.sh
 /etc/init.d/umountroot
 /etc/init.d/urandom
+/etc/init.d/mount-configfs
 /etc/default/devpts
 /etc/default/halt
 /etc/default/rcS
diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index 82ab6a71..b1e3e6c2 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -45,7 +45,7 @@ make_rc_local_conffile
 
 umask 022
 
-INITSCRIPTS="mountkernfs.sh brightness hostname.sh mountdevsubfs.sh 
checkroot.sh \
+INITSCRIPTS="mountkernfs.sh mount-configfs brightness hostname.sh 
mountdevsubfs.sh checkroot.sh \
checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \
mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \
umountroot umountfs umountnfs.sh sendsigs killprocs single motd \
diff --git a/debian/initscripts.postrm b/debian/initscripts.postrm
index 6847f9ff..5e232568 100755
--- a/debian/initscripts.postrm
+++ b/debian/initscripts.postrm
@@ -5,7 +5,7 @@
 
 set -e
 
-INITSCRIPTS="mountkernfs.sh brightness hostname.sh mountdevsubfs.sh 
checkroot.sh \
+INITSCRIPTS="mountkernfs.sh mount-configfs brightness hostname.sh 
mountdevsubfs.sh checkroot.sh \
checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \
mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \
umountroot umountfs umountnfs.sh sendsigs killprocs single motd \
diff --git a/debian/src/initscripts/etc/init.d/mount-configfs 
b/debian/src/initscripts/etc/init.d/mount-configfs
new file mode 100644
index ..6cfd16bf
--- /dev/null
+++ b/debian/src/initscripts/etc/init.d/mount-configfs
@@ -0,0 +1,34 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides:  mount-configfs
+# Required-Start:mountkernfs
+# Required-Stop:
+# Should-Start:  kmod
+# Default-Start: S
+# Default-Stop:
+# Short-Description: Mount configfs kernel virtual file system.
+# Description:   Mount configfs kernel virtual file system,
+#if "configfs" module is loaded.
+### END INIT INFO
+set -eu
+
+export PATH=/bin:/usr/bin
+
+case ${1:-missing} in
+(start|restart|force-reload)
+   readonly mountpoint='/sys/kernel/config'
+   # This directory exists only if "configfs" module was loaded by "kmod"
+   # script.
+   test -d "${mountpoint}"  || exit 0
+   ! findmnt "${mountpoint}" >/dev/null || exit 0
+
+   mount none -t configfs "${mountpoint}"
+   ;;
+(stop)
+   # No-op
+   ;;
+(*)
+   echo "Usage: mount-configfs [start|stop]" >&2
+   exit 3
+   ;;
+esac
diff --git a/debian/src/initscripts/etc/init.d/mountkernfs.sh 
b/debian/src/initscripts/etc/init.d/mountkernfs.sh
index e95cac3a..146581a6 100755
--- a/debian/src/initscripts/etc/init.d/mountkernfs.sh
+++ b/debian/src/initscripts/etc/init.d/mountkernfs.sh
@@ -48,10 +48,6 @@ mount_filesystems () {
domount "$MNTMODE" pstore "" /sys/fs/pstore pstore ""
fi
 
-   if [ -d /sys/kernel/config ]
-   then
-   domount "$MNTMODE" configfs "" /sys/kernel/config configfs ""
-   fi
 }
 
 case "$1" 

Bug#932290: insserv: Script has overlapping Default-Start and Default-Stop runlevels

[Dmitry Bogatov]

control: tags -1 +confirmed +help +upstream +patch

[2019-07-24 14:12] Lorenz 
> Control: severity -1 normal
>
> Ok, here is what I've found out; to reproduce the issue you need to
> disable with update-rc.d a script that has an empty ' Default-Stop: ' field
> in the LSB header.
> [...]

Yes, I reproduced.

> This is a minor issue, but still i have few suggestions:
>
> 1. the message looks like an error, but insserv exits 0, so i guess it' a
> warning,
> maybe it should be ' insserv: warning: Script ssh has ...'
> 2. disabling a service is a legit action and insserv already prints a
> warning about
> overriding LSB defaults, so what is this warning about (what is to be
> fixed)?
> Is an empty ' Default-Stop: ' field a bug, or it's something else?

This check is about LSB headers, where some runlevel is listed both in
Default-Start and Default-Stop. It is really serious.  But behaviour you
are reporing is false-positive. There is no need to change message --
only to make sure it is printed in apporiate situations.

I prepared patch that fix problem at hand (I believe), but I am not sure
that it does not introduce problems in another cases. The whole point is
that `script_inf.default_stop' value gets overrided around
insserv.c:3698, so I moved overlap check up. Jesse, can you please take
a look?

By the way, `if (!service)' conditional is always true -- `service'
variable gets initialized to `0' and is not modified before this
conditional.

diff --git a/insserv.c b/insserv.c
index 0c638dd..fa02b23 100644
--- a/insserv.c
+++ b/insserv.c
@@ -3475,6 +3475,12 @@ int main (int argc, char *argv[])
}   /* !findservice(, script_inf.provides) */
}
 
+   overlap = Start_Stop_Overlap(script_inf.default_start, 
script_inf.default_stop);
+   if (overlap) {
+   warn("Script %s has overlapping Default-Start and Default-Stop 
runlevels (%s) and (%s). This should be fixed.\n",
+d->d_name, script_inf.default_start, 
script_inf.default_stop);
+   }
+
/*
 * Use guessed service to find it within the the runlevels
 * (by using the list from the first scan for script locations).
@@ -3733,13 +3739,6 @@ int main (int argc, char *argv[])
}
 #endif /* not SUSE */
 
-overlap = Start_Stop_Overlap(script_inf.default_start, 
script_inf.default_stop);
-if (overlap)
-{
-warn("Script %s has overlapping Default-Start and Default-Stop 
runlevels (%s) and (%s). This should be fixed.\n",
-  d->d_name, script_inf.default_start, 
script_inf.default_stop);
-}
-
if (isarg && !defaults && !del) {
if (argr[curr_argc]) {
char * ptr = argr[curr_argc];

-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#783990: initscripts: mount efivars directory during boot when using sysvinit

[Dmitry Bogatov]

control: tags -1 +moreinfo

[ Sorry for late response ]

[2015-05-01 20:52] "Pearson, Greg" 
> Package: initscripts
> Version: 2.88dsf-59
> Severity: normal
>
> # uname -a
> Linux sa1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)
> x86_64 GNU/Linux
>
> I installed Debian on a HP ProLiant DL580Gen9 system in UEFI mode using
> "debian-8.0.0-amd64-DVD-1.iso". After the installation finished I
> installed the sysvinit-core package (2.88dsf-59) and rebooted the
> system. This replaces systemd with sysvinit. I then checked if the
> directory /sys/firmware/efi/efivars was mounted and it was not. It seems
> like a good idea to have this directory automounted on boot so EFI tools
> use the new interface to access EFI variables.
>
> One possible solution would be to add the following to
> /etc/init.d/mountkernfs.sh which is delivered by the initscripts package:
>
> if [ -d /sys/firmware/efi/efivars ]
> then
> domount "$MNTMODE" efivarfs "" /sys/firmware/efi/efivars efivarfs ""
> fi

Hi. As I see on my system, /sys/firmware/efi is now part of /sys:

$ ls /sys/firmware/efi/
config_table
efivars
fw_platform_size
fw_vendor
runtime
runtime-map
systab
vars
$ mount | grep efi
/dev/sda1 on /boot/efi type vfat 
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

Am I missing something?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#770342: [Pkg-sysvinit-devel] Bug#770342: "dashism" in /etc/init.d/bootlogs ?

[Dmitry Bogatov]

control: tags -1 +moreinfo

[2014-11-21 12:43] Harald Dunkel 
> On Fri, 21 Nov 2014 11:45:15 +0100
> Petter Reinholdtsen  wrote:
>
> > [Harald Dunkel]
> > > Is there something unusual?
> > 
> > Not that I can see, no. :( The 255 file descriptor was a bit unexpected
> > to me, but I guess that is how the shell work.
> > 
> > Is this different when using bash?
> > 
>
> This *is* bash. Using /bin/sh --> dash it doesn't get stuck, making
> it almost impossible to check /proc.
>
> bash on Wheezy doesn't get stuck, either.

Sorry for late response.

Does this bug reproduces on modern installations? If so, can you please
run this script with `-x'?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#933016: rustc: status of nightly toolchains

[Dmitry Bogatov]

Source: rustc
Severity: wishlist

Dear Maintainer,

are there any plans to add into Debian version of Rust compiler, that
supports #![feature]?

Currently, to compile project I am interested in, I am forced to use
`curl | sh` installation, which is quite creepy.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8)
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled


pgpnltlalPkfr.pgp
Description: PGP signature

Bug#933017: Please add source link and bug reporting info to footer

[Ian Jackson]

Package: www.debian.org

It would be nice if the website told you where its source code is
namely AFAICT
  https://salsa.debian.org/webmaster-team/webwml
and where to report bugs (AFAICT, here).

I looked for this information in the footer of this page
  https://www.debian.org/legal/privacy
and it wasn't there.

I see now that this page
  https://www.debian.org/Bugs/pseudo-packages
does have it.  This is mysterious to me.  I hope someone in the web
team can do something sensible about this...

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#705056: /etc/default/devpts instructions to set "mesg n" by default don't work

[Dmitry Bogatov]

control: tags -1 +moreinfo +unreproducible

[2013-04-09 17:13] Jakub Wilk 
> Package: initscripts,libc6
>
> /etc/default/devpts reads:
> # Set to 600 to have `mesg n' be the default
> TTYMODE=620
>
> But this doesn't really work. Even if you mount /dev/pts with mode=600, 
> your pty devices will end up with 620 permissions. This is because 
> well-behaved software calls grantpt(), which changes the device 
> permissions.
>
> Either grantpt() should be fixed not to touch permissions if /dev/pts is 
> a devpts fs (as it did in the past[0]) or initscripts should be fixed 
> not to claim you can have "mesg n" by default.

I just tried this -- remounted /dev/pts with mode=600 and started
dvtm(1) and stterm(1). This resulted in /dev/pts/{0,1} with $USER:tty,
600. So to be `TTYMODE' seems to work.

Did I miss something?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#933011: lvm2: udev rules don't work outside of systemd

[Julian Andres Klode]

Control: tag -1 patch
Control: forwarded -1 lvm-de...@redhat.com

On Thu, Jul 25, 2019 at 03:07:03PM -0300, Julian Andres Klode wrote:
> Package: lvm2
> Version: 2.03.02-2ubuntu5
> Severity: important
> 
> lvm2 udev rules now use the systemd background magic, which means the stuff
> they run is not run on non-systemd systems. We noticed this in Ubuntu, because
> we rely on udev rules to scan PVs in initramfs (compared to Debian, which just
> runs lvchange in a loop as part of local-block).

Attached patch to detect systemd at run-time.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en
>From b59270bc579cc89816a56756def3acdabfff4a07 Mon Sep 17 00:00:00 2001
From: Julian Andres Klode 
Date: Thu, 25 Jul 2019 15:40:42 -0300
Subject: [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

systems might have systemd as their normal init systems, but
might not be using it in their initramfs; or like Debian, support
different init systems.

Detect whether we are running on systemd by checking for /run/systemd/system
and then change the behavior accordingly.

This effectively breaks compatibility with systemd versions prior to
205, as 205 was the minimum version for the feature.

Bug-Debian: https://bugs.debian.org/933011
---
 configure.ac  | 24 
 udev/69-dm-lvm-metad.rules.in |  6 --
 udev/Makefile.in  | 10 +-
 3 files changed, 5 insertions(+), 35 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1e45c0edc..5beffd8e6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1055,29 +1055,6 @@ AC_MSG_RESULT($BLKID_WIPING)
 AC_DEFINE_UNQUOTED(DEFAULT_USE_BLKID_WIPING, [$DEFAULT_USE_BLKID_WIPING],
 		   [Use blkid wiping by default.])
 
-
-dnl -- Enable udev-systemd protocol to instantiate a service for background jobs
-dnl -- Requires systemd version 205 at least (including support for systemd-run)
-AC_ARG_ENABLE(udev-systemd-background-jobs,
-	  AC_HELP_STRING([--disable-udev-systemd-background-jobs],
-			 [disable udev-systemd protocol to instantiate a service for background job]),
-	  UDEV_SYSTEMD_BACKGROUND_JOBS=$enableval,
-	  UDEV_SYSTEMD_BACKGROUND_JOBS=maybe)
-
-if test "$UDEV_SYSTEMD_BACKGROUND_JOBS" != no; then
-	pkg_config_init
-	PKG_CHECK_MODULES(SYSTEMD, systemd >= 205,
-			  [UDEV_SYSTEMD_BACKGROUND_JOBS=yes],
-			  [if test "$UDEV_SYSTEMD_BACKGROUND_JOBS" = maybe; then
-UDEV_SYSTEMD_BACKGROUND_JOBS=no
-			   else
-AC_MSG_ERROR([bailing out... systemd >= 205 is required])
-			   fi])
-fi
-
-AC_MSG_CHECKING(whether to use udev-systemd protocol for jobs in background)
-AC_MSG_RESULT($UDEV_SYSTEMD_BACKGROUND_JOBS)
-
 
 dnl -- Enable udev synchronisation
 AC_MSG_CHECKING(whether to enable synchronisation with udev processing)
@@ -1772,7 +1749,6 @@ AC_SUBST(CACHE_RESTORE_CMD)
 AC_SUBST(UDEV_PC)
 AC_SUBST(UDEV_RULES)
 AC_SUBST(UDEV_SYNC)
-AC_SUBST(UDEV_SYSTEMD_BACKGROUND_JOBS)
 AC_SUBST(UDEV_RULE_EXEC_DETECTION)
 AC_SUBST(UDEV_HAS_BUILTIN_BLKID)
 AC_SUBST(USE_TRACKING)
diff --git a/udev/69-dm-lvm-metad.rules.in b/udev/69-dm-lvm-metad.rules.in
index d51006496..a797bbcd6 100644
--- a/udev/69-dm-lvm-metad.rules.in
+++ b/udev/69-dm-lvm-metad.rules.in
@@ -73,7 +73,8 @@ GOTO="lvm_end"
 # For "systemd_background" mode, systemd takes care of this by activating
 # the lvm2-pvscan@.service only once.
 LABEL="next"
-ACTION!="(PVSCAN_ACTION)", GOTO="lvm_end"
+TEST!="/run/systemd/system", ACTION!="add", GOTO="lvm_end"
+TEST=="/run/systemd/system", ACTION!="add|change", GOTO="lvm_end"
 
 LABEL="lvm_scan"
 
@@ -83,7 +84,8 @@ ENV{SYSTEMD_READY}="1"
 # --(enable|disable)-udev-systemd-background-jobs to "configure".
 # On modern distributions with recent systemd, it's "systemd_background";
 # on others, "direct_pvscan".
-GOTO="(PVSCAN_RULE)"
+TEST!="/run/systemd/system", GOTO="direct_pvscan"
+TEST=="/run/systemd/system", GOTO="systemd_background"
 
 LABEL="systemd_background"
 
diff --git a/udev/Makefile.in b/udev/Makefile.in
index e32cba921..57a96fefb 100644
--- a/udev/Makefile.in
+++ b/udev/Makefile.in
@@ -43,16 +43,8 @@ else
 BLKID_RULE=IMPORT{program}=\"${SBIN}\/blkid -o udev -p \$$tempnode\"
 endif
 
-ifeq ("@UDEV_SYSTEMD_BACKGROUND_JOBS@", "yes")
-PVSCAN_RULE=systemd_background
-PVSCAN_ACTION=add|change
-else
-PVSCAN_RULE=direct_pvscan
-PVSCAN_ACTION=add
-endif
-
 %.rules: $(srcdir)/%.rules.in
-	$(Q) $(SED) -e "s+(DM_DIR)+$(DM_DIR)+;s+(BINDIR)+$(BINDIR)+;s+(BLKID_RULE)+$(BLKID_RULE)+;s+(PVSCAN_RULE)+$(PVSCAN_RULE)+;s+(PVSCAN_ACTION)+$(PVSCAN_ACTION)+;s+(DM_EXEC_RULE)+$(DM_EXEC_RULE)+;s+(DM_EXEC)+$(DM_EXEC)+;s+(LVM_EXEC_RULE)+$(LVM_EXEC_RULE)+;s+(LVM_EXEC)+$(LVM_EXEC)+;" $< >$@
+	$(Q) $(SED) -e 

Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd

[Norbert Preining]

Hi Hilmar,

a few things:
- your email is not configured for git, git lists
hille@debian-amd64-sid
  as email.

> W: dvisvgm source: useless-autoreconf-build-depends autotools-dev

fixed

> W: dvisvgm source: dep5-copyright-license-name-not-unique gpl-3+
> (paragraph at line 11)
> W: dvisvgm source: dep5-copyright-license-name-not-unique gpl-3+
> (paragraph at line 63)
> W: dvisvgm source: dep5-copyright-license-name-not-unique mit (paragraph
> at line 128)
> W: dvisvgm source: dep5-copyright-license-name-not-unique gpl-2+
> (paragraph at line 179)

fixed

> W: dvisvgm: description-synopsis-starts-with-article

fixed

> E: dvisvgm: possible-gpl-code-linked-with-openssl

That is still open.

> - the possible-gpl-code-linked-with-openssl could eventually be resolved
>   by statical linking w/ the delivered libs/md5 instead of dyn link
>   against libssl. I'll try again later.

That would be great.

> - I did not push the orig.tar.gz to pristine-tar branch yet, it is on
>   [1], please push the code.

Ok, please do so at some point.

> - you can't build the package twice using debuild. The reason is that
>   make distclean deletes the manual page, which is not re-created during
>   build. I've opened [2] for now.

So what, that is not a requirement. I have several packages with similar
problems.

Best

Norbert

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

Bug#932935: Fixed

[mg-devin]

Update to e2fsprogs fixed my problem now...

Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time

[Paul Gevers]

Control: tags -1 moreinfo

Hi Chris,

On 25-07-2019 18:51, Chris Lamb wrote:
>> PS: I failed to spot bugs against (some of) those packages communication
>> the removal, I think that would be nice for those maintainers.
> 
> This might have been justifiably and fairly missed as it was dicussed
> quite some time, possibly years, ago. Not your fault, possibly ours…
> However, as Brian mentions we do really have no option but to use the
> 2.x branch of Django these days and, unfortunately, this means that
> Python 2.x support is accordingly dropped.

It's OK to move on and it's very OK to do that at the beginning of a
release cycle. However I expect you to coordinate this with your reverse
dependencies and *I* didn't see that so far (but of course it's easy for
me to miss stuff).

> The packages you list may thus need to be updated or removed. (I'm
> afraid I haven't looked into the specifics...)

Sure. Contacting the maintainers, and they can help as well, I guess.

>> Your package is trying to fix a CVE
> 
> Can you elaborate? I'm a little distracted by DebConf stuff but I
> can't seem to grok what you mean here specifically.

https://qa.debian.org/excuses.php?package=python-django says this upload
will fix bug #931316 in testing. That bug is about CVE-2019-12781.
Testing has not seen the fix yet, and due to the dropping of Python 2,
it will take time before it does, as python-django can not migrate
before reverse dependencies are fixed or removed. The latter isn't very
nice for your reverse dependencies if you didn't give them proper
heads-up. The former isn't nice for the python-django users of testing.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#932985: [Python-modules-team] Bug#932985: Please remove Python 2 support

[eamanu15 .]

Hello,

I applied the patch.

I recommend to the uploader, Jean-Michel (CC), give to the
repository the git structure master, debian and pristine-tar.

Just an opinion :-)

Cheers!

El jue., 25 de jul. de 2019 a la(s) 10:12, Thomas Goirand (z...@debian.org)
escribió:

> Source: django-session-security
> Version: 2.6.5+dfsg-1
> Severity: serious
> Tags: patch
>
> Hi,
>
> Please remove Python 2 support. Attached patch may help.
>
> Thomas
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team



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

Bug#933015: libssh FTBFS on hurd: unconditional usage of PATH_MAX

[Paul Sonnenschein]

Package: src:libssh
Severity: Important
Version: 0.9.0-1
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Dear maintainer,

the package libssh fails to build from source on hurd-i386 in sid due
to an unconditional use of PATH_MAX, which the Hurd does not provide.

A patch which uses code similiar to the example in [1] is appended.

Thanks

[1]: 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html
Subject: Fix unconditional use of PATH_MAX
Author: Paul Sonnenschein 
diff --git a/tests/torture.c b/tests/torture.c
index 772942c..8f9f39d 100644
--- a/tests/torture.c
+++ b/tests/torture.c
@@ -1029,17 +1029,25 @@ char *torture_get_current_working_dir(void)
 
 char *cwd = NULL;
 char *result = NULL;
+size_t path_max;
+
+#ifdef PATH_MAX
+path_max = PATH_MAX;
+#else
+path_max = 4095;
+#endif /* PATH_MAX undefined */
+for ( ; result == NULL; path_max *= 2) {
+cwd = (char *)realloc(cwd, path_max + 1);
+if (cwd == NULL) {
+goto end;
+}
 
-cwd = (char *)malloc(PATH_MAX + 1);
-if (cwd == NULL) {
-goto end;
-}
-
-result = getcwd(cwd, PATH_MAX);
+result = getcwd(cwd, path_max);
 
-if (result == NULL) {
-SAFE_FREE(cwd);
-goto end;
+if (result == NULL && errno != ERANGE) {
+SAFE_FREE(cwd);
+goto end;
+}
 }
 
 end:


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

Bug#933007: [Pkg-javascript-devel] Bug#933007: pkg-js-tools: Automatically link components in node_modules directory

[Xavier]

Le 25/07/2019 à 20:08, Pirate Praveen a écrit :
> 
> 
> On 2019, ജൂലൈ 25 11:15:50 PM IST, Xavier Guimard  wrote:
>> Package: pkg-js-tools
>> Version: 0.8.1
>> Severity: wishlist
>>
>> When using components in node modules, the best way to use them is to
>> install them in node_modules/ directory. However, dpkg-source install
>> them at the top source directory under a directory named by "component"
>> field value (debian/watch).
>>
>> The idea here is, before build, to automatically read debian/watch to
>> find
>> components, read /package.json to find the node name and
>> create a link "../ => " in node_modules directory
>> (created on-the-fly). Also, it will remove automatically node_modules
>> directory during dh_clean step.
>> Then no need to overwrite NODE_PATH in debian/rules.
>>
>> Any comment is welcome here ;-).
> 
> Good idea. It would be nice if we can somehow automate installation too, 
> instead of adding each module in debian/install. May be we can read 
> package.json#dependencies to determine which should be installed (but it can 
> get complex if we consider whole dependency tree). Or provide 
> debian/node_modules file to explicitly list the node modules to be installed.

Good idea! By default, all component will be installed in
/usr/share/nodejs or /usr/lib/nodejs depending on "Architecture" field
value, if debian/nodeSubmodules exists, then only component listed here
will be installed. To install in nodejs root directory, a custom
debian/install will be required

Only component/**.(js|json|node) files will be installed except
component/test*

Bug#933014: ITP: xchroot -- chroot for Xorg with read-only access

[Elmar Stellnberger]

Package: wnpp
Severity: wishlist

 * Package name: xchroot
   Version : 2.3.4-2
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/xchroot/
 * License : GPLv3
   Programming Lang: bash
   Description : an extended chroot with features like Xorg-access 
or read-only roots


  xchroot is still one of the most used programs on elstel.org though 
nowadays there are alternatives for chroot with Xorg/X11. However 
xchroot also allows to chroot onto a chroot environment on a read only 
data carrier like a blue ray where temporary writes are stored via aufs 
where the differences can be saved to disk intermediately for later 
chroots. Besides two different methods for chroot with Xorg xchroot 
supports chroot as user via sudo, automounting of directories and 
multiple simultaneous chroots to the same root unmounting only when the 
last user leaves the chroot. sudoers entries can be added and removed 
via xchroot for different users and chroot root directories.

Bug#519716: at: use nice levels starting from 0

[Christoph Berg]

Re: Jose M Calhariz 2019-07-18 <20190718145028.pfd7ib2wwvgy7...@calhariz.com>
> I have been working on a new release of at and took the decision to
> implement your request.  Are you still interested in this feature?
> Do you want to review it?

Hi Jose,

TBH I can't remember anything about this patch, so please just go
ahead implementing it.

Christoph

Bug#933013: linux-source: kernel panic using CIFS share in smb2_push_mandatory_locks()

[LUCIAHUO]

Package: linux-source
Severity: normal

[Impact]

* We got reports of a kernel crash in cifs module with the following
* signature:

BUG: unable to handle kernel NULL pointer dereference at
0038
IP: smb2_push_mandatory_locks+0x10e/0x3b0 [cifs]
PGD 0 P4D 0
RIP: 0010:smb2_push_mandatory_locks+0x10e/0x3b0 [cifs]
Call Trace:
cifs_oplock_break+0x12f/0x3d0 [cifs]
process_one_work+0x14d/0x410
worker_thread+0x4b/0x460
kthread+0x105/0x140
[...]

* Low-level analysis (decodecode script output and the objdump of
* the function) revealed that we are crashing in a NULL ptr
* dereference when trying to access "cfile->tlink"; below, a snippet
* of the objdump at function smb2_push_mandatory_locks():
   
[...]
mov 0x10(%r14),%r15 # %r15 = cifsFileInfo *cfile
mov 0x18(%r14),%rbx # %rbx = cifsLockInfo *li = (fdlocks->locks)
lea 0x18(%r14),%r12
mov 0x90(%r15),%rax # %rax = struct tcon_link *tlink (cfile->tlink)
cmp %r12,%rbx
mov 0x38(%rax),%rax # <--- TRAP [trying to get cifs_tcon *tl_tcon]
[...]

* After discussing the issue with CIFS maintainers (Steve French and
* Pavel Shilovsky) they suggested commit b98749cac4a6 ("CIFS: keep
* FileInfo handle live during oplock break")
* [http://git.kernel.org/linus/b98749cac4a6] as a fix for multiple
* reports of this kind of crash.
* The fix was sent to stable kernels and is present in Ubuntu
* kernels 5.0 and newer. We are requesting the SRU for this patch
* here in order to fix the crashes, after reports of successful
* testing with the patch (see below section) and since the patch is
* restricted to the cifs module scope and accepted on linux stable.
* Alternatively the issue is known to be avoided when oplocks are
* disabled using "cifs.enable_oplocks=N" module parameter.

[Test case]

* Unfortunately we cannot reproduce the issue. The patch proposed
* here was
validated by us with xfstests (instructions followed from
https://wiki.samba.org/index.php/Xfstesting-cifs) and fio. Also, we
have a user report of test validation using LISA
(https://github.com/LIS/LISAv2).
* Using xfstest with the exclusions proposed in the link above we
* managed to get the same results as a non-patched kernel, i.e., the
* same tests failed in both kernels, we didn't get worse results
* with the patch. Fio also didn't show noticeable performance
* regression with the patch.

[Regression potential]

* The patch was validated by the cifs filesystem maintainers (in
* fact they suggested its inclusion in Ubuntu) and by the
* aforementioned tests; also, the scope is restricted to cifs only
* so the likelihood of regressions is considered low.
* Due to the nature of the code modification (add a new reference of
* a file handler and manipulate it in different places), I consider
* that if we have a regression it'll manifest as deadlock/blocked
* tasks, not something more serious like crashes or data corruption.


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

Kernel: Linux 4.4.0-17763-Microsoft
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages linux-source depends on:
pn  linux-source-4.15.0  

linux-source recommends no packages.

linux-source suggests no packages.

Bug#933007: [Pkg-javascript-devel] Bug#933007: pkg-js-tools: Automatically link components in node_modules directory

[Pirate Praveen]

On 2019, ജൂലൈ 25 11:15:50 PM IST, Xavier Guimard  wrote:
>Package: pkg-js-tools
>Version: 0.8.1
>Severity: wishlist
>
>When using components in node modules, the best way to use them is to
>install them in node_modules/ directory. However, dpkg-source install
>them at the top source directory under a directory named by "component"
>field value (debian/watch).
>
>The idea here is, before build, to automatically read debian/watch to
>find
>components, read /package.json to find the node name and
>create a link "../ => " in node_modules directory
>(created on-the-fly). Also, it will remove automatically node_modules
>directory during dh_clean step.
>Then no need to overwrite NODE_PATH in debian/rules.
>
>Any comment is welcome here ;-).

Good idea. It would be nice if we can somehow automate installation too, 
instead of adding each module in debian/install. May be we can read 
package.json#dependencies to determine which should be installed (but it can 
get complex if we consider whole dependency tree). Or provide 
debian/node_modules file to explicitly list the node modules to be installed.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#933012: ITP: confinedrv -- sets up a virtual drive with restricted access rights

[Elmar Stellnberger]

Package: wnpp
Severity: wishlist

 * Package name: confinedrv
   Version : 1.7.7-4
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/qemu/
 * License : GPLv3
   Programming Lang: bash
   Description : a script to confine individual partitions to 
read-only or no access


  confinedrv can be used to boot with qemu or similar virtualization 
software into another operating system installed on disk. If you have 
installed multiple operating systems into mutiple partitions you can not 
boot a second OS via qemu because you would need to give full write 
access to the same disk. However if the whole disk is accessed by two 
operating system instances in parallel that will cause disk corruption 
because there is no synchronization of these accesses. The solution 
confinedrv provides is to make the OS partition read write and all other 
partitions read-only so that they can not be written to and thereby 
possibly corrupted. Of course the OS partition must not be mounted by 
the host OS. You can also exclude read access for given partitions which 
will however still be visible in the partition table. confinedrv uses 
dmsetup and losetup internally to control access via device mapper. The 
partitions need to be aligned by the page size (usually 4096 Bytes) to 
make this work. However for modern SSDs this is the case by default.

Bug#933011: lvm2: udev rules don't work outside of systemd

[Julian Andres Klode]

Package: lvm2
Version: 2.03.02-2ubuntu5
Severity: important

lvm2 udev rules now use the systemd background magic, which means the stuff
they run is not run on non-systemd systems. We noticed this in Ubuntu, because
we rely on udev rules to scan PVs in initramfs (compared to Debian, which just
runs lvchange in a loop as part of local-block).

It's unclear to me what to do here.

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

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-2ubuntu5
ii  dmsetup   2:1.02.155-2ubuntu5
ii  libaio1   0.3.112-3
ii  libblkid1 2.33.1-0.1ubuntu2
ii  libc6 2.29-0ubuntu3
ii  libdevmapper-event1.02.1  2:1.02.155-2ubuntu5
ii  libreadline5  5.2+dfsg-3build2
ii  libselinux1   2.9-2
ii  libsystemd0   240-6ubuntu9
ii  libudev1  240-6ubuntu9
ii  lsb-base  10.2019051400ubuntu1

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
pn  thin-provisioning-tools  

-- no debconf information

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#933007: [Pkg-javascript-devel] Bug#933007: pkg-js-tools: Automatically link components in node_modules directory

[Xavier]

Le 25/07/2019 à 19:45, Xavier Guimard a écrit :
> Package: pkg-js-tools
> Version: 0.7
> Severity: wishlist
> 
> When using components in node modules, the best way to use them is to
> install them in node_modules/ directory. However, dpkg-source install
> them at the top source directory under a directory named by "component"
> field value (debian/watch).
> 
> The idea here is, before build, to automatically read debian/watch to find
> components, read /package.json to find the node name and
> create a link "../ => " in node_modules directory
> (created on-the-fly). Also, it will remove automatically node_modules
> directory during dh_clean step.
> Then no need to overwrite NODE_PATH in debian/rules.
> 
> Any comment is welcome here ;-).

To disable this, just to not call dh_auto_build in override_dh_auto_build

Bug#933010: haskell-quickcheck_2.12.6.1-1_s390x.changes REJECTED

[Aurelien Jarno]

Source: haskell-quickcheck
Version: 2.12.6.1-1
Severity: serious


On 2019-07-25 17:34, Debian FTP Masters wrote:
> 
> 
> libghc-quickcheck2-prof_2.12.6.1-1_s390x.deb: has 2 file(s) with a timestamp 
> too far in the past:
>   usr/share/doc/libghc-quickcheck2-prof/changelog.gz (Thu Jan  1 00:00:00 
> 1970)  usr/share/doc/libghc-quickcheck2-prof/README (Thu Jan  1 00:00:00 1970)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#933009: ghc: FTBFS on riscv64, debian/patches/risc-support.patch lost

[Aurelien Jarno]

Source: ghc
Version: 8.6.5+dfsg1-1
Severity: important
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

ghc fails to build on riscv64 with the following error:

| checking for gfind... no
| checking for find... /usr/bin/find
| checking for sort... /usr/bin/sort
| checking for GHC Git commit id... given 
92b6a0237e0195cee4773de4b237951addd659d9
| checking version of ghc... 8.4.4
| checking build system type... riscv64-unknown-linux-gnu
| checking host system type... riscv64-unknown-linux-gnu
| checking target system type... riscv64-unknown-linux-gnu
| Unknown CPU riscv64

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=ghc=riscv64=8.6.5%2Bdfsg1-1=1564007171=0

In version 8.4.4+dfsg1-3 the aclocal.m4 file was patched to add support
for riscv64. This patch has been lost in version 8.6.5+dfsg1-1. Please
find attached the patch rebased onto the new version. It would be nice
if you can include it in the next upload.

Thanks,
Aurelien
Description: cherry-pick of upstream commits
 beba89a0f16681c85d39fc8a894bde4162ff492a.patch:
 5e63a25249f3cb07300258e115af9ff55079d2ea.patch:
Last-Update: 2019-05-27

Index: b/aclocal.m4
===
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -217,7 +217,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V
 mipsel)
 test -z "[$]2" || eval "[$]2=ArchMipsel"
 ;;
-hppa|hppa1_1|ia64|m68k|nios2|rs6000|s390|s390x|sh4|vax)
+hppa|hppa1_1|ia64|m68k|nios2|riscv32|riscv64|rs6000|s390|s390x|sh4|vax)
 test -z "[$]2" || eval "[$]2=ArchUnknown"
 ;;
 *)
@@ -1906,6 +1906,12 @@ case "$1" in
   powerpc*)
 $2="powerpc"
 ;;
+  riscv64*)
+$2="riscv64"
+;;
+  riscv|riscv32*)
+$2="riscv32"
+;;
   rs6000)
 $2="rs6000"
 ;;

Bug#933008: ITP: qcoan - a GUI for simulating non-deterministic FAs, PDAs and Turing machines

[Elmar Stellnberger]

Package: wnpp
Severity: wishlist
Owner: Elmar Stellnberer 

 * Package name: qcoan
   Version : 2.0-6
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/coan/
 * License : GPLv3
   Programming Lang: C++
   Description : an automata simulation GUI using Qt

Full-fledged automaton simulator which can run finite automata, pushdown 
automata, Turing machines and machine schemata for deterministic and 
non-deterministic automata. It may be used for educational as well as 
possibly also for scientific purposes to test a Turing machine 
constructed on paper. Many proves use Turing machines as model for 
computability. To ease the construction of complicated Turing machines 
you may define machine schemata. Simulating non-deterministic automata 
by showing all possible activations in parallel is also an interesting 
feature that is to my knowledge not supported by similar projects at 
least not for all machines and in a way providing similar oversight.

Bug#918492: (no subject)

[Bart Van Assche]

Can someone backport the upstream bug fix mentioned in
https://bugs.kde.org/show_bug.cgi?id=398324?

Bug#933007: pkg-js-tools: Automatically link components in node_modules directory

[Xavier Guimard]

Package: pkg-js-tools
Version: 0.8.1
Severity: wishlist

When using components in node modules, the best way to use them is to
install them in node_modules/ directory. However, dpkg-source install
them at the top source directory under a directory named by "component"
field value (debian/watch).

The idea here is, before build, to automatically read debian/watch to find
components, read /package.json to find the node name and
create a link "../ => " in node_modules directory
(created on-the-fly). Also, it will remove automatically node_modules
directory during dh_clean step.
Then no need to overwrite NODE_PATH in debian/rules.

Any comment is welcome here ;-).

Bug#933003: Golang-go should suggest git

[Louis-Philippe Véronneau]

The MR in question:

https://salsa.debian.org/go-team/compiler/golang-defaults/merge_requests/1

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#933006: reportbug should warn about '@localhost' email addresses

[Chris Danis]

Package: reportbug
Version: 7.5.2

A friend of mine used reportbug for the first time and it attempted to
submit a bug from username@localhost.  Ideally it would detect an
obviously-bogus email address like this and prompt the user.

Bug#933005: ansible: CVE-2019-10206

[Salvatore Bonaccorso]

Source: ansible
Version: 2.7.8+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ansible/ansible/pull/59246
Control: found -1 2.7.7+dfsg-1

Hi,

The following vulnerability was published for ansible.

CVE-2019-10206[0]:
disclosure data when prompted for password and template characters are passed

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-10206
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10206
[1] https://github.com/ansible/ansible/pull/59246

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#933004: reportbug should default to smtphost reportbug.debian.org

[Chris Danis]

Package: reportbug
Version: 7.5.2

While reportbug-gtk will prompt the user about MTAs vs using a
smtphost (and offer reportbug.debian.org as an option), plain
reportbug will not.  I was attempting to guide a friend of mine
through reportbug'ing a kernel issue using reportbug while he was
using ssh to the machine in question, and it took some time to realize
that as he had no MTA configured, nothing had actually happened.

I suspect many users are often in the situation of wanting to
reportbug about issues soon after installing the system.  Probably,
reportbug should default to using a known-to-work SMTP host.