Bug#1029186: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules
Hi mentors! I packaged new version of libcommons-validator [1] and uploaded again to debian mentors[2], please refer to Upload #2 . The below line from debian/maven.properties was omitted to ensure all the tests get passed. maven.test.failure.ignore=true In fact all the test cases should get passed. But the DomainValidatorStartupTest depends on a package not available in Debian, which breaks the building. I plan to skip it during the testing but have no ways . And finally I decide to remove it entirely through adding a new patch. I’d appreciate for your further sponsorship. [1] https://archive.apache.org/dist/commons/validator/source/commons-validator-1.7-src.tar.gz [2] https://mentors.debian.net/package/libcommons-validator-java/
Bug#1029281: [Pkg-openssl-devel] Bug#1029281: Bug#1029281: openssl: loongarch64 is little endian
On 2023-02-03 10:43:43 [+0800], zhangdandan wrote: > Dear maintainer(s), > The configuration of Loongarch64 should be modified in Openssl. > Please consider the suggestion of Han Gao. I have tested the patch. So it has been tested, thank you. There will be an upload on TUE evenning of 3.0.8 and I plan to include it there. Sebastian
Bug#1028402: rtl-433: Incomplete list of devices
Dear Angus Can you be more details, like what is the command you try and how does it fail? From the standard output of just running rtl-433, I can see they are supposed to be supported: Registered 191 out of 223 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-223 ] If you don't see that, I'll be glad to forward your bug report to upstream issue tracker. Best,
Bug#888315:
Hello, I fixed my problem. strace indicated a problem with netdata's sqlite database. That was not reported in any netdata output. So I deleted the contents of /var/cache/netdata and all was fine. So while my problem is solved, there might be two problems that caused this bug report: - sqlite conversion seems to be faulty. At least that's what the strace output suggests. I attached it for completeness and maybe an upstream bug report. - `apt purge netdata` should delete or offer to delete /var/cache/netdata. If it would have done that, my problem would have been fixed quite soon: [gru:~] % apt purge netdata Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: fonts-glyphicons-halflings libjs-bootstrap libnetfilter-acct1 netdata-core netdata-plugins-bash netdata-plugins-python netdata-web Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: netdata* 0 upgraded, 0 newly installed, 1 to remove and 69 not upgraded. After this operation, 47.1 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 288452 files and directories currently installed.) Removing netdata (1.37.1-2) ... θ70° [gru:~] 6s % ll /var/cache/netdata total 5668 -rw-r- 1 netdata netdata 4096 Feb 3 07:30 context-meta.db -rw-r- 1 netdata netdata 32768 Feb 3 07:32 context-meta.db-shm -rw-r- 1 netdata netdata 61832 Feb 3 07:32 context-meta.db-wal drwxrwx--- 2 netdata netdata 4096 Feb 3 07:30 dbengine/ drwxrwx--- 2 netdata netdata 4096 Feb 3 07:30 dbengine-tier1/ drwxrwx--- 2 netdata netdata 4096 Feb 3 07:30 dbengine-tier2/ -rw-r- 1 netdata netdata 1507328 Feb 3 07:33 netdata-meta.db -rw-r- 1 netdata netdata 32768 Feb 3 07:33 netdata-meta.db-shm -rw-r- 1 netdata netdata 4148872 Feb 3 07:33 netdata-meta.db-wal * "could not find cloud.conf" Yes, I also saw that message when I ran the natively installed netdata daemon * output from starting netdata in the foreground θ61° [gru:~] 3s % sudo netdata -D 2023-02-03 07:20:54: netdata INFO : MAIN : CONFIG: cannot load cloud config '/var/lib/netdata/cloud.d/cloud.conf'. Running with internal defaults. θ63° [gru:~] 1 % That's it. Exit code 1, not helpful... So you could fix that bug, but it would be good if the above mentioned problems would be addressed. Thanks for your work as a maintainer! -- Markus Grunwald
Bug#1030335: python3-pip: PEP 668 support breaks --user/--editable
Package: python3-pip Version: 23.0+dfsg-1 Severity: important X-Debbugs-Cc: f...@obfusk.net Hi! I just updated python3-pip and was greeted with a NEWS message about PEP 668 support: This version of pip introduces PEP 668 support. Debian's python3.11 interpreter will soon (>= 3.11.1-3) declare the installation to be EXTERNALLY-MANAGED, instructing pip to disallow package installation outside virtualenvs. See: https://peps.python.org/pep-0668/ Practically, this means that you can't use pip to install packages outside a virtualenv, on a Debian system, any more. See /usr/share/doc/python3.11/README.venv for more details. If that isn't available yet, check: https://salsa.debian.org/cpython-team/python3/-/blob/master/debian/README.venv Not being able to install packages system-wide seems like a good idea, I fully support that. But I often install the Python packages I'm developing under my own user account with "pip install -e", which is also made impossible by this change. And I intentionally do not use virtualenvs for this because I want to have all dependencies provided by Debian packages, not downloaded from PyPI. And as far as I can tell there is not even an option I can give to pip to tell it to allow me to install to ~/.local anyway. PEP 668 mentions a --break-system-packages (as an example), but such an option doesn't seem to actually exist. - FC
Bug#1030212: puppet-agent: conffiles not removed: /etc/init.d/puppet-agent /etc/default/puppet-agent
On Wed, 2023-02-01 at 23:39 -0500, Jérôme Charaoui wrote: > Thanks for the clarification. I think you meant that I should have used > prior-version "7.21.0-3~" instead of "7.21.0.2~", because the first > version of the package with the service renamed was "7.21.0-3", and that > is also the version where I added those lines in d/puppet-agent.maintscript. The key is to base the prior-version on the version of the upload you are doing that adds the conffile removal, not the version that actually dropped the conffile from the .deb. > I'll adjust the prior-version to "7.22.0-4~" in my next upload, > hopefully that fixes things. That should do it yeah. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1030334: opendkim: does not work with sqlite3
Package: opendkim
Version: 2.11.0~beta2-4
Severity: important
Dear Maintainer,
I have been unable to use opendkim with an sqlite3 data source.
According to the OpenDBX documentation[1], the sqlite backend uses the
host information to provide a path to the directory where the database
is stored, and the database name is used as the name of a file in that
directory.
In order to include this information within opendkim's dataset DSN
string, it seems the absolute pathname must be encoded as described in
opendkim(8):
> No value within the DSN may contain any of the six punctuation
> characters (":", "/", "@", "+", "?" and "=") used to delimit
> portions of the DSN. To include such characters within a value,
> encode them in quoted-printable style (e.g., "=20" will be
> translated into a single space character). Encoding of spaces
> is also advised.
So, in order to use a database path like /etc/mail/config.sqlite, I
would like to use something like this:
KeyTable
dsn:sqlite3://=2Fetc=2Fmail=2F/config.sqlite/table=dkim_keys?keycol=domain?datacol=domain,selector,private_key
However, strace reveals that opendkim is using the host and database
values to construct a database file path without any quoted-printable
decoding, e.g.:
> % strace opendkim-testkey
> [...]
> lstat("=2Fetc=2Fmail=2Fconfig.sqlite", 0x7ffcad8871a0) = -1 ENOENT (No such
> file or directory)
> [...]
>
> opendkim-testkey: dkimf_db_open() failed
I would have expected the database path (host value) to be decoded from
its quoted-printable form before being passed to OpenDBX.
Thank you.
[1]:
https://linuxnetworks.de/doc/index.php?title=OpenDBX/Configuration#sqlite3_backend
-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-21-amd64 (SMP w/2 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 opendkim depends on:
ii adduser 3.118
ii dns-root-data2021011101
ii init-system-helpers 1.60
ii libbsd0 0.11.3-1
ii libc62.31-13+deb11u5
ii libdb5.3 5.3.28+dfsg1-0.8
ii libldap-2.4-22.4.57+dfsg-3+deb11u1
ii liblua5.1-0 5.1.5-8.1+b3
ii libmemcached11 1.0.18-4.2
ii libmilter1.0.1 8.15.2-22
ii libopendbx1 1.4.6-15
ii libopendkim112.11.0~beta2-4
ii librbl1 2.11.0~beta2-4
ii libssl1.11.1.1n-0+deb11u3
ii libunbound8 1.13.1-1
ii libvbr2 2.11.0~beta2-4
ii lsb-base 11.1.0
Versions of packages opendkim recommends:
ii opendkim-tools 2.11.0~beta2-4
opendkim suggests no packages.
-- Configuration Files:
/etc/dkimkeys/README.PrivateKeys [Errno 13] Permission denied:
'/etc/dkimkeys/README.PrivateKeys'
/etc/opendkim.conf changed:
Syslog yes
SyslogSuccess yes
Canonicalizationrelaxed/simple
OversignHeaders From
SigningTable
dsn:sqlite3://=2Fetc=2Fmail=2F/config.sqlite/table=dkim_keys?keycol=domain?datacol=domain
KeyTable
dsn:sqlite3://=2Fetc=2Fmail=2F/config.sqlite/table=dkim_keys?keycol=domain?datacol=domain,selector,private_key
UserID opendkim
UMask 007
Socket local:/run/opendkim/opendkim.sock
PidFile /run/opendkim/opendkim.pid
TrustAnchorFile /usr/share/dns/root.key
-- no debconf information
Bug#1030200: linux-image-6.1.0-3-amd64: "Loading of module with unavailable key is rejected", /proc/keys says key is loaded; system unbootable
Turns out Debian .config includes dyndbg, so I tried booting with dyndbg="+pfm; module iommu =_; module acpi =_" log_buf_len=4M and got A Result. In both cases I broke as in the initrd (too late, it seems), echo MARK > /dev/kmsg modprobe zfs echo MARK > /dev/kmsg modprobe vfat echo MARK > /dev/kmsg then i turned off dyndbg. dmesg and journalctl -b in resp. files (all compressed now, sorry; dmesgs are 4M and journals 6M per). dkms-$kver is /lib/modules/.../dkms (with the DKMSed .kos) and I also added vfat.ko for reference, but that's, naturally, from the package. Interesting bits: /both/ logs have this exact fragment (time is different, of course): [0.756794] integrity: Loaded X.509 cert 'babtop.nabijaczleweli.xyz: 82b7fc21cc3f583ac4a7b05712d95377f41fbdd6' [0.756794] integrity: Loading X.509 certificate: UEFI:db [0.756795] asymmetric_keys:asymmetric_key_preparse: Trying parser 'x509' [0.756834] x509_key_parser:x509_note_sig_algo: X.509: PubKey Algo: 15 [0.756955] x509_key_parser:x509_process_extension: X.509: Extension: 44 [0.756973] x509_key_parser:x509_process_extension: X.509: Extension: 71 [0.756987] x509_key_parser:x509_note_OID: X.509: Unknown OID: [551] 2.16.840.1.113730.1.1 [0.756995] x509_key_parser:x509_process_extension: X.509: Extension: 98 [0.757013] x509_key_parser:x509_process_extension: X.509: Extension: 72 [0.757033] x509_key_parser:x509_process_extension: X.509: Extension: 65 [0.757052] x509_key_parser:x509_process_extension: X.509: Extension: 68 [0.757071] x509_key_parser:x509_process_extension: X.509: Extension: 64 [0.757072] x509_key_parser:x509_process_extension: X.509: subjkeyid 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1 [0.757087] x509_key_parser:x509_note_tbs_certificate: X.509: x509_note_tbs_certificate(,4,04,8,646)! [0.757106] x509_key_parser:x509_note_signature: X.509: Signature: alg=15, size=257 [0.757117] x509_key_parser:x509_akid_note_kid: X.509: AKID: keyid: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1 [0.757118] x509_key_parser:x509_akid_note_kid: X.509: authkeyid 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1 [0.757271] asymmetric_keys:asymmetric_key_preparse: Parser recognised the format (ret 0) [0.757274] integrity: Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1' [0.757687] integrity:load_uefi_certs: integrity: dbx variable wasn't found [0.758064] integrity:load_uefi_certs: integrity: mokx variable wasn't found [0.758435] integrity:load_moklist_certs: integrity: MokListRT variable wasn't found And when loading vfat, both have this (uargs and the mokx digest are different, that's expected): [ 37.135400] MARK [ 40.188878] main:__do_sys_finit_module: finit_module: fd=3, uargs=61bb63d7, flags=0 [ 40.190252] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#32a0287f841a036fa393c1e065c43ae6b2422643311e301c0603550403131544656269616e2053656375 26081 726520426f6f74204341) [ 40.190256] asymmetric_keys:find_asymmetric_key: Look up: "ex:32a0287f841a036fa393c1e065c43ae6b2422643311e301c0603550403131544656269616e2053656375726520426f6f74204341" [ 40.191459] signing:mod_is_hash_blacklisted: 188779 digest: ba2fe77f90be3c8ca26422359c20213f9dd0f68c9b9bbd1f54f47e77e6e124cf [ 40.191470] main:layout_sections: Core section allocation order: [ 40.191472] main:layout_sections:.text [ 40.191473] main:layout_sections:.text.unlikely [ 40.191474] main:layout_sections:.exit.text But when searching for 7e7595e2f222646de0dcfee034bd181ed37844b7 (to get the first instance of a DKMSed module being loaded; that bit also matches the cert serial, apparently), 6.0.0-5-amd64 says this: [1.757036] main:__do_sys_finit_module: finit_module: fd=3, uargs=160ad9df, flags=0 [1.758562] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f7731) [1.758566] asymmetric_keys:find_asymmetric_key: Look up: "ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a" [1.758572] asymmetric_keys:find_asymmetric_key: Request for key 'ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a' err -11 [1.759871] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f7731) [1.759872] asymmetric_keys:find_asymmetric_key: Look up:
Bug#1030189: Let regular users know need to put non-free-firmware in sources.list
> "DK" == David Kalnischkies writes: DK> The message is rather cryptic, but its intent is to catch unaware DK> sid/testing users and those stable users who don't read release notes, I am the perfect user to test it on. I am the one who just has used sid for the last 20 years and all I do is aptiude update; aptiude full-upgrade not even using any GUI, curses, etc. Anyway all those cool names "bookworm" or whatever, no, not even "in one ear and out the other"... they never even get to one ear. I'm like grandma who never watches the news. Wouldn't know if they changed the flag until one day I looked on top of the post office. Anyway to test it on me, "you'll need to give me a special cellphone (.deb) that beeps when there is a (test) national alert", so as not to bother other users.
Bug#1029281: [Pkg-openssl-devel] Bug#1029281: openssl: loongarch64 is little endian
Dear maintainer(s), The configuration of Loongarch64 should be modified in Openssl. Please consider the suggestion of Han Gao. I have tested the patch. Test results of the Loongarch architecture: - Configuration stage Configuring OpenSSL version 3.0.7 for target debian-loong64 Using os-specific seed configuration Created Makefile.in Created Makefile Created include/openssl/configuration.h ** *** *** *** OpenSSL has been successfully configured *** - Generate library files # file libssl.so.3 libssl.so.3: ELF 64-bit LSB shared object, LoongArch, version 1 (SYSV), dynamically linked, BuildID[sha1]=9daab5d80c9c17d1d02077b31361abd0f10e9ba3, with debug_info, not stripped # file libcrypto.so.3 libcrypto.so.3: ELF 64-bit LSB shared object, LoongArch, version 1 (SYSV), dynamically linked, BuildID[sha1]=1b99ba5d0385c1f5c967bf96e42aabcf8aa51dac, with debug_info, not stripped - Generate openssl packages dpkg-deb --root-owner-group --build debian/openssl .. dpkg-deb: building package 'openssl' in '../openssl_3.0.7-2_loong64.deb'. dpkg-deb --root-owner-group --build debian/libssl3 .. dpkg-deb: building package 'libssl3' in '../libssl3_3.0.7-2_loong64.deb'. dpkg-deb --root-owner-group --build debian/libssl-dev .. dpkg-deb: building package 'libssl-dev' in '../libssl-dev_3.0.7-2_loong64.deb'. dpkg-genbuildinfo --build=any -O../openssl_3.0.7-2_loong64.buildinfo Thanks, Dandan Zhang
Bug#1028345: python3-sage: sagemath uninstallable due to python3-sage issues
Package: python3-sage Version: 9.5-4+b3 Followup-For: Bug #1028345 Dear Maintainer, Just confirming the bug remains and it related to #1025874, posted by myself on Dec. 10th 2022. Best, Alexandre -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable-security') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-sage depends on: ii bc1.07.1-3+b1 ii binutils 2.40-2 ii bzip2 1.0.8-5+b1 ii ca-certificates 20211016 pn cliquer ii cmake 3.25.1-1 ii curl 7.87.0-2 pn cython3 pn ecl pn eclib-tools pn fflas-ffpack pn flintqs pn gap-atlasrep pn gap-dev pn gap-online-help pn gap-primgrp pn gap-smallgrp pn gap-table-of-marks pn gap-transgrp pn gfan ii gfortran 4:12.2.0-3 pn glpk-utils pn gmp-ecm pn jmol pn lcalc ii libatlas3-base [libblas.so.3] 3.10.3-13 pn libatomic-ops-dev ii libblas3 [libblas.so.3] 3.11.0-2 ii libboost-dev 1.74.0.3 pn libbraiding-dev pn libbraiding0 pn libbrial-dev pn libbrial-groebner-dev pn libbrial-groebner3 pn libbrial3 ii libbz2-dev1.0.8-5+b1 ii libc6 2.36-8 pn libcdd-dev pn libcdd-tools pn libcliquer-dev pn libcliquer1 pn libcurl4-openssl-dev pn libec-dev pn libec10 pn libecl21.2 pn libecm-dev pn libecm1 ii libffi-dev3.4.4-1 pn libflint-arb-dev pn libflint-arb2 pn libflint-dev pn libflint17 ii libfreetype-dev [libfreetype6-dev]2.12.1+dfsg-4 ii libfreetype6-dev 2.12.1+dfsg-4 pn libgap-dev pn libgap7 pn libgc-dev ii libgcc-s1 12.2.0-14 pn libgd-dev ii libgd32.3.3-7+b1 pn libgf2x-dev pn libgiac-dev pn libgiac0 pn libgivaro-dev pn libgivaro9 pn libglpk-dev ii libglpk40 5.0-1 pn libgmp-dev ii libgmp10 2:6.2.1+dfsg1-1.1 pn libgmpxx4ldbl pn libgsl-dev ii libgsl27 2.7.1+dfsg-3+b1 pn libhomfly-dev pn libhomfly0 pn libiml-dev pn libiml0
Bug#1030249: unexpected "prefclean output on ..." emails since bookworm upgrade
On 2023-02-01 23:35:09, Francesco Poli wrote: > On Wed, 01 Feb 2023 10:25:21 -0500 Antoine Beaupre wrote: [...] > I must admit that I am somewhat surprised that you see all these mail > notifications about fixed packages as something new. > apt-listbugs has notified root by (local) mail about fixed packages for > ages. Through the cron job mechanism and, starting from 2019, through > the manually-implemented mailing in the systemd timer. > > So, I wonder what has changed in your box, when you began to see these > mail notifications... I am not sure. I recently deployed unattended-upgrades on all my machines, and recently upgraded them to bookworm, which might have triggered more of those warnings. 2019 is not that long ago though, was this part of bullseye? [...] > Well, it's the first time that someone complains about these mail > notifications. Hi! :) > Personally, I like to be informed, when a bug that I feared has been > fixed, and the fixed package can finally be upgraded on my box. > > Anyway, that's a matter of preference, I must admit. > Hence, it may make sense to implement an option to silence those > notifications... Glad you are open to the suggestion, thanks! [...] > I think that the best place where I can implement the option is > probably an APT preference to be read (via 'apt-config') by aptcleanup, > which would suppress its " Fixed packages:" output. Yeah, that's what I had in mind too... > But I am afraid that this is not the right time to implement that for > bookworm. > I won't introduce such a change during the freeze. > I will probably do so for trixie, after bookworm is released. Oh, okay. I'm happy to test a patch that would implement this, for what that's worth though... > In the meanwhile, you could try the attached patch as temporary > workaround for your specific case (the "I do not want any mail > notifications" case). > Please let me know whether it works as intended. Ah well, I thought I could write something like this on my own of course, but I didn't want to diverge from upstream and forget I had that patch lying around. I suspect it might just work, indeed, as the caller checks to see if there's any output beforing firing off that email... Thanks for the patch! -- People in glass houses shouldn't throw stones. People in glass cities shouldn't fire missiles. - Banksy
Bug#1030333: mirror submission for mirror01-pcl-ott1.accuris.ca
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror01-pcl-ott1.accuris.ca Type: leaf Archive-architecture: amd64 i386 Archive-http: /debian/ Maintainer: Accuris Technologies Ltd. Country: CA Canada Location: PureColo Kanata Trace Url: http://mirror01-pcl-ott1.accuris.ca/debian/project/trace/ Trace Url: http://mirror01-pcl-ott1.accuris.ca/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror01-pcl-ott1.accuris.ca/debian/project/trace/mirror01-pcl-ott1.accuris.ca
Bug#1030247: ITP: libtext-names-perl -- module for proper name parsing, normalization, recognition and classification
On 3/02/23 3:11 am, Andrius Merkys wrote: Hi Mason, On 2023-02-01 17:04, m...@kohaaloha.com wrote: Text::Namess provides a number of name normalization routines, plus ^ Letter 's' is duplicated (Namess) in package description in debian/control. Best, Andrius fixed, thanks :)
Bug#1030332: libcamera0.0.3:amd64: crashes wireplumber/pipewire sometimes when camera appears
Package: libcamera0.0.3 Version: 0.0.3-4 Severity: normal When a USB camera appears (usbguard allow-device …, or just echo 1 >/sys/…/authorized), the pipewire and/or wireplumber processes sometimes segfault in libcamera. Not always, but doing usbguard block-device followed by usbguard allow-device a couple times makes them crash eventually. I can reproduce this with the integrated camera on two different ThinkPads made a couple years apart, the T25 and P14s Gen2i. Backtraces from coredumpctl debug follow: Core was generated by `/usr/bin/wireplumber'. Program terminated with signal SIGSEGV, Segmentation fault. #0 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_S_left (__x=) at /usr/include/c++/12/bits/stl_function.h:407 407 operator()(const _Tp& __x, const _Tp& __y) const [Current thread is 1 (Thread 0x7fd067eb16c0 (LWP 1508236))] (gdb) bt #0 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_S_left(std::_Rb_tree_node_base*) (__x=) at /usr/include/c++/12/bits/stl_function.h:407 #1 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_M_lower_bound(std::_Rb_tree_node > > >*, std::_Rb_tree_node_base*, unsigned long const&) (__k=@0x7fd067eaff08: 20736, __y=0x7fd05c002e20, __x=0x21, this=0x7fd05c002e18) at /usr/include/c++/12/bits/stl_tree.h:1952 #2 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::lower_bound(unsigned long const&) (__k=@0x7fd067eaff08: 20736, this=0x7fd05c002e18) at /usr/include/c++/12/bits/stl_tree.h:1270 #3 std::map >, std::less, std::allocator > > > >::lower_bound(unsigned long const&) (__x=@0x7fd067eaff08: 20736, this=0x7fd05c002e18) at /usr/include/c++/12/bits/stl_map.h:1307 #4 std::map >, std::less, std::allocator > > > >::operator[](unsigned long const&) (__k=@0x7fd067eaff08: 20736, this=0x7fd05c002e18) at /usr/include/c++/12/bits/stl_map.h:507 #5 libcamera::DeviceEnumeratorUdev::addV4L2Device(unsigned long) (this=0x7fd05c000e10, devnum=) at ../src/libcamera/device_enumerator_udev.cpp:306 #6 0x7fd075efe10f in libcamera::DeviceEnumeratorUdev::addUdevDevice(udev_device*) (this=0x7fd05c000e10, dev=0x7fd05c0037d0) at ../src/libcamera/device_enumerator_udev.cpp:113 #7 0x7fd075efed03 in libcamera::DeviceEnumeratorUdev::udevNotify() (this=0x7fd05c000e10) at ../src/libcamera/device_enumerator_udev.cpp:340 #8 0x7fd075d7092c in libcamera::Signal<>::emit() (this=) at ../include/libcamera/base/signal.h:153 #9 libcamera::EventDispatcherPoll::processNotifiers(std::vector > const&) (this=0x7fd05c0012e0, pollfds=) at ../src/libcamera/base/event_dispatcher_poll.cpp:281 #10 0x7fd075d70dc2 in libcamera::EventDispatcherPoll::processEvents() (this=0x7fd05c0012e0) at ../src/libcamera/base/event_dispatcher_poll.cpp:169 #11 0x7fd075d79809 in libcamera::Thread::exec() (this=this@entry=0x56119d05f840) at ../src/libcamera/base/thread.cpp:341 #12 0x7fd075e52507 in libcamera::CameraManager::Private::run() (this=0x56119d05f830) at ../src/libcamera/camera_manager.cpp:122 #13 0x7fd075ad44a3 in std::execute_native_thread_routine(void*) (__p=0x56119cfa2aa0) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:82 #14 0x7fd079377fd4 in start_thread (arg=) at ./nptl/pthread_create.c:442 #15 0x7fd0793f78d0 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100 Core was generated by `/usr/bin/pipewire'. Program terminated with signal SIGSEGV, Segmentation fault. #0 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_S_left (__x=) at /usr/include/c++/12/bits/stl_function.h:407 407 operator()(const _Tp& __x, const _Tp& __y) const [Current thread is 1 (Thread 0x7fe1d62986c0 (LWP 1507832))] (gdb) bt #0 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_S_left (__x=) at /usr/include/c++/12/bits/stl_function.h:407 #1 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_M_lower_bound (__k=@0x7fe1d6297008: 20738, __y=0x7fe1cc010f30, __x=0x10001, this=0x7fe1cc010f28) at /usr/include/c++/12/bits/stl_tree.h:1952 #2 std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::lower_bound (__k=@0x7fe1d6297008: 20738, this=0x7fe1cc010f28) at /usr/include/c++/12/bits/stl_tree.h:1270 #3 std::map >, std::less, std::allocator > > > >::lower_bound (__x=@0x7fe1d6297008: 20738, this=0x7fe1cc010f28) at /usr/include/c++/12/bits/stl_map.h:1307 #4 std::map >, std::less, std::allocator > > > >::operator[] (__k=@0x7fe1d6297008: 20738, this=0x7fe1cc010f28) at /usr/include/c++/12/bits/stl_map.h:507 #5 libcamera::DeviceEnumeratorUdev::addV4L2Device (this=0x7fe1cc012130, devnum=) at ../src/libcamera/device_enumerator_udev.cpp:306 #6 0x7fe1d9fa810f in libcamera::DeviceEnumeratorUdev::addUdevDevice (this=0x7fe1cc012130, dev=0x7fe1cc012790) at ../src/libcamera/device_enumerator_udev.cpp:113 #7
Bug#1030331: scribus: enable harfbuzz subset feature
Source: scribus Version: 6.0.0+dfsg-3 Severity: wishlist The scribus maintainer requested that harfbuzz make available the subset library. This has been done now in Unstable. See https://bugs.debian.org/988781 Therefore, please rebuild scribus to pick up the new library. There wasn't any change to harfbuzz-dev or a need to add a new -dev library for the subset feature. I suppose you could optionally raise the dependency on harfbuzz to >= 6.0.0+dfsg-2~ New build log excerpt --- Harfbuzz library Found OK -- Checking for module 'icu-uc' -- Found icu-uc, version 72.1 -- Checking for module 'harfbuzz-subset>=2.4.0' -- Found harfbuzz-subset, version 6.0.0 Harfbuzz subset library Found OK Thank you, Jeremy Bicha
Bug#1030325: lintian: archive-liberty-mismatch (in section for firmware-nvidia-gsp) non-free-firmware vs non-free
On 03/02/2023 00.21, Cyril Brulebois wrote:
E: nvidia-graphics-drivers source: archive-liberty-mismatch (in section for
firmware-nvidia-gsp) non-free-firmware vs non-free [debian/control:106]
for my $inferior_liberty ('non-free', 'contrib') {
into this:
for my $inferior_liberty ('non-free-firmware', 'non-free', 'contrib') {
That doesn't work for me (but may be needed for other cases).
The attached patch does make the error go away by adding an exception
for 'non-free-firmware build from non-free' similar to 'contrib built
from main'
Andreas--- /usr/share/lintian/lib/Lintian/Check/Archive/Liberty/Mismatch.pm.orig 2023-02-03 00:30:29.782861611 +0100
+++ /usr/share/lintian/lib/Lintian/Check/Archive/Liberty/Mismatch.pm 2023-02-03 01:02:12.441805855 +0100
@@ -87,6 +87,9 @@
# special exception for contrib built from main
next
if $source_liberty eq 'main' && $installable_liberty eq 'contrib';
+# and non-free-firmware built from non-free
+next
+ if $source_liberty eq 'non-free' && $installable_liberty eq 'non-free-firmware';
my $control_item= $self->processable->debian_control->item;
my $position = $installable_fields->position('Section');
Bug#1030330: apt: update only warns if section doesn't exist
Package: apt Version: 2.5.5 Severity: normal X-Debbugs-Cc: Debian Security Team Hey. It seems that apt only gives a warning (and exit status 0) in case a section has been specified in sources.list, which doesn't exist. E.g. aptitde doesn't seem to even show that warning. Isn't that kind of a "security issue"? Imagine someone simply mistypes his deb http://security.debian.org/debian-security/ stable-security mian line and thus wouldn't see any updates. If updating the package lists (and perhps even upgrading) is handled automatically, this may be easily unnoticed. Cheers, Chris. -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (no /etc/apt/preferences.d/* present) -- -- (/etc/apt/sources.list present, but not submitted) -- -- (/etc/apt/sources.list.d/10_local_unstable.sources present, but not submitted) -- -- (/etc/apt/sources.list.d/50_debian_unstable.sources present, but not submitted) -- -- (no /etc/apt/sources.list.d/disabled present) -- -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt depends on: ii adduser 3.130 ii base-passwd 3.6.1 ii debian-archive-keyring 2021.1.1 ii gpgv2.2.40-1 ii libapt-pkg6.0 2.5.5 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libgnutls30 3.7.8-4 ii libseccomp2 2.5.4-1+b3 ii libstdc++6 12.2.0-14 ii libsystemd0 252.5-2 Versions of packages apt recommends: ii ca-certificates 20211016 Versions of packages apt suggests: ii apt-doc 2.5.5 ii aptitude0.8.13-5 ii dpkg-dev1.21.19 ii gnupg 2.2.40-1 ii powermgmt-base 1.37 -- Configuration Files: /etc/logrotate.d/apt changed [not included] -- no debconf information
Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
On 2023-02-02, Vagrant Cascadian wrote: > On 2023-02-01, Jérôme Charaoui wrote: >> Perhaps an alternative would be to add "puppet-agent" as a build >> dependency, because that package will create a "puppet" user in the >> environment. And for completeness, this also worked for me: sbuild --add-depends puppet-agent ... live well, vagrant signature.asc Description: PGP signature
Bug#1030329: osspd-pulseaudio depends on pulseaudio, it should depend on pulseaudio OR pipewire-pulse
Package: osspd-pulseaudio Version: 1.3.2-13+b2 Severity: normal X-Debbugs-Cc: gpe...@gmail.com Dear Maintainer, osspd-pulseaudio currently has a hard dependency on pulseaudio, and this causes conflicts when trying to migrate to pipewire (in my machine, it conflicts with pipewire-alsa). Ideally osspd-pulseaudio should depend on pulseaudio OR pipewire-pulse, so the user could have a pipewire system with compatibility with all of pulseaudio, jack, alsa and oss. I have tested osspd-pulseaudio in my machine, which has pipewire-pulse installed but pulseaudio uninstalled and sox file.mp3 -t oss works. Testing with osspd-alsa instead of osspd-pulseaudio fails, so that it is not an alternative. -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-1-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages osspd-pulseaudio depends on: ii libc6 2.36-8 ii libpulse0 16.1+dfsg1-2+b1 pn pulseaudio Versions of packages osspd-pulseaudio recommends: ii osspd 1.3.2-13+b2 osspd-pulseaudio suggests no packages. -- no debconf information
Bug#1030325: lintian: archive-liberty-mismatch (in section for firmware-nvidia-gsp) non-free-firmware vs non-free
Andreas Beckmann (2023-02-02):
> while preparing the move of firmware-nvidia-gsp from non-free to
> non-free-firmware I noticed this error from lintian:
>
> E: nvidia-graphics-drivers source: archive-liberty-mismatch (in section for
> firmware-nvidia-gsp) non-free-firmware vs non-free [debian/control:106]
Without a deep understanding of concepts or implementation, maybe a
quick fix would be to consider non-free-firmware of lower liberty than
non-free (even if they really should be considered the same), changing
this:
# in ascending order of liberty
for my $inferior_liberty ('non-free', 'contrib') {
into this:
# in ascending order of liberty
for my $inferior_liberty ('non-free-firmware', 'non-free', 'contrib') {
The critical bit being:
# must remain inferior
last
if $inferior_liberty eq $source_liberty;
(lib/Lintian/Check/Archive/Liberty/Mismatch.pm)
I'm short on time so I can't test this right away, but maybe Andreas
could give it a shot (e.g. hotpatching live lintian files)?
Cheers,
--
Cyril Brulebois (k...@debian.org)
Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
On 2023-02-01, Jérôme Charaoui wrote: > I don't know how common that is in build environments, but it's not > something that I have or think I should have in my build (sbuild) or > test (autopkgtest) environments. I was able to reproduce the issue with sbuild. This appears to be because sbuild copies the host's /etc/passwd and /etc/group into the chroot when it builds... and presumably the buildd environment does this as well (and all DSA machines have the puppet user available?)... and so the puppet user is in fact available in those cases, but not others... I was able to workaround the issue with: sbuild --chroot-setup-commands='adduser --gecos ,,, --disabled-password puppet' ... Is there an option in sbuild to not copy the passwd/group information into the chroot? What are the implications of that? > Is there some flag we could use to tell reproducible-builds to build > this package as a regular user instead of root? It typically builds as two different users, pbuilder1 and pbuilder2, not as root. > If not I might have to patch the test suite to work around some of the > logic in there, which I'm not too excited about. > > Perhaps an alternative would be to add "puppet-agent" as a build > dependency, because that package will create a "puppet" user in the > environment. That seems like a viable option, though obviously a bit ugly if that package does a bunch of other things or has many other dependencies. Would it make sense to have a package that just creates a user and nothing else? live well, vagrant signature.asc Description: PGP signature
Bug#1030248: [PATCH] kexec: make -a the default
AFAICT, there's no downside to this, and running into this each time I want to kexec (and, presumably, a significant chunk of the population, since lockdown is quite popular) on some machines, then going to the manual, then finding out I want the /auto/ flag(!) is quite annoying: # kexec -l /boot/vmlinuz-6.1.0-3-amd64 --initrd /boot/initrd.img-6.1.0-3-amd64 --reuse-cmdline kexec_load failed: Operation not permitted entry = 0x46eff7760 flags = 0x3e nr_segments = 7 segment[0].buf = 0x557cd303efa0 segment[0].bufsz = 0x70 segment[0].mem = 0x10 segment[0].memsz = 0x1000 segment[1].buf = 0x557cd3046fe0 segment[1].bufsz = 0x190 segment[1].mem = 0x101000 segment[1].memsz = 0x1000 segment[2].buf = 0x557cd303f6e0 segment[2].bufsz = 0x30 segment[2].mem = 0x102000 segment[2].memsz = 0x1000 segment[3].buf = 0x7f658fa37010 segment[3].bufsz = 0x12a51b5 segment[3].mem = 0x46a55a000 segment[3].memsz = 0x12a6000 segment[4].buf = 0x7f6590ce1210 segment[4].bufsz = 0x7e99e0 segment[4].mem = 0x46b80 segment[4].memsz = 0x377c000 segment[5].buf = 0x557cd3039350 segment[5].bufsz = 0x42fa segment[5].mem = 0x46eff2000 segment[5].memsz = 0x5000 segment[6].buf = 0x557cd3032000 segment[6].bufsz = 0x70e0 segment[6].mem = 0x46eff7000 segment[6].memsz = 0x9000 Closes: https://bugs.debian.org/1030248 Signed-off-by: Ahelenia Ziemiańska --- kexec/kexec.8 | 4 ++-- kexec/kexec.c | 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/kexec/kexec.8 b/kexec/kexec.8 index 3ebede6..66453b8 100644 --- a/kexec/kexec.8 +++ b/kexec/kexec.8 @@ -151,14 +151,14 @@ Specify that the new kernel is of this Specify that the new KEXEC_FILE_LOAD syscall should be used exclusively. .TP .BI \-c\ (\-\-kexec-syscall) -Specify that the old KEXEC_LOAD syscall should be used exclusively (the default). +Specify that the old KEXEC_LOAD syscall should be used exclusively. .TP .BI \-a\ (\-\-kexec-syscall-auto) Try the new KEXEC_FILE_LOAD syscall first and when it is not supported or the kernel does not understand the supplied image fall back to the old KEXEC_LOAD interface. -There is no one single interface that always works. +There is no one single interface that always works, so this is the default. KEXEC_FILE_LOAD is required on systems that use locked-down secure boot to verify the kernel signature. KEXEC_LOAD may be also disabled in the kernel diff --git a/kexec/kexec.c b/kexec/kexec.c index 0e92d96..36bb2ad 100644 --- a/kexec/kexec.c +++ b/kexec/kexec.c @@ -1049,11 +1049,11 @@ void usage(void) " to original kernel.\n" " -s, --kexec-file-syscall Use file based syscall for kexec operation\n" " -c, --kexec-syscall Use the kexec_load syscall for for compatibility\n" - " with systems that don't support -s (default)\n" + " with systems that don't support -s\n" " -a, --kexec-syscall-auto Use file based syscall for kexec and fall\n" " back to the compatibility syscall when file based\n" " syscall is not supported or the kernel did not\n" - " understand the image\n" + " understand the image (default)\n" " -d, --debug Enable debugging to help spot a failure.\n" " -S, --status Return 1 if the type (by default crash) is loaded,\n" " 0 if not.\n" @@ -1407,8 +1407,8 @@ int main(int argc, char *argv[]) int do_ifdown = 0, skip_ifdown = 0; int do_unload = 0; int do_reuse_initrd = 0; - int do_kexec_file_syscall = 0; - int do_kexec_fallback = 0; + int do_kexec_file_syscall = 1; + int do_kexec_fallback = 1; int skip_checks = 0; int do_status = 0; void *entry = 0; -- 2.30.2 signature.asc Description: PGP signature
Bug#983719: please upgrade to 4.4
This is the version in Bullseye (and Bookworm and Sid): $ esptool version esptool.py v2.8 2.8 It does not correctly identify e.g. the ESP32-PICO-V3-02, as found on the Adafruit ESP32 Feather V2, and it can not write the flash: $ esptool --port /dev/ttyACM2 chip_id esptool.py v2.8 Serial port /dev/ttyACM2 Connecting Detecting chip type... ESP32 Chip is unknown ESP32 (revision 3) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: e8:9f:6d:20:37:44 Enabling default SPI flash mode... Warning: ESP32 has no Chip ID. Reading MAC instead. MAC: e8:9f:6d:20:37:44 Hard resetting via RTS pin... The latest version (installed with pip) is 4.4: $ ~/.local/bin/esptool.py version esptool.py v4.4 4.4 It works fine with this newer module, and it can write the flash: $ ~/.local/bin/esptool.py --port /dev/ttyACM2 chip_id esptool.py v4.4 Serial port /dev/ttyACM2 Connecting Detecting chip type... Unsupported detection protocol, switching and trying again... Connecting Detecting chip type... ESP32 Chip is ESP32-PICO-V3-02 (revision v3.0) Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, Embedded PSRAM, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: e8:9f:6d:20:37:44 Uploading stub... Running stub... Stub running... Warning: ESP32 has no Chip ID. Reading MAC instead. MAC: e8:9f:6d:20:37:44 Hard resetting via RTS pin... An updated package would be appreciated. Thanks! -- Sebastian Kuzminsky
Bug#1030328: quelcom: FTBFS with TeXInfo 7.0.x
Source: quelcom Version: 0.4.0-16 Severity: important Tags: ftbfs patch Usertags: texinfo70 Dear Maintainer, the package fails to build from source when using TeX Info 7.0.x. This happens due to this change: , | 7.0 (7 November 2022) | * texi2any | . HTML output: | . use manual_name_html as output directory for split HTML instead of |manual_name or manual_name.html ` Patch is attached. Should be compatible to TeXinfo 6.8 too. For now TeXInfo 7.0 is available in experimental. This bug is not RC for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and the bug will become RC. Hilmar -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- sigmentation fault --- quelcom-0.4.0.orig/doc/makefile +++ quelcom-0.4.0/doc/makefile @@ -2,7 +2,7 @@ all: quelcom.html quelcom.info quelcom.txt quelcom.html: quelcom.texinfo - makeinfo --force --html quelcom.texinfo + makeinfo --force --html -o quelcom quelcom.texinfo quelcom.info: quelcom.texinfo makeinfo --force quelcom.texinfo signature.asc Description: PGP signature
Bug#1030248: kexec-tools: please make kexec -a the default
For a code change that changes the default behavior, I would like to see the change go into upstream project first. Please submit this proposed code change to upstream kexec project on the mailing list ke...@lists.infradead.org Thanks, Khalid On 2/1/23 08:16, наб wrote: Package: kexec-tools Version: 1:2.0.25-3+b1 Severity: normal Tags: patch Dear Maintainer, AFAICT, there's no downside to this, and running into this each time I want to kexec (and, presumably, a significant chunk of the population, since lockdown is quite popular), then going to the manual, then finding out I want the /auto/ flag(!!!) is quite annoying: -- >8 -- # kexec -l /boot/vmlinuz-6.1.0-3-amd64 --initrd /boot/initrd.img-6.1.0-3-amd64 --reuse-cmdline kexec_load failed: Operation not permitted entry = 0x46eff7760 flags = 0x3e nr_segments = 7 segment[0].buf = 0x557cd303efa0 segment[0].bufsz = 0x70 segment[0].mem = 0x10 segment[0].memsz = 0x1000 segment[1].buf = 0x557cd3046fe0 segment[1].bufsz = 0x190 segment[1].mem = 0x101000 segment[1].memsz = 0x1000 segment[2].buf = 0x557cd303f6e0 segment[2].bufsz = 0x30 segment[2].mem = 0x102000 segment[2].memsz = 0x1000 segment[3].buf = 0x7f658fa37010 segment[3].bufsz = 0x12a51b5 segment[3].mem = 0x46a55a000 segment[3].memsz = 0x12a6000 segment[4].buf = 0x7f6590ce1210 segment[4].bufsz = 0x7e99e0 segment[4].mem = 0x46b80 segment[4].memsz = 0x377c000 segment[5].buf = 0x557cd3039350 segment[5].bufsz = 0x42fa segment[5].mem = 0x46eff2000 segment[5].memsz = 0x5000 segment[6].buf = 0x557cd3032000 segment[6].bufsz = 0x70e0 segment[6].mem = 0x46eff7000 segment[6].memsz = 0x9000 -- >8 -- I'm attaching a patch I've validated works as expected. Best, наб -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 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 kexec-tools depends on: ii debconf [debconf-2.0] 1.5.82 ii dpkg 1.21.19 ii libc6 2.36-8 ii libxenmisc4.17 4.17.0-1+b1 ii lsb-base 11.5 ii sysvinit-utils [lsb-base] 3.06-2 kexec-tools recommends no packages. kexec-tools suggests no packages. -- debconf information excluded --- kexec-tools-2.0.25.orig/kexec/kexec.c +++ kexec-tools-2.0.25/kexec/kexec.c @@ -1049,11 +1049,11 @@ void usage(void) " to original kernel.\n" " -s, --kexec-file-syscall Use file based syscall for kexec operation\n" " -c, --kexec-syscall Use the kexec_load syscall for for compatibility\n" - " with systems that don't support -s (default)\n" + " with systems that don't support -s\n" " -a, --kexec-syscall-auto Use file based syscall for kexec and fall\n" " back to the compatibility syscall when file based\n" " syscall is not supported or the kernel did not\n" - " understand the image\n" + " understand the image (default)\n" " -d, --debug Enable debugging to help spot a failure.\n" " -S, --status Return 1 if the type (by default crash) is loaded,\n" " 0 if not.\n" @@ -1407,8 +1407,8 @@ int main(int argc, char *argv[]) int do_ifdown = 0, skip_ifdown = 0; int do_unload = 0; int do_reuse_initrd = 0; - int do_kexec_file_syscall = 0; - int do_kexec_fallback = 0; + int do_kexec_file_syscall = 1; + int do_kexec_fallback = 1; int skip_checks = 0; int do_status = 0; void *entry = 0; --- kexec-tools-2.0.25.orig/kexec/kexec.8 +++ kexec-tools-2.0.25/kexec/kexec.8 @@ -151,14 +151,14 @@ Specify that the new kernel is of this Specify that the new KEXEC_FILE_LOAD syscall should be used exclusively. .TP .BI \-c\ (\-\-kexec-syscall) -Specify that the old KEXEC_LOAD syscall should be used exclusively (the default). +Specify that the old KEXEC_LOAD syscall should be used exclusively. .TP .BI \-a\ (\-\-kexec-syscall-auto) Try the new KEXEC_FILE_LOAD syscall first and when it is not supported or the kernel does not understand the supplied image fall back to the old KEXEC_LOAD interface. -There is no one single interface that always works. +There is no one single interface that always works, so this is the default. KEXEC_FILE_LOAD is required on systems that use locked-down secure boot
Bug#1030323: /etc/default/puppet refers to non-existent /etc/init.d/puppet-agent
Le 2023-02-02 à 16 h 20, Antoine Beaupre a écrit : Package: puppet-agent Version: 7.22.0-3 Severity: normal [...] It should also be noted (perhaps in the NEWS.Debian?) that the previous START=no variable will probably not work to disable the agent daemon... Considering `exit 0` in there, not sure. Considering that 1) by default sysvinit systems have been migrated to systemd three releases ago, 2) the systemd unit file takes precendence over the initscript, and 3) that this systemd unit file is installed disabled-by-default, I don't think any further work or even a NEWS item is warranted here. -- Jérôme
Bug#1030327: science-numericalcomputation: please stop recommending python3-theano as it is being removed
Package: science-numericalcomputation Severity: minor theano is abandoned upstream and is broken by numpy 1.24 (#1027215). It is hence being removed from testing/next-stable, and probably from unstable as well. Hence, please stop listing it in this metapackage.
Bug#1030323: /etc/default/puppet refers to non-existent /etc/init.d/puppet-agent
Le 2023-02-02 à 16 h 20, Antoine Beaupre a écrit : Package: puppet-agent Version: 7.22.0-3 Severity: normal Today's upgrade suggested this patch to the configuration file: Configuration file '/etc/default/puppet' ==> File on system created by you or by a script. ==> File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** puppet (Y/I/N/O/D/Z) [default=N] ? d --- /etc/default/puppet 2022-09-29 12:50:59.011237328 -0400 +++ /etc/default/puppet.dpkg-new2023-01-29 10:45:20.0 -0500 @@ -1 +1,4 @@ -START=no +# Defaults for puppet - sourced by /etc/init.d/puppet + +# Startup options +DAEMON_OPTS="" Yet that file doesn't exist: cat: /etc/init.d/puppet: No such file or directory The init file is actually /etc/init.d/puppet-agent now, so the default file needs to be corrected. Actually, this is most likely a manifestation of #1030212: the confffile /etc/init.d/puppet-agent should have been renamed to /etc/init.d/puppet but it didn't happen because I messed up as described in the bug report. The service name (both sysv and systemd) is indeed supposed to be "puppet" rather than "puppet-agent". The change was implemented in the interest of cross-platform compatibility. -- Jérôme
Bug#1030326: astro-python3: please stop recommending python3-theano as it is being removed
Package: astro-python3 Severity: minor theano is abandoned upstream and is broken by numpy 1.24 (#1027215). It is hence being removed from testing/next-stable, and probably from unstable as well. Hence, please stop listing it in this metapackage.
Bug#1030325: lintian: archive-liberty-mismatch (in section for firmware-nvidia-gsp) non-free-firmware vs non-free
Package: lintian Version: 2.116.2 Severity: important X-Debbugs-Cc: Cyril Brulebois Hi, while preparing the move of firmware-nvidia-gsp from non-free to non-free-firmware I noticed this error from lintian: E: nvidia-graphics-drivers source: archive-liberty-mismatch (in section for firmware-nvidia-gsp) non-free-firmware vs non-free [debian/control:106] Andreas
Bug#1029825: emacs: reduce libgccjit0 related dependencies to optional?
On 2023-01-30 at 20:00 -0600, Rob Browning wrote: > That said, and as you mentioned, we could also consider other/additional > flavors of emacs, but of course those have their own costs. Please consider building emacs-nox (or emacs-tiny?) without native-compilation so that we can use emacs on a small storage. Thanks, -- Tatsuya Kinoshita pgpUYHtdrxMaK.pgp Description: PGP signature
Bug#1030324: ITP: lomiri-action-api -- Lomiri Action Qt API
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: lomiri-action-api Version : 1.1.2 Upstream Author : UBports Developers * URL : https://gitlab.com/ubports/development/core/lomiri-action-api * License : LGPL-3 Programming Lang: C++, QML Description : Lomiri Action Qt API Lomiri Common Action API. Allow applications to export actions in various forms to the Lomiri Shell. . This API is required by some Lomir based apps (such as browser, camera and media player). . This package will be maintained by the UBports Packaging Team.
Bug#961508: ifupdown: RTNETLINK answers: File exists
On 2023-01-31 21:02:11, ael wrote: > On Tue, Jan 31, 2023 at 02:10:46PM -0500, Antoine Beaupré wrote: >> I have a similar problem with ifupdown on my home server which has >> accumulated a rather unfortunate pile of crap... >> >> iface eth0 inet static >> # fix RTNETLINK errors on boot see https://bugs.debian.org/961508 >> pre-up ip addr flush dev eth0 || true >> address 192.168.0.3 >> netmask 255.255.255.0 >> gateway 192.168.0.1 > > I have not encountered this for a long time now. It looks as if ipdown > now flushes: > > # ifdown -v eth0 > ... > ip -4 addr flush dev eth0 > ... ah yes, that's ifdown, but on boot i suspect that doesn't run. -- The greatest crimes in the world are not committed by people breaking the rules but by people following the rules. It's people who follow orders that drop bombs and massacre villages. - Banksy
Bug#1030323: /etc/default/puppet refers to non-existent /etc/init.d/puppet-agent
Package: puppet-agent Version: 7.22.0-3 Severity: normal Today's upgrade suggested this patch to the configuration file: Configuration file '/etc/default/puppet' ==> File on system created by you or by a script. ==> File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** puppet (Y/I/N/O/D/Z) [default=N] ? d --- /etc/default/puppet 2022-09-29 12:50:59.011237328 -0400 +++ /etc/default/puppet.dpkg-new2023-01-29 10:45:20.0 -0500 @@ -1 +1,4 @@ -START=no +# Defaults for puppet - sourced by /etc/init.d/puppet + +# Startup options +DAEMON_OPTS="" Yet that file doesn't exist: cat: /etc/init.d/puppet: No such file or directory The init file is actually /etc/init.d/puppet-agent now, so the default file needs to be corrected. It should also be noted (perhaps in the NEWS.Debian?) that the previous START=no variable will probably not work to disable the agent daemon... Considering `exit 0` in there, not sure. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 puppet-agent depends on: ii adduser3.130 ii debconf [debconf-2.0] 1.5.82 ii facter 4.2.13-2 ii hiera 3.10.0-1 ii init-system-helpers1.65.2 ii ruby 1:3.1 ii ruby-augeas1:0.5.0+gem-1 ii ruby-concurrent1.1.6+dfsg-5 ii ruby-deep-merge1.1.1-2 ii ruby-semantic-puppet 1.0.4-1 ii ruby-shadow2.5.1-1 ii ruby-sorted-set1.0.3-3 Versions of packages puppet-agent recommends: ii augeas-tools 1.14.0-1 ii debconf-utils 1.5.82 ii lsb-release12.0-1 ii ruby-selinux 3.4-1+b5 Versions of packages puppet-agent suggests: pn hiera-eyaml pn puppet-module-puppetlabs-augeas-core pn puppet-module-puppetlabs-cron-core pn puppet-module-puppetlabs-host-core pn puppet-module-puppetlabs-mount-core pn puppet-module-puppetlabs-selinux-core pn puppet-module-puppetlabs-sshkeys-core pn puppet-module-puppetlabs-stdlib ii ruby-hocon 1.3.1-2 pn ruby-msgpack -- Configuration Files: /etc/puppet/puppet.conf changed [not included] -- debconf information: puppet-agent/postrm_purge_data: true
Bug#960305: matrix-synapse: No instructions on setting up TLS
Hello, On Sun, 1 Aug 2021 12:08:50 +0200 Nicolas George wrote: > I have a tidbit of information to add: > > The systemd service configuration says: > > ExecStartPre=/usr/bin/python3 -m synapse.app.homeserver > --config-path=/etc/matrix-synapse/homeserver.yaml > --config-path=/etc/matrix-synapse/conf.d/ --generate-keys > > The "--generate-keys" exists in the source code Python files. > > Yet if I run this command explicitly, it does nothing at all, and strace > shows it does nothing about the keys. yes, since synapse!4509 [1] the `--generate-keys` argument does not trigger the creation of TLS files anymore. (the new alias `--generate-missing-config` for that option is less misleading) Thus it would probably be a good idea for the matrix-synapse package to disable the TLS configuration by default and to use the new `--generate-missing-config` (instead of `--generate-keys`) to avoid any confusion. Disabled TLS is also the default configuration provided by `/usr/bin/synapse_generate_config`. Probably most users will use a separate reverse proxy. Thus, the enabled TLS setting could infact complicate deployment for many people. Thank you for maintaining the package! Cheers, Lars [1] https://github.com/matrix-org/synapse/pull/4509
Bug#1013935: dogtag-pki: flaky autopkgtest: regularly times out on amd64, armhf and s390x
Hi Adrian, On 02-02-2023 21:32, Adrian Bunk wrote: On Mon, Jun 27, 2022 at 08:31:53PM +0200, Paul Gevers wrote: I looked at the results of the autopkgtest of you package because it was showing up on our "slow" page [1]. I noticed that there were several runs that took 2:47 (our timeout time), while successful runs more in the order of minutes. ... Lookking at debci results with recent versions, this problem seems to be fixed now? It was a mistake that the block was lifted, but indeed, you might be right. There only seems to be an unrelated(?) error Installation failed: Server did not start after 60s on !amd64 that results in fast failures. But that is an RC issue on it's own, because dogtag-pki used to pass on all architectures and autopkgtest regression is listed on https://release.debian.org/testing/rc_policy.txt Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1030322: gnushogi: FTBFS with TeXInfo 7.0.x
Source: gnushogi Version: 1.4.2-7 Severity: important Tags: ftbfs Usertags: texinfo70 Dear Maintainer, the package fails to build from source when using TeX Info 7.0.x. This happens due to this change: , | 7.0 (7 November 2022) | * texi2any | . HTML output: | . use manual_name_html as output directory for split HTML instead of |manual_name or manual_name.html ` The easiest solution is probably to append option "--output=$(package)" to the "makeinfo --html" call...which would need to be done in upstreams Makefile. For now TeXInfo 7.0 is available in experimental. This bug is not RC for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and the bug will become RC. Hilmar -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- sigmentation fault signature.asc Description: PGP signature
Bug#1030177: pygame-sdl2: FTBFS: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '2.1.0-for-renpy-8.0.2'
Thanks for your help! Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#1030321: security-tracker: Add support to fetch information for non-free-firmware archive section
Package: security-tracker Severity: important X-Debbugs-Cc: car...@debian.org,k...@debian.org, Hi With the introduction of the non-free-firmware section the security-tracker need to able to fetch package information as well for non-free-firmware packages (e.g. firmware-nonfree). Currently the overview e.g. for https://security-tracker.debian.org/tracker/source-package/firmware-nonfree is not broken. At least - Makefile: Fetch packages for main contrib non-free and non-free-firmware - bin/grab-cve-in-fix: Only adjust comment AFAICS - bin/lts-missing-uploads: need to support component non-free-firmware if the upper suite has support for it. Regards, Salvatore
Bug#1030320: tango: New version 9.4.1 available
Package: tango Severity: normal We would really like to have 9.4.1 [0] in upcoming debian bookworm instead of the old 9.3.x. I've already tested if our tests pass on debian testing on amd64, yes they do [1]. The changes compared to 9.3.x are listed at [2]. Packaging wise the biggest change is that we now only support cmake. As you are using the TangoSourceDistribution we have some info posted at [3] wrt to the cmake options. Thanks, Thomas [0]: https://gitlab.com/tango-controls/cppTango/-/releases/9.4.1 [1]: https://gitlab.com/tango-controls/cppTango/-/merge_requests/1044 [2]: https://gitlab.com/tango-controls/cppTango/-/blob/main/RELEASE_NOTES.md [3]: https://gitlab.com/tango-controls/TangoSourceDistribution/-/tree/main/assets#installation
Bug#1030287: simple-cdd: What if reprepro_retries is reached?
On 2023-02-02, Arnaud Rebillout wrote: > Looking at tools/mirror/reprepro [1], I see that this script runs > 'reprepro update' in a loop, until reprepro_retries (default: 20) is > reached. > > However, it's a bit strange that, if ever reprepro_retries is reached, > the code doesn't error out with a message such as "There are still > dependencies missing after $i attempts!". Instead, the script silently > keeps going, and exits with zero, as if there was no problem. > > I'd suggest to either: > - error out when reprepro_retries is reached, as suggested above. > - if it's not considered an error, at least print a message to say that > reprepro_retries was reached, and clarify that it's not a problem. There were definitely cases of packages that had alternate dependencies that will never be satisfyable (e.g. from contrib or non-free when building only from main, or even ubuntu), so failing to resolve all dependencies is not technically an error. But sure, issuing a warning that reprepro_retries was reached and suggesting to bump the value if later steps fail due to missing dependencies seems reasonable... The mirroring here is definitely a best-effort shotgun approach, grabbing all the dependencies/recommends of any package you actually expressed interest in (by putting in a .packages or .downloads file in one of the profiles), and *trying* to pull in anything mentioned in any Depends or Recommends or Provides field, recursively... and comparing the previous run to the current run if anything changed. If it does not pull in enough, I think debian-cd still fails... maybe... I guess... hope? :) In some cases, adding more packages to one of the .downloads files is the appropriate workaround. > This is not a theoretical situation. I looked at the logs from the Kali > Linux daily builds, and for some builds it took 20 attempts, so it seems > likely that for some builds it would have taken more attempts. Sounds like the default should at least be bumped to a larger value, then. That has been the value since at least 2006, picked by finding the right value at the time for the biggest profile I ever tested and doubling it... there have been quite a few packages added to Debian since then, so it is no surprise that it would need to be updated! Feel free to propose a higher value grounded in a current real world use-case, and double it. :) An entirely different approach would be calling out to something that actually properly resolves dependencies... but the current approach, though crude, works for the most part, and keeps the dependencies quite minimal. > I can submit a patch if needed, Thanks for looking into it! Help is definitely appreciated! I have not really looked at simple-cdd much since the previous release, and simple-cdd surely needs some help now that we are into the early phases of a freeze cycle! live well, vagrant signature.asc Description: PGP signature
Bug#1030319: diffutils: FTBFS with TeXInfo 7.0.x
Package: diffutils Version: 1:3.8-3 Severity: important Tags: ftbfs Usertags: texinfo70 Dear Maintainer, the package fails to build from source when using TeX Info 7.0.x. This happens due to this change: , | 7.0 (7 November 2022) | * texi2any | . HTML output: | . use manual_name_html as output directory for split HTML instead of |manual_name or manual_name.html ` So the solution is rather easy, append the option "--output=$(package)" to the call of "makeinfo". For now TeXInfo 7.0 is available in experimental. This bug is not RC for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and the bug will become RC. Hilmar -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages diffutils depends on: ii libc6 2.36-8 diffutils recommends no packages. Versions of packages diffutils suggests: pn diffutils-doc ii wdiff 1.2.2-4 -- no debconf information -- sigmentation fault signature.asc Description: PGP signature
Bug#417870: fakechroot vs rpath affects mmdebstrap
Control: affects -1 + mmdebstrap Hi, Johannes asked me to briefly explain how this bug affects mmdebstrap. If you use mmdebstrap unprivileged on a Debian testing system without user namespaces (e.g. during an unprivileged autopkgtest) and try to bootstrap unstable, you may run into this issue, because systemd heavily employs RPATHs to load libsystemd-shared. When e.g. systemd-sysusers is invoked, it loads its libraries and - due to the RPATH - picks up the system copy of libsystemd-shared rather than the chroot copy. If these differ (e.g. because testing lags behind unstable), it may lack symbols and the program may fail to start. I think this makes mmdebstrap's --mode=fakechroot rather limited to situations where the bootstrapped release exactly matches the system release. Helmut
Bug#1013935: dogtag-pki: flaky autopkgtest: regularly times out on amd64, armhf and s390x
On Mon, Jun 27, 2022 at 08:31:53PM +0200, Paul Gevers wrote: > Source: dogtag-pki > Version: 11.0.0-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > I looked at the results of the autopkgtest of you package because it was > showing up on our "slow" page [1]. I noticed that there were several runs > that took 2:47 (our timeout time), while successful runs more in the order > of minutes. >... Lookking at debci results with recent versions, this problem seems to be fixed now? There only seems to be an unrelated(?) error Installation failed: Server did not start after 60s on !amd64 that results in fast failures. > Paul >... cu Adrian
Bug#953790: quassel-client: Typo in spanish translation
On 2 January 2023 20:21:04 CET Lisandro Damián Nicanor Pérez Meyer wrote: > Control: forwarded -1 https://github.com/quassel/quassel-i18n/pull/2 > > On 29 Dec 2022 at 21:37, Diederik de Haas wrote: > > On Fri, 13 Mar 2020 10:31:57 -0300 Lisandro Damián Nicanor Pérez Meyer > > > Could you try again at https://github.com/quassel/quassel-i18n/pulls ? > > They recently did merge an update to German translation there. > > Done, let's see how it goes. A 'bit' disappointing that it's still not merged after a month ... :-/ Upstream quassel doesn't look good in general given there were only 12 commits last year ... of which a substantial part relating to CI. signature.asc Description: This is a digitally signed message part.
Bug#951076: abi-compliance-checker: Invalid use of Perl "next"
Package: abi-compliance-checker
Version: 2.3-1
Followup-For: Bug #951076
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Control: tags -1 patch
Apologies for taking so long to address this - we've had the fix for it in
Ubuntu for a while but I've failed at upstreaming it to Debian.
The attached patch fixes this issue that my patch had introduced.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
--- abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
2021-12-08 22:49:16.0 -0800
+++ abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
2021-12-09 02:01:04.0 -0800
@@ -88,7 +88,7 @@
+sub exec_helper(@)
+{
+my ($reader, $writer) = @_;
-+do {
++while(1) {
+chomp($line = <$reader>);
+ next if (!$line);
+if ($line eq 'exit') {
@@ -96,7 +96,7 @@
+}
+system($line);
+print $writer "$? $!\n";
-+} while(1);
++}
+}
+
sub scenario()
Bug#1028041: php-excimer: FTBFS on mipsel
On Thu, Feb 02, 2023 at 02:23:21PM -0500, Kunal Mehta wrote: > severity 1028041 normal > thanks > > Hi, > > On 1/6/23 13:47, Adrian Bunk wrote: > > On Fri, Jan 06, 2023 at 08:59:08AM +0100, Paul Gevers wrote: > > > = > > > FAILED TEST SUMMARY > > > - > > > ExcimerProfiler CPU profile [tests/cpu.phpt] > > > = > > > > > > Please fix ASAP to not block the php8.2 transition. > > > > It built after I gave it back to build on the right buildd, > > so it's now rebuilt with PHP 8.2. > > Thanks. > > > The issue might depend on buildd speed, or some weird difference > > between buildds. > > Looking through my email, it's flaked before in the past (#1014801). The > test in question[1] has the following comment: > > // Test aggregateByFunction > // Typically the parent functions foo() and bar() will have self=0 and > // inclusive ~= 30. The other 4 functions will have a count of about 30/4 = > 7.5. > // The probability of C::member() or baz() having a count of zero is about 1 > in 5600. > > Maybe the known flakiness is worse due to something on the mipsel build? >... I am not convinced that this is flakiness, my guess (that could be wrong!) would be tests failing on all except the fastest mipsel buildds. It is problematic that the test doesn't output what exactly fails. On the porterbox the test passes initially, but it fails after -$profiler->setPeriod(0.1); +$profiler->setPeriod(10); I do not know whether or not this is the same failure as on the mipsel buildds. > -- Kunal cu Adrian
Bug#1030236: More info
The memory leakage only happens when stdin is redirected to /dev/zero. Please close te bug. -- Dieter Deyke mailto:dieter.de...@gmail.com Get my Gnupg key: gpg --keyserver keys.gnupg.net --recv-keys B116EA20
Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing
On Thu, Feb 2, 2023, at 14:45, Petter Reinholdtsen wrote: > [Scott Colby] > > I believe this is caused by the final command of the script being > > `zpool list ... | while read -r pool do ...; done`. When the output > > of `zpool list` is exhausted, `read` returns an error, and thus the > > script exits with that status. I have confirmed this by running the > > script with `sh -x` and seeing that the last output line is > > `+ read -r pool`. > > This sound strange. It is not according to my understanding of bourne > shell scripting, and this oneliner describe how I believe it work: > > % ((set -x; echo foo|while read a; do a=$a; done); echo $?) > + echo foo > + read a > + a=foo > + read a > 0 > % You are correct. I was continuing to investigate this and I think the actual case is that the previous call returns 1: + lsblk -dnr -o TRAN /dev/sda + [ sata = nvme ] # <-- this is false + return + read -r pool As can be demonstrated by: $ cat test.sh #!/usr/bin/env sh printf '1\n2\n3\n' | \ while read -r h do echo "aa$h" false done $ sh -x test.sh + + printf 1\n2\n3\n read -r h + echo aa1 aa1 + false + read -r h + echo aa2 aa2 + false + read -r h + echo aa3 aa3 + false + read -r h $ echo $? 1 I still think that this is a bug in the trim script though.
Bug#1030318: octave: FTBFS with TeXInfo 7.0.x
Source: octave Version: 7.3.0-1 Severity: important Tags: ftbfs Usertags: texinfo70 Dear Maintainer, the package octave runs into a endless loop when trying to build with TeXInfo 7.0.x. It happens, when ./doc/interpreter/mk-qthelp.pl is called: perl ./doc/interpreter/mk-qthelp.pl octave.html doc/interpreter/octave_interpreter && \ qcollectiongenerator -qt=5 doc/interpreter/octave_interpreter.qhcp -o doc/interpreter/octave_interpreter.qhc >/dev/null && \ rm -f doc/interpreter/octave_interpreter.qhcp doc/interpreter/octave_interpreter.qhp Use of uninitialized value $_ in pattern match (m//) at ./doc/interpreter/mk-qthelp.pl line 30, <$HTML> line 831. Use of uninitialized value $_ in pattern match (m//) at ./doc/interpreter/mk-qthelp.pl line 30, <$HTML> line 831. As far as I understand the script ./doc/interpreter/mk-qthelp.pl tries to find some strings in the HTML file generated by "makeinfo --html". These were generated by TeXInfo 6.8, but the structure of TeXInfo 7.0 is different. For testing TeXInfo 7.0 is available in experimental. This bug is not RC for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and the bug will become RC. Hilmar -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- sigmentation fault signature.asc Description: PGP signature
Bug#1028041: php-excimer: FTBFS on mipsel
Hi Kunal, On 02-02-2023 20:23, Kunal Mehta wrote: I'm lowering the severity because it no longer blocks the 8.2 transition (please revert me if I'm wrong on that). In my opinion flaky builds and flaky tests are bad because they cost quite some time of people that are not involved in the package. E.g. in this case Release Team, but imagine a security upload where the build fails. But you have flaky and flaky. https://bugs.debian.org/844264 is an interesting read in that regard. As somebody that maintains infrastructure and does a lot of QA (ci.debian.net) and is involved in transitions and migrations where I see a lot of flaky tests, I'm biased. But really, a test that fails more often than say 1/5 times is RC in my book. I didn't check the ratio of php-excimer failures. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1030316: [Pkg-zfsonlinux-devel] Bug#1030316: trim script always exits 1 despite not failing
[Scott Colby] > I believe this is caused by the final command of the script being > `zpool list ... | while read -r pool do ...; done`. When the output > of `zpool list` is exhausted, `read` returns an error, and thus the > script exits with that status. I have confirmed this by running the > script with `sh -x` and seeing that the last output line is > `+ read -r pool`. This sound strange. It is not according to my understanding of bourne shell scripting, and this oneliner describe how I believe it work: % ((set -x; echo foo|while read a; do a=$a; done); echo $?) + echo foo + read a + a=foo + read a 0 % -- Happy hacking Petter Reinholdtsen
Bug#1030317: youtube-dl replacement by yt-dlp prevents git-annex frm using it
Package: git-annex Version: 10.20221003-3 Severity: normal Now when youtube-dl is installed, there is no youtube-dl in path, so git-annex cannot use it. Newer versions of git-annex have been changed to support yt-dlp. This could be fixed by upgrading it, or cherry picking these commits: 5256be61c12fb030fe2eebe2751ee1601a5e7514 43f681d4c15221096975250c0809ded40bf8a5fd -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 git-annex depends on: ii curl7.87.0-1 ii git 1:2.39.1-0.1 ii libc6 2.36-8 ii libffi8 3.4.4-1 ii libgmp102:6.2.1+dfsg1-1.1 ii libmagic1 1:5.44-1 ii libsqlite3-03.40.1-1 ii libyaml-0-2 0.2.5-1 ii netbase 6.4 ii openssh-client 1:9.1p1-2 ii rsync 3.2.7-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages git-annex recommends: ii aria2 1.36.0-1 ii bind9-host 1:9.18.10-2 ii git-remote-gcrypt 1.5-1 ii gnupg 2.2.40-1 ii lsof 4.95.0-1 ii nocache1.1-1+b1 Versions of packages git-annex suggests: ii adb 1:29.0.6-22 ii bup 0.33-2 ii libnss-mdns 0.15.1-3 ii magic-wormhole 0.12.0-1 pn tahoe-lafs ii tor 0.4.7.13-1 ii uftp4.10.2-1.1+b2 pn xdot ii yt-dlp 2023.01.06-1 -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
-=| Jose M Calhariz, 02.02.2023 19:20:23 + |=- > This is my first security update, can I ask what is the procedure or > where is documented? https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security-building https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security -- Damyan > On January 28, 2023 12:59:09 PM GMT+00:00, Salvatore Bonaccorso > wrote: > > Source: amanda > Version: 1:3.5.1-9 > Severity: grave > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerabilities were published for amanda. > > CVE-2022-37704[0], CVE-2022-37705[1]. > > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2022-37704 > https://www.cve.org/CVERecord?id=CVE-2022-37704 > [1] https://security-tracker.debian.org/tracker/CVE-2022-37705 > https://www.cve.org/CVERecord?id=CVE-2022-37705 > [2] https://github.com/zmanda/amanda/issues/192 > > Please adjust the affected versions in the BTS as needed. > > Regards, > Salvatore >
Bug#1029992: xtl: new upstream version 0.7.5 available
On 2023-01-30 00:31, Drew Parsons wrote: Source: xtl Version: 0.7.2-2.1 Severity: normal xtl 0.7.5 has just been released. The latest version of xtensor needs it (uses xtl/xcompare.hpp), and we need the latest version of xtensor in order to support the latest version of xsimd. The latest release of xsimd fixes some issues which makes pythran more stable and more effective. scipy uses pythran to accelerate computations. tl;dr: Would it be possible to upload the new version of xtl to experimental so we can test it alongside xsimd 10.0.0 ? Hello Drew, Done.
Bug#1028041: php-excimer: FTBFS on mipsel
severity 1028041 normal thanks Hi, On 1/6/23 13:47, Adrian Bunk wrote: On Fri, Jan 06, 2023 at 08:59:08AM +0100, Paul Gevers wrote: = FAILED TEST SUMMARY - ExcimerProfiler CPU profile [tests/cpu.phpt] = Please fix ASAP to not block the php8.2 transition. It built after I gave it back to build on the right buildd, so it's now rebuilt with PHP 8.2. Thanks. The issue might depend on buildd speed, or some weird difference between buildds. Looking through my email, it's flaked before in the past (#1014801). The test in question[1] has the following comment: // Test aggregateByFunction // Typically the parent functions foo() and bar() will have self=0 and // inclusive ~= 30. The other 4 functions will have a count of about 30/4 = 7.5. // The probability of C::member() or baz() having a count of zero is about 1 in 5600. Maybe the known flakiness is worse due to something on the mipsel build? I'll ask the upstream author. Worst case we can just skip the test on mipsel. I'm lowering the severity because it no longer blocks the 8.2 transition (please revert me if I'm wrong on that). [1] https://salsa.debian.org/mediawiki-team/php-excimer/-/blob/master/tests/cpu.phpt -- Kunal
Bug#1030316: trim script always exits 1 despite not failing
Package: zfsutils-linux Version: 2.1.7-1~bpo11+1 When I invoke `sh /usr/lib/zfs-linux/trim`, the script always exits 1 despite operating properly. This is causing me some pain when trying to automate calling this script with a systemd timer, since I can't differentiate some other reason of the script exiting 1 from a successful run. I believe this is caused by the final command of the script being `zpool list ... | while read -r pool do ...; done`. When the output of `zpool list` is exhausted, `read` returns an error, and thus the script exits with that status. I have confirmed this by running the script with `sh -x` and seeing that the last output line is `+ read -r pool`. I'm not sure what the right solution to this would be, but I think that it should be addressed. Thank you, Scott Colby
Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
Hi, This is my first security update, can I ask what is the procedure or where is documented? Kind regards Jose M Calhariz On January 28, 2023 12:59:09 PM GMT+00:00, Salvatore Bonaccorso wrote: >Source: amanda >Version: 1:3.5.1-9 >Severity: grave >Tags: security upstream >Justification: user security hole >X-Debbugs-Cc: car...@debian.org, Debian Security Team > > >Hi, > >The following vulnerabilities were published for amanda. > >CVE-2022-37704[0], CVE-2022-37705[1]. > >If you fix the vulnerabilities please also make sure to include the >CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > >For further information see: > >[0] https://security-tracker.debian.org/tracker/CVE-2022-37704 >https://www.cve.org/CVERecord?id=CVE-2022-37704 >[1] https://security-tracker.debian.org/tracker/CVE-2022-37705 >https://www.cve.org/CVERecord?id=CVE-2022-37705 >[2] https://github.com/zmanda/amanda/issues/192 > >Please adjust the affected versions in the BTS as needed. > >Regards, >Salvatore
Bug#1030170: dh-virtualenv: diff for NMU version 1.2.2-1.3
Control: tags 1030170 + pending Dear maintainer, I've prepared an NMU for dh-virtualenv (versioned as 1.2.2-1.3) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. diff -Nru dh-virtualenv-1.2.2/debian/changelog dh-virtualenv-1.2.2/debian/changelog --- dh-virtualenv-1.2.2/debian/changelog 2022-08-25 15:01:52.0 -0400 +++ dh-virtualenv-1.2.2/debian/changelog 2023-02-02 14:10:21.0 -0500 @@ -1,3 +1,10 @@ +dh-virtualenv (1.2.2-1.3) unstable; urgency=medium + + * Non-maintainer upload. + * Cherry-pick upstream patch for Python 3.11 support (Closes: #1030170) + + -- Kunal Mehta Thu, 02 Feb 2023 14:10:21 -0500 + dh-virtualenv (1.2.2-1.2) unstable; urgency=medium * Non-maintainer upload. diff -Nru dh-virtualenv-1.2.2/debian/patches/0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch dh-virtualenv-1.2.2/debian/patches/0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch --- dh-virtualenv-1.2.2/debian/patches/0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch 1969-12-31 19:00:00.0 -0500 +++ dh-virtualenv-1.2.2/debian/patches/0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch 2023-02-02 13:58:02.0 -0500 @@ -0,0 +1,24 @@ +From: Andrew Morgan +Date: Tue, 3 Jan 2023 14:29:53 + +Subject: Replace usage of inspect.getargspec with inspect.getfullargspec + +It's debatable whether this check is even still needed, but for now +let's do the simple thing and update it to be compatible with modern +Python versions. +--- + bin/dh_virtualenv | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/bin/dh_virtualenv b/bin/dh_virtualenv +index 8bafbcf..0a422ad 100755 +--- a/bin/dh_virtualenv b/bin/dh_virtualenv +@@ -57,7 +57,7 @@ def main(): + # passed the packages keyword argument. Newer (like Ubuntu + # Precise) expect the whole options to be passed. + +-arguments = inspect.getargspec(DebHelper.__init__).args ++arguments = inspect.getfullargspec(DebHelper.__init__).args + if 'packages' in arguments: + dh = DebHelper(packages=options.package or None) + else: diff -Nru dh-virtualenv-1.2.2/debian/patches/series dh-virtualenv-1.2.2/debian/patches/series --- dh-virtualenv-1.2.2/debian/patches/series 1969-12-31 19:00:00.0 -0500 +++ dh-virtualenv-1.2.2/debian/patches/series 2023-02-02 13:58:02.0 -0500 @@ -0,0 +1 @@ +0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch
Bug#1029834: dpkg: cycle found while processing triggers
Hi! On Thu, 2023-02-02 at 15:52:09 +0100, Jörg-Volker Peetz wrote: > Guillem Jover wrote on 01/02/2023 23:20: > > Was there any other error during the unpack or installation in > > general? Do you have the full log of that upgrade session? From what > > version were you upgrading from? > > There was no other error during the whole upgrade but I don't have the full > log > anymore. In spite of the error message the upgrade was successful. After each > upgrade I check the installation with the commands: > > # apt-get check ; dpkg -C ; aptitude search '~b' '~g' '~c' > > The version of openjdk-17 was 17.0.5+8-2 before this upgrade. > And I have to correct the version of ca-certificates-java which was 20230103. Ok, thanks for the info! > > Do you perhaps have a backup of the status files from just before that > > upgrade session? (Either the /var/lib/dpkg/status-old if you have not > > done anything else package-wise since then, or perhaps under > > /var/backups.) > Yes I have the status file. Compressed it is ca. 400 kB. I don't know if it's > o.k. to attach it. Ah, that might be enough to try try reproduce it. Given the size and any potential privacy concerns, feel free to send it to me directly, and I'll try to reproduce locally, and send any findings here afterwards. > > Otherwise this unfortunately seems a bit non-actionable to me. :/ > > Yes, I know :-( > On a second, similar computer I didn't see the error message. Let's see, there might still be hope. :) Thanks, Guillem
Bug#1030315: qt6-base: FTBFS on hppa - shared object linked with non PIC archive library
Source: qt6-base Version: 6.4.2+dfsg~rc1-3 Severity: normal Dear Maintainer, Linking libQt6Core.so.6.4.2 fails because the link command links against libzstd.a instead of libzstd.so. There are also numerous warnings. [447/1614] : && /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -flto=auto -ffat-lto-objects -Wl,--version-script,/<>/obj-hppa-linux-gnu/src/corelib/Core.version -Wl,--no-undefined -Wl,-e,qt_core_boilerplate -Wl,--enable-new-dtags -shared -Wl,-soname,libQt6Core.so.6 -o lib/hppa-linux-gnu/libQt6Core.so.6.4.2 src/corelib/CMakeFiles/Core.dir/Core_autogen/mocs_compilation.cpp.o src/corelib/CMakeFiles/Core.dir/global/qsimd.cpp.o src/corelib/CMakeFiles/Core.dir/tools/qhash.cpp.o src/corelib/CMakeFiles/Core.dir/compat/removed_api.cpp.o src/corelib/CMakeFiles/Core.dir/global/archdetect.cpp.o src/corelib/CMakeFiles/Core.dir/global/qendian.cpp.o src/corelib/CMakeFiles/Core.dir/global/qfloat16.cpp.o src/corelib/CMakeFiles/Core.dir/global/qglobal.cpp.o src/corelib/CMakeFiles/Core.dir/global/qhooks.cpp.o src/corelib/CMakeFiles/Core.dir/global/qlibraryinfo.cpp.o src/corelib/CMakeFiles/Core.dir/global/qlogging.cpp.o src/corelib/CMakeFiles/Core.dir/global/qmalloc.cpp.o src/corelib/CMakeFiles/Core.dir/global/qnumeric.cpp.o src/corelib/CMakeFiles/Core.dir/global/qoperatingsystemversion.cpp.o src/corelib/CMakeFiles/Core.dir/global/qrandom.cpp.o src/corelib/CMakeFiles/Core.dir/io/qabstractfileengine.cpp.o src/corelib/CMakeFiles/Core.dir/io/qbuffer.cpp.o src/corelib/CMakeFiles/Core.dir/io/qdataurl.cpp.o src/corelib/CMakeFiles/Core.dir/io/qdebug.cpp.o src/corelib/CMakeFiles/Core.dir/io/qdir.cpp.o src/corelib/CMakeFiles/Core.dir/io/qdiriterator.cpp.o src/corelib/CMakeFiles/Core.dir/io/qfile.cpp.o src/corelib/CMakeFiles/Core.dir/io/qfiledevice.cpp.o src/corelib/CMakeFiles/Core.dir/io/qfileinfo.cpp.o src/corelib/CMakeFiles/Core.dir/io/qfileselector.cpp.o src/corelib/CMakeFiles/Core.dir/io/qfilesystemengine.cpp.o src/corelib/CMakeFiles/Core.dir/io/qfilesystementry.cpp.o src/corelib/CMakeFiles/Core.dir/io/qfsfileengine.cpp.o src/corelib/CMakeFiles/Core.dir/io/qfsfileengine_iterator.cpp.o src/corelib/CMakeFiles/Core.dir/io/qiodevice.cpp.o src/corelib/CMakeFiles/Core.dir/io/qipaddress.cpp.o src/corelib/CMakeFiles/Core.dir/io/qlockfile.cpp.o src/corelib/CMakeFiles/Core.dir/io/qloggingcategory.cpp.o src/corelib/CMakeFiles/Core.dir/io/qloggingregistry.cpp.o src/corelib/CMakeFiles/Core.dir/io/qnoncontiguousbytedevice.cpp.o src/corelib/CMakeFiles/Core.dir/io/qresource.cpp.o src/corelib/CMakeFiles/Core.dir/io/qresource_iterator.cpp.o src/corelib/CMakeFiles/Core.dir/io/qsavefile.cpp.o src/corelib/CMakeFiles/Core.dir/io/qstandardpaths.cpp.o src/corelib/CMakeFiles/Core.dir/io/qstorageinfo.cpp.o src/corelib/CMakeFiles/Core.dir/io/qtemporarydir.cpp.o src/corelib/CMakeFiles/Core.dir/io/qtemporaryfile.cpp.o src/corelib/CMakeFiles/Core.dir/io/qurl.cpp.o src/corelib/CMakeFiles/Core.dir/io/qurlidna.cpp.o src/corelib/CMakeFiles/Core.dir/io/qurlquery.cpp.o src/corelib/CMakeFiles/Core.dir/io/qurlrecode.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qabstracteventdispatcher.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qabstractnativeeventfilter.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qassociativeiterable.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qbasictimer.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qcoreapplication.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qcoreevent.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qcoreglobaldata.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qdeadlinetimer.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qelapsedtimer.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qeventloop.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qiterable.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qmath.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qmetacontainer.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qmetaobject.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qmetaobjectbuilder.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qmetatype.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qmimedata.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qobject.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qobjectcleanuphandler.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qpointer.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qproperty.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qsequentialiterable.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qsharedmemory.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qsignalmapper.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qsocketnotifier.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qsystemerror.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qsystemsemaphore.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qtestsupport_core.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qtimer.cpp.o src/corelib/CMakeFiles/Core.dir/kernel/qtranslator.cpp.o
Bug#1029681: nvidia-legacy-340xx-driver: Qt5 apps fail to launch with a segfault
Package: nvidia-legacy-340xx-driver Version: 340.108-17 Followup-For: Bug #1029681 X-Debbugs-Cc: pitsior...@outlook.com First of all, the title should be "gl related apps fail to launch" and let me explain why. I tried libreelec 11 beta 1 which came out a few days ago. It uses kernel 6.1, nvidia 340 and nvidia is definitely used for my card because I can check it in lspci -k. Kodi 20 works fine and it even has vdpau decoding. And, as seen here, it uses no extra patch for 6.1 https://github.com/LibreELEC/LibreELEC.tv/tree/master/packages/x11/driver/xf86-video- nvidia-legacy/patches Back on debian, I removed kodi after 10+ years of usage, because it does not work at all, and reinstalled the gles vesion of libqt5gui5 to restore the functionality on my qt5 apps. I also installed kitty, a terminal which uses opengl for its ui, and it fails to launch too. So, what if something is broken on the kernel's side, assuming that the last patch for nvidia 340 is good? -- Package-specific info: uname -a: Linux mitsos 6.1.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18) x86_64 GNU/Linux /proc/version: Linux version 6.1.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 12.2.0 (Debian 12.2.0-14) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96C [GeForce 9500 GT] [10de:0640] (rev a1) (prog-if 00 [VGA controller]) Subsystem: XFX Pine Group Inc. G96C [GeForce 9500 GT] [1682:2412] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.187829] Console: colour VGA+ 80x25 [0.422587] pci :01:00.0: vgaarb: setting as boot VGA device [0.422587] pci :01:00.0: vgaarb: bridge control possible [0.422587] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.422587] vgaarb: loaded [0.583824] Linux agpgart interface v0.103 [3.854564] nvidia: loading out-of-tree module taints kernel. [3.854629] nvidia: module license 'NVIDIA' taints kernel. [3.882969] nvidia: module verification failed: signature and/or required key missing - tainting kernel [3.958566] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.962467] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [3.962555] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 [6.532744] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs Device node permissions: crw-rw+ 1 root video 226, 0 Feb 2 19:21 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 Feb 2 19:21 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Feb 2 19:21 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Feb 2 19:21 pci-:01:00.0-card -> ../card0 video:*:44:jim Alternative 'nvidia': nvidia - auto mode link best version is /usr/lib/nvidia/legacy-340xx link currently points to /usr/lib/nvidia/legacy-340xx link nvidia is /usr/lib/nvidia/nvidia slave nvidia--20-nvidia-legacy-340xx.conf is /etc/X11/xorg.conf.d/20-nvidia-legacy-340xx.conf slave nvidia--libEGL.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 slave nvidia--libGL.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 slave nvidia--libGLESv1_CM.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1 slave nvidia--libGLESv2.so.2-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2 slave nvidia--libglx.so is /usr/lib/nvidia/libglx.so slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1 slave nvidia--monitoring.conf is /usr/share/nvidia/monitoring.conf slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy slave nvidia--nvidia-blacklists-nouveau.conf is /etc/nvidia/nvidia-blacklists-nouveau.conf slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump slave nvidia--nvidia-drm-outputclass.conf is /etc/nvidia/nvidia-drm-outputclass.conf slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf slave nvidia--nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf slave nvidia--nvidia-options.conf is /etc/modprobe.d/nvidia-options.conf slave nvidia--nvidia-settings is /usr/bin/nvidia-settings slave nvidia--nvidia-settings.1.gz is
Bug#1030177: pygame-sdl2: FTBFS: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '2.1.0-for-renpy-8.0.2'
Source: pygame-sdl2 Followup-For: Bug #1030177 Dear Maintainer, There's an upstream 'setuptools' issue[1] tracking these InvalidVersion exceptions: basically, version parsing is checking for PEP440[2] adherence. Updating the egg_info tag[2] for pygame-sdl2 to match the spec should resolve the problem. (in this case, one way to fix the bug could be: s/-for-renpy/+for-renpy/ ) Thanks, James [1] - https://github.com/pypa/setuptools/issues/3772 [2] - https://peps.python.org/pep-0440/ [3] - https://salsa.debian.org/games-team/pygame-sdl2/-/blob/b1c1d5df2d0095cbed3ade64367b460fa684788a/setup.cfg#L2
Bug#1026539: theano FTBFS
On Tue, Jan 03, 2023 at 10:21:16PM +, Rebecca N. Palmer wrote: > Please do *not* upload theano 1.12 to unstable - it's the Aesara version, > which may seriously break backward compatibility. > > I haven't had time to properly look at this bug yet. FTR, right now autopkgtest and build of both the version in bookworm/unstable and the version in experimental fail due to #1027215 (numpy 1.24). cu Adrian
Bug#1030313: ruby-google-apis-dns-v1 -- Simple REST client for Cloud DNS API V1
package: wnpp Severity: wishlist Owner: Vinay Keshava *Package Name : ruby-google-apis-dns-v1 Version : 0.12.0 Upstream Author : 2021 Google LLC *URL :https://github.com/googleapis/google-api-ruby-client *License : Apache-2.0 Programming Lang : Ruby *Description : Simple REST client for Cloud DNS API V1 This is the simple REST client for Cloud DNS API V1. Simple REST clients are Ruby client libraries that provide access to Google services via their HTTP REST API endpoints. These libraries are generated and updated automatically based on the discovery documents published by the service, and they handle most concerns such as authentication, pagination, retry, timeouts, and logging. You can use this client to access the Cloud DNS API, but note that some services may provide a separate modern client that is easier to use. This gem is required for gitlab. - Vinay Keshava
Bug#1030056: qa.debian.org: The most recent lintian version known by UDD is 2.115.3
On Tue, 31 Jan 2023 21:41:04 +0100 Lucas Nussbaum wrote: > I updated lintian on the worker. The results will get updated over the > next few days (probably 3 to 5 days). Thanks a lot! :-) [...] > I'll check again in a few days and close when the data is migrated. Sounds good. Bye! -- 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 pgptDEl_TuB7Y.pgp Description: PGP signature
Bug#1030312: fai-client: PACKAGES aptitude does not work anymore with fai6.0
Package: fai-client Version: 6.0 Severity: normal Tags: upstream X-Debbugs-Cc: hoffma...@physik.fu-berlin.de Hello, when using `PACKAGES aptitude` with FAI6.0, the operation fails, since aptitude does not know the option `--allow-change-held-packages` which was added to the default apt options (`$aptopt`) in da2a5977b3ff48be0dab8a7499a6cb9e39ce783e which are also used for aptitude (bin/install_packages#89). -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages fai-client depends on: ii debconf-utils1.5.82 ii file 1:5.44-3 ii iproute2 6.1.0-1 ii libfile-lchown-perl 0.02-3+b1 ii libgraph-perl1:0.9725-1 ii perl 5.36.0-7 ii procps 2:4.0.2-3 ii zstd 1.5.2+dfsg2-3 Versions of packages fai-client recommends: ii fdisk 2.38.1-4 ii util-linux 2.38.1-4 Versions of packages fai-client suggests: ii libgraph-perl 1:0.9725-1 pn logtail -- Configuration Files: /etc/fai/fai.conf [Errno 13] Permission denied: '/etc/fai/fai.conf' -- no debconf information
Bug#1030160: chromium: FTBFS on arm64/armhf in bullseye-security (V4L issues)
On Thu, Feb 2 2023 at 02:14:42 PM +, "Steinberg, Benjamin" wrote: On Tue, 31 Jan 2023 13:35:49 -0500 Andres Salomon wrote: > Thanks! I forgot that it can only be enabled on sid when I merged the > new release into bullseye. This will get fixed in the next security > upload. Thanks, Andres. Just to confirm, does > This will get fixed in the next security upload. mean that bullseye-security is not going to contain arm64 and armhf packages for Chromium 109.0.5414.119-1~deb11u1? I ask because in our application, I keep Chromium versions up to date and synchronized between deployments (amd64 machines) and developer machines (M1 Macs). If the arm64 package for this version won’t be present, I’ll wait for the next version, presumably 110.0.5481.77. Correct. I'll upload either the next v109 release (if we get one), or v110 (which is due out on Tuesday).
Bug#1030311: python3-grpc-tools: undefined symbol: _ZN6google8protobuf8internal22Release_CompareAndSwapEPVlll building opensnitch
Package: python3-grpc-tools Version: 1.14.1-5 Severity: important The opensnitch package fail to build on s390. The build log can be found at https://buildd.debian.org/status/fetch.php?pkg=opensnitch=s390x=1.5.5-1=1675346595=0 > and this is the failure: make[3]: Entering directory '/<>/proto' protoc -I. ui.proto --go_out=../daemon/ui/protocol/ --go-grpc_out=../daemon/ui/protocol/ --go_opt=paths=source_relative --go-grpc_opt=paths=source_relative python3 -m grpc_tools.protoc -I. --python_out=../ui/opensnitch/ --grpc_python_out=../ui/opensnitch/ ui.proto Traceback (most recent call last): File "", line 198, in _run_module_as_main File "", line 88, in _run_code File "/usr/lib/python3/dist-packages/grpc_tools/protoc.py", line 20, in from grpc_tools import _protoc_compiler ImportError: /usr/lib/python3/dist-packages/grpc_tools/_protoc_compiler.cpython-311-s390x-linux-gnu.so: undefined symbol: _ZN6google8protobuf8internal22Release_CompareAndSwapEPVlll make[3]: *** [Makefile:7: ../ui/opensnitch/ui_pb2.py] Error 1 The same code build on other architectures. -- Happy hacking Petter Reinholdtsen
Bug#1030308: simple-scan - debug messages
Hi, Please find attached the log messages I got reproducing the problem. First part is starting simple-scan, setting the source to "All Pages From Feeder" and closing it. Second part is re-opening simple-scan, trying to scan and getting the error message, then changing back to "Single Page", trying again and always getting the same message "Failed to scan - Document feeder empty". I hope this help. Regards, -- Jean-Marc simple-scan-debug.log.gz Description: application/gzip OpenPGP_signature Description: OpenPGP digital signature
Bug#1029825: emacs: reduce libgccjit0 related dependencies to optional?
control: severity -1 wishlist Hello, On Sat 28 Jan 2023 at 07:46PM +09, YOSHINO Yoshihito wrote: > When I tried to install emacs-gtk or emacs-nox in bookworm, it pulls > many development packages, especially binutils, libgcc-12-dev, > libc6-dev and linux-libc-dev, which I would avoid to install if > possible. They are pulled through libgccjit0, and probably used with > the native compilation feature. It seems automatic native compilation > can be inhibited run-time since 1:28.2+1-9. Is it possible to demote > those dependencies to Recommends? (Probably I would also have to ask > the libgccjit0 maintainer). I agree that it is unfortunate that all this now gets pulled in. I doubt that we will want to support both native-comp and non-native-comp anytime soon, however, even without the freeze. -- Sean Whitton signature.asc Description: PGP signature
Bug#1030310: python3-poetry: 'poetry check' requires python3-trove-classifiers
Package: python3-poetry Version: 1.3.2+dfsg-3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There's a missing dependency on python3-trove-classifiers in order for 'poetry check' to work. $ poetry check No module named 'trove_classifiers' - -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (530, 'testing'), (520, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) 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 python3-poetry depends on: ii python3 3.11.1-3 ii python3-cachecontrol0.12.12-2 ii python3-cleo2.0.1-5 ii python3-crashtest 0.4.1-1 ii python3-dulwich 0.21.2-1+b1 ii python3-filelock3.9.0-1 ii python3-html5lib1.1-3 ii python3-importlib-metadata 4.12.0-1 ii python3-jsonschema 4.10.3-1 ii python3-keyring 23.9.3-2 ii python3-lockfile1:0.12.2-2.2 ii python3-packaging 23.0-1 ii python3-pexpect 4.8.0-4 ii python3-pkginfo 1.8.2-2 ii python3-platformdirs2.6.0-1 ii python3-poetry-core 1.4.0-4 ii python3-requests2.28.1+dfsg-1 ii python3-requests-toolbelt 0.10.1-1 ii python3-shellingham 1.5.0-1 ii python3-tomli 2.0.1-2 ii python3-tomlkit 0.11.6-1 ii python3-urllib3 1.26.12-1 ii python3-virtualenv 20.17.1+ds-1 python3-poetry recommends no packages. python3-poetry suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCY9vkgBIcc2FtQHJvYm90 cy5vcmcudWsACgkQThGii4ZQGIpIzwEA52msPv9wVKApViUZjnun5pnaTInOBhZ9 yKyzSiWt0eEA/0behtTLnFqysrGDpW1y6/rWeKGgXgs2vjnf643ujVUB =Bc0z -END PGP SIGNATURE-
Bug#1030285: bsdutils: logger: regressed to reusing initial timestamp
tags 1030285 = patch bookworm sid
thanks
Karel Zak dixit:
>Already reported: https://github.com/util-linux/util-linux/issues/1866
>
>Bugfix:
>http://github.com/util-linux/util-linux/commit/96ccdc00e1fcf1684f9734a189baf90e00ff0c9a
Thanks
Dear Debian maintainers, please apply and upload ☺
bye,
//mirabilos
--
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”From 96ccdc00e1fcf1684f9734a189baf90e00ff0c9a Mon Sep 17 00:00:00 2001
From: Karel Zak
Date: Tue, 1 Nov 2022 10:30:06 +0100
Subject: [PATCH] logger: always update header when read from stdin
The current code updates the header only when the priority has been
changed. It's incorrect because wanted is a valid header or each entry
(don't forget that logger for stdin use-case is used in pipe to log
long-time running processes).
This patch also fixes the initial timestamp; it was originally generated
on logger startup, it now generates the header on the first message.
$ (sleep 2; date; sleep 2; date; sleep 2; date) | logger --stderr --no-act
old:
<13>Nov 1 10:42:14 kzak: Tue Nov 1 10:42:16 AM CET 2022
<13>Nov 1 10:42:14 kzak: Tue Nov 1 10:42:18 AM CET 2022
<13>Nov 1 10:42:14 kzak: Tue Nov 1 10:42:20 AM CET 2022
new:
<13>Nov 1 10:19:02 kzak: Tue Nov 1 10:19:02 AM CET 2022
<13>Nov 1 10:19:04 kzak: Tue Nov 1 10:19:04 AM CET 2022
<13>Nov 1 10:19:06 kzak: Tue Nov 1 10:19:06 AM CET 2022
Fixes: https://github.com/util-linux/util-linux/issues/1866
Signed-off-by: Karel Zak
---
misc-utils/logger.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/misc-utils/logger.c b/misc-utils/logger.c
index bec684f15b..e2b0b41abe 100644
--- a/misc-utils/logger.c
+++ b/misc-utils/logger.c
@@ -945,8 +945,6 @@ static void logger_open(struct logger_ctl *ctl)
ctl->tag = ctl->login = xgetlogin();
if (!ctl->tag)
ctl->tag = "";
-
- generate_syslog_header(ctl);
}
/* re-open; usually after failed connection */
@@ -996,10 +994,8 @@ static void logger_stdin(struct logger_ctl *ctl)
{
/* note: we re-generate the syslog header for each log message to
* update header timestamps and to reflect possible priority changes.
-* The initial header is generated by logger_open().
*/
int default_priority = ctl->pri;
- int last_pri = default_priority;
char *buf = xmalloc(ctl->max_message_size + 2 + 2);
int pri;
int c;
@@ -1026,10 +1022,6 @@ static void logger_stdin(struct logger_ctl *ctl)
} else
ctl->pri = default_priority;
- if (ctl->pri != last_pri) {
- generate_syslog_header(ctl);
- last_pri = ctl->pri;
- }
if (c != EOF && c != '\n')
c = getchar();
}
@@ -1040,8 +1032,10 @@ static void logger_stdin(struct logger_ctl *ctl)
}
buf[i] = '\0';
- if (i > 0 || !ctl->skip_empty_lines)
+ if (i > 0 || !ctl->skip_empty_lines) {
+ generate_syslog_header(ctl);
write_output(ctl, buf);
+ }
if (c == '\n') /* discard line terminator */
c = getchar();
@@ -1317,12 +1311,14 @@ int main(int argc, char **argv)
abort();
}
logger_open();
- if (0 < argc)
+ if (0 < argc) {
+ generate_syslog_header();
logger_command_line(, argv);
- else
+ } else
/* Note. --file reopens stdin making the below
* function to be used for file inputs. */
logger_stdin();
+
logger_close();
return EXIT_SUCCESS;
}
Bug#990447: Similar problems
On 2/1/23 23:31, Pascal Hambourg wrote: On 02/02/2023 at 00:33, Phil Dibowitz wrote: And I've run `grub-install` with my EFI dir mounted. What's interesting is the version in EFI is different than the version staged by the package: ``` # sum /usr/lib/shim/shimx64.efi /boot/EFI/EFI/debian/shimx64.efi 47979 918 /usr/lib/shim/shimx64.efi 36147 913 /boot/EFI/EFI/debian/shimx64.efi ``` You must compare with /usr/lib/shim/shimx64.efi.signed from shim-signed. Ah, thanks. At least I know I did the grub-install right: ``` $ sum /usr/lib/shim/shimx64.efi.signed /boot/EFI/EFI/debian/shimx64.efi 36147 913 /usr/lib/shim/shimx64.efi.signed 36147 913 /boot/EFI/EFI/debian/shimx64.efi ``` So I guess that means that the shimx64.efi that's distributed with shim-signed is, in fact, vulnerable, as proposed in the original bug. Any timeline on updating it? -- Phil Dibowitz p...@ipom.com Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." - Dr. Seuss
Bug#1030043: hplip-gui: traceback when launching hp-toolbox
tags 1029459 upstream severity 1029459 important thanks On Mon 30 Jan 2023 at 17:27:10 +0100, Julien Patriarca wrote: > Package: hplip-gui > Version: 3.22.10+dfsg0-1 > Severity: grave > Tags: patch > Justification: renders package unusable > > Dear Maintainer, > >* What led up to the situation? > Trying to launch hp-toolbox software, got this output: > > Traceback (most recent call last): > File "/usr/bin/hp-toolbox", line 280, in > toolbox = ui.DevMgr5(__version__, device_uri, None) > ^^ > File "/usr/share/hplip/ui5/devmgr5.py", line 238, in __init__ > core = CoreInstall(MODE_CHECK) > ^^^ > File "/usr/share/hplip/installer/core_install.py", line 240, in __init__ > self.passwordObj = password.Password(ui_mode) >^^ > File "/usr/share/hplip/base/password.py", line 94, in __init__ > self.__readAuthType() # self.__authType > ^ > File "/usr/share/hplip/base/password.py", line 119, in __readAuthType > distro_name = get_distro_std_name(os_name) > ^^^ > NameError: name 'get_distro_std_name' is not defined. Did you mean: > 'get_distro_name'? > > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > I patched the password.py file with the correct function name and > delete the os_name parameter when being called. > >* What was the outcome of this action? > > Positive. The hp-toolbox launched succesfully. Thank you for your report, Julien. This issue does not appear too dissimilar to #1029459: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029459 Reducing severity because not all hp-* utilities are affected. hp-wificonfig, for instance. Regards, Brian.
Bug#1030285: Fwd: Bug#1030285: bsdutils: logger: regressed to reusing initial timestamp
On Thu, Feb 02, 2023 at 02:50:30PM +, Thorsten Glaser wrote: > this regressed between 2.37.3 and 2.38~rc1 and you were the person > to touch this code last; do you have any idea which change introduced > this regression and a possible fix? Already reported: https://github.com/util-linux/util-linux/issues/1866 Bugfix: http://github.com/util-linux/util-linux/commit/96ccdc00e1fcf1684f9734a189baf90e00ff0c9a Karel > > Thanks in advance! > > -- Forwarded message -- > Message-ID: <167530436240.9092.12628425440425024484.report...@ara4.mirbsd.org> > Date: Thu, 02 Feb 2023 02:19:22 + > Subject: Bug#1030285: bsdutils: logger: regressed to reusing initial timestamp > > Package: bsdutils > Version: 1:2.38.1-4 > Severity: normal > X-Debbugs-Cc: t...@mirbsd.de > > I *know* we had this bug already, and it got fixed at some time, > but apparently a regression was introduced and this bug shows up > again in sid: long-running logger(1) sessions do not receive an > updated timestamp for later lines: > > root@ara4:~ # tail -F /var/log/syslog& > root@ara4:~ # (echo foo; sleep 5; echo bar) | logger -t baz > Feb 2 02:04:24 ara4 baz: foo > Feb 2 02:04:24 ara4 baz: bar > > Compare bullseye: > > tglase@x61w:~ $ (echo foo; sleep 5; echo bar) | logger -t baz > Feb 2 03:04:45 x61w baz: foo > Feb 2 03:04:50 x61w baz: bar > > I use “dæmonprogram | logger -t nameofthat” quite often, and > having output with ancient timestamps suddenly show up in logs > is confusing (especially fail2ban very much dislikes that). > > For the sake of completeness, the bullseye system uses > inetutils-syslogd 2:2.0-1+deb11u1, the sid system has > inetutils-syslogd 2:2.4-2, but TTBOMK the timestamp is > generated by logger(1), not the syslog dæmon (that would > be weird). > > > -- System Information: > Debian Release: bookworm/sid > APT prefers unreleased > APT policy: (500, 'unreleased'), (500, 'unstable') > Architecture: m68k > > Kernel: Linux 6.1.0-2-m68k (UP) > Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/bash > Init: sysvinit (via /sbin/init) > > Versions of packages bsdutils depends on: > ii libc62.36-4+ports > ii libsystemd0 252.4-1 > > Versions of packages bsdutils recommends: > ii bsdextrautils 2.38.1-4 > > bsdutils suggests no packages. > > -- no debconf information > -- Karel Zak http://karelzak.blogspot.com
Bug#1030189: Let regular users know need to put non-free-firmware in sources.list
On Wed, Feb 1, 2023 at 3:36 PM Sven Joachim wrote: > The release notes for Bookworm should and will certainly mention that. > I think this is where this bug is actually actionable, so I am > reassigning it there. > > > Yes, he should be regularly subscribed to debian-user, but that's too > > much. > > I have sent a heads-up message[1] there a few days ago, but as you said it > got lost in all the other topics discussed there. > > > Or https://lists.debian.org/debian-announce/, but that's too many boring > > messages too. > > There was not even a prominent notice there, at least not in the past > few weeks. > > > Yes, he uses apt-listchanges, but that won't tell him this. > > > > So I'm saying that Debian needs a mechanism to have his computer tell > > him to do this. > > > > Maybe the next time he uses apt*, somehow the system should tell him... > > Somehow, but how exactly? Good question that was brought up on > debian-devel[2], alas without replies yet. I got bitten by this, and only noticed it when my system's firmware packages showed up in the output of "apt list ~g". I'm sure I'm missing something, but why weren't transitional packages left in non-free that depend on the new versions in non-free-firmware? Perhaps they could also depend on a source-list-modifying package so the next upgrade doesn't break.
Bug#1030309: kodi-game-libretro-bsnes-mercury-accuracy: Depends: libretro-bsnes-accuracy-balanced but it is not installable
Package: kodi-game-libretro-bsnes-mercury-accuracy Version: 094+git20220807-4 Severity: serious The following packages have unmet dependencies: kodi-game-libretro-bsnes-mercury-accuracy : Depends: libretro-bsnes-accuracy-balanced but it is not installable Was the dependency intended to be on libretro-bsnes-mercury-accuracy instead?
Bug#1030303: install tmpfiles and sysusers config into correct path
Am 02.02.23 um 16:14 schrieb Philip Hands: Michael Biebl writes: I noticed that openqa and openqa-worker install its tmpfiles and sysusers configuration files into /lib. IIRC Originally the instalation into /lib was done in order to deal with the fact that dh_installsystem seemed not to notice them under /usr/lib. Btw, I'm specifically talking about sysusers and tmpfiles here. service units are still installed in /lib/systemd/system for historical reasons and for consistencies sake, openqa should continue shipping them there until we change that distro-wide. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1030303: install tmpfiles and sysusers config into correct path
Hi Phil Am 02.02.23 um 16:14 schrieb Philip Hands: Michael Biebl writes: I noticed that openqa and openqa-worker install its tmpfiles and sysusers configuration files into /lib. IIRC Originally the instalation into /lib was done in order to deal with the fact that dh_installsystem seemed not to notice them under /usr/lib. I presumed that would get fixed at some point, and intended to revert to installing them into their upstream location once that's done. However, I was also under the impression that we were supposed to be refraining from moving files between /lib/ and /usr/lib until after usr-merge was sorted out, in order to avoid issues with dpkg, so wasn't planning on touching this until that is all settled, just in case the openqa packages need rearanging at some point (since moving files between packages is what provokes that problem) That's why I think it's actually good to fix this for bookworm: openqa is not in stable yet, so you don't have an upgrade issue here that you need to worry about (as far as stable updates are concerned). I'd be happy to be proven wrong on this, as that would allow me to discard the special case from the install file. A move between / and /usr/lib is only problematic if a you also move the files between packages. This is not the case here, so should be safe. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1030308: simple-scan does not take sources' prefs into account
Package: simple-scan Version: 42.5-2 Severity: normal X-Debbugs-Cc: jean-m...@6jf.be Dear Maintainer, When I start simple-scan with "All Pages From Feeder" as source (i.e. when this was the source during my last scan session) and if I want to change to use "Single Page", I always got the message "Failed to scan - Document feeder empty". It is like simple-scan does not take into account the fact I changed the source but keep the last option from start. I can very easily reproduce it. Start simple-scan, change the source to "All Pages From Feeder" in the dropdown list at the right-hand side of the "Scan" button and close simple-scan. Start simple-scan again, it should start with the option "All Pages From Feeder" as source. Change this option choosing "Single Page" and try to scan a document clicking on the button "Scan". You should get the message "Failed to scan - Document feeder empty". Workaround is to select "Single Page" option, close simple-scan and re-start it. Hope it will help. Regards, Jean-Marc P.S. Thank you so much creating this program I use a lot ! -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages simple-scan depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.4-1 ii dbus-x11 [dbus-session-bus] 1.14.4-1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii libc6 2.36-8 ii libcairo2 1.16.0-7 ii libcolord21.4.6-2.1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.5-1 ii libgtk-3-03.24.36-2 ii libgusb2 0.3.10-1 ii libhandy-1-0 1.8.1-1 ii libpackagekit-glib2-181.2.6-2 ii libsane1 1.1.1-6+b2 ii libwebp7 1.2.4-0.1 ii libwebpmux3 1.2.4-0.1 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.2.13.dfsg-1 simple-scan recommends no packages. simple-scan suggests no packages. -- no debconf information
Bug#1030220: xrayutilities: missing dependency on python3-h5py breaks armel tests
Control: reopen 1030220 h5py 3.7.0-4 is uploaded fixing the source of the problem, but xrayutilities will need to be rebuilt to use the new pydist definitions.
Bug#1030303: install tmpfiles and sysusers config into correct path
Michael Biebl writes: > I noticed that openqa and openqa-worker install its tmpfiles and > sysusers configuration files into /lib. IIRC Originally the instalation into /lib was done in order to deal with the fact that dh_installsystem seemed not to notice them under /usr/lib. I presumed that would get fixed at some point, and intended to revert to installing them into their upstream location once that's done. However, I was also under the impression that we were supposed to be refraining from moving files between /lib/ and /usr/lib until after usr-merge was sorted out, in order to avoid issues with dpkg, so wasn't planning on touching this until that is all settled, just in case the openqa packages need rearanging at some point (since moving files between packages is what provokes that problem) I'd be happy to be proven wrong on this, as that would allow me to discard the special case from the install file. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1030307: RFS: posixsignalmanager/0.3-2 -- posix signal handling for qt
> So long for a library, change the name. It might be better to rename the package after bookworm became stable. My intent is to rename `ruby-mdl` into `markdownlint`; like `posixsignalmanager`, it is a package accepted into `testing` a couple of days ago. The recommendation I received was to stick with the odd name *for now*, and to defer attempts to rename the package, or else face the possibility that neither one form (i.e., old name, or new name) would ship.[1] Because the soft-freeze of `bookworm` merely is a few days ahead (February 12).[2] With these options ahead, I choose to stick (for now) with the name already introduced. It might be the safer choice for Christoph, too. Regards, Norwid [1] https://lists.debian.org/debian-ruby/2023/01/msg00058.html [2] https://release.debian.org/testing/freeze_policy.html
Bug#1029834: dpkg: cycle found while processing triggers
Hi Guillem, thanks for looking into this. Guillem Jover wrote on 01/02/2023 23:20: Control: tag -1 moreinfo Hi! On Sat, 2023-01-28 at 14:30:15 +0100, Jörg-Volker Peetz wrote: Package: dpkg Version: 1.21.19 Severity: normal upgrading the openjdk-17 packages on my system with # aptitude -t sid install ~Uopenjdk gives this error messages: dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: ca-certificates-java -> ca-certificates-java -> ca-certificates-java packages' pending triggers which are or may be unresolvable: ca-certificates-java: /usr/lib/jvm dpkg: error processing package ca-certificates-java (--configure): triggers looping, abandoned Setting up openjdk-17-jdk-headless:amd64 (17.0.6+10-1) ... Setting up ca-certificates-java (20230103) ... done. Setting up openjdk-17-jre:amd64 (17.0.6+10-1) ... Setting up openjdk-17-jdk:amd64 (17.0.6+10-1) ... Errors were encountered while processing: ca-certificates-java E: Sub-process /usr/bin/dpkg returned an error code (1) Any ideas? Was there any other error during the unpack or installation in general? Do you have the full log of that upgrade session? From what version were you upgrading from? There was no other error during the whole upgrade but I don't have the full log anymore. In spite of the error message the upgrade was successful. After each upgrade I check the installation with the commands: # apt-get check ; dpkg -C ; aptitude search '~b' '~g' '~c' The version of openjdk-17 was 17.0.5+8-2 before this upgrade. And I have to correct the version of ca-certificates-java which was 20230103. Do you perhaps have a backup of the status files from just before that upgrade session? (Either the /var/lib/dpkg/status-old if you have not done anything else package-wise since then, or perhaps under /var/backups.) Yes I have the status file. Compressed it is ca. 400 kB. I don't know if it's o.k. to attach it. Otherwise this unfortunately seems a bit non-actionable to me. :/ Yes, I know :-( On a second, similar computer I didn't see the error message. Thanks, Guillem Thanks, Jörg.
Bug#1022772: fixed in btllib 1.4.10+dfsg-1
Control: reopen -1 On Thu, 02 Feb 2023 08:34:35 + Debian FTP Masters wrote: > Source: btllib > Source-Version: 1.4.10+dfsg-1 > Done: Andreas Tille > > We believe that the bug you reported is fixed in the latest version of > btllib, which is due to be installed in the Debian FTP archive. While you have excluded the architectures in d/control, I still very much believe that this is not really a "fix" for the bug. The real fix shall be when btllib actually builds on 32 but archs. Hence, I'm reopening this. You can reduce the severity should you like, though. Best, Nilesh
Bug#1030285: Info received (logger regression)
notfound 1030285 1:2.37.2-1 found 1030285 1:2.38-2 found 1030285 1:2.38~rc1-1 notfound 1030285 1:2.37.3-1+b1 thanks It’s a recent regression.
Bug#1030305: django-rich: FTBFS when building with TERM=unknown
Package: django-rich Followup-For: Bug #1030305 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu lunar ubuntu-patch Control: tags -1 patch Adding a revised debdiff. This version applies the patch that I submitted upstream: https://github.com/adamchainz/django-rich/pull/103 The patch modifies the upstream test-suite rather than overriding the TERM variable at dh_auto_test time. Thanks! -- System Information: Debian Release: bookworm/sid APT prefers kinetic-updates APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 'kinetic'), (100, 'kinetic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-29-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch --- django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch 1970-01-01 01:00:00.0 +0100 +++ django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch 2023-02-02 12:05:10.0 +0100 @@ -0,0 +1,41 @@ +Description: Fix failing tests if the TERM variable is set to unknown + When running the test-suite with TERM=unknown, the tests fail because + the generated output is not "rich". + . + This happens because python rich will disable color and style if the TERM + variable is set to either "unknown" or "dumb" [1] + . + This patch monkey-patches the environment to make the test suite + insensitive to the TERM variable. + . + [1] https://rich.readthedocs.io/en/stable/console.html?highlight=unknown#environment-variables +Author: Olivier Gayot +Origin: upstream, https://github.com/adamchainz/django-rich/pull/103/commits/ac19f46572fb0550a9b7a688114c298dd7b6c872 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030305 +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/django-rich/+bug/2004553 +Forwarded: https://github.com/adamchainz/django-rich/pull/103 +Last-Update: 2023-02-02 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: django-rich-1.4.0/tests/test_management.py +=== +--- django-rich-1.4.0.orig/tests/test_management.py2023-02-02 15:06:49.343335475 +0100 django-rich-1.4.0/tests/test_management.py 2023-02-02 15:06:49.343335475 +0100 +@@ -3,6 +3,7 @@ + from functools import partial + from inspect import Parameter, Signature, signature + from io import StringIO ++import os + from unittest import mock + + import pytest +@@ -28,6 +29,9 @@ + return True + + ++# python rich will disable color/style if TERM is set to "unknown" or "dumb" ++# https://rich.readthedocs.io/en/stable/console.html?highlight=unknown#environment-variables ++@mock.patch.dict(os.environ, TERM="") + class RichCommandTests(SimpleTestCase): + def test_init_signature(self): + rc_signature = strip_annotations(signature(RichCommand.__init__)) diff -Nru django-rich-1.4.0/debian/patches/clear-TERM-variable.patch django-rich-1.4.0/debian/patches/clear-TERM-variable.patch --- django-rich-1.4.0/debian/patches/clear-TERM-variable.patch 1970-01-01 01:00:00.0 +0100 +++ django-rich-1.4.0/debian/patches/clear-TERM-variable.patch 2023-02-02 12:05:10.0 +0100 @@ -0,0 +1,20 @@ +Index: django-rich-1.4.0/tests/test_management.py +=== +--- django-rich-1.4.0.orig/tests/test_management.py2022-06-05 17:27:00.0 +0200 django-rich-1.4.0/tests/test_management.py 2023-02-02 14:50:44.876420552 +0100 +@@ -3,6 +3,7 @@ + from functools import partial + from inspect import Parameter, Signature, signature + from io import StringIO ++import os + from unittest import mock + + import pytest +@@ -28,6 +29,7 @@ + return True + + ++@mock.patch.dict(os.environ, TERM="") + class RichCommandTests(SimpleTestCase): + def test_init_signature(self): + rc_signature = strip_annotations(signature(RichCommand.__init__)) diff -Nru django-rich-1.4.0/debian/patches/series django-rich-1.4.0/debian/patches/series --- django-rich-1.4.0/debian/patches/series 2023-01-15 08:16:57.0 +0100 +++ django-rich-1.4.0/debian/patches/series 2023-02-02 12:05:10.0 +0100 @@ -1,3 +1,4 @@ Use-python3-within-test-call.patch tests-Drop-various-python-version-handling.patch tests-Another-bunch-of-adoptions-for-Python-3.11.patch +0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch
Bug#1030160: chromium: FTBFS on arm64/armhf in bullseye-security (V4L issues)
On Tue, 31 Jan 2023 13:35:49 -0500 Andres Salomon mailto:dilin...@queued.net>> wrote: > Thanks! I forgot that it can only be enabled on sid when I merged the > new release into bullseye. This will get fixed in the next security > upload. Thanks, Andres. Just to confirm, does > This will get fixed in the next security upload. mean that bullseye-security is not going to contain arm64 and armhf packages for Chromium 109.0.5414.119-1~deb11u1? I ask because in our application, I keep Chromium versions up to date and synchronized between deployments (amd64 machines) and developer machines (M1 Macs). If the arm64 package for this version won’t be present, I’ll wait for the next version, presumably 110.0.5481.77.
Bug#1030285: logger regression
notfound 1030285 1:2.25.2-6 notfound 1030285 1:2.29.2-1+deb9u1 notfound 1030285 1:2.33.1-0.1 notfound 1030285 1:2.36.1-8+deb11u1 found 1030285 1:2.38.1-4 thanks No, this is definitely a post-bullseye regression. If upstream is unwilling, this must be fixed in the Debian package. (I was just looking at alternatives; MirBSD logger(1) builds fine on Debian, but Debian’s has many incompatible changes, including systemd-related ones(?!), so it’s not a drop-in replacement. This is unfortunate for these who want to use logger(1) to add syslog functionality to programs, as is decades-long tradition.) bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#1030307: RFS: posixsignalmanager/0.3-2 -- posix signal handling for qt
The name of the package is bad. So long for a library, change the name. Regards, Mezgani Ali +212 6 44 17 94 51 ali.mezg...@nativelabs.ma https://wiki.debian.org/mezgani ⢀⣴⠾⠻⢶⣦⠀ Active member of IETF, GNU, Debian, FreeBSD and Kernel. ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄⠀ > On 02/02/2023, at 15:10, Christoph Hueffelmann wrote: > > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "posixsignalmanager": > > * Package name : posixsignalmanager > Version : 0.3-2 > Upstream contact : Martin Hostettler > * URL : https://github.com/textshell/posixsignalmanager > * License : BSL-1.0 > * Vcs : [fill in URL of packaging vcs] > Section : libs > > The source builds the following binary packages: > > libposixsignalmanager0a - posix signal handling for qt - shared library > libposixsignalmanager-dev - posix signal handling for qt - headers > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/posixsignalmanager/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/p/posixsignalmanager/posixsignalmanager_0.3-2.dsc > > Changes since the last upload: > > posixsignalmanager (0.3-2) unstable; urgency=medium > . > * debian/patches: Add upstream patch: Build fixes for non x86 architectures. > > > We hope that we can now fix the broken architectures in the debian ci for our > packages. > > Regards, > -- > Christoph Hueffelmann >
Bug#1030247: ITP: libtext-names-perl -- module for proper name parsing, normalization, recognition and classification
Hi Mason, On 2023-02-01 17:04, m...@kohaaloha.com wrote: Text::Namess provides a number of name normalization routines, plus ^ Letter 's' is duplicated (Namess) in package description in debian/control. Best, Andrius
Bug#1030307: RFS: posixsignalmanager/0.3-2 -- posix signal handling for qt
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "posixsignalmanager": * Package name : posixsignalmanager Version : 0.3-2 Upstream contact : Martin Hostettler * URL : https://github.com/textshell/posixsignalmanager * License : BSL-1.0 * Vcs : [fill in URL of packaging vcs] Section : libs The source builds the following binary packages: libposixsignalmanager0a - posix signal handling for qt - shared library libposixsignalmanager-dev - posix signal handling for qt - headers To access further information about this package, please visit the following URL: https://mentors.debian.net/package/posixsignalmanager/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/posixsignalmanager/posixsignalmanager_0.3-2.dsc Changes since the last upload: posixsignalmanager (0.3-2) unstable; urgency=medium . * debian/patches: Add upstream patch: Build fixes for non x86 architectures. We hope that we can now fix the broken architectures in the debian ci for our packages. Regards, -- Christoph Hueffelmann
Bug#998736: In other package
I've also been looking for a newer adb version. In testing and unstable in the non-free repo you find google-android-platform-tools-installer which seems to superseed the adb package. Right now it's in version 33.
Bug#1029971: gcc-sh-elf: Rebuild takes 100 times what it used to take
El 1/2/23 a las 14:39, John Scott escribió: Then again, I wonder if these timeouts reflect legitimate issues in the package? If you compile, say, abs-1.c by hand using an installed gcc-sh- elf assuming that's possible, and then try running it under sh-elf-run, does it appear to timeout? I don't know, because I found about this by doing an archive-wide rebuild of all packages in bookworm (I didn't even go as far as actually using the package). My theory is that this is due to some behaviour change in gcc-12-source, the most important build-dependency, but I would still hope that such change could be disabled in the gcc-sh-elf package itself in some way. I've put all my build logs here for you to see: https://people.debian.org/~sanvila/build-logs/gcc-sh-elf/ If you do tail -n1 * on them you will see that this was taking between one and two hours until 2022-07. Then something happened between 2022-07 and 2022-12 which made the build time to increase so much. The last three builds deserve an explanation: ==> gcc-sh-elf_4_amd64-20221211T112134.352Z <== Build needed 22:10:00, 3349844k disk space ==> gcc-sh-elf_4_amd64-20221211T112240.719Z <== Build needed 22:08:52, 3349900k disk space ==> gcc-sh-elf_4_amd64-20230121T070646.221Z <== Build needed 131:59:54, 4206644k disk space I killed the process by hand in the build logs of 2022-12-11 because I started to see there was something wrong (22 hours instead of 1-2 hours). That's why they appear as "failed builds". Then, on 2023-01-21, I decided not to kill the process to see how long would it really take. And it took 5 days. The build machines are diverse: yoda[12] and skywalker[12] are self-hosted virtual machines using kvm/libvirt, with one CPU and about 6 GB of RAM (enough for this package according to the data I collected by monitoring /proc/meminfo during the build). Machines with names starting with "hh" are Hetzner machines with 2 CPUs. Machines with names starting with a single "h" are Hetzner machines with a single CPU. I can provide ssh access to a Hetzner machine similar to the ones I used for you to test (please contact me privately for details). Thanks.
Bug#984866: unavailable packages / CVE
Tags: pending Once r2d2 (in NEW atm) enters the archive I can upload diesel-derives 2.0.0 and diesel 2.0.0 which will fix this. Regards, Matthias Geiger (werdahias)
Bug#1030306: simple-scan: Not a JPEG file: starts with 0x00 0x00
Package: simple-scan Version: 3.38.1-1 Severity: grave X-Debbugs-Cc: none, Janusz S. Bień Dear Maintainer, -- Package-specific info: -- BEGIN ATTACHMENTS -- /tmp/tmp.dgtNgi4r0Z/logfile.user /tmp/tmp.dgtNgi4r0Z/scanimage.user /tmp/tmp.dgtNgi4r0Z/lsusb.user -- END ATTACHMENTS -- After I switched Samsung Xpress M2070FW from USB to W-Fi practically every attempt to scan ends with this bug. Scanning with GIMP and SANE still works. I will appreciate your help. Regards - Janusz -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-21-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages simple-scan depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.24-0+deb11u1 ii dbus-x11 [dbus-session-bus] 1.12.24-0+deb11u1 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii libc6 2.31-13+deb11u5 ii libcairo2 1.16.0-5 ii libcolord21.4.5-3 ii libgdk-pixbuf2.0-02.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-03.24.24-4+deb11u2 ii libgusb2 0.3.5-1 ii libpackagekit-glib2-181.2.2-2 ii libsane1 1.0.31-4.1 ii libwebp6 0.6.1-2.1 ii libwebpmux3 0.6.1-2.1 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.2.11.dfsg-2+deb11u2 simple-scan recommends no packages. simple-scan suggests no packages. -- no debconf information -- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien
Bug#1005165: fwupd-amd64-signed uninstallable for a few weeks now
Hi, On Tue, 08 Feb 2022 11:11:35 +0100 Bastian Venthur wrote: Package: fwupd-amd64-signed Version: 1.5.7+5 Severity: grave Justification: renders package unusable X-Debbugs-Cc: vent...@debian.org Dear Maintainer, fwupd-amd64-signed is uninstallable as it depends on fwupd < 1.5.7-6, however the current version in unstable is 1.7.4-1. This bug is already marked fixed, but not closed. I think it can be closed, right? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1029846: freecad: after upgrading today, not possible to launch the program
Dear all, I have had the same issue after the last update. I managed to corner the problem finding that the *.desktop file call freecad with the --single-instance option and freecad does not recognise it. This option is added by the run_single-instance patch (see 1:). The issue arises because the new 0.20.2 does not seem to recognise the option anymore. The snap install of the same version does recognise the option so I should now compare the two sources (debianised sources and upstream) but run out of time. Anybody interested in investigating about this issue is welcome :) Cheers ! 1: http://salsa.debian.org/science-team/freecad/-/blob/debian/0.20.2+dfsg1-3/debian/patches/run_single-instance.patch On Sat, 28 Jan 2023 19:21:38 +0100 Eric Streit wrote: > Package: freecad > Version: 0.20.2+dfsg1-3 > Severity: normal > X-Debbugs-Cc: e...@yojik.eu > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > * What led up to the situation? > I upgraded Freecad today (28/01/2023), and it's not posible to launch > the program anymore from the gnome launcher. > * What exactly did you do (or not do) that was effective (or > ineffective)? > I was able to launch it from the terminal. > * What was the outcome of this action? > It worked. > * What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-1-amd64 (SMP w/12 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 /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages freecad depends on: > ii freecad-python3 0.20.2+dfsg1-3 > > Versions of packages freecad recommends: > pn calculix-ccx > ii graphviz 2.42.2-7+b3 > > Versions of packages freecad suggests: > pn povray > > -- no debconf information > >
