Bug#920453: googler does not display results without "--noua" switch
Hi, Sebastian Stabbert 於 2019年1月26日 週六 上午1:03寫道： > > Package: googler > Version: 2.9.0-1 > Severity: normal Could you describe your operating environment? I think it might be a PEBCAK issue. This issue won't be able to reproduce in my Linux environment. However, this issue appears in the remote console (e.g., putty). After using the tool of git bisec, I've confirmed v3.7.1 [1] fixed this issue. The reason is that there is no agent in remote console; therefore the argument of "--ua" is needed. Please feel free to use v3.7.1 of googler in stretch-backports archive [2]. [1] https://github.com/jarun/googler/commit/e704598f275f4e4bf8af100fe415ff6b8a981aaf [2] https://packages.debian.org/stretch-backports/googler SZ > > > > -- System Information: > Debian Release: 9.6 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.13.0-38-generic (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages googler depends on: > ii python3 3.5.3-1 > > googler recommends no packages. > > googler suggests no packages. > > -- no debconf information
Bug#925129: ffcall failed to build mips64 R6 version due to Illegal instruction
Package: ffcall Version: 2.1-2 Dear Maintainer: I tried build ffcall for mips64 R6, but it was fail because of illegal instruction, and I find the cause is: in mips64 R6 release, instruction "JALR" is "001001" in binary format, the corresponding last hex number is 0x9 but in previous version it is 0x8. So the binary format of instruction "j $25" (in file ./trampoline/trampoline.c and ./callback/trampoline_r/trampoline.c) for R6 is 0x0329 while for the previous version this instruction is 0x0328 attachment is my patch to fix it, could you help to take a review. Thanks so much! Thanks luyou ffcall_mipsr6.patch Description: ffcall_mipsr6.patch
Bug#925128: "dhcpcd" launches multiple times at startup.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: dhcpcd5 Version: 7.1.0-1 I am using SysV init and "ifupdown" to configure my workstation. "network-manager" is not installed because I refuse to lick Lennart's "D". "isc-dhcp-client" is not installed, so "dhcpcd" is the only thing that handles DHCP. During startup, the network has already configured in "/etc/init.d/networking", using "ifupdown". Since the interface is already configured, "/etc/init.d/dhcpcd" will launch "dhcpcd" a second time which fails the sanity test, causing the service to fail. My suggestion is that if "dhcpcd" is already running, "service dhcpcd start" should do nothing and "service dhcpcd stop" should kill all instances of "dhcpcd". Related configuration: /etc/network/interfaces --- auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp dns-nameservers 1.1.1.1 1.0.0.1 /etc/dhcpcd.conf --- hostname ipv4only clientid option rapid_commit option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes option interface_mtu require dhcp_server_identifier -- Please limit your reply to 7-bit ASCII. I refuse to see your idiotic emoji in a terminal. -BEGIN PGP SIGNATURE- Version: ProtonMail Comment: https://protonmail.com wsBcBAEBCAAGBQJckc5oAAoJENi1YDlFXXQf78MH/0/MBuOhCvC6U9+LtAHp 7Sl4ngqe+zGkK7LPf269lVplWPjXu/dcjl59c62Mb/dsJxh2qHUFEtd0GBwZ n6Xr4CguMZ4fiYoiZMOJLzIVieIO1Msa8JbrIVc/xxR0Sur8VwFK3wKJAtNq Ct02o2rcDAF8+j49IA4TnMs8IOuuKHl8c3QKloq3qESNje+59MtqrqASIGLU u5RUAWKE2dVyUkwho/0QIfFV6z7c+OgihH4vtqbgyonUwZJG3tjF0UJug336 iThiinsAvCyp5HJfB3b/xP+InE04xUqw9BWZRkcnpJm+HQbSkcIvEUDuSdIo npNwz0OBm2o1/MqlxItHpaw= =Agxf -END PGP SIGNATURE- publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc Description: application/pgp-keys publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig Description: PGP signature
Bug#925127: tcc: CVE-2019-9754
Source: tcc Version: 0.9.27-8 Severity: normal Tags: security upstream Forwarded: https://lists.nongnu.org/archive/html/tinycc-devel/2019-03/msg00038.html Hi, The following vulnerability was published for tcc. CVE-2019-9754[0]: | An issue was discovered in Tiny C Compiler (aka TinyCC or TCC) | 0.9.27. Compiling a crafted source file leads to an 1 byte out of | bounds write in the end_macro function in tccpp.c. 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-9754 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9754 [1] https://lists.nongnu.org/archive/html/tinycc-devel/2019-03/msg00038.html Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#925126: bcache-tools: Load bcache kernel module *before* registering device
Package: bcache-tools
Version: 1.0.8-3
Severity: important
Dear Maintainer,
Recently my computer wasn't booting anymore. It turns out udev was
trying to call the program bcache-register before the kernel module was
loaded. Resulting in a failure to register the device, which then
couldn't be mounted.
The udev rules contain those two lines:
RUN{builtin}+="kmod load bcache"
RUN+="bcache-register $tempnode"
I don't know if udev relaxed the order between actions RUN{builtin} and
RUN. But right now, the order in which they are run is random.
If this is not a bug from udev, then I might suggest splitting
69-bcache.rules into 68-bcache-load.rules and 69-bcache-register.rules
in order to force the execution order.
Best regards,
Celelibi
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bcache-tools depends on:
ii libblkid1 2.33.1-0.1
ii libc6 2.28-8
ii libuuid1 2.33.1-0.1
Versions of packages bcache-tools recommends:
ii initramfs-tools [linux-initramfs-tool] 0.133
bcache-tools suggests no packages.
-- no debconf information
Bug#558171:
I've had the same problem with: OpenSSH_7.9p1 Debian-9, OpenSSL 1.1.1b 26 Feb 2019 OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 including the freeze at debug1: Sending env LANG = en_US.UTF-8 which cannot be stopped by Ctrl-C. After waiting a while I once got: packet_write_wait: Connection to [ip] port 22: Broken pipe before the process ended I was, however, able to connect to the same server using: OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r 26 Feb 2019 OpenSSH_7.7p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 where I got the same message, debug1: Sending env LANG = en_US.UTF-8 but then it immediately went to command prompt rather than freezing Last login: Tue Mar 19 17:54:25 2019 from [ip] It seems that the problem was introduced to OpenSSH between 7.7 and 7.9
Bug#925125: Fwd: Fwd: RFS: hollywood/1.14-2 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "hollywood" * Package name : hollywood Version : 1.14-2 Upstream Author : Dustin Kirkland * URL : https://github.com/dustinkirkland/hollywood * License : Apache-2.0 Section : games It builds those binary packages: hollywood - fill your console with Hollywood melodrama technobabble wallstreet - fill your console with Wall Street-like news and stats To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hollywood Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hollywood/hollywood_1.14-2.dsc More information about hollywood can be obtained from https://github.com/dustinkirkland/hollywood Changes since the last upload: * New Maintainer (Closes: #920883): - Add myself to Maintainer field on d/control. * Bump debhelper to debhelper-compat (= 12) from 11 on d/control. - Delete compat file * Bump Standards-Version to 4.3.0 (from 4.2.1) on d/control. * Add myself to d/copyright for debian/* files. * Add Vcs-* links * Delete snap.wallstret and snap.hollywood folder that folder are not in the last upstream version Regards! -- @eamanu https://eamanu.com signature.asc Description: OpenPGP digital signature
Bug#925115: docker: Error response from daemon: unable to find "systemd" in controller set: unknown.
On 3/20/19 4:32 AM, Thorsten Glaser wrote: > Package: docker.io > Version: 18.09.1+dfsg1-5+b10 > Severity: important > > Docker does not work out of the box. > > $ sudo docker run -it debian /bin/bash > docker: Error response from daemon: unable to find "systemd" in controller > set: unknown. > > > Workaround: do this once manually: > > $ sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd I did a quick search, there seem to be a bug opened upstream just a few days ago: https://github.com/moby/moby/issues/38822 Which links to: https://github.com/containerd/containerd/pull/3079
Bug#925124: unblock: derpconf/0.8.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Could you, please, unblock derpconf? The new derpconf version closes #924811. debdiff with my changes: diff -Nru derpconf-0.8.2/debian/changelog derpconf- 0.8.2/debian/changelog --- derpconf-0.8.2/debian/changelog 2018-01-11 22:13:34.0 -0200 +++ derpconf-0.8.2/debian/changelog 2019-03-17 19:37:17.0 -0300 @@ -1,3 +1,12 @@ +derpconf (0.8.2-2) unstable; urgency=high + + * d/control: Remove ancient X-Python-Version field + * d/control: Set Vcs-* to salsa.debian.org + * Move package to Python Modules Team + * Fixed build-dependency not installable: python-tox + + -- Marcelo Jorge Vieira Sun, 17 Mar 2019 19:37:17 -0300 + derpconf (0.8.2-1) unstable; urgency=medium * New upstream release diff -Nru derpconf-0.8.2/debian/control derpconf-0.8.2/debian/control --- derpconf-0.8.2/debian/control 2017-08-27 17:17:52.0 -0300 +++ derpconf-0.8.2/debian/control 2019-03-17 19:36:32.0 -0300 @@ -1,6 +1,7 @@ Source: derpconf -Maintainer: Marcelo Jorge Vieira -Uploaders: Gilles Dubuc +Maintainer: Debian Python Modules Team < python-modules-t...@lists.alioth.debian.org> +Uploaders: Gilles Dubuc , + Marcelo Jorge Vieira Section: python Priority: optional Standards-Version: 4.0.0 @@ -12,12 +13,11 @@ python-gevent, python-coverage, python-colorama, - python-tox, - python-six -X-Python-Version: >= 2.6 + python-six, + tox Homepage: https://github.com/globocom/derpconf -Vcs-Git: git://github.com/globocom/derpconf.git -Vcs-Browser: https://github.com/globocom/derpconf +Vcs-Git: https://salsa.debian.org/python-team/modules/derpconf.git +Vcs-Browser: https://salsa.debian.org/python-team/modules/derpconf Package: python-derpconf Architecture: all Cheers, -- Marcelo Jorge Vieira xmpp:me...@jabber-br.org http://metaldot.alucinados.com signature.asc Description: This is a digitally signed message part
Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler
On Tue, 2019-03-19 at 15:41 +0100, Helmut Grohne wrote: [...] > src:linux Build-Depends binutils-. The binutils patch will > render these dependencies cross-unsatisfiable. They will need to be > switched to binutils-for-host or annotated with :any (after checking > that it doesn't use plugins). Maintainers Cced. We only do that for hppa, as the standard gcc-8 & binutils packages only support 32-bit code and we need to build 64-bit kernels there. We don't use plugins for binutils. Ben. > So the attached patch will break cross building of gcc and linux. It > won't break any native stuff and it'll fix the bug at hand. > > Helmut -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Bug#924760: logfiles...
Control: reassign -1 src:grub2 2.02+dfsg1-13 On Sun, Mar 17, 2019 at 11:31:46PM +0100, Samuel Thibault wrote: > Ok. It looks like os-prober finds the sda1 EFI partition fine, and > apparently "dummy" is correct for EFI platforms. Yes. (Actually it's just ignored, but having it there makes grub-installer's code a little simpler.) > But then > > grub-installer: info: Running chroot /target grub-install --force "dummy" > grub-installer: Installing for x86_64-efi platform. > grub-installer: grub-install: error: unknown filesystem. > > so I guess somehow the grub2 package doesn't manage to find its way with > an xfs filesystem for '/', thus Cc-ing grub2 maintainers, just > reassigning to grub-installer for now. Looks very much like the bug fixed upstream here: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=cda0a857dd7a27cd5d621747464bfe71e8727fff I'll cherry-pick that patch. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#924792: pidof: unsanitized user input makes pidof crash
On 3/19/19 7:28 PM, KatolaZ wrote: > On Tue, Mar 19, 2019 at 05:54:56PM -0300, Jesse Smith wrote: >> I am certainly open to replacing the "format" flag (-f) with an >> alternative field separator flag. It has a nice Unixy feel to it and >> requires less code. >> >> Personally, I think using -d (or --delimiter) might be the only change >> I'd want to make to the patch KatolaZ provided. Partly because pidof >> already has a lower-case "-s" flag and I want to avoid confusion, and >> because tools like cut also use "-d". >> >> If there are no objections, I'll upstream KatolaZ's patch and remove the >> "-f" flag. >> > No objections on my side. '-d' makes sense to me as well. > > @Jesse: I feel I owe you an apology. I read again my first post in > this thread, and I noticed that it might have sounded harsh, or worse, > patronising. Sorry: that was never my intention. I hope you can > accept my apologies. > Not to worry, and no apology necessary. You raised a valid point about over-engineering pidof and made some constructive criticism. I appreciate you helping to come up with a better solution. Jesse
Bug#925120: Updating the fflas-ffpack Uploaders list
Control: tags -1 pending On 3/19/19 8:00 AM, Pierre-Elliott Bécue wrote: > lifong...@gmail.com has not been working on > the fflas-ffpack package for quite some time. > > We are tracking their status in the MIA team and would like to ask you > to remove them from the Uploaders list of the package so we can close > that part of the file. > > (If the person is listed as Maintainer, what we are asking is to please > step in as a new maintainer.) Thanks for the report! Fixed in git [1]. [1] https://salsa.debian.org/science-team/fflas-ffpack/commit/5be112f
Bug#925123: unblock: retroarch-assets/1.3.6+git20160731+dfsg1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package retroarch-assets
I have removed the alternative dependency on fonts-roboto that depends
on fonts-roboto-unhinted now. I opted
for keeping the dependency on fonts-roboto-hinted for Buster, thus I
have not closed bug #922947 yet which we have to fix eventually but
the RC issue (broken symlinks) is resolved.
Please find attached the debdiff.
Regards,
Markus
unblock retroarch-assets/1.3.6+git20160731+dfsg1-2
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
diff -Nru retroarch-assets-1.3.6+git20160731+dfsg1/debian/changelog
retroarch-assets-1.3.6+git20160731+dfsg1/debian/changelog
--- retroarch-assets-1.3.6+git20160731+dfsg1/debian/changelog 2016-08-18
03:23:42.0 +0200
+++ retroarch-assets-1.3.6+git20160731+dfsg1/debian/changelog 2019-03-20
01:02:15.0 +0100
@@ -1,3 +1,11 @@
+retroarch-assets (1.3.6+git20160731+dfsg1-2) unstable; urgency=medium
+
+ * Team upload.
+ * Remove alternative dependency on fonts-roboto because it provides the
+unhinted version now. This fixes broken symlinks. See also #922947.
+
+ -- Markus Koschany Wed, 20 Mar 2019 01:02:15 +0100
+
retroarch-assets (1.3.6+git20160731+dfsg1-1) unstable; urgency=low
* Updated to latest git, c8f7c0b.
diff -Nru retroarch-assets-1.3.6+git20160731+dfsg1/debian/control
retroarch-assets-1.3.6+git20160731+dfsg1/debian/control
--- retroarch-assets-1.3.6+git20160731+dfsg1/debian/control 2016-08-18
03:14:52.0 +0200
+++ retroarch-assets-1.3.6+git20160731+dfsg1/debian/control 2019-03-20
01:02:15.0 +0100
@@ -9,6 +9,6 @@
Package: retroarch-assets
Architecture: all
-Depends: fonts-roboto | fonts-roboto-hinted, ${shlibs:Depends}, ${misc:Depends}
+Depends: fonts-roboto-hinted, ${shlibs:Depends}, ${misc:Depends}
Description: RetroArch assets for XMB, GLUI and Zarch
This package installs RetroArch assets for XMB, GLUI and Zarch menu drivers.
Bug#925050: Updating the givaro Uploaders list
Control: tags -1 pending On 3/19/19 8:00 AM, Pierre-Elliott Bécue wrote: > lifong...@gmail.com has not been working on > the givaro package for quite some time. > > We are tracking their status in the MIA team and would like to ask you > to remove them from the Uploaders list of the package so we can close > that part of the file. > > (If the person is listed as Maintainer, what we are asking is to please > step in as a new maintainer.) Thanks for the report! Fixed in git [1]. [1] https://salsa.debian.org/science-team/givaro/commit/bb39647
Bug#922947: retroarch-assets: please don’t use hinted Roboto fonts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: severity -1 normal The RC issue was fixed in version 1.3.6+git20160731+dfsg1-2. Let's keep this bug open for Debian 11. For Buster we can still depend on the hinted fonts thus there is no risk of breaking anything. -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAlyRhLJfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7 UeRbaxAAvnN9EO/0Nl2YY1T8wJ9nYdeKVw7zsA5KH//MNHx05BspVHl5ee6xDZn4 zc9LVS+URHt9s1IvrfaW2E1DTPrCplft/h0mFyQAnNZJ0PJwyT2aALeqOHFWThEK aUt0mukelF+VXvsdknQtFt/7AZO/3v7Z4z9NKjHtmTwejM+16mOtJ1GsytuH2Udu 9Mpnh2vNtXV/tQePlwKawzpJrbIA08vGSSVOvjtC8afrELV20ZPqTMwq55oMmSgA YEsrlGdn1W70iV31DdzYbAkbm6TLWl/ubgKglc+nIZZvh2crVcoGfArUWL3jP4xb zBVH/BjlunBTxXnT4+8hADBcjc+xdC7njXGHOisOyClqVcolzEjkEGUv/byNWZ+E 2zxVSUuiezpSgSMOXm2TcObAjaCjqeB/mgmQqpjjaohuvHy25zVo/BoH2yYolwxU 70n7+eaxG79JZjCxmukFgoHFSuUToN3KoF0MfC74XoCUzJb8JSQKqZe8rSxdr+zv bMrJtjeIyZa3ZDiA3pJPhS6C49sv4qeJp+UUgoGxgF0BrDWwt5PEcWb+5zz22tul V29LkJd7tvQUGx4jCdGwgvJ4O6SuZMJazRABotB6xjCgXcF3euKEdcYWCLFs6ESY jQZUIIuVM5M01Civ3y/zX7okdxTYPgGY2naEqtWvTxKn7dN8XnE= =6wrM -END PGP SIGNATURE-
Bug#919395: Heads up to release team about MariadB 10.3
Hi, please give-back qt4-x11. A build has succeeded today in my pbuilder sid amd64 and i386 chroot, so this was probably a compiler realted issue, it was failing previously nowhere near mysql/mariadb touching code. gb qt4-x11_4:4.8.7+dfsg-17 . ANY Andreas
Bug#916538: [btrfs-progs] btrfsck segfaults with -E and --subvol-extents
Control: tag -1 + moreinfo Hi Bruno, On Sat, Dec 15, 2018 at 05:45:24PM +0100, Bruno Kleinert wrote: > Package: btrfs-progs > Version: 4.19.1-1 > Severity: normal > > Kernel: Linux 4.18.0-3-amd64 > Please confirm if btrfs-progs/4.20.1-1 on linux/4.19.0-2-amd64 is also affected. Thanks! Nicholas signature.asc Description: PGP signature
Bug#924941: d-shlibmove: fails in opensuse build service
Control: severity -1 normal Hi Lenz, failing to backport a package to some ancient release is not release critical. Let me see if I managed to understand what you want to achieve: * your target architecture is i386 (any other achitectures?) * you want to backport src:libsrtp2 to jessie (and maybe wheezy, too) * which version? libsrtp2 | 2.0.0+20170123-1 | stable | source libsrtp2 | 2.2.0-1 | testing| source libsrtp2 | 2.2.0-1 | unstable | source Rebuilding libsrtp2 2.0.0+20170123-1 in a jessie+jessie-backports chroot just worked fine for me. Trying this in a wheezy+wheezy-backports chroot fails with a lot of unsatisfied dependencies: The following packages have unmet dependencies: pbuilder-satisfydepends-dummy : Depends: licensecheck which is a virtual package. Depends: pkg-kde-tools but it is not going to be installed. Depends: pkg-config but it is not going to be installed. Depends: libpcap0.8-dev but it is not going to be installed. Depends: psmisc but it is not going to be installed. Depends: miscfiles but it is not going to be installed. Depends: d-shlibs but it is not going to be installed. Depends: doxygen-latex but it is not going to be installed. I'm not going to look into details :-) Don't forget: Support for wheezy-LTS has ended nearly a year ago in May 2018! Andreas
Bug#922727: CVE-2019-7443
Hey, > The security bug filed against kauth in #921995 also seems to affect > kde4libs, the code is in kdecore/auth/backends/dbus/DBusHelperProxy.cpp? yes, it is likely, that also kde4libs is affected. kauth is KDE Frameworks. As the birth of KDE Frameworks is a split of kdelibs. I think KDE doesn't mention kdelibs as affected, as kdelibs is EOL so not security support by KDE anymore. (Only in Debian kdelibs was renamed to kde4libs, as there were package name conflicts. That's why I'm normally talking about kdelibs.) hefee signature.asc Description: This is a digitally signed message part.
Bug#891717: btrfs-progs: btrfs filesystem show takes a long time
Control: tag -1 + confirmed Hi Stefan, Thank you for filing this bug, and thank you for providing the upstream URL for this issue. As this is not an RC issue I expect the resolution will be deferred until bullseye (buster+1/Debian 11). If the problem is strictly in btrfs-progs it is likely that a future buster-backport release will resolve it. Cheers, Nicholas signature.asc Description: PGP signature
Bug#922947: retroarch-assets: please don’t use hinted Roboto fonts
Control: tags -1 confirmed pending On Fri, 22 Feb 2019 09:18:51 +0100 Andrej Shadura wrote: > Package: retroarch-assets > Severity: normal > > Dear Maintainer, > > The Roboto upstream no longer provides hinted fonts, so > fonts-roboto-hinted is now a transitional package providing symlinks to > the unhinted fonts. Please modify your package to use the unhinted fonts > instead. Andrej, you should have also reverted fonts-roboto to depend on fonts-roboto-hinted again when you fixed #922457. In case of retroarch-assets which depends on fonts-roboto | fonts-roboto-hinted this will pull in fonts-roboto-unhinted now when fonts-roboto-hinted is not installed. I'm going to fix this issue now in retroarch-assets by only depending on fonts-roboto-hinted but such changes should not be made without proper testing before a full freeze. :/ Markus signature.asc Description: OpenPGP digital signature
Bug#925119: Updating the paw Uploaders list
Source: paw Version: 1:2.14.04.dfsg.2-9.1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the paw package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#924368: I'll take it
On Mon, Mar 18, 2019 at 01:59:23PM +0100, Adam Borowski wrote: > On Mon, Mar 18, 2019 at 12:53:12PM +0100, Gianfranco Costamagna wrote: > > > > Thanks Adam for taking care of it! > > Just a side note: I think I sponsored a lot of backports for Nicholas in > > the past, > > he is a good contributor, and he sends patches upstream and to Debian > > packaging (dated 2017). > > > > Maybe you can both work on the package, he is a DM so he might even upload > > by himself if you > > feel comfortable with his work (Nicholas please tell us if you are still > > interested in btrfs!) > > That might work, yeah. > > On the other hand, even though there's some quite obvious work to do, doing > disruptive changes to an udeb-producing package during the freeze would be a > very bad idea, thus I plan no uploads anytime soon, doing all changes in > git. > Is there a git remote yet? I've been maintaining a patches unapplied source package (for the purposes of backporting) for quite some time at: g...@github.com:sten0/btrfs-progs.git Whether that history is dropped or integrated, it would be nice to depreciate that github project for an official salsa one. Re: quite obvious changes, it would be nice to resolve #786893 #798072 and #911623 for buster. See #589229 for a counter example and possible precedent against. Cheers, Nicholas signature.asc Description: PGP signature
Bug#925121: Updating the mclibs Uploaders list
Source: mclibs Version: 20061220+dfsg3-3.1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the mclibs package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925120: Updating the fflas-ffpack Uploaders list
Source: fflas-ffpack Version: 2.3.2-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the fflas-ffpack package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#924792: pidof: unsanitized user input makes pidof crash
On Tue, Mar 19, 2019 at 05:54:56PM -0300, Jesse Smith wrote: > I am certainly open to replacing the "format" flag (-f) with an > alternative field separator flag. It has a nice Unixy feel to it and > requires less code. > > Personally, I think using -d (or --delimiter) might be the only change > I'd want to make to the patch KatolaZ provided. Partly because pidof > already has a lower-case "-s" flag and I want to avoid confusion, and > because tools like cut also use "-d". > > If there are no objections, I'll upstream KatolaZ's patch and remove the > "-f" flag. > No objections on my side. '-d' makes sense to me as well. @Jesse: I feel I owe you an apology. I read again my first post in this thread, and I noticed that it might have sounded harsh, or worse, patronising. Sorry: that was never my intention. I hope you can accept my apologies. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
* Kurt Roeckx [2019-03-19 22:59]: > On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote: > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ > > unexpectedly returns NULL. I now avoid the function to work around the > > issue. > > This is documented here: > https://wiki.openssl.org/index.php/TLS1.3#PSKs Thanks. I'm still using the TLSv1.2 callbacks indeed, but from reading that text it's not obvious to me why SSL_get_psk_identity() would fail. (Note that I'm not using identity *hints* anywhere, which is the thing TLSv1.3 dropped.) However, I can easily imagine the bug(?) being related to the changes mentioned in that text.
Bug#924368: ITA: btrfs-progs -- Checksumming Copy on Write Filesystem utilities
On Mon, Mar 18, 2019 at 12:53:12PM +0100, Gianfranco Costamagna wrote:
> On Tue, 12 Mar 2019 16:09:35 +0100 Adam Borowski wrote:
> > Control: retitle -1 ITA: btrfs-progs -- Checksumming Copy on Write
> > Filesystem utilities
> > Control: owner -1 !
> >
> > As a long-time user ("thou shalt have no other filesystems before btrfs")
> > and an occassional contributor, I can take it.
> >
>
> Thanks Adam for taking care of it!
Yes, thank you Adam. In Debian is there anyone else besides us (and
nonpackaging Christoph Anton Mitterer), and possibly Hideki, who are
working to make trying out btrfs a more positive experience?
> Just a side note: I think I sponsored a lot of backports for Nicholas in the
> past,
> he is a good contributor, and he sends patches upstream and to Debian
> packaging (dated 2017).
>
Thank you Gianfranco :-)
> Maybe you can both work on the package, he is a DM so he might even upload by
> himself if you
> feel comfortable with his work (Nicholas please tell us if you are still
> interested in btrfs!)
>
I am still interested, and plan to continue to maintain the
stretch-backport and future buster-backport of btrfs-progs. IIRC I've
been maintaining the stable-backport since ~2016, and would appreciate
DM upload permissions for this purpose.
> In any case, two is better than one, specially when one is an upstream
> contributor and Debian maintainer :)
>
IIRC Adam is also an upstream contributor; I remember a while back he
sent a patch for btrfs-progs which more explicitly warns a user who is
about to enable raid5 or raid6 profile. That impressed me, and is one
of the reasons I think we're generally on the same page wrt btrfs.
P.S. I suspect the recent sparse/hole punched file bug that affects
transparent compression might also affect btrfs-convert, and when
convert support is presumably reenabled in the bullseye dev cycle it
would be worth adding some kind of warning.
> I hope to see Nicholas back in the team :)
>
Thanks! :-D On that note, Adam, let's form a ng-fs-integration team.
For now goals could be things like adding support for things like
btrfs installation on subvolume, doing upgrades in a rw snapshot
before rotating the snapshot to default boot rootfs, boot
environments, et al. If possible it would be nice to do this in a
modular enough way to add support for bcachefs--when the time comes.
Oh, and Adam prefers to support sysvinit while I prefer systemd, so
we've already got a bit of diversity ;-)
Regards,
Nicholas
signature.asc
Description: PGP signature
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote: > Just for the record: > > * Sebastian Andrzej Siewior [2018-11-05 00:28]: > > It is a TLS1.3 issue. If I limit max protocol to TLS1.2 then the > > testsuite passes. > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ > unexpectedly returns NULL. I now avoid the function to work around the > issue. This is documented here: https://wiki.openssl.org/index.php/TLS1.3#PSKs Kurt
Bug#925082: postfix: "Chunk exceeds message size limit" when message_size_limit = 0
This is fixed in a new upstream release that I expect to package shortly.
Scott K
On March 19, 2019 6:24:30 PM UTC, Thorben Thuermer wrote:
>Package: postfix
>Version: 3.4.1-1
>Severity: important
>
>Dear Maintainer,
>
>as also reported upstrean at
>https://marc.info/?t=15530176323=1=2
>
>i am running postfix 3.4.1-1 (from debian sid).
>
>i recently noticed that mails from multiple senders (most importantly
>google mail)
>are being rejected with:
>> 552 5.3.4 Chunk exceeds message size limit
>
>postfix logs:
>> Mar 19 17:42:48 ngs postfix/smtpd[22671]: warning: 25E74C1: BDAT
>request from \
>> mail-ed1-f44.google.com[209.85.208.44] exceeds message size limit
>
>this happens regardless of the actual message size,
>even a one-line plaintext message is rejected.
>
>/etc/postfix/main.cf has:
>header_size_limit = 4096000
>message_size_limit = 0
>
>downgrading to 3.3.2 fixed the issue.
>
>i found the responsible code in postfix-3.4.1/src/smtpd/smtpd.c
>commenting out that check also fixes the issue.
>
>/* Block too large chunks. */
>if (state->act_size > var_message_limit - chunk_size) {
>state->error_mask |= MAIL_ERROR_POLICY;
>msg_warn("%s: BDAT request from %s exceeds message size limit",
> state->queue_id ? state->queue_id : "NOQUEUE",
> state->namaddr);
>return skip_bdat(state, chunk_size, final_chunk,
> "552 5.3.4 Chunk exceeds message size limit");
>}
>
>
>after some more reading of code,
>it turns out that this usage of `var_message_limit` is missing the
>check
>of `var_message_limit > 0` that in other places enables `0` to mean
>"no limit", and thus it enforces a limit of 0 with my config :(
>
>
>-- System Information:
>Debian Release: buster/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
>Kernel taint flags: TAINT_WARN
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: sysvinit (via /sbin/init)
>
>Versions of packages postfix depends on:
>ii adduser3.118
>ii cpio 2.12+dfsg-6
>ii debconf [debconf-2.0] 1.5.71
>ii dpkg 1.19.5
>ii e2fsprogs 1.45.0-1
>ii libc6 2.28-8
>ii libdb5.3 5.3.28+dfsg1-0.6
>ii libicu63 63.1-6
>ii libsasl2-2 2.1.27+dfsg-1
>ii libssl1.1 1.1.1b-1
>ii lsb-base 10.2019031300
>ii netbase5.6
>ii ssl-cert 1.0.39
>
>Versions of packages postfix recommends:
>ii python3 3.7.2-1
>
>Versions of packages postfix suggests:
>ii bsd-mailx [mail-reader] 8.1.2-0.20180807cvs-1
>ii libsasl2-modules 2.1.27+dfsg-1
>ii mutt [mail-reader] 1.10.1-2
>pn postfix-cdb
>pn postfix-doc
>pn postfix-ldap
>pn postfix-lmdb
>pn postfix-mysql
>ii postfix-pcre 3.4.1-1
>pn postfix-pgsql
>ii postfix-sqlite 3.4.1-1
>ii procmail 3.22-26
>pn resolvconf
>pn ufw
>
>-- debconf-show failed
Bug#925118: gbp import-orig: verify upstream-vcs-tag
Package: git-buildpackage
Severity: wishlist
Hi gbp folks--
I use gbp with upstream-vcs-tag to keep my debian packaging in sync with
upstream repositories. It's really great!
I'd like to automate my workflow a little bit more, though: one of the
common things that i do is to verify the upstream vcs tags before i do
gbp import-orig.
It occurs to me that gbp import-orig could do that verification for me
(and could also encourage debian package maintainers to encourage
upstream to sign their release tags).
Here's what i'd like to happen:
* if upstream-vcs-tag is present, but the tag itself does not validate,
gbp import-orig should produce a warning with a clear explanation.
* make an option ("upstream-vcs-tag-strict"?) available (default off
initially) that causes gbp import-orig to fail rather than warn in
this scenario.
So, what does "validate" mean? This is subtle, and i'm open to
amendments, but i think a good first pass is to perform all of the
following checks:
0) the tag must be cryptographically signed (presumably that means it
is an OpenPGP-signed git tag)
1) it must be signed by a relevant key. What's a "relevant key"? It
should build a keyring from debian/upstream/vcs-release-key.asc if
that file exists; otherwise, it should build a keyring from
debian/upstream/signing-key.asc. The signature must be made by one
of the keys in the built keyring. This accomodates most projects
easily, which use the same key(s) to sign their git tags as they use
to sign their tarballs. but it also permits tighter control for
verifying upstreams that sign their release tarballs with a
different key than the keys they use to sign their git release tags.
2) the date of the signature should not be in the future (simple sanity
check)
3) the date of the signature should be *after* the date of the previous
upstream release. This could be done by checking the date of the
signature in the previous upstream-vcs-tag commit, or, failing that,
checking the date of the previous upstream release in
debian/changelog. If neither "earlier" date is found (e.g. this is
the first release, or previous releases weren't signed or
something), this check can be skipped with a warning.
4) (optionally) confirm that the tag commit message matches some
pattern. For example, if i think i'm verifying version 1.17 of the
Foo project, i might want to confirm that the first line of the
message in the git tag is "Foo v1.17". This is both a defense
against a malicious tag rename (by someone in control of the
repository) as well as a defense against a repository replacement
(by someone in control of the remote host, who replaces one
repository with another authored by the same upstream signer). This
probably needs to be specified as a regular expression or something
so that different project conventions can be matched (though
something like "%(projectname) v%(version)" is probably a reasonable
default.
i'd be happy to hear feedback on this proposal!
--dkg
signature.asc
Description: PGP signature
Bug#925117: mariadb-10.3: drop the transitional libmariadbclient18 package
Source: mariadb-10.3 Version: 1:10.3.13-1 Severity: serious Hi Otto, please drop the transitional libmariadbclient18 package with the next upload. I think this will prevent a lot of upgrade problems, because packages from stretch will not suddenly start to use libmariadb3. (I just remember the two packages we hat to add Breaks against so far. And I expect users will hit more similar problems.) anbe@coccia:~$ dak rm -Rn -b libmariadbclient18 -s testing Will remove the following packages from testing: libmariadbclient18 | 1:10.3.13-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x Maintainer: Debian MySQL Maintainers --- Reason --- -- Checking reverse dependencies... # Broken Depends: qt4-x11: libqt4-sql-mysql [amd64 armel i386] Dependency problem found. The qt4-x11 FTBFS does seem unrelated to mariadb. Andreas
Bug#925116: posh: use memfd_create(2) for heredocs when available
Package: posh Severity: wishlist Currently posh creates heredocs in the filesystem. This means that heredoc contents will unnecessarily touch the disks, and it also means dealing with risky juggling of tempfile names. It would be nicer, on platforms that support it, if posh could use memfd_create(2) for its heredocs. this appears to be done in the herein() function in exec.c. that code currently opens the same filename twice, once read-only, and then closes the read/write file descriptor. if posh uses memfd_create, it will get the file descriptor in read-write mode. once done writing, it should probably seek() back to offset 0, and somehow convert it to read-only (i don't know how to do that) before returning the file descriptor directly. --dkg
Bug#924959: qtcreator: Probably missing qtdeclarative5-dev dependency
Hi Teemu! El mar., 19 mar. 2019 04:15, Teemu Järvinen escribió: > Package: qtcreator > Version: 4.8.2-1 > Severity: important > > Dear Maintainer, > > I'm a newbie what comes to QT, so tried to install and use qtcreator. > Trying to build a simple "Hello World" -style program lead to error > message stating something like "Unknown module(s) in QT: qml quick". > At first, tried to install all the quick-dev-packages, then googled... > And installing qtdeclarative5-dev did the trick. > > This library doesn't seem to be even suggested dependency, even though > needed to build the simplest qt program. > While qt creator is the preferred way to create qt-based programs it does not means it's exclusively for that. In fact I even use it to program micro controllers. And the minimum necessary dependency to create qt-based applications is qt Core, part of qtbase5-dev. So no, creator should not install any kind of qt development package, it's up to the user to install the required dependencies for his/her project. I'm so closing this bug. Cheers, Lisandro.
Bug#925115: docker: Error response from daemon: unable to find "systemd" in controller set: unknown.
Package: docker.io Version: 18.09.1+dfsg1-5+b10 Severity: important Docker does not work out of the box. $ sudo docker run -it debian /bin/bash docker: Error response from daemon: unable to find "systemd" in controller set: unknown. Workaround: do this once manually: $ sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages docker.io depends on: ii adduser 3.118 ii iptables1.8.2-4 ii libc6 2.28-8 ii libdevmapper1.02.1 2:1.02.155-2 ii libltdl72.4.6-10 ii libnspr42:4.20-1 ii libnss3 2:3.42.1-1 ii libseccomp2 2.3.3-4 ii libsystemd0 241-2 ii lsb-base10.2019031300 ii runc1.0.0~rc6+dfsg1-3 ii tini0.18.0-1 Versions of packages docker.io recommends: ii ca-bundle [ca-certificates] 20181220tarent1 pn cgroupfs-mount ii git 1:2.20.1-2 pn needrestart ii xz-utils 5.2.4-1 Versions of packages docker.io suggests: pn aufs-tools pn btrfs-progs ii debootstrap 1.0.114 pn docker-doc ii e2fsprogs1.45.0-1 pn rinse pn xfsprogs pn zfs-fuse | zfsutils -- no debconf information
Bug#925053: unblock: squirrel3/3.1-6
Hi Andreas, thanks so much for uploading those changes! I prepared them some time ago, but unfortunately really didn't get around to uploading the package, so I'm glad you took the initiative. This is to let the Release Team know that I, as the package maintainer, fully endorse this upload (in case it makes a difference). Best regards, Fabian signature.asc Description: OpenPGP digital signature
Bug#925112: Updating the janest-core-kernel Uploaders list
Source: janest-core-kernel Version: 113.00.00-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the janest-core-kernel package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925114: Updating the lambda-term Uploaders list
Source: lambda-term Version: 1.10.1-2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the lambda-term package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
Just for the record: * Sebastian Andrzej Siewior [2018-11-05 00:28]: > It is a TLS1.3 issue. If I limit max protocol to TLS1.2 then the > testsuite passes. Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ unexpectedly returns NULL. I now avoid the function to work around the issue. ¹ https://www.openssl.org/docs/man1.1.1/man3/SSL_get_psk_identity.html
Bug#925113: Updating the zed Uploaders list
Source: zed Version: 1.4-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the zed package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925110: O: libtext-charwidth-perl -- Récupère la taille des caractères affichés sur le terminal
Package: wnpp The current maintainer of libtext-charwidth-perl, Anibal Monsalve Salazar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: libtext-charwidth-perl Binary: libtext-charwidth-perl Version: 0.04-7.1 Maintainer: Anibal Monsalve Salazar Build-Depends: debhelper (>= 7), perl (>= 5.8.0) Architecture: any Standards-Version: 3.9.2 Format: 3.0 (quilt) Files: 12a2fda3581a03b08b8081931856207c 1878 libtext-charwidth-perl_0.04-7.1.dsc fb42ffebd0b7bb32dbb61c2f18671952 8327 libtext-charwidth-perl_0.04.orig.tar.bz2 b55b65f7d4de97e8591602e1b05d454b 3315 libtext-charwidth-perl_0.04-7.1.debian.tar.bz2 Checksums-Sha256: 57f252bd5680ead35c590610dad5dd63e1524688a21b87eb301c672edc7c3c6b 1878 libtext-charwidth-perl_0.04-7.1.dsc 2990c13c3f4a5479d7dbc5a94b86c23798cf0dc7df54ffe54e065f072558b6ed 8327 libtext-charwidth-perl_0.04.orig.tar.bz2 dff4fada5c342bfcd354612996b20db61c37c366624a6bd398bdaf3b285d4695 3315 libtext-charwidth-perl_0.04-7.1.debian.tar.bz2 Homepage: http://search.cpan.org/search?module=Text::CharWidth Package-List: libtext-charwidth-perl deb perl required arch=any Directory: pool/main/libt/libtext-charwidth-perl Priority: source Section: perl Package: libtext-charwidth-perl Source: libtext-charwidth-perl (0.04-7.1) Version: 0.04-7.1+b1 Installed-Size: 43 Maintainer: Anibal Monsalve Salazar Architecture: amd64 Depends: libc6 (>= 2.2.5), perl-base (>= 5.28.0-3), perlapi-5.28.0 Description-fr: Récupère la taille des caractères affichés sur le terminal Ce module permet au logiciel perl de connaître la taille des caractères et des chaînes affichées sur le terminal, en utilisant les fonctions wcwidth() et wcswidth() de libc. . Il fournit mbwidth(), mbswidth() et mnlen(). Description-md5: 155ed3cc0b2affad276a4e9bc4bfcabc Homepage: http://search.cpan.org/search?module=Text::CharWidth Tag: devel::lang:perl, devel::library, implemented-in::c, implemented-in::perl, role::devel-lib, role::program, use::text-formatting, works-with-format::plaintext, works-with::text Section: perl Priority: optional Filename: pool/main/libt/libtext-charwidth-perl/libtext-charwidth-perl_0.04-7.1+b1_amd64.deb Size: 10004 MD5sum: e7adff4269ad5f96ea75ec9abce26def SHA256: 569110d7f4cfba720d7e322ba1fa2e14b1176f32adf1df6f7cb81aace8b6d1e0 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925109: Updating the netcat Uploaders list
Source: netcat Version: 1.10-41.1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the netcat package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925111: Updating the xfsprogs Uploaders list
Source: xfsprogs Version: 4.20.0-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the xfsprogs package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925107: Updating the bzip2 Uploaders list
Source: bzip2 Version: 1.0.6-8.1 1.0.6-9 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the bzip2 package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925108: Updating the lp-solve Uploaders list
Source: lp-solve Version: 5.5.0.15-4 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the lp-solve package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925106: php7.3-common: please add Breaks: php7.0-curl
Package: php7.3-common
Version: 7.3.3-1
Severity: important
Tags: patch
Hi,
while analyzing piuparts stretch -> buster distupgrade tests, I found
some cases where packages from stretch were not upgraded to the new
version in buster, but the old version was kept installed instead.
This is usually caused by some obsolete packages not getting removed,
because they are part of a package group with a rather high score.
One such problematic package is the old php7.0-curl from stretch. Due to
the libcurl3 -> libcurl4 transition, this is not co-installable with
php7.3-curl from buster and must therefore be removed. But that does not
happen in some cases.
I successfully tested that adding
Breaks: php7.0-curl
to php7.3-common fixes these upgrade paths.
Another issue I encountered is that the generation of debian/control is
non-deterministic, the ordering of the extension packages seems to
depend on the filesystem order in debian/rules.d/ ... which is trivial
to fix with $(sort ).
The attached patch does fix both of these issues, but does not include
the regeneration of debian/control (which is a huge diff due to the
shuffling), please run this yourself before uploading.
Andreas
diff -Nru php7.3-7.3.3/debian/changelog php7.3-7.3.3/debian/changelog
--- php7.3-7.3.3/debian/changelog 2019-03-07 20:43:34.0 +0100
+++ php7.3-7.3.3/debian/changelog 2019-03-19 04:03:09.0 +0100
@@ -1,3 +1,12 @@
+php7.3 (7.3.3-2) UNRELEASED; urgency=medium
+
+ * php7.3-common: Add Breaks against php7.0-curl for smoother upgrades from
+stretch. (Closes: #xx)
+ * Deterministically generate debian/control by sorting the extension
+packages.
+
+ -- Andreas Beckmann Tue, 19 Mar 2019 04:03:09 +0100
+
php7.3 (7.3.3-1) unstable; urgency=medium
* New upstream version 7.3.3
diff -Nru php7.3-7.3.3/debian/php-common.substvars.extra
php7.3-7.3.3/debian/php-common.substvars.extra
--- php7.3-7.3.3/debian/php-common.substvars.extra 2019-03-07
20:43:34.0 +0100
+++ php7.3-7.3.3/debian/php-common.substvars.extra 2019-03-19
04:03:09.0 +0100
@@ -1 +1 @@
-php-common:Breaks=php7.2-sodium
+php-common:Breaks=php7.0-curl, php7.2-sodium
diff -Nru php7.3-7.3.3/debian/rules php7.3-7.3.3/debian/rules
--- php7.3-7.3.3/debian/rules 2019-03-07 20:43:34.0 +0100
+++ php7.3-7.3.3/debian/rules 2019-03-19 04:03:09.0 +0100
@@ -607,7 +607,7 @@
debian/control: debian/control.in debian/rules debian/changelog
debian/source.lintian-overrides debian/rules.d/* debian/php-module.control.in
$(SED) -e "s/@PHP_VERSION@/$(PHP_NAME_VERSION)/g" -e
"s/@BUILT_USING@/$(BUILT_USING)/g" >$@ <$<
- for ext in $(ext_PACKAGES); do \
+ for ext in $(sort $(ext_PACKAGES)); do \
package=php$(PHP_NAME_VERSION)-$${ext}; \
description=$$(eval echo \$${$${ext}_DESCRIPTION}); \
echo >>$@; \
php-horde-exception_2.0.8-4.log.gz
Description: application/gzip
Bug#924496: 'realloc(): invalid next size: 0x000055a779ef2170' crash when opening iPod w/ ~12000 tracks
Hello Bernhard, Now it (a) loads completely without crash from the same iPod (and no changes there), and (b) does so in <50% as long. Arrgh! I hate Heisenbugs It was entirely repeatable last week, 3 for 3. I've not rebooted since before my report, nor has the rhythmbox package changed version (3.4.3-2) , but any of the dependencies may have been updated by automation. I installed the debugging symbol packages, then started under gdb, plugged in the iPod and no load-up crash, plays fine. I then ejected and ran rhythmbox without gdb, plugged in the iPod, and again no load-up crash, plays fine. Some more answers embedded below. On Tue, Mar 19, 2019 at 10:27 AM Bernhard Übelacker wrote: > Hello Fred Korz, > I just tried to get some more information out of backtrace, > without having an iPod or being involved on packaging rhythmbox... > > But am I right this "Debian Release: rodete" is a version > of gLinux - Googles internal rebuild of Debian testing? > Can this be downloaded somewhere? > The name, "rodete", is "ROlling DEbian TEsting" and apparently a pun in spanish as well. It is Debian testing but, as I understand it, run through an internal "sieve" of tests before rolling out a consistent snapshot to users. It's sort of what would happen if one lagged testing by about 1-2 weeks, though some packages can be closer to testing's head if urgent. > And are there debug symbols available for installation? > Yes they are. I've installed these debug symbol packages at work and will install at home tonight. > In Debian these packages are available in a separate > repository [1] and are named like this: > > rhythmbox-dbgsym librhythmbox-core10-dbgsym libglib2.0-0-dbgsym > libtdb1-dbgsym > > If yes, you could try to install them and run rhythmbox > like this and provide the output: > > gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' -ex 'bt' > -ex 'detach' -ex 'quit' --args /usr/bin/rhythmbox > Damn Heisenbug. Blew out 3 times last week, once with a coworker there to see it. None this time, either with gdb or without. > > As this fault seems to be inside the memory allocator, maybe > setting "export MALLOC_CHECK_=2" might reveal some more details? > > Can this fault be reproduced on a plain Debian testing, too? > I'll try tonight/tomorrow (20190319/20190320) on a system at home where I've been running Debian testing for 14+ years now, usually update nightly, and rarely get burned by something slipping through from experimental into testing that wasn't quite ready. It's likely that I'll have to install rhythmbox + symbol packages. I've had no need for rhythmbox there. That system is where the backup copy of my music library lives and I use vlc directly from the files, or serve my library via forked-daapd (successor to firefly / mt-daapd). > Kind regards, > Bernhard > Thanks for the guidance. I wIll both (a) get back to you with results - reproduction or Heisenbug - and (b) keep the instructions in case of some future return of the Heisenbug, hoping to get a better capture. > [1] > https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols > [1] > https://stackoverflow.com/questions/6750815/how-to-turn-off-glibc-run-time-protections >
Bug#924792: pidof: unsanitized user input makes pidof crash
I am certainly open to replacing the "format" flag (-f) with an alternative field separator flag. It has a nice Unixy feel to it and requires less code. Personally, I think using -d (or --delimiter) might be the only change I'd want to make to the patch KatolaZ provided. Partly because pidof already has a lower-case "-s" flag and I want to avoid confusion, and because tools like cut also use "-d". If there are no objections, I'll upstream KatolaZ's patch and remove the "-f" flag. Jesse
Bug#925105: CD-ROM is default repository, not mirror
Package: debian-installer Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16 After a clean installation this in the content of the sources.list: # deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64 DVD Binary-1 20190311-05:00]/ buster contrib main deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64 DVD Binary-1 20190311-05:00]/ buster contrib main deb http://deb.debian.org/debian/ buster main deb-src http://deb.debian.org/debian/ buster main deb http://security.debian.org/debian-security buster/updates main contrib deb-src http://security.debian.org/debian-security buster/updates main contrib I guess you can always argue if this is a bug. But I will claim that by far the waste majority of Debian users want to have the selected mirror in the installation to be the primary repository, not the, in many ways, useless CD-ROM. Wouldn't it be more fair that the very few that actually want the CD-ROM to be the primary repositor, are the one who has to modify the sources.list? And not the waste majority of the users. And if they don't, they can just skip selecting a mirror in the installation, and then the CD-ROM should be the repository. install log attached. Debian_install_logs.7z Description: Binary data
Bug#925104: Updating the hepmc Uploaders list
Source: hepmc Version: 2.06.09-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the hepmc package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925103: Updating the fieldslib Uploaders list
Source: fieldslib Version: 113.33.03-2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the fieldslib package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925051: diffoscope: FTBFS in stretch (failing tests)
Hi Santiago, > The relevant thing, IMO, is that proposed-updates and point > releases still exist for stretch, so I don't see it overkill Sure. Can you still loop the SRMs in on this before I backport this patch and create a stretchpu bug, etc. etc.? Thanks. :) > I don't see how the release cycle of buster is related. (Only in that one's efforts and energies might be best-placed directed towards buster, rather than stretch.) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#925102: x2gobroker: RuntimeError when run as WSGI process f rom apache
Package: x2gobroker Version: 0.0.4.0-3 Approximately half the time, wget -O - http://127.0.0.1/x2gobroker/ yields a 500 Internal Server Error. /var/log/x2gobroker/wsgi.log shows the following: > wsgilog.log: Mon, 18 Mar 2019 16:01:12 ERROR Server got itself in trouble > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/wsgilog/__init__.py", line 192, in > __call__ > return self.application(environ, start_response) > File "/usr/lib/x2gobroker/wsgi/x2gobroker-wsgi", line 408, in _application > return _tornado_application(environ, start_response) > File "/usr/lib/python3/dist-packages/tornado/wsgi.py", line 83, in __call__ > return WSGIAdapter(self)(environ, start_response) > File "/usr/lib/python3/dist-packages/tornado/wsgi.py", line 242, in __call__ > self.application(request) > File "/usr/lib/python3/dist-packages/tornado/wsgi.py", line 207, in > application, request) > File "/usr/lib/python3/dist-packages/tornado/web.py", line 2097, in __call__ > return dispatcher.execute() > File "/usr/lib/python3/dist-packages/tornado/web.py", line 2228, in execute > **self.path_kwargs) > File "/usr/lib/python3/dist-packages/tornado/gen.py", line 297, in wrapper > future = _create_future() > File "/usr/lib/python3/dist-packages/tornado/gen.py", line 187, in > _create_future > future = Future() > File "/usr/lib/python3.7/asyncio/events.py", line 644, in get_event_loop > % threading.current_thread().name) > RuntimeError: There is no current event loop in thread 'Dummy-1'. This issue appears to be the same as in this tornado bug: https://github.com/tornadoweb/tornado/issues/2371 The following workaround is suggested: > import asyncio > from tornado.platform.asyncio import AnyThreadEventLoopPolicy > asyncio.set_event_loop_policy(AnyThreadEventLoopPolicy()) The error disappeared after adding these lines right after "### launch as WSGI application ###" in /usr/bin/x2gobroker. I am using a freshly installed Debian testing VM with two vCPUs. I used the following command to install the packages: apt install apache2 x2gobroker x2gobroker-wsgi. To get this result I also had to apply the fixes to my two recent bug reports on x2gobroker and x2gobroker-wsgi.
Bug#925051: diffoscope: FTBFS in stretch (failing tests)
On Tue, Mar 19, 2019 at 03:29:52PM -0400, Chris Lamb wrote: > Hi Santiago, > > > Ok, but this still should be fixed in stretch, right? > > (Packages in stretch must build in stretch). > > Sure thing, but this would require a stable update which seems a > little overkill, especially at this point in the buster release cycle…? I don't see how the release cycle of buster is related. The relevant thing, IMO, is that proposed-updates and point releases still exist for stretch, so I don't see it overkill at all. Thanks.
Bug#925101: Updating the ethtool Uploaders list
Source: ethtool Version: 1:4.19-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the ethtool package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925100: Updating the cpio-doc Uploaders list
Source: cpio-doc Version: 2.12-0.1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the cpio-doc package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925099: Updating the libmnl Uploaders list
Source: libmnl Version: 1.0.4-2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the libmnl package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925097: Updating the pciutils Uploaders list
Source: pciutils Version: 1:3.5.2-1 1:3.3.1-1.2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the pciutils package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925098: Updating the sensible-utils Uploaders list
Source: sensible-utils Version: 0.0.12 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the sensible-utils package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925096: Updating the gparted Uploaders list
Source: gparted Version: 0.32.0-2 0.30.0-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the gparted package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#924192: ntpsec: at boot ntpsec starts before DNS is available
Thanks! I’ll give it a try tonight… Rick > On Mar 19, 2019, at 10:18 AM, Richard Laager wrote: > > Attached is an untested debdiff. This is the upstream change refreshed > to apply to the package. You should be able to apply it and build a > package locally like this: > > sudo apt update > sudo apt install build-essential devscripts > sudo apt build-dep ntpsec > apt source ntpsec > cd ntpsec-1.1.3+dfsg1 > patch -p1 < ~/ntpsec_1.1.3+dfsg1-3~1.gbpdde9c0.debdiff > debuild -uc -us > > Can you try that and see if it fixes the issue for you? > > I'm sorry I'm short on time today and couldn't do further testing > myself. I hope this helps. > > -- > Richard >
Bug#907046: texlive-science: Drop dependency on python
On 23.08.18 14:13, Paride Legovini wrote: Hi, > As far as I can tell texlive-science depends on 'python' because it > includes sympytexpackage. I think this dependency can be dropped, as > sympytexpackage needs python-sympy to work, which itself depends on > python. > I've added python-sympy to recommends, I've left the dep on python, as I'm not sure, why it was added. Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#924888: subpage /misc/related_links
On Tue, Mar 19, 2019 at 08:07:08PM +0100, Thomas Lange wrote: >We should remove related_links.wml completely. > >"Software that is DFSG compliant" just lists some projects but why >those and not others that are also DFSG compliant? > >"Miscellaneous GNU/Linux links" >DebianForum.de, exDebian, Korean Debian Users should go into the >support page of the corresponding language, if not already done. > >Linux.com, Linux.org, Freshcode, SourceForge are random links, which >gives not more information about Debian. > >"User groups": the domain luglist.com is dead, not in DNS any more. > >"Other Free Operating System Projects" again some non-Debian specific >links. +1 -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Bug#908533: (no subject)
I would also be interested if the package's source point to yshui's compton fork that seems to be the new de facto compton development repository. Any chance you could consider to change the source or should we consider an other option (NMU, Orphaned, etc)? Thanks for taking the time to let us know :).
Bug#925095: bats: Upstream source has changed
Package: bats Version: 0.4.0-1.1 Severity: normal Dear Maintainer, The current upstream for this package is https://github.com/sstephenson/bats . The last commit on this tree was over three years ago. A newer tree that is being actively maintained is located at https://github.com/bats-core/bats-core . Please consider packaging from this newer upstream. Thank you. -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#925094: ITP: knack -- A Python command line interface framework
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: knack Version : 0.5.3 Upstream Author : Microsoft Corporation * URL : https://github.com/Microsoft/knack * License : MIT Programming Lang: python Description : A Python command line interface framework Also available via pip: https://pypi.org/project/knack/ Knack is a dependency of many open-source Azure command line tools like azure-cli, vsts-cli and storage-fabric-cli. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#924448: Debug data! (Was: gimp: Bug#924448: segfault when using measuring tool)
Hi Bernhard, Thank you very much for sharing your clever debug fu! I tried it. I'm happy to report your advice elicited a stack trace like the one in bug report #908549. It's OK with me if you merge my stupendous bug report, #924448, with it. Plus, if it would be comfortable, convenient, and all those good things, feel free to share any thoughts you may happen to have on how I might reconcile why 1.) Frederic MASSOT wrote "The fix is built-in for versions 2.10" at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908549#20 2.) but version 2.10.8-2 of debian's gimp package seems to still have the same bug? Thank you again for maintaining gimp and sharing your considerable skills so freely. Both are fine qualities! So, Kingsley PS: For what it's worth, details of what I tried follows. root:~ aptitude install gimp-dbgsym libglib2.0-0-dbgsym km:~ script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' -ex 'bt' -ex 'detach' -ex 'quit' --args gimp" -a gdb_gimp_$(date +%Y-%m-%d_%H-%M-%S).log Its output is the first file attached to this email. Maybe we agree it has less of a back trace. Next, I installed the systemd-coredump package. root:~ aptitude install systemd-coredump re-ran gimp, km:~ gimp ( create a new image select the measure tool left click on the new image wait a few seconds, and. kaBOOM! ) and found a cool new core! root:~ coredumpctl list TIMEPID UID GID SIG COREFILE EXE Tue 2019-03-19 11:27:04 PDT 20581 1000 1000 11 present /usr/bin/gimp-2.10 root:~ coredumpctl gdb 20581 coredumpctl's output is in the second file attached to this email. It looks to me like the main stack trace (of thread 20581) reveals frames g_closure_invoke (libgobject-2.0.so.0) signal_emit_unlocked_R (libgobject-2.0.so.0) g_signal_emit_valist (libgobject-2.0.so.0) g_signal_emit (libgobject-2.0.so.0) gimp_tool_widget_changed (gimp-2.10) g_object_notify_by_spec_internal (libgobject-2.0.so.0) gimp_tool_compass_update_angle (gimp-2.10) gimp_tool_compass_changed (gimp-2.10) like in your email for the similar bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908549#10 Plus, much as you astutely asked yesterday, yes, they do repeat. 8 times. On 03/19/2019 14:28, Bernhard Übelacker wrote: > Hello Kingsley G. Morse Jr., > > > > My main concern?>> The normal way of eliciting a back trace from> within > > gdb didn't work.> > The non repeating lines were reported by defining> a > > function in gdb and logging output to a file. > > You can start gimp that way to get a backtrace: > > script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' > -ex 'bt' -ex 'detach' -ex 'quit' --args gimp" -a gdb_gimp_$(date > +%Y-%m-%d_%H-%M-%S).log > > This gave me a 11MB file, so it took some time > for gdb to finish to write the 68000 stack frames. > > Another alternative is to install a coredump collector > like systemd-coredump. After that you should be able to > list collected core dumps of the current boot by: > > coredumpctl list > > And have that core dump loaded into gdb by: > > coredumpctl gdb > > Both may lead to better results if you have debug > symbols installed like described in [1]. > In this case packages gimp-dbgsym libglib2.0-0-dbgsym. > > For debugging graphical applications it may also be convenient > to ssh into the target machine if a second computer is available, > or at least start gdb from the "ctl-alt-F1 old school console". > > This can be combined with running gdb inside tmux in the graphical > environment and, if keyboard gets locked, ctl-alt-F1 and 'tmux attach' > to access the locked gdb. And if the tmux step was missed, it may be > possible to "move" the locked gdb process to another terminal ... > > Happy debugging. :-) > > Kind regards, > Bernhard > > [1] > https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols -- Time is the fire in which we all burn. Script started on 2019-03-19 11:11:34-0700 Reading symbols from gimp...Reading symbols from /usr/lib/debug/.build-id/5a/56cddb418553f4e42eb66a0c9148bb7543ddcd.debug...done. done. Starting program: /usr/bin/gimp BFD: /usr/lib/debug/.build-id/da/c552d8815d9a4ef5d055ab6cd81e0478998e2c.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib/debug/.build-id/da/c552d8815d9a4ef5d055ab6cd81e0478998e2c.debug: unable to initialize decompress status for section .debug_aranges warning: File "/usr/lib/debug/.build-id/da/c552d8815d9a4ef5d055ab6cd81e0478998e2c.debug" has no build-id, file skipped BFD: /usr/lib/debug/.build-id/e5/02ab31fa523af198980f0f57ccb2949798ec9d.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib/debug/.build-id/e5/02ab31fa523af198980f0f57ccb2949798ec9d.debug:
Bug#925081: Add Palo Alto Global Protect support.
Control: forwarded -1 https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/issues/1 Control: tags -1 + confirmed upstream On Tue, Mar 19, 2019 at 12:02:40 -0600, Jason Fergus wrote: > There is a patch out there for adding this already, but it would be nice to > have the > added functionality, since the openconnect currently in testing already > supports GP > protocol. Sure, thank you, once that is merged upstream, and after buster is released. -- mike signature.asc Description: PGP signature
Bug#923942: postinst script error: mv: cannot move '/tmp/ca-certificates.crt.tmp.hi8W7j' to a subdirectory of itself, 'ca-certificates.crt'
On 3/19/19 3:29 AM, Michael Stapelberg wrote: > So I debugged this some more, and found out that the problem is that > moving *any files* from /tmp to /etc does not work, but only within the > Docker container running on travis-ci, and only when configured with > “group: deprecated-2017Q3”. The fix is to remove that config option: > https://github.com/i3/i3/pull/3650. > > I will write this off to kernel weirdness, but, independently of this > issue, it might make sense to change update-ca-certificates to no longer > need /tmp and instead create the temporary files within /etc, which > would get us closer to an atomic replacement. I appreciate the follow up. I did some quick reproduction attempts last weekend, but was unable to get the same behavior, so this makes more sense. There's another recent edge case bug, #923784 (full root partition), that may benefit from using an explicit /etc path with mktmp, so maybe we'll get a 2 for 1 fix. -- Kind regards, Michael
Bug#925051: diffoscope: FTBFS in stretch (failing tests)
Hi Santiago, > Ok, but this still should be fixed in stretch, right? > (Packages in stretch must build in stretch). Sure thing, but this would require a stable update which seems a little overkill, especially at this point in the buster release cycle…? Fancy pinging the SRMs on this? Not had to deal with this before. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#925051: diffoscope: FTBFS in stretch (failing tests)
On Tue, Mar 19, 2019 at 03:22:26PM -0400, Chris Lamb wrote: > I believe this was address on the diffoscope side here: > > > https://salsa.debian.org/reproducible-builds/diffoscope/commit/4a35e55497fac9845ca55be28fbd9e25b4e8576f > > ... which was released in diffoscope 112. Ok, but this still should be fixed in stretch, right? (Packages in stretch must build in stretch). Thanks.
Bug#925051: diffoscope: FTBFS in stretch (failing tests)
fixed 925051 112 thanks Hi Santiago, > I tried to build this package in stretch but it failed: […] This is because ghostscript was updated in stretch and it (unfortunately) now generates different output. I believe this was address on the diffoscope side here: https://salsa.debian.org/reproducible-builds/diffoscope/commit/4a35e55497fac9845ca55be28fbd9e25b4e8576f ... which was released in diffoscope 112. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#925093: debian-history: links to libresoft.es no longer valid
Package: debian-history Severity: normal Dear Maintainers, The two links to debian-counting.libresoft.es present in lines 742 and 744 of file project-history.en.dbk as of commit 176f60e3 seem to be no longer valid. Regards, Rafa. signature.asc Description: PGP signature
Bug#924888: subpage /misc/related_links
We should remove related_links.wml completely. "Software that is DFSG compliant" just lists some projects but why those and not others that are also DFSG compliant? "Miscellaneous GNU/Linux links" DebianForum.de, exDebian, Korean Debian Users should go into the support page of the corresponding language, if not already done. Linux.com, Linux.org, Freshcode, SourceForge are random links, which gives not more information about Debian. "User groups": the domain luglist.com is dead, not in DNS any more. "Other Free Operating System Projects" again some non-Debian specific links. -- regards Thomas
Bug#925091: Updating the siscone Uploaders list
Source: siscone Version: 2.0.6-2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the siscone package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925092: Updating the bin-prot Uploaders list
Source: bin-prot Version: 113.33.03-4 113.33.03-2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the bin-prot package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925090: Updating the pcp Uploaders list
Source: pcp Version: 4.3.1-1 3.10.6 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the pcp package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925085: Updating the libevent Uploaders list
Source: libevent Version: 2.1.8-stable-4 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the libevent package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925087: Updating the nasm Uploaders list
Source: nasm Version: 2.14-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the nasm package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925089: Updating the nfs-utils Uploaders list
Source: nfs-utils Version: 1:1.3.4-2.4 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the nfs-utils package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925088: Updating the libedit Uploaders list
Source: libedit Version: 3.1-20181209-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the libedit package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925086: Updating the xfsdump Uploaders list
Source: xfsdump Version: 3.1.6+nmu2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint anibal has not been working on the xfsdump package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#924712: crypt() not available _XOPEN_SOURCE is defined
* Laurent Bigonville: > Package: libc6-dev > Version: 2.28-8 > Severity: serious > > Hi, > > The crypt.3 manpage, state that _XOPEN_SOURCE should be define for > crypt() to be available. > > But it looks that it's currently the opposite, if _XOPEN_SOURCE is > defined, the function cannot be found. Can you compile the software using _DEFAULT_SOURCE (well, the default) or _GNU_SOURCE instead? We do not want to provide the CRYPT extension anymore because it implies not just support for the crypt function, but also for the DES encryption functions, which definitely do not want. In _XOPEN_SOURCE mode, it's either all of these functions or none of them (and we chose the latter because of DES), otherwise glibc wouldn't conform to the interface specification. We definitely should update the manual page, though.
Bug#925084: di-netboot-assistant: debian-installer-xxx-netboot-yyy are wrongly configured
Package: di-netboot-assistant Version: 0.60~bpo9+1 Severity: normal Tags: d-i Dear Maintainer, I've just discovered and then set-up di-netboot-assistant to manage several debian netboot versions. It works great when it manages setup di-netboot-assistant installed by itself, but it fails to configure correctly already installed installers from official packages. I get a "No DEFAULT or UI configuration directive found!" when the PXE client boots on one of these installer. (Other system information are not relevant as I'm not writing from the PXE boot server) Best regards, Jérémy VIES -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages di-netboot-assistant depends on: ii curl 7.64.0-1 ii wget 1.20.1-1 Versions of packages di-netboot-assistant recommends: ii grub-efi-amd64-bin2.02+dfsg1-12 pn tftpd-hpa | atftpd | dnsmasq Versions of packages di-netboot-assistant suggests: pn dnsmasq | isc-dhcp-server | udhcpd pn syslinux pn vim-addon-manager
Bug#925083: unblock: nsca-ng/1.5-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package nsca-ng 1.5-4.
It cherry-picks the OpenSSL 1.1.1 change from the 1.6 release available
in experimental.
unblock nsca-ng/1.5-4
Kind Regards,
Bas
diff -Nru nsca-ng-1.5/debian/changelog nsca-ng-1.5/debian/changelog
--- nsca-ng-1.5/debian/changelog2018-07-29 12:38:31.0 +0200
+++ nsca-ng-1.5/debian/changelog2019-03-19 18:32:59.0 +0100
@@ -1,3 +1,14 @@
+nsca-ng (1.5-4) unstable; urgency=medium
+
+ * Team upload.
+ * Drop autopkgtest to test installability.
+ * Add lintian override for testsuite-autopkgtest-missing.
+ * Bump Standards-Version to 4.3.0, no changes.
+ * Add upstream patch to fix FTBFS with OpenSSL 1.1.1.
+(closes: #900152)
+
+ -- Bas Couwenberg Tue, 19 Mar 2019 18:32:59 +0100
+
nsca-ng (1.5-3) unstable; urgency=medium
* Team upload.
diff -Nru nsca-ng-1.5/debian/control nsca-ng-1.5/debian/control
--- nsca-ng-1.5/debian/control 2018-07-29 12:38:31.0 +0200
+++ nsca-ng-1.5/debian/control 2019-03-19 18:29:13.0 +0100
@@ -10,7 +10,7 @@
libbsd-dev,
libssl-dev,
libsystemd-dev
-Standards-Version: 4.1.5
+Standards-Version: 4.3.0
Vcs-Browser: https://salsa.debian.org/nagios-team/pkg-nsca-ng
Vcs-Git: https://salsa.debian.org/nagios-team/pkg-nsca-ng.git
Homepage: http://www.nsca-ng.org/
diff -Nru
nsca-ng-1.5/debian/patches/0001-Work-around-TLSv1.3-PSK-bug-in-OpenSSL-1.1.1.patch
nsca-ng-1.5/debian/patches/0001-Work-around-TLSv1.3-PSK-bug-in-OpenSSL-1.1.1.patch
---
nsca-ng-1.5/debian/patches/0001-Work-around-TLSv1.3-PSK-bug-in-OpenSSL-1.1.1.patch
1970-01-01 01:00:00.0 +0100
+++
nsca-ng-1.5/debian/patches/0001-Work-around-TLSv1.3-PSK-bug-in-OpenSSL-1.1.1.patch
2019-03-19 18:31:41.0 +0100
@@ -0,0 +1,77 @@
+Description: Work around TLSv1.3 PSK bug in OpenSSL 1.1.1
+ When TLSv1.3 is used with (at least) OpenSSL 1.1.1b, the
+ SSL_get_psk_identity(3) unexpectedly returns NULL. Work around this
+ issue be storing a copy of the PSK identity into the SSL object.
+From: Holger Weiß
+Origin
:https://github.com/weiss/nsca-ng/commit/7d9ca3413e661c0ac8a020bf674d16c3af4ebccb
+Bug: https://github.com/weiss/nsca-ng/issues/4
+Bug-Debian: https://bugs.debian.org/900152
+
+--- a/src/common/tls.c
b/src/common/tls.c
+@@ -530,6 +530,8 @@ tls_free(tls_state *tls)
+ free(tls->output);
+ if (tls->addr != NULL)
+ free(tls->addr);
++ if (tls->id != NULL)
++ free(tls->id);
+ if (tls->peer != NULL)
+ free(tls->peer);
+ if (tls->ssl != NULL)
+@@ -632,7 +634,7 @@ accept_ssl_cb(EV_P_ ev_io *w, int revent
+ debug("TLS handshake with %s not (yet) successful", tls->addr);
+ check_tls_error(EV_A_ w, result);
+ } else { /* The TLS connection is established. */
+- if ((tls->id = SSL_get_psk_identity(tls->ssl)) == NULL) {
++ if ((tls->id = SSL_get_app_data(tls->ssl)) == NULL) {
+ error("Cannot retrieve client identity");
+ tls_free(tls);
+ } else {
+--- a/src/common/tls.h
b/src/common/tls.h
+@@ -61,7 +61,7 @@
+ typedef struct tls_state_s {
+ /* public: */
+ void *data; /* Can freely be used by the caller. */
+- const char *id; /* Client ID (e.g., "foo"). */
++ char *id; /* Client ID (e.g., "foo"). */
+ char *addr; /* Client IP address (e.g., "192.0.2.2"). */
+ char *peer; /* Client ID and IP address (e.g., "foo@192.0.2.2"). */
+
+--- a/src/server/auth.c
b/src/server/auth.c
+@@ -41,6 +41,7 @@
+ #include "log.h"
+ #include "system.h"
+ #include "util.h"
++#include "wrappers.h"
+
+ static bool match(regex_t * restrict, const char * restrict);
+
+@@ -49,8 +50,8 @@ static bool match(regex_t * restrict, co
+ */
+
+ unsigned int
+-check_psk(SSL *ssl __attribute__((__unused__)), const char *identity,
+- unsigned char *password, unsigned int max_password_len)
++check_psk(SSL *ssl, const char *identity, unsigned char *password,
++ unsigned int max_password_len)
+ {
+ cfg_t *auth;
+ const char *configured_pw;
+@@ -63,6 +64,15 @@ check_psk(SSL *ssl __attribute__((__unus
+ }
+ debug("Verifying key provided by %s", identity);
+
++ /*
++ * With (at least) OpenSSL 1.1.1b, SSL_get_psk_identity(3) returns NULL
++ * when TLSv1.3 is used. As a workaround, we store the ID ourselves:
++ */
++ if (SSL_set_app_data(ssl, xstrdup(identity)) != 1) {
++ error("Cannot store client-supplied ID (`%s')", identity);
++ return 0;
++ }
++
+ configured_pw = cfg_getstr(auth, "password");
+ password_len = MIN(strlen(configured_pw), max_password_len);
+ (void)memcpy(password, configured_pw, password_len);
diff -Nru
Bug#925082: postfix: "Chunk exceeds message size limit" when message_size_limit = 0
Package: postfix
Version: 3.4.1-1
Severity: important
Dear Maintainer,
as also reported upstrean at
https://marc.info/?t=15530176323=1=2
i am running postfix 3.4.1-1 (from debian sid).
i recently noticed that mails from multiple senders (most importantly google
mail)
are being rejected with:
> 552 5.3.4 Chunk exceeds message size limit
postfix logs:
> Mar 19 17:42:48 ngs postfix/smtpd[22671]: warning: 25E74C1: BDAT request from
> \
> mail-ed1-f44.google.com[209.85.208.44] exceeds message size limit
this happens regardless of the actual message size,
even a one-line plaintext message is rejected.
/etc/postfix/main.cf has:
header_size_limit = 4096000
message_size_limit = 0
downgrading to 3.3.2 fixed the issue.
i found the responsible code in postfix-3.4.1/src/smtpd/smtpd.c
commenting out that check also fixes the issue.
/* Block too large chunks. */
if (state->act_size > var_message_limit - chunk_size) {
state->error_mask |= MAIL_ERROR_POLICY;
msg_warn("%s: BDAT request from %s exceeds message size limit",
state->queue_id ? state->queue_id : "NOQUEUE",
state->namaddr);
return skip_bdat(state, chunk_size, final_chunk,
"552 5.3.4 Chunk exceeds message size limit");
}
after some more reading of code,
it turns out that this usage of `var_message_limit` is missing the check
of `var_message_limit > 0` that in other places enables `0` to mean
"no limit", and thus it enforces a limit of 0 with my config :(
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages postfix depends on:
ii adduser3.118
ii cpio 2.12+dfsg-6
ii debconf [debconf-2.0] 1.5.71
ii dpkg 1.19.5
ii e2fsprogs 1.45.0-1
ii libc6 2.28-8
ii libdb5.3 5.3.28+dfsg1-0.6
ii libicu63 63.1-6
ii libsasl2-2 2.1.27+dfsg-1
ii libssl1.1 1.1.1b-1
ii lsb-base 10.2019031300
ii netbase5.6
ii ssl-cert 1.0.39
Versions of packages postfix recommends:
ii python3 3.7.2-1
Versions of packages postfix suggests:
ii bsd-mailx [mail-reader] 8.1.2-0.20180807cvs-1
ii libsasl2-modules 2.1.27+dfsg-1
ii mutt [mail-reader] 1.10.1-2
pn postfix-cdb
pn postfix-doc
pn postfix-ldap
pn postfix-lmdb
pn postfix-mysql
ii postfix-pcre 3.4.1-1
pn postfix-pgsql
ii postfix-sqlite 3.4.1-1
ii procmail 3.22-26
pn resolvconf
pn ufw
-- debconf-show failed
Bug#925081: Add Palo Alto Global Protect support.
Package: network-manager-openconnect-gnome Version: 1.2.4-2 Severity: wishlist There is a patch out there for adding this already, but it would be nice to have the added functionality, since the openconnect currently in testing already supports GP protocol. https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/merge_requests/6 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-openconnect-gnome depends on: ii libatk1.0-0 2.30.0-2 ii libc62.28-8 ii libcairo-gobject21.16.0-3 ii libcairo21.16.0-3 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-1 ii libgtk-3-0 3.24.5-1 ii libnm0 1.14.6-2 ii libopenconnect5 8.02-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libsecret-1-00.18.7-1 ii libxml2 2.9.4+dfsg1-7+b3 ii network-manager-openconnect 1.2.4-2 network-manager-openconnect-gnome recommends no packages. network-manager-openconnect-gnome suggests no packages. -- no debconf information
Bug#924473: Corrected path
On Sun, Mar 17, 2019 at 07:09:52PM +0100, Bruno Kleinert wrote: Hi Jonathan, please find attached a debdiff that updates the path to the manpage. Thanks for this, I will endeavour to apply and upload Tomorrow (hit a snag locally, my sbuild environment hath borken)
Bug#925080: git-buildpackage: exporting fails in overlay mode if .../-tmp exists
Package: git-buildpackage Version: 0.9.13 Severity: important Hi, I found a little oddity with --overlay. If ../buildarea/-tmp exists (because I interrupted a build early with Ctrl-C), the next build will fail because -tmp is missing (after gbp-buildpackage successfully renamed the old bits to -tmp.obsolete.*.*). Rerunning the command again will succeed. This seems to be reproducible with a regular (non-native) package that does not use overlay mode by just using --git-overlay, --git-export-dir, --git-tarball-dir. (The build will fail in this case, but it seems to be sufficient to reproduce.) Here is the transcript from doing this with (a properly overlayed) package nvidia-cuda-toolkit (but debian/gbp.conf removed). I also noticed that it queries the source format quite often - why isn't that cached? $ mkdir -p ../build-area/nvidia-cuda-toolkit-tmp $ gbp buildpackage --git-verbose --git-overlay --git-export-dir=../build-area --git-tarball-dir=../tarballs --git-no-pristine-tar gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', '--git-dir'] gbp:debug: /bin/true [] [] gbp:debug: ['git', 'status', '--porcelain'] gbp:debug: ['git', 'symbolic-ref', 'HEAD'] gbp:debug: ['git', 'show-ref', 'refs/heads/master'] gbp:debug: ['git', 'ls-tree', 'HEAD'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/changelog'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: Looking for orig tarballs 'nvidia-cuda-toolkit_9.2.148.orig.tar.gz' at '../tarballs' gbp:info: All Orig tarballs 'nvidia-cuda-toolkit_9.2.148.orig.tar.gz' found at '../tarballs' gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:info: Extracting 'nvidia-cuda-toolkit_9.2.148.orig.tar.gz' to '/tmp/gbp-test/build-area/nvidia-cuda-toolkit-tmp' gbp:debug: tar ['-C', '/tmp/gbp-test/build-area/nvidia-cuda-toolkit-tmp', '-a', '-xf', '../tarballs/nvidia-cuda-toolkit_9.2.148.orig.tar.gz'] [] tar: /tmp/gbp-test/build-area/nvidia-cuda-toolkit-tmp: Cannot open: No such file or directory tar: Error is not recoverable: exiting now gbp:error: Couldn't unpack '../tarballs/nvidia-cuda-toolkit_9.2.148.orig.tar.gz': it exited with 2 $ ls -l ../build-area/ total 0 drwxr-xr-x 2 beckmann beckmann 40 Mar 19 18:57 nvidia-cuda-toolkit-tmp.obsolete.1553018428.34257 lrwxrwxrwx 1 beckmann beckmann 62 Mar 19 19:00 nvidia-cuda-toolkit_9.2.148.orig.tar.gz -> /tmp/gbp-test/tarballs/nvidia-cuda-toolkit_9.2.148.orig.tar.gz $ gbp buildpackage --git-verbose --git-overlay --git-export-dir=../build-area --git-tarball-dir=../tarballs --git-no-pristine-tar gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', '--git-dir'] gbp:debug: /bin/true [] [] gbp:debug: ['git', 'status', '--porcelain'] gbp:debug: ['git', 'symbolic-ref', 'HEAD'] gbp:debug: ['git', 'show-ref', 'refs/heads/master'] gbp:debug: ['git', 'ls-tree', 'HEAD'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/changelog'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format'] gbp:debug: Looking for orig tarballs 'nvidia-cuda-toolkit_9.2.148.orig.tar.gz' at '../tarballs' gbp:info: All Orig tarballs 'nvidia-cuda-toolkit_9.2.148.orig.tar.gz' found at '../tarballs' gbp:debug: ['git', 'show', '--pretty=medium',
Bug#925079: lightning: cannot install due to hard amd64 dependency
Package: lightning Version: 1:60.5.1-1~deb9u1 Severity: normal Dear Maintainer, I don't know if the following is due to my inability, a limitation in apt or some problem with lightning, so please bear with me :/ In any case, I had both lightning and thunderbird:i386 installed in stretch, because this is a "low-memory" amd64 system, and installing some key programs (such as firefox and thunderbirds) as i386 packages shaves off multiple gigabytes of ram usage (or rather, swap usage in practise). This worked fine until I recently tried to upgrade to buster. After the upgrade, lightning was gone. Trying to install it manually tries to pull in "thunderbird" (the amd64 package), even thought thunderbird (the i386 package) is already installed. Trying to force the issue with: # apt install lightning thunderbird:i386 Fails: The following packages have unmet dependencies: lightning : Depends: thunderbird (>= 1:60.5.1-1) but it is not going to be installed So the problem is that lightning has a hard dependency on the amd64 version of the package. This is common, and the normal solution for this problem is to install the matching lightning:i386 package, but unfortunately, lighting doesn't have a :i386 package, likely because it is Architecture:all. Again, this doesn't necessarily look like a problem with lightning, even though it is the only package that causes a problem on the system. It could well be that I am doing something wrong, or that this is a shortcoming in apt. I decided to bring this to your attention. If you know the right package for this bug (if any), it would be great if you could reassign. -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 4.19.27-041927-generic (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages lightning depends on: pn thunderbird lightning recommends no packages. Versions of packages lightning suggests: pn calendar-google-provider ii fonts-lyx 2.2.2-1
Bug#924595: backup2l: Sometimes fails to detect running instance.
On Fri, 15 Mar 2019 10:31:36 +0100 Gundolf Kiefer wrote: > Thank you for the great report and the patch! > > I applied the patch upstream: > > https://github.com/gkiefer/backup2l/commit/3941b1a50aa184a4e42fcf80345b248472404108 > > -- Gundolf Kiefer > > Gundolf, Thank you for the quick response and for doing the work of maintaining the package. It is greatly appreciated! Wayne Conrad
Bug#925077: missing autopkg test dependency
Package: src:fdroidserver Version: 1.1.1-1 Severity: important Tags: sid buster patch I have seen this only on the Ubuntu autopkg tests, but I don't see why this doesn't fail on the Debian buildds either. It looks like the aapt dependency is needed for the second test as well. test log at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/f/fdroidserver/20190319_140721_0817f@/log.gz patch at http://launchpadlibrarian.net/415757268/fdroidserver_1.1.1-1_1.1.1-1ubuntu1.diff.gz
Bug#925078: sgt-puzzles: Please update package from fresh upstream.
Package: sgt-puzzles Version: 20170606.272beef-1 Severity: wishlist Dear Maintainer, Please update the package with fresh upstream version. Most reposted bugs are already fixed in upstream, especially https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852146. This bug prevents playing some puzzles on hard levels. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sgt-puzzles depends on: ii libatk1.0-0 2.30.0-2 ii libc62.28-8 ii libcairo-gobject21.16.0-3 ii libcairo21.16.0-3 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-1 ii libgtk-3-0 3.24.5-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 Versions of packages sgt-puzzles recommends: ii google-chrome-stable [www-browser] 73.0.3683.75-1 sgt-puzzles suggests no packages. -- no debconf information
Bug#925076: Updating the ocaml-csv Uploaders list
Source: ocaml-csv Version: 1.5-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the ocaml-csv package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#924781: Inclusion of translated debconf messages
Hello Thomas, hello Michal, you recentely added debconf messages to your package. Since we are in the freeze the addition of debconf translations need to be coordinated. It would be great if the translated debconf messages could be part of Buster. I would like to coordinate that with you (and in the next step the release team). Would you like to ask for translations (informally or with podebconf-report-po(1))? Do you have a deadline, when such an upload could happen? Since we are in the deep freeze, waiting for too long is not advisable. It would be great if we could come up with a plan to get the translations into Buster. Thanks. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: Digital signature
Bug#925072: Updating the extlib Uploaders list
Source: extlib Version: 1.7.0-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the extlib package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925075: Updating the rivet Uploaders list
Source: rivet Version: 1.8.3-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the rivet package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#925071: openjdk-11-jre: please add Breaks: eclipse-platform (<< 3.8.1-11)
Package: openjdk-11-jre
Version: 11.0.3+1-1
Severity: important
Tags: patch
Hi,
while analyzing piuparts stretch -> buster distupgrade tests, I found
some cases where packages from stretch were not upgraded to the new
version in buster, but the old version was kept installed instead.
This is usually caused by some obsolete packages not getting removed,
because they are part of a package group with a rather high score.
One such problematic group is the old eclipse stack from stretch that
prevents some java packages from being upgraded to buster if it does not
get removed.
I successfully tested that adding
Breaks: eclipse-platform (<< 3.8.1-11)
to openjdk-11-jre fixes these upgrade paths. The old eclipse packages
get removed and everything else gets upgraded as expected.
Andreas
diff -Nru openjdk-11-11.0.3+1/debian/changelog
openjdk-11-11.0.3+1/debian/changelog
--- openjdk-11-11.0.3+1/debian/changelog2019-02-27 15:44:14.0
+0100
+++ openjdk-11-11.0.3+1/debian/changelog2019-03-18 15:01:43.0
+0100
@@ -1,3 +1,10 @@
+openjdk-11 (11.0.3+1-2) UNRELEASED; urgency=medium
+
+ * openjdk-11-jre: Add Breaks: eclipse-platform (<< 3.8.1-11) to smoothen
+upgrades from stretch. (Closes: #xx)
+
+ -- Andreas Beckmann Mon, 18 Mar 2019 15:01:43 +0100
+
openjdk-11 (11.0.3+1-1) unstable; urgency=medium
* OpenJDK 11.0.3+1 build.
diff -Nru openjdk-11-11.0.3+1/debian/control openjdk-11-11.0.3+1/debian/control
--- openjdk-11-11.0.3+1/debian/control 2019-02-10 10:18:49.0 +0100
+++ openjdk-11-11.0.3+1/debian/control 2019-03-18 15:01:43.0 +0100
@@ -92,6 +92,8 @@
${shlibs:Depends}, ${misc:Depends}
Recommends: ${dlopenjre:Recommends}, ${bridge:Recommends}, fonts-dejavu-extra
Suggests: ${pkg:pulseaudio}
+Breaks:
+ eclipse-platform (<< 3.8.1-11),
Provides: java-runtime, java2-runtime,
java5-runtime, java6-runtime,
java7-runtime, java8-runtime,
diff -Nru openjdk-11-11.0.3+1/debian/control.in
openjdk-11-11.0.3+1/debian/control.in
--- openjdk-11-11.0.3+1/debian/control.in 2019-02-10 10:18:46.0
+0100
+++ openjdk-11-11.0.3+1/debian/control.in 2019-03-18 15:01:43.0
+0100
@@ -92,6 +92,8 @@
${shlibs:Depends}, ${misc:Depends}
Recommends: ${dlopenjre:Recommends}, ${bridge:Recommends}, @core_fonts@
Suggests: ${pkg:pulseaudio}
+Breaks:
+ eclipse-platform (<< 3.8.1-11),
Provides: java-runtime, java2-runtime,
java5-runtime, java6-runtime,
java7-runtime, java8-runtime,
eclipse-wtp_None.log.gz
Description: application/gzip
Bug#925074: Updating the ounit Uploaders list
Source: ounit Version: 2.0.8-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint lifong...@gmail.com has not been working on the ounit package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
