Bug#928299: Confirmation
Dear Marc, dear maintainer, I can confirm the problem: See also https://lists.debian.org/debian-user-german/2019/04/msg00138.html (German). Unfortunately I did not manage to add a valid password hash (I tried it, too), but this probably was a typo, and I'm glad that you could do it, Marc. Thanks and greetings Frank. eXirius IT Dienstleistungen GmbH Juchem-Straße 24 | 66571 Eppelborn T +49 6881 5 0 | i...@exirius.de http://www.exirius.de Amtsgericht Saarbrücken HRB 12124 Geschäftsführer: Dipl.-Math. oec. Michael Royar
Bug#928230: [debian-mysql] Bug#928230: (no subject)
Hello! Thanks for working on this! Since this will is not Debian packaging specific, can you please submit it directly upstream? to 2. toukokuuta 2019 klo 2.30 Gregor Riepl kirjoitti: > tags -1 patch > thanks > > Here's a patch that adds support for the missing flags to mariadb_config. > mysql_config.sh mentioned several equivalent flags, so I added all of them. > ___ > pkg-mysql-maint mailing list > pkg-mysql-ma...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint
Bug#928323: python-atomicwrites: new upstream version (1.3.0)
Source: python-atomicwrites Version: 1.1.5-2 Severity: wishlist The latest upstream version of atomicwrites restores the ability to pass prefix/suffix to the temporary file creation function. https://github.com/untitaker/python-atomicwrites/issues/37 https://github.com/untitaker/python-atomicwrites/issues/38 https://github.com/untitaker/python-atomicwrites/issues/39 https://github.com/untitaker/python-atomicwrites/issues/40 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#928315: qtchooser: qdbus does not find qt5 qdbus
Please also check if you have any configuration file in /etc/xdg/qtchooser
Bug#928322: asmail FTCBFS: configures for the build architecture
Source: asmail Version: 2.1-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap asmail fails to cross build from source, because it configures for the build architecture. Unfortunately, the ./configure is so ancient that dh_auto_configure won't fix that. Exporting a suitable CC does the trick though. Please consider applying the attached patch. Helmut diff -u asmail-2.1/debian/changelog asmail-2.1/debian/changelog --- asmail-2.1/debian/changelog +++ asmail-2.1/debian/changelog @@ -1,3 +1,10 @@ +asmail (2.1-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Export a suitable CC for ./configure. (Closes: #-1) + + -- Helmut Grohne Thu, 02 May 2019 06:16:16 +0200 + asmail (2.1-4) unstable; urgency=low * Fix crash if starting without HOME variable set (closes: #715652) diff -u asmail-2.1/debian/rules asmail-2.1/debian/rules --- asmail-2.1/debian/rules +++ asmail-2.1/debian/rules @@ -5,6 +5,8 @@ DPKG_EXPORT_BUILDFLAGS=1 include /usr/share/dpkg/buildflags.mk +-include /usr/share/dpkg/buildtools.mk +export CC build: build-arch build-indep build-arch: build-stamp
Bug#928321: fped FTCBFS: Makefile hard codes wrong pkg-config
Source: fped Version: 0.1+201210-1.1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap fped fails to cross build from source, because the upstream Makefile hard codes the build architecture pkg-config. The attached patch makes pkg-config substitutable and fped cross buildable. Please consider applying it. Helmut --- fped-0.1+201210.orig/Makefile +++ fped-0.1+201210/Makefile @@ -33,9 +33,10 @@ SHELL = /bin/bash +PKG_CONFIG ?= pkg-config CPPFLAGS += -CFLAGS_GTK = `pkg-config --cflags gtk+-2.0` -LIBS_GTK = `pkg-config --libs gtk+-2.0` +CFLAGS_GTK = `$(PKG_CONFIG) --cflags gtk+-2.0` +LIBS_GTK = `$(PKG_CONFIG) --libs gtk+-2.0` CFLAGS_WARN = -Wall -Wshadow -Wmissing-prototypes \ -Wmissing-declarations -Wno-format-zero-length
Bug#928320: openambit FTCBFS: runs cmake for the build architecture
Source: openambit
Version: 0.3-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
openambit fails to cross build from source, because it does not pass
cross flags to cmake. The easiest way of fixing that - using
dh_auto_configure - makes openambit cross buildable. Please consider
applying the attached patch.
Helmut
diff --minimal -Nru openambit-0.3/debian/changelog
openambit-0.3/debian/changelog
--- openambit-0.3/debian/changelog 2019-02-03 10:38:27.0 +0100
+++ openambit-0.3/debian/changelog 2019-05-02 06:06:29.0 +0200
@@ -1,3 +1,9 @@
+openambit (0.3-3) UNRELEASED; urgency=medium
+
+ * Fix FTCBFS: Let dh_auto_configure pass cross flags to cmake. (Closes: #-1)
+
+ -- Helmut Grohne Thu, 02 May 2019 06:06:29 +0200
+
openambit (0.3-2) unstable; urgency=high
* QA upload.
diff --minimal -Nru openambit-0.3/debian/rules openambit-0.3/debian/rules
--- openambit-0.3/debian/rules 2014-09-16 21:34:05.0 +0200
+++ openambit-0.3/debian/rules 2019-05-02 06:06:29.0 +0200
@@ -13,11 +13,9 @@
dh $@
override_dh_auto_build:
- mkdir libambit-build
- cd libambit-build && cmake ../src/libambit -DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_C_FLAGS="${CMAKE_C_FLAGS} $(CFLAGS)"
-DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} $(CXXFLAGS)"
+ dh_auto_configure --builddirectory=libambit-build
--sourcedirectory=src/libambit -- -DCMAKE_BUILD_TYPE=Release
-DCMAKE_C_FLAGS="${CMAKE_C_FLAGS} $(CFLAGS)"
-DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} $(CXXFLAGS)"
cd libambit-build && $(MAKE) -j$(NUMCPUS)
- mkdir openambit-build
- cd openambit-build && cmake ../src/openambit -DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_C_FLAGS="${CMAKE_C_FLAGS} $(CFLAGS)"
-DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} $(CXXFLAGS)"
+ dh_auto_configure --builddirectory=openambit-build
--sourcedirectory=src/openambit -- -DCMAKE_BUILD_TYPE=Release
-DCMAKE_C_FLAGS="${CMAKE_C_FLAGS} $(CFLAGS)"
-DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} $(CXXFLAGS)"
cd openambit-build && $(MAKE) -j$(NUMCPUS)
INSTDIR=../debian/tmp/
Bug#928315: qtchooser: qdbus does not find qt5 qdbus
El jueves, 2 de mayo de 2019 00:34:14 -03 Lisandro Damián Nicanor Pérez Meyer escribió: > tag 928315 unreproducible moreinfo > thanks > > Hi Stuart! > > El miércoles, 1 de mayo de 2019 22:03:55 -03 Stuart Prescott escribió: > > Package: qtchooser > > Version: 66-1 > > Severity: serious > > Justification: Policy 9.9 Programs installed on PATH must not depend on > > environment to get reasonable defaults > > > > Dear Maintainer, > > > > On two systems I have running buster, I get the following: > > > > $ qdbus > > qdbus: could not exec '/usr/lib/x86_64-linux-gnu/qt5/bin/qdbus' since it > > links to qdbus itself. Check your installation. $ QT_SELECT=5 qdbus > > [... lots of output ...] > > There is something odd in here. Calling qdbus without parameters should not > call the qt5 version as in your case. > > By default the qt4 version should be called except the user does something > to force the situation like installing qt5-default or passing -qt5 as > argument or setting the environment variable you discovered above. But > again: it should not happen in an "out of the box" installation. > > Do you have qt4-default or qt5-default installed? In case you do: did you > install it by hand or something else dragged it in? I have tried to > reproduce the issue with and without qt5-default installed without success, > so the issue might be somewhere else. The message "since it links to" comes from qtchooser itself. It seems like a broken symlink somewhere :-/ Please check if the following commands outputs match yours: $ ls -alh /usr/lib/x86_64-linux-gnu/qtchooser/ total 336K drwxr-xr-x 2 root root 4,0K may 2 00:28 . drwxr-xr-x 143 root root 328K abr 30 14:01 .. lrwxrwxrwx 1 root root 50 nov 27 17:22 4.conf -> ../../../share/qtchooser/qt4-x86_64-linux-gnu.conf lrwxrwxrwx 1 root root 50 nov 27 17:22 5.conf -> ../../../share/qtchooser/qt5-x86_64-linux-gnu.conf lrwxrwxrwx 1 root root 50 nov 27 17:22 qt4.conf -> ../../../share/qtchooser/qt4-x86_64-linux-gnu.conf lrwxrwxrwx 1 root root 50 nov 27 17:22 qt5.conf -> ../../../share/qtchooser/qt5-x86_64-linux-gnu.conf $ ls -alh /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf lrwxrwxrwx 1 root root 53 abr 12 17:10 /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf -> ../../../../share/qtchooser/qt4-x86_64-linux-gnu.conf $ ls -alh /usr/lib/x86_64-linux-gnu/qt5/qt.conf -rw-r--r-- 1 root root 552 mar 15 04:20 /usr/lib/x86_64-linux-gnu/qt5/qt.conf $ ls -alh /usr/share/qtchooser/ total 32K drwxr-xr-x 2 root root 4,0K nov 29 15:55 . drwxr-xr-x 610 root root 20K abr 16 14:23 .. -rw-r--r-- 1 root root 60 nov 27 17:22 qt4-x86_64-linux-gnu.conf -rw-r--r-- 1 root root 43 nov 27 17:22 qt5-x86_64-linux-gnu.conf -- Only Irish coffee provides in a single glass all four essential food groups -- alcohol, caffeine, sugar, and fat. Alex Levine Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#928319: ITP: ngraph -- C++ library, compiler and runtime for Deep Learning frameworks
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: ngraph Version : Upstream Author : Nervana / Intel * URL : https://github.com/NervanaSystems/ngraph * License : Apache-2.0 Programming Lang: C++ Description : C++ library, compiler and runtime for Deep Learning frameworks This is a low-level building block for modern deep learning frameworks or inference engines such as Tensorflow and ONNX runtime. I have a good impression on the quality of Intel's open source software. This library should be fine if it doesn't pose a heavy workload on me.
Bug#928318: ITP: onnxruntime -- scoring engine for Open Neural Network Exchange (ONNX) models
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: onnxruntime Version : 0.4.0 Upstream Author : Microsoft, et al. * URL : https://github.com/Microsoft/onnxruntime * License : MIT Programming Lang: C++ Description : scoring engine for Open Neural Network Exchange (ONNX) models
Bug#928317: xcb FTCBFS: Uses the build architecture compiler
Source: xcb Version: 2.4-4.3 Severity: normal Tags: patch User:helm...@debian.org Usertags: rebootstrap Hi, xcb fails to cross build from source, because it uses the build architecture compiler. Using "dh_auto_build" instead of "$(MAKE)" can solve this problem. Please consider applying the attached patch. Hieu. diff -Nru xcb-2.4/debian/rules xcb-2.4/debian/rules --- xcb-2.4/debian/rules2012-05-11 17:23:09.0 +0700 +++ xcb-2.4/debian/rules2012-05-11 18:25:15.0 +0700 @@ -10,7 +10,7 @@ override_dh_auto_build: # CCOPTIONS is used to pass CFLAGS, CPPFLAGS when compiling .c files, # EXTRA_LOAD_FLAGS when linking the program. - $(MAKE) \ + dh_auto_build -- \ CCOPTIONS="$(CFLAGS) $(CPPFLAGS)" \ EXTRA_LOAD_FLAGS="-I. $(CFLAGS) $(LDFLAGS)" cp xcb.man debian/xcb.1 -- This mail was scanned by BitDefender For more information please visit http://www.bitdefender.com
Bug#928315: qtchooser: qdbus does not find qt5 qdbus
tag 928315 unreproducible moreinfo thanks Hi Stuart! El miércoles, 1 de mayo de 2019 22:03:55 -03 Stuart Prescott escribió: > Package: qtchooser > Version: 66-1 > Severity: serious > Justification: Policy 9.9 Programs installed on PATH must not depend on > environment to get reasonable defaults > > Dear Maintainer, > > On two systems I have running buster, I get the following: > > $ qdbus > qdbus: could not exec '/usr/lib/x86_64-linux-gnu/qt5/bin/qdbus' since it > links to qdbus itself. Check your installation. $ QT_SELECT=5 qdbus > [... lots of output ...] There is something odd in here. Calling qdbus without parameters should not call the qt5 version as in your case. By default the qt4 version should be called except the user does something to force the situation like installing qt5-default or passing -qt5 as argument or setting the environment variable you discovered above. But again: it should not happen in an "out of the box" installation. Do you have qt4-default or qt5-default installed? In case you do: did you install it by hand or something else dragged it in? I have tried to reproduce the issue with and without qt5-default installed without success, so the issue might be somewhere else. Cheers, Lisandro. -- “I don’t think security can solve problems. We need to teach greater respect.” Oslo Mayor Stang when asked whether Oslo needs greater security after the attacks in Norway, 07/2011. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
> I've re-collected the debug output from the prior round of this from the
> clean restart of the X server in the hopes that might help provide less
> confusing diagnostics. Notably now helvetica doesn't appear at all in the
> output of xlsfonts.
Yeah you definitely need to run the font tests on the same instance / run in
which xscreensaver is exhibiting problems...
> -arabic-newspaper-medium-r-normal--19-140-100-100-p-0-iso10646-1
I'm gonna guess that this font, despite claiming to be 10646 (Unicode) does not
actually contain Latin characters... So that's not ideal if your locale is set
to one that requires those.
It looks like you've got a smattering of Arabic and Japanese fonts, but all of
your Latin fonts are fixed-width! Is that intentional? By which I mean is, did
you do this on purpose or is your distro doing this by default for some reason?
Maybe you manually deleted some package that you shouldn't have?
Are any of your apps capable of displaying Latin letters in variable width? If
so, my next question will be, what font are those apps finding and how?
The following patch might help: this will remove the wildcard font-family
fallback, which should result in the xscreensaver dialogs being in "fixed"
instead of that Arabic font. But I'd still like to understand how your machine
got into this state, and how likely it is that others will also be dealing with
similar configurations.
diff --git a/utils/font-retry.c b/utils/font-retry.c
index ab999e2b..66b827f4 100644
--- a/utils/font-retry.c
+++ b/utils/font-retry.c
@@ -114,7 +114,8 @@ load_font_retry_1 (Display *dpy, int screen, const char
*xlfd, Bool xft_p)
"american typewriter",
"fixed",
"ocr a std",
- "*" };
+ /* "*" */
+ };
const char *variable[] = { "helvetica",
"arial",
"bitstream vera sans",
@@ -126,7 +127,8 @@ load_font_retry_1 (Display *dpy, int screen, const char
*xlfd, Bool xft_p)
"palatino",
"lucida",
"bitstream charter",
- "*" };
+ /* "*" */
+ };
const char *charsets[] = { "iso10646-1", "iso8859-1", "*-*" };
const char *weights[] = { "bold", "medium" };
const char *slants[] = { "o", "i", "r" };
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
On Tue, 30 Apr 2019, Jamie Zawinski wrote: Ok, I'm not really sure what's going on here. This makes me feel better ;) Possibly the problem is that your font cache needs to be regenerated with fc-cache? Tried that, didn't impact things. There's definitely a sign something is wonky in that area, however, given: $ grep -r helvetica /usr/share/fonts/X11 /usr/share/fonts/X11/misc/fonts.alias:variable -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1 (and no other matches) This didn't make sense with my first round at the diagnostics you asked for below, so I tried restarting the X session after removing the xfonts-100dpi and doing things over again. What do you get with: xlsfonts -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' Before the X restart, I got 3 answers for '-adobe-helvetica-...'. After the restart, I get: xlsfonts: pattern "-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1" unmatched xlsfonts -fn '-adobe-helvetica-bold-r-normal--0-0-100-100-p-0-iso8859-1' Before the restart, I got one answer. After I get: xlsfonts: pattern "-adobe-helvetica-bold-r-normal--0-0-100-100-p-0-iso8859-1" unmatched Does text show if you do: xterm -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' I get text, looks like the standard "fixed" font ... but presumably that's related to this error: xterm: cannot load font "-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1" This one didn't change before/after restarting X. I've re-collected the debug output from the prior round of this from the clean restart of the X server in the hopes that might help provide less confusing diagnostics. Notably now helvetica doesn't appear at all in the output of xlsfonts. The two variants of medium listed as "substituted ..." in the xscreensaver debug output produce "interesting" results in xterm: -*-*-medium-r-*-*-*-180-*-*-p-*-iso10646-1 => giant xterm with huge square characters (as judged by the size of the cursor block), but all the characters are blank -*-*-medium-r-*-*-*-140-*-*-p-*-iso10646-1 => same idea, just slightly less huge. Huge here being approximately 3x the height & 4x the width of the characters in xterm's default font. xlsfonts on each of these patterns produces this output (substituting the 140 point size as appropriate for that case): -arabic-newspaper-medium-r-normal--19-140-100-100-p-0-iso10646-1 -mutt-clearlyu alternate glyphs-medium-r-normal--19-140-100-100-p-0-iso10646-1 -mutt-clearlyu arabic-medium-r-normal--19-140-100-100-p-0-iso10646-1 -mutt-clearlyu pua-medium-r-normal--19-140-100-100-p-0-iso10646-1 -mutt-clearlyu-medium-r-normal--19-140-100-100-p-0-iso10646-1 I can't select the first one in xfontsel for whatever reason, which seems odd. In fact, if I get xfontsel to -*-*-medium-r-*-*-*-*-*-*-p-*-iso10646-1, there are _no_ fonts at ptSz 180 or 140. If I select one of the ptSz values that exists for the "arabic" one, I don't get any text. Same happens with "mutt-clearlyu alternate glyphs", and mostly so with "... arabic" (there's a couple funky characaters rendered, but nothing in the latin alphanumerics). "mutt-clearlyu pua" renders mostly as tofu (as opposed to totally blank space). "mutt-clearlyu" renders as an ugly but legible font with the expected characters all there. , hope this helps! -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9 fonts.2.txt.gz Description: fonts.2.txt.gz xscreensaver.debug.2.log.gz Description: xscreensaver.debug.2.log.gz
Bug#928316: RFS: hollywood/1.15-1
Package: sponsorship-requests Severity: normal X-Debbugs-CC ba...@knars.be Dear mentors, I am looking for a sponsor for my package "hollywood" * Package name : hollywood Version : 1.15-1 Upstream Author : Dustin Kirkland * URL : https://github.com/dustinkirkland/hollywood * License : Apache-2.0 Section : games It builds those binary packages: hollywood - fill your console with Hollywood melodrama technobabble wallstreet - fill your console with Wall Street-like news and stats To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hollywood Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hollywood/hollywood_1.15-1.dsc More information about hollywood can be obtained from https://github.com/dustinkirkland/hollywood Changes since the last upload: [ Dustin Kirkland ] * opening 1.15 * Added screenshots from public usage of Hollywood * README: - removed some cruft * screenshots/ - added a screenshots directory [ Emmanuel Arias ] * New upstream version 1.15 Regards, Emmanuel Arias -- Emmanuel Arias @eamanu https://eamanu.com signature.asc Description: OpenPGP digital signature
Bug#926903: Installation-report addition
Hi Ben, I ran 'update-initramfs -u' and got several lines saying 'W: Possible missing firmware /lib/firmware/amdgpu/vega20_ xxx for module a[off screen here]pu' where xxx refers to different items. Regards, Tom Thekathyil On Thu, 2019-05-02 at 00:45 +0100, Ben Hutchings wrote: > Does running "update-initramfs -u" fix the problem for you? -- PO Box 76, St. Helens, TAS 7216, Australia - Ph: 61 3 6373 6191 GnuPG Public Key 0xD8F45B65
Bug#928315: qtchooser: qdbus does not find qt5 qdbus
Package: qtchooser Version: 66-1 Severity: serious Justification: Policy 9.9 Programs installed on PATH must not depend on environment to get reasonable defaults Dear Maintainer, On two systems I have running buster, I get the following: $ qdbus qdbus: could not exec '/usr/lib/x86_64-linux-gnu/qt5/bin/qdbus' since it links to qdbus itself. Check your installation. $ QT_SELECT=5 qdbus [... lots of output ...] $ apt list qdbus qdbus-qt5 qtchooser qdbus-qt5/testing,now 5.11.3-4 amd64 [installed] qdbus/testing,now 4:4.8.7+dfsg-18 amd64 [installed,automatic] qtchooser/testing,now 66-1 amd64 [installed,automatic] Getting reasonable behaviour out of qdbus should not require setting environment variables, as per policy 9.9. regards Stuart -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (550, 'testing'), (500, 'testing-proposed-updates'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qtchooser depends on: ii libc6 2.28-8 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 qtchooser recommends no packages. qtchooser suggests no packages. -- no debconf information
Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)
On Thursday, April 11 2019, Santiago Vila wrote: > On Sun, 7 Apr 2019, Chris Lamb wrote: > >> Santiago Vila wrote: >> >> > I tried to build this package in buster but it failed: >> >> Hm, I've just built this package 20 times in sid and the tests pass >> every time. > > Well, but I can't build packages in your machine, I have to do it in > my machine, and it fails 50% of the time for me. Try building on a > START1-XS instance from Scaleway (still available on Amsterdam), or > ask me for an account in such a machine. I can't reproduce this one on my machine either, so I'd like to follow up on your offer and request access to the machine mentioned above, assuming that the bug still manifests, of course. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#928103: python-pythonmagick, python3-pythonmagick: import PythonMagick fails with undefined symbol: _Z41Export_pyste_src_DrawableStrokeDashOffsetv
I can confirm that the bug is fixed on version uploaded to testing I CC Juhani Numminen Regards -- Arias Emmanuel http://eamanu.com Github/Gitlab; @eamanu Debian: @eamanu-guest
Bug#926903: Installation-report addition
On Thu, 2019-05-02 at 07:32 +1000, Tom Thekathyil wrote: > Hi Ben, > > Thanks for trying to help. You will note from my original report as > well as the follow-up on 28 April that I had installed the > 'firmware-amd-graphics' package and still get the error message. Ah, sorry. > # apt search firmware-amd-graphics > > firmware-amd-graphics/testing, now 201901 14-1 all [installed] > > # whereis firmware-amd-graphics > > firmware-amd-graphics: > > Despite above response I am able to install and remove the package > easily. But it makes no visible difference to the graphics or to > dmesg error message. [...] All the amdgpu driver is doing at that point is checking that /lib/firmware/amdgpu exists - which it certainly does in the main system. But perhaps the driver has been included in the initramfs without the firmware. (I can check this but it will take a while.) Does running "update-initramfs -u" fix the problem for you? Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#928230: (no subject)
tags -1 patch
thanks
Here's a patch that adds support for the missing flags to mariadb_config.
mysql_config.sh mentioned several equivalent flags, so I added all of them.
diff --git a/libmariadb/mariadb_config/mariadb_config.c.in b/libmariadb/mariadb_config/mariadb_config.c.in
index 45d2f4e3c..f7023d990 100644
--- a/libmariadb/mariadb_config/mariadb_config.c.in
+++ b/libmariadb/mariadb_config/mariadb_config.c.in
@@ -15,6 +15,7 @@ static char *mariadb_progname;
#define SOCKET "@MARIADB_UNIX_ADDR@"
#define PORT "@MARIADB_PORT@"
#define TLS_LIBRARY_VERSION "@TLS_LIBRARY_VERSION@"
+#define EMBED_LIBS "-L@CMAKE_INSTALL_PREFIX@/@INSTALL_LIBDIR@/ -lmariadbd @extra_dynamic_LDFLAGS@"
static struct option long_options[]=
{
@@ -30,6 +31,9 @@ static struct option long_options[]=
{"port", no_argument, 0, 'i'},
{"plugindir", no_argument, 0, 'j'},
{"tlsinfo", no_argument, 0, 'k'},
+ {"libmysqld-libs", no_argument, 0, 'm' },
+ {"embedded-libs", no_argument, 0, 'm' },
+ {"embedded", no_argument, 0, 'm' },
{NULL, 0, 0, 0}
};
@@ -46,7 +50,10 @@ static const char *values[]=
SOCKET,
PORT,
PLUGIN_DIR,
- TLS_LIBRARY_VERSION
+ TLS_LIBRARY_VERSION,
+ EMBED_LIBS,
+ EMBED_LIBS,
+ EMBED_LIBS,
};
void usage(void)
@@ -115,6 +122,9 @@ int main(int argc, char **argv)
case 'l':
puts(LIBS_SYS);
break;
+case 'm':
+ puts(EMBED_LIBS);
+ break;
default:
exit((c != -1));
}
Bug#928314: wakeonlan requires netdata as dependency
Package: wakeonlan
The wakeonlan binary (all versions of all Debian branches) depends on
the netdata package. Without netdata, the following error shows up:
--
root@VM-Buster:~# wakeonlan XX:XX:XX:XX:XX:XX
Use of uninitialized value $proto in socket at /usr/bin/wakeonlan line 121.
Use of uninitialized value $port in concatenation (.) or string at
/usr/bin/wakeonlan line 124.
Sending magic packet to 255.255.255.255: with XX:XX:XX:XX:XX:XX
send : Invalid argument at /usr/bin/wakeonlan line 126.
--
The failing code part of the (perl) script:
--
15 my $DEFAULT_PORT = getservbyname('discard', 'udp');
...
118 $them = pack_sockaddr_in($port, $raddr);
119 $proto = getprotobyname('udp');
120
121 socket(S, AF_INET, SOCK_DGRAM, $proto) or die "socket : $!";
122 setsockopt(S, SOL_SOCKET, SO_BROADCAST, 1) or die "setsockopt : $!";
123
124 print "Sending magic packet to $ipaddr:$port with $hwaddr\n";
125
126 send(S, $pkt, 0, $them) or die "send : $!";
--
- If no $port is given, the default "discard" port for UDP is used.
- As no port is given in the output (after 255.255.255.255:), this
obviously fails.
- Deriving $proto fails as well.
getprotobyname() and getprotobyname() depend on files provided by the
netdata package, e.g. /etc/protocols.
The perl package has netdata as recommendation, which might be the
reason why this error is rarely faced: https://packages.debian.org/sid/perl
But since wakeonlan uses perl functions that strictly depend on netdata,
it should depend on it, so it is pulled even when used with
"--no-install-recommends".
Bug#928313: apt-key check for revoked keys
Package: apt Version: 1.8.0 I have this in my apt keyring: /etc/apt/trusted.gpg pub rsa4096 2015-06-11 [SC] C35E B17E 1EAE 708E 6603 A9B3 AD05 92FE 47F0 DF61 uid [ unknown] matrix.org (Debian signing key) sub rsa4096 2015-06-11 [E] But I know that that key has been revoked, and the revoked key is in my keyring: pub rsa4096/AD0592FE47F0DF61 2015-06-11 [SC] [revoked: 2019-04-12] C35EB17E1EAE708E6603A9B3AD0592FE47F0DF61 uid [ revoked] matrix.org (Debian signing key) But there doesn't seem to be any infrastructure to check that a key is revoked other than manually updating it. Kurt
Bug#927270: proftpd-basic: breaks directive with AuthAliasOnly
On 01.05.19 23:26, Hilmar Preuße wrote: > On 17.04.19 07:52, Tatsuki Sugiura wrote: Hi Tatsuki, >> I think this is related with follwing upstream bug; >> >> * http://bugs.proftpd.org/show_bug.cgi?id=4314 >> * https://github.com/proftpd/proftpd/pull/567 >> * https://github.com/proftpd/proftpd/pull/309 >> > Thanks for investigation! > - pull_309 is related to Bug#4255, which should have been solved in > 1.3.6rc3. > - Bug#4314 could be applied, I'll take a look at that. > OK, I've built new packages and uploaded to [1]. Please give 'em a try and report back if they solve your problem. If they do I'll try to get them into buster. Sorry only i386 for now, if you need other arches, please drop me a note. Hilmar [1] https://freeshell.de/~hille42/proftpd/927270/ -- #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#924934: connman: add a connmant-tests package
Hi Ritesh, no problem, will do so. Would you be so kind and review and sponsor it for NEW? Thanks, Alf
Bug#926903: Installation-report addition
Hi Ben, Thanks for trying to help. You will note from my original report as well as the follow-up on 28 April that I had installed the 'firmware-amd-graphics' package and still get the error message. # apt search firmware-amd-graphics > firmware-amd-graphics/testing, now 201901 14-1 all [installed] # whereis firmware-amd-graphics > firmware-amd-graphics: Despite above response I am able to install and remove the package easily. But it makes no visible difference to the graphics or to dmesg error message. Changing to a less ancient monitor has helped center the screen but there still remains the problem of font size: a) tty1-6 use large fonts b) MATE Terminal font size is normal c) XTerm & UXTerm has small windows and small font d) emacs and pluma have normal fonts I can live with all these but it would be nice to get to the root of the problem. I expect you might like to fix it before stable release. Regards, Tom Thekathyil On Tue, 2019-04-30 at 12:49 +0100, Ben Hutchings wrote: > On Tue, 2019-04-30 at 10:51 +1000, Tom Thekathyil wrote: > > Hi Geert, > > > > Thank you so much for your prompt reply. > > > > Your suggestion it could be a monitor problem provided the clue it > > could be the 11-year old model used (Acer X223w) that was causing the > > problem. Swapped for a more current unit (Dell U2414H) and screen is > > nicely centered now. > > > > That still leaves the problem why dmesg shows > > '[ 1.349124] [drm:amdgpu_pci_probe [amdgpu]] *ERROR* amdgpu > >requires firmware installed]' > > Which firmware? > [...] > > The firmware-amd-graphics package. > > Ben. > -- PO Box 76, St. Helens, TAS 7216, Australia - Ph: 61 3 6373 6191 GnuPG Public Key 0xD8F45B65
Bug#927270: proftpd-basic: jessie-security (1.3.5e) breaks directive with AuthAliasOnly
On 17.04.19 07:52, Tatsuki Sugiura wrote: Hi Tatsuki, > proftpd-basic package has been updated to 1.3.5e on jessie-security. > It breaks directive in some case. > > In my case, User is not affetcted in if AuthAliasOnly is on. > > This problem is caused on 1.3.5e-0+deb8u1 (jessie-security) and 1.3.6-4 (sid). > 1.3.5b-4 (stretch) and 1.3.5-1.1+deb8u2 (jessie) works well. > jessie-security should be fixed by now somehow. I'll look at sid right now. > I think this is related with follwing upstream bug; > > * http://bugs.proftpd.org/show_bug.cgi?id=4314 > * https://github.com/proftpd/proftpd/pull/567 > * https://github.com/proftpd/proftpd/pull/309 > Thanks for investigation! - pull_309 is related to Bug#4255, which should have been solved in 1.3.6rc3. - Bug#4314 could be applied, I'll take a look at that. Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#928312: ITP: osdlyrics -- Show synchronized lyrics with various media players
Package: wnpp Severity: wishlist Owner: Boyuan Yang * Package name: osdlyrics Version : 0.5.5~rc1 Upstream Author : Tiger Soldier * URL : https://github.com/osdlyrics/osdlyrics * License : GPL-3+ Programming Lang: Python/C Description : Show synchronized lyrics with various media players OSD Lyrics is a standalone desktop application to view lyrics. It is compatible with various media players. It shows lyrics on your desktop in the style similar to KaraOK. It also provides the feature to download lyrics from the Internet automatically. Packaging repo: https://salsa.debian.org/debian/osdlyrics.git -- Thanks, Boyuan Yang
Bug#928281: unblock: lemonldap-ng/2.0.2+ds-7 (pre-approval)
Control: tags -1 moreinfo confirmed Xavier Guimard: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package lemonldap-ng > > Hi all, > > upstream authors of lemonldap-ng have updated language translations. I > imported updated translation files in a patch. Do you think it is > opportune to update lemonldap-ng package to have better l10n support in > Buster? > > Cheers, > Xavier > > unblock lemonldap-ng/2.0.2+ds-7 > > [...] Please go ahead with the upload and remove the moreinfo tag when it is in unstable and ready to be unblocked. Thanks, ~Niels
Bug#928311: geany-plugin-spellcheck : Depends: geany-abi-18176 but it is not installable
Package: geany-plugin-spellcheck Version: 1.33+dfsg-1+b1 Severity: grave Tags: a11y Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages geany-plugin-spellcheck depends on: ii geany 1.34.1-1 pn geany-abi-18176 pn geany-plugins-common ii libc6 2.28-9 ii libenchant1c2a1.6.0-11.1+b1 ii libglib2.0-0 2.58.3-1 ii libgtk-3-03.24.5-1 geany-plugin-spellcheck recommends no packages. geany-plugin-spellcheck suggests no packages.
Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)
Hi, On 2019-05-01 00:04, Aurelien Jarno wrote: > On 2019-04-30 10:12, Uwe Kleine-König wrote: > > > > More precisely the board is a "Marvell Armada XP Development Board > > > > DB-MV784MP-GP" > > > > > > > > > anymore. Using tcpdump on both the buildd and a remote host, it > > > > > appears > > > > > that the packets correctly leave the board and that the reception side > > > > > fails. > > > > If you can send to a remote host at least ARP (or ND) must be working, > > so some reception still works, right? > > I have to try again, but what i have seen is the ARP requests from > hartmann arriving to the other hosts on the subnet. Steve McIntyre > (added in Cc:) confirmed me on IRC being able to reproduce the issue on > another board. I confirm that. Basically on the other hosts of the same subnet, I can see the ARP requests: 18:23:45.979860 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46 18:23:47.002990 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46 18:23:48.027262 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46 18:23:52.004248 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46 18:23:53.019252 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46 18:23:54.043276 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46 18:23:58.027937 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46 172.28.17.1 is the gateway, 172.28.17.18 is hartmann.d.o. > > Is it possible to test a few things on hartmann? I'd suggest: > > > > - try (vanilla) 5.1-rc6 with MVNETA=y I have tried 5.1-rc7 with: CONFIG_MVNETA_BM_ENABLE=y CONFIG_MVNETA=y CONFIG_MVNETA_BM=y and also with CONFIG_MVNETA_BM_ENABLE=m CONFIG_MVNETA=m CONFIG_MVNETA_BM=m And the mvneta network driver is not able to receive data in both cases. Best regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#928240: etw: Segmentation fault at start
Thank you very much. I have uploaded a new revision with your patch a few minutes ago. The game itself appears to work, the settings menu for the controls is a bit hidden. ETW was originally developed for the AMIGA, so that may explain some of the oddities. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#928310: unblock: wpa/2:2.7+git20190128+0c1e29f-5
Hi
Attached the debdiff between 2:2.7+git20190128+0c1e29f-4 and
2:2.7+git20190128+0c1e29f-5.
Regards,
Salvatore
diff -Nru wpa-2.7+git20190128+0c1e29f/debian/changelog
wpa-2.7+git20190128+0c1e29f/debian/changelog
--- wpa-2.7+git20190128+0c1e29f/debian/changelog2019-04-10
19:00:22.0 +0200
+++ wpa-2.7+git20190128+0c1e29f/debian/changelog2019-04-26
14:55:52.0 +0200
@@ -1,3 +1,11 @@
+wpa (2:2.7+git20190128+0c1e29f-5) unstable; urgency=high
+
+ * Fix security issue 2019-5:
+- EAP-pwd message reassembly issue with unexpected fragment
+ (Closes: #927463, no CVE assigned).
+
+ -- Andrej Shadura Fri, 26 Apr 2019 14:55:52 +0200
+
wpa (2:2.7+git20190128+0c1e29f-4) unstable; urgency=high
* Apply security fixes (Closes: #926801):
diff -Nru
wpa-2.7+git20190128+0c1e29f/debian/patches/2019-5/0001-EAP-pwd-server-Fix-reassembly-buffer-handling.patch
wpa-2.7+git20190128+0c1e29f/debian/patches/2019-5/0001-EAP-pwd-server-Fix-reassembly-buffer-handling.patch
---
wpa-2.7+git20190128+0c1e29f/debian/patches/2019-5/0001-EAP-pwd-server-Fix-reassembly-buffer-handling.patch
1970-01-01 01:00:00.0 +0100
+++
wpa-2.7+git20190128+0c1e29f/debian/patches/2019-5/0001-EAP-pwd-server-Fix-reassembly-buffer-handling.patch
2019-04-26 14:55:52.0 +0200
@@ -0,0 +1,45 @@
+From fe76f487e28bdc61940f304f153a954cf36935ea Mon Sep 17 00:00:00 2001
+From: Jouni Malinen
+Date: Wed, 17 Apr 2019 01:55:32 +0300
+Subject: [PATCH 1/3] EAP-pwd server: Fix reassembly buffer handling
+
+data->inbuf allocation might fail and if that were to happen, the next
+fragment in the exchange could have resulted in NULL pointer
+dereference. Unexpected fragment with more bit might also be able to
+trigger this. Fix that by explicitly checking for data->inbuf to be
+available before using it.
+
+Signed-off-by: Jouni Malinen
+---
+ src/eap_server/eap_server_pwd.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/src/eap_server/eap_server_pwd.c b/src/eap_server/eap_server_pwd.c
+index 11bef55..38e2af8 100644
+--- a/src/eap_server/eap_server_pwd.c
b/src/eap_server/eap_server_pwd.c
+@@ -912,6 +912,12 @@ static void eap_pwd_process(struct eap_sm *sm, void *priv,
+* the first and all intermediate fragments have the M bit set
+*/
+ if (EAP_PWD_GET_MORE_BIT(lm_exch) || data->in_frag_pos) {
++ if (!data->inbuf) {
++ wpa_printf(MSG_DEBUG,
++ "EAP-pwd: No buffer for reassembly");
++ eap_pwd_state(data, FAILURE);
++ return;
++ }
+ if ((data->in_frag_pos + len) > wpabuf_size(data->inbuf)) {
+ wpa_printf(MSG_DEBUG, "EAP-pwd: Buffer overflow "
+ "attack detected! (%d+%d > %d)",
+@@ -932,7 +938,7 @@ static void eap_pwd_process(struct eap_sm *sm, void *priv,
+* last fragment won't have the M bit set (but we're obviously
+* buffering fragments so that's how we know it's the last)
+*/
+- if (data->in_frag_pos) {
++ if (data->in_frag_pos && data->inbuf) {
+ pos = wpabuf_head_u8(data->inbuf);
+ len = data->in_frag_pos;
+ wpa_printf(MSG_DEBUG, "EAP-pwd: Last fragment, %d bytes",
+--
+2.7.4
+
diff -Nru
wpa-2.7+git20190128+0c1e29f/debian/patches/2019-5/0003-EAP-pwd-peer-Fix-reassembly-buffer-handling.patch
wpa-2.7+git20190128+0c1e29f/debian/patches/2019-5/0003-EAP-pwd-peer-Fix-reassembly-buffer-handling.patch
---
wpa-2.7+git20190128+0c1e29f/debian/patches/2019-5/0003-EAP-pwd-peer-Fix-reassembly-buffer-handling.patch
1970-01-01 01:00:00.0 +0100
+++
wpa-2.7+git20190128+0c1e29f/debian/patches/2019-5/0003-EAP-pwd-peer-Fix-reassembly-buffer-handling.patch
2019-04-26 14:55:52.0 +0200
@@ -0,0 +1,45 @@
+From d2d1a324ce937628e4d9dfe113819b7d4478 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen
+Date: Wed, 17 Apr 2019 02:21:20 +0300
+Subject: [PATCH 3/3] EAP-pwd peer: Fix reassembly buffer handling
+
+Unexpected fragment might result in data->inbuf not being allocated
+before processing and that could have resulted in NULL pointer
+dereference. Fix that by explicitly checking for data->inbuf to be
+available before using it.
+
+Signed-off-by: Jouni Malinen
+---
+ src/eap_peer/eap_pwd.c | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/src/eap_peer/eap_pwd.c b/src/eap_peer/eap_pwd.c
+index 46894a5..76fcad4 100644
+--- a/src/eap_peer/eap_pwd.c
b/src/eap_peer/eap_pwd.c
+@@ -932,6 +932,13 @@ eap_pwd_process(struct eap_sm *sm, void *priv, struct
eap_method_ret *ret,
+* buffer and ACK the fragment
+*/
+ if (EAP_PWD_GET_MORE_BIT(lm_exch) || data->in_frag_pos) {
++ if (!data->inbuf) {
++ wpa_printf(MSG_DEBUG,
++ "EAP-pwd: No buffer for reassembly");
++
Bug#928310: unblock: wpa/2:2.7+git20190128+0c1e29f-5
Control: tags -1 d-i moreinfo confirmed
On 01-05-2019 22:08, Salvatore Bonaccorso wrote:
> Please unblock package wpa. The followup update to unstable for wpa
> 2:2.7+git20190128+0c1e29f-5 fixes one additional security issue
> ("EAP-pwd message reassembly issue with unexpected fragment"). It got
> CVE-2019-11555 later assigned.
This needs an ACK from d-i, but otherwise I'd unblock it.
Paul
signature.asc
Description: OpenPGP digital signature
Bug#928310: unblock: wpa/2:2.7+git20190128+0c1e29f-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi release team,
[Not the maintainer here]
Please unblock package wpa. The followup update to unstable for wpa
2:2.7+git20190128+0c1e29f-5 fixes one additional security issue
("EAP-pwd message reassembly issue with unexpected fragment"). It got
CVE-2019-11555 later assigned.
+wpa (2:2.7+git20190128+0c1e29f-5) unstable; urgency=high
+
+ * Fix security issue 2019-5:
+- EAP-pwd message reassembly issue with unexpected fragment
+ (Closes: #927463, no CVE assigned).
+
+ -- Andrej Shadura Fri, 26 Apr 2019 14:55:52 +0200
Attached is the debdiff, and mantianer and Cyril Brulebois Cc'ed for a d-i ack.
unblock wpa/2:2.7+git20190128+0c1e29f-5
Regards,
Salvatore
Bug#928309: ITP: android-file-transfer -- reliable MTP client with minimalistic UI
Package: wnpp Owner: Dylan Aïssi Severity: wishlist Package name: android-file-transfer Upstream Author : Vladimir Menshakov URL: https://github.com/whoozle/android-file-transfer-linux License: LGPL-2.1+ Description: reliable MTP client with minimalistic UI Android-File-Transfer is a reliable MTP client with minimalistic UI. Its features are: 1. Simple Qt UI with progress dialogs. 2. FUSE wrapper, supporting partial read/writes, allowing instant access to your files. 3. No file size limits. 4. Automatically renames album cover to make it visible from media player. 5. USB ‘Zerocopy’ support found in recent Linux kernel (no user/kernel data copying). 6. No extra dependencies (e.g. libptp/libmtp). 7. Available as static/shared library. 8. Command line tool (aft-mtp-cli).
Bug#928295: unblock: pythonmagick/0.9.19-3
Control: tag -1 - moreinfo * Paul Gevers [2019-05-01 15:29]: pythonmagick was patched to compile with ImageMagick 7 in 0.9.19-1 whereas buster is still on 6. This resulted the package failing to import, see #928103 (missed to close this in the changelog). I disabled the autopkgtest as it was failing because autopep8 doesn't support module names different to packages names. How about generating a superficial test that does the same as autodep8 (I like your typo) but with the right module name for now? The rest looks good to me. There was one already, but it failed as well. I uploaded a fixed version in -4. Diff against the version in buster attached. diff --git a/debian/changelog b/debian/changelog index 9a93a17..348c161 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,18 @@ +pythonmagick (0.9.19-4) unstable; urgency=medium + + * Team upload. + * Fix autopkgtests + + -- Jochen Sprickerhof Wed, 01 May 2019 20:33:19 +0200 + +pythonmagick (0.9.19-3) unstable; urgency=medium + + * Team upload. + * Disable failing autopkgtest + * Add patch for ImageMagick < 7 + + -- Jochen Sprickerhof Wed, 01 May 2019 14:45:43 +0200 + pythonmagick (0.9.19-2) unstable; urgency=medium * Fix debci diff --git a/debian/patches/0002-Partly-revert-f4772d8-for-ImageMagick-7.patch b/debian/patches/0002-Partly-revert-f4772d8-for-ImageMagick-7.patch new file mode 100644 index 000..25d9e84 --- /dev/null +++ b/debian/patches/0002-Partly-revert-f4772d8-for-ImageMagick-7.patch @@ -0,0 +1,110 @@ +From 0c0e1e9a038d7e9f79f567714ab5054c9345 Mon Sep 17 00:00:00 2001 +From: Jochen Sprickerhof +Date: Wed, 1 May 2019 12:28:12 +0200 +Subject: [PATCH] Partly revert f4772d8 for ImageMagick < 7 + +--- + PythonMagick/__init__.py | 8 + pythonmagick_src/_main.cpp | 16 + 2 files changed, 12 insertions(+), 12 deletions(-) + +diff --git a/PythonMagick/__init__.py b/PythonMagick/__init__.py +index 61ba8d4..6750c2e 100644 +--- a/PythonMagick/__init__.py b/PythonMagick/__init__.py +@@ -51,10 +51,10 @@ class DrawableColor(_PythonMagick.DrawableColor): + class DrawableCompositeImage(_PythonMagick.DrawableCompositeImage): +pass + +-class DrawableStrokeDashArray(_PythonMagick.DrawableStrokeDashArray): ++class DrawableDashArray(_PythonMagick.DrawableDashArray): +pass + +-class DrawableStrokeDashOffset(_PythonMagick.DrawableStrokeDashOffset): ++class DrawableDashOffset(_PythonMagick.DrawableDashOffset): +pass + + class DrawableEllipse(_PythonMagick.DrawableEllipse): +@@ -78,7 +78,7 @@ class DrawableGravity(_PythonMagick.DrawableGravity): + class DrawableLine(_PythonMagick.DrawableLine): +pass + +-class DrawableAlpha(_PythonMagick.DrawableAlpha): ++class DrawableMatte(_PythonMagick.DrawableMatte): +pass + + class DrawableMiterLimit(_PythonMagick.DrawableMiterLimit): +@@ -174,7 +174,7 @@ class DrawableViewbox(_PythonMagick.DrawableViewbox): + class Exception(_PythonMagick.Exception): +pass + +-class FilterType(_PythonMagick.FilterType): ++class FilterTypes(_PythonMagick.FilterTypes): +pass + + class Geometry(_PythonMagick.Geometry): +diff --git a/pythonmagick_src/_main.cpp b/pythonmagick_src/_main.cpp +index a7d3cce..449f0b1 100644 +--- a/pythonmagick_src/_main.cpp b/pythonmagick_src/_main.cpp +@@ -30,7 +30,7 @@ void Export_pyste_src_PathArcAbs(); + void Export_pyste_src_Image(); + void Export_pyste_src_GravityType(); + void Export_pyste_src_Geometry(); +-void Export_pyste_src_FilterType(); ++void Export_pyste_src_FilterTypes(); + void Export_pyste_src_Exception(); + void Export_pyste_src_DrawableViewbox(); + void Export_pyste_src_DrawableTranslation(); +@@ -62,7 +62,7 @@ void Export_pyste_src_DrawablePointSize(); + void Export_pyste_src_DrawablePoint(); + void Export_pyste_src_DrawablePath(); + void Export_pyste_src_DrawableMiterLimit(); +-void Export_pyste_src_DrawableAlpha(); ++void Export_pyste_src_DrawableMatte(); + void Export_pyste_src_DrawableLine(); + void Export_pyste_src_DrawableGravity(); + void Export_pyste_src_DrawableFont(); +@@ -70,8 +70,8 @@ void Export_pyste_src_DrawableFillRule(); + void Export_pyste_src_DrawableFillOpacity(); + void Export_pyste_src_DrawableFillColor(); + void Export_pyste_src_DrawableEllipse(); +-void Export_pyste_src_DrawableStrokeDashOffset(); +-void Export_pyste_src_DrawableStrokeDashArray(); ++void Export_pyste_src_DrawableDashOffset(); ++void Export_pyste_src_DrawableDashArray(); + void Export_pyste_src_DrawableCompositeImage(); + void Export_pyste_src_DrawableColor(); + void Export_pyste_src_DrawableClipPath(); +@@ -119,7 +119,7 @@ BOOST_PYTHON_MODULE(_PythonMagick) + Export_pyste_src_Image(); + Export_pyste_src_GravityType(); + Export_pyste_src_Geometry(); +-Export_pyste_src_FilterType(); ++Export_pyste_src_FilterTypes(); + Export_pyste_src_Exception(); + Export_pyste_src_DrawableViewbox(); + Export_pyste_src_DrawableTranslation(); +@@ -151,7 +151,7 @@
Bug#926547: insserv: tests/run-tests are not used
On 5/1/19 7:42 AM, Dmitry Bogatov wrote: > [2019-04-28 21:05] Jesse Smith >> I have been looking into the issues with the insserv test scripts. There >> are a few problems here, in brief: >> [...] >> >> In other words, I think there is some difference in expectations between >> what I think insserv should be doing and what the scripts we inherited >> from downstream think insserv should be doing. I'm interested in getting >> some feedback on this. If a script has no LSB header, should it be given >> preset defaults, or should it be ignored? If the latter, I think we can >> remove this series of tests. Which will mean there are just two errors >> left for me to sort out. > In my opinion, insserv should print warning about missing LSB headers > and ignore them. I agree, which is good, that is what insserv currently does during the test. I'll mark this test as "passed".
Bug#928254: gcc-8: -static-libasan does not work with GNU MPFR
On 30.04.19 19:05, Vincent Lefevre wrote: > Package: gcc-8 > Version: 8.3.0-7 > Severity: minor > > When I build and check GNU MPFR with: > > ./configure CFLAGS="-fsanitize=address -static-libasan" > make > make check > > I get lots of failure with the error: > > Your application is linked against incompatible ASan runtimes. > > Though -static-libasan has been used, there is still a dynamic libasan, > as shown by ldd on a test program: > > libasan.so.5 => /usr/lib/x86_64-linux-gnu/libasan.so.5 > (0x7fdcf052d000) > > This may be the cause of the issue. > > If there is a limitation (due to the use of other shared libraries?), > this should be mentioned in the gcc man page and manual. the linker never sees your CFLAGS. At least -static-libasan needs to be added to LDFLAGS.
Bug#928308: integrit segfault at 804e48c ip 0804e48c sp bfe178dc error 14
Package: integrit Version: 4.1-1.1+b1 Severity: normal Dear Maintainer, I've had integrit crash several times with a segmentation fault: $ integrit -C /etc/integrit/integrit.conf -cu Segmentation fault dmesg has: integrit[17557]: segfault at 804e48c ip 0804e48c sp bfb32fbc error 14 Unfortunately, this seems to be tricky to reproduce reliably. It was crashing repeatedly each time I ran the command above. When I ran integrit under gdb, the crash didn't happen. When I apt-get installed valgrind to investigate further, the segfault stopped happening altogether (with no changes to integrit.conf or known.cdb or anything else as far as I can see). Sadly I don't have a coredump. (gdb) x/10i 0x804e48c 0x804e48c <__unified_syscall+33>:pop%ebp 0x804e48d <__unified_syscall+34>:pop%ebx 0x804e48e <__unified_syscall+35>:pop%esi 0x804e48f <__unified_syscall+36>:pop%edi 0x804e490 <__unified_syscall+37>:cmp$0xff7c,%eax 0x804e495 <__unified_syscall+42>:jb 0x804e4a4 <__unified_syscall+57> 0x804e497 <__unified_syscall+44>:neg%eax 0x804e499 <__unified_syscall+46>:push %eax 0x804e49a <__unified_syscall+47>:call 0x804eaa0 <__errno_location> 0x804e49f <__unified_syscall+52>:popl (%eax) Valgrind finds a valid problem with an uninitialized pointer being passed to munmap (munmap call is at cdb.c:56, problematic curr_cdb defined at missing.c:136 and then passed uninitialized to open_current_state_cdb). However this problem appears to be too late in the program to cause the segfault I'm seeing. Segfault seems to happen before config file is done parsing since nothing is yet printed to the terminal. I know this is likely not enough information to debug this. I'm reporting it here just in case someone else has a similar problem and has more relevant info. Thanks, Tomaž -- System Information: Debian Release: 9.9 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-9-686-pae (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) integrit depends on no packages. Versions of packages integrit recommends: ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4 ii cron 3.0pl1-128+deb9u1 integrit suggests no packages.
Bug#927329: Update Arduino from 1.8.2 to 1.8.9
On Wed, May 01, 2019 at 01:07:39PM -0500, Kashif Shah wrote: > @Rock Thanks for the update. My earlier attempt was with packaging the > binaries, which is a no-no, I take it? Absolutely, whatever is distributed must be built from source. I tried to reason why on this bug [1]. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922965#12 > I made an attempt from scratch last > night, actually, after looking at the previous patches. I’ll continue with > it, but it will be slow going as I am not a Java dev by trade. I'm also no Java expert either, any help is welcome :) Cheers, -- Rock Storm GPG KeyID: 4096R/C96832FD GPG Fingerprint: C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD
Bug#928307: wide-dhcpv6-client: default route not set
Package: wide-dhcpv6-client Version: 20080615-19 Severity: normal Tags: ipv6 Dear Maintainer, currently, my wide-dhcpv6-client successfully gets one ipv6 address and two delegation prefixes from my upstream isp, but it does not set a default route to the next hop, rendering ipv6 to and from the outside non-working. Adding the route manually by running ip route add default via fe80::201:5cff:feb1:ade4 dev eth0 fixes it. The address comes from the log (I ran /usr/sbin/dhcp6c once manually with -d -D -f): --- log begin --- ... May/01/2019 20:09:52: client6_send: send solicit to ff02::1:2%eth0 May/01/2019 20:09:52: dhcp6_reset_timer: reset a timer on eth0, state=SOLICIT, timeo=0, retrans=1093 May/01/2019 20:09:52: client6_recv: receive advertise from fe80::201:5cff:feb1:ade4%eth0 on eth0 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option client ID, len 14 May/01/2019 20:09:52: DUID: 00:01:00:01:20:3e:b1:3a:00:0d:b9:20:42:30 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option server ID, len 14 May/01/2019 20:09:52: DUID: 00:01:00:01:1b:18:de:65:00:18:51:a6:21:ea May/01/2019 20:09:52: dhcp6_get_options: get DHCP option identity association, len 40 May/01/2019 20:09:52: IA_NA: ID=0, T1=302345, T2=483752 May/01/2019 20:09:52: copyin_option: get DHCP option IA address, len 24 May/01/2019 20:09:52: copyin_option: IA_NA address: 2a02:2450:15:9000:a9b9:1a09:ab1e:1f44 pltime=604691 vltime=1209491 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option IA_PD, len 41 May/01/2019 20:09:52: IA_PD: ID=0, T1=302345, T2=483752 May/01/2019 20:09:52: copyin_option: get DHCP option IA_PD prefix, len 25 May/01/2019 20:09:52: copyin_option: IA_PD prefix: 2a02:2450:1159:157::/64 pltime=604691 vltime=1209491 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option IA_PD, len 41 May/01/2019 20:09:52: IA_PD: ID=1, T1=302345, T2=483752 May/01/2019 20:09:52: copyin_option: get DHCP option IA_PD prefix, len 25 May/01/2019 20:09:52: copyin_option: IA_PD prefix: 2a02:2450:1159:539::/64 pltime=604691 vltime=1209491 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option preference, len 1 May/01/2019 20:09:52: preference: 255 May/01/2019 20:09:52: client6_recvadvert: server ID: 00:01:00:01:1b:18:de:65:00:18:51:a6:21:ea, pref=255 May/01/2019 20:09:52: client6_recvadvert: unexpected advertise May/01/2019 20:09:52: client6_send: a new XID (db56d0) is generated May/01/2019 20:09:52: copy_option: set client ID (len 14) May/01/2019 20:09:52: copy_option: set server ID (len 14) May/01/2019 20:09:52: copyout_option: set IA address May/01/2019 20:09:52: copyout_option: set identity association May/01/2019 20:09:52: copy_option: set elapsed time (len 2) May/01/2019 20:09:52: copyout_option: set IA_PD prefix May/01/2019 20:09:52: copyout_option: set IA_PD May/01/2019 20:09:52: copyout_option: set IA_PD prefix May/01/2019 20:09:52: copyout_option: set IA_PD May/01/2019 20:09:52: client6_send: send request to ff02::1:2%eth0 May/01/2019 20:09:52: dhcp6_reset_timer: reset a timer on eth0, state=REQUEST, timeo=0, retrans=949 May/01/2019 20:09:52: client6_recv: receive advertise from fe80::201:5cff:feb1:ade4%eth0 on eth0 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option client ID, len 14 May/01/2019 20:09:52: DUID: 00:01:00:01:20:3e:b1:3a:00:0d:b9:20:42:30 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option server ID, len 14 May/01/2019 20:09:52: DUID: 00:01:00:01:19:43:39:5f:00:18:51:33:a0:4d May/01/2019 20:09:52: dhcp6_get_options: get DHCP option identity association, len 40 May/01/2019 20:09:52: IA_NA: ID=0, T1=302400, T2=483840 May/01/2019 20:09:52: copyin_option: get DHCP option IA address, len 24 May/01/2019 20:09:52: copyin_option: IA_NA address: 2a02:2450:15:9800:c13e:5c92:248e:3994 pltime=604800 vltime=1209600 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option IA_PD, len 41 May/01/2019 20:09:52: IA_PD: ID=0, T1=302400, T2=483840 May/01/2019 20:09:52: copyin_option: get DHCP option IA_PD prefix, len 25 May/01/2019 20:09:52: copyin_option: IA_PD prefix: 2a02:2450:1159:805d::/64 pltime=604800 vltime=1209600 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option IA_PD, len 41 May/01/2019 20:09:52: IA_PD: ID=1, T1=302400, T2=483840 May/01/2019 20:09:52: copyin_option: get DHCP option IA_PD prefix, len 25 May/01/2019 20:09:52: copyin_option: IA_PD prefix: 2a02:2450:1159:80c8::/64 pltime=604800 vltime=1209600 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option preference, len 1 May/01/2019 20:09:52: preference: 127 May/01/2019 20:09:52: client6_recvadvert: XID mismatch May/01/2019 20:09:52: client6_recv: receive reply from fe80::201:5cff:feb1:ade4%eth0 on eth0 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option client ID, len 14 May/01/2019 20:09:52: DUID: 00:01:00:01:20:3e:b1:3a:00:0d:b9:20:42:30 May/01/2019 20:09:52: dhcp6_get_options: get DHCP option server ID, len 14 May/01/2019 20:09:52: DUID: 00:01:00:01:1b:18:de:65:00:18:51:a6:21:ea
Bug#928103: closing 928103
Hi eamanu, * eamanu [2019-05-01 14:03]: The package is still fail on testing: Should be fixed in -4, thanks for the ping. Cheers Jochen signature.asc Description: PGP signature
Bug#642401: [xmonad] lockup when starting gvim in terminal
Hi, I can't reproduce the bug in next stable release. I've also tested installing 1:7.1.314-3+lenny2 version on a debootstrap. More details on how to reproduce the "confirmed" bug would be great. Probably Squeeze fixed the bug. I've also tested 7.2 (Squeeze) and 7.4 (Jessie) versions without problems. Thanks, -- Antoni Villalonga http://friki.cat/
Bug#927329: Update Arduino from 1.8.2 to 1.8.9
@Rock Thanks for the update. My earlier attempt was with packaging the binaries, which is a no-no, I take it? I made an attempt from scratch last night, actually, after looking at the previous patches. I’ll continue with it, but it will be slow going as I am not a Java dev by trade. On Wed, May 1, 2019 at 12:03 PM Rock Storm wrote: > Hi all, > > @Kashif, thanks for volunteering, please let us know if you succeed on > packaging it from scratch. IIRC on our last attempt we got stuck > packaging some of the java dependencies such as 'mrbean', some info on > this bug report [1]. Project is now hosted on Salsa [2]. > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780706#63 > [2]: https://salsa.debian.org/electronics-team/arduino/arduino > > @Brian, thank you for insisting on this topic. We probably need someone > to push us a little bit to get this done. I sincerely believe Arduino > being in Debian is a must. As I said, I'll work on it as soon as I can. > > Regards, > > -- > Rock Storm > GPG KeyID: 4096R/C96832FD > GPG Fingerprint: > C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD >
Bug#914999: [libc6] Locking problems into libc6
12.12.18 17:11, Roman Savochenko wrote: There are thousands of packages in different versions between Debian 8 and Debian 9. You have found it's not related to the kernel, but I fail to see how that shows it's a libc6 issue. For example when you have tried the kernel from Debian 9 in Debian 8, have you also tried with the rtl8192 firmware from Debian 9? I will compare the firmware, thanks. I have installed of equal package firmware-realtek 20161130-4 on Debian 9 and this problem is actual yet. So, I have found a way of fixing this problem: https://github.com/Mange/rtl8192eu-linux-driver/issues/46 sudo nano /etc/NetworkManager/NetworkManager.conf and add below 2 lines: [device] wifi.scan-rand-mac-address=no Regards, Roman
Bug#928306: unblock: liblivemedia/2018.11.26-1.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package liblivemedia
Dear Release team,
liblivemedia 2018.11.26-1 from Buster is affected by CVE-2019-9215[1] and
CVE-2019-7314[2], two security issues in the server part of the library.
The impact is at least DoS, which is trivial to manage using a publicly
available script. In fact theses issues might allow any script kiddie to
make any live555 server fully unusable.
These issues have been fixed in oldstable and stable. Not fixing them in
Buster would be a security regression.
Sebastian Ramacher (Debian maintainer) did not want to take time for this
NMU, but did not oppose either[3]. He meant that these CVEs are only
affecting the server part of the library, which is not used by reverse
dependencies.
debdiff with targeted fixes in attachment.
[0] https://security-tracker.debian.org/tracker/CVE-2019-9215
[1] https://security-tracker.debian.org/tracker/CVE-2019-7314
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924655
unblock liblivemedia/2018.11.26-1.1
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
diff -Nru liblivemedia-2018.11.26/debian/changelog liblivemedia-2018.11.26/debian/changelog
--- liblivemedia-2018.11.26/debian/changelog 2018-11-28 21:08:09.0 +0100
+++ liblivemedia-2018.11.26/debian/changelog 2019-05-01 17:56:46.0 +0200
@@ -1,3 +1,12 @@
+liblivemedia (2018.11.26-1.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * CVE-2019-7314: use-after-free during RTSP stream termination.
+ * CVE-2019-9215: malformed headers lead to invalid memory access
+in the parseAuthorizationHeader function.
+
+ -- Hugo Lefeuvre Wed, 01 May 2019 17:54:20 +0100
+
liblivemedia (2018.11.26-1) unstable; urgency=medium
* New upstream release.
diff -Nru liblivemedia-2018.11.26/debian/patches/CVE-2019-7314.patch liblivemedia-2018.11.26/debian/patches/CVE-2019-7314.patch
--- liblivemedia-2018.11.26/debian/patches/CVE-2019-7314.patch 1970-01-01 01:00:00.0 +0100
+++ liblivemedia-2018.11.26/debian/patches/CVE-2019-7314.patch 2019-05-01 17:52:25.0 +0200
@@ -0,0 +1,17 @@
+Description: fix use-after-free in the RTSP server implementation
+ Whenever a stream ends (via StreamState::endPlaying), the stream socket
+ is removed but the request alternative byte handler of this same stream
+ socket is not updated to reflect the stream deletion. Remote attackers
+ might leverage this vulnerability to trigger a use-after-free and
+ subsequent server crash.
+Origin: upstream
+--- a/liveMedia/OnDemandServerMediaSubsession.cpp 2016-11-28 22:42:18.0 +0100
b/liveMedia/OnDemandServerMediaSubsession.cpp 2019-03-12 16:37:46.040247175 +0100
+@@ -582,6 +582,7 @@
+
+ if (dests->isTCP) {
+ if (fRTPSink != NULL) {
++ RTPInterface::clearServerRequestAlternativeByteHandler(fRTPSink->envir(), dests->tcpSocketNum);
+ fRTPSink->removeStreamSocket(dests->tcpSocketNum, dests->rtpChannelId);
+ }
+ if (fRTCPInstance != NULL) {
diff -Nru liblivemedia-2018.11.26/debian/patches/CVE-2019-9215.patch liblivemedia-2018.11.26/debian/patches/CVE-2019-9215.patch
--- liblivemedia-2018.11.26/debian/patches/CVE-2019-9215.patch 1970-01-01 01:00:00.0 +0100
+++ liblivemedia-2018.11.26/debian/patches/CVE-2019-9215.patch 2019-05-01 17:52:25.0 +0200
@@ -0,0 +1,80 @@
+Description: fix invalid memory access in parseAuthorizationHeader
+ sscanf(fields, "%[^=]=\"\"", parameter) returns 1 even if the entry is
+ incorrectly formatted (e.g. fields = "p="), leading to excessive
+ incrementation of fields pointer later:
+ fields += strlen(parameter) + 2 /*="*/ + strlen(value) + 1 /*"*/;
+ .
+ This might allow attackers to perform invalid memory accesses.
+ .
+ This patch implements manual parsing of the keywords, allowing for better
+ error resilience.
+ .
+ Patch source: diff v2019.02.03 -> v2019.02.27
+Origin: upstream
+--- a/liveMedia/RTSPServer.cpp 2019-03-12 18:36:07.618027268 +0100
b/liveMedia/RTSPServer.cpp 2019-03-12 18:36:07.614027288 +0100
+@@ -894,6 +894,8 @@
+ }
+ }
+
++#define SKIP_WHITESPACE while (*fields != '\0' && (*fields == ' ' || *fields == '\t')) ++fields
++
+ static Boolean parseAuthorizationHeader(char const* buf,
+ char const*& username,
+ char const*& realm,
+@@ -911,15 +913,28 @@
+
+ // Then, run through each of the fields, looking for ones we handle:
+ char const* fields = buf + 22;
+- while (*fields == ' ') ++fields;
+ char* parameter = strDupSize(fields);
+ char* value = strDupSize(fields);
+- while (1) {
+-value[0] = '\0';
+-if (sscanf(fields, "%[^=]=\"%[^\"]\"", parameter, value) != 2 &&
+- sscanf(fields, "%[^=]=\"\"", parameter) != 1) {
+- break;
+-}
++ char* p;
++ Boolean success;
++ do {
++// Parse: =""
++success =
Bug#927329: Update Arduino from 1.8.2 to 1.8.9
Hi all, @Kashif, thanks for volunteering, please let us know if you succeed on packaging it from scratch. IIRC on our last attempt we got stuck packaging some of the java dependencies such as 'mrbean', some info on this bug report [1]. Project is now hosted on Salsa [2]. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780706#63 [2]: https://salsa.debian.org/electronics-team/arduino/arduino @Brian, thank you for insisting on this topic. We probably need someone to push us a little bit to get this done. I sincerely believe Arduino being in Debian is a must. As I said, I'll work on it as soon as I can. Regards, -- Rock Storm GPG KeyID: 4096R/C96832FD GPG Fingerprint: C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD
Bug#922097: inkscape stops with message complaining about an internal illegal instruction on start
Hello André Isidoro Fernandes Esteves, > I have installed inkscape/experimental,now 1.0~alpha-1 amd64 with no > problems whatsoever. > So now i can't test the bug. Sorry :( Glad to hear it is working. Just to clarify: I guess that on your system the file "/usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1.1.0" got corrupted and may now be working as it got replaced by updating. In this picture would fit that the "arrow_type" is just one bit different to "arbow_type" (from the warning message you received just before the crash). This might point to a problem with your harddisk or memory? I guess this bug can then be closed? Kind regards, Bernhard
Bug#928297: xserver-xorg-core: transitively depends on libgl1-mesa-dri
Control: retitle -1 xserver-xorg-core: transitively depends on libgl1-mesa-dri On Wed, 01 May 2019 at 15:42:23 +0200, Jonas Smedegaard wrote: > Quoting Jonas Smedegaard (2019-05-01 15:25:16) > > xserver-xorg-core 2:1.19.3-2 has Depends: libgl1-mesa-glx | libgl > > > > xserver-xorg-core 2:1.19.4-1 has Depends: libgl (The former is correct, but the latter should say libgl1, not libgl) I don't think this is a bug. libgl1-mesa-glx was an implementation of the abstract libgl interface. Xorg now depends on libgl1, which is a vendor-neutral dispatcher that loads one of several backends, including Mesa's: because it's vendor-neutral, there is no longer any need for alternatives. libgl1-mesa-glx is now a transitional package which pulls in libgl1 and libglx-mesa0, and (indirectly) libgl1-mesa-dri, so adding it as an alternative would not help to make libgl1-mesa-dri more optional. > Seems the change coincide with the introduction of src:libglvnd. libgl1-mesa-glx | libgl dependencies being replaced by libgl1 is part of the GLVND transition, but would not necessarily cause the symptom of a transitive dependency on libgl1-mesa-dri. I think that might actually be caused by: mesa (17.2.0~rc6-1) experimental; urgency=medium ... * control: Bump libgl1-mesa-dri to libglx-mesa0 Depends, it's needed for swrast used on some tests. If I'm correct about that, then this bug should perhaps be reassigned to libglx-mesa0. Perhaps it should be those tests that explicitly pull in libgl1-mesa-dri? (Although I do question how useful libglx-mesa0 can possibly be without the DRI drivers that make it work.) smcv
Bug#928224: Valgrind is broken on armhf
Hello Benjamin Wozniak, I just wanted to help triaging this issue. For this I started a qemu vexpress-a15 emulation with current Buster armhf installed. Unfortunately I could not reproduce this valgrind error. Some more details about my test in attached file. So maybe the valgrind maintainer will need some more information about the system showing this behaviour. Kind regards, Bernhard # Buster armhf qemu VM 2019-05-01 apt update apt dist-upgrade apt install valgrind valgrind /bin/true root@debian:~# valgrind /bin/true ==632== Memcheck, a memory error detector ==632== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==632== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==632== Command: /bin/true ==632== ==632== ==632== HEAP SUMMARY: ==632== in use at exit: 0 bytes in 0 blocks ==632== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==632== ==632== All heap blocks were freed -- no leaks are possible ==632== ==632== For counts of detected and suppressed errors, rerun with: -v ==632== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) root@debian:~# dpkg -l | grep -E "2.28-8|1:3.14.0-3" ii libc-bin2.28-8 armhf GNU C Library: Binaries ii libc-l10n 2.28-8 all GNU C Library: localization files ii libc6:armhf 2.28-8 armhf GNU C Library: Shared libraries ii libc6-dbg:armhf 2.28-8 armhf GNU C Library: detached debugging symbols ii locales 2.28-8 all GNU C Library: National Language (locale) data [support] ii valgrind1:3.14.0-3 armhf instrumentation framework for building dynamic analysis tools ii valgrind-dbg1:3.14.0-3 armhf instrumentation framework for building dynamic analysis tools (debug) root@debian:~# dpkg -S ld-linux-armhf.so.3 libc6:armhf: /lib/ld-linux-armhf.so.3 libc6:armhf: /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 root@debian:~# uname -a Linux debian 4.19.0-4-armmp-lpae #1 SMP Debian 4.19.28-2 (2019-03-15) armv7l GNU/Linux root@debian:~# lscpu Architecture:armv7l Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 Vendor ID: ARM Model: 1 Model name: Cortex-A15 Stepping:r2p1 BogoMIPS:125.00 Flags: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm /usr/bin/qemu-system-arm -m 2G -M vexpress-a15 -smp 4 -monitor stdio -sd system.img -nic user,model=lan9118,hostfwd=tcp:127.0.254.60:-:22,hostfwd=tcp:127.0.254.60:3389-:3389,hostfwd=tcp:127.0.254.60:4445-:445,hostfwd=tcp:127.0.254.60:8080-:80,hostfwd=tcp:127.0.254.60:5901-:5901,tftp=/home/bernhard/data/pxeboot,bootfile=/boot/grub/i386-pc/core.0 -kernel boot/vmlinuz-4.19.0-4-armmp-lpae -initrd boot/initrd.img-4.19.0-4-armmp-lpae -dtb vexpress-v2p-ca15-tc1.dtb -append root=/dev/mmcblk0p2 -boot c -no-shutdown -snapshot
Bug#928305: mhc: lack of Japan's new era 令和 (Reiwa) and new holidays
Control: forwarded -1 https://github.com/yoshinari-nomura/mhc/pull/49 Control: forwarded -1 https://github.com/yoshinari-nomura/mhc/pull/50 Thanks, -- Tatsuya Kinoshita
Bug#928305: mhc: lack of Japan's new era 令和 (Reiwa) and new holidays
Package: mhc Version: 1.2.1-1 Severity: important Please support Japan's new era 令和 (Reiwa) and new holidays. Japan's new era 令和 (Reiwa) started on 2019/5/1. However this package doesn't support it in the function mhc-calendar/inserter-nengo(). Also, new holidays, such as emperor's birthday (23 Feb), should be added to japanese-holidays.mhcc. Thanks, -- Tatsuya Kinoshita
Bug#928115: zdbsp FTCBFS: confuses build vs. host
Thanks for the report, and the patch. It looks good to me, but as we are in hard freeze for Buster and this (sadly) would not qualify for a freeze exception, I'm going to wait before applying it or uploading a fixed package to sid. Best wishes
Bug#927270: proftpd-basic: jessie-security (1.3.5e) breaks directive with AuthAliasOnly
Control: tags -1 confirmed Thanks for the report. I can confirm this issue is still present in 1.3.6-4. I have reverted to version 1.3.5 in Jessie again, so this problem should not occur in Jessie anymore. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#928304: groonga-httpd: Privilege escalation due to insecure use of logrotate
Package: groonga-httpd
Version: 6.1.5-1
Severity: critical
Tags: security
Justification: root security hole
Dear Maintainer,
The path of the logdirectory of groonga-httpd can be manipulated by user
groonga:
ls -l /var/log/groonga
total 8
-rw-r--r-- 1 rootroot1296 Apr 25 18:44 groonga.log
drwxr-xr-x 2 groonga groonga 4096 Apr 25 18:55 httpd
The files in /var/log/groonga/httpd/*.log are once a day rotated by
logrotate as user root with the following config:
/var/log/groonga/httpd/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 640 groonga groonga
sharedscripts
postrotate
. /etc/default/groonga-httpd
if [ x"$ENABLE" = x"yes" ]; then
/usr/bin/curl --silent --output /dev/null \
"http://127.0.0.1:10041/d/log_reopen;
fi
endscript
}
Due to logrotate is prone to a race-condition(see the link to my
blog below) it is possible for user "groonga" to replace the
directory /var/log/groonga/httpd with a symbolik link to any
directory(for example /etc/bash_completion.d). logrotate will place
files AS ROOT into /etc/bash_completition.d and set the owner and
group to "groonga.groonga". An attacker could simply place a
reverse-shell into this file. As soon as root logs in, a reverse
shell will be executed then.
You can find an exploit for this bug at my blog:
https://tech.feedyourhead.at/content/abusing-a-race-condition-in-logrotate-to-elevate-privileges
(This exploit won't work well with lvm or docker but works reliable
if the filesystem is directly on the disk)
Mitigation:
You could mitigate the problem by changing the owner and group of
/var/log/groonga to root, or by using the "su option" inside the
logrotate-configfile.
-- System Information:
Debian Release: 9.9
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages groonga-httpd depends on:
ii curl 7.52.1-5+deb9u9
ii groonga-server-common 6.1.5-1
ii init-system-helpers1.48
ii libc6 2.24-11+deb9u4
ii libgroonga06.1.5-1
ii libpcre3 2:8.39-3
ii libssl1.1 1.1.0j-1~deb9u1
ii lsb-base 9.20161125
ii zlib1g 1:1.2.8.dfsg-5
groonga-httpd recommends no packages.
groonga-httpd suggests no packages.
-- no debconf information
Bug#922097: Fwd: Bug#922097: inkscape stops with message complaining about an internal illegal instruction on start
Looping in BTS again. Weitergeleitete Nachricht Betreff: Re: Bug#922097: inkscape stops with message complaining about an internal illegal instruction on start Datum: Wed, 1 May 2019 16:14:36 +0100 Von: André Esteves An: Bernhard Übelacker I have installed inkscape/experimental,now 1.0~alpha-1 amd64 with no problems whatsoever. So now i can't test the bug. Sorry :( Thk y, Andre Esteves
Bug#928303: ITP: lightdm-settings -- LightDM Settings Configuration Tool
Package: wnpp Severity: wishlist Owner: tsimo...@debian.org * Package name: lightdm-settings Version : 1.2.5 Upstream Author : Linux Mint * URL : https://github.com/linuxmint/lightdm-settings * License : GPL-3 Programming Lang: Python Description : LightDM Settings Configuration Tool This is in order to upstream a package uploaded to Ubuntu, which allows for graphical configuration of the LightDM display manager. I plan on maintaining this package alongside Martin Wimpress, from Debian MATE, and David Mohammed, from Debian Budgie, both of which are colleagues of mine in Ubuntu. David is a Debian Maintainer and I plan on giving him upload rights to this package, while Martin's uploads would need to be sponsored by either of us. -- Simon Quigley tsimo...@debian.org tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#928153: Bug#852963: Cross reference to RM
On 30.04.2019 00:34, Geert Stappers wrote: > On Mon, Apr 29, 2019 at 01:53:14PM +0300, Alex Morega wrote: >> On 29.04.2019 03:16, Geert Stappers wrote: >>> >>> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928153 >>> is requested to remove git-sh from the Debian archive >>> >> Are you using git-sh? Maybe it's just time to remove it from debian. > > Removing git-sh from Debian is what #928153 is all about. > > You can help with that removal with replying to this email. > It has Reply-To set. Just say in your own words that the removal > is OK for you. Yes, I'm ok with removing git-sh from the archive. -- Alex
Bug#928302: please provide virt-manager.mo for en instead of en_GB
Package: virt-manager Version: 1:2.0.0-3 Severity: normal Hi, virt-manager's English language file is delivered as en_GB. which causes a system with configured LANGUAGE=en_US:de to speak German. Moving the file to en from en_GB causes it to be used for en_US as well. Since it doesn't make much sense to deliver a virt-manager.mo for every English variant and/or to put every English variant into LANGUAGE, it would probably be the best solution to deliver /usr/share/locale/en_GB/LC_MESSAGES/virt-manager.mo as /usr/share/locale/en/LC_MESSAGES/virt-manager.mo instead. Thanks for considering. Greetings Marc -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.10-zgws1 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-gtk-vnc-2.0 0.9.0-1.1 ii gir1.2-libosinfo-1.0 1.2.0-1 ii gir1.2-libvirt-glib-1.0 1.0.0-1 ii gir1.2-vte-2.91 0.54.2-2 ii librsvg2-common 2.44.10-2 ii python-requests 2.21.0-1 ii python3 3.7.3-1 ii python3-dbus 1.2.8-3 ii python3-gi 3.30.4-1 ii python3-gi-cairo 3.30.4-1 ii python3-libvirt 5.0.0-1 ii virtinst 1:2.0.0-3 Versions of packages virt-manager recommends: ii gir1.2-spiceclientglib-2.0 0.35-2 ii gir1.2-spiceclientgtk-3.0 0.35-2 ii libvirt-daemon-system 5.0.0-2 Versions of packages virt-manager suggests: ii gir1.2-secret-1 0.18.7-1 ii gnome-keyring 3.28.2-5 ii ksshaskpass [ssh-askpass] 4:5.14.5-1 ii lxqt-openssh-askpass [ssh-askpass] 0.14.1-1 pn python3-guestfs ii virt-viewer 7.0-2 -- no debconf information -- debsums errors found: debsums: can't check virt-manager file /usr/share/locale/en_GB/LC_MESSAGES/virt-manager.mo (not a regular file)
Bug#928301: python3-psycopg2: new upstream available
Package: python3-psycopg2 Version: 2.7.7-1 Severity: wishlist Tags: upstream Dear maintainers, there is a new upstream version available. May I kindly ask for packaging as time permits ? Thanks, Karsten -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 5.0.0-trunk-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-psycopg2 depends on: ii libc62.28-8 ii libpq5 11.2-2 ii python3 3.7.2-1 python3-psycopg2 recommends no packages. Versions of packages python3-psycopg2 suggests: ii python-psycopg2-doc 2.7.7-1 -- no debconf information
Bug#928300: shim-signed: secure boot via removable media path unavailable
Package: shim-signed Severity: normal Dear Maintainer, on my up to date buster system I have installed shim-signed and grub-efi- amd64-singed and their dependencies as described on https://wiki.debian.org/SecureBoot/Testing. However, booting with secure boot option on (in firmware) is not possible. I strongly belive that the reason for that is my buggy UEFI implementation on my Intel board, as many people may have: I need to use the removable media path, as the debian installer provides the option. (see https://wiki.debian.org/UEFI#Force_grub- efi_installation_to_the_removable_media_path) Using only grub (without secure boot) this works well, and I can trigger that by dpkg-reconfigure grub-efi-amd64 and using the option force-efi-extra- removable true option. I see no option to do something similar with shim-signed and its companions. Unfortunately, manually cloning shimx64.efi to /boot/efi/EFI/BOOTX64.EFI and copying the rest of the /boot/efi/EFI/debian directory does not help. And, however, this would also be a todo after all packet updates... Thanks, Chris -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages shim-signed depends on: ii debconf [debconf-2.0] 1.5.71 ii grub-efi-amd64-bin 2.02+dfsg1-16 ii grub2-common 2.02+dfsg1-16 pn mokutil pn shim-helpers-amd64-signed Versions of packages shim-signed recommends: pn secureboot-db shim-signed suggests no packages.
Bug#928274: python-openopt: Here is a script to test all of the examples
Dear Kingsley, I am afraid that openopt is no longer developed upstream... openopt.org is not reachable, I see some clones laying around, e.g. https://github.com/troyshu/openopt pointing to archives of the elderly docs. CCing the last known for upstream email address. Dmitrey -- could you update on the status of the project, and either you know of someone picking up maintaining/further developing it? On Tue, 30 Apr 2019, Kingsley G. Morse Jr. wrote: > Package: python-openopt > Version: 0.38+svn1589-1.1 > Severity: normal > Dear Maintainer, >* What led up to the situation? >I tested an example script that comes with >the package named "python-openopt". >It failed. >I emailed the package's maintainer a few days >ago. >No reply. >Yet. >It occurred to me > 1.) it may interesting to test all of the > example scripts in the package, > 2.) I can code, > 3.) curse these good looks and > 4.) ;-) >* What exactly did you do (or not do) that was effective (or > ineffective)? > I wrote the following shell code to test all > of the examples included in the > python-openopt package > $ for f in /usr/share/doc/python-openopt/examples/*.py ; do echo > "===" ; echo ; echo "$f" ; echo ; echo ; echo ; python "$f" ; > done | tee /tmp/python-openopt_examples.log >* What was the outcome of this action? > The output file is attached. >* What outcome did you expect instead? >Less errors. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
Bug#927867: RM: elilo-installer -- ROM; elilo is no longer in the archive
Hello! On 4/24/19 12:46 PM, John Paul Adrian Glaubitz wrote: > elilo-installer can be removed from the archive as the bootloader it > installs, elilo, has been removed from the archive almost five > years ago [1]. > > There is no concern of breakage as all architectures which used elilo > in the past can now use GRUB without any problems, including ia64 which > we just switched over to use the grub-efi-ia64 package. elilo is also > dead upstream. > > Please remove elilo-installer. As a heads-up: ia64 has now been completely switched over to GRUB (both for the installed system and debian-installer) and ELILO is no longer needed. Hence, elilo-installer can be purged from the archive. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#928299: installation-reports: network-console doesnt set password hash, ssh not possible
Package: installation-reports Severity: important Tags: d-i Dear Maintainer, at least today's daily installer snapshot has a totally broken network-console. It asks for a password and confirmation and then prompts to continue isntallation with ssh installer@. However, no password hash is written to /etc/shadow, hence login into the installer is not possible. After changing to a different virtual console of the installing system and putting a valid password hash into /etc/shadow allowed installation to continue. Greetings Marc
Bug#927687: RFS: golang-gopkg-src-d-go-git.v4
On Wed, May 01, 2019 at 10:50:01PM +0900, Jongmin Kim wrote: > Dear Go team, > > I'm looking for a sponsor for the package "golang-gopkg-src-d-go-git.v4" > (#927687). > > This package is a prerequisite for some upcoming packages: > * golang-gopkg-src-d-go-git-fixtures.v3 (#927694) > * lazygit (#908894) > * gopasspw (#901133) > > This package needs some requisites not a part of Debian yet: > * golang-github-src-d-gcfg (#927675, NEW) <-- Uploaded, waiting for > migration.. > * golang-github-jbenet-go-context (#926172, RFS) <-- Please upload this > first. Thanks! EDIT: Both packages are already uploaded. * golang-github-src-d-gcfg (#927675, NEW) * golang-github-jbenet-go-context (#926172, NEW) Thank you! > > The package is on: > https://salsa.debian.org/go-team/packages/golang-gopkg-src-d-go-git.v4 > > The package was tested on both gbp and sbuild. It's also lintian-clean. > > The test of this package has a strong circular dependency relationship > with go-git-fixtures.v3. As go-git-fixtures.v3 do only matter with > the test, I disabled the test. I'll enable the test later, after the > go-git-fixtures.v3 uploaded to Debian. > > Please consider to review and upload it. Any kind of suggestions are > appreciated. > > Thank you! -- Jongmin Kim OpenPGP key located at https://jongmin.dev/pgp OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE 9472 D39D 8D29 BAF3 6DF8 signature.asc Description: PGP signature
Bug#926556: unblock: yubikey-personalization/1.19.3-3
Hi Nicoo, Ping. On Sun, 14 Apr 2019 06:27:00 + Niels Thykier wrote: > I cannot see these changes in unstable, so we cannot unblock them (nor > do I see them NEW). Please upload this and remove the moreinfo tag once > it is in unstable and ready for unblocking. I noticed in the other bug you may be looking for a sponsor. Is the packaging available somewhere? Please link it in both bugs so others can help you uploading it if that is still needed. Paul signature.asc Description: OpenPGP digital signature
Bug#927687: RFS: golang-gopkg-src-d-go-git.v4
Dear Go team, I'm looking for a sponsor for the package "golang-gopkg-src-d-go-git.v4" (#927687). This package is a prerequisite for some upcoming packages: * golang-gopkg-src-d-go-git-fixtures.v3 (#927694) * lazygit (#908894) * gopasspw (#901133) This package needs some requisites not a part of Debian yet: * golang-github-src-d-gcfg (#927675, NEW) <-- Uploaded, waiting for migration.. * golang-github-jbenet-go-context (#926172, RFS) <-- Please upload this first. Thanks! The package is on: https://salsa.debian.org/go-team/packages/golang-gopkg-src-d-go-git.v4 The package was tested on both gbp and sbuild. It's also lintian-clean. The test of this package has a strong circular dependency relationship with go-git-fixtures.v3. As go-git-fixtures.v3 do only matter with the test, I disabled the test. I'll enable the test later, after the go-git-fixtures.v3 uploaded to Debian. Please consider to review and upload it. Any kind of suggestions are appreciated. Thank you! -- Jongmin Kim OpenPGP key located at https://jongmin.dev/pgp OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE 9472 D39D 8D29 BAF3 6DF8 signature.asc Description: PGP signature
Bug#925936: release.debian.org: Would v4l-utils 1.16.5 match unblocking criteria?
Control: tags -1 - moreinfo On Sun, 14 Apr 2019 20:30:00 + Niels Thykier wrote: > Please go ahead with this patch and remove the moreinfo tag once it has > been fixed. The upload happened (two of them), the removal of the moreinfo tag was missing. Paul signature.asc Description: OpenPGP digital signature
Bug#925350: unblock: ubuntu-keyring/2018.09.18.1-5
Hi Hideki,
Kind ping. Do you have any intent to follow up on your request for the
unblock of ubuntu-keyring? Please respond on my remarks.
Paul
On 06-04-2019 21:24, Paul Gevers wrote:
> Control: tags -1 moreinfo
>
> Hi Hideki,
>
> On Sat, 23 Mar 2019 23:36:50 +0900 Hideki Yamane wrote:
>
>> + # force remove garbage that was created by previous version, oh
> moron...
>> + rm -f
> /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cloud-archive\,\
> ubuntu-cloud-removed-keys.gpg
>
> Policy 10.7.3 [1] says you can't do that if the local administrator has
> changed that file.
>
>> + # once clean up keyrings
>> + rm -f "${TRUSTEDPARTS}ubuntu-keyring-2012-cloud-archive.gpg" \
>> +"${TRUSTEDPARTS}ubuntu-keyring-2012-removed-keys.gpg"
>
> Same here. And in most other files. I admit it isn't very likely, but still.
>
> Paul
>
> [1] https://www.debian.org/doc/debian-policy/ch-files.html#behavior
>
signature.asc
Description: OpenPGP digital signature
Bug#928297: xserver-xorg-core: miss dependency in libgl1-mesa-glx -> effectively depends on libgl1-mesa-dri
Quoting Jonas Smedegaard (2019-05-01 15:25:16) > xserver-xorg-core 2:1.19.3-2 has Depends: libgl1-mesa-glx | libgl > > xserver-xorg-core 2:1.19.4-1 has Depends: libgl > > That change makes it impossible to install Xorg without DRI modules. > > In Debian stretch/amd64, a core X11 environment requires 14MB: [...] > In Debian buster/amd64, a core X11 environment requires 284 MB: [...] > I see no mention of need for tightening dependencies in changelog > entry for 2:1.19.4-1, and suspect that this change may be purely > accidental. Seems the change coincide with the introduction of src:libglvnd. - 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#925314: unblock: wordpress/5.0.3+dfsg1-1
Control: tags -1 - moreinfo On Mon, 8 Apr 2019 17:25:24 +0200 Ivo De Decker wrote: > Remove the moreinfo tag from this bug once the upload is in t-p-u. Somehow forgotten as the upload happened on 2019-04-18. Paul signature.asc Description: OpenPGP digital signature
Bug#928295: unblock: pythonmagick/0.9.19-3
Control: tags -1 moreinfo confirmed On 01-05-2019 15:06, Jochen Sprickerhof wrote: > pythonmagick was patched to compile with ImageMagick 7 in 0.9.19-1 > whereas buster is still on 6. This resulted the package failing to > import, see #928103 (missed to close this in the changelog). > I disabled the autopkgtest as it was failing because autopep8 doesn't > support module names different to packages names. How about generating a superficial test that does the same as autodep8 (I like your typo) but with the right module name for now? The rest looks good to me. Paul signature.asc Description: OpenPGP digital signature
Bug#928298: LUKS1 encrypting does not work
Package: zulucrypt-gui Version: 5.4.0-3 When I try to encrypt an USB-stick with the default-settings it gives an error and it does not work. First when I choose "LUKS2" it works. Using LUKS1 is the default in Zulucrypt-gui. ( When I insert an not-encrypted USB-stick Zulucrypt-gui does not see it. First when I unmount the stick, Zulucrypt lists it to make it possible to encrypt it.) With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Bug#928297: xserver-xorg-core: miss dependency in libgl1-mesa-glx -> effectively depends on libgl1-mesa-dri
Package: xserver-xorg-core Version: 2:1.19.3-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 xserver-xorg-core 2:1.19.3-2 has Depends: libgl1-mesa-glx | libgl xserver-xorg-core 2:1.19.4-1 has Depends: libgl That change makes it impossible to install Xorg without DRI modules. In Debian stretch/amd64, a core X11 environment requires 14MB: root@auryn:/# LANG=C apt install xserver-xorg-core Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: keyboard-configuration libbsd0 libdbus-1-3 libdrm2 libegl1-mesa libepoxy0 libexpat1 libffi6 libfontenc1 libfreetype6 libgbm1 libgl1-mesa-glx libglapi-mesa libice6 libkmod2 liblocale-gettext-perl libpciaccess0 libpixman-1-0 libpng16-16 libprocps6 libsm6 libwayland-client0 libwayland-server0 libx11-6 libx11-data libx11-xcb1 libxau6 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxcb-xfixes0 libxcb1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont2 libxkbfile1 libxmu6 libxpm4 libxshmfence1 libxt6 libxxf86vm1 procps udev x11-common x11-xkb-utils xkb-data xserver-common Suggested packages: pciutils xfonts-100dpi | xfonts-75dpi xfonts-scalable Recommended packages: dbus libgl1-mesa-dri psmisc xfonts-base xauth libpam-systemd The following NEW packages will be installed: keyboard-configuration libbsd0 libdbus-1-3 libdrm2 libegl1-mesa libepoxy0 libexpat1 libffi6 libfontenc1 libfreetype6 libgbm1 libgl1-mesa-glx libglapi-mesa libice6 libkmod2 liblocale-gettext-perl libpciaccess0 libpixman-1-0 libpng16-16 libprocps6 libsm6 libwayland-client0 libwayland-server0 libx11-6 libx11-data libx11-xcb1 libxau6 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxcb-xfixes0 libxcb1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont2 libxkbfile1 libxmu6 libxpm4 libxshmfence1 libxt6 libxxf86vm1 procps udev x11-common x11-xkb-utils xkb-data xserver-common xserver-xorg-core 0 upgraded, 53 newly installed, 0 to remove and 0 not upgraded. Need to get 13.9 MB of archives. After this operation, 38.8 MB of additional disk space will be used. That's same as when explicitly avoiding libgl1: root@auryn:/# LANG=C apt install xserver-xorg-core libgl1- Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'libgl1-mesa-glx' instead of 'libgl1' The following additional packages will be installed: keyboard-configuration libbsd0 libdbus-1-3 libdrm2 libegl1-mesa libepoxy0 libexpat1 libffi6 libfontenc1 libfreetype6 libgbm1 libgl1-mesa-glx libglapi-mesa libice6 libkmod2 liblocale-gettext-perl libpciaccess0 libpixman-1-0 libpng16-16 libprocps6 libsm6 libwayland-client0 libwayland-server0 libx11-6 libx11-data libx11-xcb1 libxau6 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxcb-xfixes0 libxcb1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont2 libxkbfile1 libxmu6 libxpm4 libxshmfence1 libxt6 libxxf86vm1 procps udev x11-common x11-xkb-utils xkb-data xserver-common Suggested packages: pciutils xfonts-100dpi | xfonts-75dpi xfonts-scalable Recommended packages: dbus libgl1-mesa-dri psmisc xfonts-base xauth libpam-systemd The following NEW packages will be installed: keyboard-configuration libbsd0 libdbus-1-3 libdrm2 libegl1-mesa libepoxy0 libexpat1 libffi6 libfontenc1 libfreetype6 libgbm1 libgl1-mesa-glx libglapi-mesa libice6 libkmod2 liblocale-gettext-perl libpciaccess0 libpixman-1-0 libpng16-16 libprocps6 libsm6 libwayland-client0 libwayland-server0 libx11-6 libx11-data libx11-xcb1 libxau6 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxcb-xfixes0 libxcb1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont2 libxkbfile1 libxmu6 libxpm4 libxshmfence1 libxt6 libxxf86vm1 procps udev x11-common x11-xkb-utils xkb-data xserver-common xserver-xorg-core 0 upgraded, 53 newly installed, 0 to remove and 0 not upgraded. Need to get 13.9 MB of archives. After this operation, 38.8 MB of additional disk space will be used. In Debian buster/amd64, a core X11 environment requires 284 MB: root@auryn:/# LANG=C apt install xserver-xorg-core Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: dbus dmsetup keyboard-configuration libapparmor1 libargon2-1 libbsd0 libcap2 libcryptsetup12 libdbus-1-3 libdevmapper1.02.1 libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2 libegl-mesa0 libegl1 libegl1-mesa libelf1 libepoxy0 libexpat1 libfontenc1 libfreetype6 libgbm1 libgl1 libgl1-mesa-dri libglapi-mesa libglvnd0 libglx-mesa0 libglx0 libice6 libidn11 libip4tc0 libjson-c3 libkmod2 libllvm7 liblocale-gettext-perl libnss-systemd libpam-systemd libpciaccess0 libpixman-1-0 libpng16-16 libsensors-config libsensors5 libsm6 libssl1.1
Bug#925496: Fix available upstream
Control: tag -1 pending On Wed, 2019-05-01 at 14:04 +0100, Mike Crowe wrote: > Control: tags -1 + fixed-upstream > > The workaround is included in upstream v4.19.35 onwards: > b787544dc5e707fec86161b881391eb9342806e6. This will be in the next update, as we've already rebased on 4.19.37. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#927694: ITP: golang-gopkg-src-d-go-git-fixtures.v3 -- several git fixtures to run go-git tests
Control: block -1 by 924280 927687 -- Jongmin Kim OpenPGP key located at https://jongmin.dev/pgp OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE 9472 D39D 8D29 BAF3 6DF8 signature.asc Description: PGP signature
Bug#928296: RFS: ghostwriter/1.8.0-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ghostwriter" * Package name: ghostwriter Section : editors It builds those binary packages: ghostwriter - Distraction-free, themeable Markdown editor To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ghostwriter Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/ghostwriter/ghostwriter_1.8.0-1.dsc More information about ghostwriter can be obtained from https://www.example.com. Changes since the last upload: ghostwriter (1.8.0-1) unstable; urgency=medium * New upstream release * removal clean-deps.patch * debian/control: change dependencies from QtWebKit to QtWebEngine -- Sebastien CHAVAUX Mon, 29 Apr 2019 08:22:44 +0200 Can you ship it in experimental? Regards, Sebastien CHAVAUX
Bug#927687: ITP: golang-gopkg-src-d-go-git.v4 -- highly extensible Git implementation in pure Go
Control: block -1 by 926172 927675 -- Jongmin Kim OpenPGP key located at https://jongmin.dev/pgp OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE 9472 D39D 8D29 BAF3 6DF8 signature.asc Description: PGP signature
Bug#928295: unblock: pythonmagick/0.9.19-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package pythonmagick pythonmagick was patched to compile with ImageMagick 7 in 0.9.19-1 whereas buster is still on 6. This resulted the package failing to import, see #928103 (missed to close this in the changelog). I disabled the autopkgtest as it was failing because autopep8 doesn't support module names different to packages names. unblock pythonmagick/0.9.19-3 -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-4-armmp (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff --git a/debian/changelog b/debian/changelog index 9a93a17..a20d793 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +pythonmagick (0.9.19-3) unstable; urgency=medium + + * Team upload. + * Disable failing autopkgtest + * Add patch for ImageMagick < 7 + + -- Jochen Sprickerhof Wed, 01 May 2019 14:45:43 +0200 + pythonmagick (0.9.19-2) unstable; urgency=medium * Fix debci diff --git a/debian/control b/debian/control index 4bbea2f..e3795c1 100644 --- a/debian/control +++ b/debian/control @@ -22,7 +22,6 @@ Build-Depends: python3-setuptools Standards-Version: 4.3.0 Homepage: http://www.imagemagick.org -Testsuite: autopkgtest-pkg-python Package: python-pythonmagick Architecture: any diff --git a/debian/patches/0002-Partly-revert-f4772d8-for-ImageMagick-7.patch b/debian/patches/0002-Partly-revert-f4772d8-for-ImageMagick-7.patch new file mode 100644 index 000..25d9e84 --- /dev/null +++ b/debian/patches/0002-Partly-revert-f4772d8-for-ImageMagick-7.patch @@ -0,0 +1,110 @@ +From 0c0e1e9a038d7e9f79f567714ab5054c9345 Mon Sep 17 00:00:00 2001 +From: Jochen Sprickerhof +Date: Wed, 1 May 2019 12:28:12 +0200 +Subject: [PATCH] Partly revert f4772d8 for ImageMagick < 7 + +--- + PythonMagick/__init__.py | 8 + pythonmagick_src/_main.cpp | 16 + 2 files changed, 12 insertions(+), 12 deletions(-) + +diff --git a/PythonMagick/__init__.py b/PythonMagick/__init__.py +index 61ba8d4..6750c2e 100644 +--- a/PythonMagick/__init__.py b/PythonMagick/__init__.py +@@ -51,10 +51,10 @@ class DrawableColor(_PythonMagick.DrawableColor): + class DrawableCompositeImage(_PythonMagick.DrawableCompositeImage): +pass + +-class DrawableStrokeDashArray(_PythonMagick.DrawableStrokeDashArray): ++class DrawableDashArray(_PythonMagick.DrawableDashArray): +pass + +-class DrawableStrokeDashOffset(_PythonMagick.DrawableStrokeDashOffset): ++class DrawableDashOffset(_PythonMagick.DrawableDashOffset): +pass + + class DrawableEllipse(_PythonMagick.DrawableEllipse): +@@ -78,7 +78,7 @@ class DrawableGravity(_PythonMagick.DrawableGravity): + class DrawableLine(_PythonMagick.DrawableLine): +pass + +-class DrawableAlpha(_PythonMagick.DrawableAlpha): ++class DrawableMatte(_PythonMagick.DrawableMatte): +pass + + class DrawableMiterLimit(_PythonMagick.DrawableMiterLimit): +@@ -174,7 +174,7 @@ class DrawableViewbox(_PythonMagick.DrawableViewbox): + class Exception(_PythonMagick.Exception): +pass + +-class FilterType(_PythonMagick.FilterType): ++class FilterTypes(_PythonMagick.FilterTypes): +pass + + class Geometry(_PythonMagick.Geometry): +diff --git a/pythonmagick_src/_main.cpp b/pythonmagick_src/_main.cpp +index a7d3cce..449f0b1 100644 +--- a/pythonmagick_src/_main.cpp b/pythonmagick_src/_main.cpp +@@ -30,7 +30,7 @@ void Export_pyste_src_PathArcAbs(); + void Export_pyste_src_Image(); + void Export_pyste_src_GravityType(); + void Export_pyste_src_Geometry(); +-void Export_pyste_src_FilterType(); ++void Export_pyste_src_FilterTypes(); + void Export_pyste_src_Exception(); + void Export_pyste_src_DrawableViewbox(); + void Export_pyste_src_DrawableTranslation(); +@@ -62,7 +62,7 @@ void Export_pyste_src_DrawablePointSize(); + void Export_pyste_src_DrawablePoint(); + void Export_pyste_src_DrawablePath(); + void Export_pyste_src_DrawableMiterLimit(); +-void Export_pyste_src_DrawableAlpha(); ++void Export_pyste_src_DrawableMatte(); + void Export_pyste_src_DrawableLine(); + void Export_pyste_src_DrawableGravity(); + void Export_pyste_src_DrawableFont(); +@@ -70,8 +70,8 @@ void Export_pyste_src_DrawableFillRule(); + void Export_pyste_src_DrawableFillOpacity(); + void Export_pyste_src_DrawableFillColor(); + void Export_pyste_src_DrawableEllipse(); +-void Export_pyste_src_DrawableStrokeDashOffset(); +-void Export_pyste_src_DrawableStrokeDashArray(); ++void Export_pyste_src_DrawableDashOffset(); ++void Export_pyste_src_DrawableDashArray(); + void Export_pyste_src_DrawableCompositeImage(); + void Export_pyste_src_DrawableColor(); + void Export_pyste_src_DrawableClipPath(); +@@ -119,7 +119,7 @@
Bug#925496: Fix available upstream
Control: tags -1 + fixed-upstream The workaround is included in upstream v4.19.35 onwards: b787544dc5e707fec86161b881391eb9342806e6. Mike.
Bug#919161: [Debichem-devel] Bug#927955: Bug#927955: Bug#927955: python-rdkit: missing module pyAvalonTools
Control: tags 919161 + pending Hi Alex, On 2019-04-30 17:01, Alex Mestiashvili wrote: > may be you also can have a look on #919161. I use python3 bindings for > work and see no reason why the merge request shouldn't be integrated. I have accepted your MR, will upload once it finishes building. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#782001: access granted to /home files of another user
On Sat, 2019-03-02 at 13:20 +0100, Yves-Alexis Perez wrote: > On Sat, 2019-03-02 at 08:15 +0100, Ansgar wrote: > > I think this problem (having $HOME world-readable by default) should > > really be fixed... In installations sharing $HOME between multiple > > users this means private data of all sorts (medical records, unpublished > > scientific articles, exam results, ...) can be accessed by /all/ users > > by default. This seems a really bad idea. > > > > Dear security team, should such issues get a CVE id? If one follows the > > link from [1], one should contact the Debian security team to assign one > > (even though [1] says Debian won't assign one?). > > Own opinion on this: I don't think it deserves a CVE but I'd be all for > changing the default. Well, it's local information disclosure. It similar to having /etc/shadow world-readable (though having $HOME world-readable is actually worse as shadow only has hashed passwords). > In 2019 I'd say most installations are single (human) > users but changing uids might be used for isolation between applications for > example. I think world-readable home by default is totally inappropriate for any multi-user system in 2019. Note that the entire $HOME is also readable by system users, including nobody, by default this way. That just defeats the purpose of having unpriviledged users on single-user systems... On multi-user systems this is worse, more so when $HOME is on a network system: every user can read other users' data, including private information (unless applications take care to not make them world- readable). I think Debian should be usable with multiple local users by default, without needing special configuration; there is no documentation what users would have to do to be able to run a multi-user system. So the default should be safe. Ansgar
Bug#912137: Acer C740 hanging with kernel 4.18.0-0.bpo.1-amd64 from Stretch backports
I installed 4.19.28-2~bpo9+1 and haven't encountered any hangs with it.
Bug#919978: diaspora-installer package fails to install
On Tue, 30 Apr 2019 23:20:41 +0200 Andreas Beckmann wrote: > that error seems to be unrelated to the bundler version used: This seems unrelated to diaspora-installer then. As I was able to reproduce it with bundler 2.0 and after changing to bundler 1.17.3 it worked. So it seems a fresh installation is unable to find bundle command but retrying again works, ie, if bundle command is available before installation starts, it seems to work. Any ideas? signature.asc Description: OpenPGP digital signature
Bug#925986: jruby: diff for NMU version 9.1.17.0-2.1
Control: tags 925986 + patch Control: tags 925986 + pending Dear maintainer, I've prepared an NMU for jruby (versioned as 9.1.17.0-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. The reason for this NMU although there are more open unfixed CVEs is that we are in line with stretch. CVE-2018-173 was fixed in stretch but not for buster, so that would mean in any case a regression from stretch to buster. Regards, Salvatore diff -Nru jruby-9.1.17.0/debian/changelog jruby-9.1.17.0/debian/changelog --- jruby-9.1.17.0/debian/changelog 2019-02-26 10:24:15.0 +0100 +++ jruby-9.1.17.0/debian/changelog 2019-05-01 11:25:03.0 +0200 @@ -1,3 +1,11 @@ +jruby (9.1.17.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Directory traversal vulnerability in install_location (CVE-2018-173) +(Closes: #925986) + + -- Salvatore Bonaccorso Wed, 01 May 2019 11:25:03 +0200 + jruby (9.1.17.0-2) unstable; urgency=medium * Annotate the javax.annotation.Generated patch. diff -Nru jruby-9.1.17.0/debian/patches/0017-CVE-2018-173.patch jruby-9.1.17.0/debian/patches/0017-CVE-2018-173.patch --- jruby-9.1.17.0/debian/patches/0017-CVE-2018-173.patch 1970-01-01 01:00:00.0 +0100 +++ jruby-9.1.17.0/debian/patches/0017-CVE-2018-173.patch 2019-05-01 11:23:43.0 +0200 @@ -0,0 +1,25 @@ +From: Jonathan Claudius +Date: Wed, 7 Feb 2018 23:54:52 -0500 +Subject: Non-working patch for deducing symlinked base-dirs +Origin: https://github.com/rubygems/rubygems/commit/1b931fc03b819b9a0214be3eaca844ef534175e2 +Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-173 +Bug-Debian: https://bugs.debian.org/925986 + +--- + +diff --git a/lib/ruby/stdlib/rubygems/package.rb b/lib/ruby/stdlib/rubygems/package.rb +index dede959981e7..cb9c74a0fc07 100644 +--- a/lib/ruby/stdlib/rubygems/package.rb b/lib/ruby/stdlib/rubygems/package.rb +@@ -421,6 +421,8 @@ EOM + destination_dir = File.expand_path destination_dir + + destination = File.join destination_dir, filename ++destination = File.realpath destination if ++ File.respond_to? :realpath + destination = File.expand_path destination + + raise Gem::Package::PathError.new(destination, destination_dir) unless +-- +2.20.1 + diff -Nru jruby-9.1.17.0/debian/patches/series jruby-9.1.17.0/debian/patches/series --- jruby-9.1.17.0/debian/patches/series 2019-02-26 10:24:15.0 +0100 +++ jruby-9.1.17.0/debian/patches/series 2019-05-01 11:23:50.0 +0200 @@ -12,3 +12,4 @@ 0014-FELIX-5430.patch 0015-javax-annotation-Generated.patch 0016-Disable-SkinnyMethodAdapter-test.patch +0017-CVE-2018-173.patch
Bug#928294: unblock: suricata/4.1.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Although it is an upstream release, please unblock suricata 4.1.4-1 for buster. Suricata is an Intrusion Detection System (IDS), which makes it exposed to malicious traffic by design. The upstream release 4.1.4 fixes several bugs and security issues (no CVE numbers). The debdiff since 4.1.3 is too big to be included here (it contains updates to many auto-generated files like configure), so I'm adding the upstream changelog here: Changes Bug #2870: pcap logging with lz4 coverity warning Bug #2883: ssh: heap buffer overflow Bug #2884: mpls: heapbuffer overflow in file decode-mpls.c Bug #2887: decode-ethernet: heapbuffer overflow in file decode-ethernet.c Bug #2888: 4.1.3 core in HCBDCreateSpace Bug #2894: smb 1 create andx request does not parse the filename correctly Bug #2902: rust/dhcp: panic in dhcp parser Bug #2903: mpls: cast of misaligned data leads to undefined behavior Bug #2904: rust/ftp: panic in ftp parser Bug #2943: rust/nfs: integer underflow This release includes Suricata-Update 1.0.5 I hope the new version can be included. Best regards, Pierre
Bug#928264: [gnome-maps] Gnome Maps crashes as soon as you search for a city.
Control: reassign 928264 libgeocode-glib0 3.20.1-2
Control: tags 928264 + upstream fixed-upstream patch
Control: affects 928264 gnome-maps
Control: fixed 928264 libgeocode-glib0/3.26.1-1
Dear Maintainer,
I just tried to reproduce and hit the segfault below [3].
This seems to be reported in bugs [1],
but just fixed in buster yet.
The upstream patch applies to 3.20.1-2
when the filename is replaced [2].
A package built with that patch does not crash
and shows search results.
Kind regards,
Bernhard
[1]
https://bugs.debian.org/925539
https://bugs.debian.org/924499
[2]
wget
https://gitlab.gnome.org/GNOME/geocode-glib/commit/e7216583a219df9d9eba21a7fe1b74543b6d5851.patch
-O ../e7216583a219df9d9eba21a7fe1b74543b6d5851.patch
sed -i 's/geocode-nominatim.c/geocode-forward.c/g'
../e7216583a219df9d9eba21a7fe1b74543b6d5851-backport.patch
patch -p1 < ../e7216583a219df9d9eba21a7fe1b74543b6d5851-backport.patch
[3]
(gdb) bt
#0 0x7f5ee457fcf5 in __GI_strtol_l_internal (nptr=0x0,
endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0,
loc=0x7f5ee48e3400 <_nl_global_locale>) at ../stdlib/strtol_l.c:293
#1 0x7f5ee457fc82 in __strtol (nptr=,
endptr=endptr@entry=0x0, base=base@entry=10) at ../stdlib/strtol.c:106
#2 0x7f5ed33aa2b8 in atoi (__nptr=) at
/usr/include/stdlib.h:241
#3 0x7f5ed33aa2b8 in get_place_type_from_attributes (ht=0x7f5e3c0022a0) at
geocode-forward.c:750
#4 0x7f5ed33aa2b8 in _geocode_create_place_from_attributes
(ht=ht@entry=0x7f5e3c0022a0) at geocode-forward.c:792
#5 0x7f5ed33aa794 in insert_place_into_tree (ht=0x7f5e3c0022a0,
place_tree=0x561d40d186c0) at geocode-forward.c:887
#6 0x7f5ed33aa794 in _geocode_parse_search_json
(contents=contents@entry=0x561d407df3c0
"[{\"place_id\":595794,\"licence\":\"Data © OpenStreetMap contributors, ODbL
1.0.
https://osm.org/copyright\",\"osm_type\":\"node\",\"osm_id\":240109189,\"boundingbox\":[\"52.3570365\",\"52.6770365\",\"13.2288599\",\"13.5;...,
error=error@entry=0x7ffcefb41d80) at geocode-forward.c:999
#7 0x7f5ed33aaae6 in on_query_data_loaded (session=,
query=0x561d40f7f640 [SoupMessage], user_data=) at
geocode-forward.c:366
#8 0x7f5ed2f095be in soup_session_process_queue_item (session=, item=0x561d40577390, should_cleanup=, loop=) at soup-session.c:2025
#9 0x7f5ed2f09f42 in async_run_queue (session=session@entry=0x561d3eee3e80
[SoupSession]) at soup-session.c:2065
#10 0x7f5ed2f09ff6 in idle_run_queue (user_data=) at
soup-session.c:2092
#11 0x7f5ee56846aa in g_main_dispatch (context=0x561d3eee1650) at
././glib/gmain.c:3203
#12 0x7f5ee56846aa in g_main_context_dispatch
(context=context@entry=0x561d3eee1650) at ././glib/gmain.c:3856
#13 0x7f5ee5684a60 in g_main_context_iterate
(context=context@entry=0x561d3eee1650, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3929
#14 0x7f5ee5684b0c in g_main_context_iteration
(context=context@entry=0x561d3eee1650, may_block=may_block@entry=1) at
././glib/gmain.c:3990
#15 0x7f5ee1e9672d in g_application_run (application=0x561d3f006150
[Gjs_Application], argc=1, argv=0x561d3efbb780) at ././gio/gapplication.c:2381
#16 0x7f5ee4346038 in ffi_call_unix64 () at ../src/x86/unix64.S:76
#17 0x7f5ee4345a9a in ffi_call (cif=cif@entry=0x561d3f388598, fn=, rvalue=, rvalue@entry=0x7ffcefb422d0,
avalue=avalue@entry=0x7ffcefb421a0) at ../src/x86/ffi64.c:525
#18 0x7f5ee53d3301 in gjs_invoke_c_function(JSContext*, Function*,
JSObject*, unsigned int, jsval*, jsval*, GArgument*)
(context=context@entry=0x561d3eef4170, function=function@entry=0x561d3f388580,
obj=obj@entry=0x7f5ec2898250, js_argc=js_argc@entry=1,
js_argv=js_argv@entry=0x561d3ef41928, js_rval=js_rval@entry=0x7ffcefb424e0,
r_value=) at gi/function.cpp:999
#19 0x7f5ee53d4a7f in function_call(JSContext*, unsigned int, jsval*)
(context=0x561d3eef4170, js_argc=1, vp=0x561d3ef41918) at gi/function.cpp:1323
#20 0x7f5ee17358fc in js::CallJSNative(JSContext*, int (*)(JSContext*,
unsigned int, JS::Value*), JS::CallArgs const&) (args=..., native=, cx=0x561d3eef4170) at ./jscntxtinlines.h:321
#21 0x7f5ee17358fc in js::Invoke(JSContext*, JS::CallArgs,
js::MaybeConstruct) (cx=cx@entry=0x561d3eef4170, args=...,
construct=construct@entry=js::NO_CONSTRUCT) at ./js/src/vm/Interpreter.cpp:474
#22 0x7f5ee1736918 in Interpret(JSContext*, js::RunState&)
(cx=cx@entry=0x561d3eef4170, state=...) at ./js/src/vm/Interpreter.cpp:2298
#23 0x7f5ee173ee78 in js::RunScript(JSContext*, js::RunState&)
(cx=cx@entry=0x561d3eef4170, state=...) at ./js/src/vm/Interpreter.cpp:438
#24 0x7f5ee173fffa in js::ExecuteKernel(JSContext*, JS::Handle,
JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*)
(result=0x7ffcefb42e60, evalInFrame=..., type=js::EXECUTE_GLOBAL,
thisv=..., scopeChainArg=..., script=..., cx=0x561d3eef4170)
at ./js/src/vm/Interpreter.cpp:622
#25 0x7f5ee173fffa in js::Execute(JSContext*,
Bug#904976: Patch for gtk3
Hello, I'm having an HiRes display and Gtk2 doesn't perform very well with HiRes. Here's a patch to build the package with Gtk3. Regards Jörg #NieWiederCDU – Wir müssen die Zukunft gestalten, statt Überholtes erhalten -- Nutze die Talente, die du hast. Die Wälder wären sehr still, wenn nur die begabtesten Vögel sängen.(Henry van Dyke) diff -u -r old/geeqie-1.4+git20190121/debian/changelog geeqie-1.4+git20190121/debian/changelog --- old/geeqie-1.4+git20190121/debian/changelog 2019-02-26 02:57:33.0 +0100 +++ geeqie-1.4+git20190121/debian/changelog 2019-05-01 13:19:31.349441339 +0200 @@ -1,3 +1,9 @@ +geeqie (1:1.4+git20190121-2.gtk3) unstable; urgency=medium + + * Build with Gtk3; see #904976 + + -- Jörg Sommer Wed, 01 May 2019 13:17:37 +0200 + geeqie (1:1.4+git20190121-2) unstable; urgency=medium * Add patch to fix crash in some cases in preferences dialog diff -u -r old/geeqie-1.4+git20190121/debian/control geeqie-1.4+git20190121/debian/control --- old/geeqie-1.4+git20190121/debian/control 2019-02-26 02:57:33.0 +0100 +++ geeqie-1.4+git20190121/debian/control 2019-05-01 13:12:07.421666556 +0200 @@ -7,10 +7,12 @@ libtool, autoconf, automake, - libgtk2.0-dev, + libgtk-3-dev, libexiv2-dev, liblcms2-dev, liblircclient-dev, + libclutter-gtk-1.0-dev, + libchamplain-gtk-0.12-dev, intltool, gnome-doc-utils, imagemagick, diff -u -r old/geeqie-1.4+git20190121/debian/rules geeqie-1.4+git20190121/debian/rules --- old/geeqie-1.4+git20190121/debian/rules 2019-02-26 02:57:33.0 +0100 +++ geeqie-1.4+git20190121/debian/rules 2019-05-01 13:13:44.327989866 +0200 @@ -1,15 +1,14 @@ #!/usr/bin/make -f %: - dh $@ --fail-missing + dh $@ # build simple version first # override_dh_auto_configure: dh_auto_configure -- \ --with-htmldir=/usr/share/doc/geeqie/html \ --with-readmedir=/usr/share/doc/geeqie-common/ \ - --enable-lirc \ - --disable-gtk3 + --enable-lirc override_dh_auto_install: mkdir -p $(CURDIR)/debian/tmp/usr/share/doc/geeqie/html signature.asc Description: PGP signature
Bug#928292: stretch-pu: package signing-party/2.5-1
Hi Salvatore,
On Wed, 01 May 2019 at 13:37:12 +0200, Salvatore Bonaccorso wrote:
> On Wed, May 01, 2019 at 01:27:26PM +0200, Guilhem Moulin wrote:
>> +signing-party (2.5-1+deb9u1) stretch; urgency=medium
>> +
>> + * Backport security fix for CVE-2018-15599: unsafe shell call enabling
>> shell
> ^^ That would be CVE-2019-11627
>
> (and as well for the patch name itself).
Ooops, I got fooled by my copy-paste fu, and did the same mistake in
2.10-1… Thanks for spotting! New debdiff attached.
Cheers,
--
Guilhem.
diff -Nru signing-party-2.5/debian/changelog signing-party-2.5/debian/changelog
--- signing-party-2.5/debian/changelog 2016-10-06 14:59:44.0 +0200
+++ signing-party-2.5/debian/changelog 2019-05-01 12:55:42.0 +0200
@@ -1,3 +1,11 @@
+signing-party (2.5-1+deb9u1) stretch; urgency=medium
+
+ * Backport security fix for CVE-2019-11627: unsafe shell call enabling shell
+injection via a User ID. Use Perl's (core) module Encode.pm instead of
+shelling out to `iconv`. (Closes: #928256.)
+
+ -- Guilhem Moulin Wed, 01 May 2019 12:55:42 +0200
+
signing-party (2.5-1) unstable; urgency=low
* caff:
diff -Nru signing-party-2.5/debian/control signing-party-2.5/debian/control
--- signing-party-2.5/debian/control2016-10-06 14:59:44.0 +0200
+++ signing-party-2.5/debian/control2019-05-01 12:55:42.0 +0200
@@ -1,7 +1,7 @@
Source: signing-party
Section: misc
Priority: extra
-Maintainer: Guilhem Moulin
+Maintainer: Guilhem Moulin
Uploaders: Simon Richter
Build-Depends: debhelper (>= 9), python, dh-python,
autoconf, automake, autotools-dev,
diff -Nru signing-party-2.5/debian/patches/CVE-2019-11627.diff
signing-party-2.5/debian/patches/CVE-2019-11627.diff
--- signing-party-2.5/debian/patches/CVE-2019-11627.diff1970-01-01
01:00:00.0 +0100
+++ signing-party-2.5/debian/patches/CVE-2019-11627.diff2019-05-01
12:55:42.0 +0200
@@ -0,0 +1,27 @@
+From: Guilhem Moulin
+Date: Tue, 30 Apr 2019 19:49:45 +0200
+Subject: gpg-key2ps: Fix shell injection vulnerability in UIDs rendering.
+
+---
+ gpg-key2ps/gpg-key2ps |3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/gpg-key2ps/gpg-key2ps
b/gpg-key2ps/gpg-key2ps
+@@ -10,6 +10,7 @@
+ # $Id: gpg-key2ps 882 2016-10-06 13:04:49Z guilhem-guest $
+
+ use strict;
++use Encode ();
+ use Getopt::Long;
+
+ my $version = '$Rev: 882 $';
+@@ -269,7 +270,7 @@ while() {
+ }
+ # user ids
+ s/\\x(\p{AHex}{2})/ chr(hex($1)) /ge;
+- $_ = `echo "$_" | iconv -c -f utf-8 -t latin1`;
++ $_ = Encode::encode("latin1", Encode::decode_utf8($_));
+ s/^uid:[^:r]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:([^:]*):.*/
($1) uid/;
+ # revoked user id
+ if (s/^uid:r[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:([^:]*):.*/
($1) revuid/) {
diff -Nru signing-party-2.5/debian/patches/series
signing-party-2.5/debian/patches/series
--- signing-party-2.5/debian/patches/series 2016-10-06 14:59:44.0
+0200
+++ signing-party-2.5/debian/patches/series 2019-05-01 12:55:42.0
+0200
@@ -1 +1,2 @@
gpgwrap_makefile.diff
+CVE-2019-11627.diff
signature.asc
Description: PGP signature
Bug#928293: ITP: ensmallen -- C++ header-only library for mathematical optimization
Package: wnpp Owner: Barak A. Pearlmutter Severity: wishlist * Package name: ensmallen Version : 1.14.2 Upstream Author : Ryan Curtin * URL or Web page : https://www.ensmallen.org/ * License : 3-clause BSD Description : C++ header-only library for mathematical optimization Ensmallen provides a simple set of abstractions for writing an objective function to optimize. It also provides a large set of standard and cutting-edge optimizers that can be used for virtually any mathematical optimization task. These include full-batch gradient descent techniques, small-batch techniques, gradient-free optimizers, and constrained optimization. Will be packaged as part of the Debian Science Team.
Bug#921019: arm64: Please provide sound modules for Allwinner A64 based systems
On Jo, 31 ian 19, 17:21:54, Harald Geyer wrote: > Please enable the following Kconfig symbols as modules: > > CONFIG_SND_SUN50I_CODEC_ANALOG > CONFIG_SND_SUN8I_CODEC > CONFIG_SND_SUN4I_I2S > CONFIG_SND_SOC_SIMPLE_AMPLIFIER > CONFIG_SND_SIMPLE_CARD > > These are necessary for sound support on pinebook, Olimex TERES-I, etc. > The drivers are available upstream since 4.20. > Pinebook has sound enabled in devicetree starting with 5.0 Would this enable also the S/PDIF or is something else needed (CONFIG_SND_SUN4I_SPDIF maybe?)? According to https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix the S/PDIF is available already in 4.17, so it would be nice to activate it also for the stable kernel. Thanks for considering, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
Bug#928291: unblock: signing-party/2.10-1
On Wed, 01 May 2019 at 12:46:12 +0200, Guilhem Moulin wrote: > gpg-key2ps(1) from signing-party 2.9-1 is vulnerable to CVE-2018-15599: > unsafe shell call enabling shell injection via a User ID. Erm that should be CVE-2019-11627, and the changelog is wrong as well. Would you like me to upload a 2.10-1 with a fixed debian/changelog? -- Guilhem. signature.asc Description: PGP signature
Bug#928292: stretch-pu: package signing-party/2.5-1
Hi Guilhem [disclaimer: not part of release team, just spotted below a typo] On Wed, May 01, 2019 at 01:27:26PM +0200, Guilhem Moulin wrote: > +signing-party (2.5-1+deb9u1) stretch; urgency=medium > + > + * Backport security fix for CVE-2018-15599: unsafe shell call enabling > shell ^^ That would be CVE-2019-11627 (and as well for the patch name itself). Regards, Salvatore
Bug#787259: Acknowledgement (start error with pbuilder-satisfydepends-gdebi)
François Poirotte dixit: > this and I'm not sure how this could be fixed (does the Debian policy even > state what the character encoding should be for the control file?) It requires UTF-8 encoding, has been doing so since a couple of years. Can you try rebuilding without your local hack, but with the environment variable LC_ALL=C.UTF-8 exported? bye, //mirabilos -- This space for rent. https://paypal.me/mirabilos to support my work.
Bug#928292: stretch-pu: package signing-party/2.5-1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi there,
CVE-2019-11627 was recently published for signing-party's gpg-key2ps(1).
Unsafe shell call enabling shell injection via a User ID.
See also #928256. However the Security Team didn't issue a DSA [0], and
suggested to instead fix that via stretch-pu. I enclosed a debdiff
against signing-party_2.5-1.dsc.
In the fix I replaced the of use of iconv(1) with Perl's module
‘Encode.pm’ instead; it's a core module so the package doesn't need any
new dependency.
Cheers,
--
Guilhem.
[0] https://security-tracker.debian.org/tracker/CVE-2019-11627
diff -Nru signing-party-2.5/debian/changelog signing-party-2.5/debian/changelog
--- signing-party-2.5/debian/changelog 2016-10-06 14:59:44.0 +0200
+++ signing-party-2.5/debian/changelog 2019-05-01 12:55:42.0 +0200
@@ -1,3 +1,11 @@
+signing-party (2.5-1+deb9u1) stretch; urgency=medium
+
+ * Backport security fix for CVE-2018-15599: unsafe shell call enabling shell
+injection via a User ID. Use Perl's (core) module Encode.pm instead of
+shelling out to `iconv`. (Closes: #928256.)
+
+ -- Guilhem Moulin Wed, 01 May 2019 12:55:42 +0200
+
signing-party (2.5-1) unstable; urgency=low
* caff:
diff -Nru signing-party-2.5/debian/control signing-party-2.5/debian/control
--- signing-party-2.5/debian/control2016-10-06 14:59:44.0 +0200
+++ signing-party-2.5/debian/control2019-05-01 12:55:42.0 +0200
@@ -1,7 +1,7 @@
Source: signing-party
Section: misc
Priority: extra
-Maintainer: Guilhem Moulin
+Maintainer: Guilhem Moulin
Uploaders: Simon Richter
Build-Depends: debhelper (>= 9), python, dh-python,
autoconf, automake, autotools-dev,
diff -Nru signing-party-2.5/debian/patches/CVE-2018-15599.diff
signing-party-2.5/debian/patches/CVE-2018-15599.diff
--- signing-party-2.5/debian/patches/CVE-2018-15599.diff1970-01-01
01:00:00.0 +0100
+++ signing-party-2.5/debian/patches/CVE-2018-15599.diff2019-05-01
12:55:42.0 +0200
@@ -0,0 +1,27 @@
+From: Guilhem Moulin
+Date: Tue, 30 Apr 2019 19:49:45 +0200
+Subject: gpg-key2ps: Fix shell injection vulnerability in UIDs rendering.
+
+---
+ gpg-key2ps/gpg-key2ps |3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/gpg-key2ps/gpg-key2ps
b/gpg-key2ps/gpg-key2ps
+@@ -10,6 +10,7 @@
+ # $Id: gpg-key2ps 882 2016-10-06 13:04:49Z guilhem-guest $
+
+ use strict;
++use Encode ();
+ use Getopt::Long;
+
+ my $version = '$Rev: 882 $';
+@@ -269,7 +270,7 @@ while() {
+ }
+ # user ids
+ s/\\x(\p{AHex}{2})/ chr(hex($1)) /ge;
+- $_ = `echo "$_" | iconv -c -f utf-8 -t latin1`;
++ $_ = Encode::encode("latin1", Encode::decode_utf8($_));
+ s/^uid:[^:r]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:([^:]*):.*/
($1) uid/;
+ # revoked user id
+ if (s/^uid:r[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:([^:]*):.*/
($1) revuid/) {
diff -Nru signing-party-2.5/debian/patches/series
signing-party-2.5/debian/patches/series
--- signing-party-2.5/debian/patches/series 2016-10-06 14:59:44.0
+0200
+++ signing-party-2.5/debian/patches/series 2019-05-01 12:55:42.0
+0200
@@ -1 +1,2 @@
gpgwrap_makefile.diff
+CVE-2018-15599.diff
signature.asc
Description: PGP signature
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Thu 25/Apr/2019 16:12:42 +0200 Dmitry Bogatov wrote: > [2019-04-22 19:07] Alessandro Vesely > >> The point is building every time from scratch, rigidly enjoining specs, >> like it or lump it, versus an incremental, tolerant, minimal changes >> operation. > > What is the point of "incremental, tolerant, minimal changes operation"? Just to allow a wider set of possibilities. > C compiler always builds .o file from source file always afresh, and it > reduces its complexity, and insserv(8) can be seen as compiler from > content of /etc/init.d/, /etc/insserv/ and /etc/insserv.conf to > /etc/rc[0-6].d .o files are not quite editable. To patch them, one needs so much careful checking that it is not practical to do it. There is no tool to support it. And, you don't recompile every object and library every time. > The only possible reason to attempt reusing existing content of > /etc/rc[0-6].d is perfomance, and it does not apply. I agree performance is not an issue. > I argue, that isserv(8) is compiler, not build tool like make(1), since > it is impossible to separate processing of any individual file from rest > of them: /etc/init.d/, /etc/insserv/ and /etc/insserv.conf together > are single input. It is possible to consider each /etc/rc[0-6].d as > separate output, but it is useless. Your latter paragraph condenses very well the point on which we disagree. Unlike object files, /etc/rc?.d can be edited using ln, mv and rm. It would even be possible to place there a plain script or --why not?-- an executable. No, I never did that and cannot imagine why on earth someone else would do it. But, in case, who am I to deny them the right to do so? Put it another way, if I drop the (admittedly unrealistic) possibility to edit rc?.d's by hand, I would have to conclude that that architecture is a relic devoid of its functionality. Do we maintain it for aesthetic reasons, like the Colosseum? I wouldn't know. I like it, probably just because I've been using it for so long. I appreciate LSB comment convention as a clever evolution, which helps ordering the links. Preserving that somewhat baroque directory structure, deprived of its flexibility merits, however, sounds fictional. Best Ale --
Bug#928288: knack: please make the build reproducible
On Wed, 2019-05-01 at 06:18 -0400, Chris Lamb wrote: > [adding > reproducible-bui...@lists.alioth.debian.org > to CC] > > Hi Luca, > > > Also the reprotest on the Gitlab CI didn't flag it as those builds > > are > > run with "nocheck": > > That's... unfortunate. :) Indeed, there are a non-trivial number of > packages that are non-determinstic due to their tests. Could you > spearhead getting this changed? > > > Best wishes, Sure, opened a MR: https://salsa.debian.org/salsa-ci-team/pipeline/merge_requests/74 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#928291: unblock: signing-party/2.10-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi there,
gpg-key2ps(1) from signing-party 2.9-1 is vulnerable to CVE-2018-15599:
unsafe shell call enabling shell injection via a User ID.
Debdiff between 2.9-1 and 2.10-1 attached. (While the package is not
native we're also upstream.) I replaced the of use of iconv(1) with
Perl's module ‘Encode.pm’ instead; it's a core module so the package
doesn't need any new dependency.
unblock signing-party/2.10-1
Thanks for considering its inclusion to Buster!
Cheers,
--
Guilhem.
diff -Nru signing-party-2.9/debian/changelog signing-party-2.10/debian/changelog
--- signing-party-2.9/debian/changelog 2019-03-01 15:39:40.0 +0100
+++ signing-party-2.10/debian/changelog 2019-05-01 12:21:59.0 +0200
@@ -1,3 +1,11 @@
+signing-party (2.10-1) unstable; urgency=high
+
+ * gpg-key2ps: Security fix for CVE-2018-15599: unsafe shell call enabling
+shell injection via a User ID. Use Perl's (core) module Encode.pm instead
+of shelling out to `iconv`. (Closes: #928256.)
+
+ -- Guilhem Moulin Wed, 01 May 2019 12:21:59 +0200
+
signing-party (2.9-1) unstable; urgency=medium
* gpglist:
diff -Nru signing-party-2.9/gpg-key2ps/gpg-key2ps
signing-party-2.10/gpg-key2ps/gpg-key2ps
--- signing-party-2.9/gpg-key2ps/gpg-key2ps 2019-03-01 15:40:38.0
+0100
+++ signing-party-2.10/gpg-key2ps/gpg-key2ps2019-05-01 12:22:19.0
+0200
@@ -9,6 +9,7 @@
#
use strict;
+use Encode ();
use Getopt::Long;
my $version = '@@VERSION@@';
@@ -267,7 +268,7 @@
}
# user ids
s/\\x(\p{AHex}{2})/ chr(hex($1)) /ge;
- $_ = `echo "$_" | iconv -c -f utf-8 -t latin1`;
+ $_ = Encode::encode("latin1", Encode::decode_utf8($_));
s/^uid:[^:r]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:([^:]*):.*/
($1) uid/;
# revoked user id
if (s/^uid:r[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:([^:]*):.*/
($1) revuid/) {
signature.asc
Description: PGP signature
Bug#926547: insserv: tests/run-tests are not used
[2019-04-28 21:05] Jesse Smith > > I have been looking into the issues with the insserv test scripts. There > are a few problems here, in brief: > [...] > > In other words, I think there is some difference in expectations between > what I think insserv should be doing and what the scripts we inherited > from downstream think insserv should be doing. I'm interested in getting > some feedback on this. If a script has no LSB header, should it be given > preset defaults, or should it be ignored? If the latter, I think we can > remove this series of tests. Which will mean there are just two errors > left for me to sort out. In my opinion, insserv should print warning about missing LSB headers and ignore them. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
