Bug#908564: Migration of dwarves-dfsg to samba.d.o
On October 15, 2018 7:58:42 PM UTC, Thomas Girard wrote: >Hello Hi Thomas, >On 10/10/18 6:11 PM, Domenico Andreoli wrote: Sorry for the late reply. I have been quite busy for a while but >now my available bandwidth should be hopefully better. >> >> how is it going? ;) > >I have found my git repo and I am about to create the Salsa repo. You >suggested renaming the repo+source to pahole as per upstream, but >current version RPM remain as dwarves. Shall we go for dwarves or >pahole >then? let's keep dwarves then :) >I will probably create the repo on the debian group (was CollabMaint on > >Alioth) and upload what I have (1.10-2, NMU to reapply). yes, this was also my intention, please go ahead. >Thanks, >Regards, > >Thomas thanks to you! Dom
Bug#911130: Package doesn't actually bump SOVERSION
Package: libtidy5.6 Version: 1:5.6.0-0.1~exp1 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, when symbols in the library change, you need to actually bump the SOVERSION/SONAME of the package. It's not enough and it's wrong to just change the package name for several reasons: 1. The old and new package must declare Conflicts/Replaces among themselves 2. It's impossible to do proper transition (due to 1) 3. It will break non-packaged software So, instead of having libtidy5.6 package that contains libtidy.so.5, you will need to bump the SOVERSION to 6 (it would be best to coordinate with upstream) and the package would be named libtidy6. (The naming convention is lib). I could help with that if you want, but the current approach is wrong, it will break things and it needs to be fixed before transition is started. Thanks, Ondrej - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/6 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libtidy5.6 depends on: ii libc6 2.27-6 libtidy5.6 recommends no packages. libtidy5.6 suggests no packages. -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAlvFeNRfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcIkhA/+IazfDUqK1FeEUMx0gpRiZMc4Wlu6QIz/LsmbLlnvSgB8fE4tcplKYZyP 07w4HyrhRSrouEOeSmdROrbpIqQp1dwC7JFgXyh3JaygSf3uNruVc/DKv8RYkYOB FsgUWhVo2/f0eJ61pW2J0YIEKxmvhBlLB8oXh3G2jrfl5vxjXR+zm6GQmytjGlwX EL2A5PTSCLdPaqH6IAYeO9ehSrVCwhA3T2XLCYCyfUwKP4VlHh3IzCOZRVFDabv7 2KbvUsPWj8Lrno3ELpCVs0yfVVfJYPqn/HbTZJGDAAp1cbPFf/FlSQA75eAL+OMy V2j5DYkNWFxqnMe7odlVJ6/UsUXit7L/Tr4A+WbiFuPZwhMPokEvUuVnKDaPOIHN 3fhxbflVzfaqcwxfH2M1y3dJ4xighh2vN1OUv5zNGZSzdFU0GbubS/orYWISqcaG MEw+EcTQ5JE0s+ppMVDBxXllqokfJ/ohx4iWZBcFxAdsPW2bLGf/W4/fuZjD1lNO EdqWwG6TteDE9TsHnSghmbeMcYQj+ynHxAJ7ByUt85mpLs0/Z0rUJ78tpsZQwvEb Oq4uaTEeBr1APhQeQJv9psIsrU9rHewHxc2+8pvJMRihqUvb13+KLanHBxzb8ktw ibCURP/VR+rG7V64784m+nk/dFtLj0lw9xCq80hbv9vj1sL6RkA= =esEQ -END PGP SIGNATURE-
Bug#911129: RFP: node-faucet -- human-readable TAP summarizer
Package: wnpp Severity: wishlist * Package name: node-faucet Version : 0.0.2 Upstream Author : James Halliday * URL : https://notabug.org/themusicgod1/faucet/ * License : MIT Programming Lang: javascript Description : human-readable TAP summarizer Pipe TAP text into the faucet command, get back pretty results.
Bug#911128: Infinite Loop in Hangman
Package: bsdgames
Version: 2.17-26build1
In the case where the provided dictionary only has a single word, it will
result in an infinite loop, since the second fgets will always return NULL.
Here is a patch for this very severe problem.
*** bsdgames-2.17/hangman/getword.c 2018-10-16 00:38:37.0 -0400
--- bsdgames-2.17_mod/hangman/getword.c 2018-10-16 00:33:45.653529037 -0400
*** getword()
*** 62,63
! if (fgets(Word, BUFSIZ, inf) == NULL)
! continue;
--- 62,67
! if (fgets(Word, BUFSIZ, inf) == NULL) {
! pos = 0;
! fseek(inf,pos,SEEK_SET);
! if (fgets(Word, BUFSIZ, inf) == NULL)
! goto cont;
! }
*** cont:
*** 71
--- 76
+
--
*^KB* SENT FROM WORDSTAR 4.0
*^KK*
Bug#911127: olm FTCBFS: python build dependency not installable
Source: olm Version: 2.2.2+git20170526.0fd768e+dfsg-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap olm fails to cross build from source, because its Build-Depends request the host architecture python and that fails to install. Looking deeper, one sees that python is used in two capacities: Once for running rst2html and also for creating python-olm. The latter is only necessary for indep builds and the former wants the build architecture python. So we can shrink the problem by removing python-olm from the arch-only build. Doing so allows demoting python-all-dev to Build-Depends-Indep, which is irrelevant to cross building. The attached patch implements the moving of Build-Depends. Using diffoscope and reproducible builds I verified that the resulting .debs do not vary accross full builds arch-only builds or indep-only builds. Please close this bug when removing python-all-dev from Build-Depends even though that might not be sufficient for making olm cross buildable. In case of further issues, I shall file further bug reports. Helmut diff --minimal -Nru olm-2.2.2+git20170526.0fd768e+dfsg/debian/changelog olm-2.2.2+git20170526.0fd768e+dfsg/debian/changelog --- olm-2.2.2+git20170526.0fd768e+dfsg/debian/changelog 2017-06-13 01:18:18.0 +0200 +++ olm-2.2.2+git20170526.0fd768e+dfsg/debian/changelog 2018-10-16 05:49:58.0 +0200 @@ -1,3 +1,10 @@ +olm (2.2.2+git20170526.0fd768e+dfsg-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Demote python dependencies to Build-Depends-Indep. (Closes: #-1) + + -- Helmut Grohne Tue, 16 Oct 2018 05:49:58 +0200 + olm (2.2.2+git20170526.0fd768e+dfsg-1) unstable; urgency=medium * Initial release (Closes: #847566) diff --minimal -Nru olm-2.2.2+git20170526.0fd768e+dfsg/debian/control olm-2.2.2+git20170526.0fd768e+dfsg/debian/control --- olm-2.2.2+git20170526.0fd768e+dfsg/debian/control 2017-06-13 01:17:56.0 +0200 +++ olm-2.2.2+git20170526.0fd768e+dfsg/debian/control 2018-10-16 05:49:56.0 +0200 @@ -1,7 +1,8 @@ Source: olm Priority: optional Maintainer: Hubert Chathi -Build-Depends: debhelper (>=9), dh-python, python-all-dev (>= 2.6.6-3~), python-docutils, python-pygments +Build-Depends: debhelper (>=9), python-docutils, python-pygments +Build-Depends-Indep: dh-python, python-all-dev (>= 2.6.6-3~), Standards-Version: 3.9.8 Section: libs Homepage: https://matrix.org/git/olm/ diff --minimal -Nru olm-2.2.2+git20170526.0fd768e+dfsg/debian/rules olm-2.2.2+git20170526.0fd768e+dfsg/debian/rules --- olm-2.2.2+git20170526.0fd768e+dfsg/debian/rules 2017-06-12 20:58:31.0 +0200 +++ olm-2.2.2+git20170526.0fd768e+dfsg/debian/rules 2018-10-16 05:47:37.0 +0200 @@ -14,16 +14,19 @@ #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed %: - dh $@ --with python2 + dh $@ $(DH_ADDONS) +build binary %-indep: DH_ADDONS=--with=python2 override_dh_auto_build: make make doc -override_dh_auto_install: +override_dh_auto_install-arch: dh_auto_install -- PREFIX=/usr mkdir debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH) mv debian/tmp/usr/lib/libolm* debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/ + +override_dh_auto_install-indep: for v in `pyversions -vr`; do \ mkdir -p debian/python-olm/usr/lib/python$$v/dist-packages; \ cp -r python/olm debian/python-olm/usr/lib/python$$v/dist-packages; \
Bug#911109: darkstat: start darkstat does not work (status:start darkstat monitoring system at boot);manuall works"
On Tue, Oct 16, 2018 at 6:24 AM Manfred Braun wrote: > INTERFACE="-i ens18 -p " > PORT="-p 667" > Looks like there's a stray -p in INTERFACE.
Bug#911036: Acknowledgement (partman-lvm: Volume group name "■" has invalid characters, and cannot removed)
Hi, Here's a step to reproduce this bug --- 1. boot from d-i media and start installer 2. create encrypted LVM volume 3. select "go back" and "Change language" to "Japanese" (or other multi-byte locale) 4. select "論理ボリュームマネージャーの設定 (Configure the Logical Volume Manager)" -> "論理ボリュームの削除 (Delete logical volue)" and any volume 5. Got error 6. select "戻る (go back) and "言語の選択/Change language" to "English" 7. select "Configure the Logical Volume Manager" -> "Delete logical volume" and any volume 8. you can delete it without error! -- Hideki Yamane
Bug#911126: nouveau: Black screen after reboot
Package: xserver-xorg-video-nouveau Version: 1:1.0.15-3 Severity: important Dear Maintainer, This deskop system had been up and working fine with the nouveau driver for at least two months, then did an apt update/upgrade and the graphics hung. I then switched to the console and first tried restarting the graphics (/etc/init.d/lightdm restart) and when that didn't help rebooted (which also did not help). If I start lightdm the screen flashes (about a 5 second cycle) between pure black (no light at all) and something that is lit, but show no image. This machine did have the NVidia driver on it at one stage but for the last several months has been running with nouveau. I would really just like the graphics to work. Cheers, Erik -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050] [10de:1c81] (rev a1) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 4 -rw-r--r-- 1 root root 226 Jul 20 01:49 90-xpra-virtual.conf /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 4.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.10-2 (2018-10-07) Xorg X server log files on system: -- -rw-r--r-- 1 root root 63828 May 28 22:07 /var/log/Xorg.1.log -rw-r--r-- 1 root root 50320 Oct 16 13:38 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [84.912] X.Org X Server 1.20.1 X Protocol Version 11, Revision 0 [84.912] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian [84.912] Current Operating System: Linux ada 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-10-07) x86_64 [84.912] Kernel command line: BOOT_IMAGE=/vmlinuz-4.18.0-2-amd64 root=/dev/mapper/dark--vg-root ro quiet [84.912] Build Date: 26 September 2018 10:20:47AM [84.912] xorg-server 2:1.20.1-4 (https://www.debian.org/support) [84.912] Current version of pixman: 0.34.0 [84.912]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [84.912] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [84.912] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Oct 16 13:38:57 2018 [84.912] (==) Using config directory: "/etc/X11/xorg.conf.d" [84.912] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [84.912] (==) No Layout section. Using the first Screen section. [84.912] (==) No screen section available. Using defaults. [84.912] (**) |-->Screen "Default Screen Section" (0) [84.912] (**) | |-->Monitor "" [84.912] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [84.912] (==) Automatically adding devices [84.912] (==) Automatically enabling devices [84.912] (==) Automatically adding GPU devices [84.912] (==) Max clients allowed: 256, resource mask: 0x1f [84.912] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [84.912]Entry deleted from font path. [84.912] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [84.912] (==) ModulePath set to "/usr/lib/xorg/modules" [84.912] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [84.912] (II) Loader magic: 0x55e8b099ce20 [84.912] (II) Module ABI versions: [84.912]X.Org ANSI C Emulation: 0.4 [84.912]X.Org Video Driver: 24.0 [84.912]X.Org XInput driver : 24.1 [84.912]X.Org Server Extension : 10.0 [84.913] (++) using VT number 7 [84.913] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [84.914] (II) xfree86: Adding drm device (/dev/dri/card0) [84.915] (--) PCI:*(1@0:0:0) 10de:1c81:1458:3765 rev 161, Mem @ 0xf600/16777216, 0xe000/268435456, 0xf000/33554432, I/O @ 0xe000/128, BIOS @ 0x/131072 [84.915] (II) LoadModule: "glx" [84.915] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [84.916] (II) Module glx: vendor="X.Org Foundation" [84.916]compiled for 1.20.1, module version = 1.0.0
Bug#700576: cowsay: Pleasy add kangaroo cow :)
tags -1 patch Attached is a kangaroo cow, all ready to be copied to the cows directory. The file author, copyright, and license are given in comments in the header. I am also attaching the email exchange where the creator of the kangaroo gave permission to use that kangaroo (after I flipped it horizontally) with the stated copyright and license terms. Francois, this package has no maintainer right now so if you want to upload this patch please do. The header information in kangaroo.cow could be copied into debian/copyright as well. Have fun! Thanks, Paul Hardy kangaroo.cow Description: Binary data permission.txt.gz.sig Description: PGP signature permission.txt.gz Description: application/gzip kangaroo.cow.sig Description: PGP signature
Bug#907629: librsvg: Embedded code copies: assorted Rust libraries
Hi, you are welcome to package the below dependencies as part of the Rust team. All our packaging is in one repo: https://salsa.debian.org/rust-team/debcargo-conf/ It should be possible to use dh-cargo in librsvg's build, you might have to call it using something like: override_dh_auto_install: # other stuff dh_auto_install -S cargo -D Done this way, it will also omit `cargo test` so you don't have to worry about dev-dependencies. If you want to run those as well then you'll need to package them, and then add: override_dh_auto_test: # other stuff dh_auto_test -S cargo -D -- test Note that without the "test" at the end dh-cargo will only run a *cargo build*, this is by design, see https://salsa.debian.org/rust-team/debcargo/issues/15 for details. Please feel free to ask any other questions. X On Thu, 30 Aug 2018 11:38:09 +0100 Simon McVittie wrote: > Source: librsvg > Version: 2.44.1-1 > Severity: normal > Tags: help > > librsvg contains "vendored" copies of various Rust libraries. Ideally > we would use the vendored copy or the system copy of each library, > whichever is (compatible and) newer, but I don't know enough Rust to > know how to do that (and set the right Built-Using) for a package that > is not built with dh-cargo. > > We can't use dh-cargo because the Rust code here is only part of a larger > package that uses an Autotools build system. > > Some of the vendored libraries are available in Debian, others are not: > > [x] aho-corasick > [ ] alga > [x] ansi_term > [ ] approx > [x] arrayvec > [x] atty > [ ] backtrace > [ ] backtrace-sys (in NEW) > [x] bitflags > [ ] bitflags-0.9.1 > [x] byteorder > [ ] c_vec > [ ] cairo-rs > [ ] cairo-sys-rs > [ ] cast > [x] cc > [ ] cfg-if > [x] chrono > [x] clap > [x] cloudabi > [ ] criterion > [ ] criterion-plot > [ ] criterion-stats > [ ] crossbeam-deque > [x] crossbeam-epoch > [x] crossbeam-utils > [ ] cssparser > [ ] cssparser-macros > [x] csv > [x] csv-core > [ ] downcast-rs > [x] dtoa > [ ] dtoa-short > [x] either > [ ] failure > [x] failure_derive > [ ] float-cmp > [x] fuchsia-zircon > [x] fuchsia-zircon-sys > [x] generic-array > [ ] glib > [ ] glib-sys > [ ] gobject-sys > [ ] handlebars -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#911125: lmfit-py: please make the build reproducible
Chris Lamb wrote: > This is because the tests generate an unreproducible modelresult_1.sav > file that ends up in /usr/lib/python3/dist-packages >From Lintian 2.5.109 this will be be warned out via the "unknown-file- in-python-module-directory" tag: https://salsa.debian.org/lintian/lintian/commit/b76a4797ae5ccdeff4bca582af1ec8566e592feb Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#911125: lmfit-py: please make the build reproducible
Source: lmfit-py Version: 0.9.11+dfsg-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that lmfit-py could not be built reproducibly. This is because the tests generate an unreproducible modelresult_1.sav file that ends up in /usr/lib/python3/dist-packages. You have a debian/ python3-lmfit.remove file (not seen these before as it happens…) but it appears to reference "python3.7" instead of "python3". Untested patch attached but I'm sure you get the idea. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff --git a/debian/python3-lmfit.remove b/debian/python3-lmfit.remove index 0ba55b6..0486ac3 100644 --- a/debian/python3-lmfit.remove +++ b/debian/python3-lmfit.remove @@ -1 +1 @@ -python3.7/dist-packages/modelresult_1.sav +python3/dist-packages/modelresult_1.sav
Bug#911124: RFP: node-has-symbols -- Determine if the JS environment has Symbol support
Package: wnpp Severity: wishlist * Package name: node-has-symbols Version : 1.0.0 Upstream Author : Jordan Harband ( @ljh...@twitter.com ) * URL : https://notabug.org/themusicgod1/has-symbols * License : MIT Programming Lang: javascript Description : Determine if the JS environment has Symbol support Two functions (hasSymbols, hasNativeSymbols) for determining symbol support. Supports node-get-own-property-symbols, node-core-js Is a prerequisite of node-object.assign among other things.
Bug#881748: crash on startup
Well I guess we can scratch my previous statement now. 4:18.08.1-1 just dropped in testing, I tried it, and it started first time with no problem. So whatever problem got introduced for me in the previous version must've been fixed with this one.
Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Simon McVittie wrote: > The wontfix tag was because upstream are not willing to add pkg-config > metadata It was. Now, it has been changed. In the next version of libgpg-error (1.33), we will offer gpg-error.pc (if nothing is going wrong). I believe this change helps cross-compiling other packages with libgpg-error. IIUC, Debian offers its (special) script named pkg-config-crosswrapper, then, users can use -pkg-config command generated by pkg-config-dpkghook. Currently, in our development version (to be 1.33), gpg-error-config script itself is not architecture independent (having architecture dependent string), because it needs to find the gpg-error.pc file in architecture dependent path, just like pkg-config does. I'm not sure if it's worth to have -gpg-error-config command, when we have gpg-error.pc. Nevertheless, I think that it is possible to improve gpg-error-config script to detect architecture dependent path dynamically... to be Debian friendly (possibly), so that Debian can offer -gpg-error-config command. --
Bug#910770: dash: systemd-detect-virt fails to detect virtualized environment when run under dash
On Wed, Oct 10, 2018 at 7:50 PM Michael Biebl wrote: > Am 11.10.18 um 03:53 schrieb Jonathan Nieder: > Fwiw, I can't reproduce > > ... > > This is on stretch. > Works as expected on stretch. Both moving parts - both systemd (215 -> 232) & dash (0.5.7 -> 0.5.8) - are at different versions on Jessie vs Stretch.
Bug#903698: sphinxbase: build appears broken for multiple python3 versions
Samuel Thibault, le ven. 12 oct. 2018 04:12:08 +0200, a ecrit: > I'm thinking... My chroots have a lib -> usr/lib symlink. Could it be > that python somehow gets lost between /lib/python* and /usr/lib/python*, > and dependending on e.g. inode number or directory order, we could have > one way or the other? > > Right now I have two VMs with almost the same chroot (differences > notably lie in .pyc files), one works, the other doesn't. When I mount > the chroot of one on the other, the chroot behavior holds (i.e. the > failing chroot keeps failing on the VM which produced a working chroot). This is driving me crazy :) I have uploaded the VM images on https://people.debian.org/~sthibault/tmp/fails.img.gz https://people.debian.org/~sthibault/tmp/works.img.gz Booting one or the other does not matter. What does matter is the disk image used to store the chroot. Each VM image has its own /var/cache/pbuilder/sphinxbase-build directory (almost exactly the same), and it does not matter which of the two I copy, if I copy it inside the fails.img disk I'm getting the lintian issue, and if it's inside the works.img disk I'm not getting it (there's a fresh checkout of sphinbase in /tmp/sphinxbase inside the chroots). And of course my own main system is in the fails case, thus preventing me from building the package :) tune2fsk does not show any difference between the two filesystem options, just creation time, mount count & such. Any other idea of what could be different between the two filesystems? Samuel
Bug#911123: Fixed in upstream
This has now been fixed in upstream [1], and will be in the next release (which will be the one after 5.13.0). [1] https://github.com/jeremyevans/sequel/commit/0e9e0a
Bug#904248: Beginnings of a patch to add netbase to build-essential
On Tue, Oct 16, 2018 at 12:01:35AM +0100, Ian Jackson wrote:
> Josh Triplett writes ("Bug#904248: Beginnings of a patch to add netbase to
> build-essential"):
> > On Mon, 15 Oct 2018 13:39:32 +0100 Ian Jackson
> > wrote:
> > > My proposed wording about "longstanding and conventionally available
> > > service and protocol names and numbers" says that if the admin has
> > > modified the file they need to make sure their modified version isn't
> > > toally borked.
> >
> > Which effectively means the admin should never delete any existing entry
> > in the file, only add their own.
>
> It's a config file. If you make semantically unwise changes to a
> config file you get to keep all the remaining pieces. I'm not sure
> why that is controversial ?
The baseline information is fundamentally not configurable. It's not a
config file, it's a data file. (I think one of the only arguments for
having it in /etc at all is needing to have it on / rather than /usr,
and that no longer applies.)
> > It doesn't seem reasonable for a package to require a particular entry
> > in a conffile in order to build. Packages should contain that
> > information themselves.
>
> Looking up protocols and services entries at build time was once
> regarded as good practice.
Yes. Once.
> And there is nothing particularly wrong
> with it.
It makes your package build depend on an external, *configurable* file,
rather than having a service responsible for foo know that foo typically
lives on port 1234. Why is that a feature rather than a bug?
> > Much like /usr/share/misc/pci.ids and other such databases that record
> > the state of the real world and standards committees, editing these
> > files at all seems questionable. Suppose, hypothetically, that these
> > files all moved to /usr/share/misc/ , and then libnss_files.so learned
> > to read both /etc/$file and /usr/share/misc/$file , with the former not
> > existing by default? (We could also switch to a faster lookup mechanism,
> > but let's not change too many things simultaneously.)
>
> This is all a lovely hypothetical world.
This is not hard to patch, if there's an inclination to do so. I'd be
happy to write such patches myself.
> > (This is separate from the problem that netbase should *still* not be
> > build-essential, as several have said on this thread. Personally, I'm
> > leaning increasingly in the direction of "even an explicit build-depends
> > on netbase should be treated as a sign of a bug in the package".)
>
> You don't seem to be addressing the same situation as I am at all.
Quite possibly. The situation I'm trying to address is "let's make
packages more robust, and have less essential/build-essential packages".
At the very *least* I don't think it's unreasonable to ask packages that
need netbase to build-depend on it.
> And you don't have any answer to gregor herrmann's point that these
> failures are not uncommon.
Many types of bugs are not uncommon.
> I don't understand what the huge objection
> is to this pretty harmless package.
A pretty harmless package here, a pretty harmless package there...
Bug#910911: Could there be any databases built by Debian which might be affected.
Dear all, While upgrading my system, I came across this bug (shared by apt-listbugs) . I wonder if there are any gdbm databases which are built and have that database. The one example that was shared by6 Niko was of libmarc-charset-perl an optional component. Maybe some core packges might be affected though ? Also how do I recognize which files or package are vulnerable to this change ? -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#898297: ufraw/ufraw-batch: segfault during ufraw_close (program shutdown)
Package: ufraw Version: 0.22-3 Followup-For: Bug #898297 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu cosmic ubuntu-patch *** /tmp/tmp3CJ0Wh/bug_body In Ubuntu I had to add checks to both ld_modifier_destroy calls. It fixes the segfault on exit. -- System Information: Debian Release: buster/sid APT prefers bionic-updates APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic'), (100, 'bionic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-34-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru ufraw-0.22/debian/patches/05_lensfun_destroy_cleanup.patch ufraw-0.22/debian/patches/05_lensfun_destroy_cleanup.patch --- ufraw-0.22/debian/patches/05_lensfun_destroy_cleanup.patch 1969-12-31 21:00:00.0 -0300 +++ ufraw-0.22/debian/patches/05_lensfun_destroy_cleanup.patch 2018-10-15 19:43:41.0 -0300 @@ -0,0 +1,20 @@ +Fix cleanup of lensfun, as suggested in + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898297 +Index: ufraw-0.22/ufraw_ufraw.c +=== +--- ufraw-0.22.orig/ufraw_ufraw.c ufraw-0.22/ufraw_ufraw.c +@@ -767,8 +767,10 @@ void ufraw_close(ufraw_data *uf) + g_free(uf->displayProfile); + g_free(uf->RawHistogram); + #ifdef HAVE_LENSFUN +-lf_modifier_destroy(uf->TCAmodifier); +-lf_modifier_destroy(uf->modifier); ++if (uf->TCAmodifier != NULL) ++lf_modifier_destroy(uf->TCAmodifier); ++if (uf->modifier != NULL) ++lf_modifier_destroy(uf->modifier); + #endif + ufobject_delete(uf->conf->ufobject); + g_free(uf->conf); diff -Nru ufraw-0.22/debian/patches/series ufraw-0.22/debian/patches/series --- ufraw-0.22/debian/patches/series2017-10-20 22:37:33.0 -0300 +++ ufraw-0.22/debian/patches/series2018-10-15 19:44:42.0 -0300 @@ -2,3 +2,4 @@ 02_CVE-2015-8366.patch 03_fix-unsigned-char.patch 04_fix-abs-gcc-7.patch +05_lensfun_destroy_cleanup.patch
Bug#823860: bcache-tools: bcache does not work with suspend
Package: bcache-tools
Version: 1.0.8-2
Tags: patch
Please find attached bc-debdiff.
It's basically smoser's proposed patch but with a proper systemd service
instead of dropping scripts in places intended for local use only. Also
added a 1-second delay before and after suspend because my laptop still
seemed to have issues with suspend which stopped after I added the delays.
diff -Nru bcache-tools-1.0.8/debian/bcache-tools.dirs
bcache-tools-1.0.8/debian/bcache-tools.dirs
--- bcache-tools-1.0.8/debian/bcache-tools.dirs 2015-06-10 03:18:50.0
-1000
+++ bcache-tools-1.0.8/debian/bcache-tools.dirs 2018-10-13 19:38:53.0
-1000
@@ -1,4 +1,6 @@
usr/sbin/
lib/udev/rules.d/
+lib/systemd/system/
usr/share/man/man8/
usr/share/initramfs-tools/hooks/
+
diff -Nru bcache-tools-1.0.8/debian/changelog
bcache-tools-1.0.8/debian/changelog
--- bcache-tools-1.0.8/debian/changelog 2015-06-26 04:25:47.0 -1000
+++ bcache-tools-1.0.8/debian/changelog 2018-10-15 12:02:41.0 -1000
@@ -1,3 +1,16 @@
+bcache-tools (1.0.8-2vppa3) UNRELEASED; urgency=medium
+
+ * debian/patches/0003-Fix-suspend-systemd.patch: Handle suspend/resume
+in systemd using recommended interface.
+Based on smoser's proposed fix but using a proper service instead of
+dropping scripts in places intended for local use.
+(Debian bug #823860)
+ * debian/rules: Enable systemd service for suspend/resume.
+ * debian/control: Add dh-systemd to Build-Depends.
+ * debian/bcache-tools.dirs: Add /lib/systemd/system/
+
+ -- nbpwrsav Mon, 15 Oct 2018 12:02:41 -1000
+
bcache-tools (1.0.8-2) unstable; urgency=medium
* Only run update-initramfs if installed. Fix dracut. (Closes: #788442)
diff -Nru bcache-tools-1.0.8/debian/control bcache-tools-1.0.8/debian/control
--- bcache-tools-1.0.8/debian/control 2015-06-10 03:18:50.0 -1000
+++ bcache-tools-1.0.8/debian/control 2018-10-15 12:02:41.0 -1000
@@ -4,7 +4,7 @@
Section: utils
Priority: optional
Standards-Version: 3.9.5
-Build-Depends: debhelper (>= 9), pkg-config, uuid-dev, libblkid-dev
+Build-Depends: debhelper (>= 9), dh-systemd, pkg-config, uuid-dev, libblkid-dev
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/bcache-tools.git
Vcs-Git: git://anonscm.debian.org/collab-maint/bcache-tools.git
Homepage: http://bcache.evilpiepirate.org/
diff -Nru bcache-tools-1.0.8/debian/patches/0003-Fix-suspend-systemd.patch
bcache-tools-1.0.8/debian/patches/0003-Fix-suspend-systemd.patch
--- bcache-tools-1.0.8/debian/patches/0003-Fix-suspend-systemd.patch
1969-12-31 14:00:00.0 -1000
+++ bcache-tools-1.0.8/debian/patches/0003-Fix-suspend-systemd.patch
2018-10-11 17:58:41.0 -1000
@@ -0,0 +1,125 @@
+## Description: add some description
+## Origin/Author: add some origin or author
+## Bug: bug URL
+Index: bcache-tools-1.0.8/Makefile
+===
+--- bcache-tools-1.0.8.orig/Makefile
bcache-tools-1.0.8/Makefile
+@@ -2,6 +2,7 @@
+ PREFIX=/usr
+ UDEVLIBDIR=/lib/udev
+ DRACUTLIBDIR=/lib/dracut
++SYSDDIR=/lib/systemd/system
+ INSTALL=install
+ CFLAGS+=-O2 -Wall -g
+
+@@ -9,12 +10,16 @@ all: make-bcache probe-bcache bcache-sup
+
+ install: make-bcache probe-bcache bcache-super-show
+ $(INSTALL) -m0755 make-bcache bcache-super-show
$(DESTDIR)${PREFIX}/sbin/
++ $(INSTALL) -m0755 bcache-suspend.sh
$(DESTDIR)${PREFIX}/sbin/bcache-suspend.sh
+ $(INSTALL) -m0755 probe-bcache bcache-register
$(DESTDIR)$(UDEVLIBDIR)/
+ $(INSTALL) -m0644 69-bcache.rules $(DESTDIR)$(UDEVLIBDIR)/rules.d/
+ $(INSTALL) -m0644 -- *.8 $(DESTDIR)${PREFIX}/share/man/man8/
+ $(INSTALL) -D -m0755 initramfs/hook
$(DESTDIR)/usr/share/initramfs-tools/hooks/bcache
+ $(INSTALL) -D -m0755 initcpio/install
$(DESTDIR)/usr/lib/initcpio/install/bcache
+ $(INSTALL) -D -m0755 dracut/module-setup.sh
$(DESTDIR)$(DRACUTLIBDIR)/modules.d/90bcache/module-setup.sh
++ifneq ($(BCACHE_NO_SYSTEMD),1)
++ $(INSTALL) -D -m0644 bcache-suspend.service
$(DESTDIR)$(SYSDDIR)/bcache-suspend.service
++endif
+ # $(INSTALL) -m0755 bcache-test $(DESTDIR)${PREFIX}/sbin/
+
+ clean:
+Index: bcache-tools-1.0.8/bcache-suspend.service
+===
+--- /dev/null
bcache-tools-1.0.8/bcache-suspend.service
+@@ -0,0 +1,17 @@
++# bcache - systemd suspend/resume service
++# Handle suspend/resume (fixes Debian bug 823860 and Ubuntu bug 1515780)
++# https://bugs.launchpad.net/debian/+source/bcache-tools/+bug/1515780
++
++[Unit]
++Description=bcache suspend/resume
++Before=sleep.target
++StopWhenUnneeded=yes
++
++[Service]
++Type=oneshot
++RemainAfterExit=yes
++ExecStart=/usr/sbin/bcache-suspend.sh suspend
++ExecStop=/usr/sbin/bcache-suspend.sh resume
++
++[Install]
++WantedBy=sleep.target
+Index: bcache-tools-1.0.8/bcache-suspend.sh
+===
+---
Bug#911120: espeakup fails to install
Please always keep the bug in Cc, so that I am not the only recipient of the mail. Writing to me only means risking falling in the middle of my vacations and thus not getting an answer for weeks, or that I just don't have the time to answer and thus you would at best get a terse answer, or worse, no answer at all... Conversely, keeping the bug in Cc means avoiding all these issues completely, you'll involve all the community to help you, make the answers you get available to everyone, and even archived for web crawlers to find them whenever somebody has the same issue. Keith Barrett, le lun. 15 oct. 2018 23:34:16 +0100, a ecrit: > > I.e. just run modprobe speakup_soft before this. > Right, no joy, unfortunately. > > sudo modprobe speakup_soft > No error message. [...] > espeakup -d > Unable to open the softsynth device no such file or directory Does /dev/softsynth exist after that? If not, what does dmesg tell? Samuel
Bug#911120: espeakup fails to install
On 15/10/18 22:02, Samuel Thibault wrote:
Hello,
Keith Barrett, le dim. 14 oct. 2018 16:50:08 +0100, a ecrit:
I removed the package with a view to reinstalling but
invoke-rc.d: initscript espeakup, action "start" failed.
Mmm, perhaps you just need to have the speakup_soft module loaded?
I.e. just run modprobe speakup_soft before this.
Right, no joy, unfortunately.
sudo modprobe speakup_soft
No error message.
sudo apt-get install espeakup
Reading package lists...
Building dependency tree...
Reading state information...
espeakup is already the newest version (1:0.80-10).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Setting up espeakup (1:0.80-10) ...
update-rc.d: warning: start and stop actions are no longer supported;
falling back to defaults
Job for espeakup.service failed because the control process exited with
error code.
See "systemctl status espeakup.service" and "journalctl -xe" for details.
invoke-rc.d: initscript espeakup, action "start" failed.
● espeakup.service - Software speech output for Speakup
Loaded: loaded
(#]8;;file://debian/lib/systemd/system/espeakup.service#/lib/systemd/system/espeakup.service#]8;;#;
enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Mon
2018-10-15 23:15:52 BST; 17ms ago
Docs: #]8;;man:espeakup(8)#man:espeakup(8)#]8;;#
Process: 3089 ExecStart=/usr/bin/espeakup -V ${VOICE}
#[0;1;31m(code=exited, status=2)#[0m
dpkg: error processing package espeakup (--configure):
installed espeakup package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
espeakup
E: Sub-process /usr/bin/dpkg returned an error code (1)
espeakup -d
Unable to open the softsynth device no such file or directory
I'll make espeakup to just load the module itself to avoid that issue.
If that's not the issue, you can try to run espeakup by hand to see
which error shows up:
espeakup -d
Samuel
Bug#911045: xenstore-utils: removal of xenstore-utils makes files disappear from xen-utils-common
Ian Jackson writes ("Re: xenstore-utils: removal of xenstore-utils makes files
disappear from xen-utils-common"):
> > The installation sequence to reproduce this problem is
> >
> > apt-get install xen-utils-common/stretch
> > # (1)
> > apt-get install xenstore-utils/sid
> > apt-get remove xenstore-utils
> > # (2)
>
> But this is not possible because xen-utils-common Depends on
> xenstore-utils (even in stretch). You could in theory upgrade only
> xenstore-utils and then downgrade it again, to make the files
> disappear, but I don't think that is supported. And in practice
> no-one would do that.
>
> So I don't think this is a bug we care about.
Indeed I looked at the log and it does show a downgrade, not a
removal, of xenstore-utils.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#911045: xenstore-utils: removal of xenstore-utils makes files disappear from xen-utils-common
> The installation sequence to reproduce this problem is > > apt-get install xen-utils-common/stretch > # (1) > apt-get install xenstore-utils/sid > apt-get remove xenstore-utils > # (2) But this is not possible because xen-utils-common Depends on xenstore-utils (even in stretch). You could in theory upgrade only xenstore-utils and then downgrade it again, to make the files disappear, but I don't think that is supported. And in practice no-one would do that. So I don't think this is a bug we care about. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#909805: About bug 308382: kernel 4.18 fails to boot on my system
Hi Andrey, could you check if the circumstances of bug 908382 also apply to you? It seems very similar, particularly if your system also has more than 4G memory. It could be the same bug. Regards Jiri Palecek
Bug#908382: Update on kernel bug: kernel 4.18 fails to boot
Hello, just for an update on this bug, I finally did the bisecting and found the first offending commit is this: commit 21e07dba9fb1179148089d611fc9e6e70d1887c3 (HEAD, refs/bisect/bad) Author: Christoph Hellwig Date: Tue Apr 3 19:09:59 2018 +0200 scsi: reduce use of block bounce buffers We can rely on the dma-mapping code to handle any DMA limits that is bigger than the ISA DMA mask for us (either using an iommu or swiotlb), so remove setting the block layer bounce limit for anything but the unchecked_isa_dma case, or the bouncing for highmem pages. Signed-off-by: Christoph Hellwig Reviewed-by: Jens Axboe Apparently the system with 5G memory needs bounce buffers after all, and without iommu, the swiotlb thingy didn't quite make it. Init then crashes after unsuccessful read of the disk. Regards Jiri Palecek
Bug#904248: Beginnings of a patch to add netbase to build-essential
Josh Triplett writes ("Bug#904248: Beginnings of a patch to add netbase to
build-essential"):
> On Mon, 15 Oct 2018 13:39:32 +0100 Ian Jackson
> wrote:
> > My proposed wording about "longstanding and conventionally available
> > service and protocol names and numbers" says that if the admin has
> > modified the file they need to make sure their modified version isn't
> > toally borked.
>
> Which effectively means the admin should never delete any existing entry
> in the file, only add their own.
It's a config file. If you make semantically unwise changes to a
config file you get to keep all the remaining pieces. I'm not sure
why that is controversial ?
> It doesn't seem reasonable for a package to require a particular entry
> in a conffile in order to build. Packages should contain that
> information themselves.
Looking up protocols and services entries at build time was once
regarded as good practice. And there is nothing particularly wrong
with it.
> Much like /usr/share/misc/pci.ids and other such databases that record
> the state of the real world and standards committees, editing these
> files at all seems questionable. Suppose, hypothetically, that these
> files all moved to /usr/share/misc/ , and then libnss_files.so learned
> to read both /etc/$file and /usr/share/misc/$file , with the former not
> existing by default? (We could also switch to a faster lookup mechanism,
> but let's not change too many things simultaneously.)
This is all a lovely hypothetical world.
> (This is separate from the problem that netbase should *still* not be
> build-essential, as several have said on this thread. Personally, I'm
> leaning increasingly in the direction of "even an explicit build-depends
> on netbase should be treated as a sign of a bug in the package".)
You don't seem to be addressing the same situation as I am at all.
And you don't have any answer to gregor herrmann's point that these
failures are not uncommon. I don't understand what the huge objection
is to this pretty harmless package.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#776413: The status of ed
Lev Lamberov wrote: > Dear FTP Masters, > > I'd like to request your input on #776413. It is concerned with the > priority of the ed package. I am not speaking «ex cathedra» here as an FTP master but this may be more suitable to raise with the Policy team. At the very least IIRC they offered helpful advice that led to a similar resolutions recently. Or that may have been on archive sections, alas I cannot recall right now. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#911056: chromium,webext-browserpass: impossible to install chromium and webext-browserpass together
Unless chromium changed the places it looks for some files, I guess this is an oversight in chromium and thus be fixed there. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#911123: ruby-sequel: PG adapter does not support `service` parameter keyword
Package: ruby-sequel
Version: 4.37.0-1
Severity: normal
Forwarded: https://github.com/jeremyevans/sequel/issues/1558
tags -1 + found 5.6.0-1
thanks
Dear Maintainer,
Sequel's pg adapter [1] does not support the libpq service parameter keyword
[2].
It fully ignores a connection defined in the connection service file [3].
Tested were:
Sequel.connect('postgresql://?service=test')
Sequel.postgres('postgresql://?service=test')
Sequel.connect('postgresql://', driver_options: { service: 'test' })
Sequel.connect(adapter: 'postgres', driver_options: { service: 'test' })
Sequel.postgres(adapter: 'postgres', driver_options: { service: 'test' })
Here Sequel does not connect to a (remote) `test` service connection defined in
`~/.pg_service.conf` but tries localhost:
PG::ConnectionBad: could not connect to server: No such file or directory
# or
PG::ConnectionBad: FATAL: role "www-data" does not exist
The issue was reported upstream.
[1]
https://github.com/jeremyevans/sequel/blob/8b6f117ff47ff8c28f0b952cc20a07300b9f2ecb/lib/sequel/adapters/postgres.rb#L196-L203
[2]
https://www.postgresql.org/docs/10/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS
[3] https://www.postgresql.org/docs/current/static/libpq-pgservice.html
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages ruby-sequel depends on:
ii ruby 1:2.3.3
ii ruby-json 2.0.1+dfsg-3
Versions of packages ruby-sequel recommends:
ii ruby-sequel-pg 1.6.16-1
ruby-sequel suggests no packages.
-- no debconf information
Bug#909658: debian-installer: blank screen on install (HP Elitebook 830 G5)
control: merge 899240 -1 control: severity -1 serious Hi, I've updated to newest BIOS 1.04 (Oct 11th version) and then change UEFI setting with enable legacy boot (CSM) and d-i works. (I guess old HP Elitebook 830 G5 BIOS doesn't work well). I'll rise its severity since it seems to be common issue on new hardware, and unfortunately some hardware doesn't support CSM. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#911122: RFS: vitetris/0.57.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "vitetris" Package name: vitetris Version : 0.57.2-2 Upstream Author : Victor Geraldsson URL : http://www.victornils.net/tetris/ License : BSD-2-Clause Section : games It builds those binary packages: vitetris - Virtual terminal *tris clone To access further information about this package, please visit the following URL: https://mentors.debian.net/package/vitetris Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/v/vitetris/vitetris_0.57.2-2.dsc More information about vitetris can be obtained from http://www.victornils.net/tetris/. Source repository: https://salsa.debian.org/lyknode-guest/vitetris Changes since the last upload: * Rename binary to vitetris (Closes: #911053) * Rename manpage to vitetris * Fix desktop entry * Fix implicit declaration on netplay.c * Add source README to package Regards, Baptiste BEAUPLAT - lyknode -BEGIN PGP SIGNATURE- iIcEARYIAC8WIQQt4kiVMTxdp/CJ4U4XSUsQeV3XMwUCW8UOWhEcbHlrbm9kZUBj aWxnLm9yZwAKCRAXSUsQeV3XM15RAQDxYpGr3reuTnEps4u+KW7i5lx/nGSFzydL jhvsdv5tUAD/dA7PSHNJ7/Cxptt1THKJM/24xYfEXOVwc5fDPf2jyQg= =eJbE -END PGP SIGNATURE-
Bug#911118: I think I've fixed it...
I must have overlooked one setting in Samba when I was trying to eliminate its configuration as a source for this issue: strict allocate = yes This seems to be what caused the problem. Sorry for the falsely attributed bug report, but maybe it's interesting information - I still think it's weird that this only caused an issue with FUSE/MHDDFS, not the other share I was using.
Bug#911121: Please compile with CONFIG_SND_BCM2835=m
Package: src:linux Version: 4.18.10-2 Severity: wishlist Hi! I'm currently running this kernel on Raspberry Pi 3b without much trouble, however no sound devices are found, After reading and looking at raspbian modules, it seems that sound is handled by this module, so if you would please enable it with a little luck we'll have sound working on Pi 3b on standard buster. Thanks in advance. -- Package-specific info: ** Version: Linux version 4.18.0-2-arm64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.10-2 (2018-10-07) ** Command line: bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 dma.dmachans=0x7f35 bcm2709.boardrev=0xa02082 bcm2709.serial=0xff0fa6ff bcm2709.uart_clock=4800 smsc95xx.macaddr=B8:27:EB:0F:A6:FF vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 console=ttyS1,115200 root=/dev/md1 rw elevator=deadline fsck.repair=yes net.ifnames=0 cma=64M rootwait ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information Device Tree model: Raspberry Pi 3 Model B Rev 1.2 ** Loaded modules: nf_log_ipv4 nf_log_common xt_LOG xt_pkttype xt_limit ipt_REJECT nf_reject_ipv4 xt_owner xt_conntrack iptable_filter ipt_MASQUERADE xt_REDIRECT xt_nat xt_tcpudp xt_addrtype iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_connmark nf_conntrack xt_mark iptable_mangle bridge stp llc vc4 snd_soc_core nls_ascii nls_cp437 snd_pcm_dmaengine vfat fat snd_pcm brcmfmac snd_timer snd soundcore cec brcmutil drm_kms_helper cfg80211 drm asix sg bcm2835_rng rng_core smsc95xx libphy bcm2835_thermal leds_gpio usbnet mii rfkill pwm_bcm2835 bcm2835_wdt ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto ecb aes_arm64 sd_mod raid10 uas raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx usb_storage xor scsi_mod raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod dwc2 udc_core usbcore sdhci_iproc sdhci_pltfm usb_common sdhci bcm2835 phy_generic ** PCI devices: not available ** USB devices: Bus 001 Device 006: ID 0bc2:2322 Seagate RSS LLC Bus 001 Device 005: ID 0b95:772b ASIX Electronics Corp. AX88772B Bus 001 Device 004: ID 0939:0b15 Lumberg, Inc. Toshiba Stor.E Alu 2 Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: arm64 (aarch64) Kernel: Linux 4.18.0-2-arm64 (SMP w/4 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE=gl_ES.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 linux-image-4.18.0-2-arm64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.132 ii kmod25-1 ii linux-base 4.5 Versions of packages linux-image-4.18.0-2-arm64 recommends: ii apparmor 2.13-8 ii firmware-linux-free 3.4 ii irqbalance 1.3.0-0.1+b1 Versions of packages linux-image-4.18.0-2-arm64 suggests: pn debian-kernel-handbook pn linux-doc-4.18 Versions of packages linux-image-4.18.0-2-arm64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x ii firmware-brcm8021120180825+dfsg-1 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-realtek 20180825+dfsg-1 pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#911120: espeakup: Does not fully install
Package: espeakup Version: 1:0.80-10 Severity: grave Tags: a11y Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Frequent loss of speech in the console, particularly when switching to another console or from the desktop. * What exactly did you do (or not do) that was effective (or ineffective)? Removed the package with a view to reinstalling. * What was the outcome of this action? Package failed to install * What outcome did you expect instead? Package to fully install and work. *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.18.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages espeakup depends on: ii espeak 1.48.04+dfsg-6 ii libc6 2.27-6 ii libespeak-ng1 1.49.2+dfsg-4 ii lsb-base 9.20170808 espeakup recommends no packages. espeakup suggests no packages. -- no debconf information
Bug#911087: schroot: --preserve-environment does not preserve env vars set to ""
On 15/10/18 19:43, Peter Maydell wrote: Roger Leigh wrote: Please see https://gitlab.com/codelibre/schroot/merge_requests/38 for a patch containing the fixes. This looks like an oversight/mis-design which is corrected by this merge request to make the behaviour consistent for all environment handling methods. Wow, thanks for the incredibly fast response -- I appreciate it. No problem! Note that I've tweaked that change slightly. I added GitLab CI support to test a range of distributions and found that the 1.6 backport needed a couple of additional tweaks, which I've now made, tested and merged as https://gitlab.com/codelibre/schroot/merge_requests/39. Regards, Roger
Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Wed, 25 Jul 2018 at 21:59:55 +0100, Simon McVittie wrote: > While looking at this bug as a result of a package I maintain (ostree) > gaining a direct dependency on libgpg-error, it occurred to me that for > the special case of Debian, there's no reason why the -config script > needs to know about @libdir@ at all: passing -L/usr/lib/x86_64-linux-gnu > to the linker is unnecessary, because that's in our version of gcc's > search path anyway. > > This is probably the only reason why it's possible to cross-compile > packages that depend on libgpg-error, in fact. > > gpg-error-config does include another architecture-dependent string, > which is its response to the --host command-line argument. However, > that command-line argument is undocumented, and only seems to be used > by gpg-error.m4 (and its clone gpgrt.m4), which copes gracefully if > it's rejected: a gpg-error-config for which --host fails is treated > as potentially being from any architecture. > > So perhaps [1] would be suitable? It seems to work. I see there has been an upload of libgpg-error recently. Would you mind reconsidering whether the wontfix tag on this bug is appropriate? The wontfix tag was because upstream are not willing to add pkg-config metadata (which I personally think would have been a better solution, but they get to choose how their compile-time interfaces work), but the patches I suggested in [1] don't actually require that. Thanks, smcv [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643341#88
Bug#911119: pybigwig: Should list python3-all as an explicit test dependency
Package: pybigwig Version: 0.3.11-1 Severity: minor Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu cosmic ubuntu-patch Hi Diane, With a recent upload of python-numpy in Ubuntu, the pybigwig autopkgtests have started to fail: autopkgtest [18:55:33]: test command2: [--- bash: python3.7: command not found autopkgtest [18:55:34]: test command2: ---] autopkgtest [18:55:34]: test command2: - - - - - - - - - - results - - - - - - - - - - command2 FAIL non-zero exit status 127 (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/p/pybigwig/20181015_185543_80f75@/log.gz) The reason for this is that pybigwig runs its test suite for all python versions in the output of py3versions -r, but does not depend on python3-all, so not all python3 versions are guaranteed to be installed; and python3.7 is supported currently as a non-default python version in Ubuntu; and the latest upload of python-numpy specifically drops the dependency on python3.7, so that it does not force non-default python3 versions to be installed in order to use python-numpy. The net result is that this autopkgtest failure may still be currently masked in Debian for a number of reasons, but it would still be more correct for pybigwig to declare an explicit test dependency on python3-all. With this change, the autopkgtest passes locally for me on Ubuntu cosmic. Thanks for considering, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru pybigwig-0.3.11/debian/tests/control pybigwig-0.3.11/debian/tests/control --- pybigwig-0.3.11/debian/tests/control2018-07-03 14:50:07.0 -0700 +++ pybigwig-0.3.11/debian/tests/control2018-10-15 13:56:43.0 -0700 @@ -12,4 +12,4 @@ ; $py test.py ; cd .. ; done -Depends: python3-pybigwig +Depends: python3-pybigwig, python3-all
Bug#907829: p4est: FTBFS on single CPU machines (?)
Adrian Bunk wrote: > You are being a complete asshole when you are trying to use RC bugs for > forcing other people to spend any time *ever* on your pet project. Whatever the technical merits here, calling a colleague an "asshole" in any context is completely inappropriate and moreover behaviour unbecoming of a Debian Developer. Adrian, I cordially invite you to withdraw your statement. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#893448: please add a chromium-source binary package
On Mon, Oct 15, 2018 at 10:41:25PM +0200, Steinar H. Gunderson wrote: > On Mon, Oct 15, 2018 at 10:33:11PM +0200, Moritz Muehlenhoff wrote: > > Ultimately this is up for Michael to decide, as he's dealing with Chromium > > updates single-handedly. > > Agreed. > > > Personally I have no reservations against this entering unstable, but this > > doesn't sound > > like something that should enter a stable release. If the Chrome > > development team with > > it's hundreds of full time developers can't/wont commit to a stable > > interface for these > > kinds of extensions, why should we kludge around this with our sparse > > resources? > > I guess the answer is because software wants it. :-) > > CEF exists precisely to be an API-stable interface for this; it's unfortunate > that Chrome doesn't care enough, but CEF is meant to be that layer, and seems > to be doing pretty well (judging by the amount of software that uses it). But our current infrastructure for security.debian.org doesn't scale for this kind of API whack-a-mole. Any update to unbreak CEF after Chromium major releases would need to go through the security team and sucks up our time which is more usefully spend elsewhere. Realistically, to make this would we'd need $SOMEONE to implement #817285, if that were in place we could simply push an ACL change and enable you take care of CEF updates in buster-security on your own. Cheers, Moritz
Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
Hello, again, thanks a lot to dkg for your hard work to bring Enigmail 2.0 to Stretch! Once again it's amazing to follow your work and see how thorough you are :) On Sun, 14 Oct 2018 18:58:33 -0400 Daniel Kahn Gillmor wrote: > Hi release team, security team: > > over in #910398, i wrote: > > On Fri 2018-10-05 17:48:10 -0500, Daniel Kahn Gillmor wrote: > > I'd like to update the version of GnuPG in debian stable with a series > > of targeted bugfixes (most of which are backported from upstream). > > > > There are four complementary reasons, which i explain in more detail > > below: > > > > * ptrace hardening for scdaemon > > * bugfixes that target some common workflows > > * updating cryptographic defaults > > * fixing enigmail in stretch > > > > All of the patches that implement these changes have been in buster > > for many months (either as upstream improvements or debian-specific > > improvements). > > I'd appreciate some followup on this from the debian teams -- am i > barking up the wrong tree? should i take a different approach? or do i > (and the stretch users of enigmail) just need to wait a little while > longer for review? > > Many thanks for your work in keeping debian stable safe, healthy, and > useful. Due to the intrusive changes I can imagine that the responsible teams need some time for the decision. Still it would be great if you could send a short note on whether you discuss this internally and whether you consider it a valid approach at all. That would help a lot with waiting. As dkg already explained, right now, everybody who uses Enigmail on Stretch is stuck with vulnerable Thunderbird 52 packages. Which, unfortunately, means a *lot* of users. Thus I consider any necessary steps (or prerequisites) to get Enigmail 2.0 into Stretch pretty urgent. > PS thanks to Georg for his testing of these changes, as noted in > #910398! Ack, thanks Georg! Cheers jonas signature.asc Description: OpenPGP digital signature
Bug#893448: please add a chromium-source binary package
On Mon, Oct 15, 2018 at 10:33:11PM +0200, Moritz Muehlenhoff wrote: > Ultimately this is up for Michael to decide, as he's dealing with Chromium > updates single-handedly. Agreed. > Personally I have no reservations against this entering unstable, but this > doesn't sound > like something that should enter a stable release. If the Chrome development > team with > it's hundreds of full time developers can't/wont commit to a stable interface > for these > kinds of extensions, why should we kludge around this with our sparse > resources? I guess the answer is because software wants it. :-) CEF exists precisely to be an API-stable interface for this; it's unfortunate that Chrome doesn't care enough, but CEF is meant to be that layer, and seems to be doing pretty well (judging by the amount of software that uses it). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#911118: mhddfs hangs for a while on writing
Package: mhddfs Version: 0.1.39+nmu1ubuntu2 When I initiate a samba share file transfer to a drive mounted through MHDDFS, it takes many seconds to start writing, and I observe high MHDDFS CPU usage. Reading a file works perfectly fine. Local writes are also fine. The length of the delay seems to scale with the size of the file I want to write. In the Log, when the client waits for the transfer to start, this message shows up many times: mhddfs [2018-10-15 01:03:37]: [140267440191232] mhdd_getxattr: path = /mnt/hd1/Folder/File-to-Copy.mkv name = security.capability bufsize = 0 Copying the same file to the same location through a direct Samba share is fine. This seems to happen with Windows clients (7 & 10 tested), and not with the other Ubuntu machine I have. best regards Marcél ProblemType: Bug ApportVersion: 2.20.9-0ubuntu7.4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Oct 15 01:24:54 2018 Dependencies: adduser 3.116ubuntu1 apt 1.6.3ubuntu0.1 apt-utils 1.6.3ubuntu0.1 ca-certificates 20180409 debconf 1.5.66 debconf-i18n 1.5.66 dpkg 1.19.0.5ubuntu2 fdisk 2.31.1-0.4ubuntu3.1 fuse 2.9.7-1ubuntu1 gcc-8-base 8.2.0-1ubuntu2~18.04 gpgv 2.2.4-1ubuntu1.1 libacl1 2.2.52-3build1 libapt-inst2.0 1.6.3ubuntu0.1 libapt-pkg5.0 1.6.3ubuntu0.1 libattr1 1:2.4.47-2build1 libaudit-common 1:2.8.2-1ubuntu1 libaudit1 1:2.8.2-1ubuntu1 libblkid1 2.31.1-0.4ubuntu3.1 libbz2-1.0 1.0.6-8.1 libc6 2.27-3ubuntu1 libcap-ng0 0.7.7-3.1 libdb5.3 5.3.28-13.1ubuntu1 libfdisk1 2.31.1-0.4ubuntu3.1 libffi6 3.2.1-8 libfuse2 2.9.7-1ubuntu1 libgcc1 1:8.2.0-1ubuntu2~18.04 libgcrypt20 1.8.1-4ubuntu1.1 libgmp10 2:6.1.2+dfsg-2 libgnutls30 3.5.18-1ubuntu1 libgpg-error0 1.27-6 libgpm2 1.20.7-5 libhogweed4 3.4-1 libidn2-0 2.0.4-1.1build2 liblocale-gettext-perl 1.07-3build2 liblz4-1 0.0~r131-2ubuntu3 liblzma5 5.2.2-1.3 libmount1 2.31.1-0.4ubuntu3.1 libncursesw5 6.1-1ubuntu1.18.04 libnettle6 3.4-1 libp11-kit0 0.23.9-2 libpam-modules 1.1.8-3.6ubuntu2 libpam-modules-bin 1.1.8-3.6ubuntu2 libpam0g 1.1.8-3.6ubuntu2 libpcre3 2:8.39-9 libseccomp2 2.3.1-2.1ubuntu4 libselinux1 2.7-2build2 libsemanage-common 2.7-2build2 libsemanage1 2.7-2build2 libsepol1 2.7-1 libsmartcols1 2.31.1-0.4ubuntu3.1 libssl1.1 1.1.0g-2ubuntu4.1 libstdc++6 8.2.0-1ubuntu2~18.04 libsystemd0 237-3ubuntu10.3 libtasn1-6 4.13-2 libtext-charwidth-perl 0.04-7.1 libtext-iconv-perl 1.7-5build6 libtext-wrapi18n-perl 0.06-7.1 libtinfo5 6.1-1ubuntu1.18.04 libudev1 237-3ubuntu10.3 libunistring2 0.9.9-0ubuntu1 libuuid1 2.31.1-0.4ubuntu3.1 libzstd1 1.3.3+dfsg-2ubuntu1 mount 2.31.1-0.4ubuntu3.1 openssl 1.1.0g-2ubuntu4.1 passwd 1:4.5-1ubuntu1 perl-base 5.26.1-6ubuntu0.2 sed 4.4-2 tar 1.29b-2 ubuntu-keyring 2018.02.28 util-linux 2.31.1-0.4ubuntu3.1 uuid-runtime 2.31.1-0.4ubuntu3.1 zlib1g 1:1.2.11.dfsg-0ubuntu2 DistroRelease: Ubuntu 18.04 InstallationDate: Installed on 2018-09-28 (16 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Package: mhddfs 0.1.39+nmu1ubuntu2 PackageArchitecture: amd64 ProcCpuinfoMinimal: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz stepping : 9 microcode : 0x20 cpu MHz : 3531.958 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 6800.35 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ProcEnviron: LC_TIME=de_AT.UTF-8 LC_MONETARY=de_AT.UTF-8 TERM=xterm-256color PATH=(custom, no user) LC_ADDRESS=de_AT.UTF-8 XDG_RUNTIME_DIR= LANG=en_US.UTF-8 LC_TELEPHONE=de_AT.UTF-8 LC_NAME=de_AT.UTF-8 SHELL=/bin/bash LC_MEASUREMENT=de_AT.UTF-8 LC_IDENTIFICATION=de_AT.UTF-8 LC_NUMERIC=de_AT.UTF-8 LC_PAPER=de_AT.UTF-8 ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18 SourcePackage: mhddfs Tags: bionic Uname: Linux 4.15.0-36-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) _MarkForUpload: True
Bug#893448: please add a chromium-source binary package
On Mon, Oct 15, 2018 at 11:00:24AM -0700, Jonathan Nieder wrote: > Hi, > > Emilio Pozuelo Monfort wrote: > Michael Gilbert wrote: > > > Major updates to chromium in stable have so far been contingent on it > > being a leaf package, where there is no chance for it to break > > anything else. Adding CEF as a reverse dependency would change that. > > ^^ > > > On 15/10/2018 19:19, Steinar H. Gunderson wrote: > >> On Mon, Jul 02, 2018 at 12:29:15PM +0200, Steinar H. Gunderson wrote: > > >>> Release team, for the short recap: Would it be acceptable to have chromium > >>> provide a chromium-source binary package, and then package CEF (Chromium > >>> Embedded Framework) Build-Depending on that package, and then have other > >>> packages depend on CEF? CEF aims to provide a stable API/ABI on top of > >>> Chromium for other software to use, but needs updating whenever Chromium > >>> releases a new major version. See #893448 for some more details. > >> > >> Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we > >> could add a CEF package in unstable only (ie., with a testing blocker bug) > >> for the time being. > >> > >> FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was > >> required was > >> to patch out installation of Swiftshader (since Debian's packages now > >> disable it). > > > > I'm not sure we (RT) need to make any decision here. > > > > Adding a chromium-src for other packages to build against is not special in > > any > > way, we don't approve this for other packages. > > However, you do have some say in whether a package is able to have > non-trivial updates in stable. Can we infer from your reply that > you're still okay with this for Chromium even if CEF relies on it, > provided security team is okay with it? > > > As for the security support concerns, that's up to the security team. > > Therefore cc-ing security team. Ultimately this is up for Michael to decide, as he's dealing with Chromium updates single-handedly. Personally I have no reservations against this entering unstable, but this doesn't sound like something that should enter a stable release. If the Chrome development team with it's hundreds of full time developers can't/wont commit to a stable interface for these kinds of extensions, why should we kludge around this with our sparse resources? This is rather that kind of wacky not-really-suitable-for-stable-but-still-kinda-nice stuff we should have PPAs for. Cheers, Moritz
Bug#868411: gniall: Port to GTK+ 3
On Mon, Oct 15, 2018 at 3:59 PM Yavor Doganov wrote: > It would be great if you can create a repository (possibly using gbp's > --debsnap option), import it at Salsa and grant me commit access. > That way, I can make gradual commits which will be easier to review by > a potential sponsor (rather than a giant debdiff). I created an empty Salsa repo at https://salsa.debian.org/debian/gniall Go ahead and push your packaging there. I can sponsor directly from the git repo, so ping me when you're ready for upload. The orphan bug is https://bugs.debian.org/97 Thanks, Jeremy
Bug#911022: flann breaks hugin autopkgtest: undefined symbol: LZ4_resetStreamHC
* Andreas Metzler [2018-10-15 17:23]: I guess flann not only exposes lz4 in its header but also flann-using packages directly call lz4-functions when using flann functions. Which would explain why transitive linking to lz4 via fall is not enough. (Hugin FTBFS). Yes, plus Hugin set's -as-needed and as it doesn't use any symbols from flann_cpp, it strips it, loosing the lz4 symbols as well. Anyway, this change seems to be a ABI break for flann, I guess it will need to add a Breaks: hugin (<< fixed-version~) I don't think that's needed, flann_cpp links lz4 (as-needed tricked me as well, -6 should be fine), so the Hugin binaries in unstable still work. Cheers Jochen signature.asc Description: PGP signature
Bug#911112: libtickit-dev: man pages are missing
On Mon, Oct 15, 2018 at 09:42:49PM +0200, Adam Borowski wrote: > I'm afraid this package doesn't include any documentation. The source > includes a metric crapload of man pages, yet they don't get installed > anywhere. It's a wee bit hard to use the library without them... Hmm, not sure how I missed installing those somewhere. I'll fix that up ASAP (modulo NEW time). Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#911117: O: gniall -- program that tries to learn a human language
Package: wnpp Severity: normal I am orphaning the gniall package. See https://bugs.debian.org/868411 for more details. The package description is: gNiall attempts to learn whatever language you try to teach it. It is basically a dissociator: it collects statistics on sentences you type and tries to construct meaningful replies. gNiall is inspired by Niall, an Amiga program by Matthew Peck.
Bug#784327: python-moinmoin: should (and be adapted to and) recommend ckeditor (not fckeditor)
On Tue, 05 May 2015 14:35:53 +0200 Jonas Smedegaard wrote: > Package: python-moinmoin > Severity: important > > fckeditor has been removed from Jessie, yet is recommended by > python-moinmoin. > > One of the RC bugs against fckeditor - bug#758897 - indicates that > ckeditor is a successor, so hopefully python-moinmoin can be adapted to > use that instead. This is still true in 2018. At least fckeditor should be removed from Recommends because it does not exist anymore. signature.asc Description: OpenPGP digital signature
Bug#911115: ITP: xfce4-screensaver -- screen saver and locker that is integrated with the xfce4 desktop
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: xfce4-screensaver Version : 0.1.0 Upstream Author : Sean M. Davis URL : https://git.xfce.org/apps/xfce4-screensaver/ * License : GPL-2 / LGPL-2.1 / LGPL-2 Programming Lang: C Description : screen saver and locker that is integrated with the xfce4 desktop Xfce Screensaver is a screen saver and locker that aims to have simple, sane, secure defaults and be well integrated with the Xfce desktop. It is a port of MATE Screensaver, itself a port of GNOME Screensaver. It has been tightly integrated with the Xfce desktop, utilizing Xfce libraries and the Xfconf configuration backend. Features: * Integration with the Xfce Desktop per-monitor wallpaper * Locking down of configuration settings via Xfconf * DBUS interface to limited screensaver interaction * Full translation support into many languages * Shared styles with LightDM GTK+ Greeter * Support for XScreensaver screensavers * User switching See also: Initial release announcement on: https://bluesabre.org/2018/10/15/xfce-screensaver-0-1-0-released/
Bug#909000: Thunderbird 60 cannot STILL be at stretch normal repository
Hello, On Wed, 10 Oct 2018 19:19:53 +0200 Narcis Garcia wrote: > Stable packages aren't ready for Thunderbird 60 presence. > It's better to wait for better repository consistence before adding this > update. With keeping Thunderbird at version 52 in stretch you mean to keep the packages with known security vulnerabilites? For obvious reasons, that's not an option. Cheers jonas signature.asc Description: OpenPGP digital signature
Bug#911116: ITP: python-anyqt -- Qt4/Qt5 compatibility layer
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-anyqt * URL : https://github.com/ales-erjavec/anyqt * License : GPL Programming Lang: Python Description : Qt4/Qt5 compatibility layer About to appear on salsa.debian.org/python-team/modules/anyqt.
Bug#868382: gbatnav: Please drop the (build-)dependency against gnome-vfs
Ying-Chun Liu, please review the patch attached to https://bugs.debian.org/868382 to fix the RC bug keeping gbatnav out of Testing. If we don't hear from you soon, we will NMU this package. Thanks, Jeremy Bicha
Bug#906125: please support environment settings or build profiles in autopkg tests
Control: severity -1 normal On Tue, 14 Aug 2018 18:26:16 +0200 Matthias Klose wrote: > So please either support running a build with an environment variable set I guess my response is not what you are looking for, but you can already do this, except you have to start your build in your test script. You can do: Test-Command: X=y run-my-command See e.g. how I set the temporary directory in dbconfig-common: https://sources.debian.org/src/dbconfig-common/2.0.10/debian/tests/control/?hl=5#L5 Paul signature.asc Description: OpenPGP digital signature
Bug#908564: Migration of dwarves-dfsg to samba.d.o
Hello On 10/10/18 6:11 PM, Domenico Andreoli wrote: Sorry for the late reply. I have been quite busy for a while but now my available bandwidth should be hopefully better. how is it going? ;) I have found my git repo and I am about to create the Salsa repo. You suggested renaming the repo+source to pahole as per upstream, but current version RPM remain as dwarves. Shall we go for dwarves or pahole then? I will probably create the repo on the debian group (was CollabMaint on Alioth) and upload what I have (1.10-2, NMU to reapply). Thanks, Regards, Thomas
Bug#868411: gniall: Port to GTK+ 3
Jeremy Bicha wrote: > Yavor, I'm planning to orphan gniall now. Are you interested in being > its maintainer in Debian? It's ok if you don't want to. No, but if it gets orphaned, I can prepare a QA upload fixing other packaging issues and take care of it in the future (I'm already subscribed to the PTS), treating it like my own package. This is more or less the same thing as adopting it. It would be great if you can create a repository (possibly using gbp's --debsnap option), import it at Salsa and grant me commit access. That way, I can make gradual commits which will be easier to review by a potential sponsor (rather than a giant debdiff).
Bug#528513: 4.12 in stretch - still there
I just want to report that this bug still appears valid in 4.12.1 as found in stretch. My impression is that only shortcuts involving the key are affected. In particular I have set Ctrl+Super+Up/Down/Left/Right as Shortcut for Upper/Bottom/Left/Right Workspace . I made the following observation: Pressing accidentally Fn+Ctrl+Left/Right/Up/Down deletes only the Ctrl+Super+Left/Up functions.
Bug#908975: column: outdated version lacking the option -o (--output-separator) implemented 5 years ago
Control: tags -1 + wontfix moreinfo Hello Marek Onuszko, Please see my comments inline below. On Mon, Sep 17, 2018 at 12:00:55AM +0200, Marek Onuszko wrote: > Package: util-linux > Version: 2.32.1-0.1 > Severity: wishlist > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > >I searched the internet for a way to format MarkDown tables in vim. >I found a StackOverflow thread recommending to use the new version >of 'column' with its -o option (output separator). Unfortuantely, >even Buster still contains the outdated version. > >While vim may have alternative ways like the tabular plugin, other >programs do not (for example the kakoune editor). > >links that may be helpful: > >The Launchpad page blames debian for incorrectly identifying the >bsdutils version of column as the newer one: >https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1705437 Please note the differente between bsdutils (from src:util-linux) and bsdmainutils (from src:bsdmainutils). There are two different sources implementing two different versions of the same utililies with the same name. > > The -o option was implemented 5 years ago: > > https://gitlab.apertis.org/packaging/util-linux/commit/47bd8ddc5b72739cf30f287ce84c984eb05b124e This is the util-linux version which is not used. If you want the bsdutils to provide (util-linux version of) the tools you need to convince the bsdmainutils maintainers that they should stop shipping theirs, since we can't have file collisions between different packages (ie. debian policy forbids two different packages to provide the same file). Until you've convinced the bsdmainutils maintainers we should change to the util-linux versions, there's nothing that can be done on the util-linux/bsdutils side - thus the wontfix tag. Regards, Andreas Henriksson
Bug#911114: stretch-pu: package fofix-dfsg/3.121-5~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
fofix dies with a python NotImplementedError exception during startup.
(#873156)
Based on the submitters patch I've prepared a QA upload for stretch.
The upload to sid was only a dummy to serve as a base for fixing the bug
in stretch, the package is not installable in sid because of a
dependency on the no longer available python-imaging.
I could reproduce the bug in stretch and the fixed version starts
in stretch successfully, creating a GUI window.
The package is already uploaded.
Andreas
diff -Nru fofix-dfsg-3.121/debian/changelog fofix-dfsg-3.121/debian/changelog
--- fofix-dfsg-3.121/debian/changelog 2016-09-02 20:35:13.0 +0200
+++ fofix-dfsg-3.121/debian/changelog 2018-10-15 21:06:22.0 +0200
@@ -1,7 +1,23 @@
+fofix-dfsg (3.121-5~deb9u1) stretch; urgency=medium
+
+ * QA upload.
+ * Rebuild for stretch.
+
+ -- Andreas Beckmann Mon, 15 Oct 2018 21:06:22 +0200
+
+fofix-dfsg (3.121-5) unstable; urgency=medium
+
+ * QA upload.
+ * Call image.tobytes('raw', ...) instead of image.tostring('raw', ...),
+thanks to Christian Trenkwalder. (Closes: #873156)
+ * Override source-contains-prebuilt-ms-help-file.
+
+ -- Andreas Beckmann Mon, 15 Oct 2018 18:25:19 +0200
+
fofix-dfsg (3.121-4) unstable; urgency=low
- * Orphaning package.
- * Build-Deps: Replayce python-support by dh-python
+ * Orphaning package.
+ * Build-Deps: Replace python-support by dh-python
-- Christian Brunotte Fri, 02 Sep 2016 20:35:13 +0200
diff -Nru fofix-dfsg-3.121/debian/patches/series
fofix-dfsg-3.121/debian/patches/series
--- fofix-dfsg-3.121/debian/patches/series 2013-01-09 00:24:24.0
+0100
+++ fofix-dfsg-3.121/debian/patches/series 2018-10-14 13:54:40.0
+0200
@@ -1 +1,2 @@
player-cache-location
+tostring.patch
diff -Nru fofix-dfsg-3.121/debian/patches/tostring.patch
fofix-dfsg-3.121/debian/patches/tostring.patch
--- fofix-dfsg-3.121/debian/patches/tostring.patch 1970-01-01
01:00:00.0 +0100
+++ fofix-dfsg-3.121/debian/patches/tostring.patch 2018-10-15
14:25:26.0 +0200
@@ -0,0 +1,54 @@
+Author: Christian Trenkwalder
+Description: switch from image.tostring() to image.tobytes()
+ Traceback (most recent call last):
+ [...]
+ File "/usr/share/fofix/src/Texture.py", line 77, in loadImage
+ string = image.tostring('raw', 'RGBA', 0, -1)
+ File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 697, in tostring
+ "Please call tobytes() instead.")
+ NotImplementedError: tostring() has been removed. Please call tobytes()
instead.
+
+--- a/src/Texture.py
b/src/Texture.py
+@@ -74,19 +74,19 @@ class Texture:
+ """Load the texture from a PIL image"""
+ image = image.transpose(Image.FLIP_TOP_BOTTOM)
+ if image.mode == "RGBA":
+- string = image.tostring('raw', 'RGBA', 0, -1)
++ string = image.tobytes('raw', 'RGBA', 0, -1)
+ self.loadRaw(image.size, string, GL_RGBA, 4)
+ elif image.mode == "RGB":
+- string = image.tostring('raw', 'RGB', 0, -1)
++ string = image.tobytes('raw', 'RGB', 0, -1)
+ self.loadRaw(image.size, string, GL_RGB, 3)
+ elif image.mode == "L":
+- string = image.tostring('raw', 'L', 0, -1)
++ string = image.tobytes('raw', 'L', 0, -1)
+ self.loadRaw(image.size, string, GL_LUMINANCE, 1)
+ else:
+ try:
+ image = image.convert('RGB')
+ Log.warn("Unsupported image mode '%s' converted to 'RGB'. May have
unexpected results." % image.mode)
+-string = image.tostring('raw', 'RGB', 0, -1)
++string = image.tobytes('raw', 'RGB', 0, -1)
+ self.loadRaw(image.size, string, GL_RGB, 3)
+ except:
+ raise TextureException("Unsupported image mode '%s'" % image.mode)
+@@ -113,7 +113,7 @@ class Texture:
+ # appears to be using PIL to do the conversion.
+ string = pygame.image.tostring(surface, "RGB")
+ image = Image.fromstring("RGB", surface.get_size(), string).convert("L")
+- string = image.tostring('raw', 'L', 0, -1)
++ string = image.tobytes('raw', 'L', 0, -1)
+ self.loadRaw(surface.get_size(), string, GL_LUMINANCE, GL_INTENSITY8)
+ else:
+ if alphaChannel:
+@@ -132,7 +132,7 @@ class Texture:
+ # appears to be using PIL to do the conversion.
+ string = pygame.image.tostring(surface, "RGB")
+ image = Image.fromstring("RGB", surface.get_size(), string).convert("L")
+- string = image.tostring('raw', 'L', 0, -1)
++ string = image.tobytes('raw', 'L', 0, -1)
+ self.loadSubRaw(surface.get_size(), position, string, GL_INTENSITY8)
+ else:
+ if alphaChannel:
diff -Nru fofix-dfsg-3.121/debian/source/lintian-overrides
fofix-dfsg-3.121/debian/source/lintian-overrides
--- fofix-dfsg-3.121/debian/source/lintian-overrides1970-01-01
01:00:00.0 +0100
+++
Bug#911113: O: cellwriter -- grid-entry handwriting input panel
Package: wnpp I intend to orphan the cellwriter package. It had a trivial RC bug for 9 months ( https://bugs.debian.org/885672 ) and hasn't had a maintainer upload in 5 or 10 years depending on how you count. The package description is: CellWriter is a grid-entry natural handwriting input panel. As you write characters into the cells, your writing is instantly recognized at the character level. When you press 'Enter' on the panel, the input you entered is sent to the currently focused application as if typed on the keyboard. . * Writer-dependent, learns your handwriting for reliable recognition * Correcting preprocessor algorithms account for digitizer noise, differing stroke order, direction, and number of strokes * Unicode support enables you to write in your native language
Bug#911112: libtickit-dev: man pages are missing
Package: libtickit-dev Version: 0.2-4 Severity: normal Hi! I'm afraid this package doesn't include any documentation. The source includes a metric crapload of man pages, yet they don't get installed anywhere. It's a wee bit hard to use the library without them... Meow! -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.120--std-ipv6-64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libtickit-dev depends on: ii libtickit1 0.2-4 libtickit-dev recommends no packages. libtickit-dev suggests no packages. -- no debconf information
Bug#911111: ITP: python-louvain -- community graph analysis implementing Louvain method
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-louvain * URL : https://github.com/taynaud/python-louvain * License : BSD Programming Lang: Python Description : community graph analysis implementing Louvain method A dependency for the Orange machine learning suite. It is meant to arrive on salsa.debian.org/python-team/modules/python-louvain any time soonish.
Bug#910395: mediathekview with openjfx 11
Hi, Am 15.10.18 um 19:45 schrieb Erich Schubert: > Hi, > > It seems the classpath is not set up correctly. > > With Java 11 as my main java, the following works: > > java -cp > /usr/share/mediathekview/MediathekView.jar:/usr/share/java/javafx-base-11.jar:/usr/share/java/javafx-controls-11.jar:/usr/share/java/javafx-fxml-11.jar:/usr/share/java/javafx-graphics-11.jar:/usr/share/java/javafx-media-11.jar:/usr/share/java/javafx-swing-11.jar:/usr/share/java/javafx-web-11.jar > mediathek.Main > > Since this launches correctly (I haven't tried to load anything though) > it seems the classpath / launch script is the problem. > > (If your default java is 8, you may need to set JAVA_HOME or use the > full path name). How could you launch mediathekview like that without getting the error message that JavaFX couldn't be found on the classpath (because you are using Java 11 and mediathekview checks explicitly for Java 8) ? I am aware that the javajfx-*.jar files have to be added to the CLASSPATH now. My problem is that I have to compile with OpenJDK 10 at the moment and due to some removed class files in this version, I have to switch to Java 9 bytecode at least. I have also upgraded Mediathekview to the latest upstream version 13.1.2. I am able to compile it but I get a RunTimeException with Java 10 or Java 11 and OpenJFX 11. That is bug #910764. signature.asc Description: OpenPGP digital signature
Bug#868411: gniall: Port to GTK+ 3
Yavor, I'm planning to orphan gniall now. Are you interested in being its maintainer in Debian? It's ok if you don't want to. Thanks, Jeremy
Bug#889033: smartmontools: New version (6.6) is available
unarchive 804299 reopen 804299 thanks On Thu, Apr 05, 2018 at 07:13:42AM +0200, Christian Franke wrote: For a smartmontools-6.6+ package, please reconsider the decision to remove the update-smart-drivedb script (Bug#804299) as it now validates the downloaded file. I'll (attempt to) reopen #804299, as *this* bug (#889033) will be closed by the next package upload, and we won't have deliberated on re-adding update-smart-drivedb by then. Thanks -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄
Bug#911087: schroot: --preserve-environment does not preserve env vars set to ""
Roger Leigh wrote: >Please see https://gitlab.com/codelibre/schroot/merge_requests/38 for a >patch containing the fixes. This looks like an oversight/mis-design >which is corrected by this merge request to make the behaviour >consistent for all environment handling methods. Wow, thanks for the incredibly fast response -- I appreciate it. -- PMM
Bug#911110: gradio: automatic codec installation isn't supported by your distribution
Package: flatpak Version: 1.0.4-1 Severity: normal Dear Maintainer, Hi, on a fresh debian install, after installing flatpak as follow: apt install flatpak apt install gnome-software-plugin-flatpak flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo reboot I tried to install gradio from here: https://flathub.org/apps/details/de.haeckerfelix.gradio The process did well. But after looking for the radio named: couleur3 with the thumbnail: https://upload.wikimedia.org/wikipedia/commons/thumb/3/3a/Couleur_3_logo.svg/360px- Couleur_3_logo.svg.png The gradio application says: automatic codec installation isn't supported by your distribution. Please install "gstreamer|1.0|gradio|MPEG-2 AAC decoder-audio/mpeg, mpegversion=(int)2, level=(string)1, profile=(string)lc" manually. So it seems that somehow, flatpak could be able to automatically install the right package, or at least provide a "apt install " to ease the installation -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH:fr (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages flatpak depends on: ii bubblewrap 0.3.1-2 ii libappstream-glib8 0.7.12-1 ii libarchive13 3.2.2-5 ii libc6 2.27-6 ii libglib2.0-0 2.58.1-2 ii libgpgme11 1.11.1-2 ii libjson-glib-1.0-0 1.4.4-1 ii libostree-1-1 2018.8-2 ii libpolkit-gobject-1-0 0.105-21 ii libseccomp22.3.3-3 ii libsoup2.4-1 2.64.1-3 ii libxau61:1.0.8-1+b2 ii libxml22.9.4+dfsg1-7+b1 ii xdg-desktop-portal 1.0.3-1 Versions of packages flatpak recommends: ii desktop-file-utils 0.23-4 ii gtk-update-icon-cache3.24.1-2 ii hicolor-icon-theme 0.17-2 ii libpam-systemd 239-10 ii p11-kit 0.23.14-2 ii policykit-1 0.105-21 ii shared-mime-info 1.10-1 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend] 1.0.2-2 Versions of packages flatpak suggests: ii avahi-daemon 0.7-4+b1 -- no debconf information
Bug#911109: darkstat: start darkstat does not work (status:start darkstat monitoring system at boot);manuall works"
Package: darkstat
Version: 3.0.719-1+b1
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation? Darkstat never starts as daemon, wether on
boot, nor manually
* What exactly did you do (or not do) that was effective (or
ineffective)? "systemctl start darkstat" ('restart' too)
* What was the outcome of this action? In status: "systemd[1]: Started LSB:
start darkstat monitoring system at boot time."
* What outcome did you expect instead? The daemon should have been started.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 9.5
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-0.bpo.1-amd64 (SMP w/2 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)
Versions of packages darkstat depends on:
ii debconf [debconf-2.0] 1.5.61
ii libc6 2.24-11+deb9u3
ii libpcap0.8 1.8.1-3
ii lsb-base 9.20161125
ii zlib1g 1:1.2.8.dfsg-5
darkstat recommends no packages.
darkstat suggests no packages.
-- Configuration Files:
/etc/darkstat/init.cfg changed:
START_DARKSTAT="yes"
INTERFACE="-i ens18 -p "
DIR="/var/lib/darkstat"
PORT="-p 667"
BINDIP="-b 185.216.213.5"
LOCAL="-l 185.216.213.0/255.255.252.0"
DAYLOG="--daylog darkstat.log"
DNS="--no-dns"
OPTIONS="--syslog --no-macs"
/etc/init.d/darkstat changed:
set -e
. /lib/lsb/init-functions
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON="/usr/sbin/darkstat"
NAME="darkstat"
DESC="darkstat network daemon"
INIT="/etc/darkstat/init.cfg"
HOMEDIR="/var/lib/darkstat"
PIDFILE="/var/run/$NAME.pid"
DIR="/var/lib/darkstat"
test -f $DAEMON || exit 0
test -f $INIT || exit 0
INTERFACE=""
PORT=""
BINDIP=""
LOCAL=""
DNS=""
DAYLOG=""
DB="--import darkstat.db --export darkstat.db"
FILTER=""
. $INIT
if [ "$START_DARKSTAT" = "no" ] ; then
log_warning_msg "please change the value of START_DARKSTAT in $INIT, in order
to start darkstat"
exit 0
fi
test "$START_DARKSTAT" = "yes" || exit 0
case "$1" in
start)
log_begin_msg "Starting $DESC : $NAME "
if start-stop-daemon --start --quiet -b --exec $DAEMON -- \
$INTERFACE \
$PORT \
--chroot $DIR \
--pidfile $PIDFILE \
$BINDIP \
$LOCAL \
$FIP \
$DNS \
$DAYLOG \
$DB \
$OPTIONS \
-f "$FILTER"; then
log_success_msg "done"
else
log_progress_msg "already running"
fi
log_end_msg 0
;;
stop)
log_begin_msg "Stopping $DESC : $NAME... "
if [ ! -f "$PIDFILE" ] ; then
log_progress_msg "not running"
else
if start-stop-daemon --quiet --oknodo --stop --name $NAME --pidfile
$PIDFILE --retry 30; then
rm -f $PIDFILE
log_success_msg "stopped"
else
log_progress_msg "not running"
fi
fi
log_end_msg 0
;;
restart | force-reload)
log_begin_msg "Restarting $DESC : $NAME "
if [ ! -f "$PIDFILE" ] ; then
log_progress_msg "not running "
else
if start-stop-daemon --stop --oknodo --name $NAME --pidfile $PIDFILE
--retry 30; then
rm -f $PIDFILE
else
log_progress_msg "$DESC : $NAME is not running"
rm -f $PIDFILE
fi
fi
sleep 1
start-stop-daemon --start --quiet -b --exec $DAEMON -- \
$INTERFACE \
$PORT \
--chroot $DIR \
--pidfile $PIDFILE \
$BINDIP \
$LOCAL \
$FIP \
$DNS \
$DAYLOG \
$DB \
$OPTIONS \
-f "$FILTER"
log_success_msg "done"
log_end_msg 0
;;
debug-run)
log_success_msg "$0: this option is not longer available."
log_success_msg "$0: please run darkstat with --no-daemon option"
log_success_msg "$0: for more info please check darkstat(8)."
;;
*)
N=/etc/init.d/$NAME
log_success_msg "Usage: $N {start|stop|restart|force-reload|debug-run}" >&2
exit 1
;;
esac
exit 0
-- debconf information:
darkstat/upgrade-question/db_purge-2.5-1: true
Bug#911025: Transition to postgresql-11
On Mon, Oct 15, 2018 at 4:30 AM Christoph Berg wrote: > Can I help with the transition? If you want, you can investigate why the build tests seem to hang with postgresql 11. You can check whether glom works with postgresql 11. And you can report any issues to https://gitlab.gnome.org/GNOME/glom/issues (I don't know if @murrayc is watching that yet so you may want to CC him there just to be sure he sees issues or merge requests you send.) I don't really use glom myself. I just added it to Debian since it was already in Ubuntu and people wanted it. Thanks, Jeremy Bicha
Bug#911108: libexif-gtk FTCBFS: uses the build architecture pkg-config
Source: libexif-gtk Version: 0.4.0-2 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap libexif-gtk fails to cross build from source, because it uses the build architecture pkg-config (via AC_PATH_PROG). Switching to AC_PATH_TOOL fixes that. The attached patch implements that and makes libexif-gtk cross buildable. A better solution would be replacing GP_PKG_CONFIG with the upstream macro PKG_PROG_PKG_CONFIG, but they behave subtly different. Meanwhile please consider fixing the cross build failure using my patch. Helmut --- libexif-gtk-0.4.0.orig/m4m/gp-pkg-config.m4 +++ libexif-gtk-0.4.0/m4m/gp-pkg-config.m4 @@ -19,7 +19,7 @@ fi dnl AC_REQUIRE([PKG_CHECK_MODULES]) -AC_PATH_PROG([PKG_CONFIG],[pkg-config],[false]) +AC_PATH_TOOL([PKG_CONFIG],[pkg-config],[false]) if test "$PKG_CONFIG" = "false"; then AC_MSG_ERROR([ *** Build requires pkg-config
Bug#910912: uscan: ignore USCAN_SYMLINK=rename with --download-version
On Mon, Oct 15, 2018 at 08:11:47PM +0200, Xavier wrote: > Le 15/10/2018 à 19:10, Mattia Rizzolo a écrit : > > Right, that's me being silly. I used both --report and > > --download-version, which don't really make sense (shouldn't --report > > (and --safe) conflict with all the --*)ownload* options? - unrelated, > > eh!) > > An idea: > retitle -1 uscan: --safe should allow operations that doesn't need to repack > severity -1 wishlist not really: since --safe is an alias for --report, that's clearly something that is meant to only report the status, not do anything, imho. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#866878: release.debian.org: should autopkgtest regressions be considered RC?
Control: tags -1 pending On Mon, 03 Jul 2017 15:35:00 + Niels Thykier wrote: > Graham Inggs: > > Package: release.debian.org > > Severity: wishlist > > > > Dear Release Team > > > > I recall some discussion from dc16 and I see a talk planned for dc17 > > [1] on using autopkgtest results for unstable to testing migration. > > In other words, package uploads that cause autopkgtests to fail, where > > those tests passed previously, should be prevented from migrating to > > testing. The regression can be in the uploaded package's own > > autopkgtests, or in those of a reverse dependency. > > > > Can a decision please be made, as to whether autopkgtest regressions > > will be considered RC for buster, so that bugs of severity level > > 'serious' can be filed now? > > > > Regards > > Graham > > > > > > [1] https://debconf17.debconf.org/talks/2/ > > > > Hi Graham, > > Thanks for the interest in getting this clarified. > > > I am not sure yet whether it will be ready for buster, but I think we > can defer this to a later time (a la 6 months to a year). > > > The status quo is that: > > * A failure can be RC if it basically shows that the package is broken >or have significantly regressed in functionality (possibly caused by >a dependency). > > * But autopkgtests failures in themselves are not RC at the moment. > > Related: The idea presented in the DebConf17 talk is by no means new. > This already thought up and agreed upon during DC13 plus announced on > d-d-a back then. What changed is that Paul Gevers volunteered to do it > (much appreciated, btw.). > > If you would like to help make this move forward then you are welcome to: > > * Assist Paul with implementing the necessary feature set in ci.d.n and >Britney. > > * Analyse autopkgtests failures and file bugs as appropriate (RC when >the package appears to be actually broken, non-RC otherwise). >- Patches are probably very welcome here as well. > > > Thanks, > ~Niels > > An update on this: Per https://lists.debian.org/debian-devel-announce/2018/09/msg4.html, autopkgtest regressions will block migration to testing before (or no later than) the transition freeze. Due to the slowly increasing delay, the regressions will effectively be RC several weeks before the transition freeze. Thanks, ~Niels
Bug#911025: Transition to postgresql-11
Re: To Jeremy Bicha 2018-10-15 <20181015083032.gb6...@msg.df7cb.de> > Re: Jeremy Bicha 2018-10-15 > > > How soon do you need this issue fixed? I'm ok with glom being removed > > from Testing if that helps. > > At the moment the biggest blocker is that llvm-toolchain-7 is not in > testing (OOM when stripping on mips(el)), so it's not urgent anyway. > But that could change anytime. I totally forgot to mention: as we have both pg10 and pg11 as source packages, reverse-dependencies still depending on pg10 won't block the transition to testing, so this isn't blocking anything. > Can I help with the transition? (That still stands.) Christoph
Bug#911107: deluged sends port=0 via IPv6 announce instead of the correct port
Package: deluged Version: 1.3.15-2 Severity: important Tags: ipv6 Dear Maintainer, * What led up to the situation? My system has both IPv4 and IPv6 connections and I used deluged to get the debian-9.5.0-amd64-netinst.iso . * What exactly did you do (or not do) that was effective (or ineffective)? When I did an update tracker, I saw that 2 announce messages are sent. One to the tracker's IPv4 address and one to the tracker's IPv6 address, but the last one sent port=0 instead of the correct portnumber. * What was the outcome of this action? I did a tcpdump of the connection to the debian tracker and saw the following data: To 130.239.18.159 on port 6969: ..`.NGD.GET /announce?info_hash=%3b%1d%85%f8x%0e%f8%c4%d8S%8f%80%9azc%fcR%991%8e_id=-DE13F0-a7HtrDr99EyW=28741=0=0=0=0=EBA0497F=started=200=1_peer_id=1=1=0 HTTP/1.1 Host: bttracker.debian.org:6969 User-Agent: Deluge 1.3.15 Accept-Encoding: gzip Connection: close and to 2001:6b0:e:2018::159 on port 6969: ..5ENGD.GET /announce?info_hash=%3b%1d%85%f8x%0e%f8%c4%d8S%8f%80%9azc%fcR%991%8e_id=-DE13F0-a7HtrDr99EyW=0=0=0=0=0=EBA0497F=started=200=1_peer_id=1=1=0 HTTP/1.1 Host: bttracker.debian.org:6969 User-Agent: Deluge 1.3.15 Accept-Encoding: gzip Connection: close Here you can see the port=0 part of the announce message, which will make the tracker think the client is listening on port 0, but it is not. * What outcome did you expect instead? I would expect that both the IPv4 and IPv6 announce messages would send the correct port * Additional information: I used deluge-gtk to talk to the deluged daemon. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages deluged depends on: ii adduser3.118 ii deluge-common 1.3.15-2 ii lsb-base 9.20170808 ii python 2.7.15-3 ii python-libtorrent 1.1.9-1 deluged recommends no packages. deluged suggests no packages. -- no debconf information
Bug#911106: ITP: orange3 -- machine learning suite for python
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: orange3 Version : 3.0.15 * URL : https://orange.biolab.si * License : GPL Programming Lang: C, C++, Python Description : machine learning suite for python About to appear on https://salsa.debian.org/python-team/modules/orange3
Bug#911104: mosquitto: New upstream release available
Package: mosquitto Version: 1.4.15-2 Severity: wishlist Dear Maintainer, As you're most likely well aware of there's a new upstream release available. It would be nice to have it in Debian. For your convenience I've already prepared an updated package that is available at https://people.debian.org/~ah/mosquitto/ (which has still to be properly tested and inspected). In case you don't have time for updating the package I would happily help out with an non-maintainer upload (NMU). Your review would ofcourse be much appreciated though, if you have time to look over the changes. Please get back to me as soon as possible on how you'd like to see it handled. Regards, Andreas Henriksson PS. the Vcs-Git repository is out of date or I'd have based the changes on that and provided a git tree.
Bug#911105: ITP: python-serverfiles -- accesses files on a HTTP server and stores them locally for reuse
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-serverfiles Version : 0.2.1 * URL : https://github.com/biolab/serverfiles * License : GPL Programming Lang: Python Description : accesses files on a HTTP server and stores them locally for reuse A small library that is requested by the Orange machine learning suite. I am about to upload it to https://salsa.debian.org/python-team/modules/python-serverfiles The naming "serverfiles" is obviously rather unfortunate. Hoping the prefix to render it tolerable.
Bug#911102: horst: no horst package present in repo for armhf arch
Seems to be already reported for older version of horst: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906472 I wonder if it's already "patched" for other archs but not for armhf. On Mon, Oct 15, 2018 at 6:01 PM Antoine Beaupré wrote: > On 2018-10-15 19:55:38, Pavel Kreuzt wrote: > > Package: horst > > Version: 5.0-2+b1 > > Severity: normal > > > > Dear Maintainer, > > > > there is no package horst for armhf available in repo althought the > program seems to build and run correctly in this arch (i've tested). > > This is *another* failure of sparse on non-i386 archs: > > > https://buildd.debian.org/status/fetch.php?pkg=horst=armhf=5.0-2=1504353794=0 > > can you file the bug there? > > a. > > -- > Only in the darkness can you see the stars. > - Martin Luther King, Jr. >
Bug#910575: Bug#910591: ITA: logdata-anomaly-miner -- lightweight tool for log checking, log analysis
Hi Markus, Wurzenberger Markus 于2018年10月15日周一 下午12:55写道： > > Dear Boyuan, > > I fixed all bugs you mentioned and lintian shows no more errors. Hence, it > should be possible to continue with your review. This one looks okay and I have helped upload this package. Nitpicking one more issue: you should be more verbose in writing debian/changelog entries, at least you should have closed the ITA bug (#910575) in the changelog entries as described in developers-reference ( https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-bugfix ). Now you must close your ITA bug manually by yourself. -- Thanks, Boyuan Yang
Bug#910912: uscan: ignore USCAN_SYMLINK=rename with --download-version
Le 15/10/2018 à 19:10, Mattia Rizzolo a écrit : > Control: tag -1 moreinfo > > On Mon, Oct 15, 2018 at 06:45:30PM +0200, Xavier wrote: >> looking at uscan doc, --report (same as --same) disables mk-origtargz, >> so no operation is done and you fall on actual behavior (no rename). >> What changes do you want? > > Right, that's me being silly. I used both --report and > --download-version, which don't really make sense (shouldn't --report > (and --safe) conflict with all the --*)ownload* options? - unrelated, > eh!) > > I'm now in a slow network place, so I'll try again tomrrow... An idea: retitle -1 uscan: --safe should allow operations that doesn't need to repack severity -1 wishlist
Bug#910485: Confirm issue with libpsm2-2/11.2.68-1
I'm having the same issue with libpsm2-2 version 11.2.68-1. Downgrading to 10.3.58-2 fixes it for me. -- Jonas Lippuner, PhD Scientist Computational Physics and Methods, CCS-2 Center for Theoretical Astrophysics Los Alamos National Laboratory jlippu...@lanl.gov 505-667-1646 http://jonaslippuner.com
Bug#911103: android-platform-dalvik: libandroid-dex-java dependency is no longer built
Source: android-platform-dalvik Version: 7.0.0+r33-1 Severity: serious X-Debbugs-CC: saif...@cse.mrt.ac.lk android-platform-dalvik depends and build-dpeends on libandroid-dex-java but that package is no longer built by android-platform-libcore. This has led to android-sdk-meta being removed from Testing. The libcore update said: "Remove `libandroid-dex-java`: Sources are moved to `android-platform-dalvik`" Thanks, Jeremy Bicha
Bug#911102: horst: no horst package present in repo for armhf arch
On 2018-10-15 19:55:38, Pavel Kreuzt wrote: > Package: horst > Version: 5.0-2+b1 > Severity: normal > > Dear Maintainer, > > there is no package horst for armhf available in repo althought the program > seems to build and run correctly in this arch (i've tested). This is *another* failure of sparse on non-i386 archs: https://buildd.debian.org/status/fetch.php?pkg=horst=armhf=5.0-2=1504353794=0 can you file the bug there? a. -- Only in the darkness can you see the stars. - Martin Luther King, Jr.
Bug#893448: please add a chromium-source binary package
Hi, Emilio Pozuelo Monfort wrote: Michael Gilbert wrote: > Major updates to chromium in stable have so far been contingent on it > being a leaf package, where there is no chance for it to break > anything else. Adding CEF as a reverse dependency would change that. ^^ > On 15/10/2018 19:19, Steinar H. Gunderson wrote: >> On Mon, Jul 02, 2018 at 12:29:15PM +0200, Steinar H. Gunderson wrote: >>> Release team, for the short recap: Would it be acceptable to have chromium >>> provide a chromium-source binary package, and then package CEF (Chromium >>> Embedded Framework) Build-Depending on that package, and then have other >>> packages depend on CEF? CEF aims to provide a stable API/ABI on top of >>> Chromium for other software to use, but needs updating whenever Chromium >>> releases a new major version. See #893448 for some more details. >> >> Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we >> could add a CEF package in unstable only (ie., with a testing blocker bug) >> for the time being. >> >> FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required >> was >> to patch out installation of Swiftshader (since Debian's packages now >> disable it). > > I'm not sure we (RT) need to make any decision here. > > Adding a chromium-src for other packages to build against is not special in > any > way, we don't approve this for other packages. However, you do have some say in whether a package is able to have non-trivial updates in stable. Can we infer from your reply that you're still okay with this for Chromium even if CEF relies on it, provided security team is okay with it? > As for the security support concerns, that's up to the security team. Therefore cc-ing security team. Thanks, Jonathan
Bug#910835: libgnutls30: elinks errors with SSL error with 3.6.4-2 libgnutls28 on any https website
On 2018-10-12 Dimitri John Ledkov wrote: [...] > gnutls_priority_set_direct(*state, "NORMAL:-CTYPE-OPENPGP", NULL) > which used to pass fine in 3.5. (aka use normal, but disable OPENPGP > certs), with with 3.6 this errors out, because OPENPGP certs are > disabled now by default but that matches the requested > expectations. > Imho, it would be nice if -CTYPE-OPENPGP was still valid in 3.6 and be > a no-op. Confirmed (with gnutls-cli --priority 'NORMAL:-CTYPE-OPENPGP' --list). I will ask upstream, looks like an oversight. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#911098: webext-ublock-origin: missing strings on dashbord
Am 15.10.18 um 19:22 schrieb Jakub Wilk: > Package: webext-ublock-origin > Version: 1.17.0+dfsg-2 > > Some strings are missing on the dashboard page: > * "Shortcuts" tab; > * "Disable JavaScript" checkbox. > > See the attached screenshot. > > Curiously, they both show correctly in a newly created profile. [..] Your checkboxes look different than the default theme. Did you install a different theme? Are there any other addons installed? What happens if you only use ublock-origin? Markus signature.asc Description: OpenPGP digital signature
Bug#911101: nmu: kannel-sqlbox_0.7.2-5
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal Hi, kannel-sqlbox was uploaded slightly after kannel 1.4.5-2. On most architectures, kannel-sqlbox was built against newer kannel-dev resulting in a dependency on libssl1.1. On a few architectures it was built against the older kannel package and still depends on libssl1.0.2. Please binNMU to correct this. nmu kannel-sqlbox_0.7.2-5 . armel mipsel kfreebsd-i386 kfreebsd-amd64 . -m "rebuild against kannel-dev (>= 1.4.5-2)" While at it, one could set additional B-D for kannel-sqlbox on x32. dw kannel-sqlbox_0.7.2-5 . x32 . -m 'kannel-dev (>= 1.4.5-2)' Sebastian
Bug#911102: horst: no horst package present in repo for armhf arch
Package: horst Version: 5.0-2+b1 Severity: normal Dear Maintainer, there is no package horst for armhf available in repo althought the program seems to build and run correctly in this arch (i've tested).
Bug#911100: help: please cross-reference 'scrollbind' and 'cursorbind'
Package: vim-common Version: 2:8.1.0320-1 Severity: wishlist Tags: upstream Dear Maintainer, I think it would be useful for the documentation of the 'scrollbind' option to reference the 'cursorbind' option, to make the latter more discoverable. A reference to 'cursorbind' could be added to «:help 'scrollbind'» and/or to «:help scroll-binding». Perhaps a reference in the reverse direction should be added as well, from «:help 'cursorbind'» to «:help 'scrollbind'». I've checked «:helpgrep cursorbind» and the option is only referenced in «:help start-vimdiff». Cheers, Daniel
Bug#910911: libgdbm6: can't read (some?) older GDBM databases
[2018-10-15 20:18] Niko Tyni > > I am sorry to say it, but probably binNMU or sourceful upload would > > be required for all packages, that bundle gdbm databases, generated > > by (gdbm << 1.9) > > This sounds really sad. So even the gdbm we have in our current stable > release is too old to be supported anymore! > > Any packaged databases are easily rebuilt, but what about local user > databases? I think breaking compat with those is horrible, and I don't > even see a way to recover their contents after they've upgraded gdbm. Well, you can use gdbm_dump/stable. What else? * I can write debian/NEWS to warn about incompatibility. * We can introduce new source package, that provides gdbmtool out of gdbm-1.8 (I am not fan of this idea)
Bug#893448: please add a chromium-source binary package
On 15/10/2018 19:19, Steinar H. Gunderson wrote: > On Mon, Jul 02, 2018 at 12:29:15PM +0200, Steinar H. Gunderson wrote: >> On Mon, Jun 04, 2018 at 12:17:21AM +0200, Steinar H. Gunderson wrote: Major updates to chromium in stable have so far been contingent on it being a leaf package, where there is no chance for it to break anything else. Adding CEF as a reverse dependency would change that. This is more of a question for the release team, it would need their approval. >>> Agreed. >> Release team, for the short recap: Would it be acceptable to have chromium >> provide a chromium-source binary package, and then package CEF (Chromium >> Embedded Framework) Build-Depending on that package, and then have other >> packages depend on CEF? CEF aims to provide a stable API/ABI on top of >> Chromium for other software to use, but needs updating whenever Chromium >> releases a new major version. See #893448 for some more details. > > Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we > could add a CEF package in unstable only (ie., with a testing blocker bug) > for the time being. > > FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required > was > to patch out installation of Swiftshader (since Debian's packages now disable > it). I'm not sure we (RT) need to make any decision here. Adding a chromium-src for other packages to build against is not special in any way, we don't approve this for other packages. As for the security support concerns, that's up to the security team. Cheers, Emilio
Bug#910395: mediathekview with openjfx 11
Hi, It seems the classpath is not set up correctly. With Java 11 as my main java, the following works: java -cp /usr/share/mediathekview/MediathekView.jar:/usr/share/java/javafx-base-11.jar:/usr/share/java/javafx-controls-11.jar:/usr/share/java/javafx-fxml-11.jar:/usr/share/java/javafx-graphics-11.jar:/usr/share/java/javafx-media-11.jar:/usr/share/java/javafx-swing-11.jar:/usr/share/java/javafx-web-11.jar mediathek.Main Since this launches correctly (I haven't tried to load anything though) it seems the classpath / launch script is the problem. (If your default java is 8, you may need to set JAVA_HOME or use the full path name).
Bug#911053: vitetris: vitetirs is not available by used "vitetris command"
Control: tags -1 confirmed Hi Felix, Thanks for your input. I think the name for the binary can be explained by the intent of the original author to provide a terminal-based tetris implementation, not a new game. However, I do agree with you. The name tetris is trademarked and should be changed. I'm going to make the changes and re-upload the package. Regards, -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature
Bug#893448: please add a chromium-source binary package
On Mon, Jul 02, 2018 at 12:29:15PM +0200, Steinar H. Gunderson wrote: > On Mon, Jun 04, 2018 at 12:17:21AM +0200, Steinar H. Gunderson wrote: >>> Major updates to chromium in stable have so far been contingent on it >>> being a leaf package, where there is no chance for it to break >>> anything else. Adding CEF as a reverse dependency would change that. >>> >>> This is more of a question for the release team, it would need their >>> approval. >> Agreed. > Release team, for the short recap: Would it be acceptable to have chromium > provide a chromium-source binary package, and then package CEF (Chromium > Embedded Framework) Build-Depending on that package, and then have other > packages depend on CEF? CEF aims to provide a stable API/ABI on top of > Chromium for other software to use, but needs updating whenever Chromium > releases a new major version. See #893448 for some more details. Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we could add a CEF package in unstable only (ie., with a testing blocker bug) for the time being. FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required was to patch out installation of Swiftshader (since Debian's packages now disable it). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#911087: schroot: --preserve-environment does not preserve env vars set to ""
tags 911087 + patch forwarded 911087 https://gitlab.com/codelibre/schroot/merge_requests/38 thanks On 15/10/18 15:00, Peter Maydell wrote: The schroot --preserve-environment is supposed to preserve the user's environment variables. However it does not pass through environment variables which are set to the empty string: mnementh$ FOO=bar schroot --preserve-environment -c buster-amd64-sbuild env | grep FOO FOO=bar mnementh$ FOO= schroot --preserve-environment -c buster-amd64-sbuild env | grep FOO Compare the results without schroot: mnementh$ FOO=bar env | grep FOO FOO=bar mnementh$ FOO= env | grep FOO FOO= indicating that 'env' distinguishes variables which are unset from those which are set to the empty string, but that when we run env under schroot schroot has dropped the setting of FOO. This matters because some programs treat "set to empty string" specially. For instance gcc uses "GCC_COLORS is set to the empty string" to mean "don't use color in error messages", but "GCC_COLORS is unset" to mean "use whatever the default is (for debian that means use colors)". Please see https://gitlab.com/codelibre/schroot/merge_requests/38 for a patch containing the fixes. This looks like an oversight/mis-design which is corrected by this merge request to make the behaviour consistent for all environment handling methods. Will need backporting to the 1.6 branch for Debian. Please see https://gitlab.com/codelibre/schroot/merge_requests/39 for the patch. Kind regards, Roger
Bug#911084: sagemath crashes as cantor backend
Control: reassign -1 cantor-backend-sage Please provide more information. How can the bug be triggered? I'm not familiar with cantor. If someone can demonstrate that the segfault is really in sage, the bug can be reassigned to sagemath. Best, Tobias On 10/15/2018 03:34 PM, Kinky Nekoboi wrote: > Package: sagemath > Version: 8.3-3 > Severity: serious > Justification: unkown > > as above > cantor-sage-backend crashes with Segmentation fault. > > > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), > LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages sagemath depends on: > ii cysignals-tools 1.6.7+ds-4 > ii cython 0.28.4-1 > ii ecl 16.1.2-4+b1 > ii eclib-tools 20171002-1+b3 > ii f2c 20160102-1 > ii fflas-ffpack 2.3.2-3 > ii flintqs 1:1.0-3 > ii gap-core 4r8p8-3 > ii gfan 0.6.2-2 > ii gmp-ecm 7.0.4+ds-3 > ii ipython 5.5.0-1 > ii iso-codes4.1-1 > ii jmol 14.6.4+2016.11.05+dfsg1-3.1 > ii lcalc1.23+dfsg-7 > ii less 487-0.1+b1 > ii libatlas3-base [liblapack.so.3] 3.10.3-7+b1 > ii libblas3 [libblas.so.3] 3.8.0-1+b1 > ii libbrial-groebner3 1.2.0-2 > ii libbrial31.2.0-2 > ii libc62.27-6 > ii libcdd-tools 094h-1+b1 > ii libcliquer1 1.21-2 > ii libec3 20171002-1+b3 > ii libecm1 7.0.4+ds-3 > ii libflint-2.5.2 2.5.2-18 > ii libflint-arb21:2.14.0-4 > ii libgap-sage-4 > 4.8.8+3+20160327g69a66f0+dsx-1 > ii libgcc1 1:8.2.0-7 > ii libgd3 2.2.5-4 > ii libgivaro9 4.0.4-2 > ii libglpk404.65-2 > ii libgmp10 2:6.1.2+dfsg-3 > ii libgmpxx4ldbl2:6.1.2+dfsg-3 > ii libgsl23 2.5+dfsg-5 > ii libgslcblas0 2.5+dfsg-5 > ii libiml0 1.0.4-1+b2 > ii libjs-mathjax2.7.4+dfsg-1 > ii libjs-three 80+dfsg2-2 > ii liblapack3 [liblapack.so.3] 3.8.0-1+b1 > ii liblfunction01.23+dfsg-7 > ii liblinbox-1.5.2-01.5.2-2 > ii liblinboxsage-1.5.2-01.5.2-2 > ii liblrcalc1 1.2-2+b1 > ii libm4ri-0.0.20140914 20140914-2+b1 > ii libm4rie-0.0.2015090820150908-2 > ii libmpc3 1.1.0-1 > ii libmpfi0 1.5.3+ds-2 > ii libmpfr6 4.0.1-1 > ii libntl35 10.5.0-2 > ii libopenblas-base [liblapack.so.3]0.3.3+ds-1 > ii libpari-gmp-tls6 2.11.0-1 > ii libplanarity03.0.0.5-3 > ii libpng16-16 1.6.34-2 > ii libppl14 1:1.2-3 > ii libpynac18 0.7.22-3 > ii libratpoints-2.1.3 1:2.1.3-1+b2 > ii libreadline7 7.0-5 > ii librw0 0.8+ds-1 > ii libsingular4 1:4.1.1-p2+ds-2 > ii libstdc++6 8.2.0-7 > ii libsymmetrica2 2.0+ds-5 > ii libzn-poly-0.9 0.9-3+b2 > ii maxima-sage 5.41.0+ds-2 > ii maxima-sage-doc 5.41.0+ds-2 > ii maxima-sage-share5.41.0+ds-2 > ii nauty2.6r10+ds-1 > ii octave
Bug#911098: webext-ublock-origin: missing strings on dashbord
Package: webext-ublock-origin Version: 1.17.0+dfsg-2 Some strings are missing on the dashboard page: * "Shortcuts" tab; * "Disable JavaScript" checkbox. See the attached screenshot. Curiously, they both show correctly in a newly created profile. -- System Information: Architecture: i386 Versions of packages webext-ublock-origin depends on: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-1 Versions of packages webext-ublock-origin recommends: ii firefox-esr 60.2.2esr-1 -- Jakub Wilk
Bug#911099: libnginx-mod-http-cache-purge: Use current (or more recent) version of http cache purge module
Package: libnginx-mod-http-cache-purge Severity: wishlist Dear Maintainer, Please include the current version of the cache purge module. The current version does not require the segfault patch, and also implements functionality (such as partial purges) not found in the currently packaged version. It can be found at https://github.com/nginx-modules/ngx_cache_purge Please note that the system information below reflects the system from which I wrote the bug report, not the system on which nginx is installed. -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libnginx-mod-http-cache-purge depends on: ii libc6 2.24-11+deb9u3 pn nginx-common libnginx-mod-http-cache-purge recommends no packages. libnginx-mod-http-cache-purge suggests no packages. -- Sean Davis Engineer Lex Machina
