Bug#953080: create and store ssh private host keys in tpm?
Package: openssh-server Version: 1:8.2p1-4 Severity: wishlist The private host keys in /etc/ssh are (usually) unencrypted and easy to steal, e.g. using docker (not shown here). Would it be possible to add some code to postinst to make use of the tpm to create and store the private ssh keys, if the hardware can be found? See also the simple-tpm-pk11 package, for example https://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys---properly.html Regards Harri
Bug#952695: Request for sponsorship or upload rights Re: r-cran-xml2: autopkgtest failure against libxml2 2.9.10
Hi Michael, On Tue, 3 Mar 2020 16:22:47 +0100 "Michael R. Crusoe" wrote: > I've commited a fix for this bug. > > > If a DD could sponsor that upload or grant me upload rights, I would > appreciate it. > Thanks for this! Just uploaded! I got an error when I tried to grant you upload rights for this package, but probably only from my side. I will try to fix it before the next time. Best, Dylan
Bug#918531: ITP: trx -- realtime audio over IP
Hi, Apologies, I did not see this ITP when I was searching for it earlier. I have packaged and uploaded trx to the NEW queue [1]. The package is in the Debian group on Salsa [2], and you are welcome to become a co-maintainer of the package if you wish. The binaries have been renamed to trx-rx and trx-tx. [1] https://ftp-master.debian.org/new/trx_0.5-1.html [2] https://salsa.debian.org/debian/trx Cheers Kyle -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ https://wiki.debian.org/KyleRobbertze
Bug#952408: fontforge: no longer works in non-GUI environment
tags 952408 patch
forwarded 952408 https://github.com/fontforge/fontforge/issues/4203
thanks
On Sun, Feb 23, 2020 at 09:28:55PM +, Julian Gilbey wrote:
> [...]
> Up until a relatively recent release of fontforge, if fontforge were
> run from a script without a GUI present, it would behave exactly like
> the non-GUI version. But this release breaks this behaviour: even
> running 'fontforge --help' bombs out with the error message:
> [...]
The current upstream version has fixed this (see the above URL). The
relevant patch backported to the current Debian version is attached.
Best wishes,
Julian
--- a/fontforgeexe/startui.c
+++ b/fontforgeexe/startui.c
@@ -1099,10 +1099,6 @@
CheckIsScript(argc,argv); /* Will run the script and exit if it is a
script */
/* If there is no UI, there is always a
script */
/* and we will never return from the
above */
-#ifdef FONTFORGE_CAN_USE_GDK
-gdk_init(, );
-gdk_set_allowed_backends("win32,quartz,x11");
-#endif
if ( load_prefs==NULL ||
(strcasecmp(load_prefs,"Always")!=0 && /* Already loaded */
strcasecmp(load_prefs,"Never")!=0 ))
@@ -1185,6 +1181,10 @@
}
#endif
}
+#ifdef FONTFORGE_CAN_USE_GDK
+gdk_init(, );
+gdk_set_allowed_backends("win32,quartz,x11");
+#endif
ensureDotFontForgeIsSetup();
#if defined(__MINGW32__) && !defined(_NO_LIBCAIRO)
Bug#953079: fontforge: FTBFS: builds with Python 2.7 by default if it is present and build then fails
Package: fontforge Version: 1:20190801~dfsg-2 Severity: serious Tags: patch The configure script prefers Python 2.7 over Python 3.x by default. This then leads to a build failure as the shlib symbols in debian/libfontforge3.symbols do not match the symbols in the compiled libfontforge3. The easy solution is to change the line in debian/rules which reads --enable-python-scripting \ to read --enable-python-scripting=3 \ (This is tested and it appears to work.) Best wishes, Julian
Bug#953078: libvirt: CVE-2019-20485
Source: libvirt Version: 5.6.0-3 Severity: important Tags: security upstream fixed-upstream Control: found -1 5.6.0-2 Control: fixed -1 6.0.0-1 Hi, The following vulnerability was published for libvirt. CVE-2019-20485[0]: | potential DoS by holding a monitor job while querying QEMU guest-agent If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-20485 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20485 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1809740 [2] https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=a663a860819287e041c3de672aad1d8543098ecc Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#949584: mmdebstrap fails to create temp file if TMPDIR is set to directory with mode 0755
Hi, Quoting Benjamin Drung (2020-03-03 17:05:44) > Am Mittwoch, den 22.01.2020, 21:40 +0100 schrieb Johannes Schauer: > > Quoting Benjamin Drung (2020-01-22 13:23:36) > > > Am Mittwoch, den 22.01.2020, 13:13 +0100 schrieb Johannes Schauer: > > > > Quoting Benjamin Drung (2020-01-22 12:58:38) > > > > > when I set TMPDIR to a directory that has mode 0755, mmdebstrap > > > > > will fail: > > > > > > > > > > ``` > > > > > $ ls -ld . > > > > > drwxr-xr-x 3 bdrung bdrung 80 Jan 22 12:43 . > > > > > $ TMPDIR=$(pwd) mmdebstrap buster buster.tar.xz > > > > > I: automatically chosen mode: unshare > > > > > > > > you are using the unshare mode. This means that your temporary > > > > directory needs > > > > to be accessible by the unshared user. Evidently it is not. I > > > > don't > > > > think there > > > > is anything that mmdebstrap can do about it. > > > > > > mmdebstrap could create a temporary directory, change the mode to > > > 1777 and > > > let unshare use that, couldn't it? > > > > but that's not where the error comes from. From the output you posted > > in your > > report it seems like mmdebstrap is not able to create the temporary > > directory > > at all. Obviously it cannot change permissions of something that > > doesn't exist. > > I don't think mmdebstrap should attempt touching the permissions of > > the $TMPDIR > > directory. > > From the log from the initial report: > > I: using /tmpfs/foo/mmdebstrap.wYxMFPcZHA as tempdir > > This directory is created and owned by unshared user. Afterwards > mmdebstrap tries to create another temporary directory in /tmpfs/foo > (instead of /tmpfs/foo/mmdebstrap.wYxMFPcZHA) and fails. > > I expect that mmdebstrap would succeed if it would create additional > temporary directories in that initial /tmpfs/foo/mmdebstrap.wYxMFPcZHA > directory. ah, now I understood what you mean. The proper solution would not be to change its mode to 1777 but to change its owner to the unshared user in the same way as it is done for /tmpfs/foo/mmdebstrap.wYxMFPcZHA in your example. But there is a simpler way. The only time that a temporary file is created as the unshare user is when the temporary apt.conf is created. That file could just be created in /tmpfs/foo/mmdebstrap.wYxMFPcZHA/tmp/ and the problem would be solved. The only thing that still puzzles me is the output you pasted. If it was really the apt.conf failing, then the error should be "cannot open apt.conf: ..." but that's not in your output. I'm also puzzled by your line number 1178 as that line has nothing useful over here. Thanks! cheers, josch signature.asc Description: signature
Bug#953077: adequate informs obsolete-conffile for mate-settings-daemon when it upgrades it
Package: mate-settings-daemon Version: 1.24.0-2 Severity: normal User: debian...@lists.debian.org Usertags : obsolete-conffile@adequate Dear Maintainer, I got the following obsolete-conffile complaint by adequate while upgrading. Please fix the same - mate-settings-daemon: obsolete-conffile /etc/dbus-1/system.d/org.mate.SettingsDaemon.DateTimeMechanism.conf -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-debug'), (100, 'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mate-settings-daemon depends on: ii libc62.29-10 ii libcairo21.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libdbus-1-3 1.12.16-2 ii libdbus-glib-1-2 0.110-5 ii libdconf10.34.0-2 ii libfontconfig1 2.13.1-2+b1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-2 ii libglib2.0-0 2.62.5-1 ii libgtk-3-0 3.24.13-1 ii libmate-desktop-2-17 1.24.0-2 ii libmatekbd4 1.24.0-1 ii libmatemixer01.24.0-1 ii libnotify4 0.7.9-1 ii libnspr4 2:4.24-1 ii libnss3 2:3.49.1-1 ii libpolkit-gobject-1-00.105-26 ii libpulse013.0-5 ii librda0 0.0.5-1 ii libx11-6 2:1.6.9-2 ii libxi6 2:1.7.9-1 ii libxklavier165.4-4 ii mate-desktop-common 1.24.0-2 ii mate-polkit 1.24.0-2 ii mate-settings-daemon-common 1.24.0-2 ii x11-xserver-utils7.7+8 mate-settings-daemon recommends no packages. mate-settings-daemon suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#953076: unace: goes into endless loop when stdin is /dev/null
Package: unace Version: 1.2b-17 Severity: normal Dear Maintainer, unace goes into an endless loop when stdin is /dev/null, for example, when using xargs:; unace t x.ace
Bug#952742: mumble: start locks sound for all application (even the client itself)
severity 952742 important tags 952742 + moreinfo unreproducible thanks lemmel: > Package: mumble > Version: 1.3.0+dfsg-1+b1 > Severity: grave > Tags: upstream > Justification: renders package unusable > > Dear Maintainer, > > fresh dist-upgrade (this day 02/28/20) brought up a mumble that lock all sound > on the host, the mumble client itself producing no sound. > > I did all kind of setup with the mumble client (OSS, ALSA, etc), but it did > nothing. I upgraded a VM running native Sid + Buster and did a full upgrade, and found audio with Mumble 1.3.0+dfsg-1+b1 via pulseaudio worked fine. I tried using ALSA with Mumble, and was not able to get that to work with the "[default] Playback/recording through the PulseAudio sound server" setting, and haven't tried further settings (yet). I tried OSS with Mumble and was not able to get that to work, but that didn't surprise me. Concerning Debian Sid/Unstable, my understanding is that it is not a complete distribution, and so Unstable is meant to be run as Unstable + Stable, i.e. Sid + Buster. Looking at the distributions you're currently using I see it's Unstable + Testing, i.e. Sid + Bullseye. I'm not sure if that may explain this bug or not; I may try to take a VM snapshot and upgrade to Sid + Bullseye and see if I can get the audio in Mumble to crap out. But for now I'm marking the severity of this bug as "important" rather than "grave" because as best I can tell it's broken on your system but not others. [If other users hit this bug when running Sid + Buster, please report that to this bug.] It's also possible this might be AppArmor related, because Mumble doesn't ship an AppArmor profile at the moment, and I see you've got AppArmor enabled. [...] > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled The best place I know to get more helpful advice in tracking down the audio difficulty is the #mumble IRC channel on irc.freenode.net. There are users in the IRC channel that regularly help with PulseAudio issues. Similar to your experience, for me PulseAudio is mostly a "magic" thing which I tweak a bunch to get what I need if I find I need something specific. I'll try to be more help if I can. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#953075: debian-reference: Incorrect environment example for 'date' in section 1.5.2
Package: debian-reference Version: 2.76 Severity: minor Dear Maintainer, In section 1.5.2, The "$LANG" variable, one of the examples given, showing how to pass an environement variable to a shell command, doesn't work as expected. The example looks like: $ date Sun Jun 3 10:27:39 JST 2007 $ LANG=fr_FR.UTF-8 date dimanche 3 juin 2007, 10:27:33 (UTC+0900) but when I run it on my own system, I see the following (note that on my system, LANG=en_CA.UTF-8 and all LC_* environment variables are the same): $ date Tue Mar 3 21:56:39 EST 2020 $ LANG=fr_CA.UTF-8 date Tue Mar 3 21:56:58 EST 2020 Note that output in both cases in identical. The man page for date clearly says that date relies on LC_TIME and this works as expected: $ LC_TIME=fr_CA.UTF-8 date mardi 3 mars 2020, 22:00:45 (UTC-0500) Something in this section needs to be updated to reflect this. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.13-sunvillage (SMP w/8 CPU cores; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA.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 debian-reference depends on: ii debian-reference-en 2.76 Versions of packages debian-reference recommends: pn debian-reference-de pn debian-reference-es pn debian-reference-fr pn debian-reference-it pn debian-reference-ja pn debian-reference-pt pn debian-reference-zh-cn pn debian-reference-zh-tw debian-reference suggests no packages. -- no debconf information
Bug#953074: python3-twisted: conch/client/knownhosts.py:492: SyntaxWarning: "is" with a literal. Did you mean "=="?
Package: python3-twisted Version: 18.9.0-6 Severity: normal File: /usr/lib/python3/dist-packages/twisted/conch/client/knownhosts.py Usertag: warnings I got a warning from Python when upgrading python3-twisted recently: Setting up python3-twisted (18.9.0-6) ... /usr/lib/python3/dist-packages/twisted/conch/client/knownhosts.py:492: SyntaxWarning: "is" with a literal. Did you mean "=="? if keytype is "EC": -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (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 python3-twisted depends on: ii python3 3.7.5-3 ii python3-attr 19.3.0-1 ii python3-automat 0.6.0-1 ii python3-constantly15.1.0-1 ii python3-hamcrest 1.9.0-2 ii python3-hyperlink 19.0.0-1 ii python3-idna 2.6-2 ii python3-incremental 16.10.1-3.1 ii python3-openssl 19.0.0-1 ii python3-service-identity 18.1.0-5 ii python3-twisted-bin 18.9.0-6 ii python3-zope.interface4.7.1-1 python3-twisted recommends no packages. Versions of packages python3-twisted suggests: pn python3-glade2 pn python3-gtk2 pn python3-pampy pn python3-qt4 pn python3-serial ii python3-tk3.8.0-1 pn python3-wxgtk2.8 -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#953073: texlive-fonts-extra: TwemojiMozilla.ttf is included in 4 Debian packages
Package: texlive-fonts-extra Version: 2019.202000302-1 Severity: wishlist User: pkg-fonts-de...@lists.alioth.debian.org Usertags: duplicate Dear Maintainer, Seaching TwemojiMozilla.ttf for Debian unstable packages by https://packages.debian.org shows that it is included in firefox-esr firefox thunderbird texlive-fonts-extra Best regards, Ryutaroh Matsumoto -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. *** The Debian TeX Team is *not* a LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) or http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files lrwxrwxrwx 1 root root 31 Feb 18 07:37 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 475 Mar 4 10:28 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Feb 18 07:37 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN lrwxrwxrwx 1 root root 32 Feb 18 07:37 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 2763 Mar 4 10:28 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Dec 3 19:04 mktex.cnf -rw-r--r-- 1 root root 475 Mar 4 10:28 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-40-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-fonts-extra depends on: ii tex-common6.13 ii texlive-base 2019.20200218-1 Versions of packages texlive-fonts-extra recommends: pn fonts-adf-accanthis pn fonts-adf-berenis pn fonts-adf-gillius pn fonts-adf-universalis pn fonts-cabin pn fonts-cantarell pn fonts-comfortaa pn fonts-croscore pn fonts-crosextra-caladea pn fonts-crosextra-carlito ii fonts-dejavu-core 2.37-1 pn fonts-dejavu-extra pn fonts-ebgaramond pn fonts-ebgaramond-extra pn fonts-font-awesome pn fonts-freefont-otf pn fonts-freefont-ttf pn fonts-gfs-artemisia pn fonts-gfs-complutum pn fonts-gfs-didot pn fonts-gfs-neohellenic pn fonts-gfs-olga pn fonts-gfs-solomos pn fonts-go pn fonts-junicode pn fonts-lato pn fonts-linuxlibertine pn fonts-lobstertwo pn fonts-noto-core pn fonts-noto-mono pn fonts-oflb-asana-math pn fonts-open-sans pn fonts-roboto-unhinted pn fonts-sil-gentium pn fonts-sil-gentium-basic pn fonts-sil-gentiumplus pn fonts-sil-gentiumplus-compact pn fonts-stix pn texlive-fonts-extra-links pn texlive-fonts-recommended pn texlive-latex-extra
Bug#953072: texlive-fonts-extra: NotoColorEmoji.ttf is included in 3 Debian packages
Package: texlive-fonts-extra Version: 2019.202000302-1 Severity: minor User: pkg-fonts-de...@lists.alioth.debian.org Usertags: duplicate Dear Maintainer, Seaching NotoColorEmoji.ttf for Debian unstable packages by https://packages.debian.org shows that it is included in fonts-noto-color-emoji supertuxkart-data texlive-fonts-extra In addition, texlive-fonts-extra has newer version of NotoColorEmoji.ttf than fonts-noto-color-emoji, thus just making symlink to fonts-noto-color-emoji does not solve this font dupulication. See also https://wiki.debian.org/Fonts/Bugs/duplicate Best regards, Ryutaroh Matsumoto -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. *** The Debian TeX Team is *not* a LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) or http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files lrwxrwxrwx 1 root root 31 Feb 18 07:37 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 475 Mar 4 10:28 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Feb 18 07:37 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN lrwxrwxrwx 1 root root 32 Feb 18 07:37 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 2763 Mar 4 10:28 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Dec 3 19:04 mktex.cnf -rw-r--r-- 1 root root 475 Mar 4 10:28 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-40-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-fonts-extra depends on: ii tex-common6.13 ii texlive-base 2019.20200218-1 Versions of packages texlive-fonts-extra recommends: pn fonts-adf-accanthis pn fonts-adf-berenis pn fonts-adf-gillius pn fonts-adf-universalis pn fonts-cabin pn fonts-cantarell pn fonts-comfortaa pn fonts-croscore pn fonts-crosextra-caladea pn fonts-crosextra-carlito ii fonts-dejavu-core 2.37-1 pn fonts-dejavu-extra pn fonts-ebgaramond pn fonts-ebgaramond-extra pn fonts-font-awesome pn fonts-freefont-otf pn fonts-freefont-ttf pn fonts-gfs-artemisia pn fonts-gfs-complutum pn fonts-gfs-didot pn fonts-gfs-neohellenic pn fonts-gfs-olga pn fonts-gfs-solomos pn fonts-go pn fonts-junicode pn fonts-lato pn fonts-linuxlibertine pn fonts-lobstertwo pn fonts-noto-core pn fonts-noto-mono pn fonts-oflb-asana-math pn fonts-open-sans pn fonts-roboto-unhinted pn fonts-sil-gentium
Bug#953071: ndisc6: please make the build reproducible
Source: ndisc6 Version: 1.0.4-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0] we noticed that ndisc6 could not be built reproducibly. This is because it includes the CFLAGS used to build the package in the binary via PACKAGE_CONFIGURE_INVOCATION which then includes the absolute build path via (eg.) the -ffile-prefix-map flag. I see you already patch out the hostname, etc. and you could follow this approach and remove the CFLAGS too, but just in case they might be useful I've attached a patch that strips out the -fdebug-prefix-map (etc.) calls instead. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/reproducible-build2.patch 1969-12-31 16:00:00.0 -0800 --- b/debian/patches/reproducible-build2.patch 2020-03-03 17:44:08.283963589 -0800 @@ -0,0 +1,15 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2020-03-03 + +--- ndisc6-1.0.4.orig/configure.ac ndisc6-1.0.4/configure.ac +@@ -21,7 +21,7 @@ dnl + AC_COPYRIGHT([Copyright (C) 2005-2016 Remi Denis-Courmont]) + AC_INIT(ndisc6, 1.0.4, remi_no_bulk_m...@remlab.net) + AC_PREREQ(2.62) +-INVOCATION="`echo "$0 $ac_configure_args" | sed -e 's/\\\/\\\/g'`" ++INVOCATION="`echo "$0 $ac_configure_args" | sed -e 's/\\\/\\\/g' -e 's@ [[^ ]]*-f\(file\|debug\)-prefix-map=[[^ ]]*@@g'`" + + AS_MESSAGE(checking system...) + AC_CONFIG_SRCDIR(configure.ac) --- a/debian/patches/series 2020-03-03 17:27:41.254772042 -0800 --- b/debian/patches/series 2020-03-03 17:38:05.811926815 -0800 @@ -1,2 +1,3 @@ resolvconf-rdnssd-hook.patch reproducible-build.patch +reproducible-build2.patch
Bug#953070: RFP: source-to-image -- toolkit for building reproducible container images from source code
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: source-to-image Version : 1.2.0 Upstream Author : Various * URL : https://github.com/openshift/source-to-image * License : Apache 2.0 Programming Lang: Go Description : toolkit for building reproducible container images from source code Source-to-Image (S2I) S2I produces ready-to-run images by injecting source code into a container image and letting the container prepare that source code for execution. By creating self-assembling builder images, you can version and control your build environments exactly like you use container images to version your runtime environments. -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl5fAmwSHHNhbUByb2Jv dHMub3JnLnVrAAoJENILQgJc2ie5Qj4P+gO9RW6HwqDIewsik99hWGMHN8C55ue0 AhH5dHLJRvAYW7R+0b279tJRbRDJwqYKCYubDNwBHYM8rw+dF+jbQwxJTDocb/GG zgz0UEYGoak2+YNVCynAFKbJ/OwOA+WUq9Dssp0SU1kcifTuZQtRFImwSOAIhxMm 3sediKtS41bpoFBML4CZ7MG6BxJ/e/uUgvxFep/G9SLAWbP98XolEmBLPmbFIqJg K8JH2TNGJQQ/MXP1FTMVl9RXPGuBSP6roxMQM4hgoxLeqHbMYnoB1OmNI6Xgb12a RDrrhK60l3HQsnj0sYtWIioPqIH/bcpOKvZZZhp3VR2MoT+z2iVrxYh9BFHQjzQw d4epcPBf8UEkl6FTZyFWYtIWLJA51w6FbswgZ7BWGojsRbM5lkY3FPAEnzVGKKji oz+qHZ8gqzZWxqlY27t2k9LzMkbG7r4LjnfO1avcZsAubRlSLyFRKFrw0qRvV37H WyXPSGnXIg8NyTk3St9EP7tNWX04nfD2eJwVe+r0wokIj2YZCvXf9rxSBXWNz3sZ gh38Kh0MpDeLReFsnloOSAm5oaYgdymTu+PrUPWJ/CW1uI/bFktGohLU8lYD6Lju Yt/ktyc/QGmE2w8FzRkKrkqZrSX53PfSvoXX3E7j+15FokBjME0zn61/pKUs+T8w QiBq0EYHAr4v =MiI4 -END PGP SIGNATURE-
Bug#933425: sooperlooper: Please rebuild against wxWidgets GTK 3 package
Package: sooperlooper Followup-For: Bug #933425 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu focal ubuntu-patch I've confirmed that sooperlooper can build against gtk3 with a one-line change to the build-dependencies. Please see attached. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru sooperlooper-1.7.3~dfsg0/debian/control sooperlooper-1.7.3~dfsg0/debian/control --- sooperlooper-1.7.3~dfsg0/debian/control 2020-03-03 16:49:44.0 -0800 +++ sooperlooper-1.7.3~dfsg0/debian/control 2020-03-03 17:00:41.0 -0800 @@ -17,7 +17,7 @@ libsamplerate-dev, libsigc++-2.0-dev (>= 2.2.10), libsndfile1-dev, - libwxgtk3.0-dev, + libwxgtk3.0-gtk3-dev, libxml2-dev Standards-Version: 3.9.8 Homepage: http://www.essej.net/sooperlooper/
Bug#953067: (no subject)
The JFrame children should be available for garbage collection and garbage collected after the JFrames are closed.
Bug#953069: libgnatcoll-db: FTBFS on mipsel with assembler message: branch out of range
Source: libgnatcoll-db Version: 19.2-2 Severity: normal The relevant lines are: xref/gnatcoll-xref.adb: In function ‘GNATCOLL.XREF’: xref/gnatcoll-xref.adb:40:1: note: variable tracking size limit exceeded with ‘-fvar-tracking-assignments’, retrying without Assembler messages: 678119: Error: branch out of range
Bug#946572: abcm2ps: diff for NMU version 8.14.7-0.1
Dear maintainer,
New upstream version 8.14.7 includes Helmut's fix for #946572.
Please update the package, or allow the attached trivial NMU.
Thanks.
diff -Nru abcm2ps-8.14.6/abcm2ps.h abcm2ps-8.14.7/abcm2ps.h
--- abcm2ps-8.14.6/abcm2ps.h 2019-11-05 14:02:00.0 +0100
+++ abcm2ps-8.14.7/abcm2ps.h 2020-02-19 14:00:51.0 +0100
@@ -524,7 +524,7 @@
float topspace, wordsspace, titlespace, subtitlespace, partsspace;
float composerspace, musicspace, vocalspace, textspace;
float breaklimit, maxshrink, lineskipfac, parskipfac, stemheight;
- float gutter, indent, infospace, slurheight, notespacingfactor, scale;
+ float gutter, indent, infospace, slurheight, tieheight, notespacingfactor, scale;
float staffsep, sysstaffsep, maxstaffsep, maxsysstaffsep, stretchlast;
int abc2pscompat, alignbars, aligncomposer, autoclef;
int barsperstaff, breakoneoln, bstemdown, cancelkey, capo;
diff -Nru abcm2ps-8.14.6/abcparse.c abcm2ps-8.14.7/abcparse.c
--- abcm2ps-8.14.6/abcparse.c 2019-11-05 14:02:00.0 +0100
+++ abcm2ps-8.14.7/abcparse.c 2020-02-19 14:00:51.0 +0100
@@ -3,7 +3,7 @@
*
* This file is part of abcm2ps.
*
- * Copyright (C) 1998-2019 Jean-François Moine (http://moinejf.free.fr)
+ * Copyright (C) 1998-2020 Jean-François Moine (http://moinejf.free.fr)
* Adapted from abc2ps, Copyright (C) 1996-1998 Michael Methfessel
*
* This program is free software; you can redistribute it and/or modify it
@@ -1794,6 +1794,7 @@
int *p_len)
{
int len, fac;
+ int err = 0;
char *q;
len = dur_u;
@@ -1801,27 +1802,33 @@
len *= strtol(p, , 10);
if (len <= 0) {
syntax("Bad length", p);
- len = BASE_LEN;
+ len = dur_u;
}
p = q;
}
- fac = 1;
- while (*p == '/') {
- p++;
- if (isdigit((unsigned char) *p)) {
- fac *= strtol(p, , 10);
- if (fac == 0) {
-syntax("Bad length divisor", p - 1);
-fac = 1;
- }
- p = q;
- } else {
- fac *= 2;
+ if (*p != '/') {
+ *p_len = len;
+ return p;
+ }
+ if (isdigit((unsigned char) p[1])) {
+ fac = strtol(p + 1, , 10);
+ p = q;
+ if (fac == 0 || (fac & (fac - 1)))
+ err = 1;
+ else
+ len /= fac;
+ } else {
+ while (*p == '/') {
+ if (len & 1)
+err = 1;
+ len /= 2;
+ p++;
}
}
- if (len % fac)
+ if (err || !len) {
syntax("Bad length divisor", p - 1);
- len /= fac;
+ len = dur_u;
+ }
*p_len = len;
return p;
}
@@ -2037,6 +2044,8 @@
case CHAR_SLASH: /* '/' */
if (flags & ABC_F_GRACE)
goto bad_char;
+ if (char_tb[(unsigned char) p[-1]] != CHAR_BAR)
+goto bad_char;
q = p;
while (*q == '/')
q++;
@@ -2332,7 +2341,7 @@
len = 1;
if (isdigit((unsigned char) *p)) {
len = strtol(p, , 10);
- if (len == 0 && len > 100) {
+ if (len == 0 || len > 100) {
syntax("Bad number of measures", p);
len = 1;
}
diff -Nru abcm2ps-8.14.6/configure abcm2ps-8.14.7/configure
--- abcm2ps-8.14.6/configure 2019-11-05 14:02:00.0 +0100
+++ abcm2ps-8.14.7/configure 2020-02-19 14:00:51.0 +0100
@@ -1,10 +1,11 @@
#! /bin/sh
# (automatic update)
-VERSION=8.14.6
-VDATE=2019-11-05
+VERSION=8.14.7
+VDATE=2020-02-19
CC=gcc
+PKG_CONFIG=pkg-config
CFLAGS="-g -O2 -Wall -pipe"
srcdir=.
@@ -57,11 +58,11 @@
DEFAULT_FDIR="$prefix/share/abcm2ps"
fi
-if which pkg-config > /dev/null ; then
- if pkg-config --exists freetype2 ; then
- if pkg-config --exists pangocairo ; then
- CPPFLAGS="$CPPFLAGS -DHAVE_PANGO=1 `pkg-config pango cairo freetype2 --cflags`"
- LDLIBS="$LDLIBS `pkg-config pangocairo pangoft2 freetype2 --libs`"
+if which $PKG_CONFIG > /dev/null ; then
+ if $PKG_CONFIG --exists freetype2 ; then
+ if $PKG_CONFIG --exists pangocairo ; then
+ CPPFLAGS="$CPPFLAGS -DHAVE_PANGO=1 `$PKG_CONFIG pango cairo freetype2 --cflags`"
+ LDLIBS="$LDLIBS `$PKG_CONFIG pangocairo pangoft2 freetype2 --libs`"
else
echo "pangocairo not found - no pango support"
fi
diff -Nru abcm2ps-8.14.6/debian/changelog abcm2ps-8.14.7/debian/changelog
--- abcm2ps-8.14.6/debian/changelog 2019-12-10 11:43:53.0 +0100
+++ abcm2ps-8.14.7/debian/changelog 2020-03-04 01:30:55.0 +0100
@@ -1,3 +1,11 @@
+abcm2ps (8.14.7-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * New upstream release closes: #946572.
+ * Standards-Version: 4.5.0.
+
+ -- Nicolas Boulenguez Wed, 04 Mar 2020 01:30:55 +0100
+
abcm2ps (8.14.6-0.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru abcm2ps-8.14.6/debian/control abcm2ps-8.14.7/debian/control
--- abcm2ps-8.14.6/debian/control 2019-12-10 11:43:53.0 +0100
+++ abcm2ps-8.14.7/debian/control 2020-03-04 01:30:55.0 +0100
@@ -8,7 +8,7 @@
libpango1.0-dev,
pkg-config,
python3-docutils,
-Standards-Version: 4.4.1
+Standards-Version: 4.5.0
Rules-Requires-Root: no
Homepage: http://moinejf.free.fr/
diff -Nru abcm2ps-8.14.6/debian/copyright abcm2ps-8.14.7/debian/copyright
--- abcm2ps-8.14.6/debian/copyright 2019-11-09 09:25:03.0 +0100
+++
Bug#950716: transition: ruby2.7
Am Montag, den 02.03.2020, 15:01 -0300 schrieb Lucas Kanashiro: > On 02/03/2020 08:35, Graham Inggs wrote: > > Hi Lucas > > > > I notice kamailio and klayout still appear red in the Debian tracker > > [1], but went green in Ubuntu [2]. > > > > Do you have any ideas? Do we miss something in Debian? > > Since we basically have the same version in Debian and Ubuntu I believe > the only difference is that in Ubuntu we already have Ruby 2.7 as the > only default, in Debian it is just in experimental. So when we upload > version 1:2.7~0 to unstable they should get green as in Ubuntu. Can yóu please schedule a rebuild of facter too? At least three FTBFS reports are caused by factor only providing the Ruby2.5 library (#952024, #952022, #952070). I cannot upload the fixed packages. If this is not the right place, please let me know. Regarding this issue: should the ben file include sources build-depending on ruby-all-dev? $ reverse-depends -lb ruby-all-dev broccoli-ruby facter gem2deb libprelude ruby-ffi ruby-pgplot rubygems-integration sonic-pi uwsgi xapian-bindings Regards, Daniel signature.asc Description: This is a digitally signed message part
Bug#953068: bossa: patch to initialize variables (needed when building with -O3)
Package: bossa
Version: 1.9.1-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch
Hi Scott,
In Ubuntu, the latest version of bossa has failed to build on ppc64el
because the ppc64el architecture in Ubuntu uses -O3 as a default
optimization, which exposes a number of uninitialized variables in the code.
In reality none of these variables are used uninitialized, but the compiler
can't /prove/ that, so it errors out.
The attached patch fixes this issue by adding initializers to the various
variables, and has been uploaded to Ubuntu. Please consider including this
patch in Debian, and/or forwarding it to upstream.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru bossa-1.9.1/debian/patches/no-uninitialized-variables.patch
bossa-1.9.1/debian/patches/no-uninitialized-variables.patch
--- bossa-1.9.1/debian/patches/no-uninitialized-variables.patch 1969-12-31
16:00:00.0 -0800
+++ bossa-1.9.1/debian/patches/no-uninitialized-variables.patch 2020-03-03
16:11:50.0 -0800
@@ -0,0 +1,151 @@
+Description: ensure all variables are provably initialized before use.
+ When compiling with gcc -O3 (as on Ubuntu ppc64el), the compiler notices
+ a number of variables do not have initializers. While these variables are
+ passed by reference to functions that we know are going to initialize them
+ on success, we add various initializers here anyway to make the compiler
+ happy.
+Author: Steve Langasek
+Last-Update: 2020-03-03
+
+Index: bossa-1.9.1/src/Command.cpp
+===
+--- bossa-1.9.1.orig/src/Command.cpp
bossa-1.9.1/src/Command.cpp
+@@ -293,7 +293,7 @@ CommandBod::CommandBod() :
+ void
+ CommandBod::invoke(char* argv[], int argc)
+ {
+-bool value;
++bool value = false;
+
+ if (!argNum(argc, 2) ||
+ !argBool(argv[1], ) ||
+@@ -320,7 +320,7 @@ CommandBootf::CommandBootf() :
+ void
+ CommandBootf::invoke(char* argv[], int argc)
+ {
+-bool value;
++bool value = false;
+
+ if (!argNum(argc, 2) ||
+ !argBool(argv[1], ) ||
+@@ -341,7 +341,7 @@ CommandBor::CommandBor() :
+ void
+ CommandBor::invoke(char* argv[], int argc)
+ {
+-bool value;
++bool value = false;
+
+ if (!argNum(argc, 2) ||
+ !argBool(argv[1], ) ||
+@@ -393,7 +393,7 @@ CommandDebug::CommandDebug() :
+ void
+ CommandDebug::invoke(char* argv[], int argc)
+ {
+-bool state;
++bool state = false;
+
+ if (!argNum(argc, 2) ||
+ !argState(argv[1], ))
+@@ -413,8 +413,8 @@ CommandDump::CommandDump() :
+ void
+ CommandDump::invoke(char* argv[], int argc)
+ {
+-uint32_t addr;
+-uint32_t count;
++uint32_t addr = 0;
++uint32_t count = 0;
+
+ if (!argNum(argc, 3) ||
+ !argUint32(argv[1], ) ||
+@@ -483,7 +483,7 @@ CommandGo::CommandGo() :
+ void
+ CommandGo::invoke(char* argv[], int argc)
+ {
+-uint32_t addr;
++uint32_t addr = 0;
+
+ if (!argNum(argc, 2) ||
+ !argUint32(argv[1], ) ||
+@@ -588,7 +588,7 @@ CommandMrb::CommandMrb() :
+ void
+ CommandMrb::invoke(char* argv[], int argc)
+ {
+-uint32_t addr;
++uint32_t addr = 0;
+ uint32_t count = 1;
+ uint8_t value;
+
+@@ -619,8 +619,8 @@ CommandMrf::CommandMrf() :
+ void
+ CommandMrf::invoke(char* argv[], int argc)
+ {
+-uint32_t addr;
+-uint32_t count;
++uint32_t addr = 0;
++uint32_t count = 0;
+ FILE* infile;
+ uint8_t buf[1024];
+ ssize_t fbytes;
+@@ -669,7 +669,7 @@ CommandMrw::CommandMrw() :
+ void
+ CommandMrw::invoke(char* argv[], int argc)
+ {
+-uint32_t addr;
++uint32_t addr = 0;
+ uint32_t count = 1;
+ uint32_t value;
+
+@@ -700,7 +700,7 @@ CommandMwb::CommandMwb() :
+ void
+ CommandMwb::invoke(char* argv[], int argc)
+ {
+-uint32_t addr;
++uint32_t addr = 0;
+ uint32_t value;
+
+ if (!argRange(argc, 2, 3) ||
+@@ -803,8 +803,8 @@ CommandMww::CommandMww() :
+ void
+ CommandMww::invoke(char* argv[], int argc)
+ {
+-uint32_t addr;
+-uint32_t value;
++uint32_t addr = 0;
++uint32_t value = 0;
+
+ if (!argRange(argc, 2, 3) ||
+ !argUint32(argv[1], ) ||
+@@ -874,11 +874,9 @@ CommandPio::invoke(char* argv[], int arg
+ return;
+ }
+
+-if (argv[1][2] == '\0')
+-{
+-line = 0x;
+-}
+-else
++line = 0x;
++
++if (argv[1][2] != '\0')
+ {
+ if (!argUint32([1][2], ))
+ return;
+@@ -1062,7 +1060,7 @@ CommandPio::invoke(char* argv[], int arg
+ }
+ else if (strncasecmp(argv[2], "pullup", len) == 0)
+ {
+-bool state;
++bool state = false;
+ if (!argNum(argc, 4) ||
+
Bug#953067: openjdk-8-jre: JFrame is not garbage collected.
Package: openjdk-8-jre
Version: 8u242-b08-1~deb9u1
Severity: important
Dear Maintainer,
Run the following:
import java.awt.Frame;
import java.awt.event.*;
import javax.swing.*;
public class Testing extends JFrame {
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
final JFrame parent = new JFrame("Parent");
JButton add = new JButton("New JFrame");
add.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
final JFrame child = new JFrame("Child");
child.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
child.setSize(300, 300);
child.setVisible(true);
}
});
parent.add(add);
parent.pack();
parent.setVisible(true);
}
});
}
}
i.e..
javac Testing.java
java Testing
(observe processid)
jmap histo:live processid | grep JFrame (observe the number of JFrame instances)
Exercise the JButton.
Required behaviour: JFrame instances are garbage collected.
Observed behaviour: JFrame instances are never garbage collected
(openjdk-8/debian 9)
Observed behaviour: JFrame instances are garbage collected (openjdk-11/debian
10).
-- System Information:
Debian Release: 9.12
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-12-amd64 (SMP w/2 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)
Versions of packages openjdk-8-jre depends on:
ii libasound21.1.3-5
ii libatk-wrapper-java-jni 0.33.3-13+deb9u1
ii libc6 2.24-11+deb9u4
ii libgif7 5.1.4-0.4
ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2
ii libglib2.0-0 2.50.3-2+deb9u2
ii libgtk2.0-0 2.24.31-2
ii libjpeg62-turbo 1:1.5.1-2
ii libpng16-16 1.6.28-1+deb9u1
ii libpulse0 10.0-1+deb9u1
ii libx11-6 2:1.6.4-3+deb9u1
ii libxext6 2:1.3.3-1+b2
ii libxinerama1 2:1.1.3-1+b3
ii libxrandr22:1.5.1-1
ii openjdk-8-jre-headless8u242-b08-1~deb9u1
ii zlib1g1:1.2.8.dfsg-5
Versions of packages openjdk-8-jre recommends:
ii fonts-dejavu-extra 2.37-1
Versions of packages openjdk-8-jre suggests:
pn icedtea-8-plugin
-- no debconf information
Bug#953062: FTBFS on arm64, armel, armhf, ppc64el, s390x
arm64 and s390x (and maybe ppc64el?) are all an issue with signed char conversions. I have a patch to fix that in my git repo, along with other fixes that effectively block further usage (dfsg, etc): https://salsa.debian.org/rpavlik-guest/meshlab/-/commit/2631636f29b7375a1d7977a1484b826db55ba153 armel and armhf: these platforms only have OpenGL-ES, not desktop OpenGL, so the correct thing to do is to disable this package on those platforms. Is there a better way to do this than to list all other platforms in the control file? Ryan On 3/3/20 4:08 PM, Moritz Muehlenhoff wrote: > Package: meshlab > Severity: serious > > The new meshlab FTBFSes on arm64, armel, armhf, ppc64el, s390x. > > This also means that on those archs meshlab still uses Qt4. > > Cheers, > Moritz > signature.asc Description: OpenPGP digital signature
Bug#951209: transition: libgusb
On Tue, 3 Mar 2020 20:19:12 +0100 Julien Cristau wrote: > On Wed, Feb 12, 2020 at 03:24:42PM +0100, Laurent Bigonville wrote: > > libgusb is carrying in debian a patch[0] to revert/fix an after the fact > > change that was done upstream in the versioning of the symbols. > > > > I don't think we should/can carry this patch forever and due to the fact > > that the number of reverse-dependencies is quite limited, I was planning > > to simply drop it, but that would require to binNMU them to be > > certain they are using the correct version of the symbol. > > > IMO we should keep compatibility with the old version until the next > upstream SONAME bump. That might mean keeping this patch, or something > different, if we can add properly versioned aliases for the affected > symbols? I'm not exactly sure how to do that TBH FTR, a more persistent link to the file was talking about in my initial mail https://salsa.debian.org/debian/libgusb/-/blob/80d3862872ff72b9cf10c90959973baf9755c7e9/debian/patches/revert-versioning.patch
Bug#953066: libpciaccess0: nVidia driver finds no devices, sddm dies with ABRT
Package: libpciaccess0
Version: 0.13.4-1+b2
Severity: important
-- System Information:
Debian Release: 9.12
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-0.bpo.6-amd64 (SMP w/40 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libpciaccess0 depends on:
ii libc6 2.24-11+deb9u4
ii zlib1g 1:1.2.8.dfsg-5
libpciaccess0 recommends no packages.
Versions of packages libpciaccess0 suggests:
ii pciutils 1:3.5.2-1
-- no debconf information
SUMMARY:
- this is fixed by the libpciaccess0 0.14-1 .so library manually
replacing the distribution library. Appears to be the PCI address
space size issue. (see below bug ref)
- this bug seems pretty major, so is it possible it'll ever get into
the stretch distribution?
- possible that it only effects our systems using UEFI boot as we have
some BIOS boot systems that have similar configurations that don't
have this problem. (not entirely sure the hardware is all similar)
NOTE: some report data below is from another system that was using both the
non-backports kernel as well as the backports kernel (no diff in symptoms)
Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892754
dmesg:
[ 15.915748] systemd[1]: sddm.service: Failed with result 'signal'.
[ 17.214465] systemd[1]: sddm.service: Main process exited, code=killed,
status=6/ABRT
[ 17.216271] systemd[1]: sddm.service: Failed with result 'signal'.
[ 18.447283] systemd[1]: sddm.service: Main process exited, code=killed,
status=6/ABRT
[ 18.449123] systemd[1]: sddm.service: Failed with result 'signal'.
[ 19.700575] systemd[1]: sddm.service: Start request repeated too quickly.
[ 19.701925] systemd[1]: Failed to start Simple Desktop Display Manager.
[ 19.703344] systemd[1]: sddm.service: Failed with result 'signal'.
hostname:.../share/doc/NVIDIA_GLX-1.0# grep NULL /var/log/Xorg.0.log
[13.286] (II) NVIDIA(0): nvCommonPlatformProbe: Device is NULL
[13.286] (II) NVIDIA(0): nvCommonPlatformProbe: Device is NULL
The following may be irrelevant
hostname:/etc/default/grub.d# dmesg | grep BAR\.\*size
[4.401542] pci 1:00:02.0: BAR 13: no space for [io size 0xb000]
[4.401544] pci 1:00:02.0: BAR 13: failed to assign [io size 0xb000]
[4.401546] pci 1:00:03.0: BAR 13: no space for [io size 0xc000]
[4.401547] pci 1:00:03.0: BAR 13: failed to assign [io size 0xc000]
[4.401551] pci 1:00:02.0: BAR 13: no space for [io size 0xb000]
[4.401552] pci 1:00:02.0: BAR 13: failed to assign [io size 0xb000]
[4.401554] pci 1:00:03.0: BAR 13: no space for [io size 0xc000]
[4.401556] pci 1:00:03.0: BAR 13: failed to assign [io size 0xc000]
card is there:
hostname:~# nvidia-smi -L
GPU 0: Quadro P400 (UUID: GPU-10d81f86----cdad)
NOTE: '*' used to sanitize
device info not properly enumerated
hostname:~# cat /proc/driver/nvidia/gpus/*/information
Model: Unknown
IRQ: 81
GPU UUID:GPU-----
Video BIOS: ??.??.??.??.??
Bus Type:PCIe
DMA Size:36 bits
DMA Mask:0xf
Bus Location::65:00.0
Device Minor:0
Blacklisted: No
# NOTE: the '?' above are literal (not sanitization replacements)
I am using the following (flawed) script to "workaround" this problem to get my
desktop systems functional (it fixes the problem and the X11 +sddm
system works as expected) :
dl_file="http://ftp.us.debian.org/debian/pool/main/libp/libpciaccess/libpciaccess0_0.14-1_amd64.deb;
repl_file="/usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1"
cd /
cp "${repl_file}" "${repl_file%/*}/__${repl_file##*/}.DIST"
# (prefix with __ to keep ldconfig from symlinking SONAME of old
# library)
if curl -s "${dl_file}" \
| dpkg-deb --fsys-tarfile - \
| tar xvf - .${repl_file}
then
ldconfig
else
echo "Something bad happened. rc=$?"
exit 1
fi
echo "YOU SHOULD REBOOT NOW"
Thanks,
--stephen
Bug#950795: buster-pu: package puma/3.12.0-2
Am Dienstag, den 03.03.2020, 20:37 + schrieb Adam D. Barratt: > On Thu, 2020-02-06 at 17:33 +0100, Daniel Leidert wrote: > > The proposed update will fix CVE-2019-16770 (#946312) for Buster > > users. The security team marked the issue no-dsa and asked to > > schedule the fix via the next point release. The debdiff is attached. > > The patch to fix the CVE has been taken from upstream's Git > > repository. > > +puma (3.12.0-2+deb10u1) buster-security; urgency=medium > > Just "buster" for p-u, please. Yes I already saw it. I prepared the upload first for security. But they asked me to do the upload via p-u. I'll fix this. > +Subject: Merge pull request from GHSA-7xx3-m584-x994 > + > +could monopolize a thread. Previously, this could make a DoS attack more > +severe. > > Is there a missing line (or at least words) before "could monopolize" > there? No. This is the original commit message I kept from upstream. > In any case, please go ahead (with the fixed distribution). Thanks. Regards, Daniel signature.asc Description: This is a digitally signed message part
Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader
On Fri 2020-02-14 07:58:34 -0700, Sean Whitton wrote: >>> Also, will imap-dl skip messages with the deleted flag? Do you think it >>> should? >> >> I don't think it should -- the use case at the moment is just to fetch >> all messages that exist in the inbox. Why should it treat any flag >> differently? > > What I was thinking was that the user might want imap-dl to set the > delete flag and not expunge, and then skip deleted messages on future > runs. Then they'd expunge themselves from time-to-time. > > This way, if imap-dl makes any mistakes, there is a sort of backup. > > I was particularly thinking that someone might want to use this at > first, until they could feel sure that imap-dl doesn't have any bugs > with their particular IMAP server. I'd be happy to entertain this mode of operation for imap-dl if someone wants to offer a robust patch for it with a very minimal footprint in terms of configuration complexity :) In general, i'm happy for imap-dl to remain fairly opinionated about what workflows are "sensible" and not supporting too many others directly, given the combinatoric risks of adding little tweaky options to what's effectively a state machine manager. Users who want a super-flexible toolkit might be better off writing their own, using the existing libraries. --dkg signature.asc Description: PGP signature
Bug#953065: util-linux: hwclock reports incorrect status in audit message
Package: util-linux Version: 2.31.1-0.4 hwclock code uses EXIT_SUCCESS == 0 and EXIT_FAILURE == 1. hwclock_exit() calls audit_log_user_message() and sometimes uses the exit status from a call as the status it passes to create the audit record. The audit_log_user_message() manpage states that for the status or result, 1 is "success" and 0 is "failed" So hwclock sends the opposite of what audit_log_user_message() expects for status. Although the hwclock command was successful, the audit record's, "res" field has that it failed. i.e., type=USYS_CONFIG msg=audit(1582729727.515:29021): pid=15698 uid=0 auid=1000 ses=347 msg_1='op=change-system-time exe="/sbin/hwclock" hostname=? addr=? terminal=pts/1 res=failed' hwclock needs to pass status as understood by audit_log_user_message(). This was reported upstream and fixed, https://github.com/karelzak/util-linux/commit/189edf1fe501ea39b35911337eab1740888fae7a Thanks! regards, Joy
Bug#953054: "DeprecationWarning: PY_SSIZE_T_CLEAN will be required" after python3.7 -> 3.8
* Anders Breindahl: > As unattended-upgrades was doing its thing, my regularly-running > debsecan-exploitive monitoring suite started throwing these errors on > regular debsecan invocations: > > $ debsecan > /dev/null > /usr/bin/debsecan:95: DeprecationWarning: PY_SSIZE_T_CLEAN will be > required for '#' formats > return version_compare(self.__asString, other.__asString) < 0 > /usr/bin/debsecan:98: DeprecationWarning: PY_SSIZE_T_CLEAN will be > required for '#' formats > return version_compare(self.__asString, other.__asString) == 0 > > The relevant line in unattended-upgrades seems to be this: > > Unpacking python3 (3.8.2-1) over (3.7.5-3) > > (Conveniently for bisection, apt-listchanges has the same behaviour, and > starts spewing these errors only after the above line.) > > Please let me know if you'd like any further information! Isn't this warning triggered by code in python-apt? After all, debsecan does this near the beginning of the script: apt_pkg.init() try: version_compare = apt_pkg.version_compare except AttributeError: version_compare = apt_pkg.VersionCompare
Bug#953064: FTBFS on i386
Source: odin Severity: serious odin FTBFSes on i386. This also means that on i386 it still uses Qt4. Cheers, Moritz
Bug#953063: FTBFS on i386
Source: mrtrix3 Severity: serious mrtrix3 FTBFS on i386, which means that the stale i386 build still uses Qt4. There's the existing "#916284 mrtrix3 seems to be amd64-only", so I suggest to simply restrict the arch list to amd64 and file an RM bug for the outdated i386 binaries? Cheers, Moritz
Bug#953033: Not ready for text-scale-adjust
On Tue, 03 Mar 2020 23:51:58 +0800, 積丹尼さん wrote: > Package: w3m-el-snapshot > X-Debbugs-Cc: yama...@jpl.org > Version: 1.4.632+0.20191218.2243.cef0c7e-1 > $ emacs -q -f w3m > C-x C-= [text-scale-adjust] > C-= [anonymous-command] > Here the lines get cut off. > They should fold, staying on the screen as the text zooms. In that case the window width, i.e., the return value of (window-width) is unchanged, so we have no clue for the point where to fold text lines. We have no solution for it, I think.
Bug#953062: FTBFS on arm64, armel, armhf, ppc64el, s390x
Package: meshlab Severity: serious The new meshlab FTBFSes on arm64, armel, armhf, ppc64el, s390x. This also means that on those archs meshlab still uses Qt4. Cheers, Moritz
Bug#953061: pydoc3 matplotlib gives a deprecation warning about rcparam
Package: python3-matplotlib Version: 3.1.2-2 Severity: normal pydoc3 matplotlib gives the following warning: /usr/lib/python3.7/pydoc.py:1058: MatplotlibDeprecationWarning: The examples.directory rcparam was deprecated in Matplotlib 3.0 and will be removed in 3.2. In the future, examples will be found relative to the 'datapath' directory. return cram(stripid(repr(x)), self.maxother) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-matplotlib depends on: ii libc6 2.29-10 ii libfreetype62.10.1-2 ii libgcc-s1 10-20200222-1 ii libjs-jquery3.3.1~dfsg-3 ii libjs-jquery-ui 1.12.1+dfsg-5 ii libpng16-16 1.6.37-2 ii libstdc++6 10-20200222-1 ii python-matplotlib-data 3.1.2-2 ii python3 3.7.5-3 ii python3-cycler 0.10.0-3 ii python3-dateutil2.7.3-3 ii python3-kiwisolver 1.0.1-3 ii python3-numpy [python3-numpy-abi9] 1:1.17.4-5 ii python3-pyparsing 2.4.6-1 ii python3-six 1.14.0-2 Versions of packages python3-matplotlib recommends: pn python3-pil pn python3-tk Versions of packages python3-matplotlib suggests: pn dvipng ii ffmpeg 7:4.2.2-1+b1 ii ghostscript9.50~dfsg-5 ii gir1.2-gtk-3.0 3.24.14-1 ii inkscape 0.92.4-5 pn ipython3 ii librsvg2-common2.46.4-1 pn python-matplotlib-doc pn python3-cairocffi ii python3-gi 3.34.0-6 ii python3-gi-cairo 3.34.0-6 pn python3-gobject pn python3-nose pn python3-pyqt5 pn python3-scipy pn python3-sip pn python3-tornado pn texlive-extra-utils ii texlive-latex-extra2019.202000218-1 pn ttf-staypuft -- no debconf information
Bug#953060: ImportError when trying to import OpenImageIO
Package: python3-openimageio Version: 2.1.11.2~dfsg0-3 Severity: normal I am getting an ImportError when trying to import OpenImageIO: jdietrch@saturn:~$ python3 Python 3.7.6 (default, Jan 19 2020, 22:34:52) [GCC 9.2.1 20200117] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import OpenImageIO Traceback (most recent call last): File "", line 1, in ImportError: /lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory in static TLS block >>> If did figure out that if I LD_PRELOAD that library, then the import OpenImageIO succeeds; but I don't think that should be necessary. jdietrch@saturn:~$ LD_PRELOAD=/lib/x86_64-linux-gnu/libjemalloc.so.2 python3 Python 3.7.6 (default, Jan 19 2020, 22:34:52) [GCC 9.2.1 20200117] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import OpenImageIO >>> Let me know if I can provide any further information. Thank you, James Dietrich
Bug#953059: node-vm-browserify: Please run test
Package: node-vm-browserify Version: 0.0.4-1 Severity: wishlist Dear Maintainer, After browserify is shipped upstream please run test (and add also example) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages node-vm-browserify depends on: ii nodejs 10.17.0~dfsg-2 node-vm-browserify recommends no packages. node-vm-browserify suggests no packages. -- no debconf information
Bug#953058: RFS: node-emoj/2.0.0-1~exp1 [ITP] -- Find relevant emoji from text on the command-line
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "node-emoj" * Package name: node-emoj Version : 2.0.0-1~exp1 Upstream Author : https://github.com/sindresorhus/emoj/issues * URL : https://github.com/sindresorhus/emoj#readme * License : MIT * Vcs : https://salsa.debian.org/js-team/node-emoj Section : javascript It builds those binary packages: I see other nodejs-emoji and relative, but its for developement tools, this one is easy and be happy for end user. just type and copy paste it. how simply Find relevant emoji from text on the command-line Uses the API from this great article on Emoji & Deep Learning. Check out the Dango app if you want something like this on your phone. Run it without arguments to enter the live search Use the up/down keys during live search to change the skin tone node-emoj - Find relevant emoji from text on the command-line To access further information about this package, please visit the following URL: https://mentors.debian.net/package/node-emoj Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/node-emoj/node-emoj_2.0.0-1~exp1.dsc Changes since the last upload: * Initial release (Closes: #953038) Regards,
Bug#950718: RFS: depthcharge-tools/0.3.1-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
On 03/03/2020 18:51, Cyril Brulebois wrote:
partman-* is of course fine for udebs shipping partman stuff, but
depthcharge-support-installer strikes me as something that could be
named depthcharge-support-udeb, or maybe just depthcharge-udeb?
I mimicked the flash-kernel & flash-kernel-installer naming for the
latter two, and *-installer seems to be the way bootloader-related udeb
packages are usually named (e.g. {grub,lilo,zipl}-installer currently in
the archive). But I will change it if you're not convinced -- I think
depthcharge-support-udeb is OK, but depthcharge-udeb feels weird as this
is definitely not depthcharge itself (see below).
Maybe I can merge depthcharge-support into depthcharge-tools, it's just
the easiest way I had thought of indicating "use this bootloader" like
grub-* packages do (vs. grub-*-bin packages); then we could just have a
depthcharge-tools and depthcharge-tools-installer/depthcharge-tools-udeb
whichever is better.
(Unfortunately I don't have any time to review this more thoroughly to
figure out exactly which part does what etc., but I thought sending
this quick note wouldn't hurt.)
Thanks for the reply. I tried to write up a somewhat short overview of
what my prospective packages do, to hopefully make things easier to
understand:
Depthcharge is a coreboot payload from Google which is shipped as part
of ChromeOS devices' firmware. It boots from images of a special format
written to partitions of a special type.
partman-cros:
- enables partman to create these partitions
- checks and alerts if these partitions are necessary but don't exist
depthcharge-tools provides scripts/commands that automate e.g.:
- building images for a known current machine or an arbitrary config
- writing images to partitions and setting boot priority
- blessing the currently booted partition
depthcharge-support only consists of:
- initramfs & kernel hooks to build and write an up-to-date image
- init.d script & systemd service to bless only successful boots
depthcharge-support-installer is an installer step that:
- installs depthcharge-tools to target
- makes target build and write an image for itself
- reconfigure initramfs if it's too big (machine-specific size limit)
- installs depthcharge-support if all is fine
Bug#953057: subversion: FTBFS against swig 4
Source: subversion Version: 1.13.0-2 Severity: important Dear Maintainer, While trying to rebuild src:subversion in a clean unstable amd64 chroot I got the following error: ... Wrote subversion/bindings/swig/proxy/swig_python_external_runtime.swg /usr/bin/swig -I/<>/BUILD/subversion -I/<>/subversion/include -I/<>/subversion/bindings/swig -I/<>/subversion/bindings/swig/include -I/<>/subversion/bindings/swig/proxy -I/<>/BUILD/subversion/bindings/swig/proxy -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include -python -classic -o subversion/bindings/swig/python/core.c /<>/subversion/bindings/swig/core.i Deprecated command line option: -classic. This option is no longer supported. make[1]: *** [/<>/build-outputs.mk:290: subversion/bindings/swig/python/core.c] Error 1 make[1]: Leaving directory '/<>/BUILD' make: *** [debian/rules:228: debian/stamp-build-arch] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 This is a known open upstream bug [1]. Just dropping the '-classic' option does not work, other errors pop up. [1] https://issues.apache.org/jira/browse/SVN-4818 -- Lucas Kanashiro
Bug#952188: golang-github-mendersoftware-scopestack: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/mendersoftware/scopestack returned exit code 1
On Mon, Mar 02, 2020 at 09:38:00AM +0100, Lluis Campos wrote: > Hello, > > The patch looks good to us. Thanks Andreas for following up! > > Side note. We have discussed internally and decided that we will remove > both scopestack and log[1] dependencies from the mender-client code. > This will ease maintenance of the Debian package :) Thanks for the feedback on the patch and the future roadmap! I'll upload the patched scopestack for now and will be looking forward to being able to request package removal later once new releases are out and we have everything updated. Regards, Andreas Henriksson
Bug#953056: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
Package: python3 Version: 3.8.2-1 Setting up python3 (3.8.2-1) ... running python rtupdate hooks for python3.8... /usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used self.stdin = io.open(p2cwrite, 'wb', bufsize) /usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used self.stdin = io.open(p2cwrite, 'wb', bufsize) running python post-rtupdate hooks for python3.8... /usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used self.stdin = io.open(p2cwrite, 'wb', bufsize) Setting up chromium-shell (80.0.3987.122-1) ...
Bug#952610: fixed in meson 0.53.2-2
On Mon, Mar 2, 2020 at 4:27 PM Gianfranco Costamagna wrote: > lets see the sum of the issues without the stderr change > > amd64: > crossbuild FAIL stderr: dpkg-architecture: warning: specified GNU > system type arm-linux-gnueabihf does not match CC system type > powerpc64le-linux-gnu, try setting a correct CC environment variable Can you test if the issue is fixed fro you if you add stderr=subprocess.DEVNULL to debcrossgen line 38? > > That should already be happening. AFAIUI the exhaustive test has a > > dependency on all build deps of Meson, which includes valac and rustc. > > > > nack on this. Fortunately there is a valac in unstable but not in testing, > and you can see there is no mention of meson autopkgtest against it. That is strange, because if you look at the install log for Ubuntu tests: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/m/meson/20200303_171925_00939@/log.gz both valac and rustc are installed. Maybe the autopkg dependency lookup code gets confused by @builddeps@ somehow?
Bug#953053: psychopy: missing python3 dependencies
Package: psychopy Version: 2020.1.1+dfsg-1 Severity: important Dear Maintainer, After installing psychopy 2020.1.1, when I use pip3 to install some packages (that do not have psychopy as dependency), I get the following error: ERROR: psychopy 2020.1.1 requires arabic_reshaper, which is not installed. ERROR: psychopy 2020.1.1 requires astunparse, which is not installed. ERROR: psychopy 2020.1.1 requires esprima, which is not installed. ERROR: psychopy 2020.1.1 requires glfw, which is not installed. ERROR: psychopy 2020.1.1 requires javascripthon, which is not installed. ERROR: psychopy 2020.1.1 requires opencv-python, which is not installed. ERROR: psychopy 2020.1.1 requires pyosf, which is not installed. ERROR: psychopy 2020.1.1 requires python-bidi, which is not installed. I checked and these are dependencies of psychopy are not present in the debian repos. It seems that during packaging these dependencies were omitted. As far as i can tell, these dependencies are hard dependencies. Best, Bob -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-7.1-liquorix-amd64 (SMP w/8 CPU cores; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_NL.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages psychopy depends on: ii python33.7.5-3 ii python3-configobj 5.0.6-3 ii python3-freetype 2.1.0.post1-2 ii python3-future 0.18.2-1 ii python3-gevent 1.4.0-1+b1 ii python3-git3.0.7-1 ii python3-gitlab 1:2.0.1-1 ii python3-json-tricks3.11.0-2 ii python3-lxml 4.5.0-1 ii python3-matplotlib 3.1.2-2 ii python3-msgpack0.5.6-3 ii python3-msgpack-numpy 0.4.4-1 ii python3-numpy 1:1.17.4-5 ii python3-opengl 3.1.0+dfsg-2 ii python3-openpyxl 3.0.3-1 ii python3-pandas 0.25.3+dfsg-7 ii python3-pil6.2.1-2+b1 ii python3-psutil 5.6.7-1 ii python3-pygame 1.9.6+dfsg-2 ii python3-pyglet 1.4.10-1 ii python3-requests 2.22.0-2 ii python3-scipy 1.3.3-3 ii python3-serial 3.4-5.1 ii python3-soundfile 0.10.3+post1-1 ii python3-tables 3.6.1-2 ii python3-xlrd 1.1.0-5 ii python3-yaml 5.3-1 ii python3-zmq17.1.2-4 Versions of packages psychopy recommends: pn ipython ii libxxf86vm1 1:1.1.4-1+b2 ii python3-cryptography 2.8-3 ii python3-distro1.4.0-1 ii python3-opencv4.2.0+dfsg-5 ii python3-pygame1.9.6+dfsg-2 ii python3-pyglet1.4.10-1 ii python3-pyo 1.0.0-2.1 ii python3-questplus 2019.4-2 ii python3-wxgtk4.0 4.0.7+dfsg-2 ii python3-xlib 0.23-2 Versions of packages psychopy suggests: pn libavbin0 pn python3-iolabs pn python3-pyxid
Bug#953052: psychopy: python2 dependencies
Package: psychopy Version: 2020.1.1+dfsg-1 Severity: important Dear Maintainer, Psychopy seems to have python2 dependencies. I do not have any python2 packages installed anymore. When installing psychopy 2020.1.1 with apt-get from the official debian repo, it pulls in a selection of python2 packages: ipython libpython-stdlib libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib python python-backports-shutil-get-terminal-size python-chardet python-decorator python-enum34 python-ipython python-ipython-genutils python-minimal python-pathlib2 python-pexpect python- pickleshare python-pkg-resources python-prompt-toolkit python-ptyprocess python-pygments python-scandir python-simplegeneric python-six python-traitlets python-wcwidth python2 python2-minimal python2.7 python2.7-minimal When manually installing the deb with gdebi it does not install these python2 packages. Seems to be some kind of packaging error. Best, Bob -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-7.1-liquorix-amd64 (SMP w/8 CPU cores; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_NL.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages psychopy depends on: ii python33.7.5-3 ii python3-configobj 5.0.6-3 ii python3-freetype 2.1.0.post1-2 ii python3-future 0.18.2-1 ii python3-gevent 1.4.0-1+b1 ii python3-git3.0.7-1 ii python3-gitlab 1:2.0.1-1 ii python3-json-tricks3.11.0-2 ii python3-lxml 4.5.0-1 ii python3-matplotlib 3.1.2-2 ii python3-msgpack0.5.6-3 ii python3-msgpack-numpy 0.4.4-1 ii python3-numpy 1:1.17.4-5 ii python3-opengl 3.1.0+dfsg-2 ii python3-openpyxl 3.0.3-1 ii python3-pandas 0.25.3+dfsg-7 ii python3-pil6.2.1-2+b1 ii python3-psutil 5.6.7-1 ii python3-pygame 1.9.6+dfsg-2 ii python3-pyglet 1.4.10-1 ii python3-requests 2.22.0-2 ii python3-scipy 1.3.3-3 ii python3-serial 3.4-5.1 ii python3-soundfile 0.10.3+post1-1 ii python3-tables 3.6.1-2 ii python3-xlrd 1.1.0-5 ii python3-yaml 5.3-1 ii python3-zmq17.1.2-4 Versions of packages psychopy recommends: pn ipython ii libxxf86vm1 1:1.1.4-1+b2 ii python3-cryptography 2.8-3 ii python3-distro1.4.0-1 ii python3-opencv4.2.0+dfsg-5 ii python3-pygame1.9.6+dfsg-2 ii python3-pyglet1.4.10-1 ii python3-pyo 1.0.0-2.1 ii python3-questplus 2019.4-2 ii python3-wxgtk4.0 4.0.7+dfsg-2 ii python3-xlib 0.23-2 Versions of packages psychopy suggests: pn libavbin0 pn python3-iolabs pn python3-pyxid
Bug#953055: apt-listchanges: DeprecationWarning: PY_SSIZE_T_CLEAN [...] after python3.7->python3.8
Package: apt-listchanges Version: 3.22 Severity: low Dear Maintainer, As unattended-upgrades updated python (between 06:27:18 and 06:28:21), the output behaviour of apt-listchanges changed in the subsequent run (starting 06:28:21): Log started: 2020-03-03 06:27:18 apt-listchanges: Reading changelogs... apt-listchanges: Reading changelogs... [ ... snip ... ] Preparing to unpack .../python3_3.8.2-1_amd64.deb ... Unpacking python3 (3.8.2-1) over (3.7.5-3) ... [ ... snip ... ] Log ended: 2020-03-03 06:28:21 Log started: 2020-03-03 06:28:21 /usr/bin/apt-listchanges:209: DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats if fromversion and apt_pkg.version_compare(fromversion, version) >= 0: apt-listchanges: Reading changelogs... /usr/bin/apt-listchanges:209: DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats if fromversion and apt_pkg.version_compare(fromversion, version) >= 0: apt-listchanges: Reading changelogs... I reported a similar bug in debsecan just now (don't have the number of it yet) but insofar this doesn't cause an email to be triggered to me every 10 minutes, I'm filing this one as "low." —please let me know if you need any further information! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt1.8.4 ii debconf [debconf-2.0] 1.5.73 ii python33.8.2-1 ii python3-apt1.8.6 ii python3-debconf1.5.73 ii sensible-utils 0.0.12+nmu1 ii ucf3.0038+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii elinks [www-browser]0.13.1-1 ii postfix [mail-transport-agent] 3.4.9-1 ii python3-gi 3.34.0-6 ii xterm [x-terminal-emulator] 353-1 -- debconf information excluded
Bug#953051: psychopy: python2 dependencies
Package: psychopy Version: 2020.1.1+dfsg-1 Severity: important 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: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-7.1-liquorix-amd64 (SMP w/8 CPU cores; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_NL.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages psychopy depends on: ii python33.7.5-3 ii python3-configobj 5.0.6-3 ii python3-freetype 2.1.0.post1-2 ii python3-future 0.18.2-1 ii python3-gevent 1.4.0-1+b1 ii python3-git3.0.7-1 ii python3-gitlab 1:2.0.1-1 ii python3-json-tricks3.11.0-2 ii python3-lxml 4.5.0-1 ii python3-matplotlib 3.1.2-2 ii python3-msgpack0.5.6-3 ii python3-msgpack-numpy 0.4.4-1 ii python3-numpy 1:1.17.4-5 ii python3-opengl 3.1.0+dfsg-2 ii python3-openpyxl 3.0.3-1 ii python3-pandas 0.25.3+dfsg-7 ii python3-pil6.2.1-2+b1 ii python3-psutil 5.6.7-1 ii python3-pygame 1.9.6+dfsg-2 ii python3-pyglet 1.4.10-1 ii python3-requests 2.22.0-2 ii python3-scipy 1.3.3-3 ii python3-serial 3.4-5.1 ii python3-soundfile 0.10.3+post1-1 ii python3-tables 3.6.1-2 ii python3-xlrd 1.1.0-5 ii python3-yaml 5.3-1 ii python3-zmq17.1.2-4 Versions of packages psychopy recommends: pn ipython ii libxxf86vm1 1:1.1.4-1+b2 ii python3-cryptography 2.8-3 ii python3-distro1.4.0-1 ii python3-opencv4.2.0+dfsg-5 ii python3-pygame1.9.6+dfsg-2 ii python3-pyglet1.4.10-1 ii python3-pyo 1.0.0-2.1 ii python3-questplus 2019.4-2 ii python3-wxgtk4.0 4.0.7+dfsg-2 ii python3-xlib 0.23-2 Versions of packages psychopy suggests: pn libavbin0 pn python3-iolabs pn python3-pyxid
Bug#953054: "DeprecationWarning: PY_SSIZE_T_CLEAN will be required" after python3.7 -> 3.8
Package: debsecan Version: 0.4.20.1 Severity: normal Dear Maintainer, As unattended-upgrades was doing its thing, my regularly-running debsecan-exploitive monitoring suite started throwing these errors on regular debsecan invocations: $ debsecan > /dev/null /usr/bin/debsecan:95: DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats return version_compare(self.__asString, other.__asString) < 0 /usr/bin/debsecan:98: DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats return version_compare(self.__asString, other.__asString) == 0 The relevant line in unattended-upgrades seems to be this: Unpacking python3 (3.8.2-1) over (3.7.5-3) (Conveniently for bisection, apt-listchanges has the same behaviour, and starts spewing these errors only after the above line.) Please let me know if you'd like any further information! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debsecan depends on: ii ca-certificates20190110 ii debconf [debconf-2.0] 1.5.73 ii python33.8.2-1 ii python3-apt1.8.6 Versions of packages debsecan recommends: ii cron [cron-daemon] 3.0pl1-136 ii postfix [mail-transport-agent] 3.4.9-1 debsecan suggests no packages. -- debconf information excluded
Bug#953013: [Python-modules-team] Bug#953013: pyyaml: CVE-2020-1747: arbitrary command execution through python/object/new when FullLoader is used
On Tue, Mar 03, 2020 at 12:15:09PM -0500, Scott Kitterman wrote: > On Tuesday, March 3, 2020 11:41:26 AM EST Salvatore Bonaccorso wrote: > > OK. If anyone has a reproducer for this, it'd be very helpful to sort it out. > > I think this is like the recent CVE for python-bleach where the affected code > didn't exist in the older releases, but the issue was still demonstrable. I > suspect that pyyaml << 5.1 will still have this problem even with the > SafeLoader, since the FullLoader shares code with the older SafeLoader. > > I can see how to adapt the upstream pull request to the 3.X releases, but I > agree it's not clear what the regression risk would be. I decided to leave > the security tracker alone for now too. In comparable cases in the past (can't name specific cases, but it has happened multiple times for sure) where divergent interfaces were affected, this typically led to two CVE IDs. I don't think anyone is really up to deal with the beaureaucracy involved, though. As for the regression impact I can't tell. If there's a fix which is agreed to be non-risky and fixes the security issue, we can simply apply it independent of the whole CVE discussion. Cheers, Moritz
Bug#953048: [Pkg-sass-devel] Bug#953048: ruby-sass: sass --watch does not work
control: tags -1 confirmed control: severity -1 low Quoting Werner Joss (2020-03-03 20:46:47) > sass --watcg does not work - I get the following errors: You are right, that feature has been omitted from the Debian packaging of ruby-sass. It should work if you install the Python module sass-watch locally. - 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#953005: buster-pu: package serverspec-runner/1.2.2-1+deb10u1
Control: tags -1 -moreinfo +confirmed On Tue, 2020-03-03 at 20:43 +0100, Daniel Leidert wrote: > Package: release.debian.org > Followup-For: Bug #953005 > > Sorry. Now it should be. > Thanks, please go ahead. Regards, Adam
Bug#950795: buster-pu: package puma/3.12.0-2
Control: tags -1 + confirmed On Thu, 2020-02-06 at 17:33 +0100, Daniel Leidert wrote: > The proposed update will fix CVE-2019-16770 (#946312) for Buster > users. The security team marked the issue no-dsa and asked to > schedule the fix via the next point release. The debdiff is attached. > The patch to fix the CVE has been taken from upstream's Git > repository. +puma (3.12.0-2+deb10u1) buster-security; urgency=medium Just "buster" for p-u, please. +Subject: Merge pull request from GHSA-7xx3-m584-x994 + +could monopolize a thread. Previously, this could make a DoS attack more +severe. Is there a missing line (or at least words) before "could monopolize" there? In any case, please go ahead (with the fixed distribution). Regards, Adam
Bug#953050: /usr/bin/xfdesktop: XFdesktop crashes when install libreoffice6.4-debian-menus (6.4.1-2)
Package: xfdesktop4 Version: 4.12.4-2 Severity: normal File: /usr/bin/xfdesktop Dear Maintainer, When I installed Libreoffice 6.4.1 from upstream, on the dpkg -i libreoffice6.4-debian-menus (6.4.1-2), XFdesktop and xfce4-panel crashed. Mar 3 21:01:09 X kernel: [112575.427569] xfce4-panel[1100]: segfault at 17 ip 7fd4cc74965c sp 7ffd81f98030 error 4 in libgobject-2.0.so.0.5800.3[7fd4cc71f000+32000] Mar 3 21:01:09 X kernel: [112575.427605] Code: 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 41 54 55 53 48 89 fb 48 85 ff 0f 84 a4 00 00 00 48 8b 07 48 85 c0 0f 84 a4 00 00 00 <48> 8b 28 48 89 ea 48 81 fd fc 03 00 00 0f 86 f1 00 00 00 48 83 e2 Mar 3 21:01:09 X kernel: [112575.451071] xfdesktop[1104]: segfault at 19 ip 7f899fada9ea sp 7ffcdfc3f210 error 4 in libglib-2.0.so.0.5800.3[7f899fa8a000+7e000] Mar 3 21:01:09 X kernel: [112575.451105] Code: 8d 48 ff 48 89 c3 49 89 ce 49 c1 e6 04 4c 01 f5 48 8b 45 00 48 85 c0 0f 84 c3 00 00 00 48 8b 58 08 48 85 db 0f 84 fe 01 00 00 <48> 8b 13 48 89 50 08 48 8b 45 08 48 85 c0 74 08 48 83 e8 01 48 89 Regards. -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfdesktop4 depends on: ii exo-utils0.12.4-1 ii libc62.28-10 ii libcairo21.16.0-4 ii libdbus-1-3 1.12.16-1 ii libdbus-glib-1-2 0.110-4 ii libexo-1-0 0.12.4-1 ii libgarcon-1-00.6.2-1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk2.0-0 2.24.32-3 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libwnck222.30.7-6 ii libx11-6 2:1.6.7-1 ii libxfce4ui-1-0 4.12.1-3 ii libxfce4util74.12.1-3 ii libxfconf-0-24.12.1-1 ii xfdesktop4-data 4.12.4-2 Versions of packages xfdesktop4 recommends: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii librsvg2-common 2.44.10-2.1 ii tumbler 0.2.3-1 ii xdg-user-dirs 0.17-2 Versions of packages xfdesktop4 suggests: pn menu -- no debconf information
Bug#952714: texlive-latex-extra: missing Breaks+Replaces: sdaps (<< 1.9.7)
On 28/02/2020 01.14, Norbert Preining wrote:
> what on **EARTH** made sdaps install anything into /usr/share/texlive...
fortunately it's the only non-texlive package in buster doing this ...
(and none in sid does it)
grep -h usr/share/texlive lists/buster/Contents* | awk '{print $2}' |
sort | uniq -c | sort -n
Andreas
Bug#953049: qtwebsockets-opensource-src: CVE-2018-21035: QWebsocket large frame/message issue, denial of service
Source: qtwebsockets-opensource-src Version: 5.14.1-1 Severity: important Tags: security upstream Forwarded: https://bugreports.qt.io/browse/QTBUG-70693 Control: found -1 5.12.5-2 Control: found -1 5.11.3-5 Hi, The following vulnerability was published for qtwebsockets-opensource-src. CVE-2018-21035[0]: | In Qt through 5.14.1, the WebSocket implementation accepts up to 2GB | for frames and 2GB for messages. Smaller limits cannot be configured. | This makes it easier for attackers to cause a denial of service | (memory consumption). If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-21035 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-21035 [1] https://bugreports.qt.io/browse/QTBUG-70693 [2] https://codereview.qt-project.org/c/qt/qtwebsockets/+/284735 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#953048: ruby-sass: sass --watch does not work
Package: ruby-sass Version: 3.5.6-1 Severity: normal Dear Maintainer, sass --watcg does not work - I get the following errors: sass --watch --trace custom.scss:custom.css >>> Sass is watching for changes. Press Ctrl-C to stop. Traceback (most recent call last): 9: from /usr/bin/sass:8:in `' 8: from /usr/lib/ruby/vendor_ruby/sass/exec/base.rb:19:in `parse!' 7: from /usr/lib/ruby/vendor_ruby/sass/exec/base.rb:52:in `parse' 6: from /usr/lib/ruby/vendor_ruby/sass/exec/sass_scss.rb:51:in `process_result' 5: from /usr/lib/ruby/vendor_ruby/sass/exec/sass_scss.rb:356:in `watch_or_update' 4: from /usr/lib/ruby/vendor_ruby/sass/plugin.rb:109:in `method_missing' 3: from /usr/lib/ruby/vendor_ruby/sass/plugin/compiler.rb:319:in `watch' 2: from /usr/lib/ruby/vendor_ruby/sass/plugin/compiler.rb:380:in `create_listener' 1: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- sass-listen (LoadError) -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ruby-sass depends on: ii ruby 1:2.5.1 ruby-sass recommends no packages. Versions of packages ruby-sass suggests: pn ruby-sass-listen -- no debconf information
Bug#953047: python3.8: Packages requiring python3 < 3.8 doesn't install even when 3.7 is available
Control: severity -1 normal On 3/3/20 8:44 PM, Sajjad Kabir Joy wrote: > Package: python3.8 > Version: 3.8.2-1 > Severity: important > > Dear Maintainer, > > Installation of packages depending on samba failed, and when I tried > installing samba itself I got this: If you don't know how to handle that, you shouldn't install packages from unstable. Please wait a few days/weeks until things are rebuilt.
Bug#950430: more rdeps testing
These packages were missing from my old packages-to-test list due to #953014: influxdb-python jsonpickle psychopy tqdm They have now been tested: jsonpickle - OK influxdb-python (#950063), tqdm - already broken (probably by the 0.23 -> 0.25 transition, where the same bug left them off the to-test list), but pandas 1 doesn't make them any worse psychopy - already BD-Uninstallable due to python3.7->3.8 transition (#949187 - python3-opencv hasn't been rebuilt yet) i.e. no new blockers but psychopy should probably be retested when it becomes buildable again.
Bug#953047: python3.8: Packages requiring python3 < 3.8 doesn't install even when 3.7 is available
Package: python3.8 Version: 3.8.2-1 Severity: important Dear Maintainer, Installation of packages depending on samba failed, and when I tried installing samba itself I got this: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: samba : Depends: python3 (< 3.8) but 3.8.2-1 is to be installed Depends: python3-samba but it is not going to be installed Depends: samba-common-bin (= 2:4.11.5+dfsg-1) but it is not going to be installed Depends: samba-libs (= 2:4.11.5+dfsg-1) but it is not going to be installed Recommends: attr but it is not going to be installed Recommends: python3-markdown but it is not going to be installed Recommends: samba-dsdb-modules but it is not going to be installed Recommends: samba-vfs-modules but it is not going to be installed E: Unable to correct problems, you have held broken packages. I installed python3.7 (3.7.6-1), but that didn't fix the problem. I additionally enabled Testing repositories, to no avail. As a result, I can't install anything (like mpv, gvfs-backend etc) that requires python3 < 3.8. Not to mention --fix-broken didn't help, either. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3.8 depends on: ii libpython3.8-stdlib 3.8.2-1 ii mime-support 3.64 ii python3.8-minimal3.8.2-1 python3.8 recommends no packages. Versions of packages python3.8 suggests: pn binutils pn python3.8-doc pn python3.8-venv -- no debconf information
Bug#953005: buster-pu: package serverspec-runner/1.2.2-1+deb10u1
Package: release.debian.org
Followup-For: Bug #953005
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Sorry. Now it should be.
- -- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.3.0-3-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl5es1gACgkQS80FZ8KW
0F0jvw//Wp6PT3t3pNC8alsKBju7IbOwPFgBRKhe2LsG27JMWvYu/6VIzfay5K1Q
FaTVGv+nYHLvf+NXUq/zymzRX/3CYOqbtmze07VCsBP6/jMzVFMmhIDEKhPyawzJ
c5AXnsqOX/hiAstInS3ma9dJgMXUPTl/gh77G4YfprtKkwiIHdSOo9aderf7z5KY
uFTDdeuuXuGmRa/68rCmhtvO1BCJkGxN5AA88TTYVaJj9AxI7m2h3xVKcM7sqVGH
v8G0mhkKuc7NLD9Vnbv4hUlXpLSe4oc3yRQT4VDubN3y9a5NV3bZZUoxtjHg0MTj
po+h18br9huPqRCoZmzSlRNZX5Sxm5nvDWOq2cxFazk4/lMrBUtDsJogL7lUFtdZ
V+NyliM+/fOSP2TsGUlh4cmZY+wSAnZ7+jR6+oy+YSZJnubLGNo0KrPvZglfqgPi
FAiobAN/qicxGANYoiWeOpYvwSBB5W4OAV7et0SbL1t0f6/I8yEH+4SPgFOuqegY
ldhRPeqQ/d8zuhtDfxLlKYp6coSgmoh04HoG0ijjDN1eUkyZjvjNEcPJSC4j95+c
9fcn8s5DsKN1swljMwRFdUJrVBmjwCw6+PBheu24nDUnPa7dFESP31FUD6kflaW+
QK23ZRjHdDRhvbtnWyKXD5W//5diCWVNyfLI2Q/Zr3b7qc3iKDk=
=ZiIa
-END PGP SIGNATURE-
diff -Nru serverspec-runner-1.2.2/debian/changelog
serverspec-runner-1.2.2/debian/changelog
--- serverspec-runner-1.2.2/debian/changelog2016-09-15 12:48:17.0
+0200
+++ serverspec-runner-1.2.2/debian/changelog2020-03-02 23:41:24.0
+0100
@@ -1,3 +1,11 @@
+serverspec-runner (1.2.2-1+deb10u1) buster; urgency=medium
+
+ * d/patches/fix-yaml-load-document-missing: Add patch.
+- Support Ruby 2.5 and replace YAML.load_documents (closes: #939645).
+ * d/patches/series: Add new patch.
+
+ -- Daniel Leidert Mon, 02 Mar 2020 23:41:24 +0100
+
serverspec-runner (1.2.2-1) unstable; urgency=medium
* New upstream release.
diff -Nru serverspec-runner-1.2.2/debian/patches/fix-yaml-load-document-missing
serverspec-runner-1.2.2/debian/patches/fix-yaml-load-document-missing
--- serverspec-runner-1.2.2/debian/patches/fix-yaml-load-document-missing
1970-01-01 01:00:00.0 +0100
+++ serverspec-runner-1.2.2/debian/patches/fix-yaml-load-document-missing
2020-03-02 23:41:24.0 +0100
@@ -0,0 +1,19 @@
+From: hiracy
+Date: Fri, 16 Nov 2018 19:43:15 +0900
+Acked-By: Daniel Leidert
+Origin:
https://github.com/hiracy/serverspec-runner/commit/c459787defe1b08bbe46a5acf0ea07039fe44f61.patch
+Bug-Debian: https://bugs.debian.org/939645
+Description: [PATCH] Support ruby 2.5 over
+ Use YAML.load_stream instead of YAML.load_documents.
+
+--- a/Rakefile
b/Rakefile
+@@ -165,7 +165,7 @@
+ end
+
+ File.open(ENV['scenario'] || "#{ENV['specroot']}/scenario.yml") do |f|
+-YAML.load_documents(f).each_with_index do |data, idx|
++YAML.load_stream(f).each_with_index do |data, idx|
+ if idx == 0
+ scenarios = data
+ else
diff -Nru serverspec-runner-1.2.2/debian/patches/series
serverspec-runner-1.2.2/debian/patches/series
--- serverspec-runner-1.2.2/debian/patches/series 2016-09-01
13:13:41.0 +0200
+++ serverspec-runner-1.2.2/debian/patches/series 2020-03-02
23:41:24.0 +0100
@@ -1 +1,2 @@
fix-path-issue
+fix-yaml-load-document-missing
Bug#952538: libwolfssl-dev: user_settings.h missing
Hello! Related to this is upstream issue https://jira.mariadb.org/browse/MDEV-21835 where Robert Bindar is working to make MariaDB support building with system WolfSSL. Robert might fill on this (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952538) issue if there are needs regarding what the system WolfSSL library in Debian should ship.
Bug#953046: Wrongly picks AZERTY layout when alternative Canadian layout is present.
Package: ibus-mozc Version: 2.23.2815.102+dfsg-4 Severity: normal Hi Nobuhiro, It has been years that I was affected with that bug, but I am only reporting it now as I found an (old!) workaround in Launchpad. I use GNOME with a Japanese keyboard, and I have 3 layouts configured; I switch between them according to the language I write in. - jp – Japanese (OADG 109A), for writing English and programming. - fr – Candian Multilingual, for writing French. This is a QWERTY layout. - あ – Japanese (Mozc), for writing Japanese. Strangely, while both the Japanese and Canadian layouts are QWERYY, the mozc engine automatically picks an AZERTY layout (which is standard in France), despite my laptop has a Japanese keyboard. In https://bugs.launchpad.net/ubuntu/+source/indicator-keyboard/+bug/1240004 I learnt that if I replace "default" with "jp" in /usr/share/ibus/component/mozc.xml then mozc will use the Japanese layout as appropriate. But obviously this change will be erased at the next package upgrade. I am not sure how to solve that problem in the long term… Cheers, -- Charles -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ibus-mozc depends on: ii ibus1.5.19-4+deb10u1 ii libc6 2.28-10 ii libglib2.0-02.58.3-2+deb10u2 ii libibus-1.0-5 1.5.19-4+deb10u1 ii libprotobuf17 3.6.1.3-2 ii libstdc++6 8.3.0-6 ii libxcb-xfixes0 1.13.1-2 ii libxcb1 1.13.1-2 ii mozc-data 2.23.2815.102+dfsg-4 ii mozc-server 2.23.2815.102+dfsg-4 ii tegaki-zinnia-japanese 0.3-1 Versions of packages ibus-mozc recommends: ii mozc-utils-gui 2.23.2815.102+dfsg-4 ibus-mozc suggests no packages. -- no debconf information
Bug#953018: ITP: spamassassin-milter -- milter for spam filtering with SpamAssassin
On Tue, Mar 03, 2020 at 11:00:45AM +0100, David Bürgin wrote: > Debian already has package spamass-milter, which serves the same > function. This new alternative is not exactly the same: It does a few > things better (eg automatic macro negotiation, skipping large bodies), > some things differently (eg header handling logic, no forking), and some > things are (currently) left out. spamass-milter hasn’t been active for > many years, so this could also be a fresh start. Do we need both packages in Debian? If, as you say, spamass-milter is orphaned upstream, maybe we should work to replace it with this new package? I'm not sure how our users benefit from having both, and the choice will undoubtedly lead to confusion. noah
Bug#953045: SSL routines:ssl_choose_client_version:unsupported protocol
Package: w3m Version: 0.5.3-37+b1 $ w3m -dump https://data.moi.gov.tw/MoiOD/Data/DataDetail.aspx?oid=8001F4E6-7035-49E4-ADFC-DF43E755F824 SSL error: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol w3m: Can't load https://data.moi.gov.tw/MoiOD/Data/DataDetail.aspx?oid=8001F4E6-7035-49E4-ADFC-DF43E755F824. lynx worked fine.
Bug#951209: transition: libgusb
On Wed, Feb 12, 2020 at 03:24:42PM +0100, Laurent Bigonville wrote: > libgusb is carrying in debian a patch[0] to revert/fix an after the fact > change that was done upstream in the versioning of the symbols. > > I don't think we should/can carry this patch forever and due to the fact > that the number of reverse-dependencies is quite limited, I was planning > to simply drop it, but that would require to binNMU them to be > certain they are using the correct version of the symbol. > IMO we should keep compatibility with the old version until the next upstream SONAME bump. That might mean keeping this patch, or something different, if we can add properly versioned aliases for the affected symbols? Cheers, Julien
Bug#952441: buster-pu: package user-mode-linux/4.19-1um-1+b1
Control: tags -1 -moreinfo +confirmed On Wed, 2020-02-26 at 11:02 +0100, Santiago R.R. wrote: > Control: fixed 951329 user-mode-linux/5.4-1um-2 > > El 25/02/20 a las 21:05, Adam D. Barratt escribió: > > Control: tags -1 + moreinfo > > > > On Mon, 2020-02-24 at 14:49 +0100, Santiago R.R. wrote: > > > I would like to upload user-mode-linux to buster to fix this > > > FTBFS: > > > https://bugs.debian.org/951329. Ritesh Raj Sarraf (rrs) has > > > already > > > given his ACK. > > > > > > > The metadata for that bug suggests that it affects the package in > > unstable, and is not currently fixed there. Is that correct? > > > > If it is, the issue should be fixed in unstable first. If not, the > > bug > > report should have an appropriate "fixed" version added, indicating > > the > > earliest upload that's unaffected. > > Hi Adam, > > Thanks! I forgot clarifying that this didn't affect unstable. > Hopefully > the above control command fix that. > > Also, I realised the changelog did not describe how the bug was > fixed. > Thanks, please go ahead. Regards, Adam
Bug#952586: buster-pu: package backuppc/3.3.2-2
Control: tags -1 + confirmed On Wed, 2020-02-26 at 12:26 +, Jonathan Wiltshire wrote: > I'd like to fix an important bug in backuppc which prevents > `systemd reload backuppc.service` from failing. As a result of this > bug backuppc has to be restarted for systemd's supervision to be > reset, which interrupts ongoing jobs. > Please go ahead. Regards, Adam
Bug#952785: buster-pu: package dojo/1.15.0+dfsg1-1+deb10u1
Control: tags -1 + confirmed On Mon, 2020-03-02 at 11:28 +0100, Xavier wrote: > Le 01/03/2020 à 22:52, Andreas Beckmann a écrit : > > > +#CVE-2019-10785.patch > > > > The patch is commented in the series file and thus does not get > > applied. > > > > Andreas > > Sorry for this error. Here is the real patch. > Thanks, please go ahead. Regards, Adam
Bug#953021: libhdf5-mpi-dev: provide links to default mpi (hdf5-mpi.pc)
Thinking about it, if possible it would be best to have hdf5-mpi.pc managed by update-alternatives, but tracking the mpi alternative. i.e. set up as a slave alternative depending on mpi, that updates if the local system switches mpi from openmpi to mpich. I'm not sure if this can be done cross-package, but good if it can. If it can be done, then the control logic would go in the postinst/prerm of libhdf5-openmpi-dev and libhdf5-mpich-dev rather than libhdf5-mpi-dev.
Bug#952960: buster-pu: package ruby-factory-girl-rails/4.7.0-1+deb10u1
Control: tags -1 +confirmed -moreinfo On Mon, 2020-03-02 at 18:59 +0100, Daniel Leidert wrote: > Package: release.debian.org > Followup-For: Bug #952960 > > I've uploaded the fix to unstable and updated the diff (Vcs* fields > changed, see attached). > Thanks, please go ahead. Regards, Adam
Bug#951631: lightning: UI elements show what looks like XML errors
On 21/02/2020 12:42, Carsten Schoenert wrote: > Hello Bob, > > Am 19.02.20 um 08:30 schrieb Bob Ham: >> It appears that the most recent update to lightning has caused serious >> problems in the thunderbird UI where lightning's UI elements do not >> work correctly and display large sections of what look like XML with >> error markings. In particular, more than half of the main window is >> lost to a pane showing this XML-like badness which makes the program >> very difficult to use. > > have you tried to follow these steps? > > https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues I had tried most of them, yes. I disabled the lightning plugin and checked that it was causing the problem (that's why I filed the bug against the lightning package.) I hadn't tried creating a fresh profile. Having done that now, it does seem that lightning works OK with the fresh profile. There's still a problem though; my existing profile contains a lot of information I don't want to lose or have to manually recreate, like message filter rules and so on. Bob
Bug#953005: buster-pu: package serverspec-runner/1.2.2-1+deb10u1
Control: tags -1 + moreinfo On Tue, 2020-03-03 at 01:00 +0100, Daniel Leidert wrote: > This update is to fix #939645 [1]. The debdiff is attached. Apparently not. :-) Regards, Adam
Bug#952669: reportbug output
On 3/3/20 6:56 PM, Andreas Beckmann wrote: > On 03/03/2020 18.05, Lucas B. Cohen wrote: >> Attached is partial output of : reportbug --template -T none -s none -S >> normal -b --list-cc none -q xserver-xorg-video-nvidia-legacy-390xx (with >> repeated lines removed, and some irrelevant info sanitized). > > You were running the current (418.xx) nvidia-driver: > >> /proc/driver/nvidia/version: >> NVRM version: NVIDIA UNIX x86_64 Kernel Module 418.74 Wed May 1 11:49:41 >> CDT 2019 >> GCC version: gcc version 8.3.0 (Debian 8.3.0-6) > >> lrwxrwxrwx 1 root root 23 Mar 3 16:33 /etc/alternatives/nvidia > -> /usr/lib/nvidia/current > > therefore the collected information is mostly irrelevant for the 390xx > driver. Right. I had switched back to the current driver before running reportbug. My bad. > You don't seem to have the nvidia-legacy-390xx-driver package installed > either ... Well, this is awkward. Indeed, after checking more closely it appears I only had small bits and pieces of the complete legacy driver installed. (Perhaps only a couple packages, including the dkms-support package, which misled me into reassigning this bug here). > Were you using the glvnd or nonglvnd variant of the 390xx driver? > nvidia-legacy-390xx-driver-libs | nvidia-legacy-390xx-driver-libs-nonglvnd Judging from my apt logs, neither one was present on my system! (This is consistent with strace output I was seeing previously, showing some nvidia libs not being found when launching my userspace program.) > Since that card seems to be supported by all driver versions: > is there any reason to use the 390xx legacy driver for this card? Not that I can tell. Properly installed, both work well on my system. Given the strange, quite broken state in which my system was, it's probably not worth anyone's time investigating this any further. Thank you for your answer, and sorry for the noise. > BTW, the README.txt in the 390.xx driver lists the GeForce GTX 750 Ti as > a supported card. (D'oh. This is me failing to read the last three lines of the package description.)
Bug#953042: Package removal can fail if some contained files are no present
Debian doesn’t work on “IMO”s, but on the Debian policy and it says no such thing here: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html Ondrej -- Ondřej Surý > On 3 Mar 2020, at 19:21, MichaIng wrote: > > IMO any prerm/postrm script must not depend on any of the packages files, > that is about to be removed.
Bug#953030: bacula-sd.postinst fails on systems with protected_regular=2 enabled
Hi, On Tue, Mar 03, 2020 at 05:53:31PM +0100, Carsten Leonhardt wrote: > thanks for the patch. I've commited a change to our git repository based > on it. For consistency I changed the order in similar postinst files > too. Thank you! I grabbed your commit in Ubuntu to replace my patch. signature.asc Description: PGP signature
Bug#953039: upgrading packet python3 up to 3.8.2-1 asks packets deletion
Control: severity -1 normal just wait until packages are installable again. It takes some time. On 3/3/20 6:11 PM, Сергей Фёдоров wrote: > > Package: python3 > Version: 3.7.5-3 > Severity: critical > Tags: a11y > Justification: breaks unrelated software > > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) > Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), > LANGUAGE=ru_RU.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages python3 depends on: > ii libpython3-stdlib 3.7.5-3 > ii python3-minimal3.7.5-3 > ii python3.7 3.7.6-1+b1 > > python3 recommends no packages. > > Versions of packages python3 suggests: > pn python3-doc > pn python3-tk > pn python3-venv > > -- no debconf information > > Upgrading off package python3 from 3.7.5-3 to 3.8.2-1 > asks packets deletion: > > hplip 3.20.2+dfsg0-1 > libreoffice 1:6.4.1-1 > libreoffice-librelogo 1:6.4.1-1 > libreoffice-script-provider-python 1:6.4.1-1 > libsmbclient 2:4.11.5+dfsg-1 > python3-smbc 1.0.15.6-2+b1 > python3-talloc 2.3.0-3 > python3-uno 1:6.4.1-1 > samba-libs 2:4.11.5+dfsg-1 > vlc-plugin-samba 3.0.8-4 > > but these are the latest versions of packages. >
Bug#953044: net-snmp: Either provide tool or remove references to net-snmp-cert
Source: net-snmp Source-Version: 5.8+dfsg-2 Severity: normal Hi! There are references to a helper tool called net-snmp-cert in snmpcmd(1) and snmpd.conf(5), but that tool is not shipped anywhere. Please either ship the tool somewhere, or remove the references from the man pages, as that will lead users to look for something that is not there. :) Thanks, Guillem
Bug#953043: snmpd: Please move net-snmp-create-v3-user into snmpd package
Package: snmpd Version: 5.8+dfsg-2 Severity: normal Hi! There's an administrative script called net-snmp-create-v3-user used to create SNMP v3 user credentials, but it is shipped in the libsnmp-dev, instead of in the snmpd package. Having to install a development package on a production system is not very convenient, so it would be good to move it along its man page there where it is most useful. I guess you might need to patch net-snmp-config to cope with the script being possibly missing when snmpd is not installed. Thanks, Guillem
Bug#953042: Package removal can fail if some contained files are no present
Package: libapache2-mod-php7.0 Version: 7.0.33-0+deb9u7 Hey guys, I wanted to report an issue that we faced some time ago: https://github.com/MichaIng/DietPi/issues/2797 The postrm script calls "php_invoke dismod 7.0 apache2 $mod" to disable the modules, but this fails if either "/usr/lib/apache2/modules/libphp7.0.so" or "/etc/apache2/mods-avaialble/php7.0.load" are missing already for some reason. IMO any prerm/postrm script must not depend on any of the packages files, that is about to be removed. With PHP7.3 packages this have been solved, from what I can see. Either the scripts from PHP7.3 can be adopted or otherwise a simple " || :" would allow the commands to fail. Uninstall could be unclean, but IMO better then running into such very very annoying state, that, because its about dpkg state, prevents apt/dpkg from installing/upgrading anything else without final failure (see above linked issue). Best regards, MichaIng
Bug#953041: RM: ruby-extendmatrix -- ROM; dead upstream, RC buggy, low popcon, no reverse dependencies
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 ruby-extendmatrix fails to build with the current Ruby version and has an RC bug. It has no reverse dependencies and popcon reports just one installation. After discussing it internally [1] we would like to request the removal of this package from the archive. [1] https://lists.debian.org/msgid-search/aebb6f2ee0b0c0673d802a0e3cffb284200c3346.ca...@debian.org Regards, Daniel -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl5emgIACgkQS80FZ8KW 0F0wXBAAxxuEvAo0+ntbPdjAfkrG8UXsl7i/nM2D/FJSHPRVhjt7sQY4irxPDFOk MXYbdMx0L0EnZI+8QLIGy10HHkaCzyUGc6K4MwiHGyJm2ta5ho+WMuKpZcEAZvV+ jW8R+19QRUk5IG9eZUIwfoVEzfbuchZPxhEVVQYB1rvjpUsELxYB7ahPlIb2kOlu FdakBfmwGWIsIeNLxTz00h/Qhwa85Utdx3g/BqTARF0hb24/+zclh8F4yYKkuf6R GMly0+IRlQf3UX5Hq9YsS/s7CTPquGONUvwy91a3dw+xqCBg04HI0FopYNST74kQ Lk74yY/sXnR8o8yUwMVbc9dMpondkseFjV9603blSHfm4hpIESueYQveZxc0oqpG CJA+aYJ9e8VKUgvsEbKODGnfUuzkO6mzIMvNALFYJqUNc4F4+uXdinxY6KVUxr+J bATxjEpexjahp47oZMYFOtf7BBLyn2Yr6wYOP1CfP+s8JnpTm/9kfqtF0iHbvqmi e0xGdEQqr9Et/B1b3NJk5qdjOJGtDpAnlwKvQIvHL/kuiv8ca9FbqrvDHDcMXLG0 otz9MmyNwCUGCLpc3a851sc0dBq7EGZPXRsnCOf50hWrzn+NVT/KIy2VmsMY6rTc xLePyroRkO8ZKbFYHFJHAJeFbY5xW4499SzmKSFbW3YHZkj9c0U= =C5BZ -END PGP SIGNATURE-
Bug#952669: reportbug output
On 03/03/2020 18.05, Lucas B. Cohen wrote: > Attached is partial output of : reportbug --template -T none -s none -S > normal -b --list-cc none -q xserver-xorg-video-nvidia-legacy-390xx (with > repeated lines removed, and some irrelevant info sanitized). You were running the current (418.xx) nvidia-driver: > /proc/driver/nvidia/version: > NVRM version: NVIDIA UNIX x86_64 Kernel Module 418.74 Wed May 1 11:49:41 > CDT 2019 > GCC version: gcc version 8.3.0 (Debian 8.3.0-6) > lrwxrwxrwx 1 root root 23 Mar 3 16:33 /etc/alternatives/nvidia -> /usr/lib/nvidia/current therefore the collected information is mostly irrelevant for the 390xx driver. You don't seem to have the nvidia-legacy-390xx-driver package installed either ... Were you using the glvnd or nonglvnd variant of the 390xx driver? nvidia-legacy-390xx-driver-libs | nvidia-legacy-390xx-driver-libs-nonglvnd Since that card seems to be supported by all driver versions: sid# nvidia-detect 10de:1380 Checking driver support for PCI ID [10de:1380] Your card is supported by all driver versions. Your card is also supported by the Tesla drivers series. It is recommended to install the nvidia-driver package. is there any reason to use the 390xx legacy driver for this card? BTW, the README.txt in the 390.xx driver lists the GeForce GTX 750 Ti as a supported card. Andreas
Bug#950578: (no subject)
Just going to point out that the 5.x equivalent patch has now been applied to Linux mainline as per: https://lkml.kernel.org/lkml/20200224.153146.125327154283545636.da...@davemloft.net/ Could we get some acknowledgement that this patchset is being looked at for possible integration and isn't falling through the cracks? This has been opened for more than a month now, and, notwithstanding the patch update above, it's quite damaging for Raspberry Pi users that the 10.3 update didn't include these changes, as it would have enabled them to install Debian from the vanilla 10.3 release ISO whereas Pi 4 users will have to wait months before that happens... So, can someone please look at this request and at least acknowledge it? Thank you, /Pete
Bug#953040: prometheus-mysqld-exporter: Regression on configuration disallows proper use of mysql auth_socket authentication
Package: prometheus-mysqld-exporter Version: 0.11.0+ds-1+b20 Severity: serious Justification: Policy 10.9 Dear Maintainer, After upgrading my MariaDB server boxes to buster, the version of prometheus mysqld exporter monitoring package stopped working. When I checked the cause of it, the package logged very usefuly the cause: no user or password specified under [client] in /var/lib/prometheus/.my.s5.cnf I checked an my [client] section had a user config, plust a password one, except it was configured on purpose like this: password = '' I confirmed that by adding a fully random password, different from the empty string, the exporter started working again. This is because I use socket-based authentication for the prometheus mysqld exporter user (https://mariadb.com/kb/en/authentication-plugin-unix-socket/), something that is a best practice in a secure production environement. In fact, Debian uses socket_auth for the default-created root user, which makes Debian mariadb installation much more secure. This issue not only forces users to maintain a password on the filesystem in clear text (that can be easily stolen or leaked by accident, and reused for other similarly-configured systems), it overpases the additional checks of socket-auth, that requires a matching unix acccount with the same name as that of the mysql account. This is a regression because auth_socket was working properly on previous versions of prometheus available on stretch and other OSs. Not only this breaks existing installations, it also discourages the usage of the avobe mentioned, more secure authentication mechanism. If UI-friendly errors are prefered (because people forgets to create or protect mysql accounts, please allow me to specifically mark "this account doesn't have a password, and I know what I am doing". I have not reported this upstream. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prometheus-mysqld-exporter depends on: ii daemon 0.6.4-1+b2 ii libc6 2.28-10 prometheus-mysqld-exporter recommends no packages. Versions of packages prometheus-mysqld-exporter suggests: pn default-mysql-server | virtual-mysql-server -- no debconf information
Bug#953039: upgrading packet python3 up to 3.8.2-1 asks packets deletion
Package: python3 Version: 3.7.5-3 Severity: critical Tags: a11y Justification: breaks unrelated software -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), LANGUAGE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3 depends on: ii libpython3-stdlib 3.7.5-3 ii python3-minimal3.7.5-3 ii python3.7 3.7.6-1+b1 python3 recommends no packages. Versions of packages python3 suggests: pn python3-doc pn python3-tk pn python3-venv -- no debconf information Upgrading off package python3 from 3.7.5-3 to 3.8.2-1 asks packets deletion: hplip 3.20.2+dfsg0-1 libreoffice 1:6.4.1-1 libreoffice-librelogo 1:6.4.1-1 libreoffice-script-provider-python 1:6.4.1-1 libsmbclient 2:4.11.5+dfsg-1 python3-smbc 1.0.15.6-2+b1 python3-talloc 2.3.0-3 python3-uno 1:6.4.1-1 samba-libs 2:4.11.5+dfsg-1 vlc-plugin-samba 3.0.8-4 but these are the latest versions of packages.
Bug#953013: [Python-modules-team] Bug#953013: pyyaml: CVE-2020-1747: arbitrary command execution through python/object/new when FullLoader is used
On Tuesday, March 3, 2020 11:41:26 AM EST Salvatore Bonaccorso wrote: > Hi Scott, > > On Tue, Mar 03, 2020 at 09:19:06AM -0500, Scott Kitterman wrote: > > On Tuesday, March 3, 2020 2:29:51 AM EST Salvatore Bonaccorso wrote: > > > Source: pyyaml > > > Version: 5.3-1 > > > Severity: important > > > Tags: security upstream > > > Forwarded: https://github.com/yaml/pyyaml/pull/386 > > > > > > Hi, > > > > > > The following vulnerability was published for pyyaml. > > > > > > CVE-2020-1747[0]: > > > |arbitrary command execution through python/object/new when FullLoader > > > |is used > > > > > > If you fix the vulnerability please also make sure to include the > > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > > > > > For further information see: > > > > > > [0] https://security-tracker.debian.org/tracker/CVE-2020-1747 > > > > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1747 > > > > > > [1] https://github.com/yaml/pyyaml/pull/386 > > > > > > Please adjust the affected versions in the BTS as needed. > > > > Thank you for the report. > > > > I've reviewed the current security-tracker entry and I believe it's > > incorrect. While it's true that the unsafe loader was the default loader > > in releases prior to 5.0, the safe loader has always been part of pyyaml > > and recommended for cases where untrusted input needed to be parsed. > > > > Although I haven't actually tried it yet, I reviewed the relevant code > > from > > the earlier releases and I believe the same fix would work. Unfortunately > > I don't have a test case to verify that. > > > > Also, the upstream pull request to fix this is incomplete. It only > > provides a fix for python3-yaml, not python-yaml. > > > > I've updated the affected versions in the BTS and will take a shot at > > updating the security tracker shortly. > > I'm actually unsure how to handle that CVE. While I believe to > undrstand that the unsafe loader are present, my understanding of the > CVE-2020-1747 is directly associated with the FullLoader use and > looking at the Red Hat bug where the CVE originates, > https://bugzilla.redhat.com/show_bug.cgi?id=1807367 it looks to me > that the CVE's scope is only to cover FullLoader. > > Again I'm not really sure. But if that interpretation would be > correct, and given upstream recommended for for cases where untrusted > input needed to be parsed to use the safe loaders, then not-affected > would theoretically be correct, but maybe with changed/expanded > explanation on that FullLoader is not present until 5.1. > > I'm not going to touch the CVE entry in the security-tracker now, and > looking for feedback from you all (you, Emilio, Moritz said to look as > well a the CVE later). OK. If anyone has a reproducer for this, it'd be very helpful to sort it out. I think this is like the recent CVE for python-bleach where the affected code didn't exist in the older releases, but the issue was still demonstrable. I suspect that pyyaml << 5.1 will still have this problem even with the SafeLoader, since the FullLoader shares code with the older SafeLoader. I can see how to adapt the upstream pull request to the 3.X releases, but I agree it's not clear what the regression risk would be. I decided to leave the security tracker alone for now too. Scott K signature.asc Description: This is a digitally signed message part.
Bug#950983: clickhouse FTBFS in bullseye/sid
Hi Jochen (2020.02.09_00:40:36_-0800) Control: tag -1 + patch I notice that Ubuntu has a patch for this: https://launchpadlibrarian.net/466815449/clickhouse_18.16.1+ds-5_18.16.1+ds-5ubuntu1.diff.gz It's building on amd64 and ppc64el: https://launchpad.net/ubuntu/+source/clickhouse/18.16.1+ds-5ubuntu1 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#953030: bacula-sd.postinst fails on systems with protected_regular=2 enabled
Control: tag -1 pending Hi, > bacula-sd.postinst currently uses mktemp, chowns to bacula.bacula, and > then attempts to write to the temporary file using a shell redirection. > > If a system has /proc/sys/fs/protected_regular set to 2, then this > fails[1]. thanks for the patch. I've commited a change to our git repository based on it. For consistency I changed the order in similar postinst files too. Regards, Carsten
Bug#951420: RFS: sane-backends/1.0.29-1~experimental1 -- API library for scanners -- utilities
Hello Adam, thanks for your review. We are this week on a exhibition. That's why I can't look for it until next weekend. CU Jörg Am Freitag, den 28.02.2020, 19:58 +0100 schrieb Adam Borowski: > On Sun, Feb 16, 2020 at 12:19:44PM +0100, Jörg Frings-Fürst wrote: > >Package name: sane-backends > >Version : 1.0.29-1~experimental1 > > Changes since the last upload: > ["War and Peace" skipped] > > > The build with sbuild (sbuild --no-arch-all && sbuild --no-arch-any > > && > > sbuild) and pdebuild are ok. The tests with lintian and piuparts > > and > > the autopkgtest are also ok. > > Alas, it fail autopkgtests for me: > > autopkgtest [19:12:30]: test start-net: [--- > + /bin/sed -i /localhost/d /etc/sane.d/saned.conf > + echo localhost > + /bin/sed -i s/^#\(pnm\)$/\1/ /etc/sane.d/dll.conf > + /bin/sed -i s/^# \(localhost\)$/\1/ /etc/sane.d/net.conf > + /usr/bin/scanimage -d net -L > + /bin/grep net:+ > /usr/bin/wc -l > Created directory: /var/lib/snmp/mib_indexes > + CNT=0 > + [ 0 -eq 2 ] > + exit 100 > autopkgtest [19:12:35]: test start-net: ---] > autopkgtest [19:12:35]: test start-net: - - - - - - - - - - results > - - - - - - - - - - > start-netFAIL non-zero exit status 100 > > Full log at http://ix.io/2cUE > > > Meow! -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#953038: ITP: node-emoj -- Find relevant emoji from text on the command-line
Package: wnpp Severity: wishlist Owner: kokoye2007 * Package name: node-emoj Version : 2.0.0 Upstream Author : Sindre Sorhus (sindresorhus.com ) * URL : https://github.com/sindresorhus/emoj#readme * License : MIT Programming Lang: JavaScript Description : Find relevant emoji from text on the command-line I see other nodejs-emoji and relative, but its for developement tools, this one is easy and be happy for end user. just type and copy paste it. how simply Find relevant emoji from text on the command-line Uses the API from this great article on Emoji & Deep Learning. Check out the Dango app if you want something like this on your phone. Run it without arguments to enter the live search Use the up/down keys during live search to change the skin tone -- with regards *Ko Ko Ye`* +95 97989 22022 +95 94500 22022 +95 9731 47907 kokoye2...@gmail.com kokoye2...@ubuntu.com skype: kokoye2007 jitsi: kokoye2007 http://ubuntu-mm.net http://wiki.ubuntu.com/kokoye2007 http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
Bug#953037: lua-cgi: CVE-2014-2875
Package: lua-cgi Severity: important Tags: security upstream Control: found -1 5.2~alpha2-1 Hi, The following vulnerability was published for lua-cgi. CVE-2014-2875[0]: | The session.lua library in CGILua 5.2 alpha 1 and 5.2 alpha 2 uses | weak session IDs generated based on OS time, which allows remote | attackers to hijack arbitrary sessions via a brute force attack. NOTE: | CVE-2014-10300 and CVE-2014-10400 were SPLIT from this ID. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2014-2875 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2875 Please adjust the affected versions in the BTS as needed. Cheers! Sylvain Beucler Debian LTS Team
Bug#953013: [Python-modules-team] Bug#953013: pyyaml: CVE-2020-1747: arbitrary command execution through python/object/new when FullLoader is used
Hi Scott, On Tue, Mar 03, 2020 at 09:19:06AM -0500, Scott Kitterman wrote: > On Tuesday, March 3, 2020 2:29:51 AM EST Salvatore Bonaccorso wrote: > > Source: pyyaml > > Version: 5.3-1 > > Severity: important > > Tags: security upstream > > Forwarded: https://github.com/yaml/pyyaml/pull/386 > > > > Hi, > > > > The following vulnerability was published for pyyaml. > > > > CVE-2020-1747[0]: > > |arbitrary command execution through python/object/new when FullLoader > > |is used > > > > If you fix the vulnerability please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > > > For further information see: > > > > [0] https://security-tracker.debian.org/tracker/CVE-2020-1747 > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1747 > > [1] https://github.com/yaml/pyyaml/pull/386 > > > > Please adjust the affected versions in the BTS as needed. > > Thank you for the report. > > I've reviewed the current security-tracker entry and I believe it's > incorrect. > While it's true that the unsafe loader was the default loader in releases > prior to 5.0, the safe loader has always been part of pyyaml and recommended > for cases where untrusted input needed to be parsed. > > Although I haven't actually tried it yet, I reviewed the relevant code from > the earlier releases and I believe the same fix would work. Unfortunately I > don't have a test case to verify that. > > Also, the upstream pull request to fix this is incomplete. It only provides > a > fix for python3-yaml, not python-yaml. > > I've updated the affected versions in the BTS and will take a shot at > updating > the security tracker shortly. I'm actually unsure how to handle that CVE. While I believe to undrstand that the unsafe loader are present, my understanding of the CVE-2020-1747 is directly associated with the FullLoader use and looking at the Red Hat bug where the CVE originates, https://bugzilla.redhat.com/show_bug.cgi?id=1807367 it looks to me that the CVE's scope is only to cover FullLoader. Again I'm not really sure. But if that interpretation would be correct, and given upstream recommended for for cases where untrusted input needed to be parsed to use the safe loaders, then not-affected would theoretically be correct, but maybe with changed/expanded explanation on that FullLoader is not present until 5.1. I'm not going to touch the CVE entry in the security-tracker now, and looking for feedback from you all (you, Emilio, Moritz said to look as well a the CVE later). Regards, Salvatore
Bug#953036: Flag date-based/large version numbers
Package: lintian
Severity: wishlist
From debian-devel:
On 3/3/20 7:35 AM, Edward Betts wrote:
> When I originally packaged uap-core upstream was not producing any releases.
> I was using the most recent commit to master on github with the date for the
> version number. The initial version was 20180219-1
This seems like a good thing for Lintian to check. Anyone creating
date-based version numbers like this (as opposed to 0~MMDD or
similar) could run into the same problem if upstream starts tagging
releases.
I propose that lintian check for "large" version numbers (e.g.
/^(\d+:)?[0-9]{4}/) and flag them as possibly date-based and suggest
some other format (e.g. 0~MMDD).
There are plenty of existing packages with version numbers like this.
Adding epochs to all of them at this point isn't helpful. So it probably
makes sense to skip the warning if there is a previous changelog entry
and it also trips the same check. That way, people would be flagged on
A) new packages, and B) if they change to this version format.
--
Richard
signature.asc
Description: OpenPGP digital signature
Bug#953035: openssh-client: SIGABRT with “corrupted size vs. prev_size”
Package: openssh-client Version: 1:8.2p1-4 Severity: normal An ssh session with port forwarding just crashed for me. Backtrace: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0xf7a75513 in __GI_abort () at abort.c:79 #2 0xf7acc82c in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0xf7bd4a3a "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0xf7ad2b38 in malloc_printerr (str=str@entry=0xf7bd2b56 "corrupted size vs. prev_size") at malloc.c:5366 #4 0xf7ad3325 in unlink_chunk (p=p@entry=0x57634968, av=0xf7c06880 ) at malloc.c:1468 #5 0xf7ad460b in _int_free (av=, p=0x57634878, have_lock=) at malloc.c:4354 #6 0x565b7422 in channel_garbage_collect (c=0x57634880, ssh=0x576267d0) at ../../channels.c:2417 #7 channel_handler (ssh=ssh@entry=0x576267d0, table=table@entry=0, readset=, writeset=, unpause_secs=unpause_secs@entry=0xfff54ac8) at ../../channels.c:2464 #8 0x565b7f62 in channel_prepare_select (ssh=ssh@entry=0x576267d0, readsetp=readsetp@entry=0xfff54ab8, writesetp=writesetp@entry=0xfff54abc, maxfdp=maxfdp@entry=0xfff54ac0, nallocp=nallocp@entry=0xfff54ac4, minwait_secs=minwait_secs@entry=0xfff54ac8) at ../../channels.c:2523 #9 0x56595d35 in client_wait_until_can_do_something (rekeying=0, nallocp=0xfff54ac4, maxfdp=0xfff54ac0, writesetp=0xfff54abc, readsetp=0xfff54ab8, ssh=0x576267d0) at ../../clientloop.c:524 #10 client_loop (ssh=, have_pty=1, escape_char_arg=, ssh2_chan_id=) at ../../clientloop.c:1379 #11 0x56589c54 in ssh_session2 (pw=, pw=, ssh=0x576267d0) at ../../ssh.c:2077 #12 main (ac=, av=) at ../../ssh.c:1610 -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages openssh-client depends on: ii adduser 3.118 ii dpkg 1.19.7 ii libc6 2.29-10 ii libedit2 3.1-20191231-1 ii libfido2-11.3.1-1 ii libgssapi-krb5-2 1.17-6 ii libselinux1 3.0-1 ii libssl1.1 1.1.1d-2 ii passwd1:4.8.1-1 ii zlib1g1:1.2.11.dfsg-2 Versions of packages openssh-client recommends: ii xauth 1:1.0.10-1 Versions of packages openssh-client suggests: pn keychain ii kwalletcli [ssh-askpass] 3.02-1 pn libpam-ssh pn monkeysphere -- Configuration Files: /etc/ssh/ssh_config changed: Include /etc/ssh/ssh_config.d/*.conf Host * VisualHostKey no SendEnv LANG LC_* HashKnownHosts no GSSAPIAuthentication yes ServerAliveCountMax 1 ServerAliveInterval 600 HostKeyAlgorithms ssh-rsa,rsa-sha2-256 -- no debconf information
Bug#949584: mmdebstrap fails to create temp file if TMPDIR is set to directory with mode 0755
Am Mittwoch, den 22.01.2020, 21:40 +0100 schrieb Johannes Schauer: > Hi, > > Quoting Benjamin Drung (2020-01-22 13:23:36) > > Am Mittwoch, den 22.01.2020, 13:13 +0100 schrieb Johannes Schauer: > > > Quoting Benjamin Drung (2020-01-22 12:58:38) > > > > when I set TMPDIR to a directory that has mode 0755, mmdebstrap > > > > will fail: > > > > > > > > ``` > > > > $ ls -ld . > > > > drwxr-xr-x 3 bdrung bdrung 80 Jan 22 12:43 . > > > > $ TMPDIR=$(pwd) mmdebstrap buster buster.tar.xz > > > > I: automatically chosen mode: unshare > > > > > > you are using the unshare mode. This means that your temporary > > > directory needs > > > to be accessible by the unshared user. Evidently it is not. I > > > don't > > > think there > > > is anything that mmdebstrap can do about it. > > > > mmdebstrap could create a temporary directory, change the mode to > > 1777 and > > let unshare use that, couldn't it? > > but that's not where the error comes from. From the output you posted > in your > report it seems like mmdebstrap is not able to create the temporary > directory > at all. Obviously it cannot change permissions of something that > doesn't exist. > I don't think mmdebstrap should attempt touching the permissions of > the $TMPDIR > directory. From the log from the initial report: I: using /tmpfs/foo/mmdebstrap.wYxMFPcZHA as tempdir This directory is created and owned by unshared user. Afterwards mmdebstrap tries to create another temporary directory in /tmpfs/foo (instead of /tmpfs/foo/mmdebstrap.wYxMFPcZHA) and fails. I expect that mmdebstrap would succeed if it would create additional temporary directories in that initial /tmpfs/foo/mmdebstrap.wYxMFPcZHA directory. > Also: the sticky bit probably has no influence on whether or not you > get the > "permission denied" error, right? Yes. The sticky bit has no effect on the "permission denied" error. I just mentioned it, because /tmp has mode 1777. -- Benjamin Drung DevOps Engineer and Debian & Ubuntu Developer Platform Integration (IONOS Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Dr. Martin Endreß, Hans- Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail. signature.asc Description: This is a digitally signed message part
Bug#937302: playonlinux: Python2 removal in sid/bullseye
On Tue, 3 Mar 2020, Markus Koschany wrote: Sorry, I do not mean any disrespect. What can I do to help? I believe the best thing to do would be to package the new Java version. https://github.com/PhoenicisOrg/phoenicis This requires some knowledge of Java and how Java applications are packaged for Debian. I have created https://wiki.debian.org/Java/Packaging https://wiki.debian.org/Java/Packaging/Maven which should give you some hints. If packaging the new version is out of scope for you, you could try to find out which build-dependencies have been already packaged and what we need to do in order to get phoenicis into Debian. There is a tool called mh_make that helps to create a preliminary debian directory. http://collab.debian.net/portal/planet-debian/markus-koschany-pdfsam-how-to-upgrade-a-maven-application-for-debian It is by far not perfect but it might help you to complete this task. Okay, I will take a stab at it. I'm mostly a Python packager but it will be interesting to try some Java. Scott
Bug#953033: Not ready for text-scale-adjust
Package: w3m-el-snapshot X-Debbugs-Cc: yama...@jpl.org Version: 1.4.632+0.20191218.2243.cef0c7e-1 $ emacs -q -f w3m C-x C-= [text-scale-adjust] C-= [anonymous-command] Here the lines get cut off. They should fold, staying on the screen as the text zooms.
Bug#950718: RFS: depthcharge-tools/0.3.1-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
Hey,
Alper Nebi Yasak (2020-03-03):
> I've uploaded a new version of depthcharge-tools to mentors.debian.net.
>
> General changes:
> - New upstream release v0.3.1, set version to 0.3.1-1
> - Use *.{service,init} symlinks to install systemd/init.d files
> - Export build-configuration variables in debian/rules
> - Change GPL-2.0+ to GPL-2+ in debian/copyright
>
> Installer changes:
> - Temporarily disable our initramfs hook if it already exists
> - Fix warning on nonexistent /proc/device-tree/model file
> - Add a template to override machine detection
> - Clarify initramfs compression template (to match my patch at #950086)
>
> Also, it's now possible to test debian-installer integration in a QEMU
> virtual machine with a kernel cmdline like [0], by generating a d-i image
> with localudebs including depthcharge-support-installer and partman-cros,
> and installing both deb packages from this to the target before the
> installer step is run.
>
> [0] console=tty0 priority=low live-installer/enable=false
> partman-cros/enable=true
> depthcharge-support-installer/machine="Google Kevin"
partman-* is of course fine for udebs shipping partman stuff, but
depthcharge-support-installer strikes me as something that could be
named depthcharge-support-udeb, or maybe just depthcharge-udeb?
(Unfortunately I don't have any time to review this more thoroughly to
figure out exactly which part does what etc., but I thought sending
this quick note wouldn't hurt.)
Cheers,
--
Cyril Brulebois (k...@debian.org)
Bug#952669: not an Aegisub bug
reassign 952669 nvidia-graphics-drivers-legacy-390xx severity wishlist retitle 952669 bad interaction between nvidia legacy driver 3900xx and wxWidgets 3.0 when using unsupported GM107 chip thanks Mucking around with my system, I've managed to figure that the wxWidgets UI issue in Aegisub only occurs when this driver is in use on my system. Because I'm not even using a graphics chip in the list of supported ones for this driver (GM107 aka GeForce GTX 750 Ti), I'm lowering the severity to the minimum. (I believe the upgrade process pulled this driver for me through the xserver-xorg-video-all dependency.) Switching to nouveau or to nvidia-driver caused the issue to disappear.
Bug#933301: mpd: systemd service doesn't use user configured UNIX socket since last update
On 2020/03/03 15:25, Simon Désaulniers wrote: > Hi, > > I have gone back working on this issue and I can confirm that the issue is due > to the socket. It seems like this "socket" unit is disabling usage of a Unix > socket in favor of a TCP socket. What do you recommend for someone who wants > to > use a UNIX socket? Should I edit the socket file in some way or simply disable > it? You can use a systemd drop-in to add more listener addresses, instead of editing the original unit file.
Bug#952895: php7.3-fpm: Can't install/upgrade on system with elogind (forced init switch)
On Sun, 1 Mar 2020 17:02:29 +0100 =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= wrote: > Control: severity -1 wishlist > > Hi Lorenzo, > > not until opentmpfiles provides unified interface. I am not adding more shell > spaghetti anywhere if I can help it. > > systemd does not enforce systemd-sysv package installation. Use > --no-install-recommends with apt. > This is correct. The systemd/systemd-sysv package split is made in a way that you can safely install systemd without causing a switch of the init system. Unfortunately this is torpedoed by elogind which decided it's a good idea to conflict/replace libsystemd0/systemd [1]. What you see is a fallout from that decision. Regards, Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940034#300 signature.asc Description: OpenPGP digital signature
