Bug#969403: powerdevil: Media players pause during screen powersave
Package: powerdevil Version: 4:5.14.5-1 Severity: normal Dear Maintainer, In System Settings -> Power Management -> Advanced Settings "Pause media players when suspending" is unchecked, however when the screen is turned off media players still pause. What should happen: When "Pause media players when suspending" enabled option is unchecked, when the screen is turned off in power-saving mode the media player should continue to play. -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) 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= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages powerdevil depends on: ii kio 5.54.1-1 ii libc62.28-10 ii libkf5activities55.54.0-1 ii libkf5auth5 5.54.0-2 ii libkf5completion55.54.0-1 ii libkf5configcore55.54.0-1+deb10u1 ii libkf5configgui5 5.54.0-1+deb10u1 ii libkf5configwidgets5 5.54.0-1 ii libkf5coreaddons55.54.0-1 ii libkf5crash5 5.54.0-1 ii libkf5dbusaddons55.54.0-1 ii libkf5globalaccel-bin5.54.0-1 ii libkf5globalaccel5 5.54.0-1 ii libkf5i18n5 5.54.0-1 ii libkf5kiowidgets55.54.1-1 ii libkf5networkmanagerqt6 5.54.0-1 ii libkf5notifyconfig5 5.54.0-1 ii libkf5service-bin5.54.0-1 ii libkf5service5 5.54.0-1 ii libkf5solid5 5.54.0-1 ii libkf5waylandclient5 4:5.54.0-1 ii libkf5widgetsaddons5 5.54.0-1 ii libkworkspace5-5 4:5.14.5.1-1 ii libpowerdevilcore2 4:5.14.5-1 ii libpowerdevilui5 4:5.14.5-1 ii libqt5core5a 5.11.3+dfsg1-1+deb10u3 ii libqt5dbus5 5.11.3+dfsg1-1+deb10u3 ii libqt5gui5 5.11.3+dfsg1-1+deb10u3 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u3 ii libqt5x11extras5 5.11.3-2 ii libstdc++6 8.3.0-6 ii libudev1 241-7~deb10u4 ii libxcb-dpms0 1.13.1-2 ii libxcb-randr01.13.1-2 ii libxcb1 1.13.1-2 ii powerdevil-data 4:5.14.5-1 powerdevil recommends no packages. powerdevil suggests no packages. -- no debconf information
Bug#969402: installation-reports: does not start with -q option specified
Control: tag 969402 +moreinfo On Tue, Sep 01, 2020 at 11:56:41PM -0300, LILIAN wrote: } ... only the empty template ... Pleaes tell more, such as where your added the -qand what you expect from it. Groeten Geert Stappers -- Silence is hard to parse
Bug#969260: openfjx: FTBFS (gstreamer)
On Sun, Aug 30, 2020 at 12:02:03PM +0200, Bas Couwenberg wrote: > Source: openjfx > Version: 11.0.7+0-3 > Severity: serious > Tags: ftbfs > Justification: makes the package in question unusable or mostly so > > Dear Maintainer, > > openjfx (11.0.7+0-3) FTFBS everywhere due to issues with the gstreamer > support. > > The buildlog shows may "multiple definition of" issues. > > The previous (successfull) build also used gstreamer 1.16.2, so the issue is > caused by some other change, possibly GCC 10. Thanks for reporting this. Those build logs are, uh, interesting... It builds successfully for me locally in a clean sid chroot (running gcc 10) and I don't see any ld output about gstreamer at all. I will see if I can figure out what's happening. Thanks, tony signature.asc Description: PGP signature
Bug#958110: nickle: please make the build reproducible
"Chris Lamb" writes: > Dear Maintainer, > >> Source: nickle >> Version: 2.77-1 >> Tags: patch > > There hasn't seem to be any update on this bug in 135 days, in which > time the Reproducible Builds effort has come on a long way. > > Would you consider applying this patch and uploading? So sorry -- I had applied the fixes but hadn't uploaded. Vagrant caught me on IRC and encouraged me to finish the next release. -- -keith signature.asc Description: PGP signature
Bug#969223: Can't rm directory on overlayfs in userns
On Sat, Aug 29, 2020 at 10:13 PM Shengjing Zhu wrote: > > Source: linux > Version: 5.7.10-1 > Severity: normal > > Hi, > > After enabling overlayfs for userns, I find it doesn't work as expected. > > $ cat /sys/module/overlay/parameters/permit_mounts_in_userns > Y > > zsj@debian:~/test$ pwd > /home/zsj/test > zsj@debian:~/test$ tree > . > ├── lower > │ └── a > │ └── a > ├── merged > ├── upper > └── work > > zsj@debian:~/test$ unshare -m -U -r > root@debian:~/test# mount -t overlay -o > rw,lowerdir=/home/zsj/test/lower,upperdir=/home/zsj/test/upper,workdir=/home/zsj/test/work > overlay /home/zsj/test/merged > root@debian:~/test# rm -rf merged/a > rm: cannot remove 'merged/a': Input/output error > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) > Kernel taint flags: TAINT_USER, 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) If I upgrade a debian10 VM to testing, it seems to work. However if I boot a new debian testing VM, it seems not to work. Both VMs are downloaded from http://cdimage.debian.org/cdimage/cloud/ What can be the difference here? I'm lost on debugging this.. -- Shengjing Zhu
Bug#969305: [Pkg-zsh-devel] Bug#969305: Bug#969305: zsh: safe-rm needs to be added to the default path of interactive shells to work
Francois Marier wrote on Mon, 31 Aug 2020 12:04 -0700: > On 2020-08-31 at 04:41:56, Daniel Shahaf wrote: > > I guess it should be in the zprofile file, guarded by a [[ -o interactive > > ]] check. > > From the comment in /etc/zsh/zshrc: > > # This file is sourced only for interactive shells. It > # should contain commands to set up aliases, functions, > # options, key bindings, etc. > > I thought it was a better fit, given that /etc/zsh/zprofile claims it's only > for login shells: > > # This file is sourced only for login shells (i.e. shells > # invoked with "-" as the first character of argv[0], and > # shells invoked with the -l flag.) > > Or maybe I got that wrong? > You didn't get that wrong. It's just that setting envvars is the job of a login shell, not of shells spawned later on. (That'd be analogous to how safe-rm, as you said, drops code into /etc/profile.d/, rather than into a (non-existent) /etc/bash.bashrc.d/.) Thus, zprofile. The [[ -o interactive ]] is to not apply to non-interactive login shells. (When do these happen, anyway?) > > > However, I don't see a way for packages to do this. So I guess there would > > > be two ways to make this possible: > > > > > > 1. The main /etc/zsh/zshrc script could source all .sh files in a new > > >/etc/zsh/zshrc.d/ directory. > > > 2. The /etc/zsh/zshrc that ships in Debian could include the above. > > > > > > Are either of these something you'd be willing to consider? > > > > I don't have an opinion one way or the other. > > > > I do note that option #2 would cause a stat(2) call during shell startup > > for everyone who _doesn't_ use safe-rm. Would that be a problem? > > (E.g., slower shell startup) > > Good point about the extra stat. I honestly don't know whether that kind of > impact can even be reliably measured, but you're right that it would > be unnecessary for non-users of safe-rm. > > > Probably not what you had in mind, but my first instinct here is to > > look for a shell-independent solution. For example: > > Indeed, that's an excellent approach and is in fact where I started. > Ah, I didn't know the background here. Thanks for the detailed exposition. > > 3. Get the OS to add /usr/share/safe-rm/bin to $PATH before the user's > > shell is executed in the first place. (On FreeBSD that'd be > > login.conf(5), but I don't know what the Linux equivalent is.) > > That appears to be in /etc/login.defs, but without any way for a package to > configure. > I see. > > 4. Use dpkg-divert(8) to replace /bin/rm with a wrapper that calls > > either safe-rm or the diverted rm binary, depending on whether it's > > interactive or not. > > That was my first attempt and it turned out to be extremely risky and hard > to get right: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489690 That bug basically says that when /bin/rm is replaced, the process of replacement must be atomic. I don't see how a requirement for atomicity is intractable. On the contrary, I think it's a textbook problem with textbook solutions. For example, one standard and portable answer is to use rename(2)'s atomicity guarantees. That's exactly what dash's maintainer scripts, that the above bugs point to, do: see replace_with_link(), and note how it places the $temp in the same directory as $dfile. More generally, «rm /bin/rm && ln -s foo /bin/rm» is like «ls "$@"» and «date | grep -w Tue»: it's wrong; it's not _obviously_ wrong; code review will spot the mistake easily; once the correct pattern is learned, it'll be gotten right every time, automatically. All the above being said, I wouldn't have been surprised if getting this approach right were complicated by something else — say, dpkg-divert uses in _other_ packages that need to be coëxisted with. > > If you don't already know them, see RM_STAR_SILENT and RM_STAR_WAIT in > > zshoptions(1). > > Oh, that's very cool! A very good complement to safe-rm in fact since > that's not something safe-rm can do anything about since the shell expands > these globs before passing the paths to the rm command. Well, safe-rm _could_ check whether the arguments are all in the same directory, sorted, and comprise all non-dotfiles (or all files, including dotfiles — see the GLOB_DOTS option) in that directory. However, whether that'd be practical and worth the costs (e.g., some false positives, particularly after a user pressed to manually expand the glob for review) is beyond the scope of this bug report. > > P.S. Compare #489646, about providing a directory for packages to drop > > completion files into. (That didn't involve reimplementing > > run-parts(1), though; it was just a matter of adding a directory to > > a list of directories.) > > Yes, having a /usr/share/zsh/vendor-config/ or similar would be very good. > It certainly doesn't have to live in /etc/. I didn't intend to imply anything about which directory the files should live in. I was just referencing
Bug#969084: buildd.d.o: please don't use a tainted buildenv
> I think ideally > this would be using a system pathname and be part of a package that gets > then listed in the .buildinfo files. This is how openSUSE does it as well, e.g with https://github.com/openSUSE/post-build-checks/ and https://github.com/openSUSE/brp-check-suse/ that get pulled into the build as versioned packages. If you think, that a package with 1 line is overkill, maybe you could add it to another build-only package as /usr/sbin/policy-rc.d ?
Bug#663255: Votre compte zimbra a dépassé la limite / quota
Votre compte zimbra a dépassé la limite / quota fixé par ZimbraTeam, et vous ne pourrez pas envoyer ou recevoir de nouveaux e-mails tant que vous n'aurez pas vérifié votre e-mail Zimbra. Pour vérifier votre compte, cliquez ici et remplissez le formulaire et cliquez sur Soumettre.
Bug#969402: installation-reports: does not start with -q option specified
Package: installation-reports Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: Boot method: Image version: Date: Machine: Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. -- System Information: Debian Release: 9.13 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.189 (SMP w/4 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#834050: libpam-ldap: please make the build reproducible
I'm little busy this days, If someone could make patch, please make a NMU. On 9/1/20 7:53 PM, Chris Lamb wrote: Chris Lamb wrote: [..] Gentle ping on this? Regards, -- Lucas Castro
Bug#969401: Fixed upstream
Hey, First, apologies for including the template text - it was off the bottom of my editor and I forgot to remove it. This is fixed upstream in commit 18edc98f9d08883f340087cfefbdf05c585d56f7 which is in B.02.19 . It also fixes the 'Unknown' string which I have observed on one of my machines. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud:| This space intentionally left blank https://catalystcloud.nz|
Bug#969401: lshw: -version parameter prints blank line only
Package: lshw Version: 02.18.85-0.1 Severity: normal Dear Maintainer, Running lshw with the -version parameter should display the version of lshw, instead it displays a blank line. For example: puck@flick:~$ lshw -version puck@flick:~$ Testing this on Stretch with lshw v 02.18-0.1, it works. This also affects Ubuntu Focal (02.18.85-0.3ubuntu2), it works okay on Bionic (02.18-0.1ubuntu6.18.04.1), I haven't checked any non-LTS Ubuntu releases. Cheers, Andrew *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers common APT policy: (500, 'common'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=POSIX (charmap=UTF-8) (ignored: LC_ALL set to en_NZ.UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lshw depends on: ii libc6 2.31-3 ii libgcc-s1 10.2.0-5 ii libstdc++6 10.2.0-5 Versions of packages lshw recommends: ii pciutils 1:3.7.0-2 ii usbutils 1:012-2 lshw suggests no packages. -- no debconf information
Bug#969360: Qt seccomp failure fixed upstream
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-81313 Control: tags -1 upstream fixed-upstream It turns out it is a clash both with Chromium (powers Qt WebEngine) and glibc. Check out the Red Hat bugs https://bugzilla.redhat.com/show_bug.cgi?id=1812482 (Qt) https://bugzilla.redhat.com/show_bug.cgi?id=1773289 (Chromium) The Chromium package also doesn't work on i386; that's bug #965960. signature.asc Description: This is a digitally signed message part.
Bug#969350: linux-image-4.19.0-10-amd64: Kernel regularly crashes - general protection fault in the network stack
Hi Salvatore, On Mon, Aug 31, 2020 at 11:31:26PM +0200, Salvatore Bonaccorso wrote: > Thanks for the report. This looks the same as #966846, which we have > pending fixed in the packaging repository. > > If you can expose the fixes for testing, then there are temporary and > inofficial 4.19.142-1 builds at > https://people.debian.org/~carnil/tmp/linux/4.19.142-1/ . Thank you for the hint; indeed it looks the same as #966846. I have tried the kernel you have prepared and I have not experienced any crash in the last 23 hours (it was crashing more often recently). I will keep you informed if a crash is occurring. Antoine signature.asc Description: PGP signature
Bug#967011: Bug#969360: libqt5webengine5: [i386] seccomp-bpf failure in syscall 0403 (clock_gettime64)
Control: severity -1 serious Control: affects -1 konqueror (Forgot to send this to the bug; only sent to the submitter first time around.) On Tuesday, September 1, 2020 2:32:54 PM EDT you wrote: > I am pretty sure, the issue appeared with the change from 5.12 to 5.14, around 5th of july. Checked the other logs, but there were no major changes. That was a big version jump, so I bet you're probably right. I just noticed an interesting changelog entry however: qtwebengine-opensource-src (5.14.2+dfsg1-3) unstable; urgency=medium * Add a patch to build openh264 with -DX86_32_PICASM on i386, to fix errors from new linker (closes: #965328). I have been able to reproduce this in a fresh virtual machine, and in addition to KMail it also affects Konqueror and friends. Since it's unusable on i386, I'm making this bug serious. signature.asc Description: This is a digitally signed message part.
Bug#969400: ddclient: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: ddclient Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: PGP signature
Bug#969376: openafs-client: Openafs cache erros on the logs
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
Bug#969386: Resolve file: not just file:///
On Wed, 02 Sep 2020 01:19:30 +0800, 積丹尼さん wrote: > Real w3m can deal fine with file:bla.txt and does not always need > file:///full/path/to/bla.txt . w3m visits the file `pwd`/bla.txt . That's a good feature as a user knows where the current directory is (in other words a user knows the file bla.txt exists in the current directory). But does a Chrome/Firefox/Safari/emacs-w3m user know where one is? In emacs-w3m the current directory (i.e., `default-directory') defaults to ~/.w3m for years, but there may be no file of interest. Well, for instance, probably we can modify emacs-w3m so to allow "file:bla.txt" things if and only if a user has specified `w3m-default-directory' (defaults to nil). Otherwise how about using `w3m-find-file' instead? > But emacs-w3m says > w3m--goto-url--valid-url: Wrong type argument: stringp, nil Ending up with an error is bad in that situatuion anyway. I think we should improve it so to issue something other than an error. Thanks.
Bug#777486: mimefilter: please make the build reproducible
Chris Lamb wrote: > [..] Gentle ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#777058: dbview: please make the build reproducible
Chris Lamb wrote: > [..] Gentle ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#898912: telepathy-gabble: please make the build reproducible
Dear Maintainer, > Source: telepathy-gabble > Version: 0.18.4-1 > Tags: patch There hasn't seem to be any update on this bug in 837 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#777058: dbview: please make the build reproducible
Chris Lamb wrote: > [..] Friendly ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#833612: nsnake: please make the build reproducible
Chris Lamb wrote: > [..] Friendly ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#860372: hp-search-mac: 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 971 days now (!). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#777299: checkpw: please make the build reproducible
Chris Lamb wrote: > [..] Friendly ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#862195: sendip: please make the build reproducible
Dear Maintainer, > Source: sendip > Version: 2.5-7 > Tags: patch There hasn't seem to be any update on this bug in 1210 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#956588: libctl: please make the build reproducible
Dear Maintainer, > Source: libctl > Version: 3.2.2-2 > Tags: patch There hasn't seem to be any update on this bug in 140 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#824453: gtk-gnutella: please make the build reproducible
Chris Lamb wrote: > [..] Friendly ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#958110: nickle: please make the build reproducible
Dear Maintainer, > Source: nickle > Version: 2.77-1 > Tags: patch There hasn't seem to be any update on this bug in 135 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#939548: dsdp: please make the build reproducible
Dear Maintainer, > Source: dsdp > Version: 5.8-9.1 > Tags: patch There hasn't seem to be any update on this bug in 361 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#943674: flask: 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 305 days now (!). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#827994: cmtk: please make the build (mostly) reproducible
Chris Lamb wrote: > [..] Gentle ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#777410: freecdb: please make the build reproducible
Chris Lamb wrote: > [..] Friendly ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#777287: beav: please make the build reproducible
Chris Lamb wrote: > [..] Gentle ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#776929: tinydyndns: please make the build reproducible
Chris Lamb wrote: > [..] Friendly ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#834050: libpam-ldap: please make the build reproducible
Chris Lamb wrote: > [..] Gentle ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#969399: bash-completion: Hang completing ~userame inside command substitution solved by upgrading
Package: bash-completion Version: 1:2.11-2 Severity: minor * What led up to the situation? 1.) Using version 1:2.9-1 and 2.) Typing $ egrep -i keyword $( find ~kin^I 3.) but bash hung, and didn't respond to pressing control-c. I expected pressing the tab key to let bash-completion complete "~kin" to ~kingsley/. * What exactly did you do (or not do) that was effective (or ineffective)? 1.) Upgrading to version 1:2.11-2 2.) launching a new shell 3.) completion worked! Thanks, Kingsley *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#969398: lintian: weird tag doubling (regression)
Package: lintian Version: 2.92.0 Severity: normal X-Debbugs-Cc: t...@mirbsd.de I get output like this: X: sfarklib source: debian-watch-does-not-check-gpg-signature N: P: debian-watch-does-not-check-gpg-signature N: N: This watch file does not specify a means to verify the upstream N: tarball using a cryptographic signature. […] The second and third line are new and probably should not be there (the extra N: and the P: ones). -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages lintian depends on: ii binutils2.35-2 ii bzip2 1.0.8-4 ii diffstat1.63-1 ii dpkg1.20.5 ii dpkg-dev1.20.5 ii file1: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+b2 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b5 ii libclone-perl 0.45-1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl 4.21-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1 ii libdevel-size-perl 0.83-1+b1 ii libdigest-sha-perl 6.02-1+b2 ii libdpkg-perl1.20.5 ii libemail-address-xs-perl1.04-1+b2 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1 ii libhtml-html5-entities-perl 0.004-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004002-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.416-1+b5 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl0.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 libproc-processtable-perl 0.59-2 ii libsereal-decoder-perl 4.018+ds-1 ii libsereal-encoder-perl 4.018+ds-1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b7 ii libtext-markdown-discount-perl 0.12-1 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-perl2.3300-1 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.010005-1 ii libunicode-utf8-perl0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl 2.0134+dfsg-2 ii libyaml-libyaml-perl0.82+repack-1 ii lzip1.21-8 ii lzop1.04-1 ii man-db 2.9.3-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.30.3-4 ii t1utils 1.41-4 ii unzip 6.0-25 ii xz-utils5.2.4-1+b1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35-2 pn libtext-template-perl -- no debconf information
Bug#964812: closed by Debian FTP Masters (reply to Ben Hutchings ) (Bug#964812: fixed in linux 5.8.3-1~exp1)
> -- Forwarded message -- > From: David Awogbemila > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Fri, 10 Jul 2020 18:21:14 + > Subject: linux: Pulling Google Compute Engine Virtual Ethernet Driver into > Debian > Source: linux > Severity: wishlist > > Dear Maintainer, > > Google would like to have its cloud networking driver, the Google > Compute Engine Virtual Ethernet driver (GVE) pulled into Debian > releases. > > This driver has been accepted into the upstream Linux kernel > since version 5.2: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/google?h=v5.4.46). > > I understand that the first step towards this is enabling the driver > in Debian's unstable and testing releases so I have attached the > relevant Kconfig file for GVE to this bug report. > > GVE can be configured in the kernel's config file with: > > CONFIG_GVE=m > CONFIG_NET_VENDOR_GOOGLE=y > > We're also looking to have the driver backported into Debian 10 > source. > > Please let me know other steps we need to take to accomplish the goals > listed above. > > Best > David > > -- System Information: > Debian Release: 10.4 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-9-cloud-amd64 (SMP w/16 CPU cores) > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled Thank you for the update! Just to confirm, does this mean the driver will be available to future versions on Debian (i.e. have the config options set so that the driver is available in Debian Images)? If so, what versions of Debian will this affect? (I'm guessing the ones starting with linux 5.8?) Thanks. David
Bug#968684: libqb: Please make autopkgtests cross-test-friendly
On Sat, Aug 22, 2020 at 07:14:57PM +0200, wf...@niif.hu wrote: > On Wed, 19 Aug 2020 14:04:15 -0700 Steve Langasek > wrote: > > > In Ubuntu, we have moved the i386 architecture to a compatibility-only layer > > on amd64, and therefore we are also moving our autopkgtest infrastructure to > > test i386 binaries in a cross-environment. > > > > This requires changes to some tests so that they are cross-aware and can do > > the right thing. > Hi, > Would the following change work for Ubuntu? I find using a single code > path slightly cleaner. > (https://salsa.debian.org/ha-team/libqb/-/commit/21c2e77428fa0e2bba35b43523a7af028bc3e676) Yes, this looks like it should behave correctly for both the cross and native cases (for 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 signature.asc Description: PGP signature
Bug#969396: sleef FTBFS on arm64 with gcc-10, sve code requires __sizeless_struct
Package: sleef
Version: 3.4.1-4
Severity: serious
The most recent upload of sleef fixed the build on amd64, armhf, i386 and
ppc64el. Unfortunately
it is still failing on arm64, with the following error.
In file included from /<>/src/libm/sleefsimdsp.c:209:
/<>/src/arch/helpersve.h:94:27: error: expected ‘=’, ‘,’, ‘;’,
‘asm’ or ‘__attribute__’ before ‘{’ token
94 | typedef __sizeless_struct {
| ^
It looks like __sizeless_struct is a compiler feature that was proposed for
adding to gcc,
but it doesn't appear to have actually been added, at least not under that name.
It looks like this bug has shown up now because gcc-10 added support for
"arm_sve.h". previously
this header was not present and so COMPILER_SUPPORTS_SVE was false, but now it
is true and
sleef tries and fails to build the arm sve code.
I whipped up a patch that changes the detection code so it will not try to
build the sve code
if the compiler does not support __sizeless_struct. Unfortunately it then
failed with
[ 50%] Building C object
src/libm-tester/CMakeFiles/iutypurec_scalar.dir/iutsimd.c.o
cd /sleef-3.4.1/obj-aarch64-linux-gnu/src/libm-tester && /usr/bin/cc
-DDETERMINISTIC=1 -DENABLE_ALIAS=1 -DENABLE_PUREC_SCALAR=1 -DENABLE_SYS_getrandom=1
-I/sleef-3.4.1/src/common -I/sleef-3.4.1/src/arch
-I/sleef-3.4.1/obj-aarch64-linux-gnu/include -I/sleef-3.4.1/src/libm
-I/sleef-3.4.1/obj-aarch64-linux-gnu/src/libm/include -Wall -Wno-unused -Wno-attributes
-Wno-unused-result -Wno-psabi -ffp-contract=off -fno-math-errno -fno-trapping-math -O2
-g -DNDEBUG -std=gnu99 -o CMakeFiles/iutypurec_scalar.dir/iutsimd.c.o -c
/sleef-3.4.1/src/libm-tester/iutsimd.c
/sleef-3.4.1/src/libm-tester/iutsimd.c:198:9: error: unknown type name
‘Sleef_double_2’
198 | typedef Sleef_double_2 vdouble2;
| ^~
/sleef-3.4.1/src/libm-tester/iutsimd.c:199:9: error: unknown type name
‘Sleef_float_2’
199 | typedef Sleef_float_2 vfloat2;
|
That was about where I reached the limit of my skills as someone not familiar
with the package,
a work-in progress debdiff is attatched.
Alternatively it looks like there is a new upstream release of sleef that
revamps the sve
code so it can be built with gcc 10. So that might be an alternative route.
diff -Nru sleef-3.4.1/debian/changelog sleef-3.4.1/debian/changelog
--- sleef-3.4.1/debian/changelog2020-07-30 12:55:23.0 +
+++ sleef-3.4.1/debian/changelog2020-09-01 21:17:11.0 +
@@ -1,3 +1,12 @@
+sleef (3.4.1-4.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Make sve detection code check for __sizeless_struct. gcc 10 has
+arm_sve.h but not __sizeless_struct which is needed by the sve
+implementation in this version.
+
+ -- Peter Michael Green Tue, 01 Sep 2020 21:17:11 +
+
sleef (3.4.1-4) unstable; urgency=medium
* Team Upload.
diff -Nru sleef-3.4.1/debian/patches/check-for-sizeless-struct.patch
sleef-3.4.1/debian/patches/check-for-sizeless-struct.patch
--- sleef-3.4.1/debian/patches/check-for-sizeless-struct.patch 1970-01-01
00:00:00.0 +
+++ sleef-3.4.1/debian/patches/check-for-sizeless-struct.patch 2020-09-01
21:17:11.0 +
@@ -0,0 +1,15 @@
+Description: Make sve detection code check for __sizeless_struct.
+ gcc 10 has arm_sve.h but not __sizeless_struct which is needed by the sve
+ implementation in this version.
+Author: Peter Michael Green
+
+--- sleef-3.4.1.orig/Configure.cmake
sleef-3.4.1/Configure.cmake
+@@ -554,6 +554,7 @@ if(SLEEF_ARCH_AARCH64 AND NOT DISABLE_SV
+ set (CMAKE_REQUIRED_FLAGS ${FLAGS_ENABLE_SVE})
+ CHECK_C_SOURCE_COMPILES("
+ #include
++ typedef __sizeless_struct { svint32_t x, y;} vmask2;
+ int main() {
+ svint32_t r = svdup_n_s32(1); }"
+ COMPILER_SUPPORTS_SVE)
diff -Nru sleef-3.4.1/debian/patches/series sleef-3.4.1/debian/patches/series
--- sleef-3.4.1/debian/patches/series 2020-07-30 12:55:23.0 +
+++ sleef-3.4.1/debian/patches/series 2020-09-01 21:17:11.0 +
@@ -1,2 +1,3 @@
disable-neon-on-armel.patch
fix-gcc10-build.patch
+check-for-sizeless-struct.patch
Bug#969388: debsums: Add bash completion
Package: debsums
Version: 2.2.5
Severity: wishlist
Tags: patch
Here are bash completions for debsums. The implementation of
_comp_dpkg_installed_packages() is from dpkg’s bash completions; I don’t
know whether there’s a way to share them? Or, since
/usr/share/bash-completion/completions/dpkg is in the bash-completion
package, perhaps this bug would be better filed there?
_have grep-status && {
_comp_dpkg_installed_packages()
{
grep-status -P -e "^$1" -a -FStatus 'ok installed' -n -s Package
}
} || {
_comp_dpkg_installed_packages()
{
command grep -A 1 "Package: $1" /var/lib/dpkg/status 2>/dev/null | \
command grep -B 1 -Ee "ok installed|half-installed|unpacked| \
half-configured" \
-Ee "^Essential: yes" | \
awk "/Package: $1/ { print \$2 }" 2>/dev/null
}
}
_debsums()
{
local cur prev words cword
_init_completion || return
if [[ "$cur" == -* ]]; then
COMPREPLY=( $( compgen -W '$( _parse_help "$1" )' -- "$cur" ) )
else
COMPREPLY=( $(_comp_dpkg_installed_packages "$cur") )
fi
} &&
complete -F _debsums -o default debsums
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-updates
APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'),
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-42-generic (SMP w/16 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), LANGUAGE=en_GB
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debsums depends on:
ii libdpkg-perl 1.19.7ubuntu3
ii libfile-fnmatch-perl 0.02-2build6
ii perl 5.30.0-9build1
ii ucf 3.0038+nmu1
debsums recommends no packages.
debsums suggests no packages.
-- Configuration Files:
/etc/debsums-ignore [Errno 2] No such file or directory: '/etc/debsums-ignore'
-- no debconf information
Bug#969395: chromium 83.0.4103.116-3+b1 crash immediately, SEGV_MAPERR
Package: chromium Version: 83.0.4103.116-3+b1 Severity: grave Justification: renders package unusable Dear Maintainer, Chromium crashes immediately with screen awsnap errorcode 256 Log; Sep 1 20:37:43 debian dbus-daemon[439]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.156' (uid=1000 pid=5370 comm="/usr/lib/chromium/chromium --show-component-extens") Sep 1 20:37:43 debian chromium.desktop[5370]: [5370:5370:0901/203743.006490:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id Sep 1 20:37:43 debian chromium.desktop[5370]: [5370:5370:0901/203743.006978:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id Sep 1 20:37:43 debian systemd[1]: Condition check resulted in Bluetooth service being skipped. Sep 1 20:37:45 debian chromium.desktop[5436]: ../../sandbox/linux/seccomp-bpf- helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403 Sep 1 20:37:45 debian chromium.desktop[5436]: Received signal 11 SEGV_MAPERR 0bc01193 Sep 1 20:37:45 debian chromium.desktop[5436]: #0 0x04f1577f (/usr/lib/chromium/chromium+0x4b1177e) Sep 1 20:37:45 debian chromium.desktop[5436]: #1 0x04e66a12 (/usr/lib/chromium/chromium+0x4a62a11) Sep 1 20:37:45 debian chromium.desktop[5436]: #2 0x04f153ee (/usr/lib/chromium/chromium+0x4b113ed) Sep 1 20:37:45 debian chromium.desktop[5436]: #3 0xb7ee61e4 ([vdso]+0x11e3) Sep 1 20:37:45 debian chromium.desktop[5436]: #4 0x060eed28 (/usr/lib/chromium/chromium+0x5cead27) Sep 1 20:37:45 debian chromium.desktop[5436]: #5 0x060f5cf4 (/usr/lib/chromium/chromium+0x5cf1cf3) Sep 1 20:37:45 debian chromium.desktop[5436]: #6 0x060f5a4a (/usr/lib/chromium/chromium+0x5cf1a49) Sep 1 20:37:45 debian chromium.desktop[5436]: #7 0xb7ee61e4 ([vdso]+0x11e3) Sep 1 20:37:45 debian chromium.desktop[5436]: #8 0xb7ee61cd ([vdso]+0x11cc) Sep 1 20:37:45 debian chromium.desktop[5436]: #9 0xb7ee612a ([vdso]+0x1129) Sep 1 20:37:45 debian chromium.desktop[5436]: #10 0xb3855f69 (/usr/lib/i386-linux-gnu/libc-2.31.so+0xc3f68) Sep 1 20:37:45 debian chromium.desktop[5436]: gs: 0033 fs: es: 007b ds: 007b Sep 1 20:37:45 debian chromium.desktop[5436]: edi: 0193 esi: bfbd9b08 ebp: bfbd9ad8 esp: bfbd9ac0 Sep 1 20:37:45 debian chromium.desktop[5436]: ebx: 09b3cd38 edx: 0007 ecx: 0bc01193 eax: 1000 Sep 1 20:37:45 debian chromium.desktop[5436]: trp: 000e err: 0006 ip: 060eed28 cs: 0073 Sep 1 20:37:45 debian chromium.desktop[5436]: efl: 00210206 usp: bfbd9ac0 ss: 007b Sep 1 20:37:45 debian chromium.desktop[5436]: [end of stack trace] Sep 1 20:37:45 debian chromium.desktop[5436]: Calling _exit(1). Core file will not be generated. Sep 1 20:37:45 debian chromium.desktop[5439]: ../../sandbox/linux/seccomp-bpf- helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 5.7.0-3-686-pae (SMP w/2 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 chromium depends on: ii chromium-common 83.0.4103.116-3+b1 ii libasound2 1.2.3.2-1 ii libatk-bridge2.0-0 2.34.1-3 ii libatk1.0-0 2.36.0-2 ii libatomic1 10.2.0-5 ii libatspi2.0-0 2.36.0-3 ii libavcodec58 7:4.3.1-2 ii libavformat58 7:4.3.1-2 ii libavutil56 7:4.3.1-2 ii libc6 2.31-3 ii libcairo2 1.16.0-4 ii libcups2 2.3.3-2 ii libdbus-1-3 1.12.20-1 ii libdrm2 2.4.102-1 ii libevent-2.1-7 2.1.12-stable-1 ii libexpat1 2.2.9-1 ii libflac8 1.3.3-1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.2+dfsg-3 ii libgbm1 20.1.5-1 ii libgcc-s1 10.2.0-5 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.64.4-1 ii libgtk-3-0 3.24.22-1 ii libharfbuzz0b 2.6.7-1 ii libicu67 67.1-4 ii libjpeg62-turbo 1:2.0.5-1.1 ii libjsoncpp1 1.7.4-3.1 ii liblcms2-2 2.9-4+b1 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.27-1 ii libnss3 2:3.55-1 ii libopenjp2-7 2.3.1-1 ii libopus0 1.3-1+b1 ii libpango-1.0-0 1.46.1-1 ii libpangocairo-1.0-0 1.46.1-1 ii libpng16-16 1.6.37-2 ii libpulse0 13.0-5 ii libre2-8 20200801+dfsg-1 ii libsnappy1v5 1.1.8-1 ii libstdc++6 10.2.0-5 ii libvpx6 1.8.2-1 ii libwebp6 0.6.1-2+b1 ii libwebpdemux2 0.6.1-2+b1 ii libwebpmux3 0.6.1-2+b1 ii libx11-6 2:1.6.10-3 ii libx11-xcb1
Bug#969394: gnome-disk-utility: Gives error upon failure to create flash drive image
Package: gnome-disk-utility Version: 3.36.3-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Wished to clone a flash drive by image creation and restore to another. * What exactly did you do (or not do) that was effective (or ineffective)? I can find no work around. * What was the outcome of this action?Error creating disk image Error allocating space for disk image file: No space left on device (g-io- error-quark. 12) * What outcome did you expect instead? It should have worked as it always did without this error on these flash drives. I cannot tell if some recent upgrade changed something in Disks or not, but I did upgrade to the latest testing version and it die not help. *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-disk-utility depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii libatk1.0-0 2.30.0-2 ii libc62.28-10 ii libcairo21.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libdvdread8 6.1.1-2 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 liblzma5 5.2.4-1 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpwquality11.4.0-3 ii libsecret-1-00.18.7-1 ii libsystemd0 241-7~deb10u4 ii libudisks2-0 2.8.1-4 ii udisks2 2.8.1-4 gnome-disk-utility recommends no packages. gnome-disk-utility suggests no packages. -- no debconf information
Bug#966921: Fwd: [Pkg-dpdk-devel] OVS cannot find DPDK
Forwarding our private conversation to the BTS (I hope none will mind, I
don't see anything private that shouldn't be public in the tracker here...)
Cheers,
Thomas Goirand (zigo)
Forwarded Message
Subject: Re: [Pkg-dpdk-devel] OVS cannot find DPDK
Date: Tue, 1 Sep 2020 14:43:29 +0200
From: Christian Ehrhardt
To: Luca Boccassi
CC: Thomas Goirand , Debian DPDK Maintainers
(2) comes down to breakage in DPDK 19.11.4 linking.
I've reported that at:
http://mails.dpdk.org/archives/stable/2020-September/024796.html
and Luca will take care of that.
Back to the OVS config problem, I've reproduced and found that it is
indeed toolchain related (affects old and new versions of OVS).
It seems it is indeed a problem in libdpdk-dev
$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/libdpdk.pc
[...]
Libs: -L${libdir} [...] -lnuma -lpcap -lIPSec_MB
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libfdt.so
The above path shouldn't be there as-is.
It should not be versioned to ...-gnu/9/../ which is what fails now
that we are on gcc-10.
I need to look if I can find where exactly this comes from ...
Bug#969211: RM: redmine/4.0.7-1
Dear Pirate, On 29-08-2020 12:54, Pirate Praveen wrote: > redmine is not compatible with rails 6 (#969206). This is blocking > migration of rails 6 to testing. Please remove redmine from testing to > allow rails 6 to migrate to testing. That redmine bug was filed just before you requested the removal here (why did you wait so long with informing the maintainers?). Please give the maintainers some time to fix the issue. A couple of weeks is not unreasonable. Or are there pressing issues why rails should migrate quicker? Paul
Bug#929802: checkrestart: wrongly report processes using deleted files from sssd cache
tag 929802 pending thanks Dear Baptiste, On Fri, 31 May 2019 at 14:24, Baptiste BEAUPLAT wrote: > I propose to add this directory to the list of ignored path in checkrestart. Thank you for your report and your patch, I have pushed it to the debian-goodies GIT repository (https://salsa.debian.org/debian/debian-goodies/-/blob/master/checkrestart commit 88ac8cae1ce209076744eed3750a599a08256531). It will be fixed with the next package upload. Best regards Javier Fernández-Sanguino
Bug#912889: tinyca: Depends on libgtk2-perl, that won't be part of Bullseye
Hi, intrigeri writes: >> I hope that upstream will port the code to GTK 3 in time for the >> Bullseye freeze :) When I received your initial bug report, I followed the advice given in Perl's Gtk3 module documentation to "run s/Gtk2/Gtk3/ on [the] application." Unfortunately, that didn't work at all and I put it aside. > What do you think we should do? I can think of several options, > from the least drastic to the most: > > - File a Request For Help (RFH) bug against wnpp, in order to alert >users and fellow Debian people about the current situation. > >popcon suggests this package is still quite popular, so I have some >hope someone could volunteer :) > > - Orphan the package. > > - Remove the package from sid. With the experience of my first attempt to port TinyCA from Gtk2 to Gtk3 I was considering removing the package from Debian altogether. However, encouraged by your remark that, according to popcon, there seems to be some interest in TinyCA still, I took another shot and made some progress towards a Gtk3 port. In light of this, let me get back to this bug report in about two weeks and decide how to proceed. BTW, I keep the most up-to-date copy of the TinyCA source on Salsa (https://salsa.debian.org/cpt_nemo-guest/tinyca). Regards Uli
Bug#969365: USB-C dock lacks multicast Ethernet functionality (so IPv6 is broken)
Hi Santiago, On Tue, Sep 01, 2020 at 01:01:27PM +0200, Santiago R.R. wrote: > Source: linux > Version: 4.19.118-2 > Severity: important > Tags: ipv6 upstream fixed-upstream > > IPv6 connectivity (and other network protocols relying on multicast) are > broken when using a Dell D6000 USB-C dock. > Quoting Miguel Rodríguez that filed the equivalent bug in ubuntu: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779173: > > "Dell D6000 exposes a CDC_NCM device for Ethernet traffic. However, > multicast Ethernet traffic is not processed making IPv6 not functional. > Other services, like mDNS used for LAN service discovery are also > hindered. > > The actual reason is that CDC_NCM driver was not processing requests to > filter (admit) multicast traffic. I provide two patches to the linux > kernel that admit all Ethernet multicast traffic whenever a multicast > group is being joined. > > The solution is not optimal, as it makes the system receive more traffic > than that strictly needed, but otherwise this only happens when the > computer is connected to a dock and thus is running on AC power. I > believe it is not worth the hassle to join only the requested groups. > This is the same that is done in the CDN_ETHER driver." > > The patches proposed by Miguel Rodríguez have been merged upstream, and > are part of 5.9-rc1 now. C.f. commits: > 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6 > e10dcb1b6ba714243ad5a35a11b91cc14103a9a9 > e506addeff844237d60545ef4f6141de21471caf > 0226009ce0f6089f9b31211f7a2703cf9a327a01 Thanks for the report, if I'm not mistaken this is the same as #965074. Can you request upstream backports of the needed fixes into the applicable stable releases (and as I understand you back to v4.19.y)? Regards, Salvatore
Bug#968509: Further crashes under linux-image-4.19.0-10-amd64
Hi Richard, On Tue, Sep 01, 2020 at 05:22:03PM +0100, Richard Kettlewell wrote: > On 30/08/2020 13:37, Richard Kettlewell wrote: > > On 30/08/2020 13:22, Salvatore Bonaccorso wrote: > >> Hi Richard, > Would you be able to test 4.19.142? > >>> > >>> If you can give me a route to getting .deb files for that version then > >>> sure - a download or a pointer to instructions. > >> > >> *unofficial* and *temporary* builds for that version can be found > >> here: https://people.debian.org/~carnil/tmp/linux/4.19.142-1/ > >> > >> If you prefer to build the package yourself, the source package of > >> this temporary work is as well uploaded there. > >> > >> Please let me know if that works for your. > > > > Thankyou, I'm running that kernel now on the first host. I'll report > > back when I know more. > > > The first host has been running that kernel without incident for 48 > hours and the second for nearly 24 hours. So it looks like 4.19.142 does > fix this issue. Thanks for testing the updated packages and confirming as well the status. Regards, Salvatore
Bug#969381: Viva espanol
On Tue, Sep 01, 2020 at 08:03:46PM +0200, Camaleón wrote: > Hello, > > I have to disagree. I see content for a conflict. Please proof me wrong and show the world that there is common ground. Regards Geert Stappers DD -- Silence is hard to parse
Bug#950646: sane-utils: saned does not work if starteed via systemd
Hello, searched the upstream issue tracker and found following, that seems to match your situation. https://gitlab.com/sane-project/backends/-/issues/275 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958074 Kind regards, Bernhard
Bug#950646: sane-utils: saned does not work if starteed via systemd
Hello Patrick, I found another environment to increase verbosity another little bit, please see below. Your output points also into the direction of an permission problem like what Stefan described in the first message. The unit file starts the saned server with user and group saned. On the other side it seems that the scanners usb vendor id and product id should be inside /usr/lib/udev/hwdb.d/20-sane.hwdb, and should get matched to libsane_matched=yes by udev ... Could you please additionally provide an output of 'lsusb'? A workaround might be to change the user running saned in the systemd-unit file, or add the saned user to a group that could access the usb devices. Kind regards, Bernhard /lib/systemd/system/saned@.service: User=saned Group=saned Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255 SANE_DEBUG_PLUSTEK=12 SANE_DEBUG_SANEI_USB=255
Bug#969392: le FTCBFS: uses AC_RUN_IFELSE
Source: le
Version: 1.16.5-0.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
le fails to cross build from source, because it uses AC_RUN_IFELSE to
figure out what ncurses' bool type actually is. Fortunately, all that we
know can be determined using compile test bisection
(AC_RUN_IFELSE/AC_CHECK_SIZEOF). Please consider applying the attached
patch to make le cross buildable.
Helmut
--- le-1.16.5.orig/acinclude.m4
+++ le-1.16.5/acinclude.m4
@@ -250,35 +250,33 @@
old_CFLAGS="$CFLAGS"
LIBS="$LIBS $CURSES_LIBS"
CFLAGS="$CFLAGS $CURSES_INCLUDES"
- AC_RUN_IFELSE([AC_LANG_SOURCE([[
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
#ifdef USE_NCURSES_H
# include
#else
# include
#endif
- int main()
- {
- FILE *fp = fopen("cf_test.out", "w");
- if (fp != 0) {
- bool x = TRUE;
- if ((-x) >= 0)
- fputs("unsigned ", fp);
- if (sizeof(x) == sizeof(int)) fputs("int", fp);
- else if (sizeof(x) == sizeof(char)) fputs("char", fp);
- else if (sizeof(x) == sizeof(short))fputs("short",fp);
- else if (sizeof(x) == sizeof(long)) fputs("long", fp);
- else fputs("unknown",fp);
- fclose(fp);
- }
- return(0);
- }
- ]])],[ac_cv_curses_bool="`cat cf_test.out`"
- case "$ac_cv_curses_bool" in
- *unknown*) ac_cv_curses_bool=unknown;;
- esac
- ],[ac_cv_curses_bool=unknown
- ac_cv_curses_bool=unknown],[])
- rm -f cf_test.out
+ ]],[[bool x = TRUE; int check[(-x) >= 0 ? 1 : -1];]])],[bool_sign=unsigned],[bool_sign=signed])
+ AC_CHECK_SIZEOF([bool],,[
+ #ifdef USE_NCURSES_H
+ # include
+ #else
+ # include
+ #endif
+ ])
+ AC_CHECK_SIZEOF([int])
+ AC_CHECK_SIZEOF([char])
+ AC_CHECK_SIZEOF([short])
+ AC_CHECK_SIZEOF([long])
+ AS_IF([test "$ac_cv_sizeof_bool" = "$ac_cv_sizeof_int"],
+[ac_cv_curses_bool="$bool_sign int"],
+[test "$ac_cv_curses_bool" = "$ac_cv_curses_char"],
+[ac_cv_curses_bool="$bool_sign char"],
+[test "$ac_cv_curses_bool" = "$ac_cv_curses_short"],
+[ac_cv_curses_bool="$bool_sign short"],
+[test "$ac_cv_curses_bool" = "$ac_cv_curses_long"],
+[ac_cv_curses_bool="$bool_sign long"],
+[ac_cv_curses_bool=unknown])
LIBS="$old_LIBS"
CFLAGS="$old_CFLAGS"
])
Bug#969360: libqt5webengine5: [i386] seccomp-bpf failure in syscall 0403 (clock_gettime64)
Am Dienstag, 1. September 2020, 18:38:30 CEST schrieben Sie: I am answering myself. Well, downgrading libqt5webengine5 and its dependencies sadly did not work. None of a qt-based application would start, due to the wrong version of libqt5core5a. To get it running, I would have to downgrade the whole system, and I fear, this will kill my whole system - besides it is also a lot of work. Work does not matter much, but killing my system does. I am pretty sure, the issue appeared with the change from 5.12 to 5.14, around 5th of july. Checked the other logs, but there were no major changes. And I am upgrading almost every day, so I saw this issue very fast. As I am doing so, I always see most issues very fast! I hope, this helps either. Best regards Hans > Am Dienstag, 1. September 2020, 17:34:39 CEST schrieben Sie: > Hi John, > > thanks for taking care of this. I know, Ireported this issue before, but > could not find it again. And I was notz sure, if I reported it or asked a > question in the debian forum. > > For the timeline, I am not quite sure, when this started, as I am upgrading > every day. But I believe, it might begin at Jul 5 2020, when I upgraded from > version 5.12.5+dfsg-7+b3 to 5.14.2+dfsg1-2. > > This is very close to the time, I noticed the issue. > > I will try to reinstall 5.12.XXX , but as it is no more in the repo, I > search for it in backports.debian.org. > > At the momen I am not sure, if this will succeed, as the new version was > installed due to a dependency of several other packages. I will give it a > try and then send the result. > > Again, thanks for the help and you need not apologize for inactivity. This > is all free work here and we are all thankfull, that people are still > motivated to develop great things (like debian!). > > Oh, one important note: This issue appears only on i386 (intel processor), > amd64 is good. I did not test it on 32-bit armhf on my Raspberry Pi as there > isi no plasma5 and kmail installed on it. > > Cheers and beers! > > Hans > > > Control: reassign -1 libqt5webengine5 > > Control: forcemerge 967011 -1 > > > > Hi, > > > > Sorry for the inactivity, but it seems you've reported this bug once > > before > > as #967011 so I'm merging your report with that. I hope I'll be able to > > reproduce in a virtual machine. If so, this bug will probably be > > release-critical. > > > > If you have an idea of when this started, could you check logs like > > /var/log/apt/history.log to narrow down the involved packages? signature.asc Description: This is a digitally signed message part.
Bug#840897: general: framebuffer modules for non-dri graphics cards are not loaded
Am 01.09.20 um 19:43 schrieb Ben Hutchings: > On Sun, 30 Aug 2020 19:08:00 +0200 Michael Biebl wrote: >> Control: reassign -1 udev >> Control: tags -1 + moreinfo >> >> Am 30.08.20 um 12:21 schrieb Chris Hofstaedtler: >>> Control: reassign -1 systemd >>> >>> * Michal Suchanek : So I would like the fbdev modules removed from whatever blacklist prevents loading them and have them loaded on systems that don't have dri modules to handle graphics. >>> >>> AFAICT systemd ships the fbdev blacklist nowadays, reassigning >>> there. >> >> The udev package does (but it's src:systemd, so close enough) in >> /lib/modprobe.d/fbdev-blacklist.conf >> >> I don't know the history behind this file though, it predates the >> udev/systemd merge and a quick search in the old src:udev package did >> not really yield anything useful. >> >> Hopefully Marco can chime in here and provide some context why it was >> added and if it's still required thoday. > > The old-style fbdev drivers generally cannot coexist with user-mode > graphics drivers or DRM drivers for the same devices (but the latter > can coexist with each other). The fbdev API provides very little > opportunity for X graphics acceleration, so it's generally preferable > to use X with user-mode graphics drivers (or the newer combined DRM/KMS > drivers). Therefore the fbdev drivers were blocked from auto-loading > by default. Thanks for this additional information, Ben. > I believe this file used to be a conffile in /etc so that it was > possible to override it in case the user prefers the fbdev driver. You can still do that by creating a file /etc/modprobe.d/fbdev-blacklist.conf which will override the one from /lib. > This does not explain why listing atyfb in a modules list does not > work; the "blacklist" directive should not affect that. Maybe the user did not rebuild his initramfs and the initramfs already loaded the non-fb driver, so loading fbdev failed? Michal, can you still reproduce the problem after running update-initramfs -u ? Michael signature.asc Description: OpenPGP digital signature
Bug#969391: remmina: Mouse scrolling fails on connections to Win10 RDP systems.
Package: remmina Version: 1.4.8+dfsg-1 Severity: important Dear Maintainer, The version 1.4.8 seems to have a bug with mouse scrolling function when conncting from Debain testing KDE environment to remote Windows 10 workstation. This is the link from upstream: https://gitlab.com/Remmina/Remmina/-/issues/2100 https://gitlab.com/Remmina/Remmina/-/issues/2273#note_397647365 https://gitlab.com/Remmina/Remmina/-/issues/2041#note_33593 Thank you, Andrew. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, 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 remmina 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 libavahi-client3 0.8-3 ii libavahi-common3 0.8-3 ii libavahi-ui-gtk3-00.8-3 ii libayatana-appindicator3-10.5.5-2 ii libc6 2.31-3 ii libcairo2 1.16.0-4 ii libgcrypt20 1.8.6-2 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 libsodium23 1.0.18-1 ii libsoup2.4-1 2.70.0-1 ii libssh-4 0.9.4-1 ii libssl1.1 1.1.1g-1 ii libvte-2.91-0 0.60.3-1 ii remmina-common1.4.8+dfsg-1 Versions of packages remmina recommends: ii remmina-plugin-rdp 1.4.8+dfsg-1 ii remmina-plugin-secret 1.4.8+dfsg-1 ii remmina-plugin-vnc 1.4.8+dfsg-1 Versions of packages remmina suggests: pn remmina-plugin-exec pn remmina-plugin-kwallet pn remmina-plugin-nx ii remmina-plugin-spice1.4.8+dfsg-1 pn remmina-plugin-www pn remmina-plugin-xdmcp -- no debconf information
Bug#969381: Bug reopen
Hello, I have to disagree. The GIT file has not been properly reviewed and should not be uploaded. Please keep the file attached on the bug report that has passed the Spanish translation team guidelines. Cheers, -- Camaleón
Bug#969378: Bug reopen
reopen 969378 Hello, I have to disagree. The GIT file has not been properly reviewed and should not be uploaded. Please keep the file attached on the bug report that has passed the Spanish translation team guidelines. Cheers, -- Camaleón
Bug#969380: Bug reopen
reopen 969380 Hello, I have to disagree. The GIT file has not been properly reviewed and should not be uploaded. Please keep the file attached on the bug report that has passed the Spanish translation team guidelines. Cheers, -- Camaleón
Bug#969377: Bug reopen
reopen 969377 Hello, I have to disagree. The GIT file has not been properly reviewed and should not be uploaded. Please keep the file attached on the bug report that has passed the Spanish translation team guidelines. Cheers, -- Camaleón
Bug#969390: ddcci-dkms: ddcci detection fails with "invalid identification response"
Package: ddcci-dkms Version: 0.3.2-1 Severity: normal Dear Maintainer, I was trying to control my monitor's backlight with the DDC/CI interface via the ddcci kernel module provided in the ddcci-dkms package. The monitor, a Dell P2219H, does support DDC/CI according to the manufacturer's website[1]. It is plugged into my Thinkpad T440p's docking station via DisplayPort. Loading the "ddcci" kernel module with the "dyndbg" option fails with this error in dmesg: [ 23.172820] ddcci: initializing ddcci driver [ 23.492855] ddcci: detecting 7:6e [ 23.561323] ddcci: detection failed: invalid identification response (2b != 6e) [ 23.561325] ddcci: received message was 2b c6 47 a5 43 37 ce 15 11 0f 5e ae 89 38 25 c9 55 41 1a 62 ff 9c 42 f6 20 d4 c7 27 3d 6c df f7 [ 23.608904] ddcci: detecting 10:6e [ 23.608909] ddcci: ddcci driver initialized [ 23.616410] ddcci: registering driver [ddcci-backlight] [ 23.616430] ddcci: driver [ddcci-backlight] registered After loading the ddcci module has completed, /sys/bus/ddcci/devices does not contain any nodes: $ ls -a /sys/bus/ddcci/devices . .. Loading ddcci-backlight succeeds, but /sys/class/backlight/ does not contain any new nodes: $ ls -al /sys/class/backlight/ insgesamt 0 drwxr-xr-x 2 root root 0 Sep 1 19:26 . drwxr-xr-x 61 root root 0 Sep 1 18:38 .. lrwxrwxrwx 1 root root 0 Sep 1 19:26 intel_backlight -> ../../devices/pci:00/:00:02.0/drm/card0/card0-eDP-1/intel_backlight The "intel_backlight" node refers to my laptop's internal monitor's backlight and is there regardless of whether the ddcci modules are loaded or not. To the exact questions: * What led up to the situation? I wanted to use the sysfs interface provided by the ddcci-backlight module to control my monitor's backlight, specifically at the evening hours. * What exactly did you do (or not do) that was effective (or ineffective)? I installed the ddcci-dkms package with apt-get and used modprobe(8) to first load the ddcci module, and then the ddcci-backlight module. Since that did not cause any change in the sysfs and left no messages in the dmesg, I added those two modules to /etc/modules and created the file /etc/modprobe.d/ddcci.conf with the following content: options ddcci dyndbg options ddcci-backlight dyndbg Then I rebooted. It resulted in the dmesg output given above. * What was the outcome of this action? The dmesg contained the lines given above. No new nodes in sysfs appeared. * What outcome did you expect instead? Instead of the error in the dmesg, nodes to control my monitor's backlight should have appeared in sysfs. -quintus [1]: https://www.dell.com/de-de/shop/dell-22-monitor-p2219h/apd/210-apwr/monitore-und-monitorzubeh%C3%B6r -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages ddcci-dkms depends on: ii dkms 2.6.1-4 ddcci-dkms recommends no packages. ddcci-dkms suggests no packages. -- no debconf information
Bug#969379: Reopening bug
Hello, I have to disagree. The GIT file has not been properly reviewed and should not be uploaded. Please keep the file attached on the bug report that has passed the Spanish translation team guidelines. Cheers, -- Camaleón
Bug#840897: general: framebuffer modules for non-dri graphics cards are not loaded
On Sun, 30 Aug 2020 19:08:00 +0200 Michael Biebl wrote: > Control: reassign -1 udev > Control: tags -1 + moreinfo > > Am 30.08.20 um 12:21 schrieb Chris Hofstaedtler: > > Control: reassign -1 systemd > > > > * Michal Suchanek : > >> So I would like the fbdev modules removed from whatever blacklist prevents > >> loading them and have them loaded on systems that don't have dri modules to > >> handle graphics. > > > > AFAICT systemd ships the fbdev blacklist nowadays, reassigning > > there. > > The udev package does (but it's src:systemd, so close enough) in > /lib/modprobe.d/fbdev-blacklist.conf > > I don't know the history behind this file though, it predates the > udev/systemd merge and a quick search in the old src:udev package did > not really yield anything useful. > > Hopefully Marco can chime in here and provide some context why it was > added and if it's still required thoday. The old-style fbdev drivers generally cannot coexist with user-mode graphics drivers or DRM drivers for the same devices (but the latter can coexist with each other). The fbdev API provides very little opportunity for X graphics acceleration, so it's generally preferable to use X with user-mode graphics drivers (or the newer combined DRM/KMS drivers). Therefore the fbdev drivers were blocked from auto-loading by default. I believe this file used to be a conffile in /etc so that it was possible to override it in case the user prefers the fbdev driver. This does not explain why listing atyfb in a modules list does not work; the "blacklist" directive should not affect that. Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence. signature.asc Description: This is a digitally signed message part
Bug#969387: ITP: wyhash -- fast, high-quality, portable hash function
Package: wnpp Severity: wishlist Owner: Benjamin Barenblat * Package name: wyhash Version : 0~1.gbpd15d6e7 Upstream Author : Wang Yi * URL : https://github.com/wangyi-fudan/wyhash * License : Unlicense Programming Lang: C Description : fast, high-quality, portable hash function Wyhash is a general-purpose non-cryptographic hash function. It produces high-quality output that passes the SMHasher test suite and is portable to 32- and 64-bit big- and little-endian platforms. Wyhash is small and quite fast, especially on 64-bit platforms. Wyhash is a header-only library, so there will only be a -dev package. There are some tags in the Wyhash Git repository, but none seems to correspond to what we would normally think of as a release; they seem more to indicate fundamental algorithm revisions. I’ll package and maintain this as a series of Git snapshots.
Bug#969386: Resolve file: not just file:///
X-Debbugs-cc: yama...@jpl.org Package: w3m-el-snapshot Version: 1.4.632+0.20200702.0409.dca01f9-1 Real w3m can deal fine with file:bla.txt and does not always need file:///full/path/to/bla.txt . But emacs-w3m says w3m--goto-url--valid-url: Wrong type argument: stringp, nil
Bug#969385: New upstream 1.74
Package: libboost-dev Version: 1.71.0.3 Severity: wishlist It would be nice to have a package for an updated version of boost. I've ran into a couple of packages that expect features from 1.73 already. At the time of writing, upstream is at 1.74
Bug#969384: wide-dhcpv6-client: proposed change to make ifupdown script compatible with NetworkManager
Package: wide-dhcpv6-client Version: 20080615-22 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** I am using NetworkManager to manage my connections and wide-dhcpv6-client for prefix delegation. Now I found an issue that the IPv6 addresses assigned to my LAN interfaces are not cleared when the internet connection goes down. So after the interface comes back, there will be multiple addresses assigned to a LAN interfaces and break the IPv6 connectivity. I found that part is managed by a script `dhcp6c-ifupdown`. By default, NetworkManager dispatches its connection updown events to ifupdown but it seems to me that it maps connection `down` event to `if-post-down.d` instead of `if-down.d`. So simply moving the symlink from `if-down.d` to `if-post-down.d` will make it compatible with NetworkManager. I created a PR at https://github.com/rogers0/packaging_wide-dhcpv6/pull/1 but it seems to me this package hasn't been updated for a while. Could you help take a look and help make the change happen? Let me know if you have any concerns. Thanks, Yuxiang Zhu -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/12 CPU cores) 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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wide-dhcpv6-client depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii libfl2 2.6.4-6.2 ii lsb-base 10.2019051400 ii sharutils 1:4.15.2-4 wide-dhcpv6-client recommends no packages. wide-dhcpv6-client suggests no packages. -- Configuration Files: /etc/wide-dhcpv6/dhcp6c.conf changed [not included] -- debconf information excluded
Bug#961345: cups: daemon crashes with invalid free()
Hello Ronny, > Incidentally, stopping the cups service (new packages) after a single print > job when under valgrind gave this in case it's related: > > Aug 28 10:03:59 samba-prn-01.graysofwestminster.co.uk systemd[1]: Stopping > CUPS Scheduler... > Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: > ==5238== Invalid free() / delete / delete[] / realloc() > Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: > ==5238==at 0x48369AB: free (vg_replace_malloc.c:538) > Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: > ==5238==by 0x4C73629: check_free (dlerror.c:202) > Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: > ==5238==by 0x4C73629: check_free (dlerror.c:186) > Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: > ==5238==by 0x4C73AB1: free_key_mem (dlerror.c:221) > Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: > ==5238==by 0x4C73AB1: __dlerror_main_freeres (dlerror.c:239) This might be what is described in here: https://sourceware.org/bugzilla/show_bug.cgi?id=24476 And I guess not related to the original issue. At least could not reproduce this message with libc6 2.31-3 in a up-to-date testing VM. > So running with the patched cups packages seems to fix the "invalid free" on > a test print. I've restored the systemd service file to remove valgrind so > let's see how we go on a day's printing. :-). Any news in this regard? Kind regards, Bernhard
Bug#969383: openldap fresh install /usr/sbin path bug /var/lib/dpkg/info/slapd.postinst
Control: tag -1 moreinfo Hello, On Tue, Sep 01, 2020 at 05:35:13PM +0100, SheridanJ West wrote: /var/lib/dpkg/info/slapd.postinst: slapadd: not found Does /usr/sbin/slapadd exist? Why is /usr/sbin not in the PATH for dpkg-reconfigure? I think you'll have problems with more packages than just slapd in that case...
Bug#969383: openldap fresh install /usr/sbin path bug /var/lib/dpkg/info/slapd.postinst
package: slapd apt file buster/main i386 slapd i386 2.4.47+dfsg-3+deb10u2 Attempting to figure out adding some ldap instances and have slapadd but your script file does not point near /usr/sbin. /usr/sbin/dpkg-reconfigure slapd Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.47+dfsg-3+deb10u2... done. Creating initial configuration... Loading the initial configuration from the ldif file () failed with the following error while running slapadd: /var/lib/dpkg/info/slapd.postinst: 833: /var/lib/dpkg/info/slapd.postinst: slapadd: not found Come to a halt and your postinst file is not easy to diagnose..
Bug#740369: libapache2-mod-python: needs python3 support
Control: tag -1 pending On salsa is the new upstream release 3.5.0.
Bug#883157:
Control: tag -1 pending On salsa is the new upstream release 3.5.0.
Bug#968509: Further crashes under linux-image-4.19.0-10-amd64
On 30/08/2020 13:37, Richard Kettlewell wrote: > On 30/08/2020 13:22, Salvatore Bonaccorso wrote: >> Hi Richard, Would you be able to test 4.19.142? >>> >>> If you can give me a route to getting .deb files for that version then >>> sure - a download or a pointer to instructions. >> >> *unofficial* and *temporary* builds for that version can be found >> here: https://people.debian.org/~carnil/tmp/linux/4.19.142-1/ >> >> If you prefer to build the package yourself, the source package of >> this temporary work is as well uploaded there. >> >> Please let me know if that works for your. > > Thankyou, I'm running that kernel now on the first host. I'll report > back when I know more. The first host has been running that kernel without incident for 48 hours and the second for nearly 24 hours. So it looks like 4.19.142 does fix this issue. ttfn/rjk
Bug#954289: openvpn: Incomplete handling of interrupted credentials prompt with auth-user-pass
Control: fixed -1 2.5~beta1-1 On Thu, Mar 19, 2020 at 07:34:45PM +0100, Tomáš Szaniszlo wrote: Dear Tomas, > It seems that openvpn does not handle SIGINT correctly when in client mode > with option auth-user-pass enabled. If I press ^C when presented with prompt > "Enter Auth Username: ", the terminal settings are not reset to a usable > state. Thanks for your report. According to my tests this is fixed in the 2.5 series, if we can identify the fixing commit we will issue a stable update. Bernhard
Bug#968942: openvpn: TCP socket backlog set too low
Control: fixed -1 2.4.9-1 On Mon, Aug 24, 2020 at 02:12:30PM +0200, Martin Zobel-Helas wrote: Hi, > Also the kernel at the exact same times had the following lines: > > # TCP: request_sock_TCP: Possible SYN flooding on port 1194. Dropping > request. Check SNMP counters. > > I digged a little bit around and found, that this seems to be a known > problem of openvpn below 2.4.8 on machines running kernels newer than > 4.3. > > This very same issue is described in [1]. The fix for this seems to be > [2]. Thanks, marking as such. I plan both a stable update and a buster-backport soon. Bernhard
Bug#969382: xssproxy FTCBFS: hard codes the build architecture pkg-config
Source: xssproxy Version: 1.0.0-1 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs xssproxy fails to cross build from source, because the upstream Makefile hard codes the build architecture pkg-config. After making it substitutable, xssproxy cross builds successfully. Please consider applying the attached patch. Helmut --- xssproxy-1.0.0.orig/Makefile +++ xssproxy-1.0.0/Makefile @@ -1,8 +1,9 @@ bindir = /usr/bin man1dir = /usr/share/man/man1 +PKG_CONFIG ?= pkg-config CFLAGS = -std=c11 -Wall -pedantic -g -O3 -CFLAGS_ALL = `pkg-config --cflags --libs glib-2.0 x11 xscrnsaver dbus-1` $(CFLAGS) +CFLAGS_ALL = `$(PKG_CONFIG) --cflags --libs glib-2.0 x11 xscrnsaver dbus-1` $(CFLAGS) .PHONY: all all: xssproxy xssproxy.1.gz
Bug#969380: [INTL:es] Spanish translation of the installation-guide template
Package: installation-guide Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Greetings, -- Camaleón install-methods.po.gz Description: application/gzip
Bug#969381: [INTL:es] Spanish translation of the installation-guide template
Package: installation-guide Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Greetings, -- Camaleón preseed.po.gz Description: application/gzip
Bug#969379: [INTL:es] Spanish translation of the installation-guide template
Package: installation-guide Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Greetings, -- Camaleón installation-howto.po.gz Description: application/gzip
Bug#969378: [INTL:es] Spanish translation of the installation-guide template
Package: installation-guide Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Greetings, -- Camaleón hardware.po.gz Description: application/gzip
Bug#969377: [INTL:es] Spanish translation of the installation-guide template
Package: installation-guide Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Greetings, -- Camaleón boot-installer.po.gz Description: application/gzip
Bug#969300: ITP: mmhelper -- A small program to help solving Mastermind puzzles.
On 31/08/2020 21:18, Paul Wise wrote: > On Mon, Aug 31, 2020 at 3:12 PM jathan wrote: > >> What does it mean "Control: reassign -1 wnpp" please? > > Control: lines in mails to bugs are passed to the > cont...@bugs.debian.org email address and -1 in such lines means "the > current bug". The reassign command changes which bug a package is > assigned to. The wnpp package is where all WNPP bugs (ITP/RFP/O/etc) > are assigned. > > https://www.debian.org/Bugs/server-control#reassign > https://wiki.debian.org/Glossary > Hi Paul, Thanks a lot for your explanation! I has been very useful to understand more :) Regards! Jathan -- Por favor evita enviarme adjuntos en formato de word o powerpoint, si quieres saber porque lee esto: http://www.gnu.org/philosophy/no-word-attachments.es.html ¡Cámbiate a GNU/Linux! http://getgnulinux.org/es signature.asc Description: OpenPGP digital signature
Bug#969376: openafs-client: Openafs cache erros on the logs
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. Kind regards Jose M Calhariz -- System Information: Debian Release: 10.5 Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openafs-client depends on: ii debconf [debconf-2.0] 1.5.71 ii init-system-helpers1.56+nmu1 ii libc6 2.28-10 ii libcom-err21.44.5-1+deb10u3 ii libhcrypto4-heimdal7.5.0+dfsg-3 ii libk5crypto3 1.17-3 ii libkrb5-26-heimdal 7.5.0+dfsg-3 ii libkrb5support01.17-3 ii libncurses66.1+20181013-2+deb10u2 ii libroken18-heimdal 7.5.0+dfsg-3 ii libtinfo6 6.1+20181013-2+deb10u2 ii lsb-base 10.2019051400 Versions of packages openafs-client recommends: ii lsof 4.91+dfsg-1 ii openafs-modules-dkms 1.8.6-1~dsi10+1 Versions of packages openafs-client suggests: pn openafs-doc ii openafs-krb5 1.8.6-1~dsi10+1 -- debconf information: * openafs-client/cachesize: 1400 * openafs-client/fakestat: true openafs-client/cell-info: * openafs-client/crypt: true * openafs-client/thiscell: ist.utl.pt * openafs-client/afsdb: true * openafs-client/run-client: true * openafs-client/dynroot: No
Bug#969172: buster-pu: package asterisk/1:16.2.1~dfsg-1+deb10u2
Hi, >>> Please go ahead. >> >> Thanks, upload has been ACCEPTED and built on all architectures. > > I think there may be some confusion. The new upload hasn't been built > on any architecture yet, as it's still in the stable-new queue awaiting > final review and acceptance: Err right, I mixed this up with an unblock request in my mind :-\ Bernhard
Bug#969375: ITP: smiles-scripts -- command line tools to handle SMILES descriptors
Package: wnpp Owner: Andrius Merkys Severity: wishlist * Package name: smiles-scripts Version : 0.2.0~svn212 Upstream Author : Saulius Gražulis * URL : https://projects.ibt.lt/repositories/projects/smiles-scripts * License : GPL-2.0 Programming Lang: Java, Perl Description : command line tools to handle SMILES descriptors Package provides command line tools to work with Simplified Molecular Input Line-Entry System (SMILES) descriptors. Package contains command line interface scripts for Chemistry Development Kit (CDK), as well as a syntax checker for SMILES descriptors. Disclaimer: I am one of the upstream developers. The package is described in Quirós et al. 2018, doi:10.1186/s13321-018-0279-6. I use its command line tools to validate SMILES syntax and produce SVG graphics for chemical compounds identified by SMILES descriptors. Remark: This package is to be maintained with Debichem Team at https://salsa.debian.org/debichem-team/smiles-scripts
Bug#969172: buster-pu: package asterisk/1:16.2.1~dfsg-1+deb10u2
On Tue, 2020-09-01 at 15:14 +0200, Bernhard Schmidt wrote: > Dear Adam, > > On Fri, 2020-08-28 at 16:56 +0200, Bernhard Schmidt wrote: > > > I would like to make a stable-update for asterisk. > > > > > > It fixes three minor CVEs (marked no-dsa) > > > > > > #940060 CVE-2019-15297: AST-2019-004: Crash when negotiating > > > for T.38 with a declined stream > > > #947377 CVE-2019-18610: AST-2019-007: AMI user could execute > > > system > > > commands > > > #947381 CVE-2019-18790: AST-2019-006: SIP request can change > > > address of a SIP peer > > > > > > It fixes one segmentation fault due to a wrong datatype when IPv6 > > > is > > > in use > > [...] > > > and one use-after-free that causes a misleading error message to > > > appear > > > > Please go ahead. > > Thanks, upload has been ACCEPTED and built on all architectures. I think there may be some confusion. The new upload hasn't been built on any architecture yet, as it's still in the stable-new queue awaiting final review and acceptance: asterisk | 1:16.2.1~dfsg-1+deb10u2 | stable-new | source Regards, Adam
Bug#954604: mailman-hyperkitty: FTBFS: dh_auto_test: error: pybuild --test --test-nose2 -i python{version} -p "3.7 3.8" returned exit code 13
Package: mailman-hyperkitty Version: 1.1.0-9 Followup-For: Bug #954604 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu groovy ubuntu-patch Dear Maintainer, since the last update to setuptools the autopkgtest/dh_auto_test is not running properly anymore, as pybuild tries to trigger them from with the (empty) build directory, which makes the tests fail. When run via nose2-3 from the source directory the tests pass as expected. *** /tmp/tmpolxgs94j/bug_body In Ubuntu, the attached patch was applied to achieve the following: * Avoid testing via pybuild, as it tries running tests from the empty build directory. Use nose2-3 instead, as defined via Build-Depends. (LP: #1892881) (Closes: #954604) Thanks for considering the patch. -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-42-generic (SMP w/4 CPU cores) 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=de_DE:en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru mailman-hyperkitty-1.1.0/debian/rules mailman-hyperkitty-1.1.0/debian/rules --- mailman-hyperkitty-1.1.0/debian/rules 2018-07-28 15:42:21.0 +0200 +++ mailman-hyperkitty-1.1.0/debian/rules 2020-09-01 15:18:47.0 +0200 @@ -4,3 +4,6 @@ %: dh $@ --with python3 --buildsystem=pybuild + +override_dh_auto_test: + nose2-3
Bug#969374: ITP: python-javaobj -- read and write Java objects serialized by ObjectOutputStream
Package: wnpp Severity: wishlist Owner: Hans-Christoph Steiner * Package name: python-javaobj Version : 0.4.1 Upstream Author : Thomas Calmant * URL : https://github.com/tcalmant/python-javaobj * License : Apache-2.0 Programming Lang: Python Description : read and write Java objects serialized by ObjectOutputStream python-javaobj is a Python library that provides functions for reading and writing (writing is WIP currently) Java objects serialized or will be deserialized by ObjectOutputStream. This form of object representation is a standard data interchange format in Java world. . The javaobj module exposes an API familiar to users of the standard library marshal, pickle and json modules. . * Java object instance un-marshalling * Java classes un-marshalling * Primitive values un-marshalling * Automatic conversion of Java Collections to Python ones (HashMap => dict, ArrayList => list, etc.) * Basic marshalling of simple Java objects (v1 implementation only) The original project https://github.com/vbuell/python-javaobj has not been maintained in 7 years and does not run on Python 3.x, so this uses the maintained fork which is also known as javaobj-py3.
Bug#907589: asterisk crashes when using PJSIP while processing registrations
Control: tags -1 moreinfo On Wed, Aug 29, 2018 at 10:09:48PM +0200, Joachim Foerster wrote: Dear Joachim, > I'm using Asterisk with its PJSIP backend. Every few hours Asterisk segfaults > in PJSIP library code. According to backtraces of coredumps the segfaults > seem to be related to SIP registration handling. I cannot say where the root > cause is, so I'm reporting this against asterisk and not the PJSIP library. Is this issue still there with Asterisk from Buster (which uses an embedded PJSIP library)? Bernhard
Bug#969172: buster-pu: package asterisk/1:16.2.1~dfsg-1+deb10u2
Dear Adam, > On Fri, 2020-08-28 at 16:56 +0200, Bernhard Schmidt wrote: >> I would like to make a stable-update for asterisk. >> >> It fixes three minor CVEs (marked no-dsa) >> >> #940060CVE-2019-15297: AST-2019-004: Crash when negotiating >> for T.38 with a declined stream >> #947377 CVE-2019-18610: AST-2019-007: AMI user could execute system >> commands >> #947381 CVE-2019-18790: AST-2019-006: SIP request can change >> address of a SIP peer >> >> It fixes one segmentation fault due to a wrong datatype when IPv6 is >> in use > [...] >> and one use-after-free that causes a misleading error message to >> appear > > Please go ahead. Thanks, upload has been ACCEPTED and built on all architectures. Bernhard
Bug#969370: wolfssl: Enable PKCS#11 support
On Tue, 1 Sep 2020 13:53:13 +0200 Bastian Germann wrote: > Please enable PKCS#11 support by using the --enable-pkcs11 configure option. By the way: The pkcs11.h header's license comment in upstream version 4.5.0 was modified to be GPL-2+ instead of GPL-3+ as with 4.4.0 and older.
Bug#969115: [debian-mysql] Bug#969115: mysql-5.7: FTBFS with GCC 10: multiple definition of symbols
tags 969115 + wontfix thanks Hi, Thank you for the FTBFS report. As it happens src:mysql-5.7 has been deprecated by src:mysql-8.0 and I filed a removal bug 969095 for src:mysql-5.7. So it seems pointless to fix this now. Robie On Thu, Aug 27, 2020 at 09:48:21PM +0200, Aurelien Jarno wrote: > Source: mysql-5.7 > Version: 5.7.26-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > mysql-5.7 fails to build from source with GCC 10: > > | [ 42%] Linking CXX shared module innodb_engine.so > | cd /<>/builddir/plugin/innodb_memcached/innodb_memcache && > /usr/bin/cmake -E cmake_link_script CMakeFiles/innodb_engine.dir/link.txt > --verbose=1 > | /usr/bin/x86_64-linux-gnu-g++ -fPIC -g -O2 > -fdebug-prefix-map=/<>=. > -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat > -Werror=format-security -fPIC -Wall -Wextra -Wformat-security -Wvla > -Wimplicit-fallthrough=2 -Woverloaded-virtual -Wno-unused-parameter -O3 -g > -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -std=gnu++03 > -DDBUG_OFF -fPIC -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro > -Wl,-z,now -shared -o innodb_engine.so > CMakeFiles/innodb_engine.dir/src/innodb_config.c.o > CMakeFiles/innodb_engine.dir/src/innodb_utility.c.o > CMakeFiles/innodb_engine.dir/src/hash_item_util.c.o > CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o > CMakeFiles/innodb_engine.dir/src/innodb_api.c.o > CMakeFiles/innodb_engine.dir/src/embedded_default_engine.c.o > CMakeFiles/innodb_engine.dir/src/handler_api.cc.o > CMakeFiles/innodb_engine.dir/cache-src/assoc.c.o > CMakeFiles/innodb_engine.dir/cache-src/items.c.o > CMakeFiles/innodb_engine.dir/cache-src/slabs.c.o -lpthread > ../../../archive_output_directory/libmysqlservices.a > ../../../archive_output_directory/liblibmcd_util.a -lpthread > | /usr/bin/ld: > CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:432: > multiple definition of `ib_cb_cfg_trx_level'; > CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:432: > first defined here > | /usr/bin/ld: > CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:436: > multiple definition of `ib_cb_cfg_bk_commit_interval'; > CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:436: > first defined here > | /usr/bin/ld: > CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:414: > multiple definition of `ib_cb_trx_release'; > CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:414: > first defined here > | /usr/bin/ld: > CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:398: > multiple definition of `ib_cb_tuple_delete'; > CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:398: > first defined here > | /usr/bin/ld: > CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:435: > multiple definition of `ib_cb_trx_get_start_time'; > CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:435: > first defined here > | /usr/bin/ld: > CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:413: > multiple definition of `ib_cb_trx_start'; > CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:413: > first defined here > | /usr/bin/ld: > CMakeFiles/innodb_engine.dir/src/innodb_engine.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:438: > multiple definition of `ib_cb_cursor_stmt_begin'; > CMakeFiles/innodb_engine.dir/src/innodb_config.c.o:./builddir/plugin/innodb_memcached/innodb_memcache/./plugin/innodb_memcached/innodb_memcache/include/innodb_cb_api.h:438: > first defined here > |
Bug#969372: uwsgi-emperor: SysV init script does nothing
Package: uwsgi-emperor Version: 2.0.18-1 Severity: grave Justification: renders package unusable Dear Maintainer, After installing uwsgi-emperor 2.0.18 it's impossible to change the running state of the service, as the provided init-script is doing nothing. This can be easily seen by the script being all of 27 lines long, ending just after setting up the variables, where the one from the 2.0.7 version has a total of 136 lines. As there is no SystemD unit present (as discussed in #833067) this means there is actually no way to start this service. Checking, it seems that this issue is also present in 2.0.14 from stretch, and is present in 2.0.19 for bullseye. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core) 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 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages uwsgi-emperor depends on: ii uwsgi-core 2.0.18-1 uwsgi-emperor recommends no packages. uwsgi-emperor suggests no packages. -- Configuration Files: /etc/default/uwsgi-emperor changed [not included] -- no debconf information
Bug#969371: hdf5plugin
Upstream uses hdf5plugin, but it can be patched out in 2 lines once https://salsa.debian.org/alteholz/bitshuffle/-/merge_requests/1 is merged.
Bug#969365: USB-C dock lacks multicast Ethernet functionality (so IPv6 is broken)
"Santiago R.R." writes:
> The patches proposed by Miguel Rodríguez have been merged upstream, and
> are part of 5.9-rc1 now. C.f. commits:
> 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6
> e10dcb1b6ba714243ad5a35a11b91cc14103a9a9
> e506addeff844237d60545ef4f6141de21471caf
> 0226009ce0f6089f9b31211f7a2703cf9a327a01
Note that
5fd99b5d9950 ("net: cdc_ncm: Fix build error")
should be included in this series for completeness.
It won't make any difference with the default Debian configuration,
where cdc_ether always is enabled, but it was an unfortunate glitch on
my side.
Bjørn
Bug#969371: ITP: bioxtasraw -- process biological small angle scattering data
Package: wnpp Severity: wishlist Owner: Sebastien Delafond X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: bioxtasraw Version : 2.0.2 Upstream Author : RAW, ESRF * URL : https://sourceforge.net/p/bioxtasraw/git/ * License : GPL-3 Programming Lang: Python Description : process biological small angle scattering data BioXTAS RAW is a GUI based, free, open-source Python program for reduction and analysis of small-angle X-ray solution scattering (SAXS) data. The software is designed for biological SAXS data. It provides an alternative to closed source programs such as Primus and Scatter for primary data analysis. Because it can calibrate, mask, and integrate images it also provides an alternative to synchrotron beamline pipelines that scientists can install on their own computers and use both at home and at the beamline.
Bug#969158: expeyes: maybe a false positive generated by mail_autoremovals.pl?
(note: this mail represents my opinions as an ordinary dd, I am not a member of the release team) due to the fact that it is supposed to (build-)depend on binutils-avr, which FTBFS. As I understand it "(build-)depends" should be interpreted as "depends or build-depends" The source package expeyes generates one binary package, microhope, which declares a dependency on avr-libc; should I downgrade this dependency down to a recommendation? The binary package microhope does not need binutils-avr as it is mainly an editor for small C or assembly language snippets. It needs binutils-avr only when the end user will try to compile and link one one the edited snippets. The package description for microhope implies that while it may technically be "mostly an editor" it's reason for existing is avr development. Downgrading the dependency to a reccomends is arguably correct (reccomends is described as "The Recommends field should list packages that would be found together with this one in all but unusual installations.") and would get the autoremovals tool out of your hair, but I would still question if a package that can't fulfill it's primary purpose belongs in a Debian release. IMO what really needs to happen here is that binutils-avr needs to be fixed, either by changing the actual code or by changing the compiler flags to make gcc less picky.
Bug#969370: wolfssl: Enable PKCS#11 support
Source: wolfssl Severity: wishlist Please enable PKCS#11 support by using the --enable-pkcs11 configure option.
Bug#969369: buster-pu: package node-elliptic/6.4.1_dfsg-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
node-elliptic allows ECDSA signature maleability via variations in
encoding, leading '\0' bytes, or integer overflows (CVE-2020-13822).
[ Impact ]
This could conceivably have a security-relevant impact if an application
relied on a single canonical signature.
[ Tests ]
No new test, however upstream tests are OK during build and autopkgtest
[ Risks ]
Upstream change is little (just some tests on inputs) and test coverage
seems good
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
Just some checks on inputs
diff --git a/debian/changelog b/debian/changelog
index 74b516f..3bc7a59 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+node-elliptic (6.4.1~dfsg-1+deb10u1) buster; urgency=medium
+
+ * Prevent malleability and overflows (Closes: CVE-2020-13822)
+
+ -- Xavier Guimard Tue, 01 Sep 2020 13:24:44 +0200
+
node-elliptic (6.4.1~dfsg-1) unstable; urgency=medium
[ upstream ]
diff --git a/debian/patches/CVE-2020-13822.patch
b/debian/patches/CVE-2020-13822.patch
new file mode 100644
index 000..179ecb9
--- /dev/null
+++ b/debian/patches/CVE-2020-13822.patch
@@ -0,0 +1,89 @@
+Description: signature: prevent malleability and overflows
+ CVE-2020-13822
+Author: Fedor Indutny
+Origin: upstream, https://github.com/indutny/elliptic/commit/856fe4d9
+Bug: https://github.com/indutny/elliptic/issues/226
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard
+Last-Update: 2020-09-01
+
+--- a/lib/elliptic/ec/signature.js
b/lib/elliptic/ec/signature.js
+@@ -33,11 +33,24 @@
+ return initial;
+ }
+ var octetLen = initial & 0xf;
++
++ // Indefinite length or overflow
++ if (octetLen === 0 || octetLen > 4) {
++return false;
++ }
++
+ var val = 0;
+ for (var i = 0, off = p.place; i < octetLen; i++, off++) {
+ val <<= 8;
+ val |= buf[off];
++val >>>= 0;
+ }
++
++ // Leading zeroes
++ if (val <= 0x7f) {
++return false;
++ }
++
+ p.place = off;
+ return val;
+ }
+@@ -61,6 +74,9 @@
+ return false;
+ }
+ var len = getLength(data, p);
++ if (len === false) {
++return false;
++ }
+ if ((len + p.place) !== data.length) {
+ return false;
+ }
+@@ -68,21 +84,37 @@
+ return false;
+ }
+ var rlen = getLength(data, p);
++ if (rlen === false) {
++return false;
++ }
+ var r = data.slice(p.place, rlen + p.place);
+ p.place += rlen;
+ if (data[p.place++] !== 0x02) {
+ return false;
+ }
+ var slen = getLength(data, p);
++ if (slen === false) {
++return false;
++ }
+ if (data.length !== slen + p.place) {
+ return false;
+ }
+ var s = data.slice(p.place, slen + p.place);
+- if (r[0] === 0 && (r[1] & 0x80)) {
+-r = r.slice(1);
+- }
+- if (s[0] === 0 && (s[1] & 0x80)) {
+-s = s.slice(1);
++ if (r[0] === 0) {
++if (r[1] & 0x80) {
++ r = r.slice(1);
++} else {
++ // Leading zeroes
++ return false;
++}
++ }
++ if (s[0] === 0) {
++if (s[1] & 0x80) {
++ s = s.slice(1);
++} else {
++ // Leading zeroes
++ return false;
++}
+ }
+
+ this.r = new BN(r);
diff --git a/debian/patches/series b/debian/patches/series
index 0ee9429..d86ab76 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
use-assert.patch
+CVE-2020-13822.patch
