Bug#1010419: texstudio: Stop shipping no more needed texstudio.xpm
Package: texstudio Version: 4.2.3+ds-1 Severity: minor Tags: patch Hi, the texstudio packaging manually installs the upstream texstudio.xpm file to /usr/share/pixmaps; considering that - the application icon is already installed in various sizes in the global XDG hicolor icon theme - /usr/share/pixmaps is considered a legacy locations (unthemed, unsized, etc) then it would make sense to not ship /usr/share/pixmaps/texstudio.xpm anymore. Patch attached for this. Thanks, -- Pino --- a/debian/texstudio.install +++ b/debian/texstudio.install @@ -6,6 +6,3 @@ usr/share/icons usr/share/texstudio/CREDITS/usr/share/doc/texstudio usr/share/texstudio/*.badWords usr/share/texstudio/*.stopWords* - -# installing from upstream -utilities/texstudio.xpm/usr/share/pixmaps
Bug#1010276: Bug#1010276: parasail: compiles something extra (or less) depending on the CPU features available
Hi Étienne, Am Sun, May 01, 2022 at 10:50:16AM +0200 schrieb Étienne Mollier: > I'm still looking up this issue, but I wrap up a status to clear > my mind. > > To me, the main topic of the bug is the reproducibility issue[1] > observed on i386, but other architectures may be affected. The > difference is of one *.a file, and after looking up the d/rules > file, this seems to be caused by the assumption that find sorts > in a predictable way in the recipe below, which is not the case: > > override_dh_install: > dh_install > mv `find .libs -name "libparasail*.a" | head -n1` > debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libparasail.a > d-shlibmove --commit \ > --multiarch \ > --devunversioned \ > --exclude-la \ > --movedev debian/tmp/usr/include usr \ > --movedev "debian/tmp/usr/lib/*/pkgconfig/*.pc" > usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig \ > debian/tmp/usr/lib/*/*.so > rm debian/libparasail-dev/usr/lib/$(DEB_HOST_MULTIARCH)/libparasail.a > dh_install -p libparasail-dev .libs/*.a usr/lib/$(DEB_HOST_MULTIARCH) > find debian -name "lib*.la" -delete > > I would welcome thoughts on the intent of this part of the code, > because I'm not sure which .a is the one that is supposed to be > selected. If the content is not that important, then maybe it > is just a matter of putting a `sort` between the `find` and the > `head` in the `mv` command. Thanks for having a look into this. I think it does not matter much wgat file is copied here since it is removed afterwadrs inside the rm statement. It was just a trick to make d-shlibmove not complaining about a missing libparasail.a file which is provided that way. Later in the `dh_install -p` statement simply all *.a files are copied by keeping their names whatever it might be. > [1]: > https://tests.reproducible-builds.org/debian/dbdtxt/unstable/i386/parasail_2.5+dfsg-3.diffoscope.txt.gz > > Mattia Rizzolo, on 2022-04-27: > > In fact, it seems that depending on the type of CPU it builds on, > > sometimes there are slightly different files. For example, on an i386 > > system: > > - usr/lib/i386-linux-gnu/libparasail_novec_table.a > > - usr/lib/i386-linux-gnu/libparasail_sse41_rowcol.a > > - usr/lib/i386-linux-gnu/libparasail_avx2_table.a > > or in an amrhf system: > > - usr/lib/arm-linux-gnueabihf/libparasail_novec.a > > - usr/lib/arm-linux-gnueabihf/libparasail_novec_rowcol.a > > sometimes are there or not. > > While I agree it is an error to build binaries to target > specific CPU when doing large scale distribution, in the case of > parasail, this is actually normal. Upstream implements run time > CPU detection to avoid baseline violation on older CPU. After > building the package with avx2 support, I could run the > autopkgtest suite on a generic x86_64 virtual machine (no avx2, > no sse4) without an illegal instruction crash. From the > README.md file in parasail source code: > > >> parasail uses CPU dispatching at runtime to correctly select > >> the appropriate implementation for the highest level of > >> instruction set supported. > > Interestingly, while trying to understand the variability of > build result, I noticed that we were missing builds for avx512 > instruction set, which seems to stem from ./configure failure to > recognize the option due to warnings occurring in the sample > code when -Wall build option is in use. That's probably worth > forwarding upstream. Thanks for noticing this. > > Furthermore, I notice that amongst the i386 build, there are files such > > as > > - usr/lib/i386-linux-gnu/libparasail_sse2.a > > - usr/lib/i386-linux-gnu/libparasail_sse41.a > > that makes me wonder if the program is unconditially using SSE > > instructions on i386, that would be a baseline violation; but since I > > haven't verified if those features are used unconditially I'm not filing > > this report about this, however please do check. > > On the i386 build, I also see avx2 builds, and I would tend to > think those extensions were never implemented on i386, so I > guess it wouldn't hurt, and would reduce resource consumption on > build machines in the process, that these variants are actually > not built. It should be a matter of just passing --disable-avx2 > and similar to the configure step when targeting i386 host > architecture. ACK. > So I identified three todo items: > 1. address reproducibility issue likely caused by find|head; As I tried to explain this theory is not really plausible. > 2. fix avx512 support for amd64 architecture; This would be great. > 3. disable execessive build artifacts for i386 architecture. My guess is this will rather lead to solving the reproducibly issue. > Thanks Mattia for your work on the reproducible build effort, > these issues may not have been caught otherwise! +1 > Have a nice day, :) +1 Kind regards Andreas. --
Bug#1010418: terminus: Do not set $TERM: may provide qterminal (unuseable with aptitude, ...)
Package: terminus Version: 1.15.1-2 Severity: normal Tags: upstream Dear Maintainer, I am using LXQT with qterminal as default terminal. Note that qterminal has an option to set the TERM variable (by default xterm-256color) When starting from a LXQT launcher (icon, Alt-F2, launcher in panel), terminus keeps TERM sets to "qterminal". It is quite annoying (no backspace in zsh and bash, aptitude do not start, ...). terminus should set the TERM variable to an appropriate value. Probably to xterm-256color ? To reproduce from other terminal, or environment: TERM=qterminal terminus The same test with other terminals: they set the TERM variable as expected (tested: qterminal, terminator, gnome-terminal, konsole, kitty, sakura, urxvt, uxterm, xterm). Thanks Grégory -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 terminus depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii libc62.33-7 ii libcairo21.16.0-5 ii libgee-0.8-2 0.20.5-2 ii libglib2.0-0 2.72.1-1 ii libglib2.0-bin 2.72.1-1 ii libgtk-3-0 3.24.33-1 ii libkeybinder-3.0-0 0.3.2-1.1 ii libpango-1.0-0 1.50.6+ds-2 ii libvte-2.91-00.68.0-1+b1 terminus recommends no packages. terminus suggests no packages. -- no debconf information
Bug#834724: curl: (35) gnutls_handshake() failed: Public key signature verification has failed.
On Sat, 12 Nov 2016 20:22:21 -0500 Kamaraju Kusumanchi wrote: > Confirm that Tim Small solution worked for me as well. I am running > Debian Stretch and removing libgnutls-deb0-28 fixed the error. > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages curl depends on: > ii libc62.24-3 > ii libcurl3-gnutls 7.50.1-1 > ii zlib1g 1:1.2.8.dfsg-2+b1 > > curl recommends no packages. > > curl suggests no packages. > > -- no debconf information > > -- > Kamaraju S. Kusumanchi > http://raju.shoutwiki.com/wiki/Blog > >
Bug#1010360: [Pkg-openssl-devel] Bug#1010360: Set-systemwide-default-settings-for-libssl-users.patch is broken (duplicate key for openssl_conf)
On 2022-04-29 15:52:52 [+0200], Matthias Blümel wrote: > The openssl.cnf contains an entry for openssl_conf since #12333 [1]. > > The attached patch-file should work but I haven't tested it yet. Thank you. Sebastian
Bug#1010381: commons-daemon: FTBFS on riscv64: error: Unsupported CPU architecture "riscv64"
On Sun, May 1, 2022 at 7:41 AM tony mancill wrote: > On Sun, May 01, 2022 at 12:59:27AM +0800, Bo YU wrote: > > On Sun, May 1, 2022 at 12:44 AM tony mancill > wrote: > > > > > On Sun, May 01, 2022 at 12:39:02AM +0800, Bo YU wrote: > > > > > Thank you for the bug report and the patch. I will perform an > upload > > > of > > > > > this package soon. > > > > > > > > > > Thank you. > > > > I will try to send the patch for upstream also ;) > > > > > > Thank you! Note that the Debian package is quite a bit behind > upstream, > > > so I wonder whether the patch is even necessary against upstream > version > > > 1.3.0. (I have not checked yet.) > > > > > If i am not wrong: > > > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=blob_plain;f=src/native/unix/support/apsupport.m4;hb=HEAD > > > > It seems that commons-daemon > > < > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=blob_plain;f=src/native/unix/support/apsupport.m4;hb=HEAD > > > > upstream > > did not support riscv64. > > > > Hmm, another story, in pabs review, deleting the architecture detection > > altogether is a better option from debian-riscv IRC channel talking about > > it. > > if so, this will push upstream to change a lot first i think. And i am > not > > family with the build system, maybe the java lang build does not > > detect on which arch buildng? > > The Debian commons-daemon source package generates (2) binary packages: > > Package: libcommons-daemon-java > Architecture: all > > Package: jsvc > Architecture: any > > So the jsvc package is architecture-specific. > > I will start with applying your patch against the current source version > in Debian and then look at the upgrade. > Ok. Understand it. Thank you :) BR, Bo > > Regards, > tony > >
Bug#1009934: [Pkg-openssl-devel] Bug#1009934: openssl: reproducible-builds: Embeded compiler flags contain build paths
control: forwarded -1 https://github.com/openssl/openssl/pull/11545 On 2022-04-20 15:46:41 [-0700], Vagrant Cascadian wrote: > The compiler flags usually contain the build path on Debian package > builds, and openssl embeds the compiler flags used in various binaries: … > Unfortunately, there are other outstanding issues affecting the > reproducibility of openssl, but applying this patch should reduce the > differences, making it easier to debug the remaining issues. so this report looked awkwardly familiar. The pull request https://github.com/openssl/openssl/pull/11545 should work for you, right? > live well, > vagrant Sebastian
Bug#1009308: libopenexr-dev: Missing Breaks/Replaces libilmbase-dev
Control: severity -1 serious On 2022-04-11 Andreas Metzler wrote: [...] > dpkg: error processing archive > /var/cache/apt/archives/libopenexr-dev_3.1.4-1_amd64.deb (--unpack): > trying to overwrite '/usr/include/OpenEXR/Iex.h', which is also in package > libilmbase-dev:amd64 2.5.7-2 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) [...] Should have been filed with higher severity. (policy 3.5) cu Andreas
Bug#1010413: [Pkg-javascript-devel] Bug#1010413: mocha: ftbfs with nodejs 16: workerpool needs to be updated
On 01/05/2022 01:06, Jérémy Lal wrote: Package: mocha Version: 9.2.2+ds1+~cs28.3.8-1 Severity: important Hi, node-crc ftbfs with nodejs 16 because mocha's parallel mode does: workerpool fails with: TypeError: The "options" argument must be of type object. Received an instance of Array at ChildProcess.target.send (node:internal/child_process:733:7) at Array.forEach () at dispatchQueuedRequests (/usr/share/nodejs/workerpool/src/WorkerHandler.js:262:21) at ChildProcess. (/usr/share/nodejs/workerpool/src/WorkerHandler.js:221:7) After standard uscan update (that I pushed on salsa, please tell me if I can upload it), and a patch to work around webpack < 5, node-crc builds fine with both nodejs 14 and 16. Jérémy Hi Jérémy, sure you can, thanks!
