Bug#827611: No automatic log-out of ssh connected users when switching from ISC dhcp client to dhcpcd
Control: reopen -1 Control: reassign -1 dhcpcd5 On Sb, 03 aug 19, 09:47:05, andreimpope...@gmail.com wrote: > On Sb, 18 iun 16, 17:34:58, Comer352L wrote: > > Package: dhcpcd > > Version: 6.0.5-2 > > > > When switching from the ISC dhcp client to dhcpcd (uninstalling packages > > isc-dhcp-client, isc-dhcp-common, installing package dhcpcd5) > > users which are logged in via SSH are no longer logged out automatically > > when the system is shut down. > > Switching back to isc-dhcp-client restores the correct behavior. > > This package was removed from Debian (see #743218) as it was superseded > by a newer version. Never mind, the version suggests this was intended for dhcpd5 in jessie. > In case you can reproduce this behaviour with the current version of > dhcpcd please feel free to reopen and reassign as needed. Reproducing this with newer version of dhcpcd5 would still be useful though. Kind regards, Andrei -- Looking after bugs reported against inexistent or removed packages signature.asc Description: PGP signature
Bug#933768: ITP: golang-github-anacrolix-ffprobe-dev -- Go ffprobe wrapper
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-anacrolix-ffprobe-dev Version : 1.0.0 Upstream Author : Matt Joiner * URL : https://github.com/anacrolix/ffprobe * License : Mozilla Public License 2.0 Programming Lang: Go Description : Go ffprobe wrapper Go ffprobe wrapper Required by github.com/anacrolix/dms, which provides a UPnP DLNA Digital Media Server used by the latest versions of rclone. To be maintained by the Go Packaging Team.
Bug#933767: ibus: New upstream version available
Package: ibus Version: 1.5.19-4+b1 Severity: wishlist New upstream version 1.5.20 is available. This version introduces a new API for resolving years-long Korean Hangul input issue(s). Releasing it early will help ibus-hangul development. :)
Bug#905206: profnet: autopkgtest regression
Control: tags -1 forwarded assist...@rostlab.org
Bug#932717: RFS: blastem/0.6.3.2-2 -- Fast and accurate Genesis emulator
Hi Tobias, > there are not enough changes in the package that warrant an upload: > Changing compat level handling as only change is not enough… Got it, I sent a new version of the emulator to mentors.d.n with minor upstream fixes.[1] > However, there is bug #926498 … You probably want to fix that bug, > giving you the reason you need to justify an upload ;-) Cool, I was trying to close this bug, but it wasn't closed. In fact, my justification was not correct. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933763 Thanks! -- ⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao] ⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao ⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780 ⠈⠳⣄⠀⠀⠀ 2157 630B D441 A775 BEFF D35F FA63 ADA6 B638 B780 signature.asc Description: This is a digitally signed message part
Bug#905206: profnet: autopkgtest regression
Control: tags -1 upstream Control: tags -1 forwarded profnet: autopkgtest regression Hi, please have a look at a bug in the Debian package of profnet: https://bugs.debian.org/905206 There is an issue in profnet_snapfun: profnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct none Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f43bb9da8b0 in ??? #1 0x7f43bb9d9ae3 in ??? #2 0x7f43bb65483f in ??? at /build/glibc-vjB4T1/glibc-2.28/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 #3 0x7f43bbbd104a in ??? #4 0x7f43bbbd21fd in ??? #5 0x7f43bbbd5390 in ??? #6 0x7f43bbbd691c in ??? #7 0x7f43bbbd3a98 in ??? #8 0x5569142ab3fd in ??? #9 0x5569142acc64 in ??? #10 0x5569142b5a8d in ??? #11 0x5569142a425e in ??? #12 0x7f43bb64109a in __libc_start_main at ../csu/libc-start.c:308 #13 0x5569142a4299 in ??? #14 0x in ??? Segmentation fault Unfortunately we have no idea how to fix this. Kind regards Andreas. -- http://fam-tille.de
Bug#933051: Updating the mlterm Uploaders list
Hi, On Fri, 26 Jul 2019 09:30:16 +0200 أحمد المحمودي wrote: > I will set myself as Maintainer and add you to Uploaders, is this > alright ? Sure! -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp http://wiki.debian.org/HidekiYamane
Bug#933766: ITP: roct-thunk-interface -- HSA Kernel Mode Thunk library for AMD KFD support
Package: wnpp Severity: wishlist Owner: Timo Aaltonen * Package name: roct-thunk-interface Version : 2.6.0 Upstream Author : Advanced Micro Devices, Inc. * URL : https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface * License : MIT Programming Lang: C Description : HSA Kernel Mode Thunk library for AMD KFD support HSA Kernel Mode Thunk library contains the user-mode API interfaces used to interact with the ROCk driver. This is part or ROCm - Open Source Platform for HPC and Ultrascale GPU Computing .
Bug#933714: mate-panel: Browsing impossible through the applets
Le 02/08/2019 à 16:34, Mike Gabriel a écrit : The issue needs to be addressed upstream. Once they have a sanctioned patch, I can cherry-pick it into the mate-panel Debian package. The issue is addressed upstream and fixed, see https://github.com/mate-desktop/mate-panel/issues/952 (The upstream title wasn't clear but this is this issue) Best regards, Alex.
Bug#933765: querybts: edit retrieves original submitter message
Package: reportbug Version: 7.5.2 Severity: normal Dear reportbug Maintainer, When using 'e' in the list of bugs querybts retrieves the original e-mail sent by the reporter, instead of the message processed by the BTS. This is not very useful because its missing the Reply-To: header and the bug number in the Subject. If order to reply to the message (e.g. to provide more information or triage the bug) one has to lookup the bug number separately. Retrieving the message processed by the BTS (as 'bts --mbox show' does) would be much more useful. Severity set to 'normal' as it impairs somewhat the usability of querybts (both stand-alone and within reportbug). Kind regards, Andrei -- Package-specific info: ** Environment settings: DEBEMAIL="andreimpope...@gmail.com" DEBFULLNAME="Andrei POPESCU" INTERFACE="text" ** /home/amp/.reportbugrc: reportbug_version "7.5.2" mode expert ui text no-cc list-cc-me smtphost reportbug.debian.org mbox_reader_cmd 'neomutt -F .config/neomutt/gmail_muttrc -e "set signature=~/.sig-unk" -f %s' -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 3.18.0-19346-g9ff80f5e4c97 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8), LANGUAGE=ro_RO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages reportbug depends on: ii apt1.8.2 ii python33.7.3-1 ii python3-reportbug 7.5.2 ii sensible-utils 0.0.12 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn dlocate pn emacs24-bin-common | emacs25-bin-common ii file 1:5.35-4 ii gnupg2.2.12-1 pn postfix | exim4 | mail-transport-agent pn python3-urwid pn reportbug-gtk ii xdg-utils1.1.3-1 Versions of packages python3-reportbug depends on: ii apt1.8.2 ii file 1:5.35-4 ii python33.7.3-1 ii python3-apt1.8.4 ii python3-debian 0.1.35 ii python3-debianbts 2.8.2 ii python3-requests 2.21.0-1 python3-reportbug suggests no packages. -- no debconf information
Bug#604054: if hyperref is loaded before glossaries then text size is adapted wrongly
Control: forwarded 604054 https://github.com/ho-tex/hyperref/issues/46
Am 19.11.2010 um 21:16 teilte jaakov jaakov mit:
> Consider the following latex code:
>
> \documentclass{article}
> \usepackage{hyperref}
> \usepackage[style=long3colheader]{glossaries}
> \newglossaryentry{N}{name={N}, description={N}}
> \begin{document}
> $\gls{N}_{\gls{N}}$
> \end{document}
>
> Both occurencies of N are generated same size, which is incorrect.
>
> When hyperref is commented out, the second occurence of N is generated
> smaller, the way it should be for the lower index.
>
> Please correct the packages.
>
Problem seems to be in hyperref, as it also reproduces, when glossaries
is not used:
\documentclass{article}
\usepackage[colorlinks]{hyperref}
\begin{document}
$a_{\hyperlink{target}{u}}\qquad a_{u}$
\end{document}
Further it seems to be known in upstream. Marking as forwarded.
H.
--
sigfault
#206401 http://counter.li.org
signature.asc
Description: OpenPGP digital signature
Bug#933764: stretch-pu: package e2fsprogs/1.44.5-1+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
This uplaod is to fix the important bug, #920767.
The debdiff is attached below.
diff -Nru e2fsprogs-1.44.5/debian/changelog e2fsprogs-1.44.5/debian/changelog
--- e2fsprogs-1.44.5/debian/changelog 2018-12-15 22:46:49.0 -0500
+++ e2fsprogs-1.44.5/debian/changelog 2019-08-02 23:49:00.0 -0400
@@ -1,3 +1,9 @@
+e2fsprogs (1.44.5-1+deb9u1) stretch; urgency=medium
+
+ * Fix e4defrag crashes on 32-bit architectures (Closes: #920767)
+
+ -- Theodore Y. Ts'o Fri, 02 Aug 2019 23:49:00 -0400
+
e2fsprogs (1.44.5-1) unstable; urgency=medium
* New upstream version
diff -Nru e2fsprogs-1.44.5/debian/gbp.conf e2fsprogs-1.44.5/debian/gbp.conf
--- e2fsprogs-1.44.5/debian/gbp.conf2018-12-15 22:46:49.0 -0500
+++ e2fsprogs-1.44.5/debian/gbp.conf2019-08-02 23:49:00.0 -0400
@@ -1,4 +1,4 @@
[DEFAULT]
pristine-tar = True
upstream-tag='v%(version)s'
-debian-branch=debian/master
+debian-branch=debian/stable
diff -Nru e2fsprogs-1.44.5/debian/.gitignore e2fsprogs-1.44.5/debian/.gitignore
--- e2fsprogs-1.44.5/debian/.gitignore 1969-12-31 19:00:00.0 -0500
+++ e2fsprogs-1.44.5/debian/.gitignore 2019-08-02 23:49:00.0 -0400
@@ -0,0 +1 @@
+!patches
diff -Nru
e2fsprogs-1.44.5/debian/patches/revert-e4defrag-use-64-bit-counters-to-t.patch
e2fsprogs-1.44.5/debian/patches/revert-e4defrag-use-64-bit-counters-to-t.patch
---
e2fsprogs-1.44.5/debian/patches/revert-e4defrag-use-64-bit-counters-to-t.patch
1969-12-31 19:00:00.0 -0500
+++
e2fsprogs-1.44.5/debian/patches/revert-e4defrag-use-64-bit-counters-to-t.patch
2019-08-02 23:49:00.0 -0400
@@ -0,0 +1,66 @@
+From: Theodore Ts'o
+Date: Thu, 3 Jan 2019 22:27:37 -0500
+X-Dgit-Generated: 1.44.5-1 622e62942104d357912480e49c5b5524588cf45f
+Subject: Revert "e4defrag: use 64-bit counters to track # files defragged"
+
+This reverts commit 3293ea9ecbe1d622f9cf6c41d705d82fbae6a3e3.
+
+This wasn't really the right fix, since there can't be more than 2**32
+files in a file system. The real issue is when the number of files in
+a directory change during the e4defrag run.
+
+Signed-off-by: Theodore Ts'o
+
+---
+
+--- e2fsprogs-1.44.5.orig/misc/e4defrag.c
e2fsprogs-1.44.5/misc/e4defrag.c
+@@ -169,13 +169,13 @@ static int block_size;
+ static intextents_before_defrag;
+ static intextents_after_defrag;
+ static intmode_flag;
+-static uid_t current_uid;
+-static unsigned long long defraged_file_count;
+-static unsigned long long frag_files_before_defrag;
+-static unsigned long long frag_files_after_defrag;
+-static unsigned long long regular_count;
+-static unsigned long long succeed_cnt;
+-static unsigned long long total_count;
++static unsigned int current_uid;
++static unsigned int defraged_file_count;
++static unsigned int frag_files_before_defrag;
++static unsigned int frag_files_after_defrag;
++static unsigned int regular_count;
++static unsigned int succeed_cnt;
++static unsigned int total_count;
+ static __u8 log_groups_per_flex;
+ static __u32 blocks_per_group;
+ static __u32 feature_incompat;
+@@ -1912,9 +1912,9 @@ int main(int argc, char *argv[])
+ }
+ /* File tree walk */
+ nftw64(dir_name, file_defrag, FTW_OPEN_FD, flags);
+- printf("\n\tSuccess:\t\t\t[ %llu/%llu ]\n",
+- succeed_cnt, total_count);
+- printf("\tFailure:\t\t\t[ %llu/%llu ]\n",
++ printf("\n\tSuccess:\t\t\t[ %u/%u ]\n", succeed_cnt,
++ total_count);
++ printf("\tFailure:\t\t\t[ %u/%u ]\n",
+ total_count - succeed_cnt, total_count);
+ if (mode_flag & DETAIL) {
+ printf("\tTotal extents:\t\t\t%4d->%d\n",
+@@ -1923,10 +1923,12 @@ int main(int argc, char *argv[])
+ printf("\tFragmented percentage:\t\t"
+ "%3llu%%->%llu%%\n",
+ !regular_count ? 0 :
+- (frag_files_before_defrag * 100) /
++ ((unsigned long long)
++ frag_files_before_defrag * 100) /
+ regular_count,
+ !regular_count ? 0 :
+- (frag_files_after_defrag * 100) /
++ ((unsigned long long)
++ frag_files_after_defrag * 100) /
+ regular_count);
+ }
+ break;
diff -Nru e2fsprogs-1.44.5/debian/patches/series
e2fsprogs-1.44.5/debian/patches/series
--
Bug#933763: RFS: blastem/0.6.3.3-1 -- Fast and accurate Genesis emulator
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "blastem" * Package name: blastem Version : 0.6.3.3-1 Upstream Author : Michael Pavone * URL : https://www.retrodev.com/blastem * License : GPL-3+ Section : games It builds those binary packages: blastem - Fast and accurate Genesis emulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/blastem Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/blastem/blastem_0.6.3.3-1.dsc More information about BlastEm can be obtained from https://gitlab.com/coringao/blastem. Changes since the last upload: blastem (0.6.3.3-1) unstable; urgency=medium * New upstream release: 0.6.3.3 * Using new DH level format. Consequently: - debian/compat: removed. + debian/control: changed from 'debhelper' to 'debhelper-compat' in Build-Depends field and bumped level to 12. * debian/control: + Bumped Standards-Version to 4.4.0. Regards, Carlos Donizete Froes [a.k.a coringao]
Bug#933614: Proposed NMU
Thanks. That sounds like a good plan. KEN
Bug#932252: cleanup of /intro/organization
On Wed, Jul 17, 2019 at 9:48 AM Thomas Lange wrote: > I like to clean up /intro/organization, esp. remove some content. > We have to much content on this page, much old and outdated > content. We could move some content to other pages. This page is always going to be outdated, there are only two ways to fix it: Remove all mention of any current members of any team. Automatically generate the membership lists from the canonical data sources. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#933597: qt3d5-examples: qt examples missing important files
Hi Mike! On Fri, 2 Aug 2019 at 22:33, Mike Bird wrote: > > On Fri August 2 2019 11:53:26 Dmitry Shachnev wrote: > > I wonder if it will be better to simply make the *-examples packages > > recommend the *-doc-html packages. (Not depend because the examples > > can be run without qtcreator.) What do you think about this? > > Let me do some more testing here. It might be sufficient just to move > only the various examples-manifest.xml to the examples packages but I > need to do a lot more testing to confirm this. The problem is that there is no "just move" thing. Doc packages are built separately from examples, and we would have to do a fairly lengthy process to sort out those xml files form the rest of the doc. > > I am currently on vacation so I will be able to work on this not > > earlier than in two weeks. But hopefully we can get this fixed before > > Qt 5.12 reaches unstable. > > I believe that there are additional missing dependencies for some > of the examples. Would it be possible for the *examples* packaging > to include a build-time test that the included examples build? That > looks to me to be fairly simple to implement but I'm not a DD so I > may be over-looking something. We currently lack lots of tests because we are very limited in man power. It's not just adding them but also keeping them up to date. That being said please do not hesitate in filling bugs for examples missing dependencies. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#933614: Proposed NMU
thanks! i just checked and the latest upstream release moved to sphinx, so upgrading to that one is probably the best option; i'll get to it in the next few days. On Fri, Aug 2, 2019 at 5:03 PM Kenneth Pronovici wrote: > > I have submitted a merge request with my proposed NMU changes: > > https://salsa.debian.org/python-team/modules/logilab-common/merge_requests/1 > > These are the changes that I would like to upload sometime soon, once > you've had a chance to talk with upstream. > > If upstream decides to convert away from epydoc and just needs some > time to complete that work, let's determine a timeline and we can plan > to merge my changes when the work is done. If there's no particular > plan or timeline, then I would prefer to just make this change now. > Once alternative documentation exists (in whatever format that takes), > you can add it back into the package relatively easily. > > Thanks, > > KEN > > -- > Kenneth J. Pronovici -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#933597: qt3d5-examples: qt examples missing important files
On Fri August 2 2019 11:53:26 Dmitry Shachnev wrote: > I wonder if it will be better to simply make the *-examples packages > recommend the *-doc-html packages. (Not depend because the examples > can be run without qtcreator.) What do you think about this? Let me do some more testing here. It might be sufficient just to move only the various examples-manifest.xml to the examples packages but I need to do a lot more testing to confirm this. > I am currently on vacation so I will be able to work on this not > earlier than in two weeks. But hopefully we can get this fixed before > Qt 5.12 reaches unstable. I believe that there are additional missing dependencies for some of the examples. Would it be possible for the *examples* packaging to include a build-time test that the included examples build? That looks to me to be fairly simple to implement but I'm not a DD so I may be over-looking something. --Mike
Bug#922431: Upstream is confused about Tracing consisting on non-source JS
On Wed, Jul 31, 2019 at 9:45 AM Sascha Wolke wrote: > @mike: If any help to find the sources is required, just name them and i > am going to find them. The sourceless files are in third_party/catapult/tracing, which is now stripped out of the debian source package. Best wishes, Mike
Bug#933734: ALT+LEFT or ALT+RIGHT arrow does not work anymore
so then "rm ~/.config/sakura/sakura.conf " then logout and login and start sakura.. then does not work seems the file are not readable due are not created when sakura starts!?? Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com El vie., 2 de ago. de 2019 a la(s) 19:55, Andreas Ronnquist ( gus...@debian.org) escribió: > What does your ~/.config/sakura/sakura.conf look like? > > I have > > switch_tab_accelerator=8 > > and > > prev_tab_key=Left > next_tab_key=Right > > in it, with the results that I can switch between the tabs using > Alt+Left and Alt+Right. > > What are the values of those settings in your sakura config file? > > /Andreas > gus...@debian.org >
Bug#884974: sdpa: hardcoded mumps runtime dependency
Dear Gianfranco Costamagna, Thank you very much for your support. >From the subsequent message, I understand you kindly applied the modification. I really appreciate your work. Best regards, Makoto Yamashita 2019年8月2日(金) 20:54 Gianfranco Costamagna : > control: tags -1 patch pending > > uploaded in deferred/2 > > G. >
Bug#933319: psgml: depends on old emacs packages
On 08/02/2019 06:47 AM, Gianfranco Costamagna wrote: > control: tags -1 pending > > uploaded in deferred/10 > > G. Thanks!
Bug#933762: Initscript uses wrong PID file directory
Package: kopano-server Version: 8.7.0-3 /etc/init.d/kopano-server uses /var/run/$NAME.pid for $PIDFILE, evaluating to /var/run/kopano-server.pid, which is wrong: 1. /var/run is a symlink to /run, which however is root:root with 755, but a properly configured kopano-server process runs unprivileged (kopano:kopano). 2. The default PID file location provided by the /etc/kopano/server.cfg is /var/run/kopano/server.pid (via pid_file). All Kopano initscripts seem to be affected by this as well. It's likely the best way to correct the initscripts ($PIDFILE) to match with the Kopano default configurations. Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64 GNU/Linux
Bug#933761: AppArmor configuration doesn't cover LDAP
Package: kopano-server Version: 8.7.0-3 The default AppArmor configuration file /etc/apparmor.d/usr.sbin.kopano-server doesn't cover the default LDAP configuration files, which are left by default in /usr/share/kopano/ldap.*.cfg and just included from /etc/kopano/ldap.cfg (which is the Kopano recommendation). Adding "/usr/share/kopano/ldap.*.cfg r," to /etc/apparmor.d/usr.sbin.kopano-server seems to help. Error without the modified AppArmor policy: Aug 3 01:22:19 kernel: [1053287.305384] audit: type=1400 audit(1564788139.240:75): apparmor="DENIED" operation="open" profile="/usr/sbin/kopano-server" name="/usr/share/kopano/ldap.active-directory.cfg" pid=25904 comm=7A2D733A20 requested_mask= "r" denied_mask="r" fsuid=110 ouid=0 Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64 GNU/Linux
Bug#933734: ALT+LEFT or ALT+RIGHT arrow does not work anymore
severity 933734 minor thanks What does your ~/.config/sakura/sakura.conf look like? I have switch_tab_accelerator=8 and prev_tab_key=Left next_tab_key=Right in it, with the results that I can switch between the tabs using Alt+Left and Alt+Right. What are the values of those settings in your sakura config file? /Andreas gus...@debian.org
Bug#933760: Missing /etc/kopano/ldap.cfg
Package: kopano-server Version: 8.7.0-3 After a fresh installation of kopano-server, the default configuration file /etc/kopano/ldap.cfg is missing and there is also no example configuration in /usr/share/doc/kopano-server/example-config/ https://stash.kopano.io/projects/KC/repos/kopanocore/browse/installer/linux/ldap.cfg is the default configuration in question, that is absent in the package. Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64 GNU/Linux
Bug#933759: Missing /etc/kopano/ldap.cfg
Package: kopano-server Version: 8.7.0-3 After a fresh installation of kopano-server, the default configuration file /etc/kopano/ldap.cfg is missing and there is also no example configuration in /usr/share/doc/kopano-server/example-config/ https://stash.kopano.io/projects/KC/repos/kopanocore/browse/installer/linux/ldap.cfg is the default configuration in question, that is absent in the package. Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64 GNU/Linux
Bug#933755: NMU Changes to remove Epydoc and Pychecker
It turns out that moap declares a build dependency on both python-epydoc and pychecker which is not strictly necessary. The code builds fine without either of these packages installed. The only functional difference is that the API documentation is not generated if epydoc is not installed. I have prepared a pull request to remove these dependencies: https://salsa.debian.org/python-team/applications/moap/merge_requests/1 I know I haven't given you much notice on these bugs. I would normally wait a few weeks to give you a chance to respond. However, since this NMU makes only minimal functional changes to your package, I have decided to upload immediately rather than waiting. This lets me keep moving on the removal process for epydoc and pychecker, and at the same time allows me to close the two serious bugs against your package. You can merge these changes whenever it's convenient. KEN
Bug#933597: qt3d5-examples: qt examples missing important files
Hi!
El vie., 2 ago. 2019 15:57, Dmitry Shachnev escribió:
> Hi Mike!
>
> On Wed, Jul 31, 2019 at 02:21:27PM -0700, Mike Bird wrote:
> > Installing various qt*examples packages such as this does not make
> > them visible in qtcreator. This may be because the various
> > examples-manifest.xml (and associated images) are in the doc-html
> > packages (where they do not appear to be used) rather than in
> > the qt*examples packages where they are needed. Installing the
> > doc-html files magically makes the examples appear in qtcreator.
>
> Thanks for bringing this up! I do not use qtcreator myself, so I could
> not notice this bug.
>
I do, but I also have almost the full stack installed, so I never bumped
into it.
> This is a difficult issue for two reasons:
>
> 1) It affects all submodules, not just qt3d (we have 31 *-doc-html
> packages at the moment).
>
> 2) Currently our .install files for the *-doc-html look very simple
> and basically install everything under /usr/share/qt5/doc/{MODULE}.
>
> To fix this, we need to explicitly list all files we want to install,
> except the examples-manifest.xml files, which should go to -examples.
> This is manual work, and it is easy to miss some such files.
>
> I wonder if it will be better to simply make the *-examples packages
> recommend the *-doc-html packages. (Not depend because the examples
> can be run without qtcreator.) What do you think about this?
Putting the xml files along the examples would also prove tricky, as they
are probably bring built with the arch:all build.
So yes, I think a recommendation is the best approach here.
I am currently on vacation so I will be able to work on this not
> earlier than in two weeks. But hopefully we can get this fixed before
> Qt 5.12 reaches unstable.
>
Scarlett should probably be able to goo ahead with this. Scarlett: feel
free to ping me.
>
Bug#933758: moap: Pychecker will be removed
Package: moap Severity: serious Justification: Policy 5.9.2 Hi, This is one of a few packages in the archive that still depend on Pychecker. I have filed a bug with ftp.debian.org to have epydoc removed from unstable. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I apologize for the late notice on this. I filed bugs against all of the dependencies I could find a while ago, but the FTP Master list included some additional packages. If I don't hear back from you, I will NMU a version of your package that removes the build dependency. Thanks, KEN
Bug#772928: [pdftex] Add option -synctex to pdftex(1)
not sure if this is the correct mailing list. It's fine. Subject: [pdftex] Add option -synctex to pdftex(1) Sure, why not. Thanks. -k
Bug#932892: libwayland-server0: wayland crashes when I (un)plug a monitor
Hello, Missatge de Rémi Letot del dia dc., 24 de jul. 2019 a les 12:48: > > Package: libwayland-server0 > Version: 1.17.0-1 > Severity: normal > > Dear Maintainer, > > when I plug or unplug a monitor, my desktop session crashes > and I'm back at the gdm login screen. If I do the same when > at the gdm login screen, it disappears and doesn't come back. > Then I have to restart the pc. > > I have errors in syslog: > > gnome-shell[4078]: segfault at ?? ip sp error 4 in > libwayland-server.so.0.1.0[?+7000] > > I have several errors since I tried multiple combinations, > so I replaced the non constant parts of the error with ??. > > There are probably things that I can do to have better error > messages, but you'll have to guide me :-) > > I'm now using gnome on Xorg, which doesn't crash, so the > problem is with wayland. Thanks for the report! We need more information to really know what's going on. Which monitor are you using? which kind of hardware port are you using for the connection? which graphics card are you using and which driver? Can you report which gnome-shell version are you using? I am currently on a laptop, but next time I get closer to a desktop I'll try to reproduce it. Do I understand correctly that the reproducer is unplug monitor cable from PC and plug it again? > Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), > LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libwayland-server0 depends on: > ii libc62.28-10 > ii libffi6 3.2.1-9 > > libwayland-server0 recommends no packages. > > libwayland-server0 suggests no packages. > > -- no debconf information -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#807383: gcc-doc: Manpage documentation of -l is incorrect
Hello, Missatge de Kai-Uwe Eckhardt del dia dj., 25 de jul. 2019 a les 10:48: > > Hello, > > the manual text has been fixed upstream for gcc-9.1.0. > https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Link-Options.html#Link-Options > > > The linker searches a standard list of directories for the library. The > directories searched include several standard system directories plus > any that you specify with -L. > > Static libraries are archives of object files, and have file names like > liblibrary.a. Some targets also support shared libraries, which > typically have names like liblibrary.so. If both static and shared > libraries are found, the linker gives preference to linking with the > shared library unless the -static option is used. > Thanks for the report, however I feel reluctant to patch gdb-doc documentation since GFDL is considered non-free by Debian. Regards -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#933174: wayland: Brightness bar not displayed when adjusting screen brightness
Hello, Missatge de Conrad J.C. Hughes (for Debian package stuff) del dia ds., 27 de jul. 2019 a les 11:09: > > Source: wayland > Severity: normal > > Dear Maintainer, > > When I operate my laptop's screen brightness buttons, an overlay appears, > usually with a bar showing the current level. Since upgrading to > buster+wayland, the overlay appears, but the bar doesn't: it's always blank. Which laptop is that? On a Dell XPS13 I get the bar displayed. This issue might be unrelated to wayland itself. > Just noticed that this is *not* the case prior to login; I assume that the gdm > greeter doesn't use wayland? gdm greeter uses wayland Regards
Bug#933757: Firefox-esr FTBFS "failed to open: /sbuild-nonexistent/.cargo/.package-cache"
Package: firefox-esr Version: 60.8.0esr-1 Severity: serious x-debbugs-cc: pkg-rust-maintain...@alioth-lists.debian.net While trying to update firefox-esr in raspbian bullseye I ran into a "failed to open: /sbuild-nonexistent/.cargo/.package-cache" error. The failure also shows up on the reproducible builds site for i386 and arm64 so it's not raspbian specific. I suspect it is only reproducible in builds with a nonexistent homedir (as is the standard sbuild configuration). I would guess this was triggered by the recent upload of a new version of cargo. error: failed to acquire package cache lock Caused by: failed to open: /nonexistent/first-build/.cargo/.package-cache Caused by: Permission denied (os error 13) /usr/bin/g++ -o buddhcal.o -c -I/build/1st/firefox-esr-60.8.0esr/build-browser/dist/system_wrappers -include /build/1st/firefox-esr-60.8.0esr/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DU_I18N_IMPLEMENTATION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_LEGACY_CONVERSION -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DU_CHARSET_IS_UTF8 -DU_HAVE_NL_LANGINFO_CODESET=0 -I/build/1st/firefox-esr-60.8.0esr/config/external/icu/i18n -I/build/1st/firefox-esr-60.8.0esr/build-browser/config/external/icu/i18n -I/build/1st/firefox-esr-60.8.0esr/intl/icu/source/common -I/build/1st/firefox-esr-60.8.0esr/build-browser/dist/include -I/usr/include/nspr -I/usr/include/nss -fPIC -DMOZILLA_CLIENT -include /build/1st/firefox-esr-60.8.0esr/build-browser/mozilla-config.h -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-overflow=2 -fno-sized-deallocation -fstack-protector-strong -Wformat -Werror=format-security -fno-schedule-insns2 -fno-lifetime-dse -fno-delete-null-pointer-checks -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O2 -fomit-frame-pointer -frtti -MD -MP -MF .deps/buddhcal.o.pp /build/1st/firefox-esr-60.8.0esr/intl/icu/source/i18n/buddhcal.cpp make[6]: *** [/build/1st/firefox-esr-60.8.0esr/config/rules.mk:979: force-cargo-library-build] Error 101 make[6]: Leaving directory '/build/1st/firefox-esr-60.8.0esr/build-browser/toolkit/library/rust' make[5]: *** [/build/1st/firefox-esr-60.8.0esr/config/recurse.mk:73: toolkit/library/rust/target] Error 2 make[5]: *** Waiting for unfinished jobs
Bug#933756: ITS: conman
Package: conman Version: 0.2.7-1 Severity: important Dear Maintainer, I intend to salvage package conman, which has note been updated since 2015, first upload, despite BTS requests to release updated version. My plan is to add myself as comaintainer and release newer upstream version. Regards
Bug#912303: RFA: libopenhmd -- API and drivers for immersive technology
0.3.0 has been released since the 12th of July, Please update the package to the last release when possible. http://www.openhmd.net/index.php/2019/07/12/openhmd-0-3-0-djungelvral-released/ Thanks Joey Ferwerda OpenHMD On Sun, 2 Dec 2018 21:02:02 -0300 eamanu15 wrote: > HellO! > > > > Thank you for stepping up and adopting the package! > > I've just added you as a maintainer. > > > > Thanks!!! > > Cheers! > Emmanuel
Bug#933572: ncurses-base: Screen corruptions seen when running mutt in a tmux
On Fri, Aug 02, 2019 at 06:30:39PM +0200, Sven Joachim wrote:
> On 2019-08-02 11:50 +0200, Romain Francoise wrote:
>
> > Hi Sven,
> >
> > On Wed, Jul 31, 2019 at 7:57 PM Sven Joachim wrote:
> >> So rin=\E[%p1%dT has been added in sid, apparently because of the
> >> following change in the 20190630 patchlevel:
> >>
> >> ,
> >> | + add a check in tic for paired indn/rin
> >> `
> >
> > Would it be possible to temporarily revert this change in Debian,
>
> I think reverting this particular change is not the right thing, rather
> we should drop "rin" from tmux (which Thomas has already promised) and
> from screen, which tmux still uses (for better or worse) as its default
> value for $TERM.
I see :-)
fwiw, it's been in screen a while. I see it in 3.7.1 (1995).
This comment in patchlevel.h appears to describe the change
* 27.04.94 -- 3.05.10 97801 obscure code support. Linux long
* password workaround.
But it wasn't in the terminal description using these capabilities:
parm_indexindn SFscroll forward #1
lines (P)
parm_rindex rinSRscroll back #1 lines
(P)
...
Parameterized versions of the scrolling sequences are indn and rin
which have the same semantics as ind and ri except that they take one
parameter, and scroll that many lines. They are also undefined except
at the appropriate edge of the screen.
(The non-parameterized ind/ri could have used this, but already
had been assigned to sequences which a VT100 would recognize).
Actually I'd thought the tmux program would select "tmux" if available,
in preference to "screen', but a quick check of the source
code doesn't support that idea.
For example, in options-table.c:
{ .name = "default-terminal",
.type = OPTIONS_TABLE_STRING,
.scope = OPTIONS_TABLE_SERVER,
.default_str = "screen"
},
I'll check for anything I may have overlooked,
and probably add a somewhat longer note, explaining the situation.
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Bug#933747: efl: please build with lua-old on riscv64
On Fri, Aug 02, 2019 at 10:57:25PM +0200, John Paul Adrian Glaubitz wrote: > On 8/2/19 10:50 PM, Aurelien Jarno wrote: > > efl can't be built on riscv64 as it build-depends on libluajit-5.1-dev > > which has not been ported yet on this architecture. As efl is an > > important reverse dependency, would it be possible to adopt the same > > strategy as already done for arm64 and 390x, that is building with > > lua-old instead of luajit? Yes, definitely - thanks for the patch! > Could this be done for *any* architecture that does not support LuaJIT? > > This should include alpha, ia64, hppa, m68k, sh4, sparc64 and x32. Also yes - I'm preparing a 1.22 upload, I'll include a similar change for the other arches without luajit. Ross
Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time
Hi Paul et al., > > Thanks again for your patience and understanding here, Paul. So, it looks like: django-compat django-hijack django-ratelimit django-testscenarios grr python-aws-xray-sdk python-carrot python-django-bootstrap-form python-oauth2client python-semantic-version … still Build-Depend or Build-Depend-Indep on python-django. (Zigo, did you neglect python-oauth2client and python-semantic-version in your mass uploads recently?) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#742767: fonts-texgyre: Termes font in does not render ligatures in evince
Am 27.03.2014 um 06:00 teilte Roland Haas mit: Hi Roland, I'm going through some old bugs. This bug went back and forward and different people identified different root causes (poppler or the fonts itself). In the sample document from the bug report I can't see this issue. Both pieces of software (tex-gyre and poppler) got new upstream releases in the meantime. Are you still able to reproduce the issue? Hilmar >* What led up to the situation? > Updating the system so that fonts-gyrex is used as a replacement for Times. > Possibly due to changes in fontconfig priorities. >* What exactly did you do (or not do) that was effective (or > ineffective)? > Opening a pdf file containing fi or fl ligatures. >* What was the outcome of this action? > fi and fl ligatures do not render correctly, they show up as whitespace but > can > be copied and pasted fine. >* What outcome did you expect instead? > fi and fl should show up. > > This is the same bug (I think) as reported on freedesktop's bug tracking > system: > > https://bugs.freedesktop.org/show_bug.cgi?id=73291 > > where also a link to a sample pdf file is provided. > -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#933697: libuuid1 declared to replace e2fsprogs
Thanks. Though, I'm afraid I jumped to a wrong conclusion from 'apt-cache depends libuuid1' claiming to replace e2fsprogs without showing the version caveat. It's now clearer that my problem comes up in Devuan beowulf but not in Debian buster, and as you already pointed out, this particular thing is rather a non-issue. Ralph. Theodore Y. Ts'o wrote on 3/8/19 1:46 am: > On Fri, Aug 02, 2019 at 02:09:03PM +1000, Ralph Ronnquist wrote: >> Well, >> >> when I then "agt-get install libuuid1:i386" (on this multiarch) >> I get advice about a page full of packages to be removed, and the >> following (plus a bit more): >> --- >> WARNING: The following essential packages will be removed. >> This should NOT be done unless you know exactly what you are doing! >> e2fsprogs libblkid1 (due to e2fsprogs) libuuid1 (due to e2fsprogs) fdisk >> libfdisk1 (due to fdisk) libmount1 (due to fdisk) init >> sysvinit-core (due to init) mount util-linux (due to mount) sysvinit-utils >> > > What version of e2fsprogs did you have on the system at that time? > > - Ted >
Bug#908964: evince: reports "! SyncTeX Error : No file?" at startup
On Sun, Sep 16, 2018 at 08:34:14PM +0100, Julian Gilbey wrote: > evince has recently regularly (always?) started reporting "! SyncTeX > Error : No file?" when I open a PDF to view it. I have no idea why > this would be; the PDF files in question are unrelated to TeX. Given how annoying this is and how simple and risk-free the fix is (a simple one-liner), I was wondering whether it'd be possible to include this in one of the buster/stable point updates. Thanks! Faidon
Bug#933755: moap: Epydoc will be removed
Package: moap Severity: serious Justification: Policy 5.9.2 Hi, This is one of 20+ packages in the archive that still depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I apologize for the late notice on this. I filed bugs against all of the dependencies I could find over 18 months ago, but the FTP Master list included some additional packages. If I don't hear back from you, I will NMU a version of your package that removes the build dependency. I will accomplish this by simply not building the API documentation. If you don't want me to do this, please reply and let me know how you want me to proceed. Thanks, KEN
Bug#929257: stretch-pu: package mariadb-10.1 10.1.41-0+deb9u
(sorry for replying to wrong bug report earlier) Hello! I have now prepared 10.1.41 for upload to Stretch. I am CC'ing security team in case you want this faster in than waiting for the next stable update (planned for 2019-09-07). https://salsa.debian.org/mariadb-team/mariadb-10.1/ *** mariadb-10.1 (10.1.41-0+deb9u1) stretch; urgency=medium * SECURITY UPDATE: New upstream version 10.1.41. Includes fixes for the following security vulnerabilities: - CVE-2019-2737 - CVE-2019-2739 - CVE-2019-2740 - CVE-2019-2805 * Previous release 10.1.39 includes fixes for the following security vulnerabilities: - CVE-2019-2627 - CVE-2019-2614 * Amend previous changelog entries to include newly released CVE numbers. * Gitlab-CI: Sync latest version from Debian Sid but with Stretch adaptions * Uses respolveip from correct path as per upstream fix (Closes: #928758) -- Otto Kekäläinen Fri, 02 Aug 2019 18:10:23 +0100
Bug#933754: buster-pu: package mariadb-10.3 10.3.17-0+deb9u1
Package: release.debian.org Severity: normal Tags: buster, moreinfo User: release.debian@packages.debian.org Usertags: pu MariaDB 10.3.17 includes security fixes and a few bug fixes appropriate for a stable release. This bug report is intentionally void of the debdiff as I might still amend something, or the severity of the security issues might change on further investigation. See buster branch at https://salsa.debian.org/mariadb-team/mariadb-10.3/ Changelog: mariadb-10.3 (1:10.3.17-0+deb9u1) buster; urgency=high * New upstream version 10.3.17. Includes security fixes for: - CVE-2019-2737 - CVE-2019-2739 - CVE-2019-2740 - CVE-2019-2758 - CVE-2019-2805 * Multiple Gitlab-CI/Salsa-CI improvements * Update libmariadb3 symbols to match MariaDB Connector C 3.1 API * Add Lintian override for new test binary wsrep_check_version -- Otto Kekäläinen Fri, 02 Aug 2019 19:46:11 +0100
Bug#933747: efl: please build with lua-old on riscv64
Hi! On 8/2/19 11:39 PM, Ross Vandegrift wrote: >> Could this be done for *any* architecture that does not support LuaJIT? >> >> This should include alpha, ia64, hppa, m68k, sh4, sparc64 and x32. > > Also yes - I'm preparing a 1.22 upload, I'll include a similar change > for the other arches without luajit. Great, thank you. FWIW, could you include powerpc for the time being in this list as well? The package is currently broken on powerpc but I expect that to be fixed in the future again, see [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933752 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#920373: default soundfonts
Fabian Greffrath dixit: >Agreed, then I'll prepare timgm6mb-soundfont for upload now. I just noticed that the soundfont itself is GPLv2… (only?) in mine I use a script that edits the .sf2 to update metadata like author or licence, perhaps you want to embed the licence grant into the soundfont file as well? (I also am, somewhat, working on a MuseScore patch that aggregates those headers from the soundfonts used and puts them into ID3 tags or similar for the generated waveforms so licence compliane is easier.) Do you wish to adapt that? I can commit how I imagine that to work, if you want. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#920373: default soundfonts
Fabian Greffrath dixit: >Agreed, then I'll prepare timgm6mb-soundfont for upload now. Great. I’ve just uploaded mine: • fluidr3mono-gm-soundfont @ 30 • musescore-general-soundfont-small @ 50 • musescore-general-soundfont @ 60 / 70 (for -lossless) I’ll intend to backport at least one, perhaps both, of the musescore-general ones to buster-backports and stretch-backports-sloppy (due to single-note dynamics support) so the new scheme will be available there as well. bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#933750: paleomix: Port to Python3 needed
Control: tags -1 upstream Control: forwarded -1 https://github.com/MikkelSchubert/paleomix/issues/15
Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9
On Fri, 02 Aug 2019 at 19:49:20 +0100, Simon McVittie wrote:
> If you compile test_run_seed() with -O1, and the rest of gtestutils.c
> with -O2, the clutter test hangs.
Binary-searching through the extra optimizations enabled by -O2 [1]
led me to the minimal change being: if you modify test_run_seed() to add
__attribute__((optimize("no-tree-pre")))
then the clutter test passes. Without that attribute it fails.
I have no idea why.
smcv
[1] gcc-9 -Q -O2 --help=optimizers > O2
gcc-9 -Q -O1 --help=optimizers > O1
diff -u O1 O2
From: Simon McVittie
Date: Fri, 2 Aug 2019 20:13:39 +0100
Subject: Disable an optimization when building with gcc 9
This appears to break the clutter autopkgtest, but I don't know why.
Signed-off-by: Simon McVittie
Bug: https://bugs.debian.org/931921
---
glib/gtestutils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/glib/gtestutils.c b/glib/gtestutils.c
index c9bc3dd..0908686 100644
--- a/glib/gtestutils.c
+++ b/glib/gtestutils.c
@@ -1607,6 +1607,9 @@ void
test_built_files_dir = test_argv0_dirname;
}
+#if defined(__GNUC__) && __GNUC__ >= 9 && !defined(__clang__)
+__attribute__((optimize("no-tree-pre")))
+#endif
static void
test_run_seed (const gchar *rseed)
{
Bug#933752: luajit: Patch to add ppc64/ppc64el support breaks powerpc
Source: luajit Version: 2.1.0~beta3+dfsg-5.1 Severity: normal Tags: upstream User: debian-powe...@lists.debian.org Usertags: powerpc Hello! The patch to add support for ppc64/ppc64el breaks the luajit build on powerpc (32-bit PowerPC). After removing the patch, the package builds fine for me again on powerpc. Could the patch maybe applied conditionally, so it's not being used on 32-bit PowerPC? I have already notified upstream about the issue [1]. Thanks, Adrian > [1] https://github.com/LuaJIT/LuaJIT/pull/140#issuecomment-517845750 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#933751: mini-buildd (build-)depends on cruft package.
Package: mini-buildd Version: 1.0.41 Severity: serious python-mini-buildd depends on and the mini-buildd source package build-depends on the python-django-registration binary package which is no longer built by the python-django-registration source package. I notice this already seems to be fixed in experimental, are there any blockers for uploading the experimental version to unstable?
Bug#933750: paleomix: Port to Python3 needed
Package: paleomix Severity: normal The code needs to be ported to Python3. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (501, 'testing'), (500, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages paleomix depends on: pn adapterremoval ii bcftools 1.9-1 ii bedtools 2.27.1+dfsg-4 pn bowtie2 ii bwa 0.7.17-3 pn examl ii mafft7.407-2 pn mapdamage ii phylip 1:3.697+dfsg-1 pn picard-tools ii python 2.7.16-1 pn python-coverage pn python-flexmock ii python-pysam 0.15.2+ds-2 pn python-setproctitle ii r-base-core 3.5.2-1 pn radiant ii raxml8.2.12+dfsg-1 ii samtools 1.9-4 paleomix recommends no packages. paleomix suggests no packages.
Bug#604054: Bug reports on the net
Am 12.09.2013 um 10:06 teilte Jaakov mit: Hi Jaakov, > Same bug: > http://www.dickimaw-books.com/cgi-bin/bugtracker.cgi?action=view&key=39 > https://bugs.launchpad.net/ubuntu/+source/texlive-base/+bug/1223849 > The first one has been closed as invalid, the second one is just a duplication of the Debian bug. I can still reproduce the issue. 1. As pointed out bei "Jean-Christophe Dubacq" (unfortunately only to the debian-tex-maint mailing list): pdflatex produces correct output, meanwhile latex/dvips breaks the document. Is switching to pdflatex an option for you? 2. You said you contact Heiko and Nicola Talbot. Did you ever get a response. Given the fact that pdflatex and latex are the same binary I tend to say that if must be the outpout driver (hdvips.def vs. hpdftex.def) and should be submitted to hyperref. Please be so kind to do that. Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#933614: Proposed NMU
I have submitted a merge request with my proposed NMU changes: https://salsa.debian.org/python-team/modules/logilab-common/merge_requests/1 These are the changes that I would like to upload sometime soon, once you've had a chance to talk with upstream. If upstream decides to convert away from epydoc and just needs some time to complete that work, let's determine a timeline and we can plan to merge my changes when the work is done. If there's no particular plan or timeline, then I would prefer to just make this change now. Once alternative documentation exists (in whatever format that takes), you can add it back into the package relatively easily. Thanks, KEN -- Kenneth J. Pronovici
Bug#933749: fail2ban: ever-growing fail2ban sqlite database
Package: fail2ban
Version: 0.10.2-2.1
Severity: serious
Justification: filing up filesystem, slow startup
Hi,
I've noticed this on both stretch and buster hosts with the default
configuration: the database (/var/lib/fail2ban/fail2ban.sqlite3) doesn't
seem to get any kind of clean-up. I'm seeing this at the moment on those
two internet-connected hosts:
626M /var/lib/fail2ban/fail2ban.sqlite3
940M /var/lib/fail2ban/fail2ban.sqlite3
Toying with sqlite3 and a "select * from bans limit 1;", I'm seeing:
sshd|ANO.NYM.IZ.ED|1519714548|{"matches": ["Feb 27 07:46:29 […]
sshd|ANO.NYM.IZ.ED|1520144221|{"matches": ["Mar 4 07:16:36 […]
(I'm not even sure which year those entries come from…)
The only thing that seems related returns:
Current database purge age is:
`- 86400seconds
which matches this in /etc/fail2ban/fail2ban.conf:
# Options: dbpurgeage
# Notes.: Sets age at which bans should be purged from the database
# Values: [ SECONDS ] Default: 86400 (24hours)
dbpurgeage = 1d
and I'm not sure it's taken into account. Or whether that's meant to
control that the database grows forever.
A cheap workaround might be to switch the dbfile setting to:
dbfile = :memory:
but having to do that seems very wong.
Looking around in the BTS, #823892 and #898536 seemed related but they
were closed already (with inappropriate versions since the BTS doesn't
know about backports anyway?)
Please let me know if I can help debug this further.
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#933747: efl: please build with lua-old on riscv64
Hello! On 8/2/19 10:50 PM, Aurelien Jarno wrote: > efl can't be built on riscv64 as it build-depends on libluajit-5.1-dev > which has not been ported yet on this architecture. As efl is an > important reverse dependency, would it be possible to adopt the same > strategy as already done for arm64 and 390x, that is building with > lua-old instead of luajit? Could this be done for *any* architecture that does not support LuaJIT? This should include alpha, ia64, hppa, m68k, sh4, sparc64 and x32. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#933748: munin-httpd is unable to access new sqlite database
Source: munin Version: 2.999.12-1 Severity: important Tags: upstream Forwarded: https://github.com/munin-monitoring/munin/issues/1212 Hello, since munin 2.999.12 the default settings for new sqlite databases (the default database created automatically after package installation) prevents the database from being accessed by munin-httpd. Thus the web interface is broken (status 500). The issue can be resolved by changing the database journal mode after the file was created: echo "PRAGMA journal_mode=delete;" | su -s /bin/bash -c "sqlite3 /var/lib/munin/datafile.sqlite" munin Upstream is discussing the proper solution for this issue: https://github.com/munin-monitoring/munin/issues/1212 Cheers, Lars
Bug#933747: efl: please build with lua-old on riscv64
Source: efl Version: 1.21.1-5 Severity: wishlist Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 efl can't be built on riscv64 as it build-depends on libluajit-5.1-dev which has not been ported yet on this architecture. As efl is an important reverse dependency, would it be possible to adopt the same strategy as already done for arm64 and 390x, that is building with lua-old instead of luajit? I have tested the patch below, and with it efl builds fine on riscv64. Would it be possible to include it in the next upload? Thanks, Aurelien diff -Nru efl-1.21.1/debian/control efl-1.21.1/debian/control --- efl-1.21.1/debian/control 2019-02-12 18:07:26.0 + +++ efl-1.21.1/debian/control 2019-08-02 16:29:24.0 + @@ -16,7 +16,7 @@ libxcursor-dev, libxss-dev, libxrender-dev, libxinerama-dev, libxrandr-dev, libxext-dev, libxcomposite-dev, libxi-dev, libxdamage-dev, libxtst-dev, libglib2.0-dev, - libluajit-5.1-dev [!arm64 !s390x], liblua5.2-dev [arm64 s390x], libdbus-1-dev, + libluajit-5.1-dev [!arm64 !riscv64 !s390x], liblua5.2-dev [arm64 riscv64 s390x], libdbus-1-dev, libsndfile-dev, libgnutls28-dev, libcurl4-gnutls-dev, libudev-dev [linux-any], libmount-dev [linux-any], libblkid-dev [linux-any], @@ -633,7 +633,7 @@ libharfbuzz-dev, libinput-dev, libjpeg-dev, - libluajit-5.1-dev [!arm64 !s390x], liblua5.2-dev [arm64 s390x], + libluajit-5.1-dev [!arm64 !riscv64 !s390x], liblua5.2-dev [arm64 riscv64 s390x], liblz4-dev, libmount-dev, libpulse-dev, diff -Nru efl-1.21.1/debian/rules efl-1.21.1/debian/rules --- efl-1.21.1/debian/rules 2019-02-12 18:07:26.0 + +++ efl-1.21.1/debian/rules 2019-08-02 16:29:24.0 + @@ -9,7 +9,7 @@ ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf)) arch_flags += --with-opengl=es --enable-egl endif -ifneq (,$(filter $(DEB_HOST_ARCH), arm64 s390x)) +ifneq (,$(filter $(DEB_HOST_ARCH), arm64 riscv64 s390x)) arch_flags += --enable-lua-old dhinstallflags += --exclude=elua endif
Bug#933499: libreoffice-base: database form with subform no longer works with "Data content could not be loaded" error
I'm completely stumped. There must be SQL statement created to
accomplish the link for the subform.
I found error detail on the sql statement. Here is the statement for
one of the errors:
The SQL command leading to this error is:
SELECT * FROM "aquarium"."corrections" WHERE (
"aquarium"."corrections"."testID" = :link_from_ID )
The statement for the other database is:
The SQL command leading to this error is:
SELECT * FROM "running"."workout" WHERE ( "running"."workout"."ID" =
:link_from_workoutID )
For both of these statements the master field is the last portion of
the generated name "ID" for the first and "workoutID" for the second.
Now if that is how the
Now if I run one of those statements directly from the sql view of
query design, I'm asked to provide a parameter. If I provide a valid
value, I get the exact error message that we got before.
Now if I replace the variable name with the parameter I just gave in
the dialogue, I now get the result I expect. So the bug must have to do
with the link parameter not getting replaced with the appropriate
value.
Does this help?
On Thu, 2019-08-01 at 18:31 +0200, Rene Engelhard wrote:
> Hi again,
>
> On Thu, Aug 01, 2019 at 12:04:58AM +0200, Rene Engelhard wrote:
> > On Wed, Jul 31, 2019 at 04:00:04PM -0500, william l-k wrote:
> > >have linked sub-forms from two seperate tables for entering related
> > > data.
> > >One of the databases started out as a libreoffice base then was
> > > converted
> > >to a mariadb connection. The other started out as a connection to
> > > mariadb.
>
> Maybe it's not related at all but connection to mariadb how? MySQL ODBC?
> MySQL JDBC? (both of which are removed because being buggy), MariaDB
> JDBC? Or libreoffice-mysql-connector?
>
> If the latter, 5.2 removed the extension and need for libmysqlcppconn
> but integrated it properly into the "main" packages
> (libreoffice-sdbc-mysql), just using lib{mariadb,mysql}client/libmariadb
> properly.
>
> Maybe it's related to one of those?
>
> Regards,
>
> Rene
Bug#933597: qt3d5-examples: qt examples missing important files
Sent via the Samsung Galaxy Note9, an AT&T 5G Evolution capable smartphone
Original message From: Dmitry Shachnev
Date: 8/2/19 11:53 AM (GMT-07:00) To: Mike Bird ,
933...@bugs.debian.org Subject: Bug#933597: qt3d5-examples: qt examples missing
important files Hi Mike!On Wed, Jul 31, 2019 at 02:21:27PM -0700, Mike Bird
wrote:> Installing various qt*examples packages such as this does not make>
them visible in qtcreator. This may be because the various>
examples-manifest.xml (and associated images) are in the doc-html> packages
(where they do not appear to be used) rather than in> the qt*examples packages
where they are needed. Installing the> doc-html files magically makes the
examples appear in qtcreator.Thanks for bringing this up! I do not use
qtcreator myself, so I couldnot notice this bug.This is a difficult issue for
two reasons:1) It affects all submodules, not just qt3d (we have 31
*-doc-htmlpackages at the moment).2) Currently our .install files for the
*-doc-html look very simpleand basically install everything under
/usr/share/qt5/doc/{MODULE}.To fix this, we need to explicitly list all files
we want to install,except the examples-manifest.xml files, which should go to
-examples.This is manual work, and it is easy to miss some such files.I wonder
if it will be better to simply make the *-examples packagesrecommend the
*-doc-html packages. (Not depend because the examplescan be run without
qtcreator.) What do you think about this?I am currently on vacation so I will
be able to work on this notearlier than in two weeks. But hopefully we can get
this fixed beforeQt 5.12 reaches unstable.Is this something I can help with to
reduce your workload post vacation?Scarlett --Dmitry Shachnev
Bug#933615: NMU Changes
It turns out that kiwi declares a build dependency on python-epydoc which is not necessary - the API documentation already exists and does not need to be regenerated, so epydoc is never used. I have created a merge request for this change: https://salsa.debian.org/python-team/modules/kiwi/merge_requests/2 I know I haven't given you much notice on this bug. I would normally wait a few weeks to give you a chance to respond. However, since this NMU doesn't make any functional changes to your package, I have decided to upload immediately rather than waiting. This lets me keep moving on the epydoc removal process and closes the serious bug against your package. You can merge these changes whenever it's convenient. KEN -- Kenneth J. Pronovici
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Control: tags 890734 + help
Am 01.08.2019 um 15:26 teilte Hilmar Preuße mit:
> Am 01.08.2019 um 14:36 teilte Jerome BENOIT mit:
>> On 01/08/2019 15:10, Hilmar Preuße wrote:
Hi,
>>> We'd have to calculate human readable time and then split it into
>>> strings to populate the variables,
>>
>> This far harder that it looks.
>>
>> if we want to do it right...
>>
>> Anyway, I think the reverse must be done:
>> modify mp_{year,month,day,time} .
>>
> Sorry, I forgot to mention, that strftime() should be able to not
> just display the whole time string, but also just parts of it.
> Therefore it should be not that hard to populate
> mp_{year,month,day,time} and use it later on.
>
Having said this I still repeat: I'm not a C programmer. Especially when
it comes to string manipulation I'm off. I could try to find a good C
lecture, but for know I prefer to tag that bug help in the hope anybody
volunteers to do the job.
H.
--
sigfault
#206401 http://counter.li.org
signature.asc
Description: OpenPGP digital signature
Bug#933618: NMU Patch
I have created a merge request in salsa for my proposed NMU to fix this bug: https://salsa.debian.org/sramacher/python-crypto/merge_requests/1 Since I haven't given you much notice yet, I will wait to upload this NMU for at least a few weeks. If you are OK with the change and want me to NMU sooner than that, or you want to upload your own version of the package rather than my NMU, please let me know. Thanks, KEN -- Kenneth J. Pronovici
Bug#933746: tika: CVE-2019-10094: tackOverflow from Crafted Package/Compressed Files in Apache Tika's RecursiveParserWrapper
Source: tika Version: 1.20-1 Severity: grave Tags: security upstream Control: found -1 1.21-1 Hi, The following vulnerability was published for tika. CVE-2019-10094[0]: | A carefully crafted package/compressed file that, when | unzipped/uncompressed yields the same file (a quine), causes a | StackOverflowError in Apache Tika's RecursiveParserWrapper in versions | 1.7-1.21. Apache Tika users should upgrade to 1.22 or later. 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-10094 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10094 [1] https://www.openwall.com/lists/oss-security/2019/08/02/4 Regards, Salvatore
Bug#933499: libreoffice-base: database form with subform no longer works with "Data content could not be loaded" error
Both forms now no longer change properly when the record is changing on
the main form. Now, both databases display the first record in the
table for the subform for every record in the main table. I'll toy with
this to see why one direction is behaves badly and the other just
throws an error.
On Thu, 2019-08-01 at 18:31 +0200, Rene Engelhard wrote:
> Hi again,
>
> On Thu, Aug 01, 2019 at 12:04:58AM +0200, Rene Engelhard wrote:
> > On Wed, Jul 31, 2019 at 04:00:04PM -0500, william l-k wrote:
> > >have linked sub-forms from two seperate tables for entering related
> > > data.
> > >One of the databases started out as a libreoffice base then was
> > > converted
> > >to a mariadb connection. The other started out as a connection to
> > > mariadb.
>
> Maybe it's not related at all but connection to mariadb how? MySQL ODBC?
> MySQL JDBC? (both of which are removed because being buggy), MariaDB
> JDBC? Or libreoffice-mysql-connector?
>
> If the latter, 5.2 removed the extension and need for libmysqlcppconn
> but integrated it properly into the "main" packages
> (libreoffice-sdbc-mysql), just using lib{mariadb,mysql}client/libmariadb
> properly.
>
> Maybe it's related to one of those?
>
> Regards,
>
> Rene
Bug#933745: tika: CVE-2019-10093: Denial of Service in Apache Tika's 2003ml and 2006ml Parsers
Source: tika Version: 1.20-1 Severity: important Tags: security upstream Control: found -1 1.21-1 Hi, The following vulnerability was published for tika. CVE-2019-10093[0]: | In Apache Tika 1.19 to 1.21, a carefully crafted 2003ml or 2006ml file | could consume all available SAXParsers in the pool and lead to very | long hangs. Apache Tika users should upgrade to 1.22 or later. 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-10093 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10093 [1] https://www.openwall.com/lists/oss-security/2019/08/02/3 Regards, Salvatore
Bug#933499: libreoffice-base: database form with subform no longer works with "Data content could not be loaded" error
The connection type is MYSQL(native). In the wayback I vaguely remember
using the JDBC connection type. I believe I switched the oldest to
MYSQL(native) to solve a problem with complex querys. The newest
database affected started with MYSQL(native).
Perhaps the clue is in the error states verbatum:
The data content could not be loaded. You have an error in your SQL
syntax; check the manual that corresponds to your MariaDB server
version for the right syntax to use near ':link_from_ID )'.
Data is displayed for the parent table. It does not display for the
subform.
I just checked the form properties for the subform. The link fields had
the slave in the masters position and visa versa. I flipped the order
and tested the form, and voila, it works.
The wierd thing is, it had been working fine for years. If the order
had always been reversed
I checked the second table and got the exact same error message. Made
the identical changes on this form and ta da! Everything works.
Maybe everything working before was the bug? This is fixed for me, just
leaving me curious as to exactly which change led to the problem.
Thanks for your help.
On Thu, 2019-08-01 at 18:31 +0200, Rene Engelhard wrote:
> Hi again,
>
> On Thu, Aug 01, 2019 at 12:04:58AM +0200, Rene Engelhard wrote:
> > On Wed, Jul 31, 2019 at 04:00:04PM -0500, william l-k wrote:
> > >have linked sub-forms from two seperate tables for entering related
> > > data.
> > >One of the databases started out as a libreoffice base then was
> > > converted
> > >to a mariadb connection. The other started out as a connection to
> > > mariadb.
>
> Maybe it's not related at all but connection to mariadb how? MySQL ODBC?
> MySQL JDBC? (both of which are removed because being buggy), MariaDB
> JDBC? Or libreoffice-mysql-connector?
>
> If the latter, 5.2 removed the extension and need for libmysqlcppconn
> but integrated it properly into the "main" packages
> (libreoffice-sdbc-mysql), just using lib{mariadb,mysql}client/libmariadb
> properly.
>
> Maybe it's related to one of those?
>
> Regards,
>
> Rene
Bug#933744: tika: CVE-2019-10088: OOM from a crafted Zip File in Apache Tika's RecursiveParserWrapper
Source: tika Version: 1.21-1 Severity: grave Tags: security upstream Control: found -1 1.20-1 Hi, The following vulnerability was published for tika. CVE-2019-10088[0]: | A carefully crafted or corrupt zip file can cause an OOM in Apache | Tika's RecursiveParserWrapper in versions 1.7-1.21. Users should | upgrade to 1.22 or later. 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-10088 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10088 [1] https://www.openwall.com/lists/oss-security/2019/08/02/2 Regards, Salvatore
Bug#933616: NMU Patch
Hi, Attached is the patch for my NMU. Since I haven't given you much notice yet, I will wait to upload this NMU for at least a few weeks. If you are OK with the change and want me to NMU sooner than that, or you want to upload your own version of the package rather than my NMU, please let me know. Thanks, KEN -- Kenneth J. Pronovici nmu-remove-epydoc.patch Description: Binary data
Bug#933743: LibXSLT in Debian stable has three unpatched security vulnerabilities
Package: libxslt1.1 Version: 1.1.32-2 Severity: grave The upstream version of LibXSLT shipped in Debian stable (1.1.32) has the following three CVEs reported against it: https://nvd.nist.gov/vuln/detail/CVE-2019-11068 https://nvd.nist.gov/vuln/detail/CVE-2019-13117 https://nvd.nist.gov/vuln/detail/CVE-2019-13118 Debian has taken notice of these, but has only patched them in jessie (a.k.a. oldoldstable): https://lists.debian.org/debian-lts-announce/2019/04/msg00016.html https://lists.debian.org/debian-lts-announce/2019/07/msg00020.html The current jessie package version of LibXSLT (1.1.28-2+deb8u5) contains the following patch files: CVE-2019-11068.patch CVE-2019-13117.patch CVE-2019-13118.patch These are not present in 1.1.32-2, and so these vulnerabilities appear to be exploitable in Debian stable, testing, and sid. The current upstream release of LibXSLT is 1.1.33, which unfortunately still has the above three CVEs. However, they appear to have been patched in Git.
Bug#933741: qemu: CVE-2019-14378: heap buffer overflow during packet reassembly
Control: retitle 933741 qemu: CVE-2019-14378: heap buffer overflow during packet reassembly Control: retitle 933742 slirp4netns: CVE-2019-14378: heap buffer overflow during packet reassembly Hi Ups, used the wrong CVE. The correct one is actually CVE-2019-14378, sorry about that. Regards, Salvatore
Bug#933617: NMU
I will upload my NMU later today. Changes are captured in a merge request on salsa: https://salsa.debian.org/python-team/modules/pyinotify/merge_requests/1 KEN -- Kenneth J. Pronovici
Bug#933741: qemu: CVE-2019-14459: heap buffer overflow during packet reassembly
Source: qemu Version: 1:3.1+dfsg-8 Severity: grave Tags: security upstream Control: clone -1 -2 Control: reassign -2 src:slirp4netns 0.3.1-1 Control: retitle -2 slirp4netns: CVE-2019-14459: heap buffer overflow during packet reassembly Hi, The following vulnerability was published for qemu (respective the SLiRP networking implemenatation which is as well forked in slirp4netns). CVE-2019-14378[0]: | ip_reass in ip_input.c in libslirp 4.0.0 has a heap-based buffer | overflow via a large packet because it mishandles a case involving the | first fragment. 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-14378 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14378 [1] https://gitlab.freedesktop.org/slirp/libslirp/commit/126c04acbabd7ad32c2b018fe10dfac2a3bc1210 [2] https://www.openwall.com/lists/oss-security/2019/08/01/2 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#928758: [debian-mysql] Bug#928758: Bug#928758: mariadb-server: mysql_install_db fails if basedir option isn't set, expecting resolveip to be present in /usr/sbin/
Hello! I have now prepared 10.1.41 for upload to Stretch. I am CC'ing security team in case you want this faster in than waiting for the next stable update (planned for 2019-09-07). https://salsa.debian.org/mariadb-team/mariadb-10.1/ *** mariadb-10.1 (10.1.41-0+deb9u1) stretch; urgency=medium * SECURITY UPDATE: New upstream version 10.1.41. Includes fixes for the following security vulnerabilities: - CVE-2019-2737 - CVE-2019-2739 - CVE-2019-2740 - CVE-2019-2805 * Previous release 10.1.39 includes fixes for the following security vulnerabilities: - CVE-2019-2627 - CVE-2019-2614 * Amend previous changelog entries to include newly released CVE numbers. * Gitlab-CI: Sync latest version from Debian Sid but with Stretch adaptions * Uses respolveip from correct path as per upstream fix (Closes: #928758) -- Otto Kekäläinen Fri, 02 Aug 2019 18:10:23 +0100
Bug#933597: qt3d5-examples: qt examples missing important files
Hi Mike!
On Wed, Jul 31, 2019 at 02:21:27PM -0700, Mike Bird wrote:
> Installing various qt*examples packages such as this does not make
> them visible in qtcreator. This may be because the various
> examples-manifest.xml (and associated images) are in the doc-html
> packages (where they do not appear to be used) rather than in
> the qt*examples packages where they are needed. Installing the
> doc-html files magically makes the examples appear in qtcreator.
Thanks for bringing this up! I do not use qtcreator myself, so I could
not notice this bug.
This is a difficult issue for two reasons:
1) It affects all submodules, not just qt3d (we have 31 *-doc-html
packages at the moment).
2) Currently our .install files for the *-doc-html look very simple
and basically install everything under /usr/share/qt5/doc/{MODULE}.
To fix this, we need to explicitly list all files we want to install,
except the examples-manifest.xml files, which should go to -examples.
This is manual work, and it is easy to miss some such files.
I wonder if it will be better to simply make the *-examples packages
recommend the *-doc-html packages. (Not depend because the examples
can be run without qtcreator.) What do you think about this?
I am currently on vacation so I will be able to work on this not
earlier than in two weeks. But hopefully we can get this fixed before
Qt 5.12 reaches unstable.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#627357: gnome-desktop-environment: I would like to remove avahi-daemon because mdns slows down PTR lookup
Control: reassign -1 libnss-mdns On Lu, 01 oct 12, 11:20:43, Karl O. Pinc wrote: > On 10/01/2012 02:26:25 AM, Simon McVittie wrote: > > On Thu, 19 May 2011 at 16:11:07 -0500, Karl O. Pinc wrote: > > > gnome-desktop-environment depends on gnome-user-share which, > > > eventually, depends on avahi-daemon. MDNS greatly slows down > > reverse > > > dns (PTR) lookups > > > > You should be able to address this without changes to the metapackage > > by removing libnss-mdns, which is recommended by avahi-daemon, but > > leaving avahi-daemon installed and running. Result: Avahi continues > > to work if applications like gnome-user-share explicitly use it > > (via libavahi-* or direct use of its D-Bus API), but you can no > > longer > > resolve through Avahi via the glibc name service switch API (so > > "ping foo.local" will no longer work). > > > > Removing mdns from nsswitch.conf but leaving mdns4_minimal might also > > be worth considering for your situation: mdns4_minimal will only > > resolve hostnames that match *.local or 169.254.*.*, and only with > > IPv4. > > Thanks for the response. > > Perhaps a note in README.Debian is called for? The gnome-desktop-environment meta-package doesn't exist anymore, so this bug is currently not assigned to any package. If my understanding is correct your suggestion for a note in README.Debian applies to libnss-mdns, so I'm reassigning accordingly. Kind regards, Andrei -- Looking after bugs reported against inexistent or removed packages signature.asc Description: PGP signature
Bug#933740: nfdump: CVE-2019-14459
Source: nfdump Version: 1.6.17-1 Severity: important Tags: security upstream Forwarded: https://github.com/phaag/nfdump/issues/171 Hi, The following vulnerability was published for nfdump. CVE-2019-14459[0]: | nfdump 1.6.17 and earlier is affected by an integer overflow in the | function Process_ipfix_template_withdraw in ipfix.c that can be abused | in order to crash the process remotely (denial of service). 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-14459 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14459 [1] https://github.com/phaag/nfdump/issues/171 [2] https://github.com/phaag/nfdump/commit/3b006ededaf351f1723aea6c727c9edd1b1fff9b Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9
On Fri, 02 Aug 2019 at 11:41:05 +0100, Iain Lane wrote:
> For the record: at Debconf doko suggested to me that a way to start
> debugging this from the GCC end would be to produce one working and one
> "broken" build of the same version of glib2.0, and then copy object
> files from the broken to the working one until that too becomes broken.
> That sounded long / tedious / fiddly so we didn't manage to get round to
> doing it while we were both there, unfortunately.
This is not straightforward in the Meson/Ninja build system, but what I
could do was to hack build.ninja to compile different files with different
compilers, which narrowed it down to gtestutils.c (?!).
Playing with #pragma GCC optimize ("O1") and #pragma GCC optimize ("O2")
I was able to narrow it down further, to this:
If you compile test_run_seed() with -O1, and the rest of gtestutils.c
with -O2, the clutter test hangs.
(But I need to test that minimal change in a clean build to make sure
that's really true and not being affected by other hacks.)
smcv
Bug#933317: yc-el: depends on old emacs packages
On Fri, 2 Aug 2019 13:42:46 +0200 Gianfranco Costamagna wrote: > control: tags -1 pending > diff refined and uploaded in deferred/5 Since the yc-el package is orphaned, you should do a QA upload instead of a delayed NMU. Andreas
Bug#914348: [PATCH] daxctl: link against libndctl, in case its use doesn't get pruned
On Fri, Aug 02, 2019 at 05:15:21PM +, Verma, Vishal L wrote: > On Thu, 2019-08-01 at 03:00 +0200, Adam Borowski wrote: > > util/json.c uses libndctl symbols, and is included by daxctl. These > > functions should then get pruned as unused, but on some platforms the > > toolchain fails to do so. > > this has been requested in https://bugs.debian.org/914348 > Thanks for the report and the patch - however, historically, we've > avoided linking from daxctl to libndctl. > > I think we can still avoid this by moving the libndctl users in > util/json.c and util/filter.c into respective ndctl/util/ files. > > The same goes for libdaxctl users in those files - they move into > daxctl/util/ > > I think that would be a cleaner approach, and I can take a shot at > making the split next week, however we're close to a v66 release, and it > will have to be after that happens. > > Perhaps the debian package can temporarily carry your patch for the > archs that fail? Sounds like a plan. CCing the bug. Breno: could you please take this patch for v65 or v66, until it gets done a better (but more intrusive) way? 喵! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Bug#910917: ICT-Admin-aopd.veneto.it
Commissione postale superata Stato dello spazio assegnato: da aumentare a 150,00 MB (150,00%) Servizio Webmail.aopd.veneto.it Hai superato il limite della casella di posta stabilito dal tuo Web servizio e avrai problemi a inviare e ricevere e-mail, tu potrebbe perdere tutte le informazioni quando l'account è disabilitato. Evitare questo, è necessario inviare il nome utente e le password in modo che il tuo web l'account può essere attivato. Nome e cognome: Identificazione della posta: Password email: Data di nascita: Saluti, servizio web Copyright @ 2019 aopd.veneto.itTutti i diritti riservati
Bug#933739: setuptools_scm can't parse version "debian/1.9-4"
Source: setuptools-scm
Severity: important
Dear maintainer,
setuptools_scm has a trouble parsing git tags like "debian/1.9-4",
because the regexp isn't permissive enough.
This prevents to build some packages like fava without modifying
setup.py or setup.cfg to not fetch the version from git tags.
See the following build log:
.-(19:42:17)-(~/git/debian/python-team/applications/fava/fava)(git)-[fava/debian/master]-(becue@dawaj)-
`---> sbuild -As
dpkg-source: info: using options from fava/debian/source/options:
--extend-diff-ignore=^[^/]+.egg-info/
dh clean --with python3 --buildsystem=pybuild
debian/rules override_dh_auto_clean
make[1]: Entering directory
'/home/becue/git/debian/python-team/applications/fava/fava'
dh_auto_clean
I: pybuild base:217: python3.7 setup.py clean
/usr/lib/python3/dist-packages/setuptools_scm/version.py:92: UserWarning: tag
'debian/1.9-4' no version found
warnings.warn("tag %r no version found" % (tag,))
/usr/lib/python3/dist-packages/setuptools_scm/version.py:92: UserWarning: tag
'debian/1.9-4' no version found
warnings.warn("tag %r no version found" % (tag,))
Traceback (most recent call last):
File "setup.py", line 7, in
setup()
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 145, in
setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.7/distutils/core.py", line 121, in setup
dist.parse_config_files()
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 705, in
parse_config_files
ignore_option_errors=ignore_option_errors)
File "/usr/lib/python3/dist-packages/setuptools/config.py", line 120, in
parse_configuration
meta.parse()
File "/usr/lib/python3/dist-packages/setuptools/config.py", line 425, in parse
section_parser_method(section_options)
File "/usr/lib/python3/dist-packages/setuptools/config.py", line 398, in
parse_section
self[name] = value
File "/usr/lib/python3/dist-packages/setuptools/config.py", line 183, in
__setitem__
value = parser(value)
File "/usr/lib/python3/dist-packages/setuptools/config.py", line 516, in
_parse_version
version = version()
File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 144,
in get_version
parsed_version = _do_parse(config)
File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 95, in
_do_parse
config, "setuptools_scm.parse_scm"
File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 52, in
_version_from_entrypoint
version = _call_entrypoint_fn(config, ep.load())
File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 39, in
_call_entrypoint_fn
return fn(config.absolute_root, config=config)
File "/usr/lib/python3/dist-packages/setuptools_scm/git.py", line 135, in
parse
branch=branch,
File "/usr/lib/python3/dist-packages/setuptools_scm/version.py", line 204, in
meta
assert parsed_version is not None, "cant parse version %s" % tag
AssertionError: cant parse version debian/1.9-4
E: pybuild pybuild:341: clean: plugin distutils failed with: exit code=1:
python3.7 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.7 returned exit code 13
make[1]: *** [debian/rules:26: override_dh_auto_clean] Error 25
make[1]: Leaving directory
'/home/becue/git/debian/python-team/applications/fava/fava'
make: *** [debian/rules:9: clean] Error 2
E: Failed to clean source directory
/home/becue/git/debian/python-team/applications/fava/fava
(/home/becue/git/debian/python-team/applications/fava/fava_1.10-1.dsc)
I wonder if upstream shouldn't make its version parsing regex a little
less constrained.
With best regards,
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#881629: transition: http-parser
Christoph Biedl wrote... > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition Hm, while checking the BTS for the http-parser transition filed yesterday I noticed this one here - from an earlier transition - is still open for no apparent reason. So, just for cleanliness, what to do? It it's expected the package maintainer closes the bug: I'll happy to do so, but please leave an according note in the Wiki, then. All the best, Christoph signature.asc Description: PGP signature
Bug#892102: inetd coredumpctl info
Control: tags -1 moreinfo Hi, sixerjman ezt írta (időpont: 2019. júl. 31., Sze, 18:15): > >PID: 21014 (inetd) >UID: 0 (root) >GID: 0 (root) > Signal: 6 (ABRT) > Timestamp: Tue 2019-07-09 08:00:05 EDT (3 weeks 1 days ago) > Command Line: /usr/sbin/inetd > Executable: /usr/sbin/inetd > Control Group: /system.slice/inetd.service > Unit: inetd.service > Slice: system.slice >Boot ID: acccaeafcbe0474ea3eea5fb4708e76f > Machine ID: 891bd6059e0d4cecae7b4ea3aac6b9fc > Hostname: debiant >Storage: none >Message: Process 21014 (inetd) of user 0 dumped core. Can I reproduce the issue locally somehow? Cheers, Balint
Bug#933688: FTBFS when importing sources into git because of empty directories
Hi, On Thu, Aug 01, 2019 at 11:50:41PM +0200, Daniel Baumann wrote: > Here's a patch: > > https://git.progress-linux.org/distributions/engywuck-backports/packages/inkscape/commit/?id=98c0a1546d57b88b96f1eadb769abbe4c51d0571 Do you think you could do something to the upstream part instead, that I can later forward upstream? (or upstream it yourself). I see your proposed patch as a not-so-nice workaround, whislt instead I strive to reduce the amount of stuff I need to tweak within d/rules. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#933738: openmpi: please enable java support on riscv64
Source: openmpi
Version: 3.1.3-11
Severity: wishlist
User: debian-ri...@lists.debian.org
Usertags: riscv64
In the past we asked you to disable java on riscv64 as it was not yet
available. This has now been fixed, openjdk-{11,12,13} are now available
with default-jdk pointing to openjdk-11 like on other architectures.
Therefore would it be possible to re-enable java support on riscv64 in
one of the next uploads (no urgency for that).
Thanks,
Aurelien
Bug#933737: nodejs: update tests to account for changes in libuv1 1.30
Package: nodejs
Version: 10.15.2~dfsg-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch
Dear Maintainer,
Please add the included patch for tests, which comes from upstream. This
fixes tests when building /testing against libuv1 > 1.27, which has been
changed from return EINVAL on an unbound sock, to returning EBADF.
*** /tmp/tmpED3lWj/bug_body
In Ubuntu, the attached patch was applied to achieve the above:
* debian/patches/update_test_libuv1_ebadf.patch: Starting in libuv 1.27.0,
test-dgram-address.js should expect EBADF instead of EINVAL.
Thanks for considering the patch.
-- System Information:
Debian Release: buster/sid
APT prefers eoan
APT policy: (500, 'eoan')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.2.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru nodejs-10.15.2~dfsg/debian/patches/series
nodejs-10.15.2~dfsg/debian/patches/series
--- nodejs-10.15.2~dfsg/debian/patches/series 2019-01-31 03:52:02.0
-0500
+++ nodejs-10.15.2~dfsg/debian/patches/series 2019-08-02 13:02:32.0
-0400
@@ -12,3 +12,4 @@
fix_disable_cctest.patch
benchmark_without_alice.patch
temporarily_silence_buffer_deprecations.patch
+update_test_libuv1_ebadf.patch
diff -Nru nodejs-10.15.2~dfsg/debian/patches/update_test_libuv1_ebadf.patch
nodejs-10.15.2~dfsg/debian/patches/update_test_libuv1_ebadf.patch
--- nodejs-10.15.2~dfsg/debian/patches/update_test_libuv1_ebadf.patch
1969-12-31 19:00:00.0 -0500
+++ nodejs-10.15.2~dfsg/debian/patches/update_test_libuv1_ebadf.patch
2019-08-02 13:01:32.0 -0400
@@ -0,0 +1,30 @@
+From 04f30e1a7a5a2f49b611314578758e2009ec2152 Mon Sep 17 00:00:00 2001
+From: cjihrig
+Date: Sat, 16 Mar 2019 13:45:54 -0400
+Subject: [PATCH] test: update test for libuv update
+
+Starting in libuv 1.27.0, test-dgram-address.js should expect
+EBADF instead of EINVAL.
+
+PR-URL: https://github.com/nodejs/node/pull/26707
+Reviewed-By: Santiago Gimeno
+Reviewed-By: Anna Henningsen
+Reviewed-By: Richard Lau
+Reviewed-By: Refael Ackermann
+Reviewed-By: Ruben Bridgewater
+Reviewed-By: James M Snell
+---
+ test/parallel/test-dgram-address.js | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/test/parallel/test-dgram-address.js
b/test/parallel/test-dgram-address.js
+index f14b910fc27a..2a41755e1c2e 100644
+--- a/test/parallel/test-dgram-address.js
b/test/parallel/test-dgram-address.js
+@@ -77,5 +77,5 @@ if (common.hasIPv6) {
+
+ assert.throws(() => {
+ socket.address();
+- }, /^Error: getsockname EINVAL$/);
++ }, /^Error: getsockname EBADF$/);
+ }
Bug#933736: uwsgi-plugin-php: Please include "for php7 return failures only on failure"
Package: uwsgi-plugin-php
Version: 2.0.17.1+8+0.0.3+b3
Severity: normal
Tags: patch
Dear Maintainer,
I've noticed that an interesting fix for the uwsgi PHP plugin is not included
in the upstream releases[1].
This fix[2] solves failures to initialize PHP sessions using session_start()
for PHP apps that use the feature. I was hit by this with phpmyadmin,
adminer.
[1] https://github.com/unbit/uwsgi/issues/2048
[2]
https://github.com/unbit/uwsgi/commit/7cf140aab8ed1f161c93f4c255964898560f2515
I rebuilt the uwsgi-src package with that patch included and then proceeded
to rebuilt uwsgi-plugin-php. This fixed thoses errors, for instance:
PHP Warning: session_start(): Failed to read session data: uwsgi (path:
dbadmsessions) in /usr/share/adminer/adminer.php on line 71
I think that this is a nice candidate for stable-updates, I can help preparing
an upload if appropriate.
Thanks,
Alex
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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)
Versions of packages uwsgi-plugin-php depends on:
ii libc62.28-10
pn libphp-embed
ii php7.3-cli [phpapi-20180731] 7.3.6-1
ii uwsgi-core [uwsgi-abi-a411bb8664cd85ae0fd852d2f665558a] 2.0.18-3
uwsgi-plugin-php recommends no packages.
uwsgi-plugin-php suggests no packages.
>From 7cf140aab8ed1f161c93f4c255964898560f2515 Mon Sep 17 00:00:00 2001
From: Krzysztof Warzecha
Date: Wed, 20 Sep 2017 14:31:36 +0200
Subject: [PATCH] plugins/php/session.c: for php7 return failures only on
failure
---
plugins/php/session.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/plugins/php/session.c b/plugins/php/session.c
index 2312b6b95..ddc375797 100644
--- a/plugins/php/session.c
+++ b/plugins/php/session.c
@@ -17,7 +17,10 @@ PS_READ_FUNC(uwsgi) {
#else
char *value = uwsgi_cache_magic_get((char *)key, strlen((char *)key),
&valsize, NULL, cache);
#endif
-if (!value) return FAILURE;
+ if (!value) {
+ *val = STR_EMPTY_ALLOC();
+ return SUCCESS;
+ }
#ifdef UWSGI_PHP7
*val = zend_string_init(value, valsize, 0);
#else
@@ -48,6 +51,9 @@ PS_WRITE_FUNC(uwsgi) {
PS_DESTROY_FUNC(uwsgi) {
char *cache = PS_GET_MOD_DATA();
#ifdef UWSGI_PHP7
+ if (!uwsgi_cache_magic_exists(key->val, key->len, cache))
+ return SUCCESS;
+
if (!uwsgi_cache_magic_del(key->val, key->len, cache)) {
#else
if (!uwsgi_cache_magic_del((char *)key, strlen(key), cache)) {
Bug#895142: libevent-dev: Please transition libevent-dev to multiarch
Control: tags -1 confirmed
Severity: -1 wishlist
F. Poirotte ezt írta (időpont: 2018.
ápr. 7., Szo, 18:33):
>
> Package: libevent-dev
> Version: 2.0.21-stable-3
> Severity: normal
>
> Dear Maintainer,
>
> While bug #675320 added support for multi-arch for the main packages, it seems
> the development package was overlooked. As such, it is not currently possible
> to
> install the dev package for multiple architectures (eg. amd64 and i386) at the
> same time.
>
> Trying to co-install multiple variants results in apt-get/aptitude trying to
> first
> remove previously installed packages. Here's the trace when trying to install
> the i386 variant on a system where the amd64 variant is already installed:
>
> $ sudo aptitude install libevent-dev:i386
> The following NEW packages will be installed:
> libevent-core-2.0-5:i386{a} libevent-dev:i386{b}
> libevent-extra-2.0-5:i386{a} libevent-openssl-2.0-5:i386{a}
> libevent-pthreads-2.0-5:i386{a}
> 0 packages upgraded, 5 newly installed, 0 to remove and 2 not upgraded.
> Need to get 569 kB of archives. After unpacking 1,971 kB will be used.
> The following packages have unmet dependencies:
> libevent-dev : Conflicts: libevent-dev:i386 but 2.0.21-stable-3 is to be
> installed
> libevent-dev:i386 : Conflicts: libevent-dev but 2.0.21-stable-3 is installed
> The following actions will resolve these dependencies:
>
> Remove the following packages:
> 1) libevent-dev [2.0.21-stable-3 (now, stable)]
>
>
> Accept this solution? [Y/n/q/?] q
>
>
> I checked the control file in testing/sid (libevent-2.1-6 (2.1.8-stable-4))
> and the problem is also visible there.
Yes, this is correct.
Header files differ between architectures:
$ diffoscope libevent-dev_2.1.8-stable-4_*
...
│ │ ├── ./usr/include/event2/event-config.h
│ │ │ @@ -439,33 +439,33 @@
│ │ │ your system. */
│ │ │ /* #undef EVENT__PTHREAD_CREATE_JOINABLE */
│ │ │
│ │ │ /* The size of `int', as computed by sizeof. */
│ │ │ #define EVENT__SIZEOF_INT 4
│ │ │
│ │ │ /* The size of `long', as computed by sizeof. */
│ │ │ -#define EVENT__SIZEOF_LONG 8
│ │ │ +#define EVENT__SIZEOF_LONG 4
...
This can be fixed, but the -dev packages are not co-installable currently.
Cheers,
Balint
Bug#933370: chrony won't start
Removing systemd-timesyncd from chrony's Conflicts directive worked. Some comments and details below, with more in the attached log. On Thu, Aug 1, 2019 at 1:44 PM Vincent Blut wrote: > > On Wed, Jul 31, 2019 at 01:18:02PM -0700, Ross Boylan wrote: > >Here are some tests I wasn't able to get to earlier. > > > >On Mon, Jul 29, 2019 at 5:39 PM Vincent Blut wrote: > >. > >> > >> Nevertheless, I would like you to test some things. > >> To begin with, I have an updated chrony unit file in a private git > >> branch targeting a future revision (not the next one) containing: > >> > >> Wants=time-sync.target > >> Before=time-sync.target > >> > >> That would be great if you could override the unit file currently > >> provided by chrony to add these two lines. I have no high hopes, but I’m > >> sill curious to see the result in this case. > > > >I tried it and it didn't help. I was still able to start it > >manually--I was a little concerned that since Before=time-sync.target > >would be unsatisfiable after startup it would never start. > > Thanks, it was a bit expected though. Anyway, I’ll add these two lines > to the unit file provided by chrony because according to the > time-sync.target documentation: > “Services responsible for synchronizing the system clock from a > remote source (such as NTP client implementations) should pull in > this target and order themselves before it.” It would have been nice if those instructions for time-sync.target were phrased in terms of actual systemd directs like Wants and Before instead of using seemingly ordinary English. Maybe the meaning is clear to those who know. > > >> If that does not work, just removing systemd-timesyncd.service from the > >> “Conflicts=” line in the chrony unit file may fix the issue… well I > >> think. ;-) > > > >I did systemctl disable systemd-timesyncd and now chrony runs (and > >stays running) on startup. > > Disabling systemd-timesyncd was guaranteed enough to succeed. That shows > that chrony is probably not at fault here. However, before merging this > bug report with #883241 and reassigning them to systemd, I would really > appreciate if you could check what’s happening by removing > systemd-timesyncd.service from the “Conflicts=” line in the chrony unit > file. > > Note that I would totally understand that you refuse to run some tests > again! I certainly do not want to burden you. > > If you accept to run these tests, then: > > # Reenable systemd-timesyncd > # systemctl enable systemd-timesyncd.service > > # Edit chrony’s unit file > # systemctl edit --full chrony.service > > That will invoke an editor. From there, remove > “systemd-timesyncd.service” from the “Conflicts=” line. Save & exit! I did this, also inserting the Wants=time-sync.target Before=time-sync.target directives into the new file. I left the override file that has those directives too; not sure if it gets checked if I've overridden the whole file. > > # Restart the system and report chrony’s status here (ditto for > systemd-timesyncd) See attached, which was done with systemd.log_type=debug. It also gives the contents of the configuration files. It worked properly: chrony was active on startup. Ross root-session22l.log.gz Description: application/gzip
Bug#933732: [Pkg-opencl-devel] Bug#933732: causes piglit test failure
Hello Simon, The behavior seems the correct one (from the spec): . How will the ICD handle a `NULL` cl_platform_id? + -- RESOLVED: The ICD will by default choose the first enumerated platform as the `NULL` platform. The user can override this default by setting an environment variable OPENCL_ICD_DEFAULT_PLATFORM to the desired platform index. The API calls that deal with platforms will return CL_INVALID_PLATFORM if the index is not between zero and (number of platforms - 1), both inclusive. -- Brice On 02/08/2019 10:27, Simon Richter wrote: Package: ocl-icd-libopencl1 Version: 2.2.12-2 Severity: minor Tags: upstream Hi, I have a single OpenCL ICD installed, and am running piglit tests against it. I get a test failure in the clGetExtensionFunctionForPlatform test, which expects NULL to be returned when the platform parameter passed is NULL. The implementation in ocl-icd does platform=selectPlatformID(platform); which selects the platform if only one is available, causing the test to fail. If that is indeed correct behaviour according to the spec, then the testsuite is wrong, but as far as I've understood it, this function should not fall back to the default platform if the parameter that is passed is NULL. Simon -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/32 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 /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ocl-icd-libopencl1 depends on: ii libc6 2.28-10 ocl-icd-libopencl1 recommends no packages. Versions of packages ocl-icd-libopencl1 suggests: pn opencl-icd -- no debconf information ___ Pkg-opencl-devel mailing list pkg-opencl-de...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-opencl-devel
Bug#933440:
> > Perhaps post a backtrace and maybe somebody can help? The crash can be encountered during startup, when a FITS file [1] is passed as an argument. This is the second regular way for the launch: users can pass the file, or double click in a graphical file manager: -- debian:/tmp$ gdb /scratch/opt/bin/xmunipack Reading symbols from /scratch/opt/bin/xmunipack...done. (gdb) run --verbose m27_01R.fits Starting program: /scratch/opt/bin/xmunipack --verbose m27_01R.fits [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux- gnu/libthread_db.so.1". [New Thread 0x7fffe748d700 (LWP 11555)] [New Thread 0x7fffe6c8c700 (LWP 11556)] [New Thread 0x7fffe5fce700 (LWP 11557)] Debug: FitsTone::Setup 35468 11 0.25 [New Thread 0x7fffe57cd700 (LWP 11558)] [New Thread 0x7fffe4ecc700 (LWP 11559)] Debug: Median=2938.00 MAD=29.01 Black=2912.00 Qlight=902.301575 n=5968 Debug: MuniView::OnLoadFinish [Thread 0x7fffe5fce700 (LWP 11557) exited] Debug: MuniDisplayCanvas constructor.. Thread 1 "xmunipack" received signal SIGSEGV, Segmentation fault. 0x76322650 in g_type_check_instance_cast () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (gdb) where #0 0x76322650 in g_type_check_instance_cast () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #1 0x77c13c33 in wxWindow::GTKApplyWidgetStyle(bool) () from /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0 #2 0x77c1c61c in wxWindow::SetBackgroundColour(wxColour const&) () from /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0 #3 0x557b49a9 in mpWindow::mpWindow (this=0x56052480, parent=0x55ff8000, id=-1, pos=..., size=..., flag=0) at mathplot.cpp:1193 #4 0x5573b9e9 in MuniPlotHisto::MuniPlotHisto (this=0x56052480, w=0x55ff8000) at plot.cpp:85 #5 0x556db476 in MuniDisplayPanel::MuniDisplayPanel ( this=0x55ff8000, w=0x55f33800, c=0x55b3dcd0) at dispanel.cpp:136 #6 0x556c36a8 in MuniDisplay::MuniDisplay (this=0x55f33800, w=0x55dd4c00, c=0x55b3dcd0) at display.cpp:45 #7 0x556a710b in MuniView::SetupPlaces (this=0x55dd4c00) at view.cpp:591 #8 0x556a68c9 in MuniView::OnLoadFinish (this=0x55dd4c00, event=...) at view.cpp:554 #9 0x7789d7ae in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 --Type for more, q to quit, c to continue without paging-- #10 0x7789db2a in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #11 0x7789dbc0 in wxEvtHandler::TryHereOnly(wxEvent&) () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #12 0x7789dc73 in wxEvtHandler::ProcessEventLocally(wxEvent&) () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #13 0x7789dd11 in wxEvtHandler::ProcessEvent(wxEvent&) () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #14 0x7789e6b4 in wxEvtHandler::ProcessPendingEvents() () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #15 0x7773b87f in wxAppConsoleBase::ProcessPendingEvents() () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #16 0x77bd99d9 in wxApp::DoIdle() () from /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0 #17 0x77bd9ad3 in ?? () from /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0 #18 0x7621bdd8 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #19 0x7621c1c8 in ?? () from /lib/x86_64-linux-gnu/libglib- 2.0.so.0 #20 0x7621c4c2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #21 0x7681bb15 in gtk_main () from /lib/x86_64-linux-gnu/libgtk- 3.so.0 #22 0x77bf61d5 in wxGUIEventLoop::DoRun() () --Type for more, q to quit, c to continue without paging-- from /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0 #23 0x7777348d in wxEventLoopBase::Run() () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #24 0x7773c616 in wxAppConsoleBase::MainLoop() () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #25 0x777bdcf9 in wxEntry(int&, wchar_t**) () from /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #26 0x5565766e in main (argc=3, argv=0x7fffe128) at xmunipack.cpp:38 (gdb) --- The crash at point of mathplot.cpp:1193 occurs when the perfectly regular command SetBackgroundColour( *wxWHITE ); is executed. If the command is commented out, the crash is moved to mpWindow::~mpWindow() destructor. A play with DelAllLayers(), even UpdateAll(), did not shown any advance. Some notes: * The part plots a histogram with a distribution of image counts. * wxMatplotlib included in Munipack is modified code of [2]. * The code has been worked for many years wit
Bug#933572: ncurses-base: Screen corruptions seen when running mutt in a tmux
On 2019-08-02 11:50 +0200, Romain Francoise wrote: > Hi Sven, > > On Wed, Jul 31, 2019 at 7:57 PM Sven Joachim wrote: >> So rin=\E[%p1%dT has been added in sid, apparently because of the >> following change in the 20190630 patchlevel: >> >> , >> | + add a check in tic for paired indn/rin >> ` > > Would it be possible to temporarily revert this change in Debian, I think reverting this particular change is not the right thing, rather we should drop "rin" from tmux (which Thomas has already promised) and from screen, which tmux still uses (for better or worse) as its default value for $TERM. > perhaps until tmux 3.0 is released sometime in October? The patch to > support rin is large, and I'm not comfortable carrying it as a > Debian-specific backport. Thanks. Surely, I'm just waiting for this weekend's ncurses patchlevel to be released. And for ncurses to migrate to testing - the current version contains a patch for another "garbled display" problem that I want to cherry-pick in _stable_ (#933053). Cheers, Sven
Bug#930037: irssi + mosh: badly rendered status lines
Control: reassign -1 mosh 1.3.2-2.1 Control: affects -1 + irssi This happens because mosh doesn't implement the repetition operator (see bug #933053). Minimal reproducer: $ printf 'mo\33[5b\n' mo But in xterm proper it is: $ printf 'mo\33[5b\n' moo -- Jakub Wilk
Bug#891194: 3dldf: please make the build reproducible
[Adding reproducible-b...@lists.alioth.debian.org to CC] Hi Hilmar, > The provided patch disables time stamping in general. I don't think this > is a good idea, as users might complain about changed program behavior. Is that likely? Genuine question. :) > Could you extend the patch so the program obeys the SOURCE_DATE_EPOCH > variable and changes its behavior only if that variable is set? Yes, but is this really worth any potential "regression" when compared to the admittedly-minor additionally code complexity you are proposing? Note that if we do change the behaviour based on SOURCE_DATE_EPOCH we have two options. First, we simply hide the date if this variable is exported or secondly we do some ugly parsing and use the value of this variable instead. (Naturally, the former is somewhat simpler.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#933661: Issue #40: Please consider to switch to Python3 (biobakery/metaphlan2)
--- you can reply above this line --- Issue 40: Please consider to switch to Python3 https://bitbucket.org/biobakery/metaphlan2/issues/40/please-consider-to-switch-to-python3 Francesco Beghini: Hi Andreas, we ported the latest version of MetaPhlAn2 \(2.9\) to Python3 and now it is available on the 2.9 branch. We planned to move everything on the default branch in a couple of weeks when we will release the final version. Best, Francesco -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/biobakery/metaphlan2/issue/40/unwatch/tille17/9cc3d5bb113056c1d0348bb6be68bdfdf28b586fa6f0af9576c3f6ddd291988b/
Bug#933735: ITP: drawing -- drawing application for GNOME
Package: wnpp Severity: wishlist Owner: Andrej Shadura * Package name: drawing Version : 0.4.2 Upstream Author : Romain F.T. * URL : https://maoschanz.github.io/drawing/ * License : GPL-3 Programming Lang: Python Description : drawing application for GNOME This application is a basic image editor, similar to Microsoft Paint, but aiming at the GNOME desktop.
Bug#801505: texlive-latex-extra: complaint about weong file in dpkg trigger
Am 11.10.2015 um 13:31 teilte Michal Suchanek mit: Hi Michal, https://bugs.debian.org/801505 > I tried to ugrade libstdc++ and as a result I also needed to upgrade > TeX. > > The TeX dpkg trigger complains about wrong file. > > Is this expected transitional state until some packages are rebuilt or > is something broken? > Is the issue still present? Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
