Bug#969567: kluppe FTCBFS: multiple reasons
Source: kluppe Version: 0.6.20-1.1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs kluppe fails to cross build from source. The immediate cause is not passing cross tools to make. The easiest way of doing so is using dh_auto_build. Once doing that, one notices that the upstream Makefiles hard code the build architecture pkg-config. After making it substitutable, the dh_auto_build step passes, but it fails during make install as no cross tools are passed there and it insists on relinking everything. That unconditional relinking is unnecessary and after removing it, kluppe cross builds. Please consider applying the attached patch. Helmut diff --minimal -Nru kluppe-0.6.20/debian/changelog kluppe-0.6.20/debian/changelog --- kluppe-0.6.20/debian/changelog 2017-05-27 10:41:28.0 +0200 +++ kluppe-0.6.20/debian/changelog 2020-09-05 07:31:44.0 +0200 @@ -1,3 +1,13 @@ +kluppe (0.6.20-1.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Let dh_auto_build pass cross tools to make. ++ cross.patch: Make pkg-config substitutable ++ cross.patch: Don't force a rebuild during make install. + + -- Helmut Grohne Sat, 05 Sep 2020 07:31:44 +0200 + kluppe (0.6.20-1.1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru kluppe-0.6.20/debian/patches/cross.patch kluppe-0.6.20/debian/patches/cross.patch --- kluppe-0.6.20/debian/patches/cross.patch1970-01-01 01:00:00.0 +0100 +++ kluppe-0.6.20/debian/patches/cross.patch2020-09-05 07:31:44.0 +0200 @@ -0,0 +1,34 @@ +--- kluppe-0.6.20.orig/src/frontend/kluppe/Makefile kluppe-0.6.20/src/frontend/kluppe/Makefile +@@ -1,3 +1,4 @@ ++PKG_CONFIG ?= pkg-config + BIN_DIR = $(INSTALL_PREFIX)/bin + PIXMAPS_DIR = $(INSTALL_PREFIX)/share/pixmaps + MAN_DIR = $(INSTALL_PREFIX)/share/man/man1 +@@ -5,10 +6,10 @@ + TARGETS = $(SOURCES:.c=.o) + + kluppe: $(TARGETS) +- $(CC) -DPIXMAPS_DIR=\"$(PIXMAPS_DIR)\" *.o ../../common/*.o -o kluppe $(LDFLAGS) `pkg-config gtk+-2.0 gthread-2.0 libusb alsa jack sndfile liblo libxml-2.0 --libs gthread-2.0` -lm ++ $(CC) -DPIXMAPS_DIR=\"$(PIXMAPS_DIR)\" *.o ../../common/*.o -o kluppe $(LDFLAGS) `$(PKG_CONFIG) gtk+-2.0 gthread-2.0 libusb alsa jack sndfile liblo libxml-2.0 --libs gthread-2.0` -lm + + .c.o: +- $(CC) -DPIXMAPS_DIR=\"$(PIXMAPS_DIR)\" -c -o $@ $*.c $(CFLAGS) `pkg-config gtk+-2.0 --cflags` `xml2-config --cflags` ++ $(CC) -DPIXMAPS_DIR=\"$(PIXMAPS_DIR)\" -c -o $@ $*.c $(CFLAGS) `$(PKG_CONFIG) gtk+-2.0 --cflags` `xml2-config --cflags` + + + +--- kluppe-0.6.20.orig/Makefile kluppe-0.6.20/Makefile +@@ -10,11 +10,9 @@ + export + + kluppe: commons +- rm -f src/frontend/kluppe/kluppe.o + cd src/frontend/kluppe && $(MAKE) + + klopfer: commons +- rm -f src/frontend/klopfer/klopfer.o + cd src/frontend/klopfer && $(MAKE) + + commons: diff --minimal -Nru kluppe-0.6.20/debian/patches/series kluppe-0.6.20/debian/patches/series --- kluppe-0.6.20/debian/patches/series 2017-05-27 10:41:28.0 +0200 +++ kluppe-0.6.20/debian/patches/series 2020-09-05 07:31:03.0 +0200 @@ -5,3 +5,4 @@ 70_cflags.diff 80_manpage_email.diff 90_gtkmeter_truncated_pointer.diff +cross.patch diff --minimal -Nru kluppe-0.6.20/debian/rules kluppe-0.6.20/debian/rules --- kluppe-0.6.20/debian/rules 2016-11-25 17:12:31.0 +0100 +++ kluppe-0.6.20/debian/rules 2020-09-05 07:31:44.0 +0200 @@ -9,7 +9,7 @@ dh $@ override_dh_auto_build: - $(MAKE) CFLAGS="$(CFLAGS)" INSTALL_PREFIX=/usr + dh_auto_build -- CFLAGS="$(CFLAGS)" INSTALL_PREFIX=/usr override_dh_auto_clean: [ ! -f Makefile ] || $(MAKE) clean INSTALL_PREFIX=/usr
Bug#969566: [rust-uucore]
Package: rust-uucore Version: SoapFault - faultcode: 'SOAP-ENV:Server' faultstring: 'Processing Failure' faultactor: 'null' detail: org.kxml2.kdom.Node@cc0d624 Severity: Tags: X-Debbugs-CC: Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (orineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines ***
Bug#969260: openfjx: FTBFS (gstreamer)
Chris Knadle: > For what it's worth, I used a clean cowbuilder sid chroot that was fully > upgraded to build openjfx 11.0.7+0-4 and the package built fine. The build log > is about 808kB -- I'll send it to the bug report if desired. Offhand I'm not > sure what's going on either. It's probably wishful thinking that the > cowbuilder > build log will be comparable to the buildd build logs, but I'll have a look. Okay, I've compared the cowbuilder logs and the buildd logs and there are a number of differences, and to me it looks like buildd might be using gcc-10 where my cowbuilder build may not be. The buildd logs show many warning/error lines of variables "first defined here" and that's indicative of a gcc-10 problem, along with many other errors and warnings that the cowbuilder build didn't show. I was given some hints about this in bug #957546: Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-10/porting_to.html -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#969565: python3-azure-cli: dependency unsatisfiable in sid and questionable in testing.
Package: python3-azure-cli Version: 2.10.1-1 Severity: serious python3-azure-cli depends on python3-cryptography << 3.0.0 . In unstable this dependency is unsatisfiable because python3-cryptography is now at version 3.1-1 . In testing the dependency is strictly-speaking satisfiable because testing has version 3.0-1 of python3-cryptography and per Debian version number comparision rules 3.0-1 << 3.0.0, however it seems unlikely that this was what was intended by the person writing the dependency.
Bug#969564: lightdm: could not acquire name on session bus by simultaneous login by XDMCP and keyboard
Package: lightdm Version: 1.26.0-7 Severity: normal Tags: upstream Control: -1 forwarded https://bugs.launchpad.net/lightdm/+bug/1894356 Dear Maintainer, 1. Add the following lines to /etc/lightdm/lightdm.conf [XDMCPServer] enabled=true and restart lightdm. 2. Login as a normal user from keyboard. 3. Login as the same user as 2 from XDMCP gives "Could not acquire name on session bus" and I cannot login from XDMCP. Without Step 2, XDMCP login succeeds. * The session is Mate. The same symptom is reported at https://github.com/neutrinolabs/xrdp/issues/1559#issuecomment-623977001 which recommends removal of "dbus-user-session" Debian package. I worked around the above issue by putting "unset DBUS_SESSION_BUS_ADDRESS" in /etc/X11/Xsession.d/ I believe this is an upstream issue and reported at https://bugs.launchpad.net/lightdm/+bug/1894356 I think that LightDM should not set DBUS_SESSION_BUS_ADDRESS when it starts a session. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-3-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lightdm depends on: ii adduser3.118 ii dbus 1.12.20-1 ii debconf [debconf-2.0] 1.5.74 ii libaudit1 1:2.8.5-3+b1 ii libc6 2.31-3 ii libgcrypt201.8.6-2 ii libglib2.0-0 2.64.4-1 ii libpam-systemd [logind]246.4-1 ii libpam0g 1.3.1-5 ii libxcb11.14-2 ii libxdmcp6 1:1.1.2-3 ii lightdm-gtk-greeter [lightdm-greeter] 2.0.8-1 ii lsb-base 11.1.0 Versions of packages lightdm recommends: pn xserver-xorg Versions of packages lightdm suggests: ii accountsservice 0.6.55-3 ii upower 0.99.11-2 pn xserver-xephyr -- Configuration Files: /etc/lightdm/lightdm.conf changed: [LightDM] start-default-seat=true remote-sessions-directory=/usr/share/lightdm/sessions:/usr/share/xsessions:/usr/share/wayland-sessions [Seat:*] [XDMCPServer] enabled=true [VNCServer] -- debconf information: * shared/default-x-display-manager: lightdm lightdm/daemon_name: /usr/sbin/lightdm
Bug#776746: SGVA
Good Morning, this is in regarding to the humanitarian project i reached out to you about, you never reverted back.
Bug#968169: lxc: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether.
Le dimanche 09 août 2020 à 20:04:24-0700, Francois Marier a écrit : > Package: lxc > Version: 1:4.0.2-1 > Severity: normal > > I see the following message in my logs once a day: > > Aug 9 06:43:56 hostname systemd[1]: /lib/systemd/system/lxc.service:18: > Standard output type syslog is obsolete, automatically updating to journal. > Please update your unit file, and consider removing the setting altogether. Hi, This bug has been fixed upstream, but not included in lxc 4.0.4. I'll make a patch and close this bug. Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#969174: Fixed here [was Re: Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles]
Strangely enough... the issue is back for me after another restart of firefox... o.O
Bug#968404: liblxc1 is hardwired to systemd or cgroupv1
Dear Harald, Thanks for your bug report. Le vendredi 14 août 2020 à 20:30:19+0200, Harald Dunkel a écrit : > Package: liblxc1 > Version: 1:4.0.2-1 > > Apparently I have to install either systemd or cgroupfs-mount for > liblxc1. Since cgroupfs-mount doesn't support cgroupv2 (#959021, set > to wontfix), I am stuck. A line like > > cgroup2 /sys/fs/cgroup cgroup2 defaults > > in /etc/fstab would do. > > Do you think it would be possible to move "cgroupfs-mount | systemd" > to Recommends for liblxc1 (if it can't be dropped altogether)? This point looks valid to me. This dependency was set back in 2016 by Evgeni (Cc-ed), in commit 4f5f71fb39d52a7c0927fb10709c592e39cfe300. Evgeni, do you think dropping that would make a lot of new lxc users have troubles? Cheers, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#947334: lxc-checkpoint needs the criu package
Cc-ing Salvatore, Le mercredi 25 décembre 2019 à 08:11:11+0900, Ryutaroh Matsumoto a écrit : > Package: lxc > Version: 1:3.1.0+really3.0.4-2 > Severity: normal > > Dear Maintainer, > > lxc-checkpoint command needs "criu", which is only available > in Debian experimental now. > But "criu" is neither suggested nor recommended. > Some kind of dependency by lxc seems necessary. I can't depend on criu or I won't be able to have lxc installed in any version of Debian apart from unstable. Indeed, criu is currently voluntarily blocked from entering testing because the package is not stable enough yet. Sorry. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#966998: marked as pending in python-blessed
My bad for this mess-up in the bug. I'll undo this, and sorry for the noise. That being said, I'm working on the new lxc 4 version. :) Le vendredi 04 septembre 2020 à 20:14:15+, Pierre-Elliott Bécue a écrit : > Control: tag -1 pending > > Hello, > > Bug #966998 in python-blessed reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/python-team/modules/python-blessed/-/commit/54e6d2c7e3014b2557a109cc2f58a27e2e1b4207 > > > New upstream release 1.17.10 > > Closes: #966998 > > > (this message was generated automatically) > -- > Greetings > > https://bugs.debian.org/966998 Le vendredi 04 septembre 2020 à 20:39:03+, Debian Bug Tracking System a écrit : > This is an automatic notification regarding your Bug report > which was filed against the src:lxc package: > > #966998: lxc: FTBFS: lsm/selinux.c:35:2: error: ‘security_context_t’ is > deprecated [-Werror=deprecated-declarations] > > It has been closed by Debian FTP Masters > (reply to Pierre-Elliott Bécue ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to Pierre-Elliott Bécue > ) by > replying to this email. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#969515: flash-kernel: Add vendor path for some arm64 machines
On 04/09/2020 02:30, Vagrant Cascadian wrote: I'm submitting this to the Debian bug tracking system, since this isn't directly related to u-boot. I've dropped most of the CCs on the thread, presumably should also drop the u-boot CC on follow-ups. Thanks! For the record: I added the path for *all* missing arm64 boards, not just some :) Support for installing in vendor subdirs was added to flash-kernel 3.91 from 2018, and I believe the vendor subdirs are included in the debian-installer boot media as well. alright, but if the vendor path is missing from flash-kernel's db, everything silently works with a flattened tree. See attached patch, now it works here too :) Yes, I believe this was intentional to smooth the transition without breaking booting for some machines... I guess flash-kernel should error out if it's missing for arm=arm64? Thanks, Andre
Bug#905866: uscan: prefers watch files from a random dir over debian/watch
Hi Matthijs! On Tue, May 12, 2020 at 03:22:01PM +0200, Matthijs Kooijman wrote: > Turns out there was a bug with the directory checking. I submitted a fix > here: > > https://salsa.debian.org/debian/devscripts/-/merge_requests/193 > > That MR also has a small change to the manpage that makes it a bit more > explicit that uscan works recursively by default. Thank you for this, I've now merged it. > I still think that the current default might not be ideal. However, I do > see the usecase of running uscan over a collection of debian package at > the same time. Also, I personally hate changing long-standing defaults. > Maybe the default could be changed to only scan the current directory > *if* it is a debian source tree, and default to recursive scanning if > not? That would support both the "Run on a single package" and "Run on a > collection of packages" usecases neatly? That's too surprising. Changing behaviour that way just due to the surrounding files is too unexpected for me. Regardless, I'd accept an MR that would implement: > More specifically, I would suggest: > - Adding a `--no-recursive` option, which will always check only the >current dir (and probably produce an error if no valid package and >watchfile can be found). This might be implemented as an alias for >`--watchfile debian/watch` maybe. this, and > - Adding a `--recursive` option, which ensures that recursive operation >happens, even when the current directory is a valid source tree. This >is what is the current default operation. this, and > - Specifying more than one of `--recursive`, `--no-recursive` and >`--watchfile` is an error. this. > - When none of `--recursive`, `--no-recursive` and `--watchfile` is >specified, the default is to use `--no-recursive` when the current >directory is a source tree, and `--recursive` otherwise. Don't do this, instead leave the default --recursive on. Also perhaps add a relevant config item that would switch the default locally, so that one can set, e.g., USCAN_RECURSIVE=no in their ~/.devscripts and have it re-enabled with --recursive as needed. > One open question is what constitutes a "source tree" exactly for the > purpose of the default operation. The simplest (and most conservative) > is "Whenever a debian/ subdirectory exists", the most extensive is > probably "When a debian/changelog exists and can be parsed and > debian/watch exists". [ -f debian/changelog -a -f debian/watch ] should do IMHO. Without parsing, it would just fail a few moments later anyway. Thank you again for your contribution! :) -- 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#907576: .gitlab-webide.yml file
Hello: I am currently working a project in Salsa (dream ID 52290). Within the project's Web IDE I am currently in need of starting a 'Web Terminal' in order to build and run live testing. The terminal is grayed out and gives this message: 'Configure a .gitlab-webide.yml file in the .gitlab directory to start using the Web Terminal. Learn more.' Well 'Learn More' yields a broken link. Presuming that .gitlab-webide.yml is the correct name, I have been unsuccessful a finding a document or a template dropdown which describes it. Suggestions anyone? Garie Miller Sent with [ProtonMail](https://protonmail.com) Secure Email.
Bug#969553: urlcheck.py script tries to parse compressed GIMP image files
Laura Arjona Reina writes: > Package: www.debian.org > User: www.debian@packages.debian.org > Usertag: scripts > Severity: normal > > Hi > > the scripts "urlcheck" generate this log in the /logos folder: > > Looking into http://www.debian.org/logos/openlogo.xcf.gz > Error reading page: http://www.debian.org/logos/openlogo.xcf.gz > Looking into http://www.debian.org/logos/officiallogo.xcf.gz > Error reading page: http://www.debian.org/logos/officiallogo.xcf.gz > Looking into http://www.debian.org/logos/officiallogo-nd.xcf.gz > Error reading page: http://www.debian.org/logos/officiallogo-nd.xcf.gz > > I guess this means it tries to parse the xcf.gz files and probably we > need to update the script to skip such files (compressed images). > > Anybody familiarised with Python, who can help? > > The code of the script is here: > > https://salsa.debian.org/webmaster-team/cron/-/tree/master/urlcheck > > (I guess the main script, urlcheck.py, is where maybe the fix should be > made). > > The script is called by 3 cron jobs: > > 17 3 * * * cd /srv/www.debian.org/cron/urlcheck && ./run.urlcheck > 36 12 * * * cd /srv/www.debian.org/cron/urlcheck && > ./make.bad_link.pages > 5 13 * * * cd /srv/www.debian.org/cron/urlcheck && ./cleanup.logs > > and the daily logs are here: > https://www-master.debian.org/build-logs/urlcheck/ > (check logos folder). Hi i did attach simple patch file. It is not best way. But just it works. --- run.urlcheck.orig 2020-09-05 10:59:55.275539752 +0900 +++ run.urlcheck 2020-09-05 11:02:39.847539762 +0900 @@ -6,7 +6,7 @@ --ignore News/weekly/oldurl --ignore /Lists-Archives --ignore /cgi-bin/fom \ --ignore debian.org/fom --ignore /releases/ --ignore /international/ --ignore /security/ \ --ignore /devel/ --ignore /News/ --ignore /doc/ --ignore /distrib/ \ - --ignore /ports/ --ignore /intl/ \ + --ignore /ports/ --ignore /intl/ --ignore /logos/ \ http://www.debian.org/ >& logs/web.$date & ./urlcheck.py --require www.debian.org/international http://www.debian.org/international/ \ >& logs/web.$date.intl & Sincerely, Byung-Hee -- ^고맙습니다 _救濟蒼生_ 감사합니다_^))//
Bug#608013: recode h..us doesn't replace with ASCII equivalents
On Sun, 26 Dec 2010 07:58:49 +0800 jida...@jidanni.org wrote: > > I note that recode --force h..us causes » to disappear, when it > could easily better make a >>, or " like uni2ascii -B. In other words, doing something with `--force` can go wrong. Not a bug. > OK, recode h..utf8|uni2ascii -B works. And recoding to a charset that contains the relevant characters works. Conclusion: there's no bug here.
Bug#964745: lxc-start fails when specifying a custom lxc.net.0.hwaddr (on armv7l)
Control: tags -1 +moreinfo Hey Santiago, Thanks for the bugreport! Le jeudi 09 juillet 2020 à 22:28:06+0200, Santiago R.R. a écrit : > Package: lxc > Version: 1:3.1.0+really3.0.3-8 > Severity: important > > Dear Maintainer, > > After creating an lxc container, I've manually set a MAC address for it. > The container fails to start, giving this output in the logs: > > lxc-start container-name 20200709195149.256 ERRORnetwork - > network.c:setup_hw_addr:2762 - Cannot assign requested address - Failed to > perform ioctl > lxc-start container-name 20200709195149.256 ERRORnetwork - > network.c:lxc_setup_netdev_in_child_namespaces:2907 - Failed to setup hw > address for network device "eth0" > lxc-start container-name 20200709195149.256 ERRORnetwork - > network.c:lxc_setup_network_in_child_namespaces:3047 - failed to setup netdev > lxc-start container-name 20200709195149.256 ERRORconf - > conf.c:lxc_setup:3540 - Failed to setup network > lxc-start container-name 20200709195149.257 ERRORstart - > start.c:do_start:1275 - Failed to setup container "container-name" > lxc-start container-name 20200709195149.257 ERRORsync - > sync.c:__sync_wait:62 - An error occurred in another process (expected > sequence number 5) > lxc-start container-name 20200709195149.258 ERRORlxccontainer - > lxccontainer.c:wait_on_daemonized_start:842 - Received container state > "ABORTING" instead of "RUNNING" > lxc-start container-name 20200709195149.258 ERRORlxc_start - > tools/lxc_start.c:main:330 - The container failed to start > lxc-start container-name 20200709195149.259 ERRORlxc_start - > tools/lxc_start.c:main:333 - To get more details, run the container in > foreground mode > lxc-start container-name 20200709195149.259 ERRORlxc_start - > tools/lxc_start.c:main:336 - Additional information can be obtained by > setting the --logfile and --logpriority options > lxc-start container-name 20200709195149.275 ERRORstart - > start.c:__lxc_start:1951 - Failed to spawn container "container-name" > > In the host I can see this: > > ... > Jul 09 19:53:42 olimicro audit[4788]: AVC apparmor="STATUS" > operation="profile_load" profile="/usr/bin/lxc-start" > name="lxc-container-name_" pid=4788 comm="apparmor_parser" > Jul 09 19:53:42 olimicro kernel: audit: type=1400 > audit(1594324422.794:57): apparmor="STATUS" operation="profile_load" > profile="/usr/bin/lxc-start" name="lxc-container-name_" > pid=4788 comm="apparmor_parser" > Jul 09 19:53:42 olimicro kernel: br0: port 4(vethETHNAME) entered > blocking state > Jul 09 19:53:42 olimicro kernel: br0: port 4(vethETHNAME) entered > disabled state > Jul 09 19:53:42 olimicro systemd-udevd[4789]: link_config: > autonegotiation is unset or enabled, the speed and duplex are not writable. > Jul 09 19:53:42 olimicro kernel: device vethETHNAME entered promiscuous > mode > Jul 09 19:53:42 olimicro kernel: IPv6: ADDRCONF(NETDEV_UP): > vethETHNAME: link is not ready > Jul 09 19:53:42 olimicro systemd-udevd[4789]: Using default interface > naming scheme 'v240'. > Jul 09 19:53:42 olimicro systemd-udevd[4789]: Could not generate > persistent MAC address for vethHP689N: No such file or directory This is weird, first the interface is vethETHNAME and then vethHP689N… are you sure there isn't a quirk in your config or your bridge config? I use hardcoded macs in configurations on buster since the release without any issue, but I'm under amd64 arch... > Jul 09 19:53:42 olimicro NetworkManager[935]: [1594324422.8520] > manager: (vethHP689N): new Veth device > (/org/freedesktop/NetworkManager/Devices/37) > Jul 09 19:53:42 olimicro systemd-udevd[4790]: link_config: > autonegotiation is unset or enabled, the speed and duplex are not writable. > Jul 09 19:53:42 olimicro kernel: eth0: renamed from vethHP689N > Jul 09 19:53:42 olimicro systemd-udevd[4790]: Using default interface > naming scheme 'v240'. > Jul 09 19:53:42 olimicro sudo[4781]: pam_unix(sudo:session): session > closed for user root > Jul 09 19:53:42 olimicro NetworkManager[935]: [1594324422.9294] > manager: (vethETHNAME): new Veth device > (/org/freedesktop/NetworkManager/Devices/38) > Jul 09 19:53:43 olimicro audit[4795]: AVC apparmor="STATUS" > operation="profile_remove" profile="/usr/bin/lxc-start" > name="lxc-container-name_" pid=4795 comm="apparmor_parser" > Jul 09 19:53:43 olimicro kernel: audit: type=1400 > audit(1594324423.898:58): apparmor="STATUS" operation="profile_remove" > profile="/usr/bin/lxc-start" name="lxc-container-name_" > pid=4795 comm="apparmor_parser" > Jul 09 19:53:44 olimicro kernel: br0: port 4(vethETHNAME) entered > disabled state > Jul 09 19:53:44 olimicro kernel: device vethETHNAME left promiscuous > mode > Jul 09 19:53:44 olimicro kernel: br0: port
Bug#969534: ffc autopkg test failure
Source: ffc Followup-For: Bug #969534 Weird. That shouldn't be happening.
Bug#969563: virt-manager: does not honor X11 keyboard remap of Caps Lock to Escape
Package: virt-manager Version: 1:2.2.1-5 Severity: normal At work, I use Debian unstable on a MacBook Pro with Touch Bar. This particular machine lacks a physical Escape key, which is problematic for a Vim user, so I've remapped Caps Lock to Escape using the standard X11 capslock:escape option (using the MATE configuration settings). When I run a Windows 10 VM in virt-manager using the default Spice UI (as set up by a standard OS installation using virt-manager), this setting is not honored, and hitting Caps Lock toggles letter casing instead of sending the Escape key. This is clearly not what I want, and it leads to a frustrating experience when editing text, which, due to the limited capabilities of Windows to remap keys, is hard to work around. I expect that when I strike a key on the keyboard, virt-manager, Spice, and the rest of the KVM stack honor my X11 keyboard options and send the key to which they have been mapped, not the original key. I did look for an option in the Details section for my VM, but no such configuration to control this was available. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gir1.2-gtk-3.0 3.24.22-1 ii gir1.2-gtk-vnc-2.0 1.0.0-1 ii gir1.2-gtksource-4 4.6.1-1 ii gir1.2-libosinfo-1.0 1.7.1-1 ii gir1.2-libvirt-glib-1.0 3.0.0-1 ii gir1.2-vte-2.91 0.60.3-1 ii librsvg2-common 2.48.8+dfsg-1 ii python3 3.8.2-3 ii python3-dbus 1.2.16-3 ii python3-gi 3.36.1-1 ii python3-gi-cairo 3.36.1-1 ii python3-libvirt 6.1.0-1+b1 ii virtinst 1:2.2.1-5 Versions of packages virt-manager recommends: ii gir1.2-appindicator3-0.10.4.92-8 ii gir1.2-spiceclientglib-2.0 0.38-2 ii gir1.2-spiceclientgtk-3.0 0.38-2 ii libvirt-daemon-system 6.6.0-2 Versions of packages virt-manager suggests: ii gir1.2-secret-1 0.20.3-1 ii gnome-keyring3.36.0-1 pn python3-guestfs pn ssh-askpass ii virt-viewer 7.0-2 -- no debconf information -- brian m. carlson: Houston, Texas, US signature.asc Description: PGP signature
Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
I'd really rather not run systems at all but pulseaudio is just too broken now. On Friday, September 4, 2020, Joshua Hudson wrote: > I'm not convinced it's dmraid because udev reports the nodes up. It looks > like systems only thinks the first device name on the list is alive. > Unfortunately that name isn't stable across boots. > > On Fri, Sep 4, 2020, 12:58 PM Michael Biebl wrote: > >> On Thu, 3 Sep 2020 16:06:28 -0700 Joshua Hudson >> wrote: >> > Yeah dmraid's still in use. Is there a way to just get rid of all >> > those device units because they don't do anything right now except >> > cause problems? I've modified the boot order so systemd sees >> > everything already mounted. >> >> My recommendation would be to get rid of dmraid. >> It's dead upstream and unmaintained in Debian as well. >> You are bound to run into problems and it's only getting worse in the >> future. >> >> Michael >> >>
Bug#754945: recode: A possible buffer overflow when the input filename is too long
On Thu, 12 Jan 2017 18:19:51 +0300 Alexander Gerasiov wrote: > Package: recode > Version: 3.6-23 > Followup-For: Bug #754945 > > Another possible solution would be dinamically allocate buffer for > output_name. Please see patch attached. This is already done in recode 3.7.
Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
I'm not convinced it's dmraid because udev reports the nodes up. It looks like systems only thinks the first device name on the list is alive. Unfortunately that name isn't stable across boots. On Fri, Sep 4, 2020, 12:58 PM Michael Biebl wrote: > On Thu, 3 Sep 2020 16:06:28 -0700 Joshua Hudson > wrote: > > Yeah dmraid's still in use. Is there a way to just get rid of all > > those device units because they don't do anything right now except > > cause problems? I've modified the boot order so systemd sees > > everything already mounted. > > My recommendation would be to get rid of dmraid. > It's dead upstream and unmaintained in Debian as well. > You are bound to run into problems and it's only getting worse in the > future. > > Michael > >
Bug#969562: fgetty: Non-maintainer upload; overall maintenance of the packaging, and fixing #969063
Control: retitle "QA upload; overall maintenance of the packaging, and fixing #969063" signature.asc Description: This is a digitally signed message part
Bug#969562: fgetty: Non-maintainer upload; overall maintenance of the packaging, and fixing #969063
Package: fgetty Version: 0.7-6 Severity: normal Tags: patch This is a non-maintainer upload. I did some housekeeping in the packaging, updated the Maintainer to Debian QA Group (package has been orphaned) and fixed Bug #969063. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (800, 'testing'), (550, 'stable'), (500, 'stable-updates'), (500, 'oldstable'), (400, 'unstable'), (390, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-7.1-liquorix-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8), LANGUAGE=en_US.utf8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#952694: snapd-glib: please make the build reproducible
Chris Lamb wrote: > Would you consider applying this patch and uploading? Friendly ping on this? Seems like there hasn't been any update on this bug in 182 days now (!). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#944782: python-sybil: please make the build reproducible
Chris Lamb wrote: > Would you consider applying this patch and uploading? Friendly ping on this? Seems like there hasn't been any update on this bug in 287 days now (!). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#935362: gdbm: please make the build (slightly more..) reproducible
Dear Maintainer, > Source: gdbm > Version: 1.8.3-13 > Tags: patch There hasn't seem to be any update on this bug in 379 days, in which time the Reproducible Builds effort has come on a long way. Would you consider applying this patch and uploading? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#911757: zsh-antigen: please make the build reproducible
Chris Lamb wrote: > [..] Friendly ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#887987: zorp: please make the build reproducible
Dear Maintainer, > Source: zorp > Version: 3.9.5-4 > Tags: patch There hasn't seem to be any update on this bug in 955 days, in which time the Reproducible Builds effort has come on a long way. Would you consider applying this patch and uploading? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#926421: netcdf-parallel: please make the build reproducible
Dear Maintainer, > Source: netcdf-parallel > Version: 1:4.7.3-2build1 > Tags: patch There hasn't seem to be any update on this bug in 518 days, in which time the Reproducible Builds effort has come on a long way. Would you consider applying this patch and uploading? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#969561: brotli: breaking reverse-dependencies
Source: brotli Version: 1.0.9-1 Severity: serious tags: patch Hello, an upstream change broke pkg-config based detection. https://ci.debian.net/data/autopkgtest/testing/amd64/f/freetype/6909179/log.gz please wget https://github.com/google/brotli/pull/838.patch && add-patch 838.patch thanks Gianfranco
Bug#962733: Packaged
Okay, will do!
Bug#969560: stunnel4: build-depending on ncat instead of netcat unnecessarily expands bootstrap set
Package: stunnel4 Version: 3:5.56+dfsg-4 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu groovy ubuntu-patch Hi Peter, In bug #963260, you switched stunnel4 to build-depend on ncat, the nmap implementation of netcat. This is only used for testing, and I see no indication that the tests for stunnel4 give better coverage when using ncat instead of netcat. And on the other hand, this increases bootstrapping complexity by introducing a build-dependency on nmap, vs the quite simple - and sufficient - netcat-traditional implementation. (FWIW, in Ubuntu we have switched to netcat-openbsd by default instead of netcat-traditional, and I think the same argument applies.) For Ubuntu in particular, we have a 'netcat' package in the reduced set of packages built for i386, but not nmap/ncat. I've uploaded the attached patch to Ubuntu, to allow stunnel4 to continue to be buildable on all architectures in Ubuntu. I'm happy to discuss what the best way forward might be that works for both Debian and Ubuntu. Cheers, -- 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 stunnel4-5.56+dfsg/debian/control stunnel4-5.56+dfsg/debian/control --- stunnel4-5.56+dfsg/debian/control 2020-07-29 00:27:47.0 -0700 +++ stunnel4-5.56+dfsg/debian/control 2020-09-04 13:50:43.0 -0700 @@ -11,7 +11,7 @@ libsystemd-dev [linux-any], libunicode-utf8-perl, libwrap0-dev, - ncat, + netcat, net-tools, openssl, procps diff -Nru stunnel4-5.56+dfsg/debian/tests/control stunnel4-5.56+dfsg/debian/tests/control --- stunnel4-5.56+dfsg/debian/tests/control 2020-07-29 00:27:47.0 -0700 +++ stunnel4-5.56+dfsg/debian/tests/control 2020-09-04 13:49:25.0 -0700 @@ -4,5 +4,5 @@ Features: test-name=debian-perl Test-Command: debian/tests/upstream -Depends: @, ncat, net-tools +Depends: @, netcat, net-tools Features: test-name=upstream
Bug#969559: curl segmentation fauls on any https URL
Package: curl Version: 7.64.0-4+deb10u1 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** Simply type: $ curl https://google.com Segmentation fault or use any https URL. Here is a backtrace: 0x77679bce in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (gdb) bt #0 0x77679bce in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #1 0x77674d44 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #2 0x775987d2 in ASN1_item_verify () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #3 0x776f8fb4 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #4 0x776fadd6 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #5 0x776fb416 in X509_verify_cert () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #6 0x7780bb88 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #7 0x7782d0f3 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #8 0x7782f6c5 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #9 0x77829143 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #10 0x77814f34 in SSL_do_handshake () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #11 0x77f7f240 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #12 0x77f813f0 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #13 0x77f821da in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #14 0x77f29462 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #15 0x77f4b6fe in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #16 0x77f4caa9 in curl_multi_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #17 0x77f43642 in curl_easy_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #18 0x55569f30 in ?? () #19 0x5556b42a in ?? () #20 0xd8c4 in ?? () #21 0x77b3809b in __libc_start_main (main=0xd770, argc=2, argv=0x7fffded8, init=, fini=, rtld_fini=, stack_end=0x7fffdec8) at ../csu/libc-start.c:308 #22 0xd9da in ?? () *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages curl depends on: ii libc6 2.28-10 ii libcurl4 7.64.0-4+deb10u1 ii zlib1g1:1.2.11.dfsg-1 curl recommends no packages. curl suggests no packages. -- no debconf information
Bug#962733: Packaged
On Fri, Sep 04, 2020 at 09:45:55PM +0100, Barak A. Pearlmutter wrote: > I've packaged and been using v1.2, please see > > https://salsa.debian.org/bap/lieer.git > > which has a bunch of packaging updates, including a transition to the > new name of lieer, with an appropriate transition package of course. > > I'd be happy to have the maintainer take whatever is deemed useful, or > to upload it, NMU, co-maintain --- whatever the maintainer desires. > Julian? It looks OK, I'm fine with co-maintaining, I guess set Maintainer: lieer maintainers (email address to change following rename ofc) and add us both to uploaders? -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#969551: bash: !ref: unbound variable
Hi, William, Thanks for your report. On Fri, 04 Sep 2020, William Herrin wrote: > set -u > cd / > cd ho[tab] > bash: !ref: unbound variable This is a known bug, which has been recently fixed upstream, and in debian unstable/testing (see https://bugs.debian.org/741273#27). > -- System Information: > Debian Release: 10.5 It is indeed broken in buster and I don't have plans to backport the fix. Cheers, Gabriel
Bug#969556: liferea: Feeds with MediaRSS elements fail to render in liferea 1.13.2
Package: liferea Version: 1.13.2-1 Severity: important Tags: upstream patch Dear Maintainer, liferea 1.13.2 has been recently uploaded to Debian, however this version has a regression that breaks rendering for any feed containing MediaRSS elements, like YouTube channel feeds, like for instance: https://www.youtube.com/feeds/videos.xml?channel_id=UC1O0jDlG51N3jGf6_9t-9mw The issue has been fixed upstream and the fix will be available in the next 1.13.3 release. The fix is here: https://github.com/lwindolf/liferea/commit/ff354eee64af0c1229fbde25597d8ccdce1b2353 Maybe the Debian package can cherry-pick the fix while waiting for the new upstream release? Thanks a lot for maintaining liferea. Ciao, Antonio -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages liferea depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-1 ii dbus-x11 [dbus-session-bus] 1.12.20-1 ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gir1.2-freedesktop1.64.1-1 ii gir1.2-gtk-3.03.24.22-1 ii gir1.2-peas-1.0 1.26.0-2 ii libc6 2.31-3 ii libgdk-pixbuf2.0-02.40.0+dfsg-5 ii libgirepository-1.0-1 1.64.1-1 ii libglib2.0-0 2.64.4-1 ii libgtk-3-03.24.22-1 ii libjson-glib-1.0-01.4.4-2 ii libpango-1.0-01.46.1-1 ii libpeas-1.0-0 1.26.0-2 ii libsoup2.4-1 2.70.0-1 ii libsqlite3-0 3.33.0-1 ii libwebkit2gtk-4.0-37 2.28.4-1 ii libxml2 2.9.10+dfsg-5+b1 ii libxslt1.11.1.34-4 ii liferea-data 1.13.2-1 ii python3 3.8.2-3 ii python3-cairo 1.16.2-4 ii python3-gi3.36.1-1 ii python3-notify2 0.3-4 ii python3.8 3.8.5-2 Versions of packages liferea recommends: ii gir1.2-gstreamer-1.0 1.16.2-2 ii gir1.2-notify-0.7 0.7.9-1 Versions of packages liferea suggests: pn kget pn network-manager -- no debconf information -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
Bug#969558: ITP: mcaller -- find methylation in nanopore reads
Package: wnpp Severity: wishlist Subject: ITP: mcaller -- find methylation in nanopore reads Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: mcaller Version : 0.3+git20200621.90f6389 Upstream Author : al-mcintyre * URL : https://github.com/al-mcintyre/mCaller * License : Expat Programming Lang: Python Description : find methylation in nanopore reads H | H-C-aller | H . This program is designed to call m6A from nanopore data using the differences between measured and expected currents. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/mcaller
Bug#969557: chromium: "clear browsing data" never completes
Package: chromium Version: 83.0.4103.116-1~deb10u3 Severity: normal Dear Maintainer, When choosing to clear browsing data in settings, the action to "clear browsing data" never returns. The settings I have chosen are: Time range : "All time" Given there is a total of less than 1MB of cached images and files in Chromium's cache, I would expect this to complete rapidly on my nvme backed storage. This is a problem I have noticed for a few weeks, so it may be related to a security update. Thanks, Rory -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (700, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 83.0.4103.116-1~deb10u3 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatspi2.0-02.30.0-7 ii libavcodec58 7:4.3.1-2 ii libavformat587:4.3.1-2 ii libavutil56 7:4.3.1-2 ii libc62.31-3 ii libcairo21.16.0-4 ii libcups2 2.2.10-6+deb10u3 ii libdbus-1-3 1.12.20-0+deb10u1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.9-1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgbm1 18.3.6-2+deb10u1 ii libgcc-s1 [libgcc1] 10.2.0-5 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.1-6+deb10u1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1+deb10u3 ii libopenjp2-7 2.3.0-2+deb10u1 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpng16-16 1.6.36-6 ii libpulse012.2-4+deb10u1 ii libre2-5 20190101+dfsg-2 ii libsnappy1v5 1.1.8-1 ii libstdc++6 10.2.0-5 ii libvpx5 1.7.0-3+deb10u1 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2+b1 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.10-3 ii libxcb-dri3-01.13.1-2 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2.2~deb10u1 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 83.0.4103.116-1~deb10u3 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1+deb10u1 Versions of packages chromium-common recommends: ii chromium-sandbox 83.0.4103.116-1~deb10u3 ii dunst [notification-daemon] 1.3.2-1 ii fonts-liberation 1:1.07.4-9 ii libgl1-mesa-dri 18.3.6-2+deb10u1 ii libu2f-udev 1.1.9-1 ii upower 0.99.10-1 Versions of packages chromium-sandbox depends on: ii libc6 2.31-3 -- no debconf information
Bug#962733: Packaged
I've packaged and been using v1.2, please see https://salsa.debian.org/bap/lieer.git which has a bunch of packaging updates, including a transition to the new name of lieer, with an appropriate transition package of course. I'd be happy to have the maintainer take whatever is deemed useful, or to upload it, NMU, co-maintain --- whatever the maintainer desires. Julian? Cheers, --Barak.
Bug#966524: lvm2: "lvconvert --merge" does not remove the snapshot fter completing
I tried version 2.03.10 by downloading it from the repository https://sourceware.org/git/?p=lvm2.git;a=summary, but the problem remains. I think you should report this type of problem to the developers ...
Bug#969554: ntpd: unrecognized option --mdns
Package: ntp
Version: 1:4.2.8p12+dfsg-4
The manual page for ntpd documents the --mdns option. However using it
results in:
$ ntpd --mdns
/usr/sbin/ntpd: illegal option -- mdns
ntpd - NTP daemon program - Ver. 4.2.8p12
Usage: ntpd [ - [] | --[{=| }] ]... \
[ ... ]
Try 'ntpd --help' for more information.
$
ntpd implements this feature using a library and checks for the dns_sd.h
header during build. On a Debian buil, this header is not present and
the feature is compiled out. That results in an inconsistency between
documentation and actual feature set. Please consider removing the
option from the documentation. Other distributions such as Fedora also
keep this feature disabled[1].
Helmut
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1562155
Bug#969555: newnm page has bad link for "your personal page"
Package: nm.debian.org Severity: minor Hello, After logging into the site (via salsa) I went to https://nm.debian.org/public/newnm to kick off the process to move out of retirement. I received a page that said: Debian New Member - Join the NM process You already have an entry in the system. You already have an entry in the system if you are a DD, a DM, have a guest account on Debian machines or have already applied on this page. To request to become a Debian Maintainer or a Debian Developer, to get a porterbox guest account, and more, visit your personal page and follow the "request new status" link. However, the link href for _your personal page_ points back to https://nm.debian.org/public/newnm, instead of https://nm.debian.org/person/jello/ as it seems it should. Thanks, --Joe
Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted
On Thu, 3 Sep 2020 16:06:28 -0700 Joshua Hudson wrote: > Yeah dmraid's still in use. Is there a way to just get rid of all > those device units because they don't do anything right now except > cause problems? I've modified the boot order so systemd sees > everything already mounted. My recommendation would be to get rid of dmraid. It's dead upstream and unmaintained in Debian as well. You are bound to run into problems and it's only getting worse in the future. Michael signature.asc Description: OpenPGP digital signature
Bug#969553: urlcheck.py script tries to parse compressed GIMP image files
Package: www.debian.org User: www.debian@packages.debian.org Usertag: scripts Severity: normal Hi the scripts "urlcheck" generate this log in the /logos folder: Looking into http://www.debian.org/logos/openlogo.xcf.gz Error reading page: http://www.debian.org/logos/openlogo.xcf.gz Looking into http://www.debian.org/logos/officiallogo.xcf.gz Error reading page: http://www.debian.org/logos/officiallogo.xcf.gz Looking into http://www.debian.org/logos/officiallogo-nd.xcf.gz Error reading page: http://www.debian.org/logos/officiallogo-nd.xcf.gz I guess this means it tries to parse the xcf.gz files and probably we need to update the script to skip such files (compressed images). Anybody familiarised with Python, who can help? The code of the script is here: https://salsa.debian.org/webmaster-team/cron/-/tree/master/urlcheck (I guess the main script, urlcheck.py, is where maybe the fix should be made). The script is called by 3 cron jobs: 17 3 * * * cd /srv/www.debian.org/cron/urlcheck && ./run.urlcheck 36 12 * * * cd /srv/www.debian.org/cron/urlcheck && ./make.bad_link.pages 5 13 * * * cd /srv/www.debian.org/cron/urlcheck && ./cleanup.logs and the daily logs are here: https://www-master.debian.org/build-logs/urlcheck/ (check logos folder). Kind regards -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Bug#969552: phipack: arm64 autopkgtest failure: ERROR: Illegal state encountered: �
Source: phipack Version: 0.0.20160614-4 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You recently added an autopkgtest to your package phipack, great. However, it fails on arm64. Currently this failure is blocking the migration to testing [1]. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=phipack https://ci.debian.net/data/autopkgtest/testing/arm64/p/phipack/6611212/log.gz autopkgtest [07:17:38]: test run-unit-test: [--- Run test for functionality ... ERROR: Illegal state encountered: � Exiting... Reading sequence file noro.fasta autopkgtest [07:17:38]: test run-unit-test: ---] signature.asc Description: OpenPGP digital signature
Bug#969550: csvkit: autopkgtest regression: AssertionError: 'a,b,c' != 'line_number,a,b,c'
Source: csvkit
Version: 1.0.5-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of csvkit the autopkgtest of csvkit fails in
testing when that autopkgtest is run with the binary packages of csvkit
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
csvkit from testing1.0.5-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing
I copied some of the output at the bottom of this report. Interestingly
enough, the test also passes in unstable, so it seems that there's a
versioned (test) dependency missing somewhere (no, not python-agate-sql).
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
csvkit/1.0.5-1. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=csvkit
https://ci.debian.net/data/autopkgtest/testing/amd64/c/csvkit/6905506/log.gz
=== FAILURES
===
TestCSVFormat.test_linenumbers
self =
def test_linenumbers(self):
> self.assertLines(['--linenumbers', 'examples/dummy.csv'], [
'line_number,a,b,c',
'1,1,2,3',
])
tests/test_utilities/test_csvformat.py:36:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
tests/utils.py:87: in assertLines
self.assertEqual(lines[i], row)
E AssertionError: 'a,b,c' != 'line_number,a,b,c'
E - a,b,c
E + line_number,a,b,c
___ TestCSVJSON.test_keying
self =
def test_keying(self):
js = json.loads(self.get_output(['-k', 'a', 'examples/dummy.csv']))
> self.assertDictEqual(js, {'True': {'a': True, 'c': 3.0, 'b': 2.0}})
E AssertionError: {'true': {'a': True, 'b': 2.0, 'c': 3.0}} !=
{'True': {'a': True, 'c': 3.0, 'b': 2.0}}
E - {'true': {'a': True, 'b': 2.0, 'c': 3.0}}
E ? ^
E
E + {'True': {'a': True, 'b': 2.0, 'c': 3.0}}
E ? ^
signature.asc
Description: OpenPGP digital signature
Bug#969551: bash: !ref: unbound variable
Package: bash-completion Version: 1:2.8-6 Severity: normal Dear Maintainer, * What led up to the situation? set -u * What exactly did you do (or not do) that was effective (or ineffective)? cd / cd ho[tab] * What was the outcome of this action? bash: !ref: unbound variable * What outcome did you expect instead? cd home The error appears to come from __reassemble_comp_words_by_ref() in /usr/share/bash-completion/bash_completion -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.219-deb10 (SMP w/40 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#969549: O: libquvi -- library for parsing video download links (runtime libraries)
Package: wnpp Severity: normal Unfortunately, I'm not using this package anymore. Also, checking at [0] looks it is not maintained anymore. The package description is: Library to parse Adobe flash video download links. It supports Youtube and other similar video websites. It provides access to functionality and data through an API, and does not enable or require the use of the flash technology. [0] http://quvi.sourceforge.net/r/dev/source/repos/ -- http://www.mogaal.com GPG Key Fingerprint = F6A7 EF7E 4688 70C6 6B37 A8EF F6B0 9645 B24B F200
Bug#969537: elpa-pdf-tools-server: broken when compiled against libpoppler102
Emilio Pozuelo Monfort writes: > > You're missing libpoppler-glib's dbgsym. Could you install it? > > Also if you could bisect this against poppler that would help. Given that this > is linking against libpoppler-glib and not libpoppler(-private), you shouldn't > need to recompile epdfinfo, just run it against the local poppler build with > the > appropriate LD_LIBRARY_PATH or so. Oh! installing the matching version of libpoppler-glib8 from unstable makes the segfaults go away. I can probably fix elpa-pdf-tools-server by adding a versioned depends. Should something else be ensuring the version of libpoppler-glib8 matches (or is high enough)? d
Bug#969450: partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
Control: severity -1 minor On Thu, 2020-09-03 at 08:43 +0200, jurriaan wrote: > Package: partman-auto > Severity: important > Tags: d-i > > Dear Maintainer, > > I was a bit surprised when I did a quick Debian Stable install on my > new workstation (384 Gb RAM, 512 Gb ssd) and ended up with just 80 Gb > usable diskspace, thanks to a 400 Gb swap partition that the Debian > installer created. I think a warning/question when more than 25% of > the disk is used as swap-space would be in order. I would think that > computer-owners who install large amounts of memory carefully install > enough memory to not swap excessively. [...] This is an extremely unusual configuration for a desktop. You always have the opportunity to review and modify the partitioning before going ahead. So reducing the severity. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#969548: setuptools breaks ffc autopkgtest: No module named 'ffc_factory'
Source: setuptools, ffc Control: found -1 setuptools/49.3.1-2 Control: found -1 ffc/2019.2.0~git20200123.6b621eb-2 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of setuptools the autopkgtest of ffc fails in testing when that autopkgtest is run with the binary packages of setuptools from unstable. It passes when run with only packages from testing. In tabular form: passfail setuptools from testing49.3.1-2 ffcfrom testing2019.2.0~git20200123.6b621eb-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of setuptools to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=setuptools https://ci.debian.net/data/autopkgtest/testing/amd64/f/ffc/6909276/log.gz ERRORS _ ERROR collecting ufc/finite_element/test_evaluate.py _ ImportError while importing test module '/tmp/autopkgtest-lxc.cxd5j8yt/downtmp/build.Ndr/src/test/unit/ufc/finite_element/test_evaluate.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: unit/ufc/finite_element/test_evaluate.py:25: in import ffc_factory E ModuleNotFoundError: No module named 'ffc_factory' !!! Interrupted: 1 errors during collection === 1 error in 1.40 seconds autopkgtest [10:34:49]: test test-ffc: ---] signature.asc Description: OpenPGP digital signature
Bug#969547: gnutls28: CVE-2020-24659: GNUTLS-SA-2020-09-04
Source: gnutls28 Version: 3.6.14-2 Severity: important Tags: security upstream Forwarded: https://gitlab.com/gnutls/gnutls/-/issues/1071 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for gnutls28. CVE-2020-24659[0]: | An issue was discovered in GnuTLS before 3.6.15. A server can trigger | a NULL pointer dereference in a TLS 1.3 client if a no_renegotiation | alert is sent with unexpected timing, and then an invalid second | handshake occurs. The crash happens in the application's error | handling path, where the gnutls_deinit function is called after | detecting a handshake failure. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-24659 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24659 [1] https://gitlab.com/gnutls/gnutls/-/issues/1071 [2] https://www.gnutls.org/security-new.html#GNUTLS-SA-2020-09-04 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#969546: freecad: Freecad crashes when placing beam in Arch workbench
Package: freecad Version: 0.18.4+dfsg2-5 Severity: normal Tags: upstream X-Debbugs-Cc: tylerschw...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Attempting to use the Arch workbench in Freecad. * What exactly did you do (or not do) that was effective (or ineffective)? Open a new document. Switch to the Arch workbench. Click the Structure button. Switch to Beam. Optionally, set the material and preset. Place the beam. * What was the outcome of this action? Freecad crashes with the below segfault. * What outcome did you expect instead? A new beam. *** End of the template - remove these template lines *** Program received signal SIGSEGV, Segmentation fault. #0 /lib/x86_64-linux-gnu/libc.so.6(+0x3be30) [0x7f2ef531fe30] #1 0x7f2ed9773a5f in Shiboken::Object::cppPointers(SbkObject*) from /usr/lib/x86_64-linux-gnu/libshiboken2.cpython-38-x86_64-linux-gnu.so.5.15+0xdf #2 /usr/lib/python3/dist-packages/shiboken2/shiboken2.cpython-38-x86_64-linux- gnu.so(+0x273a) [0x7f2eec17573a] #3 /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0xe5f66) [0x7f2ef632cf66] #4 /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyVectorcall_Call+0x5c) [0x7f2ef62e913c] #5 0x7f2ef73ccd07 in Gui::qt_getCppPointer(Py::Object const&, char const*, char const*) from /usr/lib/freecad-python3/lib/libFreeCADGui.so+0x2c7 #6 0x7f2ef72fd950 in Gui::TaskView::TaskDialogPython::TaskDialogPython(Py::Object const&) from /usr/lib/freecad-python3/lib/libFreeCADGui.so+0x7d0 #7 0x7f2ef72fdd0d in Gui::TaskView::ControlPy::showDialog(Py::Tuple const&) from /usr/lib/freecad-python3/lib/libFreeCADGui.so+0x8d #8 0x7f2ef72fe6b1 in Py::PythonExtension::method_varargs_call_handler(_object*, _object*) from /usr/lib/freecad-python3/lib/libFreeCADGui.so+0x1b1 #9 /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0xa19c7) [0x7f2ef62e89c7] #10 /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyObject_MakeTpCall+0xa7) [0x7f2ef62e9817] #11 /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x7dcd3) [0x7f2ef62c4cd3] #12 /usr/lib/x86_64-linux- gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x1292) [0x7f2ef62bc552] #13 /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x73073) [0x7f2ef62ba073] #14 /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyVectorcall_Call+0x5c) [0x7f2ef62e913c] #15 0x7f2ed9279dc8 in PySide::SignalManager::callPythonMetaMethod(QMetaMethod const&, void**, _object*, bool) from /usr/lib/x86_64-linux- gnu/libpyside2.cpython-38-x86_64-linux-gnu.so.5.15+0x98 #16 /usr/lib/x86_64-linux-gnu/libpyside2.cpython-38-x86_64-linux- gnu.so.5.15(+0x142ae) [0x7f2ed927e2ae] #17 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2d6610) [0x7f2ef5968610] #18 0x7f2ef596c24a in QTimer::timeout(QTimer::QPrivateSignal) from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x3a #19 /usr/lib/python3/dist-packages/PySide2/QtCore.cpython-38-x86_64-linux- gnu.so(+0x2b85bf) [0x7f2ed95585bf] #20 0x7f2ef595ee5f in QObject::event(QEvent*) from /usr/lib/x86_64-linux- gnu/libQt5Core.so.5+0x1cf #21 /usr/lib/python3/dist-packages/PySide2/QtCore.cpython-38-x86_64-linux- gnu.so(+0x2b8167) [0x7f2ed9558167] #22 0x7f2ef5d2403f in QApplicationPrivate::notify_helper(QObject*, QEvent*) from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x7f #23 0x7f2ef7108cf8 in Gui::GUIApplication::notify(QObject*, QEvent*) from /usr/lib/freecad-python3/lib/libFreeCADGui.so+0x88 #24 0x7f2ef5933b62 in QCoreApplication::notifyInternal2(QObject*, QEvent*) from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x182 #25 0x7f2ef59886c3 in QTimerInfoList::activateTimers() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x3e3 #26 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2f6f44) [0x7f2ef5988f44] #27 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x27d) [0x7f2ef32255fd] #28 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x50880) [0x7f2ef3225880] #29 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2f) [0x7f2ef322590f] #30 0x7f2ef59892ff in QEventDispatcherGlib::processEvents(QFlags) from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x5f #31 0x7f2ef59324db in QEventLoop::exec(QFlags) from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x12b #32 0x7f2ef593a782 in QCoreApplication::exec() from /usr/lib/x86_64-linux- gnu/libQt5Core.so.5+0x92 #33 0x7f2ef709a77b in Gui::Application::runApplication() from /usr/lib/freecad-python3/lib/libFreeCADGui.so+0x165b #34 freecad(main+0x6a6) [0x55aaaefdf726] #35 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f2ef530acca] #36 freecad(_start+0x2a) [0x55aaaefdfa1a] Segmentation fault -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Bug#969545: kde-plasma-desktop: Taskbar does not update its display but is clickable
Package: kde-plasma-desktop Version: 5:102 Severity: important Dear Maintainer, Taskbar does not update its display randomly. When you open a new window, items displaying on taskbar should be updated, but they do not. And when you click on the buttons on taskbar, the displayed buttons do not match the windows, and you may open a wrong window. And the clock does not update as well. Not sure if other menu items are updated correctly or not. Alt-tab works as expected. The bug happens everyday, and it goes away around after one hour. Expected outcome: Taskbar items update after open or close window, and clock update every minute. I attach a screenshot, in which you can see that the taskbar does not show a background window (Left 4 dead 2), and the desk clock on the bottom-right corner stops working: https://i.loli.net/2020/09/05/L1TYR6IzPdsUDGq.jpg -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable'), (300, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN:zh (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kde-plasma-desktop depends on: ii kde-baseapps 4:17.08.3+5.102 ii plasma-desktop4:5.14.5.1-1 ii plasma-workspace 4:5.14.5.1-1 ii udisks2 2.8.1-4 ii upower0.99.10-1 Versions of packages kde-plasma-desktop recommends: ii kwin-x11 4:5.14.5-1 ii sddm 0.18.0-1 ii xserver-xorg 1:7.7+19 Versions of packages kde-plasma-desktop suggests: ii kdeconnect 1.3.3-2 -- no debconf information
Bug#954905: Possibly duplicated
This seems to be the same as #963980 [1], where a workaround is provided. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963980 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
Bug#969544: RFS: golang-github-rickb777-date/1.0-1 [ITP] -- Go library that provides functionality for working with dates.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-rickb777-date": * Package name: golang-github-rickb777-date Version : 1.13.0-1~exp1 Upstream Author : https://github.com/rickb777/date/issues * URL : https://github.com/rickb777/date * License : BSD-3-clause * Vcs : [fill in URL of packaging vcs] Section : devel It builds those binary packages: golang-github-rickb777-date-dev - Go library that provides functionality for working with dates. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-rickb777-date/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-rickb777-date/golang-github-rickb777-date_1.13.0-1~exp1.dsc Changes for the initial release: golang-github-rickb777-date (1.13.0-1~exp1) experimental; urgency=medium . * Initial release. (Closes: #969455) Regards, -- Arun Kumar Pariyar
Bug#954954: fixed in gcc-10 10-20200402-1
Control: reopen -1 On Thu, Apr 02, 2020 at 01:33:36PM +, Debian FTP Masters wrote: >* Update libstdc++6 symbols file for armel. Closes: #954954. It seems the issue is still present in 10.2.0-6. Thanks, Ivo
Bug#607021: -k doesn't work (fwd)
This is fixed in current 3.7.7.
Bug#964899: reduce severity
control: severity -1 normal control: tags -1 unreproducible downgrade severity as it built in debian buildd and not reproducible in sbuild
Bug#969537: elpa-pdf-tools-server: broken when compiled against libpoppler102
On Fri, 04 Sep 2020 12:49:06 -0300 David Bremner wrote: > David Bremner writes: > > > Package: elpa-pdf-tools-server > > Version: 0.90-3+b2 > > Here's a backtrace > > Program received signal SIGSEGV, Segmentation fault. > 0x77e5951e in ?? () from > /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 > (gdb) bt > #0 0x77e5951e in () at > /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 > #1 0x77ac284f in Gfx::opShowSpaceText(Object*, int) > (this=0x555c3100, args=0x7fffddb0, numArgs=) at > ./poppler/Object.h:411 > #2 0x77ab8637 in Gfx::go(bool) (this=this@entry=0x555c3100, > topLevel=topLevel@entry=true) > at ./poppler/Gfx.cc:679 > #3 0x77ab8b50 in Gfx::display(Object*, bool) > (this=this@entry=0x555c3100, obj=obj@entry=0x7fffe0c0, > topLevel=topLevel@entry=true) > at ./poppler/Gfx.cc:640 > #4 0x77b12652 in Page::displaySlice(OutputDev*, double, double, int, > bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool > (*)(Annot*, void*), void*, bool) > (this=0x555b6020, out=0x555c0be0, hDPI=, > vDPI=, rotate=, useMediaBox=, > crop=, sliceX=, sliceY=-1, sliceW=-1, > sliceH=-1, printing=false, abortCheckCbk=0x0, abortCheckCbkData=0x0, > annotDisplayDecideCbk= > 0x0, annotDisplayDecideCbkData=0x0, copyXRef=false) at > ./poppler/Page.cc:574 > #5 0x77e4439c in () at > /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 > #6 0xee26 in image_render_page > (pdf=, page=0x555bd440, width=, > options=0x55589f18, do_render_annotaions=1) at epdfinfo.c:491 > #7 0xf9ab in cmd_renderpage (ctx=0x7fffe3c8, args= out>) at epdfinfo.c:3100 > #8 0xb33a in main (argc=, argv=) > at epdfinfo.c:3689 You're missing libpoppler-glib's dbgsym. Could you install it? Also if you could bisect this against poppler that would help. Given that this is linking against libpoppler-glib and not libpoppler(-private), you shouldn't need to recompile epdfinfo, just run it against the local poppler build with the appropriate LD_LIBRARY_PATH or so. Emilio
Bug#968918: Threshold function is extremely slow - Unusable - possible regression
Thanks for the report. https://github.com/ImageMagick/ImageMagick/issues/1819 doesn't mention performance problems, just corruption in the image. I can't reproduce your problem. The threshold tool works fine for me with or without conversion to PNG first. Please start gscan2pdf from the command line with the --log=log option, reproduce the problem, quit, and post the log file, which gscan2pdf should have compressed to log.xz. signature.asc Description: OpenPGP digital signature
Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load
Hi Dirk, On Fri, Sep 04, 2020 at 05:51:58PM +0200, Dirk Kostrewa wrote: > Hi Salvatore, > > meanwhile, Dell has replaced the mainboard of my laptop, and after that, > both the USB over-current kernel messages and the kworker processes with > high CPU load are gone. > > Many thanks for caring about my bug report! Thanks for reporting back! So I'm closing as well the bugreport as thre is nothing to be done on Linux side for it. Glad if it was of help. Regards, Salvatore
Bug#969376: openafs-client: Openafs cache erros on the logs
Hi, I have made an update to my private backport. It is better but I still see the same errors on the logs. This machine is a VM and no other VM or host is reporting IO errors of any kind, that I know off. It was my first time using gerrit, so can you please check if the I have downloaded the correct patches? ee578e9.diff 179a418.diff There is a way to decode this errors and try to understand better what is happening and find a fix? [9.760892] openafs: loading out-of-tree module taints kernel. [9.760898] openafs: module license 'http://www.openafs.org/dl/license10.html' taints kernel. [9.762091] openafs: module verification failed: signature and/or required key missing - tainting kernel [9.778441] Key type afs_pag registered [ 8245.094223] afs: disk cache read error in CacheItems slot 211006 off 16880500/19660820 code -4/80 [ 8245.094254] afs: disk cache read error in CacheItems slot 211006 off 16880500/19660820 code -4/80 [ 8245.094277] afs: disk cache read error in CacheItems slot 211006 off 16880500/19660820 code -4/80 [ 8245.094299] afs: disk cache read error in CacheItems slot 211006 off 16880500/19660820 code -4/80 [10181.679636] afs: disk cache read error in CacheItems slot 156531 off 12522500/19660820 code -4/80 [10181.679638] afs: Error while alloc'ing cache slot for file 204:536874423.516.5309; failing with an i/o error [11438.241843] afs_UFSGetVolSlot: error -4 reading volumeinfo [11438.242213] afs_UFSGetVolSlot: error -4 reading volumeinfo Kind regards Jose M Calhariz On Wed, Sep 02, 2020 at 07:28:50PM +0100, Jose M Calhariz wrote: > Hi, > > I will then update my private backport and see if the things improve. > I will report here the results of your sugestion. Thank you. > > Kind regards > Jose M Calhariz > > On Tue, Sep 01, 2020 at 04:07:55PM -0700, Benjamin Kaduk wrote: > > On Tue, Sep 01, 2020 at 03:43:37PM +0100, Jose M Calhariz wrote: > > > Package: openafs-client > > > Version: 1.8.6-1~dsi10+1 > > > Severity: normal > > > > > > I am using a private backport of openafs from testing. On this server I > > > am getting multiples strange errors about openafs cache. This server > > > is different in that it runs apache to serve personal web pages and every > > > web page runs under a different openafs user. So is normal for this > > > server to be simultaneuous running code under 100 or 200 different > > > openafs > > > users. > > > > > > The an example of errors on the logs are: > > > > > > afs: disk cache read error in CacheItems slot 350195 off > > > 28015620/3520 code -4/80 > > > afs: Error while alloc'ing cache slot for file 204:536874423.964.4794; > > > failing with an i/o error > > > > > > I am not certain this types of errors are to be ignored and there have > > > been reports of problems accessing openafs files. I am using this bug > > > report to collect more information about this cache errors and the > > > possibility of being an indication of important errors with the openafs > > > cache code. > > > > This error message is supposed to indicate that a read from the cache > > filesystem got EIO, which in turn is supposed to indicate a physical > > problem with the drive. That said, I'm not going to jump to conclusions > > and try to blame your drive, as there are several other things that could > > be coming into play. > > > > While the log message itself is pretty old, there's been a lot of work > > recently to more accurately report EIO in error conditions (mostly instead > > of ENOENT, since returning ENOENT can cause that to get cached at the VFS > > layer and produce strange user-visible behavior). > > > > Having a lot of users present makes me suspect that the credentials used by > > the kernel to read/write the cache file are not being saved/restored > > properly, and indeed we recently merged to 1.8.x (not in a release yet) > > https://gerrit.openafs.org/14082 and https://gerrit.openafs.org/14099 which > > improve such credentials management. > > > > My recommendation would be to try pulling in those two patches to your > > build before proceeding to try to trace the source of the EIO. > > > > Thanks for the report! > > > > -Ben > > > -- -- A esperança tem que ter a audácia do desespero. --Millôr Fernandes Retirado de http://www.uol.com.br/millor signature.asc Description: PGP signature
Bug#969543: solaar: Solaar should autostart with --window=hide
Package: solaar Version: 1.0.3+dfsg-1 Severity: normal X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, As of recently, solaar seems to be autostarting both on the system tray and as a standalone application window. Upstream ships share/autostart/solaar.desktop. It starts solaar with the --window=hide option, which causes it to launch without the main application window. This seems like a more appropriate behavior, but the Debian package instead installs a /etc/xdg/autostart/solaar.desktop that launches solaar without said option. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-3-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages solaar depends on: ii adduser 3.118 ii debconf [debconf-2.0]1.5.74 ii gir1.2-ayatanaappindicator3-0.1 0.5.5-2 ii gir1.2-gtk-3.0 3.24.22-1 ii gir1.2-notify-0.70.7.9-1 ii passwd 1:4.8.1-1 ii python3 3.8.2-3 ii python3-gi 3.36.1-1 ii python3-pyudev 0.21.0-3 ii udev 246.3-1 Versions of packages solaar recommends: ii python3-dbus 1.2.16-3 ii upower0.99.11-2 solaar suggests no packages. -- debconf information excluded
Bug#963813: evince: segmentation fault in evince opening rfc8798.pdf
Control: found -1 0.71.0-5 Control: severity -1 important Control: forwarded -1 https://gitlab.freedesktop.org/poppler/poppler/-/issues/599 Control: tags -1 + patch fixed-upstream On Fri, 04 Sep 2020 at 18:17:33 +0200, Bernhard Übelacker wrote: > Searching upstream issues for checksum points to this one [2]. > Building a package with mentioned patch makes evince no longer crash. ... > [2] > https://gitlab.freedesktop.org/poppler/poppler/-/issues/599 > > https://gitlab.freedesktop.org/poppler/poppler/-/commit/6f5327114c824791dda72dc415b047d445e46d9d This is fixed in testing, then. I'll close this bug when the metadata updates from this mail have gone through. Debian 10 'buster' continues to be affected, but the bug tracking system's version-tracking should be able to figure that out. smcv
Bug#969446: sponsorship-requests: vguitar-2.6 [ITP} -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth).
Hi Boyuan Yang, I have added my source architecture to repo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AB406C34 add to /etc/apt/sources.list.d deb-src http://apt.nick-strauss.com/apt/debian jessie main apt-get source vguitar nick strauss
Bug#969542: RFS: golang-github-teambition-rrule-go/1.0-1 [ITP] -- Go library for working with recurrence rules for calendar dates.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-teambition-rrule-go": * Package name: golang-github-teambition-rrule-go Version : 1.6.0-1~exp1 Upstream Author : https://github.com/teambition/rrule-go/issues * URL : https://github.com/teambition/rrule-go * License : MIT * Vcs : https://salsa.debian.org/pkg-deepin-team/golang-github-teambition-rrule-go Section : devel It builds those binary packages: golang-github-teambition-rrule-go-dev - Go library for working with recurrence rules for calendar dates. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-teambition-rrule-go/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-teambition-rrule-go/golang-github-teambition-rrule-go_1.6.0-1~exp1.dsc Changes for the initial release: golang-github-teambition-rrule-go (1.6.0-1~exp1) experimental; urgency=medium . * New upstream release. Regards, -- Arun Kumar Pariyar
Bug#969541: lintian: globbing-patterns-out-of-order false positive
Package: lintian Version: 2.89.0 Severity: normal Dear Maintainer, W: wasi-libc source: globbing-patterns-out-of-order libc-top-half/musl/arch/*/bits/* libc-top-half/musl/arch/mips64/* but this is fine. X -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.35-2 ii bzip2 1.0.8-4 ii clzip 1.11-9 ii diffstat 1.63-1 ii dpkg 1.20.5 ii dpkg-dev 1.20.5 ii file 1:5.38-5 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b5 ii libclone-perl 0.45-1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl4.21-1 ii libdata-dpath-perl0.58-1 ii libdata-validate-domain-perl 0.10-1 ii libdevel-size-perl0.83-1+b1 ii libdigest-sha-perl6.02-1+b2 ii libdpkg-perl 1.20.5 ii libemail-address-xs-perl 1.04-1+b2 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-parser-perl 3.75-1 pn libio-async-loop-epoll-perl ii libio-async-perl 0.77-3 ii libipc-run3-perl 0.048-2 ii libjson-maybexs-perl 1.004002-1 ii liblist-compare-perl 0.55-1 ii liblist-moreutils-perl0.416-1+b5 ii liblist-utilsby-perl 0.11-1 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.114-1 ii libperlio-gzip-perl 0.19-1+b6 ii libsereal-decoder-perl4.018+ds-1 ii libsereal-encoder-perl4.018+ds-1 ii libtext-levenshteinxs-perl0.03-4+b7 ii libtext-xslate-perl 3.5.8-1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b2 ii libtimedate-perl 2.3300-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl 1.010005-1 ii libunicode-utf8-perl 0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl2.0134+dfsg-2 pn libxml-writer-perl ii libyaml-libyaml-perl 0.82+repack-1 ii lzop 1.04-1 ii man-db2.9.3-2 ii patchutils0.4.2-1 ii perl [libdigest-sha-perl] 5.30.3-4 ii t1utils 1.41-4 ii unzip 6.0-25 ii xz-utils 5.2.4-1+b1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35-2 ii libtext-template-perl 1.59-1 -- Configuration Files: /etc/lintianrc [Errno 2] No such file or directory: '/etc/lintianrc' -- no debconf information
Bug#963980: bumblebee-nvidia: Bumblebee daemon reported: error: [XORG] (EE) Unable to locate/open config directory
In https://wiki.debian.org/Bumblebee#Debian_10_and_older I've found this hint: ``` [ERROR]Cannot access secondary GPU - error: [XORG] (EE) No devices detected You may have to set the BusID manually, in /etc/bumblebee/xorg.conf.nvidia. To get the BusID, run lspci | egrep 'VGA|3D' in a terminal. Refer to the comments in that file for further instructions. ``` So I've edited `/etc/bumblebee/xorg.conf.nvidia` and uncommented one line so it's now: ``` BusID "PCI:01:00:0" ``` And it works! `lspci | egrep 'VGA|3D'` on my machine returns: ``` 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 860M] (rev ff) ``` So some part fails to detect that only NVIDIA card..? :)
Bug#969540: [Pkg-rust-maintainers] Bug#969540: librust-directories-1-dev: short package description is too long
Le 04/09/2020 à 18:11, Daniele Forsi a écrit : Package: librust-directories-1-dev Severity: normal Dear Maintainer, the short package description is not suitable to be shown on a single line because it is 341 characters long : "Tiny mid-level library that provides platform-specific standard locations of directories for config, cache and other data on Linux, Windows and macOS by leveraging the mechanisms defined by the XDG base/user directory specifications on Linux, the Known Folder API on Windows, and the Standard Directory guidelines on macOS - Rust source code" The policy says: "The single line synopsis should be kept brief—certainly under 80 characters." https://www.debian.org/doc/debian-policy/ch-binary.html#the-single-line-synopsis Looking at rust-* here: https://lintian.debian.org/tags/synopsis-too-long.html seems that we have a bunch of problem here. :) S
Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu
On Thu, 03 Sep 2020 22:53:13 +0200 Johannes Schauer wrote:
> Hi Francesco,
Hello Johannes, thanks for following up my bug report!
>
> Quoting Francesco Poli (2020-05-06 19:40:37)
> > > did you get any further with this problem?
> >
> > Unfortunately, I failed to progress any further.
>
> I uploaded a new mmdebstrap version.
>
> I am using the attached script to build my own autopkgtest qemu images and it
> works fine for me. Maybe you want to try again?
I have just retried with my script (which seems to do the same things as yours,
except that it does set the unshare mode, since I have
kernel.unprivileged_userns_clone = 0).
Unfortunately, I still see the same guestfish error:
I: automatically chosen mode: fakechroot
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using ${HOME}/Downloads/TEST/mmdebstrap.Cd9NV53RA7 as tempdir
[...]
I: creating tarball...
I: done
I: removing tempdir ${HOME}/Downloads/TEST/mmdebstrap.Cd9NV53RA7...
I: success in 107.2860 seconds
libguestfs: error: /usr/bin/supermin exited with error status 1.
To see full error messages you may need to enable debugging.
Do:
export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again. For further information, read:
http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
You can also run 'libguestfs-test-tool' and post the *complete* output
into a bug report or message to the libguestfs mailing list.
Once again, the .qcow2 image is tiny and the .img does not boot with
$ qemu-system-x86_64 -enable-kvm -m 512 \
-serial unix:/tmp/ttyS0,server,nowait -drive \
"file=./debian-unstable.img,format=raw,cache=unsafe,if=virtio,index=0"
After attempting all possible boot devices, including a network boot,
it bails out with "No bootable device" error message.
:-(
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpIdlH9TPXII.pgp
Description: PGP signature
Bug#969540: librust-directories-1-dev: short package description is too long
Package: librust-directories-1-dev Severity: normal Dear Maintainer, the short package description is not suitable to be shown on a single line because it is 341 characters long : "Tiny mid-level library that provides platform-specific standard locations of directories for config, cache and other data on Linux, Windows and macOS by leveraging the mechanisms defined by the XDG base/user directory specifications on Linux, the Known Folder API on Windows, and the Standard Directory guidelines on macOS - Rust source code" The policy says: "The single line synopsis should be kept brief—certainly under 80 characters." https://www.debian.org/doc/debian-policy/ch-binary.html#the-single-line-synopsis thanks for you work in Debian, Daniele
Bug#963980: bumblebee-nvidia: Bumblebee daemon reported: error: [XORG] (EE) Unable to locate/open config directory
from `/var/log/Xorg.8.log` [ 2486.434] (II) NVIDIA dlloader X Driver 450.66 Wed Aug 12 19:44:12 UTC 2020 [ 2486.434] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs [ 2486.435] (EE) No devices detected. [ 2486.435] (EE) Fatal server error: [ 2486.435] (EE) no screens found(EE) [ 2486.435] (EE) So maybe this latest 450.66 simply does not support my `GM107M [GeForce GTX 860M]`, or just because of some bug?
Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load
Hi Salvatore, meanwhile, Dell has replaced the mainboard of my laptop, and after that, both the USB over-current kernel messages and the kworker processes with high CPU load are gone. Many thanks for caring about my bug report! Best regards, Dirk. Am 29.08.20 um 11:26 schrieb Salvatore Bonaccorso: Hi Dirk, Thanks for testing that. On Sat, Aug 29, 2020 at 11:04:43AM +0200, Dirk Kostrewa wrote: Hi Salvatore, I have enabled the verbose debugging mode on the command line and have appended the first 5000 lines of the dmesg output to this e-mail, running the current kernel from the Buster backports with the two kworker processes with high CPU load present. After that, I have applied your patch to this kernel and rebooted with the patched kernel: 5.7.0-0.bpo.2-amd64 #1 SMP Debian 5.7.10-1~bpo10+1a~test (2020-08-28) x86_64 GNU/Linux With your patch applied, the two kworker processes with high CPU load completely disappeared! Unfortunately I suspect this indicates either a HW fault or a HW design error as stated in the found kernel-thread which was just uncovered by the mentioned kernel fix (which we temporarily reverted with the patch). I can try to ask Alan Stern. There might be a workaround workarble for you, the issue should disapear if you prevent the system to automatically try to suspend usb2 root hub (but you have the same on usb1 root hub). # echo on >/sys/bus/usb/devices/usb2/power/control will do that for the usb2 root hub. Regards, Salvatore
Bug#969537: elpa-pdf-tools-server: broken when compiled against libpoppler102
David Bremner writes: > Package: elpa-pdf-tools-server > Version: 0.90-3+b2 Here's a backtrace Program received signal SIGSEGV, Segmentation fault. 0x77e5951e in ?? () from /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 (gdb) bt #0 0x77e5951e in () at /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 #1 0x77ac284f in Gfx::opShowSpaceText(Object*, int) (this=0x555c3100, args=0x7fffddb0, numArgs=) at ./poppler/Object.h:411 #2 0x77ab8637 in Gfx::go(bool) (this=this@entry=0x555c3100, topLevel=topLevel@entry=true) at ./poppler/Gfx.cc:679 #3 0x77ab8b50 in Gfx::display(Object*, bool) (this=this@entry=0x555c3100, obj=obj@entry=0x7fffe0c0, topLevel=topLevel@entry=true) at ./poppler/Gfx.cc:640 #4 0x77b12652 in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) (this=0x555b6020, out=0x555c0be0, hDPI=, vDPI=, rotate=, useMediaBox=, crop=, sliceX=, sliceY=-1, sliceW=-1, sliceH=-1, printing=false, abortCheckCbk=0x0, abortCheckCbkData=0x0, annotDisplayDecideCbk= 0x0, annotDisplayDecideCbkData=0x0, copyXRef=false) at ./poppler/Page.cc:574 #5 0x77e4439c in () at /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 #6 0xee26 in image_render_page (pdf=, page=0x555bd440, width=, options=0x55589f18, do_render_annotaions=1) at epdfinfo.c:491 #7 0xf9ab in cmd_renderpage (ctx=0x7fffe3c8, args=) at epdfinfo.c:3100 #8 0xb33a in main (argc=, argv=) at epdfinfo.c:3689
Bug#968912: transition: perl 5.32
Control: forwarded -1 https://release.debian.org/transitions/html/perl-5.32.html Hi Dominic On 2020-08-23 19:25:19 +0100, Dominic Hargreaves wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-p...@lists.debian.org > > Hi, perl 5.32 has been in experimental since June and I think it's going > to be ready for sid/bullseye within the next month or so - this is the > version we expect to ship with bullseye (given the freeze in January). > > The main blockers at present are the perl-tk update (I've just > pinged #960863) and, indirectly, the ipv6-only build related problems > described in #964902. > > As usual the bugs are at > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.32-transition;users=debian-p...@lists.debian.org > > This is a somewhat early heads up, in case it's helpful to pencil us in, > but either way, we'll ping this bug again when the blockers are resolved. > > Ben file: > > title = "perl"; > is_affected = .depends ~ "libperl5.30|perlapi-5.30" | .depends ~ > "libperl5.32|perlapi-5.32"; > is_good = .depends ~ "libperl5.32|perlapi-5.32"; > is_bad = .depends ~ "libperl5.30|perlapi-5.30"; The transition tracker is now live. I've also added .pre-depends similar to the perl 5.30 tracker. Best -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#969539: ITP: golang-github-rakyll-magicmime -- Go bindings for libmagic to detect MIME types
Package: wnpp Severity: wishlist Owner: Jai Flack * Package name: golang-github-rakyll-magicmime Version : 0.1.0-1 Upstream Author : Jaana Dogan * URL : https://github.com/rakyll/magicmime * License : Apache-2.0 Programming Lang: Go Description : Go bindings for libmagic to detect MIME types golang-github-rakyll-magicmime-dev is a Go package which allows you to discover a file's mimetype by looking for magic numbers in its content. It could be used as a supplementary for Go's mime (http://golang.org/pkg/mime/) package which only interprets the file extension to detect mimetypes. Internally, it implements libmagic(3) (http://linux.die.net/man/3/libmagic) bindings. I intend to maintain this under the umbrella of the Go packaging team
Bug#969538: vips/ruby-vips: autopkgtest regression on arm64 and ppc64el
Source: vips Version: 8.10.0-1 Severity: serious Hello, your package regressed its testsuite on arm64 in Debian and Ubuntu (in Ubuntu also ppc64el, in Debian I didn't check but the failure is the same) https://ci.debian.net/packages/r/ruby-vips/testing/arm64/ ??? Checking Rubygems dependency resolution on ruby2.7 ??? GEM_PATH= ruby2.7 -e gem\ \"ruby-vips\" ??? Run tests for ruby2.7 from debian/ruby-tests.rake ??? mv lib .gem2deb.lib RUBYLIB=. GEM_PATH= ruby2.7 -S rake -f debian/ruby-tests.rake /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib/rspec/core/rake_task.rb:125: warning: deprecated Object#=~ is called on Array; it always returns nil /usr/bin/ruby2.7 -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.2/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/exe/rspec --pattern ./spec/\*\*/\*_spec.rb --backtrace -r ./spec/spec_helper.rb ./usr/lib/ruby/vendor_ruby/vips/object.rb:269: warning: Capturing the given block using Proc.new is deprecated; use `` instead /usr/lib/ruby/vendor_ruby/vips/object.rb:269: warning: Capturing the given block using Proc.new is deprecated; use `` instead ./usr/lib/ruby/vendor_ruby/vips/object.rb:269: warning: Capturing the given block using Proc.new is deprecated; use `` instead ../usr/lib/ruby/vendor_ruby/vips/object.rb:269: warning: Capturing the given block using Proc.new is deprecated; use `` instead /usr/lib/ruby/vendor_ruby/vips/object.rb:269: warning: Capturing the given block using Proc.new is deprecated; use `` instead ..F Failures: 1) Vips::Image can dilate Failure/Error: expect(im.getpoint(11, 12)).to eq([255]) expected: [255] got: [0.0] (compared using ==) # /usr/share/rubygems-integration/all/gems/rspec-support-3.9.2/lib/rspec/support.rb:97:in `block in ' # /usr/share/rubygems-integration/all/gems/rspec-support-3.9.2/lib/rspec/support.rb:106:in `notify_failure' # /usr/share/rubygems-integration/all/gems/rspec-expectations-3.9.0/lib/rspec/expectations/fail_with.rb:35:in `fail_with' # /usr/share/rubygems-integration/all/gems/rspec-expectations-3.9.0/lib/rspec/expectations/handler.rb:38:in `handle_failure' # /usr/share/rubygems-integration/all/gems/rspec-expectations-3.9.0/lib/rspec/expectations/handler.rb:50:in `block in handle_matcher' # /usr/share/rubygems-integration/all/gems/rspec-expectations-3.9.0/lib/rspec/expectations/handler.rb:27:in `with_matcher' # /usr/share/rubygems-integration/all/gems/rspec-expectations-3.9.0/lib/rspec/expectations/handler.rb:48:in `handle_matcher' # /usr/share/rubygems-integration/all/gems/rspec-expectations-3.9.0/lib/rspec/expectations/expectation_target.rb:65:in `to' # ./spec/image_spec.rb:477:in `block (2 levels) in ' # /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:257:in `instance_exec' # /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:257:in `block in run' # /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:503:in `block in with_around_and_singleton_context_hooks' # /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:460:in `block in with_around_example_hooks' # /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib/rspec/core/hooks.rb:472:in `block in run' # /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib/rspec/core/hooks.rb:610:in `run_around_example_hooks_for' # /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib/rspec/core/hooks.rb:472:in `run' # /usr/share/rubygems-integration/all/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:460:in `with_around_example_hooks' #
Bug#969537: elpa-pdf-tools-server: broken when compiled against libpoppler102
Package: elpa-pdf-tools-server Version: 0.90-3+b2 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Here's a script to reproduce the segfault (path needs adjusting, must be absolute). I suspect any pdf will be the same, but I will attach the pdf in question. I say grave because this is the first command sent by the emacs package elpa-pdf-tools to verify the server is working. /usr/bin/epdfinfo < wt8.pdf Description: Adobe PDF document
Bug#969535: RFS: golang-github-rickb777-plural/1.0-1 [ITP] -- Simple Go API for Pluralisation
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-rickb777-plural": * Package name: golang-github-rickb777-plural Version : 1.2.1-1~exp1 Upstream Author : https://github.com/rickb777/plural/issues * URL : https://github.com/rickb777/plural * License : BSD-3-clause * Vcs : https://salsa.debian.org/pkg-deepin-team/golang-github-rickb777-plural Section : devel It builds those binary packages: golang-github-rickb777-plural-dev - Simple Go API for Pluralisation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-rickb777-plural/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-rickb777-plural/golang-github-rickb777-plural_1.2.1-1~exp1.dsc Changes for the initial release: golang-github-rickb777-plural (1.2.1-1~exp1) experimental; urgency=medium . * New upstream release. Regards, -- Arun Kumar Pariyar
Bug#969504: Screenshot
Screenshot after: mv ~/.mozilla ~/.mozilla-backup So with a clean config. https://vandervlis.nl/screenshot.png -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Bug#969254: i3-save-tree: Can't locate AnyEvent/I3.pm in @INC (you may need to install the AnyEvent::I3 module)
Package: i3 Version: 4.18-1 Followup-For: Bug #969254 Thank for the anwser Michael, first I confirm that by installing "libanyevent-i3-perl" the feature on i3-save-tree works as expected. My question/issue/claim was more: wouldn't be better to change "libanyevent-i3-perl" to be a requirement for "i3-save-tree" (instead of only a recomendation) ? otherwise, and IMHO, ins't directly usable as expected (the user need to install the lib explicitly). Or is the default behaviour for packages the installation of recommended packages (and thus me deviating from standard ? as you suggested ? ) From here on i'm ok I you prefer to close the issue. Thanks so far ! Regards, xiscu -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (10, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages i3 depends on: ii i3-wm 4.18-1 Versions of packages i3 recommends: pn dunst ii i3lock 2.11.1-1 ii i3status2.13-3 ii suckless-tools 45-1 i3 suggests no packages. -- no debconf information
Bug#969533: sqlobject autopkg test failure
Package: src:sqlobject
Version: 3.8.0+dfsg-1
Severity: serious
Tags: sid bullseye
seen in unstable:
autopkgtest [10:33:40]: test testdb-setuptools: [---
running develop
running egg_info
creating testlib.egg-info
writing testlib.egg-info/PKG-INFO
writing dependency_links to testlib.egg-info/dependency_links.txt
writing entry points to testlib.egg-info/entry_points.txt
writing requirements to testlib.egg-info/requires.txt
writing top-level names to testlib.egg-info/top_level.txt
writing manifest file 'testlib.egg-info/SOURCES.txt'
reading manifest file 'testlib.egg-info/SOURCES.txt'
writing manifest file 'testlib.egg-info/SOURCES.txt'
running build_ext
Creating /tmp/tmp.lmNqOQs2qz/rundir3/testlib.egg-link (link to .)
Adding testlib 0.0.1 to easy-install.pth file
Installing testdb script to /tmp/tmp.lmNqOQs2qz/rundir3
Installed /tmp/tmp.lmNqOQs2qz/mypkg
Processing dependencies for testlib==0.0.1
Searching for SQLObject==3.8.0
Best match: SQLObject 3.8.0
Adding SQLObject 3.8.0 to easy-install.pth file
Using /usr/lib/python3/dist-packages
Searching for FormEncode==1.3.1
Best match: FormEncode 1.3.1
Adding FormEncode 1.3.1 to easy-install.pth file
Using /usr/lib/python3/dist-packages
Finished processing dependencies for testlib==0.0.1
Traceback (most recent call last):
File "./testdb", line 33, in
sys.exit(load_entry_point('testlib', 'console_scripts', 'testdb')())
File "./testdb", line 22, in importlib_load_entry_point
for entry_point in distribution(dist_name).entry_points
File "/usr/lib/python3.8/importlib/metadata.py", line 504, in distribution
return Distribution.from_name(distribution_name)
File "/usr/lib/python3.8/importlib/metadata.py", line 177, in from_name
raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: testlib
autopkgtest [10:33:40]: test testdb-setuptools: ---]
autopkgtest [10:33:40]: test testdb-setuptools: - - - - - - - - - - results - -
- - - - - - - -
testdb-setuptoolsFAIL non-zero exit status 1
autopkgtest [10:33:41]: test testdb-setuptools: - - - - - - - - - - stderr - -
- - - - - - - -
Traceback (most recent call last):
File "./testdb", line 33, in
sys.exit(load_entry_point('testlib', 'console_scripts', 'testdb')())
File "./testdb", line 22, in importlib_load_entry_point
for entry_point in distribution(dist_name).entry_points
File "/usr/lib/python3.8/importlib/metadata.py", line 504, in distribution
return Distribution.from_name(distribution_name)
File "/usr/lib/python3.8/importlib/metadata.py", line 177, in from_name
raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: testlib
Bug#969534: ffc autopkg test failure
Package: src:ffc Version: 2019.2.0~git20200123.6b621eb-2 Severity: serious Tags: sid bullseye seen in unstable: autopkgtest [10:34:13]: test test-ffc: [--- running install running bdist_egg running egg_info creating fenics_ffc_factory.egg-info writing fenics_ffc_factory.egg-info/PKG-INFO writing dependency_links to fenics_ffc_factory.egg-info/dependency_links.txt writing top-level names to fenics_ffc_factory.egg-info/top_level.txt writing manifest file 'fenics_ffc_factory.egg-info/SOURCES.txt' reading manifest file 'fenics_ffc_factory.egg-info/SOURCES.txt' writing manifest file 'fenics_ffc_factory.egg-info/SOURCES.txt' installing library code to build/bdist.linux-x86_64/egg running install_lib running build_ext creating tmp x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.8 -c /tmp/tmpsyqpzq35.cpp -o tmp/tmpsyqpzq35.o -std=c++14 x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.8 -c /tmp/tmpxavabf_a.cpp -o tmp/tmpxavabf_a.o -fvisibility=default building 'ffc_factory' extension creating build creating build/temp.linux-x86_64-3.8 x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/lib/python3/dist-packages/ffc/backends/ufc -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/include/python3.8 -c interface.cpp -o build/temp.linux-x86_64-3.8/interface.o -DVERSION_INFO="0.0.1" -std=c++14 -fvisibility=default x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/lib/python3/dist-packages/ffc/backends/ufc -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/include/python3.8 -c dofmap.cpp -o build/temp.linux-x86_64-3.8/dofmap.o -DVERSION_INFO="0.0.1" -std=c++14 -fvisibility=default x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/lib/python3/dist-packages/ffc/backends/ufc -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/include/python3.8 -c finite_element.cpp -o build/temp.linux-x86_64-3.8/finite_element.o -DVERSION_INFO="0.0.1" -std=c++14 -fvisibility=default x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/lib/python3/dist-packages/ffc/backends/ufc -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/include/python3.8 -c finite_element_bindings.cpp -o build/temp.linux-x86_64-3.8/finite_element_bindings.o -DVERSION_INFO="0.0.1" -std=c++14 -fvisibility=default creating build/lib.linux-x86_64-3.8 x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.8/interface.o build/temp.linux-x86_64-3.8/dofmap.o build/temp.linux-x86_64-3.8/finite_element.o build/temp.linux-x86_64-3.8/finite_element_bindings.o -o build/lib.linux-x86_64-3.8/ffc_factory.cpython-38-x86_64-linux-gnu.so creating build/bdist.linux-x86_64 creating build/bdist.linux-x86_64/egg copying build/lib.linux-x86_64-3.8/ffc_factory.cpython-38-x86_64-linux-gnu.so -> build/bdist.linux-x86_64/egg creating stub loader for ffc_factory.cpython-38-x86_64-linux-gnu.so byte-compiling build/bdist.linux-x86_64/egg/ffc_factory.py to ffc_factory.cpython-38.pyc creating build/bdist.linux-x86_64/egg/EGG-INFO copying fenics_ffc_factory.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO copying fenics_ffc_factory.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO copying fenics_ffc_factory.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO copying
Bug#962627: eboard: playing against crafty causes "*** buffer overflow detected ***: eboard terminated"
Dear Maintainer, this buffer is caused by a variable of length 256 being snprintf'ed to with a length of 512. This got fixed upstream in [1] and was also reported here [2]. This issue is visible in the build log [3] with this warning: at proto_xboard.cc:1086:13: ... specified bound 512 exceeds destination size 256 ... There is another location in the build log with a similar warning: at util.cc:785:15: ...specified bound 1024 exceeds destination size 280 ... Kind regards, Bernhard [1] https://github.com/fbergo/eboard/commit/ed33049aff2cefd7508bcda8ab738b8ec871c948 [2] https://bugs.launchpad.net/ubuntu/+source/eboard/+bug/1306419 [3] https://buildd.debian.org/status/fetch.php?pkg=eboard=amd64=1.1.3-0.3=1558101455=0 (rr) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7fd306ea0537 in __GI_abort () at abort.c:79 #2 0x7fd306ef9828 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fd307007c28 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x7fd306f88712 in __GI___fortify_fail (msg=msg@entry=0x7fd307007bbe "buffer overflow detected") at fortify_fail.c:26 #4 0x7fd306f87110 in __GI___chk_fail () at chk_fail.c:28 #5 0x7fd306f86d45 in ___snprintf_chk (s=s@entry=0x557098bb5664 "~/.eboard/eng-out", maxlen=maxlen@entry=512, flag=flag@entry=1, slen=slen@entry=256, format=format@entry=0x557097beb6bc "%s/.eboard/craftylog") at snprintf_chk.c:29 #6 0x557097bd3a8c in snprintf (__fmt=0x557097beb6bc "%s/.eboard/craftylog", __n=512, __s=0x557098bb5664 "~/.eboard/eng-out") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:67 #7 CraftyProtocol::readDialog() (this=0x557098bb5410) at proto_xboard.cc:1086 #8 0x557097bd3780 in XBoardProtocol::run() (this=0x557098bb5410) at proto_xboard.cc:450 ... # Bullseye/testing amd64 qemu VM 2020-09-04 apt update apt dist-upgrade apt install systemd-coredump lightdm xserver-xorg openbox xterm ccache cmake make g++-multilib gdb pkg-config coreutils python3-pexpect manpages-dev git ninja-build capnproto libcapnp-dev fakeroot mc gdb eboard eboard-dbgsym libgtk2.0-0-dbgsym libglib2.0-0-dbgsym apt build-dep eboard reboot echo 1 > /proc/sys/kernel/perf_event_paranoid mkdir /home/benutzer/source/rr/git -p cd/home/benutzer/source/rr/git git clone https://github.com/mozilla/rr.git cd cd /home/benutzer/source/rr/git/ mkdir obj && cd obj cmake ../rr make -j4 mkdir /home/benutzer/source/eboard/orig -p cd/home/benutzer/source/eboard/orig apt source eboard cd export DISPLAY=:0 /home/benutzer/source/rr/git/obj/bin/rr eboard /home/benutzer/source/rr/git/obj/bin/rr replay /home/benutzer/.local/share/rr/eboard-1 set width 0 set pagination off directory /home/benutzer/source/eboard/orig/eboard-1.1.3 cont benutzer@debian:~$ /home/benutzer/source/rr/git/obj/bin/rr eboard rr: Saving execution to trace directory `/home/benutzer/.local/share/rr/eboard-1'. *** buffer overflow detected ***: terminated Abgebrochen benutzer@debian:~$ /home/benutzer/source/rr/git/obj/bin/rr replay /home/benutzer/.local/share/rr/eboard-1 ... (rr) cont Continuing. *** buffer overflow detected ***: terminated Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (rr) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7fd306ea0537 in __GI_abort () at abort.c:79 #2 0x7fd306ef9828 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fd307007c28 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x7fd306f88712 in __GI___fortify_fail (msg=msg@entry=0x7fd307007bbe "buffer overflow detected") at fortify_fail.c:26 #4 0x7fd306f87110 in __GI___chk_fail () at chk_fail.c:28 #5 0x7fd306f86d45 in ___snprintf_chk (s=, maxlen=, flag=, slen=, format=) at snprintf_chk.c:29 #6 0x557097bd3a8c in ?? () #7 0x557097bd3780 in ?? () #8 0x557097bab471 in ?? () #9 0x7fd3074a6fd2 in g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x7fd3074ba784 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x7fd3074c554f in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x7fd3074c5edf in g_signal_emit () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x7fd307e5e7ba in gtk_widget_activate () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #14 0x7fd307d59eed in gtk_menu_shell_activate_item () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #15 0x7fd307d5a1b9 in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #16 0x7fd307d47a8b in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #17 0x7fd3074a6fd2 in g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x7fd3074b9f06 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #19
Bug#969291: RFS: sane-backends/1.0.31-1~experimental1 [RC] -- API library for scanners [transitional package]
Hello, I'd like to see this new upstream release in sid so I'm taking a look but I'm quite surprised by many things. And actually I want this fix in the package too: https://gitlab.com/sane-project/backends/-/merge_requests/502 First of all, why is this packaging git repository not hosted on salsa.debian.org? I can create you a repository in the "debian" namespace and grant you commit rights on this repository. It would make it easier for random DD to help you out. Then, why is this in experimental ? I saw you switched from "libsane" to "libsane1". This was not really warranted, the lintian warning that you fixed with this rename was harmless and you should consider the cost to update all the reverse build dependencies (and there are quite a few). However now that you have added the transitional package and that you are already gone through NEW, I guess it's ok to push this to completion. I saw many numbered patches in debian/patches/ but the number does not indicate the order in which they are applied. Thus I'd suggest to drop the numbering entirely. And a few of them are likely worth forwarding to the upstream developers... I see "Forwarded: not needed" on patches that should be forwarded IMO. Looking at your history on this package, have you considered asking for the Debian Maintainer status so that you can upload that package on your own? Cheers, On Sun, 30 Aug 2020, Jörg Frings-Fürst wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Package: sponsorship-requests > Severity: important > > Dear mentors, > > I am looking for a sponsor for my package "sane-backends": > >Package name: sane-backends >Version : 1.0.31-1~experimental1 >Upstream Author : [fill in name and email of upstream] >URL : http://www.sane-project.org >License : GPL-3+, GPL-2+ with sane exception, Artistic, GFDL-1.1, > GPL-2+, LGPL-2.1+, GPL-2 >Vcs : https://jff.email/cgit/sane-backends.git >Section : graphics > > It builds those binary packages: > > libsane - API library for scanners [transitional package] > libsane-dev - API development library for scanners [development files] > libsane1 - API library for scanners > libsane-common - API library for scanners -- documentation and support files > sane-utils - API library for scanners -- utilities > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/sane-backends/ > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.31-1~experimental1.dsc > > or from > > git > https://jff.email/cgit/sane-backends.git?h=release%2Fdebian%2F1.0.31-1_experimental1 > > Changes since the last upload: > > sane-backends (1.0.31-1~experimental1) experimental; urgency=medium > . >* New upstream release (Closes: #968949, #962539). >* Add back libsane transitional package, to ease upgrades (Closes: > #962936): > - debian/control: Add package libsane as oldlibs. >Thanks to Gianfranco Costamagna . >* debian/copyright: > - Fix lintian *-globbing-patterns errors. > - Refresh to the new upstream release. >* Convert debian/po/de.po to utf-8. >* New patches: > - debian/patches/0045-disable_lock_test_at_build_time.patch > - debian/patches/0050-Use-python3-shebang.patch > - debian/patches/0055-Fix_build_error.patch >* debian/rules: > - Use --enable-locking instead --disable-locking. >* debian/control: > - Add libpoppler-glib-dev to Build-Depends. > - Add ipp-usb to libsane1 Recommends (Closes: #968953). >* debian/libsane1.symbols: > - Remove 7 not longer available symbols. >* debian/saned@.service: > - Switch Standard[Output|Error] from syslog to append:/var/log/saned.log. > - New debian/sane-utils.logrotate to pack and remove old logs. >* debian/libsane-common.lintian-overrides: > - Rename tags. >* debian/patches/0125-multiarch_dll_search_path.patch: > - Add $(prefix)/lib64/sane to lib search path (Closes: #931297). >* Fix FTCBFS: (Closes: #948711) > - 0060-cross.patch: Make gphoto2 detection use the host architecture >pkg-config. > - Build tools/sane-desc for the build architecture. > - Thanks to Helmut Grohne . >* Remove files no longer needed: > - debian/saned.socket > - debian/saned@.service > > CU > Jörg > > - -- > New: > GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D > GPG key (long) : 09F89F3C8CA1D25D > GPG Key: 8CA1D25D > CAcert Key S/N : 0E:D4:56 > > Old pgp Key: BE581B6E (revoked since 2014-12-31). > > Jörg Frings-Fürst > D-54470 Lieser > > > git: https://jff.email/cgit/ > > Threema: SYR8SJXB > Wire: @joergfringsfuerst > Skype:joergpenguin > Ring: jff >
Bug#969532: ITP: joypy -- ridgeline-/joyplots plotting routine
Package: wnpp Severity: wishlist Subject: ITP: joypy -- ridgeline-/joyplots plotting routine Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: joypy Version : 0.2.2 Upstream Author : Leonardo Taccari * URL : https://github.com/sbebo/joypy * License : MIT Programming Lang: Python Description : ridgeline-/joyplots plotting routine JoyPy is a one-function Python package based on matplotlib + pandas with a single purpose: drawing joyplots (a.k.a. ridgeline plots). Joyplots are stacked, partially overlapping density plots. They are a nice way to plot data to visually compare distributions, especially those that change across one dimension (e.g., over time). Though hardly a new technique, they have become very popular lately thanks to the R packages ggridges and ggjoy. Remark: This package is maintained by Debian Python Modules Team at https://salsa.debian.org/python-team/modules/joypy
Bug#963290: re: e-antic: FTBFS: ../e-antic/e-antic.h:24:2: error: #error FLINT 2.5.2 or 2.5.3 required
control: tags -1 patch pending Hello, I changed a little bit the changelog, removed the useless patch and uploaded to sid! G. On Thu, 27 Aug 2020 19:46:28 +0100 peter green wrote: > tags 963290 +patch > thanks > > I just took a look at this issue. > > First I did some digging in the upstream git repo. Once I figured out their > branch structure (the "master0" branch is > apparently where current releases are made from) I was able to find two > relavent commits. > 10ed02f429f75a418ee41814af2dffc8cd41101f which added support for flint 2.6.0 > and cebabe52632013a70be321d590301e06c306a766 > which removed the upper limit on the flint version. > > I applied these to the Debian package, in the process I found that > 10ed02f429f75a418ee41814af2dffc8cd41101f conflicted > with the existing debian patch upstream-fix-sprintf_buffer_overflow.patch, > following the upstream issue report link > for that patch lead to a claim the issue was fixed as part of > 10ed02f429f75a418ee41814af2dffc8cd41101f so I removed > upstream-fix-sprintf_buffer_overflow.patch from the series. > > Next I ran into an issue with a test failing to build because it could not > find the newly added > EANTIC_FIXED_fmpq_poly_add_fmpq symbol. I added the symbol to the version > script. > > The final issue I ran into was that some symbols had disappeared. > > +#MISSING: 0.1.5+ds-2+rpi1# > EANTIC_FIXED_fmpq_poly_get_str_pretty@LIBEANTIC_0_1_2 0.1.2 > +#MISSING: 0.1.5+ds-2+rpi1# > _EANTIC_FIXED_fmpq_poly_get_str_pretty@LIBEANTIC_0_1_2 0.1.2 > +#MISSING: 0.1.5+ds-2+rpi1# _nf_elem_mod_fmpz@LIBEANTIC_0_1_2 0.1.2 > +#MISSING: 0.1.5+ds-2+rpi1# nf_elem_mod_fmpz@LIBEANTIC_0_1_2 0.1.2 > +#MISSING: 0.1.5+ds-2+rpi1# nf_elem_mod_fmpz_den@LIBEANTIC_0_1_2 0.1.2 > > I searched for EANTIC_FIXED_fmpq_poly_get_str_pretty and nf_elem_mod_fmpz on > the > codesearch.debian.net website . I also installed all the reverse-dependencies > listed on the autoremoval list and then grepped in /usr/lib and /usr/bin . > With the source search the only references I found were in the e-antic > source package. With the binary search the only references I found were > in libeantic.so.0.1.5 and libeantic.a. As such I decided it was probably > ok to remove the symbols from the symbols file and went ahead and updated > the symbols file. > > With that I was able to get a successful build in Raspbian bullseye-staging > and I have uploaded the package to Raspbian. A debdiff should appear soon > at https://debdiffs.raspbian.org/main/e/e-antic > > diff -Nru e-antic-0.1.5+ds/debian/changelog e-antic-0.1.5+ds/debian/changelog --- e-antic-0.1.5+ds/debian/changelog 2020-05-19 14:45:32.0 +0200 +++ e-antic-0.1.5+ds/debian/changelog 2020-08-27 17:59:03.0 +0200 @@ -1,3 +1,26 @@ +e-antic (0.1.5+ds-2.1) unstable; urgency=medium + + [ Gianfranco Costamagna ] + * Non-maintianer upload + + [ Peter Michael Green ] + * Fix build with flint 2.6.3 (Closes: 963290 ) ++ Apply upstream commit 10ed02f429f75a418ee41814af2dffc8cd41101f + as debian/patches/flint-2.6.0.patch to support flint 2.6.0 ++ Apply upstream commit cebabe52632013a70be321d590301e06c306a766 + as debian/patches/remove-flint-upperlimit.patch to allow builds + with newer flint versions. ++ Disable debian/patches/upstream-fix-sprintf_buffer_overflow.patch + it conflicts with the flint 2.6.0 patch and according to + https://github.com/videlec/e-antic/pull/92 the issue it addresses + was fixed as part of that patch. ++ Add EANTIC_FIXED_fmpq_poly_add_fmpq to libeantic.map in + upstream-libtool-version_script.patch ++ Update symbols file, removed symbols do not appear to be + used by any other packages in Debian. + + -- Peter Michael Green Thu, 27 Aug 2020 15:59:03 + + e-antic (0.1.5+ds-2) unstable; urgency=medium * Serious fix release, revert symbols (Closes: #960614, #960875). diff -Nru e-antic-0.1.5+ds/debian/libeantic0.symbols e-antic-0.1.5+ds/debian/libeantic0.symbols --- e-antic-0.1.5+ds/debian/libeantic0.symbols 2020-05-19 14:40:01.0 +0200 +++ e-antic-0.1.5+ds/debian/libeantic0.symbols 2020-08-27 17:59:03.0 +0200 @@ -1,8 +1,7 @@ libeantic.so.0 libeantic0 #MINVER# * Build-Depends-Package: libeantic-dev - EANTIC_FIXED_fmpq_poly_get_str_pretty@LIBEANTIC_0_1_2 0.1.2 + EANTIC_FIXED_fmpq_poly_add_fmpq@LIBEANTIC_0_1_2 0.1.5+ds-2+rpi1 LIBEANTIC_0_1_2@LIBEANTIC_0_1_2 0.1.2 - _EANTIC_FIXED_fmpq_poly_get_str_pretty@LIBEANTIC_0_1_2 0.1.2 _fmpq_poly_resultant_div@LIBEANTIC_0_1_2 0.1.2 _fmpq_vec_fprint@LIBEANTIC_0_1_2 0.1.2 _fmpq_vec_randtest_uniq_sorted@LIBEANTIC_0_1_2 0.1.2 @@ -33,7 +32,6 @@ _nf_elem_get_nmod_poly@LIBEANTIC_0_1_2 0.1.2 _nf_elem_inv@LIBEANTIC_0_1_2 0.1.2 _nf_elem_invertible_check@LIBEANTIC_0_1_2 0.1.2 - _nf_elem_mod_fmpz@LIBEANTIC_0_1_2 0.1.2 _nf_elem_mul@LIBEANTIC_0_1_2 0.1.2 _nf_elem_mul_red@LIBEANTIC_0_1_2 0.1.2 _nf_elem_norm@LIBEANTIC_0_1_2 0.1.2 @@ -114,8 +112,6 @@
Bug#969531: avahi-daemon: retrieving printer info blocks printing until shutdown
Package: avahi-daemon Version: 0.8-3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** OKI printer B432, conected via USB, no network cable attached. * What led up to the situation? Want to print * What exactly did you do (or not do) that was effective (or ineffective)? select document, start print dialog, select my printer (config was done via CUPS); Now the printer appears a second time in the list with a different entry. If I select this new entry, I am asked for CUPS PW twice, then it (a deamon, whatever) starts retriving printer info which *never* completes. * What was the outcome of this action? Either way, selecting my own entry or the new one made by the daemon, the printer does nothing (I waited up to 45 minutes... until I shutdown my system. Them during shutdown, there is a pause during which the document gets printed. * What outcome did you expect instead? I want the printer to print after I sent the job. *** End of the template - remove these template lines *** There is a workaround: In the original /etc/avahi/avahi-daemon.conf file, there is an entry "#allow- interfaces=eth0". Changing and uncommenting it to "allow-interfaces=eth9" solves the problem (printer not conected via ethXYZ, though). Therefor I assume this hides a bug or an improper default configuration. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.5-towo.3-siduction-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages avahi-daemon depends on: ii adduser 3.118 ii bind9-host [host]1:9.16.6-2 ii dbus 1.12.20-1 ii init-system-helpers 1.58 ii libavahi-common3 0.8-3 ii libavahi-core7 0.8-3 ii libc62.31-3 ii libcap2 1:2.43-1 ii libdaemon0 0.14-7+b1 ii libdbus-1-3 1.12.20-1 ii libexpat12.2.9-1 ii lsb-base 11.1.0 Versions of packages avahi-daemon recommends: ii libnss-mdns 0.14.1-1 Versions of packages avahi-daemon suggests: pn avahi-autoipd -- Configuration Files: /etc/avahi/avahi-daemon.conf changed: [server] use-ipv4=yes use-ipv6=yes allow-interfaces=eth9 ratelimit-interval-usec=100 ratelimit-burst=1000 [wide-area] enable-wide-area=yes [publish] publish-hinfo=no publish-workstation=no [reflector] [rlimits] -- no debconf information
Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]
Hello Oliver, Am 04.09.20 um 09:44 schrieb SerNet Support Oliver Seufer: > Hello Markus, > > This is Oliver. I just did some more troubleshooting and I found the error > message in the debug logfile: > kid1| 23,3| url.cc(471) urlParse: urlParse: Split URL 'http://:0' into > proto='http', host='', port='0', path='/' > kid1| 23,3| url.cc(492) urlParse: urlParse: Invalid port '0' [...] So my initial thought is that squid works correctly in this case. This is the header which squid needs to parse. ICAP/1.0 200 OK ISTag: "10017;4140202;836248;8189206" Server: AVIRA ICAP (1.21.1.61) X-Response-Info: Clean Encapsulated: req-hdr=0, null-body=215 HEAD http://:0 HTTP/1.0 User-Agent: w3m/0.5.3+git20170102 Accept: text/html, text/*;q=0.5, image/*, application/*, message/* Accept-Language: en;q=1.0 Host: www.sernet.de Accept-Encoding: gzip,bzip2,deflate The HEAD http://:0 HTTP/1.0 is weird. It starts with the http protocol but there is no domain name and port 0 obviously does not exist. This probably used to work because the squid3 parser was less strict before. I would try to change the output of your AVIRA server. Is there a reason why it has to send this specific HEAD line in the first place and can you modify it? Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#892423: groff: Lintian crashes host for some Asian-language manual pages
Hi, In archive-wide Lintian runs, this issue occurred in the following binary packages. apt_2.1.10_amd64.deb dos2unix_7.4.1-1_amd64.deb manpages-zh_1.6.3.4-1_all.deb mplayer_1.3.0-8+b9_amd64.deb wesnoth-1.14-core_1.14.13-1_amd64.deb A sample command is: man --warnings -E UTF-8 -l -Tutf8 -Z mplayer/usr/share/man/zh_CN/man1/mplayer.1.gz but the screen width must be 80 or smaller to reproduce. Jakub Wilk suggested the minimal code below to reproduce the issue. When the troff subprocess is not killed in a timely manner (within six to ten hours), it will consume all of the host machine's I/O buffers and cause a kernel panic. It was observed several times over the past two weeks. Lintian triaged the issue by setting the value to 120 in this commit, but the change should probably be reverted when this bug is fixed: https://salsa.debian.org/lintian/lintian/-/commit/5be6bd66a9f52872615ef32d234b6d616fd5fa49 The credit for tracking down the issue to groff and suggesting a fix belongs to Jakub Wilk. Thanks! Kind regards Felix Lechner * * * $ mkdir -p usr/share/man/ja/man5 $ printf '\343\201\210\343\201\260\343\200\201.lcs.mit.edu_debian_dists_unstable_contrib_binary\\-i386_Release \n' > usr/share/man/ja/man5/test.5 $ MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8 -Z usr/share/man/ja/man5/test.5 > /dev/null troff: :1: warning [p 1, 0.0i]: cannot adjust line [hangs indefinitely]
Bug#969530: rsync: CVE-2020-14387
Source: rsync Version: 3.2.3-2 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 3.2.0-1 Hi, The following vulnerability was published for rsync. CVE-2020-14387[0]: | rsync-ssl does not verify the hostname in the server certificate | when using openssl If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-14387 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14387 [1] https://git.samba.org/?p=rsync.git;a=commitdiff;h=c3f7414c450faaf6a8281cc4a4403529aeb7d859 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1875549 Regards, Salvatore
Bug#969526: negotiate_kerberos_auth: Kerberos auth helper broken with error: "Invalid base64 token" after upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u3
Control: tags -1 confirmed pending Hello Joel, Am 04.09.20 um 11:53 schrieb Joel K.: > Package: squid > Version: 3.5.23-5+deb9u3 > Severity: important > > > After upgrading from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u3 the > negotiate_kerberos_auth helper is completely broken. The Kerberos code contained a typo this is why you see error messages like BH Invalid negotiate request token You can use my updated packages from https://people.debian.org/~apo/lts/squid3/stretch/ in the meantime. New official packages will follow soon. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#936941: found 936941 in 2.9.10+dfsg-2
On Wed, Jun 24, 2020 at 03:18:18PM +0200, Mattia Rizzolo wrote: > On Tue, Jun 23, 2020 at 10:58:17PM +0200, Moritz Mühlenhoff wrote: > > With the removal of gnome-doc-utils the only remaining rdep of > > python-libxml2 > > is gone (apart from src:chirp, but it's already uninstallable for various > > other > > packages which have dropped Py2 support, so can be safely ignored). > > There is also gimp-help still there, with a B-D-I on pyhon-libxml2. > What about that? gimp-help has been fixed in 2.10.0-1 Cheers, Moritz
Bug#969529: libxml2: CVE-2020-24977
Source: libxml2 Version: 2.9.10+dfsg-5 Severity: important Tags: security upstream Forwarded: https://gitlab.gnome.org/GNOME/libxml2/-/issues/178 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for libxml2. CVE-2020-24977[0]: | GNOME project libxml2 v2.9.10 and earlier have a global Buffer | Overflow vulnerability in xmlEncodeEntitiesInternal at | libxml2/entities.c. The issue has been fixed in commit 8e7c20a1 | (20910-GITv2.9.10-103-g8e7c20a1). Please note that the CVE description looks missleading, because 8e7c20a1 is not the fixing commit, rather [1]. There is some upstream discussion but this appears to be really a issue for xmllint, and as well present before the bisected commit in the upstream issue. That said, it is marked no-dsa for buster still. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-24977 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977 [1] https://gitlab.gnome.org/GNOME/libxml2/-/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2 [2] https://gitlab.gnome.org/GNOME/libxml2/-/issues/178 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#969174: Fixed here [was Re: Bug#969174: firefox: FF80 seems to have
broken all add-ons on existing profiles] Message-Id: <20200904132941.cacb8887fd7ab7f486ccc...@6jf.be> In-Reply-To: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 04 Sep 2020 01:33:53 +0200 Christoph Anton Mitterer wrote: > On Thu, 2020-09-03 at 22:43 +0200, Ra=C3=BAl S=C3=A1nchez Siles wrote: > > Fortunately 80.0.1-1 came around and this bug has been somehow > > fixed or not exposed. This is what I can tell so far. Let me know if > > I can provide any more helpful information. >=20 > yes... that seems to fix it... Not on my system. I though it was fixed because just after the upgrade to FF 80.0.1-1, the extensions re-appeared. But at the second start, they were gone again. It is a bit the same behavior that with FF80.0.1. If you disable+re-enable the extensions, they are back. But they disappear after briefly appearing once you re-start FF. > Cheers, > Chris. Regards, Jean-Marc https://6jf.be/keys/ED863AD1.txt https://6jf.be/keys/ED0B8558.txt pgpRC1DJ2d8Hb.pgp Description: PGP signature
Bug#969528: lintian: odd-mark-in-description should exclude digit grouping (345,000)
Package: lintian Version: 2.93.0 Severity: normal Dear Maintainer, current lintian complains with odd-mark-in-description that there is a comma without tailing white space in the description of trans-de-en and dict-de-en (both from source package ding 1.8.1-9). Both descriptions contain the string "345,000 entries", where the comma is a decimal separator. From my point of view this should be excluded from the lintian warning, since decimal separators should be allowed... This issue was introduced with lintian 2.81.0 closing #591665 https://salsa.debian.org/lintian/lintian/-/commit/346d081ce3ca9739fc7fb5e82c212d0488dbfb83 Greetings Roland signature.asc Description: PGP signature
Bug#968965: [Pkg-xen-devel] Bug#968965: xen: FTBFS in sid
Hi Gianfranco, On 8/24/20 7:03 PM, Gianfranco Costamagna wrote: > Source: xen > Version: 4.11.4+24-gddaaccbbab-1 > Severity: serious > > Hello, looks like xen is FTBFS because of some bd-uninstallable python > package and a gcc-10 related build failure. Yes. Thanks for the report. Currently (actually, also today!) Ian Jackson and I are working on this. We want to have Xen 4.14 in Debian unstable, and the two big things that are needed are GCC 10 fixes and getting rid of python 2 usage. So, just to let you know it's known and being worked on. > gcc -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall > -Wstrict-prototypes -Wdeclaration-after-statement > -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 > -fomit-frame-pointer > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF > .tdb.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -g -O2 > -fdebug-prefix-map=/build/xen-4.11.4+24-gddaaccbbab=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -Werror -I. -include > /build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/config.h > -I./include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/evtchn/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libxc/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/toollog/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/foreignmemory/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/devicemodel/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -D__XEN_TOOLS__ > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/toolcore/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -DXEN_LIB_STORED="\"/var/lib/xenstored\"" > -DXEN_RUN_STORED="\"/var/run/xenstored\"" > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/gnttab/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include -c -o > tdb.o tdb.c > gcc -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall > -Wstrict-prototypes -Wdeclaration-after-statement > -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 > -fomit-frame-pointer > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF > .talloc.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -g -O2 > -fdebug-prefix-map=/build/xen-4.11.4+24-gddaaccbbab=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -Werror -I. -include > /build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/config.h > -I./include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/evtchn/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libxc/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/toollog/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/foreignmemory/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/devicemodel/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -D__XEN_TOOLS__ > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/toolcore/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include > -DXEN_LIB_STORED="\"/var/lib/xenstored\"" > -DXEN_RUN_STORED="\"/var/run/xenstored\"" > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/libs/gnttab/include > -I/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore/../../tools/include -c -o > talloc.o talloc.c > gcc xs_tdb_dump.o utils.o tdb.o talloc.o-Wl,-z,relro -Wl,-z,now -o > xs_tdb_dump > /usr/bin/ld: utils.o:./tools/xenstore/utils.h:27: multiple definition of > `xprintf'; xs_tdb_dump.o:./tools/xenstore/utils.h:27: first defined here > collect2: error: ld returned 1 exit status > make[6]: *** [Makefile:97: xs_tdb_dump] Error 1 > make[6]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab/tools/xenstore' > make[5]: *** [/build/xen-4.11.4+24-gddaaccbbab/tools/../tools/Rules.mk:253: > subdir-install-xenstore] Error 2 > make[5]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab/tools' > make[4]: *** [/build/xen-4.11.4+24-gddaaccbbab/tools/../tools/Rules.mk:248: > subdirs-install] Error 2 > make[4]: Leaving directory
Bug#969076: dpkg: Fails if package containing symlink to network FS is upgraded
Guillem Jover schrieb am Fr., 4. Sept. 2020, 00:28: > Hi! > > On Thu, 2020-08-27 at 09:19:52 +0200, Sven Mueller wrote: > > Package: dpkg > > Version: 1.19.7 > > Tags: patch > > > When a package contains a symlink that reaches into a filesystem that > can't > > be accessed by root (due to missing key, errno=ENOKEY), installation > works, > > removal works, but upgrade or reinstallation of the package doesn't work > > and fails because dpkg fails to stat the link target. > > OOC, why is a pathname that is reference by a .deb, within a > filesystem that currently has a missing key? > Think of Kerberos authenticated NFS. Root (especially in cron jobs) doesn't have a ticket with access to the link target. Most actual users of the system do have access. > > Patch attached, which fixes this issue, though I suspect other locations > > should possibly use a similar logic. > > > > As far as I understand (also mentioned in the header of the patch), this > is > > to avoid unpacking a link into a directory the link originally pointed > to. > > If that is the case, the patch should be fine, but I wonder if this > > shouldn't be handled differently. But I would need to dig into the code > > much more than I am comfortable with, given that this is C and I don't > > usually use C. _If_ dpkg unpacks the package into some temporary > directory > > first and then moves the files into place, then there should be other > > options to avoid the behavior mentioned. > > I'm not sure this is correct for the general case though, as that > makes the check inert, which seems wrong? > No, it is not inert. It covers the case the test wants to protect against: if the link target is a directory (as far as root is concerned), unpacking and archive containing anything that is intended to replace the symlink would instead unpacking into the directory the link points to. However if the link points to something root had no access to, unpacking behaves the same way as if the symlink was dangling (target doesn't exist). Which is also why I named the patch this way: on overwrite of the symlink, the kennel behaves the same way as if the target didn't even exist, so dpkg should do the same. Cheers, Sven >
