Bug#744196: AHGRE
Do you received my last email ?
Bug#966230: RFP: overmix -- automatic anime screenshot stitching in high quality
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: overmix Version : 0.3.0 Upstream Author : Sebastian Wahl * URL : https://github.com/spillerrec/Overmix * License : GPL-3.0+ Programming Lang: C++ Description : automatic anime screenshot stitching in high quality Overmix can stitch fractions of smaller images together to create the original full image. It is specifically made for stitching anime screenshots, where a small portion of a scene is shown and the viewpoint slides to show the remaining area. The idea behind Overmix is to increase the amount of images which is used to stitch it together, and use this to solve MPEG compression, color banding and on-screen text/logo issues. Development is now geared towards understanding the more theoretical parts about Image Reconstruction and how this can be applied to increase quality even further. I think Debian can have this excellent program in the primary archive. -BEGIN PGP SIGNATURE- iQJEBAEBCgAuFiEElBWbaQfLEfz8kO8/ePhWwrW9dV4FAl8bw/4QHGd1cmlldi1u c0B5YS5ydQAKCRB4+FbCtb11Xsa2EAC5oxvbVsSyTQOLcjWFIwbYge88OLQEyI6b QhauRwOFN5muGh8i1RvuzPWqOikUg9spTZWQQln7hJ5QoDTAR8BEPGMHI0oBZnUt OLaD9USMpKMFLCkI3S8Ebde9VL7/PI1iDtYRbSW/4aa4yOB4DUNGiU7uVX02Y8lH muFj+aZhecev3oh+2csCBgf18TuReAcDkjQZDyq0FVtX656CSJJTkg8mGzMIDwaS bfKOhRPk1YHoaoJV1aCBH/TJcjKuNQTt8fv0biIUxXq6ykt0nZIi9Rl57TRUfUNL nFoRpT7Ylz/XGuP5Qrwi2SYzAyvN4VghUUD8bsBRJ6w8REJYHllHG+RoK2kppCzF MvHe2B2aJLJO2nktsR19ycueFvytb9bNRVCz0bLuo0/mUxCffT7obCHd8ZXFd/ZS 71fC4N8meExX7QK+b/oQfjwgR9Bub2xM9h/6G10eHVLSj5KnlQYmYGE/SyPO16Nt 5gwRz2t99Tb6owjuI3cnmqWuUViM/MnKbBxyg+5Y6fCpobro3KmEk7byasbk+xjf TxaGRNVvrNQkMFDsX+7e2q/1v6WzEf4aMyWTZjI5mVLxPqpVhR0crynreVDws8ck AnokcqEnUgjfSVi0+S+gzN5K97io1hasf5v+VwGfhzCUSOpvsCQ62zQBUlJFofej OtIm1qN1VA== =fR/w -END PGP SIGNATURE-
Bug#966009: golang-github-jung-kurt-gofpdf_2.17.2+ds-1_amd64.changes REJECTED
Hi Thorsten, On Fri, Jul 24, 2020 at 10:00:09PM +, Thorsten Alteholz wrote: > please also mention at least gofpdf-2.17.2/label.go in your debian/copyright. Fixed in new upload. Thanks for thorough checking Andreas. -- http://fam-tille.de
Bug#825336: isenkram-lookup: suggests enhancements to programs I don't use
On Fri, 2020-07-24 at 11:18 +0200, Petter Reinholdtsen wrote: > While I agree that this is unfortunate, I have no idea how to avoid it > without teaching isenkram about all packages and their relationship in > Debian, a feature I believe isenkram should not have. That seems reasonable. > Anyone got any ideas how to use the existing metadata in the package > archive to do better choices? For gkrellm-thinkbat the fact that it is a plugin combined with the fact that I don't have the dependencies installed should be enough to rule it out. Some plugins might use Enhances instead of Depends. $ apt-cache show gkrellm-thinkbat | grep -o 'role::[^ ,]*' role::plugin role::program $ apt-cache show gkrellm-thinkbat | grep Depends Depends: libc6 (>= 2.7), gkrellm (>= 2.0.0) I cannot think of any straight-forward way to avoid the tpb suggestion, a more complicated way might be to demote things not using the same uitoolkit:: tag as my current desktop, but there would still not be any way to know that tpb provides the same functionality as my desktop. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#897688: [Pkg-pascal-devel] Bug#897688: RFP: tomboy-ng -- simple note-taking application
Now, responding to a very old topic, and if I an doing wrong there, very sorry ! Its really an "attention Abou Al Montacir thing" ! Original message was from Erik about adding tomboy-ng to debian. It was quite rightly pointed out that tomboy-ng was not, then ready. I am the lead developer of tomboy-ng and think, perhaps, it is a lot closer now. Abou indicated he would be willing to help, is that still the case ? Background - tomboy-ng is a rewrite of the original Tomboy but using Free Pascal and Lazarus to avoid the run time libraries that are making Tomboy impracticable on many platforms. It is, now, reasonably stable, still requires a bit of UI polishing but is largely fully functional and largely bug free. I currently release binary debs (along with rpm, windows and MacOS packages) from github. I can now build a SRC Deb, not sure what you will think of the way I do it but it does work. While FPC/Lazarus does have minimal run time dependencies, build time does require some setup ! I will clearly require some assistance ! Davo On Mon, 07 May 2018 11:12:56 +0200 Abou Al Montacir wrote: > I would sponsor. > -- > Cheers, > Abou Al Montacir
Bug#966229: ITP: protocol -- a simple command line tool for displaying standard network protocol headers
Package: wnpp Severity: wishlist Owner: Vasudev Kamath * Package name: protocol Version : 0.1 Upstream Author : Luis MartinGarcia * URL : http://www.luismg.com/protocol/ * License : GPL-3.0 Programming Lang: Python Description : a simple command line tool for displaying standard network protocol headers Protocol is a simple command-line tool that serves two purposes: - Provide a simple way for engineers to have a look at standard network protocol headers, directly from the command-line, without having to google for the relevant RFC or for ugly header image diagrams. - Provide a way for researchers and engineers to quickly generate ASCII RFC-like header diagrams for their own custom protocols. - why is this package useful/relevant? It is useful for observing headers of Standard Network protocol without going to need to go through wiki page for protocol or from RFC documents. It is also helpful to generate RFC like ASCII header diagram for custom protocol. - how do you plan to maintain it? For now myself, might consider later to move it to Python application team.
Bug#966227: ITP: python-libzim -- Python bindings for the libzim library
Package: wnpp Severity: wishlist Owner: Kunal Mehta * Package name: python-libzim Version : 0.0.3 Upstream Author : openZIM developers * URL : https://github.com/openzim/python-libzim * License : GPL-3 Programming Lang: C++/Python Description : Python bindings for the libzim library python-libzim contains Python bindings for the libzim library, allowing for programmatic reading and creation of ZIM files in a manner that's easier and faster than shelling out to zimwriterfs (part of zim-tools). Many ZIM scrapers are being adapted to now use this Python library.
Bug#965062: systemd: Cannot resolve user name systemd-network: No such process
On Sun, Jul 19, 2020 at 03:40:41PM +0200, Michael Biebl wrote: > Maybe you start with a minimal debian system and turn that bit by bit > into a system like the one where you encounter the problem to see which > change is causing it. Unfortunately, I was away for a bit and when I returned some helpful person had it set up from scratch, deleting the old installation. I was told that /var/tmp had wrong permissions (1700 instead of 1777), so maybe that was the reason for the problem, although when I manually chmod 1700 /var/tmp, I can't reproduce the problem with the fresh setup, either. > I do also notice, that you run a 5.7.0 kernel. So this appears to be a > jessie->buster upgraded system with a mix of unstable/testing. > Maybe there is some configuration mixed/messed up. Certainly, although the kernel was added afterwards (the whole upgrade was to get a more recent kernel for newer hardware, and more specifically, a debian kernel, as we used mainlinme-ppa kernels before). On Sun, Jul 19, 2020 at 05:03:21PM +0200, Michael Biebl wrote: > getent passwd systemd-network Already sent this one - I don't think resolving the passwd/group entries were the problem, something else went wrong, and the problem here is just very bad error reporting. Anyway, I'm sorry to not be able to provide closure here, I did reserve the pxe environment for further debugging, but due to circumstances out of my control, it has been deleted. A fresh buster setup, not surprisingly, works fine. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#950473: Please stop using deprecated and headers
On Sun, May 31, 2020 at 05:30:30PM +0200, Laurent Bigonville wrote: > libselinux 3.1 rc1 has been uploaded in experimental and I'm planning to > upload the final version in unstable as soon as it's released in the > upcoming days/weeks. > > Could you please make sure that your package is ready? This will make your > package FTBFS as the and > headers will be gone. Ugh, sorry for the inconvenience - I'd neglected to subscribe to openssh-ssh1 bugs and so didn't notice this report. Fixing now. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#966122: Hangs when run under mc(1)
Hi Andrey, On Thu, Jul 23, 2020 at 4:03 AM Andrey Rahmatullin wrote: > > lintian 2.85.0 hang when run on any .deb from under mc. This issue is related to the mixing of IO::Async with other methods of forking processes. IO::Async replaces the SIGCHLD handler (and relies on it staying that way). When those calls are interleaved with calls to system(), strange things can happen. We have known about that for some time, but for the most part it worked great against all odds until the Heisenbug mentioned in commit cb45b444 brought the matter back into focus. Triage is under way and may entail dropping IO::Async from Lintian. We know this bug is urgent. The fix is coming soon. Kind regards Felix Lechner
Bug#966186: u-boot-omap: Unusable on BeagleBone Black
On 24/07/2020 20:50, Vagrant Cascadian wrote: > On 2020-07-24, rah wrote: >> For some reason, the u-boot environment has `board_name=BBG1` so it >> thinks the board is a BeagelBone Green. If I reset the environment, >> the board_name variable is set to: > > Have you used saveenv in the past on either or both the microSD or eMMC? I don't believe so. > If so, you may have to wipe the environment from the media If u-boot is reading environment from the media, wouldn't it make sense for u-boot to save the environment there as well? Regardless, where is the environment being read from? How can one wipe it? >> => saveenv >> Saving Environment to FAT... Unable to use mmc 0:1... Failed (1) >> == > Yes, vfat /boot is not supported by flash-kernel (or Debian in general). Debian's u-boot is trying to save its environment to a first FAT partition. If a vfat /boot is not supported, wouldn't it make sense to disable CONFIG_ENV_IS_IN_FAT? > Do you have any capes hooked up, or is it just a bare board? Bare board.
Bug#965355: transition: ace
Just an update: 'diagnostics' now builds fine with new binutils/2.35-1 and the RC bug has been closed. I have also tested it with ace 6.5.10+dfsg-1 version in experimental and it builds properly with that. -- Regards Sudip
Bug#964631: diagnostics: FTBFS: FAIL: stacktrace
Control: close -1 Hi, With the new binutils/2.35-1 it builds again. +--+ | Summary | +--+ Build Architecture: amd64 Build Type: full Build-Space: 225684 Build-Time: 149 Distribution: unstable Host Architecture: amd64 Install-Time: 38 Job: diagnostics Machine Architecture: amd64 Package: diagnostics Package-Time: 189 Source-Version: 0.3.3-12 Space: 225684 Status: successful Version: 0.3.3-12 Finished at 2020-07-24T23:02:17Z Build needed 00:03:09, 225684k disk space And, so I am closing this bug. Please re-open if you think this was a mistake. -- Regards Sudip
Bug#847513: ITA: vfu -- A versatile text-based filemanager
retitle 847513 ITA: vfu -- A versatile text-based filemanager owner 847513 ! thanks
Bug#958018: java-common: Provide some kind of latest-jre/latest-jdk packages
I would also like this. Usually, in the case of GCC or LLVM, they keep their metapackages in experimental following the newest major version. However, the OpenJDK metapackages in experimental point to OpenJDK 12 which doesn't appear to exist anymore, instead of version 14 or 15. So if java-common could be rebuilt in experimental, that'd be well sufficient. For anyone else interested in keeping ahead of changes, I do it with apt pinning since apt now supports pinning based on source packages: Package: src:gcc-defaults src:llvm-defaults Pin: release a=experimental Pin-Priority: 500 signature.asc Description: This is a digitally signed message part.
Bug#847513: ITA: vfu -- Versatile text-based filemanager
Package: wnpp Severity: normal Control: retitle 847513 ITA: vfu -- A versatile text-based filemanager Control: owner 847513 ! Control: thanks I intend to adopt the vfu package. Besides using it, I am well familiar with the code and have also contributed to the upstream project. The package description is: vfu is a nice filemanager using the ncurses library. It has many nice features: . * Fast one-key commands * Filename completion and wildcard expansion * Directory tree with sizes * File-type colorization * Archives support (TAR, TGZ, BZ2, and many more) * FTP support through archive-like interface * Internal text/hex file viewer and hex editor * Automount feature * Extensive user-defined external support/utils!
Bug#966226: wf-recorder cannot record to v4l2 devices
Package: wf-recorder Version: 0.2.1-1 Severity: normal X-Debbugs-Cc: paciorek.wojci...@googlemail.com Dear Maintainer, trying to use wf-recorder with an v4l2 loopback device fails: wf-recorder --muxer=v4l2 --codec=rawvideo --file=/dev/video2 selected region 0 0 0 0 [NULL @ 0x7f6454000cc0] Requested output format 'v4l2' is not a suitable output format Failed to allocate output context It would be great if wf-recorder would be built with v4l2 support, so this would be possible. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) 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 not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wf-recorder depends on: ii libavcodec587:4.3-3+b1 ii libavformat58 7:4.3-3+b1 ii libavutil56 7:4.3-3+b1 ii libc6 2.31-1 ii libgcc-s1 10.1.0-6 ii libpulse0 13.0-5 ii libstdc++6 10.1.0-6 ii libswresample3 7:4.3-3+b1 ii libswscale5 7:4.3-3+b1 ii libwayland-client0 1.18.0-1 wf-recorder recommends no packages. wf-recorder suggests no packages. -- no debconf information
Bug#966225: ITA: vfu -- Versatile text-based filemanager
Package: wnpp Severity: normal retitle 847513 ITA: vfu -- A versatile text-based filemanager owner 847513 ! I intend to adopt the vfu package. Besides using it, I am well familiar with the code and have also contributed to the upstream project. The package description is: vfu is a nice filemanager using the ncurses library. It has many nice features: . * Fast one-key commands * Filename completion and wildcard expansion * Directory tree with sizes * File-type colorization * Archives support (TAR, TGZ, BZ2, and many more) * FTP support through archive-like interface * Internal text/hex file viewer and hex editor * Automount feature * Extensive user-defined external support/utils!
Bug#966224: RM: ezmlm-idx/experimental -- RoQA; NPOASR; useless without qmail
Package: ftp.debian.org Severity: normal with qmail removed from the archive, there is no point in keeping the orphaned mailing list manager for it that never found its way out of experimental. Andreas
Bug#966119: popularity-contest: Unable to find runuser due to missing /sbin/ in PATH?
[Bill Allombert] > We would need to know which popcon version you installed first... > Maybe /var/log/dpkg.log still has the info. The first trace etckeeper have of popularity-contest is version 1.56 installed 2013-07-16 22:51+0200. I believe this was the initial installation. Then a small interlude with 1.63~pre2 before returning back to 1.56, followed by 1.61, 1.64 and finally 1.67. -- Happy hacking Petter Reinholdtsen
Bug#966223: Cannot install without wiping other packages
Package: unar
Version: 1.10.1-2+b6
With sid:
# aptitude install unar
The following NEW packages will be installed:
unar{b} (D: gnustep-base-runtime, D: libgnustep-base1.27, D: libobjc4)
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,274 kB of archives. After unpacking 6,124 kB will be used.
The following packages have unmet dependencies:
unar : Depends: gnustep-base-runtime (>= 1.27.0) but it is not installable
Depends: libgnustep-base1.27 (>= 1.27.0) but it is not installable
Depends: libobjc4 (>= 4.2.1) but it is not installable
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) unar [Not Installed]
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Remove the following packages:
1) guile-2.2-libs [2.2.7+1-5.1 (now, unstable)]
2) libgc1 [1:8.0.4-1 (now, unstable)]
3) libmailutils6 [1:3.9-3.1 (now, unstable)]
4) libmu-dbm6 [1:3.9-3.1 (now, unstable)]
5) mailutils [1:3.9-3.1 (now, unstable)]
6) w3m [0.5.3-38+b1 (now, unstable)]
7) w3m-el-snapshot [1.4.632+0.20200702.0409.dca01f9-1 (now, unstable)]
Install the following packages:
8) gnustep-base-common [1.27.0-3 (unstable)]
9) gnustep-base-runtime [1.27.0-3 (unstable)]
10) gnustep-common [2.8.0-1 (unstable)]
11) libgc1c2 [1:7.6.4-0.4 (unstable)]
12) libgnustep-base1.27 [1.27.0-3 (unstable)]
13) libobjc4 [10.1.0-6 (unstable)]
Bug#952369: terraintool: diff for NMU version 1.13-2.1
On 2020-07-24 18:28 -0300, Fabio Augusto De Muzio Tobich wrote: > Control: tags 952369 + pending > > > Dear maintainer, > > I've prepared an NMU for terraintool (versioned as 1.13-2.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer or cancel the NMU. Thanks for that fix. I have a mostly-prepared 0.14 here, which was waiting for upstream to make some other fixes, and to solve the javahelper build issue, but upstream seems to have stalled for now, so I'll upload 0.14 with your fix. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#966222: Please build with nbd support
Package: fio Version: 3.21-1 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org $ fio nbd.fio fio: engine nbd not loadable fio: failed to load engine Please consider building fio with nbd support enabled. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fio depends on: ii init-system-helpers 1.58 ii libaio1 0.3.112-8 ii libc62.31-2 ii libgfapi07.6-1 ii libibverbs1 29.0-1 ii libnuma1 2.0.12-1+b1 ii libpmem1 1.9-1 ii libpmemblk1 1.9-1 ii librados214.2.9-1+b1 ii librbd1 14.2.9-1+b1 ii librdmacm1 29.0-1 ii python3 3.8.2-3 ii zlib1g 1:1.2.11.dfsg-2 fio recommends no packages. Versions of packages fio suggests: pn gfio ii gnuplot-x11 [gnuplot] 5.2.8+dfsg1-2 pn python-scipy -- no debconf information
Bug#952369: terraintool: diff for NMU version 1.13-2.1
Control: tags 952369 + pending Dear maintainer, I've prepared an NMU for terraintool (versioned as 1.13-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer or cancel the NMU. Regards. Fabio Tobich diff -Nru terraintool-1.13/debian/changelog terraintool-1.13/debian/changelog --- terraintool-1.13/debian/changelog 2017-11-27 12:07:17.0 -0200 +++ terraintool-1.13/debian/changelog 2020-07-24 17:03:09.0 -0300 @@ -1,3 +1,12 @@ +terraintool (1.13-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: bumped javahelper dependency version in Build-Depends-Indep +field, in source stanza, to 0.74 or greater, to avoid a FTBFS caused by a +bug in jh_manifest (see #952370). (Closes: #952369) + + -- Fabio Augusto De Muzio Tobich Fri, 24 Jul 2020 17:03:09 -0300 + terraintool (1.13-2) unstable; urgency=medium * Readme updates diff -Nru terraintool-1.13/debian/control terraintool-1.13/debian/control --- terraintool-1.13/debian/control 2017-11-27 11:38:45.0 -0200 +++ terraintool-1.13/debian/control 2020-07-24 17:02:22.0 -0300 @@ -2,7 +2,7 @@ Section: science Priority: extra Maintainer: Wookey -Build-Depends-Indep: debhelper (>= 7.0.50~), javahelper (>= 0.32), default-jdk, docbook-to-man +Build-Depends-Indep: debhelper (>= 7.0.50~), javahelper (>= 0.74), default-jdk, docbook-to-man Standards-Version: 4.1.1 Homepage: http://www.ubss.org.uk/terraintool/terraintool.php
Bug#965964: ITP: geant4 -- physics simulation toolit from CERN
The package is now on mentors [1], the source code on Salsa [2]. Be warned, the source package is about 1.5GB big. This is mainly due to the large datasets. Without the datasets Geant4 is unusable (programs compile but don't start). As I already mentioned, the package quality is rather bad, lintian takes ages to run on this an the output is super long. Building also takes at least 15min btw. There a still a couple of things that can be done, and I would love some help if someone is interested. Here's a incomplete list: * proper copyright review * taking a look at /usr/share/Geant4-10.6.2/tools.license and find out to what it applies * building the doxygen documentation * write man pages for geant4-config and geant4-env * get rid of the recursive symlink (/usr/lib/x86_64-linux-gnu/Geant4-10.6.2/Linux-g++) * install the Python module * use Debians CLHEP library, it is in Debian but it needs to be updated to >= 2.4.1.0 * take care of the fonts * in geant4-env, use the user's shell instead of bash [1] https://mentors.debian.net/package/geant4/ [2] https://salsa.debian.org/stephanlachnit/geant4
Bug#966194: Wrong code in the report
Correct code that created the error message in valgrind:
#include
#include
#include
#define DIM 32
int main(void)
{
char *p = NULL;
p = malloc(DIM);
if(p == NULL)
{
printf("Allocation error.\n");
exit(1);
}
strcpy(p, "This is a test.");
for(int x = 0 ; x < DIM; ++x)
{
printf("%02x ", p[x]);
}
putchar('\n');
free(p);
return 0;
}
Bug#966145: apt-listbugs: [INTL:nl] Dutch po file for the apt-listbugs package
On Thu, 23 Jul 2020 21:17:27 +0200 Frans Spiesschaert wrote: [...] > Please find attached the updated Dutch po file for the apt-listbugs > package. Hello Frans! Thanks a lot for your contribution. It's always nice, when a translation update is received, without even the need to ask for it! ;-) I will add the update to the package soon. Bye and thanks again. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpqMrUasT4Fo.pgp Description: PGP signature
Bug#965481: ddclient: Removal of obsolete debhelper compat 5 and 6 in bookworm
On 2020-07-24 08:19, Torsten Landschoff wrote: Hmm, I uploaded the build on wednesday. dput did not complain but I still can't see the package in Debian. I saw a "ddclient_3.9.1-4_source.changes REJECTED" email: ddclient_3.9.1-4.dsc: Refers to non-existing file 'ddclient_3.9.1.orig.tar.gz' Perhaps you need to include the file in your upload? I actually spent quite a while fighting with pbuilder because I wanted to include the changelog of all versions that we did not upload to the archive (so that the closes: #... entries in changelog are applied). Looks like you figured it out. Thanks for uploading! For any lurkers out there curious about the solution, you can pass -v to dpkg-genchanges to get it to show more than just the latest entry: gbp buildpackage -v3.8.3-1.1
Bug#966186: u-boot-omap: Unusable on BeagleBone Black
Control: tags 966186 moreinfo On 2020-07-24, rah wrote: > I've successfully installed u-boot to an SD card and set my BeagleBone > Black to not boot from MMC. However, when u-boot runs, it cannot > boot the kernel: I've just booted a beaglebone black using the am335x_boneblack target and the am335x_evm target, and both work fine for me. > == > U-Boot SPL 2020.07+dfsg-1 (Jul 08 2020 - 23:29:02 +) > Trying to boot from MMC1 > > > U-Boot 2020.07+dfsg-1 (Jul 08 2020 - 23:29:02 +) > > CPU : AM335X-GP rev 2.1 > Model: TI AM335x BeagleBone Black > DRAM: 512 MiB > WDT: Started with servicing (60s timeout) > NAND: 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Loading Environment from FAT... Unable to use mmc 0:1... not set. > Validating first E-fuse MAC > Net: eth0: ethernet@4a10 > Warning: usb_ether MAC addresses don't match: > Address in ROM is de:ad:be:ef:00:01 > Address in environment is c8:df:84:dc:f1:6a > , eth1: usb_ether > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > SD/MMC found on device 0 > ** Unrecognized filesystem type ** > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found U-Boot script /boot/boot.scr > 1634 bytes read in 7 ms (227.5 KiB/s) > ## Executing script at 8000 > 4260352 bytes read in 277 ms (14.7 MiB/s) > SCRIPT FAILED: continuing... > ... > == > > > For some reason, the u-boot environment has `board_name=BBG1` so it > thinks the board is a BeagelBone Green. If I reset the environment, > the board_name variable is set to: Have you used saveenv in the past on either or both the microSD or eMMC? If so, you may have to wipe the environment from the media, as saveenv may have saved incompatible values from an old u-boot version. In general, I don't recommend using saveenv for this reason. > == > => env default -a - > ## Resetting to default environment > => pri > ... > board_name=am335x > ... > == > > Which likewise fails to boot: > > == > => boot > WARNING: Could not determine device tree to use > ... > == Unfortunately, even "env default -a" may not reset the values to the same state as an uninitialized environment, as it may run additional code to update the environment at boot... this is another reason I don't recommend using saveenv. > If I set the board_name variable to `A335BNLT` then it can boot OK. > However, I cannot save the environment using an ext2 root: > > == > => setenv board_name A335BNLT > => saveenv > Saving Environment to FAT... Unable to use mmc 0:1... Failed (1) > == > > > If I try to build an image using a vfat /boot partition then > flash-kernel causes an error while installing the kernel: > > == > Installing /usr/lib/linux-image-4.19.0-9-armmp/am335x-boneblack.dtb into > /boot/dtbs/4.19.0-9-armmp/./am335x-boneblack.dtb > Installing new am335x-boneblack.dtb. > /usr/bin/ln: failed to create symbolic link '/boot/dtb-4.19.0-9-armmp': > Operation not permitted > run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code > 1 > run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 > dpkg: error processing package linux-image-4.19.0-9-armmp (--configure): > installed linux-image-4.19.0-9-armmp package post-installation script > subprocess returned error exit status 1 > == Yes, vfat /boot is not supported by flash-kernel (or Debian in general). You might be able to save the environment to a different partition than the one used for /boot, but I don't have much experience with the pitfalls of using a saved environment. > So the package is unfortunatley unusable on the BeagleBone Black. I can't reproduce your problem with my BeagleBone Black, so I'm guessing there is something specific to your environment or configuration. Do you have any capes hooked up, or is it just a bare board? live well, vagrant signature.asc Description: PGP signature
Bug#966220: ITP: golang-github-evilsocket-islazy -- Set of opinionated packages, objects, helpers and functions
Package: wnpp Severity: wishlist Owner: Francisco Vilmar Cardoso Ruviaro X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net * Package name: golang-github-evilsocket-islazy Version : 1.10.6 Upstream Author : Simone 'evilsocket' Margaritelli * URL : https://github.com/evilsocket/islazy * License : GPL-3 Programming Lang: Go Description : Set of opinionated packages, objects, helpers and functions This package contains a Go library containing a set of opinionated (https://stackoverflow.com/questions/802050/what-is-opinionated-software) packages, objects, helpers and functions implemented with the KISS principle (https://en.wikipedia.org/wiki/KISS_principle) in mind.
Bug#966119: popularity-contest: Unable to find runuser due to missing /sbin/ in PATH?
On Thu, Jul 23, 2020 at 02:24:25PM +0200, Petter Reinholdtsen wrote: > [Bill Allombert] > > Hello Petter, long time no see! > > Yeah, too long. Real life happened. :) > > > Could you compare your /etc/cron.d/popularity-contest > > with the official one in 1.67 ? > > Not quite sure how to do that. But looking at > /var/lib/dpkg/info/popularity-contest.postinst, my version seem to lack > the PATH line. Any idea how that could happen? We would need to know which popcon version you installed first... Maybe /var/log/dpkg.log still has the info. Cheers, -- Bill. Imagine a large red swirl here.
Bug#962159: RFS: ddclient/3.9.1-1 [ITP] -- address updating utility for dynamic DNS services
On 2020-07-23 19:55, Chris Hofstaedtler wrote: * Richard Hansen [200723 23:54]: [ Martin Pitt ] * Drop obsolete initscripts dependency. /lib/init/vars.sh is now in the (required) sysvinit-utils. (Closes: #804975) . [ Christian Hofstaedtler ] * Bump Standards-Version to 3.9.8 (no changes required) * Update Vcs-Browser, Vcd-Git to use https URLs . These changes were already part of the 3.8.3-1.1 upload, so they should not be in the changelog for 3.9.x. They're not in the changelog for 3.9.x, though they used to be. Are you looking at the latest version? See: https://salsa.debian.org/debian/ddclient/-/blob/0cedc54476bca2c7bff6f3975beedd7e16dc20bb/debian/changelog#L76
Bug#966219: nmu: libcpuid_0.5.0+repack1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: by...@debian.org sunwea...@debian.org Package libcpuid just went through NEW and the amd64 binary was not built on buildd. This binNMU would rebuild binary on buildd. nmu libcpuid_0.5.0+repack1-1 . amd64 . unstable . -m "Rebuild on buildd" -- Regards, Boyuan Yang
Bug#966218: firmware: failed to load iwl-debug-yoyo.bin (-2)
Package: firmware-iwlwifi Version: 20200421-1 Severity: normal These two lines appear in the journal log indicating missing firmware, running `apt-file search iwl-debug-yoyo.bin` shows no matches for this firmware existing in any Debian package. Jul 22 23:21:52 debian kernel: iwlwifi :06:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2) Jul 22 23:21:52 debian kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (120, 'stable'), (110, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.137 -- no debconf information
Bug#966217: mystiq: Consider having package team-maintained in Debian Multimedia Team
Source: mystiq Version: 20.03.23-1 Severity: wishlist Dear Debian mystiq package maintainer, I believe mystiq is worthwhile to be team-maintained under Debian Multimedia Team (https://wiki.debian.org/DebianMultimedia). You may further read this Debian Wiki page on how the Multimedia Team works. If you are willing to have this package team-maintained in the multimedia- team, you are welcome to put "Debian Multimedia Maintainers < debian-multime...@lists.debian.org>" into the maintainer field or the uploaders field in your package. There is no need to further move the git packaging repo on Salsa GitLab since the current git repo can be made to be grant write permission to the multimedia-team members if necessary. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#966216: libxrdesktop-0.15-0: missing Breaks+Replaces: libxrdesktop-0.14-0
Package: libxrdesktop-0.15-0 Version: 0.15.1-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Selecting previously unselected package libxrdesktop-0.15-0:amd64. Preparing to unpack .../libxrdesktop-0.15-0_0.15.1-2_amd64.deb ... Unpacking libxrdesktop-0.15-0:amd64 (0.15.1-2) ... dpkg: error processing archive /var/cache/apt/archives/libxrdesktop-0.15-0_0.15.1-2_amd64.deb (--unpack): trying to overwrite '/usr/share/glib-2.0/schemas/org.xrdesktop.gschema.xml', which is also in package libxrdesktop-0.14-0:amd64 0.14.1-2 Errors were encountered while processing: /var/cache/apt/archives/libxrdesktop-0.15-0_0.15.1-2_amd64.deb cheers, Andreas libxrdesktop-0.14-0=0.14.1-2_libxrdesktop-0.15-0=0.15.1-2.log.gz Description: application/gzip
Bug#966215: mystiq: Please also enable build on other architectures
Source: mystiq Version: 20.03.23-1 Severity: minor Dear Debian mystiq maintainer, Thanks for maintaining package mystiq in Debian. I noticed that this software was instructed to only build on amd64 architecture. Ideally this package should be built on any architecture currently supported by Debian, not only limited to amd64. Is there any specific need in the package that can only be achieved on amd64? If the software can function well on other hardware architectures, please consider enabling build for them. This can be done by using "Architecture: any" instead of "Architecture: amd64" in debian/control file. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#966098: systemd: 'systemctl status' reports "access denied" after upgrade
Am 23.07.20 um 16:20 schrieb Michael Biebl: > Control: tags -1 + moreinfo unreproducible > > Am 23.07.20 um 03:13 schrieb Dima Kogan: >> Package: systemd >> Version: 245.6-3 >> Severity: grave >> X-Debbugs-Cc: none, Dima Kogan >> >> Hi. I'm running Debian/sid. Updating all the packages on my system put >> apt into a broken state: >> > > 239-15 is from 2 years ago. > Please update *all* packages besides systemd to their latest version > from sid. Then reboot. Then upgrade the systemd packages again. Please also upgrade systemd to 241-7~deb10u4 (then reboot) then upgrade to 245.6-3. Dist-upgrades are only tested from the last stable release. signature.asc Description: OpenPGP digital signature
Bug#966214: vienna-rna: FTBFS with GCC 10: multiple definition of ... due to -fno-common
Source: vienna-rna Version: 2.4.14+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, vienna-rna started to FTBFS when GCC 10 was made the default compiler: gcc -I./../../src/ViennaRNA -I./../../src -I/usr/include/json-c/ -I/usr/include/libsvm/ -Wl,-z,relro -o Kinfold baum.o cache.o globals.o main.o nachbar.o cmdline.o -fno-strict-aliasing -flto -L./../../src/ViennaRNA -lRNA -fopenmp -lgsl -lgslcblas -lmpfr -lgmp -lm /usr/bin/ld: globals.o:(.bss+0x0): multiple definition of `GSV'; baum.o:(.bss+0x0): first defined here /usr/bin/ld: globals.o:(.bss+0x60): multiple definition of `GAV'; baum.o:(.bss+0x60): first defined here /usr/bin/ld: globals.o:(.bss+0x8c0): multiple definition of `GTV'; baum.o:(.bss+0x8c0): first defined here /usr/bin/ld: main.o:(.bss+0x0): multiple definition of `GSV'; baum.o:(.bss+0x0): first defined here /usr/bin/ld: main.o:(.bss+0x60): multiple definition of `GAV'; baum.o:(.bss+0x60): first defined here /usr/bin/ld: main.o:(.bss+0x8c0): multiple definition of `GTV'; baum.o:(.bss+0x8c0): first defined here /usr/bin/ld: nachbar.o:(.bss+0x0): multiple definition of `GSV'; baum.o:(.bss+0x0): first defined here /usr/bin/ld: nachbar.o:(.bss+0x60): multiple definition of `GAV'; baum.o:(.bss+0x60): first defined here /usr/bin/ld: nachbar.o:(.bss+0x8c0): multiple definition of `GTV'; baum.o:(.bss+0x8c0): first defined here collect2: error: ld returned 1 exit status make[6]: *** [Makefile:485: Kinfold] Error 1 More information about the corresponding GCC change can be found here: https://gcc.gnu.org/gcc-10/porting_to.html "Default to -fno-common" Andreas
Bug#966212: autopkgtest fails with rails 6 in experimental
Package: ruby-js-image-paths Version: 0.1.1-1 Severity: important User: pkg-ruby-extras-maintain...@lists.alioth.debian.org Usertags: rails6-transition Control: forwarded -1 https://github.com/jhass/js_image_paths/issues/6 Hi, This package's autopkgtest and rebuilds failed with rails 6 currently in experimental. rails 6 will be uploaded to unstable in a weeks time, so please make sure this package is ready for rails 6. The severity of this bug will be raised to serious after rails 6 is uploaded to unstable. Relevant errors, GEM_PATH= ruby2.7 -e gem\ \"js_image_paths\" /usr/lib/ruby/2.7.0/rubygems/dependency.rb:313:in `to_specs': Could not find 'rails' (< 6.0, >= 4.0) - did find: [rails-6.0.3.1] (Gem::MissingSpecVersionError) Checked in 'GEM_PATH=/home/debci/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0', execute `gem env` for more information Full log https://people.debian.org/~praveen/rails6-meta-build/autopkgtest/ruby-js-image-paths.log Forwarded upstream at https://github.com/jhass/js_image_paths/issues/6
Bug#966213: buster-pu: package pillow/5.4.1-2+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
A few non-severe security issues, debdiff below.
Cheers,
Moritz
diff -Nru pillow-5.4.1/debian/changelog pillow-5.4.1/debian/changelog
--- pillow-5.4.1/debian/changelog 2020-02-06 20:47:20.0 +0100
+++ pillow-5.4.1/debian/changelog 2020-07-22 17:25:31.0 +0200
@@ -1,3 +1,9 @@
+pillow (5.4.1-2+deb10u2) buster; urgency=medium
+
+ * CVE-2020-11538 CVE-2020-10378 CVE-2020-10177
+
+ -- Moritz Mühlenhoff Wed, 22 Jul 2020 19:23:16 +0200
+
pillow (5.4.1-2+deb10u1) buster-security; urgency=medium
* CVE-2019-16865 CVE-2019-19911 CVE-2020-5311 CVE-2020-5312 CVE-2020-5313
diff -Nru pillow-5.4.1/debian/patches/CVE-2020-10177.patch
pillow-5.4.1/debian/patches/CVE-2020-10177.patch
--- pillow-5.4.1/debian/patches/CVE-2020-10177.patch1970-01-01
01:00:00.0 +0100
+++ pillow-5.4.1/debian/patches/CVE-2020-10177.patch2020-07-22
17:19:07.0 +0200
@@ -0,0 +1,154 @@
+Backport the following commits:
+c66d8aa75436f334f686fe32bca8e414bcdd18e6
+f6926a041b4b544fd2ced3752542afb6c8c19405
+b4e439d6d7fd986cd6b4c7f9ca18830d79dacd44
+c88b0204d7c930e3bd72626ae6ea078571cc0ea7
+c5edc361fd6450f805a6a444723b0f68190b1d0c
+8d4f3c0c5f2fecf175aeb895e9c2d6d06d85bdc9
+088ce4df981b70fbec140ee54417bcb49a7dffca
+5b490fc413dfab2d52de46a58905c25d9badb650
+
+--- pillow-5.4.1.orig/src/libImaging/FliDecode.c
pillow-5.4.1/src/libImaging/FliDecode.c
+@@ -24,7 +24,12 @@
+ #define I32(ptr)\
+ ((ptr)[0] + ((ptr)[1] << 8) + ((ptr)[2] << 16) + ((ptr)[3] << 24))
+
+-
++#define ERR_IF_DATA_OOB(offset) \
++ if ((data + (offset)) > ptr + bytes) {\
++state->errcode = IMAGING_CODEC_OVERRUN; \
++return -1; \
++ }
++
+ int
+ ImagingFliDecode(Imaging im, ImagingCodecState state, UINT8* buf, int bytes)
+ {
+@@ -78,10 +83,12 @@ ImagingFliDecode(Imaging im, ImagingCode
+ break; /* ignored; handled by Python code */
+ case 7:
+ /* FLI SS2 chunk (word delta) */
++ /* OOB ok, we've got 4 bytes min on entry */
+ lines = I16(data); data += 2;
+ for (l = y = 0; l < lines && y < state->ysize; l++, y++) {
+- UINT8* buf = (UINT8*) im->image[y];
++ UINT8* local_buf = (UINT8*) im->image[y];
+ int p, packets;
++ ERR_IF_DATA_OOB(2)
+ packets = I16(data); data += 2;
+ while (packets & 0x8000) {
+ /* flag word */
+@@ -91,29 +98,33 @@ ImagingFliDecode(Imaging im, ImagingCode
+ state->errcode = IMAGING_CODEC_OVERRUN;
+ return -1;
+ }
+- buf = (UINT8*) im->image[y];
++ local_buf = (UINT8*) im->image[y];
+ } else {
+ /* store last byte (used if line width is odd) */
+- buf[state->xsize-1] = (UINT8) packets;
++ local_buf[state->xsize-1] = (UINT8) packets;
+ }
++ ERR_IF_DATA_OOB(2)
+ packets = I16(data); data += 2;
+ }
+ for (p = x = 0; p < packets; p++) {
++ ERR_IF_DATA_OOB(2)
+ x += data[0]; /* pixel skip */
+ if (data[1] >= 128) {
++ ERR_IF_DATA_OOB(4)
+ i = 256-data[1]; /* run */
+ if (x + i + i > state->xsize)
+ break;
+ for (j = 0; j < i; j++) {
+- buf[x++] = data[2];
+- buf[x++] = data[3];
++ local_buf[x++] = data[2];
++ local_buf[x++] = data[3];
+ }
+ data += 2 + 2;
+ } else {
+ i = 2 * (int) data[1]; /* chunk */
+ if (x + i > state->xsize)
+ break;
+- memcpy(buf + x, data + 2, i);
++ ERR_IF_DATA_OOB(2+i)
++ memcpy(local_buf + x, data + 2, i);
+ data += 2 + i;
+ x += i;
+ }
+@@ -129,22 +140,27 @@ ImagingFliDecode(Imaging im, ImagingCode
+ break;
+ case 12:
+ /* FLI LC chunk (byte delta) */
++ /* OOB Check ok, we have 4 bytes min here */
+ y = I16(data); ymax = y + I16(data+2); data += 4;
+ for (; y < ymax && y < state->ysize; y++) {
+ UINT8* out = (UINT8*) im->image[y];
++ERR_IF_DATA_OOB(1)
+ int p, packets = *data++;
+ for (p = x = 0; p < packets; p++, x += i) {
++ ERR_IF_DATA_OOB(2)
+ x += data[0]; /* skip pixels */
+ if (data[1] & 0x80) {
+ i =
Bug#966211: trn4: FTBFS with GCC 10: multiple definition of ... due to -fno-common
Source: trn4 Version: 4.0-test77-12 Severity: serious Tags: ftbfs sid bullseye Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, trn4 started to FTBFS when GCC 10 was made the default compiler: gcc -Wl,-z,relro addng.o art.o artio.o artsrch.o autosub.o backpage.o bits.o cache.o charsubst.o datasrc.o decode.o edit_dist.o env.o final.o hash.o head.o help.o init.o intrp.o kfile.o last.o list.o mime.o ng.o ngdata.o ngsrch.o ngstuff.o only.o opt.o rcln.o rcstuff.o respond.o rthread.o rt-mt.o rt-ov.o rt-process.o rt-page.o rt-select.o rt-util.o rt-wumpus.o search.o sw.o term.o trn.o util.o util2.o uudecode.o parsedate.o nntpinit.o nntpclient.o nntpauth.o nntp.o wildmat.o color.o filter.o scan.o scmd.o sdisp.o smisc.o sorder.o spage.o scanart.o samain.o samisc.o sadisp.o sacmd.o sadesc.o sathread.o url.o mempool.o univ.o score.o scorefile.o scoresave.o score-easy.o tkstuff.o tktree.o -ltinfo -lm -lresolv -lnsl -o trn /usr/bin/ld: ng.o:./scan.h:105: multiple definition of `s_cur_type'; init.o:./scan.h:105: first defined here /usr/bin/ld: ng.o:./scan.h:96: multiple definition of `s_flags'; init.o:./scan.h:96: first defined here /usr/bin/ld: ng.o:./scan.h:95: multiple definition of `s_ptr_page_line'; init.o:./scan.h:95: first defined here /usr/bin/ld: ng.o:./scan.h:93: multiple definition of `s_desc_cols'; init.o:./scan.h:93: first defined here /usr/bin/ld: ng.o:./scan.h:92: multiple definition of `s_itemnum_cols'; init.o:./scan.h:92: first defined here /usr/bin/ld: ng.o:./scan.h:91: multiple definition of `s_cursor_cols'; init.o:./scan.h:91: first defined here /usr/bin/ld: ng.o:./scan.h:90: multiple definition of `s_status_cols'; init.o:./scan.h:90: first defined here /usr/bin/ld: ng.o:./scan.h:89: multiple definition of `s_bot_lines'; init.o:./scan.h:89: first defined here /usr/bin/ld: ng.o:./scan.h:88: multiple definition of `s_top_lines'; init.o:./scan.h:88: first defined here /usr/bin/ld: ng.o:./scan.h:86: multiple definition of `s_ref_desc'; init.o:./scan.h:86: first defined here /usr/bin/ld: ng.o:./scan.h:85: multiple definition of `s_ref_status'; init.o:./scan.h:85: first defined here /usr/bin/ld: ng.o:./scan.h:83: multiple definition of `s_ref_bot'; init.o:./scan.h:83: first defined here /usr/bin/ld: ng.o:./scan.h:82: multiple definition of `s_ref_top'; init.o:./scan.h:82: first defined here /usr/bin/ld: ng.o:./scan.h:81: multiple definition of `s_ref_all'; init.o:./scan.h:81: first defined here /usr/bin/ld: ng.o:./scan.h:79: multiple definition of `s_refill'; init.o:./scan.h:79: first defined here /usr/bin/ld: ng.o:./scan.h:78: multiple definition of `s_bot_ent'; init.o:./scan.h:78: first defined here /usr/bin/ld: ng.o:./scan.h:77: multiple definition of `s_top_ent'; init.o:./scan.h:77: first defined here /usr/bin/ld: ng.o:./scan.h:75: multiple definition of `page_ents'; init.o:./scan.h:75: first defined here /usr/bin/ld: ng.o:./scan.h:73: multiple definition of `s_page_size'; init.o:./scan.h:73: first defined here /usr/bin/ld: ng.o:./scan.h:71: multiple definition of `s_ent_index_max'; init.o:./scan.h:71: first defined here [...] More information about the corresponding GCC change can be found here: https://gcc.gnu.org/gcc-10/porting_to.html "Default to -fno-common" Andreas
Bug#966210: src:django-ranged-response: fails to migrate to testing for too long: maintainer built arch:all binary
Source: django-ranged-response Version: 0.2.0-2 Severity: serious Control: close -1 0.2.0-4 Tags: sid bullseye pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:django-ranged-response in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=django-ranged-response signature.asc Description: OpenPGP digital signature
Bug#966209: src:debianutils: fails to migrate to testing for too long: autopkgtest failure
Source: debianutils Version: 4.9.1 Severity: serious Control: close -1 4.11 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 961872 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:debianutils in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=debianutils signature.asc Description: OpenPGP digital signature
Bug#928197: libmp3-tag-perl: diff for NMU version 1.13-1.2
Control: tags 928197 + pending
Dear maintainer,
I've prepared an NMU for libmp3-tag-perl (versioned as 1.13-1.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.
In general, I suggest to move the package to the pkg-perl group to
broaden the maintainer basis.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Schmetterlinge: Verhandlung Thiers - Moltke
diff -Nru libmp3-tag-perl-1.13/debian/changelog libmp3-tag-perl-1.13/debian/changelog
--- libmp3-tag-perl-1.13/debian/changelog 2017-07-12 21:25:22.0 +0200
+++ libmp3-tag-perl-1.13/debian/changelog 2020-07-24 20:24:18.0 +0200
@@ -1,3 +1,13 @@
+libmp3-tag-perl (1.13-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix "Perl 5.28 warning: Unescaped left brace in regex is deprecated
+here (and will be fatal in Perl 5.32)":
+add patch from Gerald Turner to escape some more left braces.
+(Closes: #928197)
+
+ -- gregor herrmann Fri, 24 Jul 2020 20:24:18 +0200
+
libmp3-tag-perl (1.13-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru libmp3-tag-perl-1.13/debian/patches/03_fix_more_escapes.patch libmp3-tag-perl-1.13/debian/patches/03_fix_more_escapes.patch
--- libmp3-tag-perl-1.13/debian/patches/03_fix_more_escapes.patch 1970-01-01 01:00:00.0 +0100
+++ libmp3-tag-perl-1.13/debian/patches/03_fix_more_escapes.patch 2020-07-24 20:17:03.0 +0200
@@ -0,0 +1,31 @@
+Description: fix another "unescaped left brace" error
+Author: Gerald Turner
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/928197
+Forwarded: not-needed
+Applied-Upstream: fixed in 1.15
+Last-Update: 2019-04-29
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: libmp3-tag-perl-1.13/lib/MP3/Tag.pm
+===
+--- libmp3-tag-perl-1.13.orig/lib/MP3/Tag.pm
libmp3-tag-perl-1.13/lib/MP3/Tag.pm
+@@ -2941,7 +2941,7 @@ sub format_time {
+ local $self->{ms} = int($time * 1000 + 0.5) if defined $time;
+ my ($out, %have, $c) = '';
+ for my $f (@_) {
+-$have{$+}++ if $f =~ /^\??({([^{}]+)}|.)/;
++$have{$+}++ if $f =~ /^\??(\{([^{}]+)}|.)/;
+ }
+ for my $f (@_) {
+ if (!$c++ and $f =~ /^=>(\w)$/) {
+@@ -2953,7 +2953,7 @@ sub format_time {
+ }
+ my $ff = $f; # Modifiable
+ my $opt = ($ff =~ s/^\?//);
+-$ff =~ s/^({[^{}]+}|\w)// or die "unexpected time format: <<$f>>";
++$ff =~ s/^(\{[^{}]+}|\w)// or die "unexpected time format: <<$f>>";
+ my ($what, $format) = ($1, '');
+ if ($opt) {
+ if ($what eq 'H') {
diff -Nru libmp3-tag-perl-1.13/debian/patches/series libmp3-tag-perl-1.13/debian/patches/series
--- libmp3-tag-perl-1.13/debian/patches/series 2017-07-12 21:22:53.0 +0200
+++ libmp3-tag-perl-1.13/debian/patches/series 2020-07-24 20:17:03.0 +0200
@@ -1,2 +1,3 @@
01_spelling.patch
02_fix_escape.patch
+03_fix_more_escapes.patch
signature.asc
Description: Digital Signature
Bug#966208: libconfig-model-dpkg-perl: Add support for upstream/metadata file
Package: libconfig-model-dpkg-perl Version: 2.137 Severity: wishlist Dear Maintainer, Please add support for upstream/metadata file [1]. I think this task can be done by people willing to learn a bit more about Config::Model, but it does not require much knowledge of Perl. This task requires to run 'cme meta edit' in libconfig-model-dpkg-perl repository and create with the GUI the following items: - Create a new Dpkg::Metadata config class - add in this class the DEP-12 parameters as described in [1]. Please also add the parameter description to provide on-line doc - add a YAML backend for Dpkg::Metadata config class - specify the target file for the YAML backend (debian/upstream/metadata) - add a metadata node element in Dpkg class with configuration_class set to Dpkg::Metadata - add relevant tests in t/model_test.t/ See also https://github.com/dod38fr/config-model/wiki/How-to-add-a-new-parameter-to-an-existing-model I'll provide help in case of problem. Any taker ? All the best [1] https://wiki.debian.org/UpstreamMetadata -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 libconfig-model-dpkg-perl depends on: ii debhelper 13.2 ii libapt-pkg-perl0.1.36+b3 ii libarray-intspan-perl 2.004-1 ii libconfig-model-backend-yaml-perl 2.133-2 ii libconfig-model-perl 2.139-1 ii libexporter-lite-perl 0.08-1 ii liblog-log4perl-perl 1.50-1 ii libmouse-perl 2.5.10-1 ii libparse-recdescent-perl 1.967015+dfsg-2 ii libsoftware-licensemoreutils-perl 1.004-1 ii libsort-versions-perl 1.62-1 ii libtext-autoformat-perl1.75-1 ii libtext-levenshtein-damerau-perl 0.41-1 ii liburi-perl1.76-2 ii libwww-perl6.46-1 ii libyaml-libyaml-perl 0.82+repack-1 ii licensecheck 3.0.47-1 ii lintian2.85.0 ii perl [libmodule-corelist-perl] 5.30.3-4 Versions of packages libconfig-model-dpkg-perl recommends: ii libconfig-model-tkui-perl 1.371-2 libconfig-model-dpkg-perl suggests no packages. -- no debconf information
Bug#965217: libgrpc++1: ServerBuilder::BuildAndStart hangs
Hello László, I can confirm the fix. You could add the following as an autopkg test: dependencies: libprotobuf-dev pkg-config protobuf-compiler-grpc protobuf-compiler libgrpc-dev libgrpc++-dev $ cd /examples/cpp/helloworld $ make $ ./greeter_server & ./greeter_client # Server listening on 0.0.0.0:50051 Greeter received: Hello world Thanks! On Fri, Jul 24, 2020 at 6:12 PM László Böszörményi (GCS) wrote: > On Fri, Jul 24, 2020 at 3:48 PM Benjamin Barenblat > wrote: > > I’ve just reuploaded Abseil with an shlibs file instead of a symbols > > file. The symbols file doesn’t buy us a whole lot anyway, since Abseil > > is going to break ABI with every release. > It worked, builds are correct this time. Just uploaded gRPC 1.30.2 to > unstable now. > @Michael: Please test it and report back if it still hangs for you and > / or any other patch you need applied. >
Bug#639104: taglib: Missing static library.
Control: tags -1 -wontfix Control: tags -1 +help On Sat, 31 Aug 2013 01:59:24 +1000 Reuben wrote: > > Why is it so strong as 'should'? According to what? On the same basis > you > > could argue that all libraries in Debian should do this but you won't > get very > > far with this reasoning. Debian *prefers* shared libraries because > you can > > provide sane security support for them. > > Because it is in the package description > (http://packages.debian.org/sid/libtagc0-dev): > "This is the development package which contains headers and static libraries > for the TagLib Audio Meta-Data Library." Hi, I'm writting to let you know that I strongly disagree with the position that the old package maintainer held. Even though Debian prefers shared libraries, Debian's preference on its internal policy should not block various external needs from users. I still consider this bug as a valid feature request. Now that I have taken over the package maintainership (and have it team- maintained under the Multimedia Team), I will accept patches for adding a static library but I do not have time to implement it myself. I strongly recommend having your patch sent to taglib upstream first and give a reference link in this bug report after that. Any help would be appreciated. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#966207: RM: infon -- ROM; No longer actively maintained
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, while requesting removal of `metainit` I noticed that this is still used by the `infon` package. This, too, has probably little value these days and I don’t mind if it is removed. Cheers, Joachim -BEGIN PGP SIGNATURE- iHEEARECADEWIQQxTjstYFpus1p9gRn2KOuTR0MgbAUCXxsciBMcbm9tZWF0YUBk ZWJpYW4ub3JnAAoJEPYo65NHQyBsaI0Anii60ChD3xat2tZv/8lG6U/XrzBAAKCz Tx4yj9JieitEn7wjGfHgAP1HSg== =DDD+ -END PGP SIGNATURE-
Bug#966206: RM: metainit -- ROM; Obsolete, unused
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nudged by #965722 I think it’s probably best to remove metainit. I wrote that 13 years ago to alleivate the pains during the init system wars, but it never caught on, and is quite obsolete now. If someone disagrees feel free to take over the package. -BEGIN PGP SIGNATURE- iHEEARECADEWIQQxTjstYFpus1p9gRn2KOuTR0MgbAUCXxsbsxMcbm9tZWF0YUBk ZWJpYW4ub3JnAAoJEPYo65NHQyBsV80AnRMMeHtJDmyCgmOyTbucLidMekwgAJ9M CseFz5s5B9crRe3BzOZMwZTgVA== =TsU9 -END PGP SIGNATURE-
Bug#965969: inkscape: Crash when using some cursor themes
Thank you for the quick response and fix! I've already pulled the update and it has fixed the problem. On Tue, Jul 21, 2020, 12:30 PM wrote: > Control: forwarded -1 https://gitlab.com/inkscape/inbox/-/issues/1807 > Control: tag -1 upstream fixed-upstream > Control: severity -1 normal > > On Tue, Jul 21, 2020 at 12:07:55PM -0500, Michael Johnson wrote: > > When run from the command line, I get the following: > > > > Gdk-Message: 11:41:59.818: Unable to load sb_up_arrow from the > cursor theme > > > > Emergency save activated! > > Emergency save completed. Inkscape will close now. > > > > It looks like this will probably be fixed in an upcoming version of > Inkscape, > > as > > https://gitlab.com/inkscape/inbox/-/issues/1807 seems to match my issue > and has > > a three line patch. However, I'm not sure on the time frame as the > ticket was > > opened 5 months ago. > > Thanks for the throughout investigation, that makes my life sensibly > easier. > > I'll go and pick > > https://gitlab.com/inkscape/inkscape/-/commit/c4d387e289c03a90f41ffef7e8d0a7292219d7b7 > into the debian package soon then :) > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > More about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- >
Bug#965964: ITP: geant4 -- physics simulation toolit from CERN
Hi Peter, > according to [0] the Geant4 license is not DFSG compliant. > > Peter > > [0] https://wiki.debian.org/DebianScience/Geant4 The relevant part of the license [1] mentioned on the wiki page is: > 5. You may not include this software in whole or in part in any patent > or patent application in respect of any modification of this software > developed by you. I don't see how this doesn't comply with the DFSG. It doesn't limit derived works, it doesn't discriminate anyone, and it isn't specific to Debian or any other software product. I'm not a lawyer though, but if indeed isn't compliant with the DFSG, I would still want to see this in non-free. Cheers, Stephan [1] https://geant4.web.cern.ch/license/license
Bug#966096: geeqie: immediate segfault
Sorry, it already says image.use_clutter_renderer = "false" On Fri, Jul 24, 2020 at 11:13 AM Andreas Ronnquist wrote: > On Fri, 24 Jul 2020 10:21:03 -0400 > James Van Zandt wrote: > > >Alas, no. Same symptom. > > > >FWIW, I'm attaching the tail end of an strace log, and a (long) list > >of the shared libraries used, per ldd. I note that in the latter > >list, there are no nvidia libraries - but the strace log shows it was > >looking for (and apparently not finding) libGLX_nvidia.so.0. apt-find > >indicates that library can be found in these packages: > > > > > >$ apt-file search libGLX_nvidia.so.0 > >libglx-nvidia-legacy-390xx0: > >/usr/lib/x86_64-linux-gnu/nvidia/legacy-390xx/libGLX_nvidia.so.0 > >libglx-nvidia-tesla-418-0: > >/usr/lib/x86_64-linux-gnu/nvidia/tesla-418/libGLX_nvidia.so.0 > >libglx-nvidia-tesla-440-0: > >/usr/lib/x86_64-linux-gnu/nvidia/tesla-440/libGLX_nvidia.so.0 > >libglx-nvidia-tesla-450-0: > >/usr/lib/x86_64-linux-gnu/nvidia/tesla-450/libGLX_nvidia.so.0 > >libglx-nvidia0: > >/usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 > > > > > >I don't suppose the tesla packages are relevant, and apt-get isn't > >able to find the other two. The first is supposed to be in non-free. > >My /etc/apt/sources.list already includes > > > >deb http://ftp.us.debian.org/debian/ unstable main contrib non-free > > > >Should I have something else configured to access that package? > > > > What if you edit your config (in ~/.config/geeqie/geeqierc.xml), and > change the line > > image.use_clutter_renderer = "true" > > (which I assume it is set to), to > > image.use_clutter_renderer = "false" > > ? > > /Andreas >
Bug#953075: debian-reference: Incorrect environment example for 'date' in section 1.5.2
I see. If you "export" LC_TIME, then that may have priority ... Please check output of "export" My system is free from /etc/locale.conf My "export" output for locale related variables are only with declare -x LANG="en_US.UTF-8" declare -x LANGUAGE="en_US:en" Maybe changing example to use LC_ALL $ export LC_TIME=en_US.UTF-8 $ LC_ALL=fr_CA.UTF-8 date samedi 25 juillet 2020, 02:08:20 (UTC+0900) $ LANG=fr_CA.UTF-8 date Sat 25 Jul 2020 02:08:34 AM JST On Fri, 2020-07-24 at 12:08 -0400, Hank Knox wrote: > locales-all got installed by this morning's full-upgrade, but the > issue > is the same. > > I think my problem is having an /etc/locale.conf file with a bunch > of > LC_ variables set. I don't know where that file came from, perhaps a > previous installation that got copied into the new one. > > Hank > > On 2020-07-24 11:39 a.m., Osamu Aoki wrote: > > Oops, > > > > I think your problem goes out if you install the locales-all > > package > > > > I forgot to ask: > > > > $ dpkg -l locales* > > > > If you didn't install locales-all package or generate fr_CA.UTF-8 > > locale data manually by running the following > > > > $ sudo dpkg-reconfigure locales > > > > You get English ... didn't I mention this ... Yes: > > > > For fine details of the locale configuration, see Section 8.4, > > “The > > locale”. > > > > You should have clicked there to read Section 8.4. But not so > > obvious > > ... Now I know ... > > > > Ububtu and Old Debian's locales are like locales-all on recent > > Debian. > > > > Current Debian's locales are small and requires user to configure > > it > > manually while locales-all is huge and pre-confugured > > > > Maybe it is good idea to guide people to the locales-all package > > > > On Fri, 2020-07-24 at 09:38 -0400, Hank Knox wrote: > > > Thank you for taking the time to respond to this. > > > > > > I was reading the Debian Reference shortly after a clean install > > > of > > > bullseye. (It's a very useful document, BTW, thanks for doing > > > it.) > > > However I have been running Debian for years and migrated some > > > config > > > files over from a previous installation so perhaps my setup does > > > not > > > reflect the usual defaults. > > > > > > Here is the info you asked for: > > > > > > hank@SunVillage:~$ locale > > > LANG=en_CA.utf8 > > > LANGUAGE= > > > LC_CTYPE="en_CA.utf8" > > > LC_NUMERIC=en_CA.UTF-8 > > > LC_TIME=en_CA.UTF-8 > > > LC_COLLATE="en_CA.utf8" > > > LC_MONETARY=en_CA.UTF-8 > > > LC_MESSAGES="en_CA.utf8" > > > LC_PAPER=en_CA.UTF-8 > > > LC_NAME=en_CA.UTF-8 > > > LC_ADDRESS=en_CA.UTF-8 > > > LC_TELEPHONE=en_CA.UTF-8 > > > LC_MEASUREMENT=en_CA.UTF-8 > > > LC_IDENTIFICATION=en_CA.UTF-8 > > > LC_ALL= > > > > > > hank@SunVillage:~$ echo > > > $XDG_CURRENT_DESKTOP='XDG_CURRENT_DESKTOP' > > > XFCE=XDG_CURRENT_DESKTOP > > > > > > I am not sure what is setting the various LC_ variables. I > > > grepped > > > my > > > home directory, /etc/bash.bashrc and /etc/profile and the only > > > result > > > that references LC_ is > > > ".xsession-errors:dbus-update-activation-environment: setting > > > LC_TIME=en_CA.UTF-8" in my home directory; there are similar > > > entries > > > for > > > all the other LC_ variables in my environment. Is there some > > > configuration of dbus that sets those variables? If so, I don't > > > know > > > where that is configured. I fear I have enough Linux experience > > > to > > > get > > > in trouble but not enough to be really knowledgeable! > > > > > > Best, > > > > > > Hank Knox > > > > > > On 2020-07-23 10:44 p.m., Osamu Aoki wrote: > > > > Hmmm... > > > > > > > > I agree this is probably not a bug but a user support > > > > problem. Let > > > > me > > > > add a comment: > > > > > > > > I chose to use $LANG to set the locale since that seems to be > > > > the > > > > way > > > > default install configures used by Debian system. > > > > > > > > Hank, if you are facing this issue on some default install > > > > system > > > > without violating my recommendation, let is know your desktop > > > > etc. > > > > > > > > Please run the following to check: > > > > > > > > $ locale > > > > $ echo "XDG_CURRENT_DESKTOP='$XDG_CURRENT_DESKTOP'" > > > > > > > > Report it back to this bug > > > > > > > > Hank, anyway did you read on to the last part of 1.5.2 first: > > > > > > > > See locale(5) and locale(7) for "$LANG" and related > > > > environment > > > > variables. > > > > > > > > [Note] Note > > > > I recommend you to configure the system environment just > > > > by the > > > > "$LANG" variable and to stay away from "$LC_*" variables > > > > unless > > > > it > > > > is absolutely needed. > > > > > > > > I am pretty sure your system doesn't follow my recommendation. > > > > > > > > FYI: locale(7) describes: > > > > > > > > 1. If there is a non-null environment variable LC_ALL, the > > > > value of > > > > LC_ALL is used. > > > > > > > > 2. If an
Bug#966205: Exim4-base cron script doesn't call tidydb correctly
Package: exim4-base
Version: 4.90.1-1ubuntu1.5
The cron script exim4-base, present in /etc/cron.daily, performs various
update actions for exim, amongst which is calling exim_tidydb for the
installed BDB databases. The code that calls tidydb is at the end of the
file, and in my configuration the script exits with code 123 but no
messages; this causes cron to complain.
The relevant code is as follows:
# run tidydb as Debian-exim:Debian-exim.
if [ -x /usr/sbin/exim_tidydb ]; then
cd $SPOOLDIR/db || exit 1
if ! find $SPOOLDIR/db -maxdepth 1 -name '*.lockfile' -or -name 'log.*' \
-or -type f -printf '%f\0' | \
xargs -0r -n 1 \
start-stop-daemon --start --exec /usr/sbin/exim_tidydb \
--chuid Debian-exim:Debian-exim -- $SPOOLDIR > /dev/null; then
# if we reach this, invoking exim_tidydb from start-stop-daemon has
# failed, most probably because of libpam-tmpdir being in use
# (see #373786 and #376165)
find $SPOOLDIR/db -maxdepth 1 -name '*.lockfile' -or -name 'log.*' \
-or -type f -printf '%f\0' | \
runuser --shell=/bin/bash \
--command="xargs -0r -n 1 /usr/sbin/exim_tidydb $SPOOLDIR >
/dev/null" \
Debian-exim
fi
fi
This seems excessively complex, but also assumes that any file which is
present and not a lockfile or a logfile is a BDB database. Checking the
source code for tidydb shows that only the following names are accepted:
"retry", "misc", "callout" and "wait-*". In my configuration I use the
widely known "greylist" code, and it makes sense to me to put the sqlite
greylist database in SPOOL/db.
I propose replacing the above code with the following, much simpler and
more correct version, because it finds all databases that are acceptable
to exim_tidydb while ignoring any other file. I have avoided using
'runuser' as this step does not appear to be necessary: tidied files are
changed in-place, and so there is no reason for the user or group name
to change. It could of course be reinstated if needed.
# run tidydb.
if [ -x /usr/sbin/exim_tidydb ]; then
cd $SPOOLDIR/db || exit 1
# exim_tidydb operates on Berkeley DB files retry, misc, callout, and
# wait-* (e.g. wait-remote_smtp), but not on the lockfiles that can
accompany
# them. The lockfiles are zero length so it's easiest to eliminate
that way
# (rather than checking the name).
[ -f "retry" ] && /usr/sbin/exim_tidydb $SPOOLDIR retry
[ -f "misc" ] && /usr/sbin/exim_tidydb $SPOOLDIR misc
[ -f "callout" ] && /usr/sbin/exim_tidydb $SPOOLDIR callout
for db in "wait-*" ; do
[ ! -s "${db}" ] && /usr/sbin/exim_tidydb $SPOOLDIR $db
done
fi
--
Software Manager & Engineer
Tel: 01223 414180
Blog: http://www.ivimey.org/blog
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
Hi Niels, > Can we not think of some better solution to this, where we can get the > reward sooner than 6 years without shoving all the risk onto me and > without shoving ton of work onto you? I hear you, ouch. :/ I had not appreciated all of the implications here, particularly in that that you would get all the flak from the fallout. Unfortunately, I can just imagine how this has played out in the past with other changes. I note that this bug has been marked as fixed in debhelper 13.2. To help others viewing this bug from reproducible context, here is the relevant changelog entry: * cmake.pm: Pass -DCMAKE_SKIP_RPATH=ON -DBUILD_RPATH_USE_ORIGIN=ON to cmake in compat 14. This should fix some reproducibility issues but may cause breakage if packages run binaries directly from the build directory. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#966204: ITP: relacy -- meticulous synchronization algorithm verifier for relaxed memory models
Package: wnpp Severity: wishlist Subject: ITP: relacy -- meticulous synchronization algorithm verifier for relaxed memory models Package: wnpp Owner: Shayan Doust Severity: wishlist * Package name: relacy Version : 0.0+git20191025.acc09bb Upstream Author : Dmitry S. Vyukov * URL : https://github.com/dvyukov/relacy * License : BSD-3-Clause Programming Lang: C Description : meticulous synchronization algorithm verifier for relaxed memory models Relacy Race Detector is a tool for efficient execution of unit tests for synchronization algorithms written in C++0x. Every user thread is represented as a fiber (ucontext). Every time only one fiber is running, and special scheduler controls interleaving between fibers. With random scheduler it just executes numerous amount of various interleavings between threads. With full search scheduler or context-bound scheduler it systematically executes all possible interleavings between threads. While executing particular interleaving it makes exhaustive verification of various aspects of execution (races, accesses to freed memory etc). . If no errors found then verification terminates when particular number of interleavings are verified (for random scheduler), or when all possible interleavings are verified (for full search scheduler). If error is found then tool outputs execution history which leads to error and terminates. Physically Relacy Race Detector is a header-only library for C++98. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/relacy
Bug#674857: Groeten
Ik heb je deze maand geleden een brief gestuurd en ik weet niet zeker of ik het begrijp. En ik herhaal dat ik advocaat Chris Ramson ben, ik heb contact met u opgenomen om u te helpen bij de klacht en om de geschatte waarde ($ 13,580 miljoen) van het door mijn cliënt achtergelaten fonds over te maken voordat het wordt overgedragen aan het bedrijf dat financieel in beslag is genomen of dat is hier onbruikbaar verklaard. Ik heb om deze reden contact met je opgenomen omdat je dezelfde achternaam hebt bij mijn overleden cliënt. Reageer voor meer informatie over deze klacht. Vriendelijke groet, Advocaat Chris Ramson. (Esq) (chrisramso...@gmail.com)
Bug#966185: monit: new upstream version 5.27.0
Package: monit Version: 1:5.26.0-6 Severity: wishlist Hi, Since about a month there is a new upstream version 5.27.0 [1]. It would be nice to see it packaged in Debian sid. Best regards Christian Göttsche [1]: https://mmonit.com/monit/changes/
Bug#953075: debian-reference: Incorrect environment example for 'date' in section 1.5.2
locales-all got installed by this morning's full-upgrade, but the issue is the same. I think my problem is having an /etc/locale.conf file with a bunch of LC_ variables set. I don't know where that file came from, perhaps a previous installation that got copied into the new one. Hank On 2020-07-24 11:39 a.m., Osamu Aoki wrote: Oops, I think your problem goes out if you install the locales-all package I forgot to ask: $ dpkg -l locales* If you didn't install locales-all package or generate fr_CA.UTF-8 locale data manually by running the following $ sudo dpkg-reconfigure locales You get English ... didn't I mention this ... Yes: For fine details of the locale configuration, see Section 8.4, “The locale”. You should have clicked there to read Section 8.4. But not so obvious ... Now I know ... Ububtu and Old Debian's locales are like locales-all on recent Debian. Current Debian's locales are small and requires user to configure it manually while locales-all is huge and pre-confugured Maybe it is good idea to guide people to the locales-all package On Fri, 2020-07-24 at 09:38 -0400, Hank Knox wrote: Thank you for taking the time to respond to this. I was reading the Debian Reference shortly after a clean install of bullseye. (It's a very useful document, BTW, thanks for doing it.) However I have been running Debian for years and migrated some config files over from a previous installation so perhaps my setup does not reflect the usual defaults. Here is the info you asked for: hank@SunVillage:~$ locale LANG=en_CA.utf8 LANGUAGE= LC_CTYPE="en_CA.utf8" LC_NUMERIC=en_CA.UTF-8 LC_TIME=en_CA.UTF-8 LC_COLLATE="en_CA.utf8" LC_MONETARY=en_CA.UTF-8 LC_MESSAGES="en_CA.utf8" LC_PAPER=en_CA.UTF-8 LC_NAME=en_CA.UTF-8 LC_ADDRESS=en_CA.UTF-8 LC_TELEPHONE=en_CA.UTF-8 LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=en_CA.UTF-8 LC_ALL= hank@SunVillage:~$ echo $XDG_CURRENT_DESKTOP='XDG_CURRENT_DESKTOP' XFCE=XDG_CURRENT_DESKTOP I am not sure what is setting the various LC_ variables. I grepped my home directory, /etc/bash.bashrc and /etc/profile and the only result that references LC_ is ".xsession-errors:dbus-update-activation-environment: setting LC_TIME=en_CA.UTF-8" in my home directory; there are similar entries for all the other LC_ variables in my environment. Is there some configuration of dbus that sets those variables? If so, I don't know where that is configured. I fear I have enough Linux experience to get in trouble but not enough to be really knowledgeable! Best, Hank Knox On 2020-07-23 10:44 p.m., Osamu Aoki wrote: Hmmm... I agree this is probably not a bug but a user support problem. Let me add a comment: I chose to use $LANG to set the locale since that seems to be the way default install configures used by Debian system. Hank, if you are facing this issue on some default install system without violating my recommendation, let is know your desktop etc. Please run the following to check: $ locale $ echo "XDG_CURRENT_DESKTOP='$XDG_CURRENT_DESKTOP'" Report it back to this bug Hank, anyway did you read on to the last part of 1.5.2 first: See locale(5) and locale(7) for "$LANG" and related environment variables. [Note] Note I recommend you to configure the system environment just by the "$LANG" variable and to stay away from "$LC_*" variables unless it is absolutely needed. I am pretty sure your system doesn't follow my recommendation. FYI: locale(7) describes: 1. If there is a non-null environment variable LC_ALL, the value of LC_ALL is used. 2. If an environment variable with the same name as one of the categories above exists and is non-null, its value is used for that category. 3. If there is a non-null environment variable LANG, the value of LANG is used.
Bug#966203: transition: grpc
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Transition of gRPC that I've already uploaded. The only affected package is src:collectd - the Sid upload of that FTBFS on armel and mipsel due to a problem in the previous gRPC version. This new upload should fix that, so please binNMU collectd on all architectures. Thanks, Laszlo/GCS
Bug#966202: utfcpp: Please fix the broken VCS-SVN field
Source: utfcpp Version: 2.3.4-1 Severity: normal X-Debbugs-CC: ma...@debian.org Tags: sid Dear Debian utfcpp maintainer, Your package is still using anonscm.debian.org in Vcs fields, which is now broken. Please consider updating this information in the packaging metadata. Since the new version of taglib library is starting to use utfcpp, I am looking into improving the packaging of utfcpp recently. Let me know if it's okay to refresh packaging with 0-day NMUs (otherwise I would follow a bug report -> NMU pattern). -- Regards, Boyuan Yang
Bug#965217: libgrpc++1: ServerBuilder::BuildAndStart hangs
On Fri, Jul 24, 2020 at 3:48 PM Benjamin Barenblat wrote: > I’ve just reuploaded Abseil with an shlibs file instead of a symbols > file. The symbols file doesn’t buy us a whole lot anyway, since Abseil > is going to break ABI with every release. It worked, builds are correct this time. Just uploaded gRPC 1.30.2 to unstable now. @Michael: Please test it and report back if it still hangs for you and / or any other patch you need applied.
Bug#966201: vmdb2: temporary Ansible inventory files are not removed properly
Package: vmdb2 Version: 0.16-2 Severity: normal It seems that only the last-created inventory file is removed: Created /tmp/tmp4bldfn_5 for Ansible inventory Created /tmp/tmpuu_y3a27 for Ansible variables Exec: ['ansible-playbook', '-c', 'chroot', '-i', '/tmp/tmp4bldfn_5', '-e', '@/tmp/tmpuu_y3a27', 'librelan/network/dhcp/playbook.yml'] Created /tmp/tmpsxoq4cu6 for Ansible inventory Created /tmp/tmp2bh_xqmr for Ansible variables Exec: ['ansible-playbook', '-c', 'chroot', '-i', '/tmp/tmpsxoq4cu6', '-e', '@/tmp/tmp2bh_xqmr', 'librelan/network/dns/playbook.yml'] Created /tmp/tmpgdtx7usn for Ansible inventory Created /tmp/tmp0vjhsy5u for Ansible variables Exec: ['ansible-playbook', '-c', 'chroot', '-i', '/tmp/tmpgdtx7usn', '-e', '@/tmp/tmp0vjhsy5u', 'librelan/game/doom/playbook.yml'] Created /tmp/tmp_phchqyn for Ansible inventory Created /tmp/tmptaoail0j for Ansible variables Exec: ['ansible-playbook', '-c', 'chroot', '-i', '/tmp/tmp_phchqyn', '-e', '@/tmp/tmptaoail0j', 'a.rb-store-f-mount.yml'] Removing /tmp/tmp_phchqyn Removing /tmp/tmp_phchqyn ERROR: [Errno 2] No such file or directory: '/tmp/tmp_phchqyn' ERROR: FileNotFoundError(2, 'No such file or directory') Removing /tmp/tmp_phchqyn ERROR: [Errno 2] No such file or directory: '/tmp/tmp_phchqyn' ERROR: FileNotFoundError(2, 'No such file or directory') Removing /tmp/tmp_phchqyn ERROR: [Errno 2] No such file or directory: '/tmp/tmp_phchqyn' ERROR: FileNotFoundError(2, 'No such file or directory') Removing /tmp/tmp_phchqyn ERROR: [Errno 2] No such file or directory: '/tmp/tmp_phchqyn' ERROR: FileNotFoundError(2, 'No such file or directory') Exec: ['umount', '/tmp/tmp16wkym14'] Exec: ['kpartx', '-dsv', 'valerian.img'] All went fine. There are quite a collection of inventory files building up in my /tmp directory, including the first three files created above: $ find /tmp/ -name "tmp*" -size 25c /tmp/tmp4bldfn_5 /tmp/tmptm2wkiha /tmp/tmp4im17_at /tmp/tmp5o9m1te1 /tmp/tmp7xgpoo_v /tmp/tmp20kv6z1w /tmp/tmph2igits4 /tmp/tmpsxoq4cu6 /tmp/tmpgdtx7usn /tmp/tmpsxlo_bhc /tmp/tmprt9qyxpn /tmp/tmpqlsibcdn /tmp/tmp1qqj9jpu /tmp/tmppheh74wo /tmp/tmp948014o_ /tmp/tmpko7defxv /tmp/tmpoah5mqe7 $ -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (991, 'stable'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable'), (70, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-linux-latest-32 (SMP w/16 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages vmdb2 depends on: ii cmdtest 0.32-3 ii debootstrap 1.0.119~bpo10+1 ii kpartx 0.7.9-3 ii parted 3.2-25 ii python3 3.7.3-1 ii python3-cliapp 1.20180812.1-2 ii python3-jinja2 2.10-2 ii python3-yaml3.13-2 ii qemu-utils 1:3.1+dfsg-8+deb10u6 Versions of packages vmdb2 recommends: ii ansible 2.7.7+dfsg-1 vmdb2 suggests no packages. -- no debconf information
Bug#966199: nastran: FTBFS with GCC 10: Error: BOZ constant at (1) uses nonstandard postfix syntax
Source: nastran Version: 0.1.95-1 Severity: serious Tags: ftbfs sid bullseye Justification: fails to build from source User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, nastran started to FTBFS when GCC 10 was made the default compiler: f77 -g -w -fno-range-check -fno-automatic -fcray-pointer -std=legacy -c -o bufchk.o bufchk.f bufchk.f:16:28: 16 | 1 '1'X, '2'X , '3'X, '4'X , '8'X / |1 Error: BOZ constant at (1) uses nonstandard postfix syntax [see '-fno-allow-invalid-boz'] bufchk.f:18:32: 18 | 1 'F'X, 'F'X , 'F'X, 'F'X / |1 Error: BOZ constant at (1) uses nonstandard postfix syntax [see '-fno-allow-invalid-boz'] bufchk.f:20:32: 20 | 1 'F'X, 'F'X , 'F'X, 'F'X / |1 Error: BOZ constant at (1) uses nonstandard postfix syntax [see '-fno-allow-invalid-boz'] make[2]: *** [Makefile:390: bufchk.o] Error 1 More information about the corresponding GCC changes can be found here: https://gcc.gnu.org/gcc-10/porting_to.html Andreas
Bug#966200: CVE-2020-1722
Source: freeipa Severity: important Tags: security This was assigned CVE-2020-1722: https://pagure.io/freeipa/issue/8268 Cheers, Moritz
Bug#953075: debian-reference: Incorrect environment example for 'date' in section 1.5.2
Control: reopen -1 Control: tags -1 pending On Sat, 2020-07-25 at 00:39 +0900, Osamu Aoki wrote: > Oops, > > I think your problem goes out if you install the locales-all package > > I forgot to ask: > > $ dpkg -l locales* > > If you didn't install locales-all package or generate fr_CA.UTF-8 > locale data manually by running the following > > $ sudo dpkg-reconfigure locales > > You get English ... didn't I mention this ... Yes: > >For fine details of the locale configuration, see Section 8.4, > “The >locale”. > > You should have clicked there to read Section 8.4. But not so > obvious > ... Now I know ... > > Ububtu and Old Debian's locales are like locales-all on recent > Debian. > > Current Debian's locales are small and requires user to configure it > manually while locales-all is huge and pre-confugured > > Maybe it is good idea to guide people to the locales-all package > > On Fri, 2020-07-24 at 09:38 -0400, Hank Knox wrote: > > Thank you for taking the time to respond to this. > > > > I was reading the Debian Reference shortly after a clean install > > of > > bullseye. (It's a very useful document, BTW, thanks for doing it.) > > However I have been running Debian for years and migrated some > > config > > files over from a previous installation so perhaps my setup does > > not > > reflect the usual defaults. > > > > Here is the info you asked for: > > > > hank@SunVillage:~$ locale > > LANG=en_CA.utf8 > > LANGUAGE= > > LC_CTYPE="en_CA.utf8" > > LC_NUMERIC=en_CA.UTF-8 > > LC_TIME=en_CA.UTF-8 > > LC_COLLATE="en_CA.utf8" > > LC_MONETARY=en_CA.UTF-8 > > LC_MESSAGES="en_CA.utf8" > > LC_PAPER=en_CA.UTF-8 > > LC_NAME=en_CA.UTF-8 > > LC_ADDRESS=en_CA.UTF-8 > > LC_TELEPHONE=en_CA.UTF-8 > > LC_MEASUREMENT=en_CA.UTF-8 > > LC_IDENTIFICATION=en_CA.UTF-8 > > LC_ALL= > > > > hank@SunVillage:~$ echo $XDG_CURRENT_DESKTOP='XDG_CURRENT_DESKTOP' > > XFCE=XDG_CURRENT_DESKTOP > > > > I am not sure what is setting the various LC_ variables. I grepped > > my > > home directory, /etc/bash.bashrc and /etc/profile and the only > > result > > that references LC_ is > > ".xsession-errors:dbus-update-activation-environment: setting > > LC_TIME=en_CA.UTF-8" in my home directory; there are similar > > entries > > for > > all the other LC_ variables in my environment. Is there some > > configuration of dbus that sets those variables? If so, I don't > > know > > where that is configured. I fear I have enough Linux experience to > > get > > in trouble but not enough to be really knowledgeable! > > > > Best, > > > > Hank Knox > > > > On 2020-07-23 10:44 p.m., Osamu Aoki wrote: > > > Hmmm... > > > > > > I agree this is probably not a bug but a user support > > > problem. Let > > > me > > > add a comment: > > > > > > I chose to use $LANG to set the locale since that seems to be the > > > way > > > default install configures used by Debian system. > > > > > > Hank, if you are facing this issue on some default install system > > > without violating my recommendation, let is know your desktop > > > etc. > > > > > > Please run the following to check: > > > > > > $ locale > > > $ echo "XDG_CURRENT_DESKTOP='$XDG_CURRENT_DESKTOP'" > > > > > > Report it back to this bug > > > > > > Hank, anyway did you read on to the last part of 1.5.2 first: > > > > > > See locale(5) and locale(7) for "$LANG" and related > > > environment > > > variables. > > > > > > [Note]Note > > > I recommend you to configure the system environment just by > > > the > > > "$LANG" variable and to stay away from "$LC_*" variables > > > unless > > > it > > > is absolutely needed. > > > > > > I am pretty sure your system doesn't follow my recommendation. > > > > > > FYI: locale(7) describes: > > > > > > 1. If there is a non-null environment variable LC_ALL, the > > > value of > > > LC_ALL is used. > > > > > > 2. If an environment variable with the same name as one of the > > > categories above exists and is non-null, its value is used > > > for > > > that > > > category. > > > > > > 3. If there is a non-null environment variable LANG, the value > > > of LANG > > > is used.
Bug#966197: CVE-2013-7489
Source: beaker Severity: important Tags: security Please see: https://github.com/bbangert/beaker/issues/191 https://www.openwall.com/lists/oss-security/2020/05/14/11 Cheers, Moritz
Bug#966198: gdm3: Defunct gdm-session-worker processes occationally remains unhandled.
Package: gdm3 Version: 3.36.2-1 Severity: normal Dear Maintainer, Sometimes defunct gdm-session-worker processes may appear after logging out from a gnome session, which usually lasts several hours, but sometimes logging out from a gnome session lasting only one minute can trigger this phenomenon. These defunct gdm-session-worker processes are owned by the user "Debian-gdm", and their cpu time last only several seconds. These defunct processes do not clearly impact the functionality of gdm3, but they occupy available process slots, and cannot be manually cleared unless I restart gdm3 with no gnome session active (via console or ssh). -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 0.6.55-2 ii adduser 3.118 ii cdebconf [debconf-2.0] 0.253 ii dbus 1.12.20-1 ii dconf-cli 0.36.0-1 ii dconf-gsettings-backend 0.36.0-1 ii debconf [debconf-2.0] 1.5.74 ii gir1.2-gdm-1.0 3.36.2-1 ii gnome-session [x-session-manager] 3.36.0-2 ii gnome-session-bin 3.36.0-2+b1 ii gnome-session-flashback [x-session-manager] 3.36.3-1 ii gnome-settings-daemon 3.36.1-1 ii gnome-shell 3.36.3-1 ii gnome-terminal [x-terminal-emulator] 3.36.2-1 ii gsettings-desktop-schemas 3.36.1-1 ii libaccountsservice0 0.6.55-2 ii libaudit1 1:2.8.5-3+b1 ii libc6 2.31-1 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libgdm1 3.36.2-1 ii libglib2.0-0 2.64.4-1 ii libglib2.0-bin 2.64.4-1 ii libgtk-3-0 3.24.20-1 ii libkeyutils1 1.6.1-2 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam-systemd 245.6-2 ii libpam0g 1.3.1-5 ii librsvg2-common 2.48.7-1 ii libselinux1 3.0-1+b3 ii libsystemd0 245.6-2 ii libwrap0 7.6.q-30 ii libx11-6 2:1.6.9-2+b1 ii libxau6 1:1.0.8-1+b2 ii libxcb1 1.14-2 ii libxdmcp6 1:1.1.2-3 ii lsb-base 11.1.0 ii metacity [x-window-manager] 1:3.36.1-1 ii mutter [x-window-manager] 3.36.3-1 ii policykit-1 0.105-28 ii procps 2:3.3.16-5 ii tilix [x-terminal-emulator] 1.9.3-4+b2 ii ucf 3.0043 ii x11-common 1:7.7+20 ii x11-xserver-utils 7.7+8 ii xterm [x-terminal-emulator] 358-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.36.0-2 ii desktop-base 10.0.3 ii x11-xkb-utils 7.7+5 ii xserver-xephyr 2:1.20.8-2 ii xserver-xorg 1:7.7+20 ii zenity 3.32.0-5 Versions of packages gdm3 suggests: pn gnome-orca pn libpam-fprintd ii libpam-gnome-keyring 3.36.0-1 -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3
Bug#966196: mariadb-server-10.3: Mariadb 10.3.22 fails to start after Stretch update, Failed at step EXEC spawning /etc/mysql/debian-start: No such file or directory
Package: mariadb-server-10.3 Version: 1:10.3.22-0+deb10u1 Severity: normal Dear Maintainer, After updating Stretch mariadb fails with Jul 25 01:19:38 dog systemd[23576]: mariadb.service: Failed at step EXEC spawning /etc/mysql/debian-start: No such file or directory Jul 25 01:19:38 dog systemd[1]: mariadb.service: Control process exited, code=exited, status=203/EXEC Jul 25 01:19:40 dog systemd[1]: mariadb.service: Failed with result 'exit-code'. Jul 25 01:19:40 dog systemd[1]: Failed to start MariaDB 10.3.22 database server. The file debian-start actually has some text inside it saying this file is no longer needed, I deleted it once and got the same error. I recreated it and it all worked again. It seems to have vanished after the update bringing the same situation back. A workaround is to create the file. -- 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-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server-10.3 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.71 ii galera-3 25.3.25-2 ii gawk 1:4.2.1+dfsg-1 ii iproute2 4.20.0-2 ii libc6 2.28-10 ii libdbi-perl 1.642-1+b1 ii libgnutls30 3.6.7-4+deb10u4 ii libpam0g 1.3.1-5 ii libstdc++68.3.0-6 ii lsb-base 10.2019051400 ii lsof 4.91+dfsg-1 ii mariadb-client-10.3 1:10.3.22-0+deb10u1 ii mariadb-common1:10.3.22-0+deb10u1 ii mariadb-server-core-10.3 1:10.3.22-0+deb10u1 ii passwd1:4.5-1.1 ii perl 5.28.1-6 ii psmisc23.2-1 ii rsync 3.1.3-6 ii socat 1.7.3.2-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages mariadb-server-10.3 recommends: ii libhtml-template-perl 2.97-1 Versions of packages mariadb-server-10.3 suggests: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 pn mariadb-test pn netcat-openbsd pn tinyca -- Configuration Files: /etc/logcheck/ignore.d.paranoid/mariadb-server-10_3 [Errno 13] Permission denied: '/etc/logcheck/ignore.d.paranoid/mariadb-server-10_3' /etc/logcheck/ignore.d.server/mariadb-server-10_3 [Errno 13] Permission denied: '/etc/logcheck/ignore.d.server/mariadb-server-10_3' /etc/logcheck/ignore.d.workstation/mariadb-server-10_3 [Errno 13] Permission denied: '/etc/logcheck/ignore.d.workstation/mariadb-server-10_3' /etc/mysql/debian-start [Errno 13] Permission denied: '/etc/mysql/debian-start' /etc/mysql/mariadb.conf.d/50-server.cnf changed [not included] -- debconf information excluded
Bug#953075: debian-reference: Incorrect environment example for 'date' in section 1.5.2
Oops, I think your problem goes out if you install the locales-all package I forgot to ask: $ dpkg -l locales* If you didn't install locales-all package or generate fr_CA.UTF-8 locale data manually by running the following $ sudo dpkg-reconfigure locales You get English ... didn't I mention this ... Yes: For fine details of the locale configuration, see Section 8.4, “The locale”. You should have clicked there to read Section 8.4. But not so obvious ... Now I know ... Ububtu and Old Debian's locales are like locales-all on recent Debian. Current Debian's locales are small and requires user to configure it manually while locales-all is huge and pre-confugured Maybe it is good idea to guide people to the locales-all package On Fri, 2020-07-24 at 09:38 -0400, Hank Knox wrote: > Thank you for taking the time to respond to this. > > I was reading the Debian Reference shortly after a clean install of > bullseye. (It's a very useful document, BTW, thanks for doing it.) > However I have been running Debian for years and migrated some > config > files over from a previous installation so perhaps my setup does not > reflect the usual defaults. > > Here is the info you asked for: > > hank@SunVillage:~$ locale > LANG=en_CA.utf8 > LANGUAGE= > LC_CTYPE="en_CA.utf8" > LC_NUMERIC=en_CA.UTF-8 > LC_TIME=en_CA.UTF-8 > LC_COLLATE="en_CA.utf8" > LC_MONETARY=en_CA.UTF-8 > LC_MESSAGES="en_CA.utf8" > LC_PAPER=en_CA.UTF-8 > LC_NAME=en_CA.UTF-8 > LC_ADDRESS=en_CA.UTF-8 > LC_TELEPHONE=en_CA.UTF-8 > LC_MEASUREMENT=en_CA.UTF-8 > LC_IDENTIFICATION=en_CA.UTF-8 > LC_ALL= > > hank@SunVillage:~$ echo $XDG_CURRENT_DESKTOP='XDG_CURRENT_DESKTOP' > XFCE=XDG_CURRENT_DESKTOP > > I am not sure what is setting the various LC_ variables. I grepped > my > home directory, /etc/bash.bashrc and /etc/profile and the only > result > that references LC_ is > ".xsession-errors:dbus-update-activation-environment: setting > LC_TIME=en_CA.UTF-8" in my home directory; there are similar entries > for > all the other LC_ variables in my environment. Is there some > configuration of dbus that sets those variables? If so, I don't know > where that is configured. I fear I have enough Linux experience to > get > in trouble but not enough to be really knowledgeable! > > Best, > > Hank Knox > > On 2020-07-23 10:44 p.m., Osamu Aoki wrote: > > Hmmm... > > > > I agree this is probably not a bug but a user support problem. Let > > me > > add a comment: > > > > I chose to use $LANG to set the locale since that seems to be the > > way > > default install configures used by Debian system. > > > > Hank, if you are facing this issue on some default install system > > without violating my recommendation, let is know your desktop etc. > > > > Please run the following to check: > > > > $ locale > > $ echo "XDG_CURRENT_DESKTOP='$XDG_CURRENT_DESKTOP'" > > > > Report it back to this bug > > > > Hank, anyway did you read on to the last part of 1.5.2 first: > > > > See locale(5) and locale(7) for "$LANG" and related environment > > variables. > > > > [Note] Note > > I recommend you to configure the system environment just by the > > "$LANG" variable and to stay away from "$LC_*" variables unless > > it > > is absolutely needed. > > > > I am pretty sure your system doesn't follow my recommendation. > > > > FYI: locale(7) describes: > > > > 1. If there is a non-null environment variable LC_ALL, the > > value of > > LC_ALL is used. > > > > 2. If an environment variable with the same name as one of the > > categories above exists and is non-null, its value is used for > > that > > category. > > > > 3. If there is a non-null environment variable LANG, the value > > of LANG > > is used.
Bug#966195: python3-hid: references an unreleased API from libhidapi, resulting in undefined symbols
Package: python3-hid Version: 0.9.0.post3-1 Severity: grave Tags: a11y upstream Justification: renders package unusable X-Debbugs-Cc: tz123123...@gmx.de Dear Maintainer, I have an app depending on this package but since the last update of python3-hid, I am unable to run it. Simply running $ python3 -c "import hidraw" or $ python3 -c "import hid" exposes the issue. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-hid depends on: ii libc6 2.31-2 ii libhidapi-hidraw0 0.9.0+dfsg-1 ii libhidapi-libusb0 0.9.0+dfsg-1 ii python33.8.2-3 ii python3-pkg-resources 46.1.3-1 python3-hid recommends no packages. python3-hid suggests no packages. -- no debconf information
Bug#953075: debian-reference: Incorrect environment example for 'date' in section 1.5.2
I am a little embarrassed. A little digging revealed all the LC_ variables are set in /etc/locale.conf. I'm not sure how that file got set but the date suggests it was around the time I installed Debian. So either it came from a long-ago config file or something prompted me to set it. I think we can close this bug. Hank
Bug#966194: gcc-9: valgrind error: Conditional jump or move depends on uninitialised value(s)
Package: gcc-9
Version: 9.3.0-15
Severity: important
X-Debbugs-Cc: r...@scotsgeek.com
Dear Maintainer,
Source:
#include
#include
#define DIM 32
char p[DIM] = "NULL";
int main(void)
{
strcpy(p, "This is a test.");
for(int x = 0 ; x < DIM; ++x)
{
printf("%02x ", p[x]);
}
putchar('\n');
return 0;
}
valgrind output:
==16291== Use of uninitialised value of size 8
==16291==at 0x48B4E5A: _itoa_word (_itoa.c:180)
==16291==by 0x48CE753: __vfprintf_internal (vfprintf-internal.c:1687)
==16291==by 0x48BAD6A: printf (printf.c:33)
==16291==by 0x10920D: main (ptest.c:33)
==16291==
==16291== Conditional jump or move depends on uninitialised value(s)
==16291==at 0x48B4E6C: _itoa_word (_itoa.c:180)
==16291==by 0x48CE753: __vfprintf_internal (vfprintf-internal.c:1687)
==16291==by 0x48BAD6A: printf (printf.c:33)
==16291==by 0x10920D: main (ptest.c:33)
==16291==
...
==16291== ERROR SUMMARY: 64 errors from 4 contexts (suppressed: 0 from 0)
Error only occurs with heap allocation, not with global or local arrays.
Error did not occur with previous versions of gcc. Compilation command has not
changed.
"gcc -std=c18 -Wall -Wextra -Wpedantic -g -I . -o ptest ptest.c"
Error should not occur with the code posted here.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
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 gcc-9 depends on:
ii binutils 2.34.90.20200706-1
ii cpp-9 9.3.0-15
ii gcc-9-base9.3.0-15
ii libc6 2.31-1
ii libcc1-0 10.1.0-6
ii libgcc-9-dev 9.3.0-15
ii libgcc-s1 10.1.0-6
ii libgmp10 2:6.2.0+dfsg-6
ii libisl22 0.22.1-1
ii libmpc3 1.1.0-1
ii libmpfr6 4.0.2-1
ii libstdc++610.1.0-6
ii zlib1g1:1.2.11.dfsg-2
Versions of packages gcc-9 recommends:
ii libc6-dev 2.31-1
Versions of packages gcc-9 suggests:
pn gcc-9-doc
pn gcc-9-locales
pn gcc-9-multilib
-- no debconf information
Bug#957563: mpg321: ftbfs with GCC-10
tag 957563 + patch
thanks
Attached is the patch mpg321_common.diff that adds -fcommon to CFLAGS (see
http://gcc.gnu.org/gcc-10/porting_to.html), plus adding "export" to make them
take effect, and demoting one error to warning again.
I've also attached the patch mpg321_extern.diff which fixes the actual cause
for the problem (builds fine, but didn't really test the resulting binary).
You might want to forward it to upstream.
Best regards,
Joachim
diff -Nru mpg321-0.3.2/debian/changelog mpg321-0.3.2/debian/changelog
--- mpg321-0.3.2/debian/changelog 2019-03-13 15:59:02.0 +0100
+++ mpg321-0.3.2/debian/changelog 2020-07-23 17:22:42.0 +0200
@@ -1,3 +1,13 @@
+mpg321 (0.3.2-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Export CFLAGS to make them take effect.
+ * Add -Wno-error=format-security to CFLAGS to disable the default from
+dpkg-buildflags as workaround for some build error.
+ * Add -fcommon to CFLAGS (Closes: #957563).
+
+ -- Joachim Reichel Thu, 23 Jul 2020 17:22:42 +0200
+
mpg321 (0.3.2-3) unstable; urgency=medium
* Fix compilation error
diff -Nru mpg321-0.3.2/debian/rules mpg321-0.3.2/debian/rules
--- mpg321-0.3.2/debian/rules 2012-05-01 08:53:43.0 +0200
+++ mpg321-0.3.2/debian/rules 2020-07-23 17:22:42.0 +0200
@@ -4,7 +4,7 @@
#export DH_VERBOSE=1
-CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused
+export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused -Wno-error=format-security -fcommon
MPG321_ARCH = $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
Description:
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details).
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: ,
Bug:
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded:
Reviewed-By:
Last-Update: 2020-07-23
--- mpg321-0.3.2.orig/mpg321.h
+++ mpg321-0.3.2/mpg321.h
@@ -116,7 +116,7 @@ extern char *playlist_file;
extern int quit_now;
extern char remote_input_buf[PATH_MAX + 5];
extern int file_change;
-int loop_remaining;
+extern int loop_remaining;
extern int status;
extern int scrobbler_time;
@@ -233,8 +233,8 @@ RETSIGTYPE handle_sigchld(int sig);
#define FFT_BUFFER_SIZE_LOG 9
#define FFT_BUFFER_SIZE (1 << FFT_BUFFER_SIZE_LOG) /* 512 */
/*Temporary data stores to perform FFT in */
-double real[FFT_BUFFER_SIZE];
-double imag[FFT_BUFFER_SIZE];
+extern double real[FFT_BUFFER_SIZE];
+extern double imag[FFT_BUFFER_SIZE];
typedef struct {
double real[FFT_BUFFER_SIZE];
@@ -258,10 +258,10 @@ fft_state *fft_init(void);
/* Output buffer process */
void frame_buffer_p();
/* Semaphore array */
-int semarray;
+extern int semarray;
/* Input/Output buffer position */
-int mad_decoder_position;
-int output_buffer_position;
+extern int mad_decoder_position;
+extern int output_buffer_position;
/* Output Frame including needed information */
typedef struct {
unsigned char data[4*1152];
@@ -285,10 +285,10 @@ typedef struct {
} decoded_frames;
/* Output frame queue pointer */
-output_frame *Output_Queue;
+extern output_frame *Output_Queue;
/* Shared total decoded frames */
-decoded_frames *Decoded_Frames;
+extern decoded_frames *Decoded_Frames;
#if defined(__GNU_LIBRARY__) && !defined(_SEM_SEMUN_UNDEFINED)
/* */
--- mpg321-0.3.2.orig/mpg321.c
+++ mpg321-0.3.2/mpg321.c
@@ -90,6 +90,7 @@ mad_timer_t current_time;
mpg321_options options = { 0, NULL, NULL, 0 , 0, 0};
int status = MPG321_STOPPED;
int file_change = 0;
+int loop_remaining = 0;
int remote_restart = 0;
int muted = 0;
char *id3_get_tag (struct id3_tag const *tag, char const *what, unsigned int maxlen);
@@ -104,6 +105,15 @@ extern http_file_length;
/* ALSA Volume Range */
extern long volume_min,volume_max;
#endif
+
+double real[FFT_BUFFER_SIZE];
+double imag[FFT_BUFFER_SIZE];
+int semarray;
+int mad_decoder_position;
+int output_buffer_position;
+output_frame *Output_Queue;
+decoded_frames *Decoded_Frames;
+
/* Get the next frame in the round buffer */
int getnext_place(int position)
{
Bug#966193: vice: FTBFS with GCC 10: multiple definition of ... due to -fno-common
Source: vice Version: 3.4.0.dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, vice started to FTBFS when GCC 10 was made the default compiler: g++ -std=c++11 -g -O3 -Wall -Wformat -Wformat-signedness -Wshadow -Wpointer-arith -Wstrict-prototypes -Wuninitialized -Wunreachable-code -Wno-unused-parameter -Werror=implicit-function-declaration -Wfatal-errors -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux -gnu/glib-2.0/include -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/ include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/ usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -fdebug-prefix-map=/build/vice-3.4.0.dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -o vsid alarm.o attach.o autostart.o autostart-pr g.o cbmdos.o cbmimage.o charset.o clipboard.o clkguard.o cmdline.o color.o crc32.o datasette.o debug.o dma.o embedded.o event.o findpath.o fliplist.o gcr.o info.o init.o initcmdline.o interrupt.o ioutil.o kbdbuf.o keyboard.o lib.o libm_math.o log.o machine-bu s.o machine.o main.o network.o opencbmlib.o palette.o ram.o rawfile.o rawnet.o resources.o romset.o screenshot.o snapshot.o socket.o sound.o sysfile.o traps.o util.o vicefeatures.o vsync.o zfile.o zipcode.o midi.o ../src/arch/shared/libarchdep.a ../src/c64/li bvsid.a ../src/sid/libsid.a ../src/monitor/libmonitor.a ../src/sounddrv/libsounddrv.a ../src/mididrv/libmididrv.a ../src/socketdrv/libsocketdrv.a ../src/hwsiddrv/libhwsiddrv.a ../src/iodrv/libiodrv.a ../src/serial/libserial.a ../src/core/libcore.a ../src/vici ivsid/libviciivsid.a ../src/raster/libraster.a ../src/video/libvideo.a ../src/arch/gtk3/libarch.a ../src/arch/gtk3/widgets/libwidgets.a ../src/arch/gtk3/widgets/base/libbasewidgets.a ../src/arch/gtk3/novte/libnovte.a ../src/resid/libresid.a ../src/joyport/ libjoyport.a ../src/hvsc/libhvsc.a -lpulse-simple -lpulse -lasound -ljpeg -lpng -lz -ldl ../src/arch/gtk3/libarch.a ../src/arch/gtk3/widgets/libwidgets.a ../src/arch/gtk3/widgets/base/libbasewidgets.a ../src/arch/gtk3/novte/libnovte.a ../src/arch/shared/li barchdep.a -lnsl -lreadline -lm -ldl -lGLEW -lGL -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lglib-2.0 -lfontconfig /usr/bin/ld: ../src/arch/gtk3/libarch.a(uimedia.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base/carthelpers.h:40: multiple definition of `carthelpers_can_flush_func'; ../src/arch/gtk3/libarch.a(uicart.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/b ase/carthelpers.h:40: first defined here /usr/bin/ld: ../src/arch/gtk3/libarch.a(uimedia.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base/carthelpers.h:39: multiple definition of `carthelpers_can_save_func'; ../src/arch/gtk3/libarch.a(uicart.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/ba se/carthelpers.h:39: first defined here /usr/bin/ld: ../src/arch/gtk3/libarch.a(uimedia.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base/carthelpers.h:38: multiple definition of `carthelpers_disable_func'; ../src/arch/gtk3/libarch.a(uicart.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/bas e/carthelpers.h:38: first defined here /usr/bin/ld: ../src/arch/gtk3/libarch.a(uimedia.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base/carthelpers.h:37: multiple definition of `carthelpers_enable_func'; ../src/arch/gtk3/libarch.a(uicart.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base /carthelpers.h:37: first defined here /usr/bin/ld: ../src/arch/gtk3/libarch.a(uimedia.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base/carthelpers.h:36: multiple definition of `carthelpers_is_enabled_func'; ../src/arch/gtk3/libarch.a(uicart.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/ base/carthelpers.h:36: first defined here /usr/bin/ld: ../src/arch/gtk3/libarch.a(uimedia.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base/carthelpers.h:35: multiple definition of `carthelpers_flush_func'; ../src/arch/gtk3/libarch.a(uicart.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base/ carthelpers.h:35: first defined here /usr/bin/ld: ../src/arch/gtk3/libarch.a(uimedia.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base/carthelpers.h:34: multiple definition of `carthelpers_save_func'; ../src/arch/gtk3/libarch.a(uicart.o):./src/arch/gtk3/../../../src/arch/gtk3/widgets/base/c arthelpers.h:34: first defined here /usr/bin/ld:
Bug#966096: geeqie: immediate segfault
On Fri, 24 Jul 2020 10:21:03 -0400 James Van Zandt wrote: >Alas, no. Same symptom. > >FWIW, I'm attaching the tail end of an strace log, and a (long) list >of the shared libraries used, per ldd. I note that in the latter >list, there are no nvidia libraries - but the strace log shows it was >looking for (and apparently not finding) libGLX_nvidia.so.0. apt-find >indicates that library can be found in these packages: > > >$ apt-file search libGLX_nvidia.so.0 >libglx-nvidia-legacy-390xx0: >/usr/lib/x86_64-linux-gnu/nvidia/legacy-390xx/libGLX_nvidia.so.0 >libglx-nvidia-tesla-418-0: >/usr/lib/x86_64-linux-gnu/nvidia/tesla-418/libGLX_nvidia.so.0 >libglx-nvidia-tesla-440-0: >/usr/lib/x86_64-linux-gnu/nvidia/tesla-440/libGLX_nvidia.so.0 >libglx-nvidia-tesla-450-0: >/usr/lib/x86_64-linux-gnu/nvidia/tesla-450/libGLX_nvidia.so.0 >libglx-nvidia0: >/usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 > > >I don't suppose the tesla packages are relevant, and apt-get isn't >able to find the other two. The first is supposed to be in non-free. >My /etc/apt/sources.list already includes > >deb http://ftp.us.debian.org/debian/ unstable main contrib non-free > >Should I have something else configured to access that package? > What if you edit your config (in ~/.config/geeqie/geeqierc.xml), and change the line image.use_clutter_renderer = "true" (which I assume it is set to), to image.use_clutter_renderer = "false" ? /Andreas
Bug#966192: ITP: libcharts4j-java -- free, lightweight charts and graphs Java API
Package: wnpp Severity: wishlist Owner: Debian Java team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org * Package name: libcharts4j-java Version : 1.3 Upstream Author : Julien Chastang * URL : https://github.com/julienchastang/charts4j * License : MIT Programming Lang: Java Description : free, lightweight charts and graphs Java API charts4j enables developers to programmatically create the charts available in the Google Chart API through a straightforward and intuitive Java API. This package is needed as a dependency of snpeff, which the Debian med team would like to package. I am personnally aiming at this. The package will be maintained in the Debian Java team.
Bug#912677: ITP: oci-systemd-hook - OCI systemd hook enables users to run systemd in OCI compatible runtimes
On Fri, 2 Nov 2018 14:48:53 -0400 (EDT) Qian Cai wrote: > package: wnpp > Severity: wishlist > Owner: 'Qian Cai' > > *Package Name : oci-systemd-hook > Version : 0.1.18 > *URL : https://github.com/projectatomic/oci-systemd-hook > *License : GPLv3 > *Description : OCI systemd hook enables users to run systemd in docker > and OCI compatible runtimes such as runc without requiring --privileged > flag. [...] I'm interested in having this in Debian. However, it looks like runc requires a non-upstream patch to implement that hook mechanism. Is there any plan to apply that in Debian? Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
Bug#966191: cufflinks: FTBFS with GCC 10: multiple definition of ... due to -fno-common
Source: cufflinks Version: 2.2.1+dfsg.1-7 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, cufflinks started to FTBFS when GCC 10 was made the default compiler: g++ -Wall -Wno-strict-aliasing -g -gdwarf-2 -Wunused -Wuninitialized -ftemplate-depth-1024 -O3 -g -O2 -fdebug-prefix-map=/build/cufflinks-2.2.1+dfsg.1=. -fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG -pthread -I/usr/include -Wl,-z,rel ro -Wl,-z,now -L/usr/lib -Wl,-z,relro -Wl,-z,now -o cufflinks cufflinks.o libcufflinks.a libgc.a -lbam -lz -lboost_system -lboost_thread -lboost_serialization /usr/bin/ld: libcufflinks.a(c_plot.o):./src/locfit/c_plot.c:12: multiple definition of `curwin'; libcufflinks.a(startlf.o):./src/locfit/startlf.c:236: first defined here More information about the corresponding GCC change can be found here: https://gcc.gnu.org/gcc-10/porting_to.html "Default to -fno-common" Andreas
Bug#966190: alien-arena: FTBFS with GCC 10: multiple definition of ... due to -fno-common
Source: alien-arena Version: 7.66+dfsg-5 Severity: serious Tags: ftbfs sid bullseye Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, alien-arena started to FTBFS when GCC 10 was made the default compiler: gcc -g -O2 -fdebug-prefix-map=/build/alien-arena-7.66+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -ffast-math -fno-strict-aliasing -Wl,-z,relro -Wl,-z,now -o alienarena-ded game/alienarena_ded-q_shared.o null/alienarena_ded-cl_null.o qcommon/alienarena_ded-cmd.o qcommon/alienarena_ded-cmodel.o qcommon/alienarena_ded-common.o qcommon/alienarena_ded-crc.o qcommon/alienarena_ded-cvar.o qcommon/alienarena_ded-files.o qcommon/alienarena_ded-htable.o qcommon/alienarena_ded-mdfour.o qcommon/alienarena_ded-net_chan.o qcommon/alienarena_ded-pmove.o server/alienarena_ded-sv_ccmds.o server/alienarena_ded-sv_ents.o server/alienarena_ded-sv_game.o server/alienarena_ded-sv_init.o server/alienarena_ded-sv_main.o server/alienarena_ded-sv_send.o server/alienarena_ded-sv_user.o server/alienarena_ded-sv_world.o unix/alienarena_ded-glob.o unix/alienarena_ded-net_udp.o unix/alienarena_ded-q_shunix.o unix/alienarena_ded-sys_unix.o libgame.a -ljpeg -ldl -lm /usr/bin/ld: null/alienarena_ded-cl_null.o:./source/./game/q_shared.h:264: multiple definition of `com_parseLine'; game/alienarena_ded-q_shared.o:./source/game/q_shared.h:264: first defined here /usr/bin/ld: qcommon/alienarena_ded-cmd.o:./source/qcommon/qcommon.h:745: multiple definition of `remoteserver_runspeed'; null/alienarena_ded-cl_null.o:./source/null/../qcommon/qcommon.h:745: first defined here /usr/bin/ld: qcommon/alienarena_ded-cmd.o:./source/qcommon/qcommon.h:744: multiple definition of `remoteserver_jousting'; null/alienarena_ded-cl_null.o:./source/null/../qcommon/qcommon.h:744: first defined here /usr/bin/ld: qcommon/alienarena_ded-cmd.o:./source/./game/q_shared.h:264: multiple definition of `com_parseLine'; game/alienarena_ded-q_shared.o:./source/game/q_shared.h:264: first defined here /usr/bin/ld: qcommon/alienarena_ded-cmodel.o:./source/qcommon/qcommon.h:745: multiple definition of `remoteserver_runspeed'; null/alienarena_ded-cl_null.o:./source/null/../qcommon/qcommon.h:745: first defined here /usr/bin/ld: qcommon/alienarena_ded-cmodel.o:./source/qcommon/qcommon.h:744: multiple definition of `remoteserver_jousting'; null/alienarena_ded-cl_null.o:./source/null/../qcommon/qcommon.h:744: first defined here /usr/bin/ld: qcommon/alienarena_ded-cmodel.o:./source/./game/q_shared.h:264: multiple definition of `com_parseLine'; game/alienarena_ded-q_shared.o:./source/game/q_shared.h:264: first defined here /usr/bin/ld: qcommon/alienarena_ded-common.o:./source/qcommon/qcommon.h:745: multiple definition of `remoteserver_runspeed'; null/alienarena_ded-cl_null.o:./source/null/../qcommon/qcommon.h:745: first defined here /usr/bin/ld: qcommon/alienarena_ded-common.o:./source/qcommon/qcommon.h:744: multiple definition of `remoteserver_jousting'; null/alienarena_ded-cl_null.o:./source/null/../qcommon/qcommon.h:744: first defined here /usr/bin/ld: qcommon/alienarena_ded-common.o:./source/./game/q_shared.h:264: multiple definition of `com_parseLine'; game/alienarena_ded-q_shared.o:./source/game/q_shared.h:264: first defined here [...] More information about the corresponding GCC change can be found here: https://gcc.gnu.org/gcc-10/porting_to.html "Default to -fno-common" Andreas
Bug#966189: cuneiform: FTBFS with GCC 10: multiple definition of ... due to -fno-common
Source: cuneiform Version: 1.1.0+dfsg-7.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, cuneiform started to FTBFS when GCC 10 was made the default compiler: [ 31%] Linking CXX shared library librlings.so cd /build/cuneiform-1.1.0+dfsg/obj/cuneiform_src/Kern/rling/sources && /usr/bin/cmake -E cmake_link_script CMakeFiles/rlings.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -g -O2 -fdebug-prefix-map=/build/cuneiform-1.1.0+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++98 -Wno-error -Wl,-Bsymbolic -Wl,-z,relro -Wl,--as-needed -shared -Wl,-soname,librli ngs.so.0 -o librlings.so.1.1.0 CMakeFiles/rlings.dir/cpp/crled.cpp.o CMakeFiles/rlings.dir/cpp/crling.cpp.o CMakeFiles/rlings.dir/cpp/crlmemory.cpp.o CMakeFiles/rlings.dir/cpp/dll.cpp.o CMakeFiles/rlings.dir/cpp/rlcontrol.cpp.o CMakeFiles/rlings.dir/c/rling_m a.c.o CMakeFiles/rlings.dir/c/spel2dic.c.o CMakeFiles/rlings.dir/c/spel2voc.c.o CMakeFiles/rlings.dir/c/spelabc.c.o CMakeFiles/rlings.dir/c/spelart.c.o CMakeFiles/rlings.dir/c/spelbuf.c.o CMakeFiles/rlings.dir/c/spelchk.c.o CMakeFiles/rlings.dir/c/speldat1.c. o CMakeFiles/rlings.dir/c/speldat2.c.o CMakeFiles/rlings.dir/c/speldici.c.o CMakeFiles/rlings.dir/c/speldict.c.o CMakeFiles/rlings.dir/c/speldvoc.c.o CMakeFiles/rlings.dir/c/speledf1.c.o CMakeFiles/rlings.dir/c/speledf2.c.o CMakeFiles/rlings.dir/c/speledio.c. o CMakeFiles/rlings.dir/c/spelfun.c.o CMakeFiles/rlings.dir/c/spelloop.c.o CMakeFiles/rlings.dir/c/spelout.c.o CMakeFiles/rlings.dir/c/spelq.c.o CMakeFiles/rlings.dir/c/spelset.c.o CMakeFiles/rlings.dir/c/spelspec.c.o CMakeFiles/rlings.dir/c/udictini.c.o CMak eFiles/rlings.dir/c/udictuti.c.o -Wl,-rpath,/build/cuneiform-1.1.0+dfsg/obj/cuneiform_src/Kern/cstr:/build/cuneiform-1.1.0+dfsg/obj/cuneiform_src/Kern/cfcompat:/build/cuneiform-1.1.0+dfsg/obj/cuneiform_src/Kern/ccom: ../../cstr/libcstr.so.1.1.0 ../../cfcompa t/libcfcompat.so.1.1.0 ../../ccom/libccom.so.1.1.0 -ldl /usr/bin/ld: CMakeFiles/rlings.dir/c/speldici.c.o:./obj/cuneiform_src/Kern/rling/sources/./cuneiform_src/Kern/rling/sources/c/speldici.c:123: multiple definition of `my_free'; CMakeFiles/rlings.dir/c/rling_ma.c.o:./obj/cuneiform_src/Kern/rling/sources/./cunei form_src/Kern/rling/sources/c/rling_ma.c:110: first defined here /usr/bin/ld: CMakeFiles/rlings.dir/c/speldici.c.o:./obj/cuneiform_src/Kern/rling/sources/./cuneiform_src/Kern/rling/sources/c/speldici.c:122: multiple definition of `my_alloc'; CMakeFiles/rlings.dir/c/rling_ma.c.o:./obj/cuneiform_src/Kern/rling/sources/./cune iform_src/Kern/rling/sources/c/rling_ma.c:109: first defined here More information about the corresponding GCC change can be found here: https://gcc.gnu.org/gcc-10/porting_to.html "Default to -fno-common" Andreas
Bug#966188: d2x-rebirth: FTBFS with GCC 10: multiple definition of ... due to -fno-common
Source: d2x-rebirth Version: 0.58.1-1.2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, d2x-rebirth started to FTBFS when GCC 10 was made the default compiler: gcc -o d2x-rebirth -Wl,-z,relro 2d/2dsline.o 2d/bitblt.o 2d/bitmap.o 2d/box.o 2d/canvas.o 2d/circle.o 2d/disc.o 2d/font.o 2d/gpixel.o 2d/line.o 2d/palette.o 2d/pcx.o 2d/pixel.o 2d/rect.o 2d/rle.o 2d/scalec.o 3d/clipper.o 3d/draw.o 3d/globvars.o 3d/instance.o 3d/interp.o 3d/matrix.o 3d/points.o 3d/rod.o 3d/setup.o arch/sdl/event.o arch/sdl/init.o arch/sdl/joy.o arch/sdl/key.o arch/sdl/mouse.o arch/sdl/rbaudio.o arch/sdl/timer.o arch/sdl/window.o arch/sdl/digi.o arch/sdl/digi_audio.o iff/iff.o libmve/decoder8.o libmve/decoder16.o libmve/mve_audio.o libmve/mvelib.o libmve/mveplay.o main/ai.o main/ai2.o main/aipath.o main/automap.o main/bm.o main/cntrlcen.o main/collide.o main/config.o main/console.o main/controls.o main/credits.o main/digiobj.o main/dumpmine.o main/effects.o main/endlevel.o main/escort.o main/fireball.o main/fuelcen.o main/fvi.o main/game.o main/gamecntl.o main/gamefont.o main/gamemine.o main/gamepal.o main/gamerend.o main/gamesave.o main/gameseg.o main/gameseq.o main/gauges.o main/hostage.o main/hud.o main/inferno.o main/kconfig.o main/kmatrix.o main/laser.o main/lighting.o main/menu.o main/mglobal.o main/mission.o main/morph.o main/movie.o main/multi.o main/multibot.o main/newdemo.o main/newmenu.o main/object.o main/paging.o main/physics.o main/piggy.o main/player.o main/playsave.o main/polyobj.o main/powerup.o main/render.o main/robot.o main/scores.o main/segment.o main/slew.o main/songs.o main/state.o main/switch.o main/terrain.o main/texmerge.o main/text.o main/titles.o main/vclip.o main/wall.o main/weapon.o maths/fixc.o maths/rand.o maths/tables.o maths/vecmat.o mem/mem.o misc/args.o misc/error.o misc/hash.o misc/hmp.o misc/ignorecase.o misc/physfsrwops.o misc/physfsx.o misc/strio.o misc/strutil.o texmap/ntmap.o texmap/scanline.o arch/ogl/gr.o arch/ogl/ogl.o arch/sdl/digi_mixer.o arch/sdl/digi_mixer_music.o arch/sdl/jukebox.o main/net_udp.o main/vers_id.o -lSDL -lphysfs -lm -lGL -lGLU -lSDL_mixer /usr/bin/ld: texmap/ntmap.o:./texmap/ntmap.c:58: multiple definition of `Max_perspective_depth'; main/render.o:./main/render.c:72: first defined here collect2: error: ld returned 1 exit status scons: *** [d2x-rebirth] Error 1 More information about the corresponding GCC change can be found here: https://gcc.gnu.org/gcc-10/porting_to.html "Default to -fno-common" Andreas
Bug#966186: u-boot-omap: Unusable on BeagleBone Black
Package: u-boot-omap
Version: 2020.07+dfsg-1
Severity: normal
I've successfully installed u-boot to an SD card and set my BeagleBone
Black to not boot from MMC. However, when u-boot runs, it cannot
boot the kernel:
==
U-Boot SPL 2020.07+dfsg-1 (Jul 08 2020 - 23:29:02 +)
Trying to boot from MMC1
U-Boot 2020.07+dfsg-1 (Jul 08 2020 - 23:29:02 +)
CPU : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM: 512 MiB
WDT: Started with servicing (60s timeout)
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to use mmc 0:1... not set.
Validating first E-fuse MAC
Net: eth0: ethernet@4a10
Warning: usb_ether MAC addresses don't match:
Address in ROM is de:ad:be:ef:00:01
Address in environment is c8:df:84:dc:f1:6a
, eth1: usb_ether
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Unrecognized filesystem type **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
1634 bytes read in 7 ms (227.5 KiB/s)
## Executing script at 8000
4260352 bytes read in 277 ms (14.7 MiB/s)
SCRIPT FAILED: continuing...
...
==
For some reason, the u-boot environment has `board_name=BBG1` so it
thinks the board is a BeagelBone Green. If I reset the environment,
the board_name variable is set to:
==
=> env default -a -
## Resetting to default environment
=> pri
...
board_name=am335x
...
==
Which likewise fails to boot:
==
=> boot
WARNING: Could not determine device tree to use
...
==
If I set the board_name variable to `A335BNLT` then it can boot OK.
However, I cannot save the environment using an ext2 root:
==
=> setenv board_name A335BNLT
=> saveenv
Saving Environment to FAT... Unable to use mmc 0:1... Failed (1)
==
If I try to build an image using a vfat /boot partition then
flash-kernel causes an error while installing the kernel:
==
Installing /usr/lib/linux-image-4.19.0-9-armmp/am335x-boneblack.dtb into
/boot/dtbs/4.19.0-9-armmp/./am335x-boneblack.dtb
Installing new am335x-boneblack.dtb.
/usr/bin/ln: failed to create symbolic link '/boot/dtb-4.19.0-9-armmp':
Operation not permitted
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-4.19.0-9-armmp (--configure):
installed linux-image-4.19.0-9-armmp package post-installation script
subprocess returned error exit status 1
==
So the package is unfortunatley unusable on the BeagleBone Black.
-- System Information:
Debian Release: 10.4
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: armhf (armv7l)
Kernel: Linux 4.19.0-9-armmp (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Bug#966187: d1x-rebirth: FTBFS with GCC 10: multiple definition of ... due to -fno-common
Source: d1x-rebirth Version: 0.58.1-1.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, d1x-rebirth started to FTBFS when GCC 10 was made the default compiler: gcc -o d1x-rebirth -Wl,-z,relro 2d/2dsline.o 2d/bitblt.o 2d/bitmap.o 2d/box.o 2d/canvas.o 2d/circle.o 2d/disc.o 2d/font.o 2d/gpixel.o 2d/line.o 2d/palette.o 2d/pcx.o 2d/pixel.o 2d/poly.o 2d/rect.o 2d/rle.o 2d/scalec.o 3d/clipper.o 3d/draw.o 3d/globvars.o 3d/i nstance.o 3d/interp.o 3d/matrix.o 3d/points.o 3d/rod.o 3d/setup.o arch/sdl/event.o arch/sdl/init.o arch/sdl/joy.o arch/sdl/key.o arch/sdl/mouse.o arch/sdl/rbaudio.o arch/sdl/timer.o arch/sdl/window.o arch/sdl/digi.o arch/sdl/digi_audio.o iff/iff.o main/ai.o m ain/aipath.o main/automap.o main/bm.o main/bmread.o main/cntrlcen.o main/collide.o main/config.o main/console.o main/controls.o main/credits.o main/custom.o main/digiobj.o main/dumpmine.o main/effects.o main/endlevel.o main/fireball.o main/fuelcen.o main/fvi. o main/game.o main/gamecntl.o main/gamefont.o main/gamemine.o main/gamerend.o main/gamesave.o main/gameseg.o main/gameseq.o main/gauges.o main/hostage.o main/hud.o main/inferno.o main/kconfig.o main/kmatrix.o main/laser.o main/lighting.o main/menu.o main/mglo bal.o main/mission.o main/morph.o main/multi.o main/multibot.o main/newdemo.o main/newmenu.o main/object.o main/paging.o main/physics.o main/piggy.o main/player.o main/playsave.o main/polyobj.o main/powerup.o main/render.o main/robot.o main/scores.o main/slew .o main/snddecom.o main/songs.o main/state.o main/switch.o main/terrain.o main/texmerge.o main/text.o main/titles.o main/vclip.o main/wall.o main/weapon.o maths/fixc.o maths/rand.o maths/tables.o maths/vecmat.o mem/mem.o misc/args.o misc/dl_list.o misc/error. o misc/hash.o misc/hmp.o misc/ignorecase.o misc/physfsx.o misc/strio.o misc/strutil.o texmap/ntmap.o texmap/scanline.o arch/ogl/gr.o arch/ogl/ogl.o arch/sdl/digi_mixer.o arch/sdl/digi_mixer_music.o arch/sdl/jukebox.o main/net_udp.o main/vers_id.o -lSDL -lphys fs -lm -lGL -lGLU -lSDL_mixer /usr/bin/ld: arch/sdl/mouse.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/ai.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/automap.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/bm.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/bmread.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/cntrlcen.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/collide.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/endlevel.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/fireball.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/fuelcen.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/game.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/gamecntl.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/gamerend.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here /usr/bin/ld: main/gamesave.o:./main/multi.h:184: multiple definition of `multi_allow_powerup_mask'; arch/sdl/joy.o:./main/multi.h:184: first defined here [...] More information about the corresponding GCC change can be found here: https://gcc.gnu.org/gcc-10/porting_to.html "Default to -fno-common" Andreas
Bug#966173: libc6: __atan2_finite reference in dlopened module no longer found in executable linked to libm
On Fri, 24 Jul 2020 at 14:36:54 +0200, Bastian Blank wrote:
> On Fri, Jul 24, 2020 at 10:11:04AM +0100, Simon McVittie wrote:
> > The bug (#966150) is that a version of uix86_64.so compiled with a slightly
> > older (2020-02-18) toolchain fails to load on an up-to-date sid system,
> > with:
> > undefined symbol: __atan2_finite
>
> Because the binary was not linked with -lm, the linker never saw the
> real symbol __atan2_finite@GLIBC2_16, so the linke only emitted a reference
> to __atan2_finite.
Right. However, note that there's no mention of __atan2_finite() in the
source code - it's only used because older glibc would replace atan2()
with a reference to __atan2_finite() when building with -ffast-math.
> At least dpkg-shlibdeps or so should warn about that.
For at least openarena, it doesn't seem to. I'm not sure why not.
For the next update to openarena I'm going to build it with -Wl,-z,defs
so that missing dependencies are always fatal. However, that isn't
always applicable: some plugin architectures (like Python extensions)
rely on being able to pick up symbols exported by the executable, which
are not necessarily programmatically distinguishable from symbols that
are defined by libraries used by the executable.
> > I've been trying to put together a standalone reproducer that only uses
> > libdl and libm, but so far I have not been successful.
>
> Something like that?
>
> | % cat test.c
> | void __atan2_finite(void);
> | void test(void) {
> | __atan2_finite();
> | }
I was aiming for something a bit closer to openarena's situation,
where there is no explicit reference to __atan2_finite() in the source
code: it calls atan2(), and cc -ffast-math rewrites that into a call
to __atan2_finite(). I've now managed to make this work: see attached.
Compile them and run ./prog in a buster environment (or an outdated
bullseye/sid environment with glibc < 2.31), then run ./prog in an
up-to-date bullseye/sid environment without recompiling.
libmymodule.so will get a dynamic reference to __atan2_finite.
The historical result is that prog outputs 0.463648, twice.
The result in up-to-date bullseye/sid is that prog outputs 0.463648,
once, and then fails with "undefined symbol: __atan2_finite".
Using __FINITE_MATH_ONLY__ (which is defined by -ffast-math) is necessary
to be able to reproduce the bug this way.
If you consider this sort of thing to be too niche to be supportable,
please feel free to close the bug.
smcv
all = prog libmymodule.so
CFLAGS = -ffast-math
check: $(all)
objdump -Tx libmymodule.so
./prog
all: $(all)
prog: prog.c Makefile
$(CC) $(CFLAGS) -Wl,--no-as-needed -o $@ $< -ldl -lm
# Note that this cannot be compiled with -Wl,-z,defs: it deliberately has
# undefined references to symbols from libm
libmymodule.so: module.c Makefile
$(CC) $(CFLAGS) -shared -o $@ $<
clean:
rm -f $(all)
#include
#include
#include
#include
#if !defined(__FINITE_MATH_ONLY__) || !__FINITE_MATH_ONLY__
#warning Not using finite-only mathematics
#endif
int main (void)
{
void *module;
double (*my_atan2) (double, double);
printf ("%f\n", atan2 (1, 2));
module = dlopen ("${ORIGIN}/libmymodule.so", RTLD_NOW);
if (module == NULL)
errx(1, "%s", dlerror ());
my_atan2 = (double (*) (double, double)) dlsym (module, "my_atan2");
if (my_atan2 == NULL)
errx(1, "%s", dlerror ());
printf ("%f\n", my_atan2 (1, 2));
return 0;
}
#if !defined(__FINITE_MATH_ONLY__) || !__FINITE_MATH_ONLY__
#warning Not using finite-only mathematics
#endif
#include
double my_atan2 (double x, double y)
{
return atan2 (x, y);
}
Bug#966096: geeqie: immediate segfault
Alas, no. Same symptom. FWIW, I'm attaching the tail end of an strace log, and a (long) list of the shared libraries used, per ldd. I note that in the latter list, there are no nvidia libraries - but the strace log shows it was looking for (and apparently not finding) libGLX_nvidia.so.0. apt-find indicates that library can be found in these packages: $ apt-file search libGLX_nvidia.so.0 libglx-nvidia-legacy-390xx0: /usr/lib/x86_64-linux-gnu/nvidia/legacy-390xx/libGLX_nvidia.so.0 libglx-nvidia-tesla-418-0: /usr/lib/x86_64-linux-gnu/nvidia/tesla-418/libGLX_nvidia.so.0 libglx-nvidia-tesla-440-0: /usr/lib/x86_64-linux-gnu/nvidia/tesla-440/libGLX_nvidia.so.0 libglx-nvidia-tesla-450-0: /usr/lib/x86_64-linux-gnu/nvidia/tesla-450/libGLX_nvidia.so.0 libglx-nvidia0: /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0 I don't suppose the tesla packages are relevant, and apt-get isn't able to find the other two. The first is supposed to be in non-free. My /etc/apt/sources.list already includes deb http://ftp.us.debian.org/debian/ unstable main contrib non-free Should I have something else configured to access that package? On Fri, Jul 24, 2020, 9:36 AM Andreas Ronnquist wrote: > On Thu, 23 Jul 2020 08:08:26 -0400 > James Van Zandt wrote: > > >Thanks, I'll do that when I get a chance. > > > >In the meantime (since I assume the package is working for you), could > >you compare our shared library versions? If we're out of sync, maybe > >there's an unrecognized incompatibility. > > I have uploaded a new git snapshot to unstable (1:1.5.1+git20200723-2), > please test that one too if it changes anything. > > /Andreas > trace.log.excerpt Description: Binary data shared-libraries Description: Binary data
Bug#927302: apache2ctl graceful can cause apache to run in a different cgroup
On Wed, 17 Apr 2019 13:05:08 -0400 Joey Hess wrote: > Package: apache2 > Version: 2.4.38-2 > Severity: normal > > If apache is not running when apache2ctl graceful is run, it starts the > daemon up itself: > > root@darkstar:~>systemctl stop apache2 > root@darkstar:~>apache2ctl graceful > httpd not running, trying to start > > Problem is, that results in an apache daemon running in a cgroup other > than the usual systemd cgroup for apache. > > That prevents systemctl from being used to manage apache. In particular, > both systemctl start apache2 and systemctl restart apache2 then silently > do nothing and exit 0. > > Seems this could happen in a race, if something runs apache2ctl > graceful just as apache is being upgraded or otherwise restarted, it > might see no apache process running and so start its own process up. > > I keep encountering this problem on a server intermittently. It has > resulted for me in apache not loading new letsencrypt certs for long > enough that certs have expired, at least twice. I don't entirely > understand why, since certbot seems to itself use apache2ctl graceful to > reload apache certs. > > IMHO, apache2ctl should not be starting the daemon itself when systemd > is in use; it ought to start it via systemctl or service. And indeed, > apache2ctl start already does do that, but the fix for #839227 missed > that apache2ctl graceful can also start apache. I had a look at the apache2ctl script [1] and I agree in that the "restart|graceful)" case stanza requires the same change that fixed the bug #839227 for the "start" command. I'd also move the need_systemd logic out of the "case" to avoid duplication. Paride [1] https://salsa.debian.org/apache-team/apache2/-/blob/master/debian/apache2ctl
Bug#953075: debian-reference: Incorrect environment example for 'date' in section 1.5.2
Thank you for taking the time to respond to this. I was reading the Debian Reference shortly after a clean install of bullseye. (It's a very useful document, BTW, thanks for doing it.) However I have been running Debian for years and migrated some config files over from a previous installation so perhaps my setup does not reflect the usual defaults. Here is the info you asked for: hank@SunVillage:~$ locale LANG=en_CA.utf8 LANGUAGE= LC_CTYPE="en_CA.utf8" LC_NUMERIC=en_CA.UTF-8 LC_TIME=en_CA.UTF-8 LC_COLLATE="en_CA.utf8" LC_MONETARY=en_CA.UTF-8 LC_MESSAGES="en_CA.utf8" LC_PAPER=en_CA.UTF-8 LC_NAME=en_CA.UTF-8 LC_ADDRESS=en_CA.UTF-8 LC_TELEPHONE=en_CA.UTF-8 LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=en_CA.UTF-8 LC_ALL= hank@SunVillage:~$ echo $XDG_CURRENT_DESKTOP='XDG_CURRENT_DESKTOP' XFCE=XDG_CURRENT_DESKTOP I am not sure what is setting the various LC_ variables. I grepped my home directory, /etc/bash.bashrc and /etc/profile and the only result that references LC_ is ".xsession-errors:dbus-update-activation-environment: setting LC_TIME=en_CA.UTF-8" in my home directory; there are similar entries for all the other LC_ variables in my environment. Is there some configuration of dbus that sets those variables? If so, I don't know where that is configured. I fear I have enough Linux experience to get in trouble but not enough to be really knowledgeable! Best, Hank Knox On 2020-07-23 10:44 p.m., Osamu Aoki wrote: Hmmm... I agree this is probably not a bug but a user support problem. Let me add a comment: I chose to use $LANG to set the locale since that seems to be the way default install configures used by Debian system. Hank, if you are facing this issue on some default install system without violating my recommendation, let is know your desktop etc. Please run the following to check: $ locale $ echo "XDG_CURRENT_DESKTOP='$XDG_CURRENT_DESKTOP'" Report it back to this bug Hank, anyway did you read on to the last part of 1.5.2 first: See locale(5) and locale(7) for "$LANG" and related environment variables. [Note] Note I recommend you to configure the system environment just by the "$LANG" variable and to stay away from "$LC_*" variables unless it is absolutely needed. I am pretty sure your system doesn't follow my recommendation. FYI: locale(7) describes: 1. If there is a non-null environment variable LC_ALL, the value of LC_ALL is used. 2. If an environment variable with the same name as one of the categories above exists and is non-null, its value is used for that category. 3. If there is a non-null environment variable LANG, the value of LANG is used.
Bug#965217: libgrpc++1: ServerBuilder::BuildAndStart hangs
I’ve just reuploaded Abseil with an shlibs file instead of a symbols file. The symbols file doesn’t buy us a whole lot anyway, since Abseil is going to break ABI with every release.
Bug#951048: util-linux: please build with dm-verity support when uploading 2.35
On Fri, 2020-07-24 at 15:19 +0200, Chris Hofstaedtler wrote: > Luca, Helmut, everyone reading at home, > > * Luca Boccassi [200724 15:11]: > > > PR opened at https://github.com/karelzak/util-linux/pull/1084 > > > > PR for dlopen() has been merged and it's part of the 2.36 release which > > was just uploaded to unstable, so opened another MR to enable it again > > (in dlopen mode): > > > > https://salsa.debian.org/debian/util-linux/-/merge_requests/16 > > > > Built locally and confirmed there's no linkage, and thus no dependency, > > and strace shows libcryptsetup is only loaded if one of the verity > > options is requested, so there should not be any conflict in the > > future. > > Okay, I see the PR. > > However: > > 1) Helmut, will this cause problems again for bootstrapping or is > this fine? > > 2) What exactly are we doing this for? What is the usecase for > Debian? 1) Helmut should double-check, but there's no runtime dependency of any kind (-dev package, pkg-config, linking) and the build-dep is marked as !stage1, so should all be good on that front as far as I can tell 2) it's an end-user feature for anybody (myself being one) wanting to use verity-protected volumes (integrity checks, possible signature checks) on their machines https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#966096: geeqie: immediate segfault
On Thu, 23 Jul 2020 08:08:26 -0400 James Van Zandt wrote: >Thanks, I'll do that when I get a chance. > >In the meantime (since I assume the package is working for you), could >you compare our shared library versions? If we're out of sync, maybe >there's an unrecognized incompatibility. I have uploaded a new git snapshot to unstable (1:1.5.1+git20200723-2), please test that one too if it changes anything. /Andreas
Bug#966183: abseil FTBFS on !amd64/ppc64: missing symbols
On Friday, July 24, 2020, at 2:58 PM +0300, Adrian Bunk wrote: > When the soname of the library encodes the exact upstream > version as abseil does, there are exactly zero benefits > of using a symbols - every update of abseil will be a > library transition in any case. Makes sense. I was hoping to stick with the symbols infrastructure because it’s what I’m familiar with, but I’m completely convinced at this point that it’s going to be more trouble than it’s worth. I’ll reupload today with shlibs instead.
Bug#951048: util-linux: please build with dm-verity support when uploading 2.35
Luca, Helmut, everyone reading at home, * Luca Boccassi [200724 15:11]: > > PR opened at https://github.com/karelzak/util-linux/pull/1084 > > PR for dlopen() has been merged and it's part of the 2.36 release which > was just uploaded to unstable, so opened another MR to enable it again > (in dlopen mode): > > https://salsa.debian.org/debian/util-linux/-/merge_requests/16 > > Built locally and confirmed there's no linkage, and thus no dependency, > and strace shows libcryptsetup is only loaded if one of the verity > options is requested, so there should not be any conflict in the > future. Okay, I see the PR. However: 1) Helmut, will this cause problems again for bootstrapping or is this fine? 2) What exactly are we doing this for? What is the usecase for Debian? Chris
Bug#951048: util-linux: please build with dm-verity support when uploading 2.35
Control: tags -1 patch On Tue, 30 Jun 2020 09:30:34 +0100 Luca Boccassi wrote: > On Mon, 2020-06-29 at 20:11 +0200, Michael Biebl wrote: > > Hi Luca > > > > On Mon, 29 Jun 2020 12:16:39 +0100 Luca Boccassi wrote: > > > On Mon, 2020-06-29 at 12:58 +0200, Michael Biebl wrote: > > > > Am 29.06.20 um 12:41 schrieb Luca Boccassi: > > > > > In terms of image size, what % does that additional 5.6MB represent? > > > > > > > > A minbase debootstrap of bullseye is currently 197M > > > > > > Thanks - so about ~2.5%. I can look into changing to dlopen as you > > > suggested in the next few days. > > > > I see that Simon has been very active in tracking down and informing all > > affected upstreams and trying to get them on board in fixing this in a > > coordinated fashion. > > > > As far as libmount is concerned, I think going the upstream route is > > definitely the right approach. We shouldn't do this downstream. Let's > > see what Karel has to say. > > Btw, thanks for the offer to look into this. > > > > Regards, > > Michael > > PR opened at https://github.com/karelzak/util-linux/pull/1084 PR for dlopen() has been merged and it's part of the 2.36 release which was just uploaded to unstable, so opened another MR to enable it again (in dlopen mode): https://salsa.debian.org/debian/util-linux/-/merge_requests/16 Built locally and confirmed there's no linkage, and thus no dependency, and strace shows libcryptsetup is only loaded if one of the verity options is requested, so there should not be any conflict in the future. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels
On Wed, Jul 22, 2020 at 03:28:39PM -0400, Gabriel Krisman Bertazi wrote: Hi, Well, after an analyze on my side, the EFI mode is detected based on the EFI stub, right ? Then the kernel populates the FDT with EFI properties into its own address space (based on what was previously found from the stub). Kexec simply does not preserve the EFI mode at all for arm64, it is only present for x86. With the original debian patch, we suppose that the "secure-boot" property will always be set in the FDT, simply because this information should be found in the EFI stub (unset, disabled, enabled, etc...), so the corresponding FDT property will always have a value and will always be present. So assume that it is always the case is correct, imho. Now, if the EFI stubs informations are not passed to the second stage kernel, either nor "system table" or "secure-boot" or the rest will be found, explaining the issue of the first comment (read the first comment it is "System table" that is not found). We should have a "setup_efi_info" like it is the case in the kexec-tools code base for x86, except we should have something similar for arm64. Regards, Romain signature.asc Description: PGP signature
Bug#966170: ITP: ayatana-indicator-datetime -- Ayatana Indicator providing clock and calendar
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: ayatana-indicator-datetime Version : 0.4.0 Upstream Author : Mike Gabriel * URL : https://github.com/AyatanaIndicators/ayatana-indicator-datetime * License : GPL-3 Programming Lang: C++ Description : Ayatana Indicator providing clock and calendar This Ayatana Indicator provides a combined calendar, clock, alarm and event management tool.
Bug#959963: Updating qterminal to version 0.15.0
Hi, is there any chance that one of you can take care of updating qterminal to the latest upstream version? Version 0.15 is available and it seems to fix a bunch of issues for many persons. It's our main terminal in Kali and we would like to see the latest version in Debian. https://github.com/lxqt/qterminal/releases/download/0.15.0/qterminal-0.15.0.tar.xz If you don't have the time to handle this, are you OK with a NMU to upload the new version? Feel free to grant me (temporary if you want) membership in the lxqt team on salsa if you want me to commit this to the git repository (I'm user 'hertzog'). I expect the work to be relatively easy given that Ubuntu already did it: https://launchpad.net/ubuntu/+source/qterminal/0.15.0-0ubuntu1 Thank you in advance! -- Raphaël Hertzog ◈ Offensive Security ◈ Kali Linux Developer
Bug#966173: libc6: __atan2_finite reference in dlopened module no longer found in executable linked to libm
On Fri, Jul 24, 2020 at 10:11:04AM +0100, Simon McVittie wrote:
> The bug (#966150) is that a version of uix86_64.so compiled with a slightly
> older (2020-02-18) toolchain fails to load on an up-to-date sid system, with:
> undefined symbol: __atan2_finite
Because the binary was not linked with -lm, the linker never saw the
real symbol __atan2_finite@GLIBC2_16, so the linke only emitted a reference
to __atan2_finite. At least dpkg-shlibdeps or so should warn about that.
> I've been trying to put together a standalone reproducer that only uses
> libdl and libm, but so far I have not been successful.
Something like that?
| % cat test.c
| void __atan2_finite(void);
| void test(void) {
| __atan2_finite();
| }
| % gcc --shared -o test.so test.c -Wall -W
| % objdump -x test.so | grep atan
| *UND* __atan2_finite
Regards,
Bastian
--
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8
Bug#962995: fixed in testssl.sh 3.0.2+dfsg1-2
On 24.07.20 13:04, Daniel Reichelt wrote: > Thus, I suggest to just remove the dependency on bsdextrautils > for buster-backports again. *hng* …make that: Thus, I suggest to replace the dependency on bsdextrautils by bsdmainutils for buster-backports. signature.asc Description: OpenPGP digital signature
