Bug#1008584: RFS: milvus/2.0.0-1 [ITP] -- Vector database for unstructured data
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "milvus": Milvus Vector Database has an active open-source community and has helped 1000+ users
Bug#1008380: confirmed and forwarded
Control: tags -1 + confirmed Control: forwarded -1 https://github.com/samuelflores/MMB/issues/24 Hello, gemmi::GridSetup has indeed disappeared in gemmi/0.5.3. I have forwarded the issue upstream. Andrius
Bug#1008283: Really confusing update-exim4.conf(8) man page
On Fri, Mar 25, 2022 at 10:03:20PM +, S E wrote: > Pulling up the manpage for 'update-exim4.conf'... read in the first FIVE > paragraphs, > still unable to comprehend. Had to write it down a flowchart. It's a complex package. Does reading /usr/share/doc/exim4-base/README.Debian.gz help? If you have understood how things work now, can you do a patch for the docs, making them better? It is sometimes hard to write beginner-level docs when you have been stuck in the details of the package for two decades. Greetings Marc
Bug#1008583: python3-sss dependencies cannot be satisfied
Package: python3-sss Version: 2.4.1-2 When I try to install sssd, I see: Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python3-ldb : Depends: python3 (< 3.10) but 3.10.4-1 is to be installed python3-sss : Depends: python3 (< 3.10) but 3.10.4-1 is to be installed python3-sss in sid or bookworm depends on a python version that is no longer available for bookwork or sid.
Bug#1008582: cloud.debian.org: SSM public parameters for buster-backports AMIs aren't getting updated
Package: cloud.debian.org
Severity: normal
User: cloud.debian@packages.debian.org
Usertags: + aws infrastructure
The IDs for buster-backports AMIs for AWS are queryable via SSM public
parameters at /aws/service/debian/release/10-backports/ However, the release
pipeline is apparently not updating them, at least some of the time, and the
most recently published parameter is from last year:
$ aws ssm get-parameters-by-path \
--path /aws/service/debian/release/10-backports \
--recursive --output json \
--query "max_by(Parameters[], )"
{
"Name": "/aws/service/debian/release/10-backports/20211229-871/arm64",
"Type": "String",
"Value": "ami-0d4fccbb20a209053",
"Version": 1,
"LastModifiedDate": 1640801031.624,
"ARN":
"arn:aws:ssm:us-west-2::parameter/aws/service/debian/release/10-backports/20211229-871/arm64",
"DataType": "text"
}
Given that we have published buster-backports AMIs within the past two days,
this data is clearly stale.
Bullseye and Buster regular listings are refreshed as expected. The problem is
likely related to the SSM publication code not handling the case when both
buster and buster-backports are being published in the same pipeline run.
Bug#1008581: gnome-software: conffiles not removed: /etc/xdg/autostart/gnome-software-service.desktop
Package: gnome-software
Version: 42.0-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate
The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb
This bug report brought to you by adequate:
https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
$ p=gnome-software ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p |
grep obsolete
gnome-software: obsolete-conffile
/etc/xdg/autostart/gnome-software-service.desktop
/etc/xdg/autostart/gnome-software-service.desktop
e9aa76e7f13a9dc704e2da2bc785c053 obsolete
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.16.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gnome-software depends on:
ii appstream 0.15.2-2
ii apt-config-icons 0.15.2-2
ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3
ii gnome-software-common 42.0-1
ii gsettings-desktop-schemas 42.0-1
ii libadwaita-1-0 1.1.0-1
ii libappstream4 0.15.2-2
ii libc6 2.33-7
ii libcairo2 1.16.0-5
ii libfwupd2 1.7.6-1
ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii libglib2.0-0 2.72.0-1
ii libgtk-4-1 4.6.2+ds-1
ii libgtk3-perl 0.038-1
ii libgudev-1.0-0 237-2
ii libjson-glib-1.0-0 1.6.6-1
ii libmalcontent-0-0 0.10.3-1
ii libpackagekit-glib2-18 1.2.5-3
ii libpango-1.0-0 1.50.6+ds-1
ii libpolkit-gobject-1-0 0.105-33
ii libsoup2.4-1 2.74.2-3
ii libxmlb2 0.3.6-2
ii packagekit 1.2.5-3
ii software-properties-gtk 0.96.20.2-2.1
Versions of packages gnome-software recommends:
ii fwupd 1.7.6-1
Versions of packages gnome-software suggests:
pn apt-config-icons-hidpi
pn gnome-software-plugin-flatpak
pn gnome-software-plugin-snap
-- no debconf information
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#733586: closure-compiler: new upstream version available
Hello Nicholas, On Mon, Mar 28, 2022 at 03:27:17PM -0400, Nicholas D Steeves wrote: > Control: unblock 886411 by -1 > > Hi Tony and Thomas, > > This package came to my attention via #975505, where it was noted that > MathJax2 has had to disable functionality because of too ancient of a > closure-compiler, and at this time it appears that MathJax3 will have to > do the same. > > Closure-compiler is a candidate for salvaging: > > https://wiki.debian.org/PackageSalvaging > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > > The ideal resolution would be for one of the listed Uploaders to resume > maintenance of the package, but orphaning is of course also an option :-) The closure-compiler package is officially a team-maintained package by the Java Team, so you or anyone else who is interested in joining Java Team and maintaining the package is welcome to do so. That is, please feel free to add yourself to Uploaders. That said, it's more of a JavaScript tool than a Java package, and so the package could also be moved to another team if that's preferable. I will gladly help with either of those options, or with reviewing and sponsoring an upload of a newer version if one is made available. Finally, I have never been a user of closure-compiler - my packaging work on it has been under the Java Team umbrella - and I have (obviously) been unable to devote sufficient time to it. I will remove myself from Uploaders to avoid any future confusion. > Pirate Praveen writes: > > > Control: block 886411 by -1 > > > > On Sat, 20 Jan 2018 20:38:02 +0530 Pirate Praveen > > wrote:> Being more familiar with nodejs packaging, I prefer to go back to > >> google-closure-compiler-js. But if there is a newer closure-compiler, > >> it'd make my work a lot easier. > >> > > > > Hi Tony, > > > > Digging deeper, I found out even the javascript version is built using > > java sources (using gwt). So I have to update the java sources even for > > javascript version. Hope you are still interested in updating > > closure-compiler and we can collaborate. > > Hi Pirate! > > I noticed that you were able to complete #886411 ITP: node-react using > some other method (perhaps google-closure-compiler-js, or perhaps > disabling functionality?), so I've unset the block relation. It seemed > worthwhile keep you in the CC list in case you wanted to create a > "switch to closure-compiler" bug, and block it with this one (#733586). > > > Kind regards, > Nicholas Cheers, tony signature.asc Description: PGP signature
Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy
On Mon, Mar 28, 2022 at 07:17:46PM +0300, Andrius Merkys wrote: > Hi Alexandre, > > On 2022-03-23 16:33, Alexandre Rossi wrote: > > Seems to work: > > > > $ ls -la /usr/share/java/htmlcleaner* > > lrwxrwxrwx 1 root root 15 18 mars 18:20 > > /usr/share/java/htmlcleaner-2.26.jar -> htmlcleaner.jar > > -rw-r--r-- 1 root root 176219 18 mars 18:20 > > /usr/share/java/htmlcleaner.jar > > $ sudo dpkg -i > > oss/debian/davmail/libhtmlcleaner-java_2.26-1+fix+bad+jar+name+1_all.deb > > [...] > > $ ls -la /usr/share/java/htmlcleaner* > > -rw-r--r-- 1 root root 176219 23 mars 15:27 > > /usr/share/java/htmlcleaner-2.26.jar > > lrwxrwxrwx 1 root root 20 23 mars 15:27 > > /usr/share/java/htmlcleaner.jar -> htmlcleaner-2.26.jar > > Many thanks for the proposed patch. It seems we need a decision now on > which one is actually buggy: maven-debian-helper or java-policy. I would > vote for upholding the java-policy if only the symlink placement switch > does not break anything (neither reverse dependencies not the update > mechanism). Having versionless symlinks parallels nicely lib*-dev shlib > scheme and there might be situations where this is beneficial for Java > too. Unluckily enough, there are >700 source packages now directly > affected by this [1]. > > [1] https://lintian.debian.org/tags/bad-jar-name Hello Andrius, hi Alexandre, I can't speak to every reverse dependency, but I don't expect breakage to occur with this change, assuming of course that the update mechanism works consistently. I also agree with you that a versionless symlink to a versioned jar file seems preferable. As you mention, if nothing else, it is consistent with other languages in Debian. So my vote is to accept the change. That fact that so many packages are affected does mean there will be a lot of uploads, but ideally we will upload at least once per release cycle (anyway), so the timing of this patch and proposal is reasonable. I am interested to hear other opinions from the Debian Java Team. Cheers, tony signature.asc Description: PGP signature
Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail
Control: severity -1 serious On Sun, Mar 27, 2022 at 12:30 PM Daniel Kahn Gillmor wrote: > I think either gnome-settings-daemon 42.1-* should indicate that it > Breaks: earlier versions of gnome-control-center, or > gnome-control-center should indicate that it is tightly bound to the > version of gnome-settings-daemon that it ships with. This fix is pending but we are waiting for gnome-control-center to build as its dependencies are part of the ongoing python3.10 transition. Thanks, Jeremy Bicha
Bug#1008580: sparse: Update gcc-10 dependency
Package: sparse Version: 0.6.4-1+b1 Severity: normal Dear Maintainer, Sparse in testing depends on gcc-10. As the kernel has moved to depend on gcc-11, sparse is the only package on my system pulling in the older compiler as a dependency. Perhaps it could be made to depend on simply 'gcc', or changed to gcc-11. Versions of packages sparse depends on: ii gcc-1010.3.0-14 ii libc6 2.33-7 ii libgcc-s1 12-20220319-1 ii libllvm13 1:13.0.1-3+b1 ii libsqlite3-0 3.38.1-1 ii libxml2 2.9.13+dfsg-1 ii perl 5.34.0-3
Bug#1008169: bootstrapping fedora34 or centos7 gives a system with an empty package database
On Thu, 24 Mar 2022 13:09:32 +0100 Enrico Zini wrote: > On Thu, Mar 24, 2022 at 12:52:24AM +, Luca Boccassi wrote: > > > Have you checked if the --clean-package-metadata= option is the cause? > > > > CleanPackageMetadata=, --clean-package-metadata= > > Enable/disable removal of package manager databases, caches, and logs at the end of installation. > > Can be specified as true, false, or “auto” (the default). With “auto”, files will be removed if the > > respective package manager executable is not present at the end of the installation. > > I just tried, and that does not seem to be the cause: > > $ sudo /usr/bin/mkosi --distribution=fedora --release=34 -- format=directory --output=target --base-packages=true -- package=bash,rootfiles,dbus,dnf --clean-package-metadata=false > … > $ sudo systemd-nspawn --volatile -D target > Spawning container target on /home/enrico/lavori/arpa/moncic- ci/target. > Press ^] three times within 1s to kill container. > -bash-5.1# rpm -qa > -bash-5.1# rpmdb --rebuilddb > -bash-5.1# rpm -qa > -bash-5.1# ls -la /var/lib/rpm > total 240 > drwxr-xr-x 2 0 0 100 Mar 24 13:08 . > drwxr-xr-x 3 0 0 60 Mar 24 13:08 .. > -rw-r--r-- 1 0 0 212992 Mar 24 13:08 rpmdb.sqlite > -rw-r--r-- 1 0 0 32768 Mar 24 13:08 rpmdb.sqlite-shm > -rw-r--r-- 1 0 0 0 Mar 24 13:08 rpmdb.sqlite-wal > -bash-5.1# Root cause is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004863 Workaround: https://github.com/systemd/mkosi/pull/940 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1008579: a2ps: 'fixps -f' calls gs device 'pswrite' which should be 'ps2write'
Package: a2ps Version: 1:4.14-7 Severity: important Dear Maintainer, The 'fixps' program fails when performing a full GS rewrite due to $ grep pswrite /usr/bin/fixps $gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pswrite -sOutputFile=- -c save pop -f $file ;; which needs to be 'ps2write' not 'pswrite'. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797528 -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-11-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 a2ps depends on: ii file 1:5.39-3 ii libc6 2.31-13+deb11u2 ii libpaper1 1.1.28+b1 ii psutils1.17.dfsg-4 Versions of packages a2ps recommends: ii bzip21.0.8-4 ii lprng [lpr] 3.8.B-5 ii wdiff1.2.2-2+b1 Versions of packages a2ps suggests: ii emacsen-common 3.0.4 ii ghostscript 9.53.3~dfsg-7+deb11u2 ii groff1.22.4-6 ii gv 1:3.7.4-2+b1 pn html2ps ii imagemagick 8:6.9.11.60+dfsg-1.3 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3 pn t1-cyrillic ii texlive-binaries [texlive-base-bin] 2020.20200327.54578-7 -- no debconf information
Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye
On Sun, Sep 05, 2021 at 05:01:18PM +0100, Steve McIntyre wrote: > On Sat, Sep 04, 2021 at 06:50:16PM +0100, Steve McIntyre wrote: > > > >I have a synquacer here still and I'll take a look. I noticed on > >bullseye release day that USB stuff didn't seem to work in the > >installer on the synquacer either. Maybe there's been a regression in > >config. :-/ > > > >I'll take a look... > > Hmmm, booting 5.10.0-0.bpo.8-arm64 here does not work at all. I'm > seeing a lot of errors around DMA setup, e.g.: I bisected this to 7a8b64d17e35810dc3176fe61208b45c15d25402 is the first bad commit commit 7a8b64d17e35810dc3176fe61208b45c15d25402 Author: Rob Herring Date: Thu Feb 6 14:02:30 2020 + of/address: use range parser for of_dma_get_range on what appears to have been a DT system with a built in DT from the firmware, using upstream's defconfig. I dimly recall seeing some discussion of issues here in the past, though I don't have one of these boxes myself so wasn't paying huge attention. I'd guess there's some bug in the DT which given that this is in the firmware the kernel ought to fix up during early init, if someone with better access to one of these systems could supply a DT for inspection that might help people figure things out. I suspect the machines might work fine when booted with ACPI firmware. The bisect log: git bisect start # bad: [3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162] Linux 5.7 git bisect bad 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 # good: [7111951b8d4973bda27ff663f2cf18b663d15b48] Linux 5.6 git bisect good 0ad2c0e5fc7bd5c5a60f88be1174271410254e32 # skip: [50a5de895dbe5df947b3a695777db5b2c313e065] Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma git bisect skip 50a5de895dbe5df947b3a695777db5b2c313e065 # good: [422c032afcf57d5e8109a54912e22ffc53d99068] netfilter: flowtable: Use rw sem as flow block lock git bisect good 422c032afcf57d5e8109a54912e22ffc53d99068 # skip: [8c1b724ddb218f221612d4c649bc9c7819d8d7a6] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect skip 8c1b724ddb218f221612d4c649bc9c7819d8d7a6 # bad: [88d7fcfa3b1fe670f0412b95be785aafca63352b] net: inet_csk: Fix so_reuseport bind-address cache in tb->fast* git bisect bad 88d7fcfa3b1fe670f0412b95be785aafca63352b # skip: [6cad420cc695867b4ca710bac21fde21a4102e4b] Merge branch 'akpm' (patches from Andrew) git bisect skip 6cad420cc695867b4ca710bac21fde21a4102e4b # good: [77a36a3ab4ff17fad23831192e3694a3c5a1750d] HID: Add driver fixing Glorious PC Gaming Race mouse report descriptor git bisect good 77a36a3ab4ff17fad23831192e3694a3c5a1750d # bad: [8ec91c0fce1500306a858d0c35d1383fd9eb6ba6] Merge tag 'gpio-v5.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio git bisect bad 8ec91c0fce1500306a858d0c35d1383fd9eb6ba6 # skip: [7be97138e7276c71cc9ad1752dcb502d28f4400d] Merge tag 'xfs-5.7-merge-8' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux git bisect skip 7be97138e7276c71cc9ad1752dcb502d28f4400d # bad: [f5637d3b42ab0465ef71d5fb8461bce97fba95e8] mm/memory_hotplug: rename mhp_restrictions to mhp_params git bisect bad f5637d3b42ab0465ef71d5fb8461bce97fba95e8 # skip: [f365ab31efacb70bed1e821f7435626e0b2528a6] Merge tag 'drm-next-2020-04-01' of git://anongit.freedesktop.org/drm/drm git bisect skip f365ab31efacb70bed1e821f7435626e0b2528a6 # skip: [c101e9bbce4ae2947b35a660f17d617fc3827595] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid git bisect skip c101e9bbce4ae2947b35a660f17d617fc3827595 # good: [dc8c609bd31d2b410fd47a82a7b259f68056b244] drm/rcar-du: Plug atomic state hooks to the default implementation git bisect good dc8c609bd31d2b410fd47a82a7b259f68056b244 # skip: [ccfc569347f870830e7c7cf854679a06cf9c45b5] mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLE git bisect skip ccfc569347f870830e7c7cf854679a06cf9c45b5 # skip: [e964f1e04a1ce562f0d748b29326244d3cb35ba4] Merge tag 'dmaengine-5.7-rc1' of git://git.infradead.org/users/vkoul/slave-dma git bisect skip e964f1e04a1ce562f0d748b29326244d3cb35ba4 # good: [1fd34184aab0fe04c5d50af01a37fe1bb8bd6595] drm/meson: dw-hdmi: stop enforcing input_bus_format git bisect good 1fd34184aab0fe04c5d50af01a37fe1bb8bd6595 # skip: [ff2ae607c6f329d11a3b0528801ea7474be8c3e9] Merge tag 'spdx-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx git bisect skip ff2ae607c6f329d11a3b0528801ea7474be8c3e9 # good: [cc674ef252f4750bdcea1560ff491081bb960954] KVM: s390: introduce module parameter kvm.use_gisa git bisect good cc674ef252f4750bdcea1560ff491081bb960954 # good: [b17350e4037257d25f1ca9772ba5daced9f1bf07] soundwire: cadence: commit changes in the exit_reset() sequence git bisect good b17350e4037257d25f1ca9772ba5daced9f1bf07 # bad: [aa1a8ce533324d12696a9f4b71dbc5eb561a2e04] Merge tag 'trace-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace git bisect bad aa1a8ce533324d12696a9f4b71dbc5eb561a2e04 # skip:
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello Chris, On Mon 28 Mar 2022 at 10:35PM +02, Christoph Berg wrote: > The problem here is that if ul-extra contains things besides rename, > and it conflicts with the perl rename, people will rightfully complain > that they can't install /usr/bin/fincore-from-ul-extra and > /usr/bin/rename-from-perl at the same time. Indeed, and doesn't it violate Policy 10.1, which says "Two different packages must not install programs with different functionality but with the same filenames" ? Perhaps it's an edge case. -- Sean Whitton signature.asc Description: PGP signature
Bug#1008275: libsane: Reinstate libieee1284 support for parallel printers
On 2022-03-28 06:14, Ralph Little wrote: The logic really does seem to be reversed, such that --enable-parport_directio is enabled for every arch except hurd. What is strange though is that if I disable the sane-git PPA to use 1.0.27 from Ubuntu standard repo, I get this: [sanei_debug] Setting debug level of plustek_pp to 50. [sanei_debug] Setting debug level of sanei_pp to 50. [sanei_pp] pp_init: called for the first time [sanei_pp] pp_init: initializing libieee1284 [sanei_pp] pp_init: 1 ports reported by IEEE 1284 library [sanei_pp] pp_init: port 0 is `parport0` [sanei_pp] pp_init: initialized successfully So it really is using libieee1284 in this case. So I'm pretty confused. Has this build code changed recently? That's not so strange. Without knowing exactly when the mistake was introduced, I don't see it in bionic, but I do see it in focal (and impish). So, as regards Ubuntu: It's about to be fixed in jammy (via a sync from version 1.1.1-5 in unstable). But if you would like to see it fixed in focal, then please file a Launchpad bug against the sane-backends source package. -- Rgds, Gunnar
Bug#987292: chromium: Use system libxnvctrl
On Tue, 20 Apr 2021 23:52:12 +0200 Bastian Germann wrote: > Package: chromium > Severity: wishlist > > debian/TODO says: "remove third_party/libXNVCtrl (package currently in contrib, bug #747837)" > > The bug is done and libxnvctrl-dev is in main now. Please compile against the system library. > > I did actually remove third_party/libXNVCtrl upstream, but there's still a copy in ANGLE (third_party/angle/src/third_party/libXNVCtrl/).
Bug#1008480: debian-policy: The mime-support package was split into media-types and mailcap
control: tag -1 + pending Hello, On Sun 27 Mar 2022 at 12:47PM +09, Charles Plessy wrote: > Package: debian-policy > Version: 4.6.0.1 > Severity: normal > X-Debbugs-Cc: ple...@debian.org > > Hi Russ and Sean, > > it is a long time I have not posted here! > > In the previous release cycle, I have split the mime-support into the > media-types and the mailcap packages. > > The patch below updates the Policy to reflect that. This is technically a normative change but since the change has already been made in the archive, I've just gone ahead and applied it to 'next'. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Bug#1008578: buster-pu: golang-github-russellhaering-goxmldsig/0.0~git20170911.b7efc62-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu The attached debdiff for golang-github-russellhaering-goxmldsig fixes CVE-2020-7711 in Buster. This CVE has been marked as no-dsa by the security team. Thorsten golang-github-russellhaering-goxmldsig_0.0~git20170911.b7efc62-1+deb10u1.debdiff Description: Binary data
Bug#1008577: bullseye-pu: golang-github-russellhaering-goxmldsig/1.1.0-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
The attached debdiff for golang-github-russellhaering-goxmldsig fixes
CVE-2020-7711 in Bullseye. This CVE has been marked as no-dsa by the
security team.
Thorsten
diff -Nru golang-github-russellhaering-goxmldsig-1.1.0/debian/changelog
golang-github-russellhaering-goxmldsig-1.1.0/debian/changelog
--- golang-github-russellhaering-goxmldsig-1.1.0/debian/changelog
2021-01-08 00:13:56.0 +0100
+++ golang-github-russellhaering-goxmldsig-1.1.0/debian/changelog
2022-03-28 22:32:49.0 +0200
@@ -1,3 +1,12 @@
+golang-github-russellhaering-goxmldsig (1.1.0-1+deb11u1) bullseye;
urgency=medium
+
+ * CVE-2020-7711
+null pointer dereference caused by crafted XML signatures
+(Closes: #968928)
+ * according to ratt, nothing else has to be built
+
+ -- Thorsten Alteholz Mon, 28 Mar 2022 22:32:49 +0200
+
golang-github-russellhaering-goxmldsig (1.1.0-1) unstable; urgency=medium
* New upstream release (Closes: #971615)
diff -Nru
golang-github-russellhaering-goxmldsig-1.1.0/debian/patches/CVE-2020-7711.patch
golang-github-russellhaering-goxmldsig-1.1.0/debian/patches/CVE-2020-7711.patch
---
golang-github-russellhaering-goxmldsig-1.1.0/debian/patches/CVE-2020-7711.patch
1970-01-01 01:00:00.0 +0100
+++
golang-github-russellhaering-goxmldsig-1.1.0/debian/patches/CVE-2020-7711.patch
2022-03-24 02:38:42.0 +0100
@@ -0,0 +1,23 @@
+commit fb23e0af61c023e3a6dae8ad30dbd0f04d8a4d8f
+Merge: 3541f5e ca2b448
+Author: Russell Haering
+Date: Fri Aug 27 20:19:01 2021 -0700
+
+Merge pull request #71 from aporcupine/patch-1
+
+Explicitly check for case where SignatureValue is nil
+
+Index: golang-github-russellhaering-goxmldsig-1.1.0/validate.go
+===
+--- golang-github-russellhaering-goxmldsig-1.1.0.orig/validate.go
2022-03-24 02:38:38.797524728 +0100
golang-github-russellhaering-goxmldsig-1.1.0/validate.go 2022-03-24
02:38:38.797524728 +0100
+@@ -271,6 +271,9 @@
+ if !bytes.Equal(digest, decodedDigestValue) {
+ return nil, errors.New("Signature could not be verified")
+ }
++ if sig.SignatureValue == nil {
++ return nil, errors.New("Signature could not be verified")
++ }
+
+ // Decode the 'SignatureValue' so we can compare against it
+ decodedSignature, err :=
base64.StdEncoding.DecodeString(sig.SignatureValue.Data)
diff -Nru golang-github-russellhaering-goxmldsig-1.1.0/debian/patches/series
golang-github-russellhaering-goxmldsig-1.1.0/debian/patches/series
--- golang-github-russellhaering-goxmldsig-1.1.0/debian/patches/series
1970-01-01 01:00:00.0 +0100
+++ golang-github-russellhaering-goxmldsig-1.1.0/debian/patches/series
2022-03-24 02:39:15.0 +0100
@@ -0,0 +1 @@
+CVE-2020-7711.patch
Bug#1007717: Native source package format with non-native version
Hello Lucas, Many thanks for providing this summary of your position. Let me just note a point of disagreement: On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote: > A point that I find important is the following: as a project, I think > that we care about facilitating the review of changes we make to > upstream source. Certainly we do. > I think that the preferred method (and widely accepted method) for > that is currently to use the 3.0 (quilt) format with DEP-3-documented > patches, on top of a tarball that contains the pristine upstream > source. > > The git packaging workflows that generate source packages using either > 1.0 native packages, or 1.0 non-native packages without patches, make it > harder to identify and review those changes, as they require browsing > the git repository, which sometimes is not properly documented using > Vcs-*. I don't think it's the preferred method. I believe most of the project sees git histories are the preferred tool for achieving the goal you state. If we had only source packages for this purpose, then yes, 3.0 (quilt) plus DEP-3 would be preferred. But we have git, too, and indeed dgit. Repositories for packages contain both upstream history and Debian packaging history, and we have powerful git subcommands for extracting information. In many cases there is a good argument to be made that the git history is part of the preferred form of modification. -- Sean Whitton signature.asc Description: PGP signature
Bug#1008576: python3.10: Please backport patch to fix FTBFS on ia64
Source: python3.10 Version: 3.10.4-1 Severity: normal Tags: patch upstream User: debian-i...@lists.debian.org Usertags: ia64 X-Debbugs-Cc: debian-i...@lists.debian.org Hello! The current FTBFS on ia64 is another variant of the segmentation fault we already addressed in #995987 [1] with a work-around. Upstream has decided now to fix the issue properly once and for all [2]. I have cherry-picked the patch from [3] onto the 3.10 branch of cpython which fixed the issue for me. I'm attaching the patch. The workaround in debian/rules from [1] can be removed again. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995987 > [2] https://bugs.python.org/issue45526 > [3] > https://github.com/python/cpython/commit/0224b7180b280794b9fba62057b278ffb536c86f -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From 0224b7180b280794b9fba62057b278ffb536c86f Mon Sep 17 00:00:00 2001 From: Neil Schemenauer Date: Thu, 21 Oct 2021 14:05:46 -0700 Subject: [PATCH] bpo-45526: obmalloc radix use 64 addr bits (GH-29062) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Łukasz Langa --- .../2021-10-19-10-29-47.bpo-45526.WQnvW9.rst | 3 + Objects/obmalloc.c| 55 --- 2 files changed, 38 insertions(+), 20 deletions(-) create mode 100644 Misc/NEWS.d/next/Core and Builtins/2021-10-19-10-29-47.bpo-45526.WQnvW9.rst diff --git a/Misc/NEWS.d/next/Core and Builtins/2021-10-19-10-29-47.bpo-45526.WQnvW9.rst b/Misc/NEWS.d/next/Core and Builtins/2021-10-19-10-29-47.bpo-45526.WQnvW9.rst new file mode 100644 index 00..c35e5f58a4 --- /dev/null +++ b/Misc/NEWS.d/next/Core and Builtins/2021-10-19-10-29-47.bpo-45526.WQnvW9.rst @@ -0,0 +1,3 @@ +In obmalloc, set ADDRESS_BITS to not ignore any bits (ignored 16 before). That is +safer in the case that the kernel gives user-space virtual addresses that span +a range greater than 48 bits. diff --git a/Objects/obmalloc.c b/Objects/obmalloc.c index 2eddb2cafd..4e17bf44b4 100644 --- a/Objects/obmalloc.c +++ b/Objects/obmalloc.c @@ -1280,21 +1280,30 @@ _Py_GetAllocatedBlocks(void) #if WITH_PYMALLOC_RADIX_TREE /*==*/ -/* radix tree for tracking arena usage +/* radix tree for tracking arena usage. If enabled, used to implement + address_in_range(). - bit allocation for keys + memory address bit allocation for keys - 64-bit pointers and 2^20 arena size: - 16 -> ignored (POINTER_BITS - ADDRESS_BITS) - 10 -> MAP_TOP - 10 -> MAP_MID - 8 -> MAP_BOT + 64-bit pointers, IGNORE_BITS=0 and 2^20 arena size: + 15 -> MAP_TOP_BITS + 15 -> MAP_MID_BITS + 14 -> MAP_BOT_BITS + 20 -> ideal aligned arena + + 64 + + 64-bit pointers, IGNORE_BITS=16, and 2^20 arena size: + 16 -> IGNORE_BITS + 10 -> MAP_TOP_BITS + 10 -> MAP_MID_BITS + 8 -> MAP_BOT_BITS 20 -> ideal aligned arena 64 32-bit pointers and 2^18 arena size: - 14 -> MAP_BOT + 14 -> MAP_BOT_BITS 18 -> ideal aligned arena 32 @@ -1306,11 +1315,16 @@ _Py_GetAllocatedBlocks(void) /* number of bits in a pointer */ #define POINTER_BITS 64 -/* Current 64-bit processors are limited to 48-bit physical addresses. For - * now, the top 17 bits of addresses will all be equal to bit 2**47. If that - * changes in the future, this must be adjusted upwards. +/* High bits of memory addresses that will be ignored when indexing into the + * radix tree. Setting this to zero is the safe default. For most 64-bit + * machines, setting this to 16 would be safe. The kernel would not give + * user-space virtual memory addresses that have significant information in + * those high bits. The main advantage to setting IGNORE_BITS > 0 is that less + * virtual memory will be used for the top and middle radix tree arrays. Those + * arrays are allocated in the BSS segment and so will typically consume real + * memory only if actually accessed. */ -#define ADDRESS_BITS 48 +#define IGNORE_BITS 0 /* use the top and mid layers of the radix tree */ #define USE_INTERIOR_NODES @@ -1318,7 +1332,7 @@ _Py_GetAllocatedBlocks(void) #elif SIZEOF_VOID_P == 4 #define POINTER_BITS 32 -#define ADDRESS_BITS 32 +#define IGNORE_BITS 0 #else @@ -1332,6 +1346,9 @@ _Py_GetAllocatedBlocks(void) # error "arena size must be < 2^32" #endif +/* the lower bits of the address that are not ignored */ +#define ADDRESS_BITS (POINTER_BITS - IGNORE_BITS) + #ifdef USE_INTERIOR_NODES /* number of bits used for MAP_TOP and MAP_MID nodes */ #define INTERIOR_BITS ((ADDRESS_BITS - ARENA_BITS + 2) / 3) @@ -1360,11 +1377,9 @@ _Py_GetAllocatedBlocks(void) #define MAP_MID_INDEX(p) ((AS_UINT(p) >>
Bug#1007776: authemtication of wireless network after password input fails
The output of lsmod from the same Debian live is attached. I apologize for the delay. Cheers, Peter The live test is quite useful, thanks for mentioning it. I'm wondering whether this could be due to missing crypto modules inside our image, which I've seen to be the reason for failure to associate from the installer, while the installed system was fine. Any chance you could start the live image again, save the output of `lsmod`, and attach it here, using reply-all? Module Size Used by ctr16384 2 ccm20480 6 si2157 24576 1 si2168 24576 1 m88rs6000t 24576 1 a8293 20480 1 cx2584073728 1 intel_rapl_msr 20480 0 intel_rapl_common 28672 1 intel_rapl_msr snd_hda_codec_realtek 159744 1 snd_hda_codec_generic98304 1 snd_hda_codec_realtek ipmi_ssif 40960 0 ledtrig_audio 16384 1 snd_hda_codec_generic snd_hda_codec_hdmi 73728 1 skx_edac 24576 0 nfit 77824 1 skx_edac snd_hda_intel 57344 5 cx23885 208896 1 libnvdimm 196608 1 nfit snd_intel_dspcfg 28672 1 snd_hda_intel altera_ci 20480 1 cx23885 soundwire_intel45056 1 snd_intel_dspcfg tda18271 53248 1 cx23885 soundwire_generic_allocation16384 1 soundwire_intel altera_stapl 36864 1 cx23885 x86_pkg_temp_thermal20480 0 iwlmvm339968 0 snd_soc_core 315392 1 soundwire_intel intel_powerclamp 20480 0 m88ds3103 40960 2 cx23885 coretemp 20480 0 i2c_mux16384 2 m88ds3103,si2168 mac80211 983040 1 iwlmvm kvm_intel 327680 0 tveeprom 28672 1 cx23885 snd_compress 32768 1 snd_soc_core cx2341x32768 1 cx23885 soundwire_cadence 36864 1 soundwire_intel videobuf2_dvb 16384 1 cx23885 kvm 921600 1 kvm_intel libarc416384 1 mac80211 snd_hda_codec 172032 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek dvb_core 155648 4 m88ds3103,altera_ci,cx23885,videobuf2_dvb rc_core61440 1 cx23885 videobuf2_dma_sg 16384 1 cx23885 videobuf2_memops 20480 1 videobuf2_dma_sg irqbypass 16384 1 kvm snd_hda_core 110592 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek videobuf2_v4l2 36864 1 cx23885 videobuf2_common 65536 3 videobuf2_v4l2,cx23885,videobuf2_dvb snd_hwdep 16384 1 snd_hda_codec iwlwifi 294912 1 iwlmvm videodev 286720 5 cx2341x,videobuf2_v4l2,videobuf2_common,cx23885,cx25840 soundwire_bus 90112 3 soundwire_intel,soundwire_generic_allocation,soundwire_cadence rapl 20480 0 mc 61440 6 videodev,si2157,videobuf2_v4l2,dvb_core,videobuf2_common,cx25840 eeepc_wmi 16384 0 snd_pcm 135168 9 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,soundwire_intel,snd_compress,snd_soc_core,cx23885,snd_hda_core intel_cstate 20480 0 cfg80211 970752 3 iwlmvm,iwlwifi,mac80211 asus_wmi 45056 1 eeepc_wmi snd_timer 49152 1 snd_pcm battery20480 1 asus_wmi intel_uncore 176128 0 iTCO_wdt 16384 0 efi_pstore 16384 0 sparse_keymap 16384 1 asus_wmi pcspkr 16384 0 acpi_ipmi 20480 0 snd 110592 22 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_compress,snd_soc_core,cx23885,snd_pcm intel_pmc_bxt 16384 1 iTCO_wdt iTCO_vendor_support16384 1 iTCO_wdt intel_wmi_thunderbolt20480 0 rfkill 28672 7 asus_wmi,cfg80211 wmi_bmof 16384 0 tpm_crb20480 0 soundcore 16384 1 snd watchdog 28672 1 iTCO_wdt sg 36864 0 ipmi_si73728 1 ipmi_devintf 20480 0 ipmi_msghandler 118784 4 ipmi_devintf,ipmi_si,acpi_ipmi,ipmi_ssif mei_me 45056 0 tpm_tis16384 0 tpm_tis_core 28672 1 tpm_tis tpm73728 3 tpm_tis,tpm_crb,tpm_tis_core mei 139264 1 mei_me ioatdma61440 0 rng_core 16384 1 tpm evdev 28672 10 acpi_tad 20480 0 msr16384 0 fuse 167936 3 configfs 57344 1 efivarfs 16384 1 ip_tables 32768 0 x_tables 53248 1 ip_tables autofs453248 2 squashfs 69632 1 loop 40960 2 overlay 143360
Bug#1008575: linux-image-5.10.0-13-amd64: Wi-Fi stops working after upgrading from -12- to linux-image-5.10.0-13-amd64 (iwlwifi: probe of 0000:00:14.3 failed with error -110)
Package: src:linux Version: 5.10.106-1 Severity: important Dear Kernel maintainers and other Debian users that maybe have the same problem, After upgrading from linux-image-5.10.0-12-amd64 to linux-image-5.10.0-13-amd64 the iwlwifi is unable to initialise the Intel Corporation Wi-Fi 6 AX201 (rev 20) Wi-Fi device. Before: [4.549794] iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-QuZ-a0-hr-b0-59.ucode [4.549800] iwlwifi :00:14.3: api flags index 2 larger than supported by driver [4.549808] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 65.3.35.22 [4.550084] iwlwifi :00:14.3: loaded firmware version 59.601f3a66.0 QuZ-a0-hr-b0-59.ucode op_mode iwlmvm [4.550099] iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) After: [4.481502] iwlwifi: probe of :00:14.3 failed with error -110 The bug looks remotely similar to: https://bugs.debian.org/976110 https://bugs.debian.org/1003026 https://bugs.debian.org/976110 I've given the bug the severity: important, because this laptop is mostly used for being online and thus without that function is becomes more or less useless. I'll check whether I find something upstream. And report back. *t -- Package-specific info: ** Version: Linux version 5.10.0-12-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.103-1 (2022-03-07) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-12-amd64 root=UUID=2fd78bce-bb85-4405-82b5-2779947d695e ro quiet ** Not tainted ** Kernel log: ** Model information sys_vendor: HP product_name: HP ENVY Laptop 17-cg1xxx product_version: Type1ProductConfigId chassis_vendor: HP chassis_version: Chassis Version bios_vendor: Insyde bios_version: F.12 board_vendor: HP board_name: 8822 board_version: 49.36 ** Loaded modules: ctr ccm rfcomm cmac algif_hash algif_skcipher af_alg bnep binfmt_misc dm_crypt dm_mod snd_soc_skl_hda_dsp snd_soc_hdac_hdmi snd_soc_dmic mei_hdcp intel_rapl_msr x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic kvm_intel kvm snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_sof_xtensa_dsp snd_sof snd_sof_intel_hda snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi irqbypass ledtrig_audio intel_cstate intel_uncore snd_hda_intel joydev snd_intel_dspcfg soundwire_intel soundwire_generic_allocation btusb iwlmvm snd_soc_core btrtl btbcm btintel snd_compress pcspkr soundwire_cadence bluetooth mac80211 serio_raw efi_pstore hp_wmi snd_hda_codec libarc4 wmi_bmof snd_hda_core snd_hwdep iwlwifi soundwire_bus uvcvideo jitterentropy_rng snd_pcm videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common drbg snd_timer videodev snd ansi_cprng iTCO_wdt intel_pmc_bxt iTCO_vendor_support cfg80211 ee1004 watchdog soundcore ecdh_generic mmc_block mc ecc mei_me mei rfkill hid_multitouch ucsi_acpi processor_thermal_device typec_ucsi intel_rapl_common intel_soc_dts_iosf typec tpm_crb int3403_thermal tpm_tis int340x_thermal_zone tpm_tis_core ac tpm intel_hid sparse_keymap rng_core soc_button_array int3400_thermal acpi_pad evdev acpi_thermal_rel intel_pmc_core msr parport_pc ppdev lp parport fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod i915 i2c_algo_bit nvme crc32_pclmul spi_pxa2xx_platform crc32c_intel drm_kms_helper nvme_core hid_generic dw_dmac ahci dw_dmac_core libahci t10_pi rtsx_pci_sdmmc ghash_clmulni_intel crc_t10dif libata mmc_core cec crct10dif_generic drm aesni_intel scsi_mod xhci_pci xhci_hcd libaes crct10dif_pclmul crypto_simd crct10dif_common usbcore cryptd glue_helper vmd rtsx_pci i2c_i801 intel_lpss_pci i2c_smbus intel_lpss idma64 usb_common i2c_hid fan wmi hid battery video button ** PCI devices: :00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01) Subsystem: Hewlett-Packard Company 11th Gen Core Processor Host Bridge/DRAM Registers [103c:8822] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- :00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Iris Xe Graphics [103c:8822] 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: i915 Kernel modules: i915
Bug#1008518: nmu: libxxf86vm_1:1.1.4-1+b2
On 2022-03-28 12:57:38, Paul Gevers wrote: > Right, multiarch. > Rebuilding on all architectures wouldn't help, as the other > architectures would be bumped too, so we only want to rebuild ia64 > and riscv64. Scheduled. Thanks for the clarifications. I think based on this that in the future I should do 2 things differently. 1. Don't select all architectures, but instead choose only the affected architectures. (I saw this as an option in reportbug, but the irc advice specifically said all, so I thought it best to go with that.) 2. In the comment field I should mention multiarch, so the motivation is clearer. Thanks again! -Jordan signature.asc Description: signature
Bug#985907: rnp: accepts weak cryptographic primitives
Control: close 985907 0.16.0-1 On Thu 2021-03-25 13:39:00 -0400, Daniel Kahn Gillmor wrote: > rnp currently accepts signatures over weak or untrustworthy > cryptographic primitives. As of 0.16.0, rnp introduces the following relevant safeguards (from upstream's CHANGELOG.md): * Mark SHA1 signatures produced later than 2019-01-19, as invalid. * Mark MD5 signatures produced later than 2012-01-01, as invalid. * Use SHA1 collision detection code when using SHA1. While we might debate whether these are the best possible defaults, it's no longer completely insecure by default. In addition, rnp now has the following APIs which can adjust the underlying acceptable security primitives: rnp_get_security_rule rnp_add_security_rule rnp_remove_security_rule So it's possible to adjust the acceptable security levels directly if the user wants to nudge the defaults. I'm not convinced this is the ideal interface, but it should be at least usable. --dkg signature.asc Description: PGP signature
Bug#994388: dpkg currently warning about merged-usr systems
On Fri, 25 Mar 2022 18:04:14 + Luca Boccassi wrote: > On Fri, 2022-03-25 at 11:32 -0600, Gunnar Wolf wrote: > > Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]: > > > I am part of that group, and that is definitely _not_ why I wouldn't > > > touch dpkg with a barge pole as things stand (and have stood for > > > years). You are making a gigantic leap with that assumption, not sure > > > what you base it on. As a downstream and upstream maintainer in several > > > large projects I fix things that don't impact me all the time, all over > > > the place. > > > > > > But anyway, it turns out it's all moot because - drum roll - there is a > > > patch: > > > > > > https://0x0.st/oNFG.diff > > > > > > This was shared just now on #debian-devel IRC by user 'uau', linked > > > here with explicit permission. > > > > > > So it looks like you, Russ and others who chimed in this thread should > > > now be in a position to test your theory that a missing patch was the > > > only issue. Care to take it forward? > > > > Wow, this is a positive turn of events! Do you happen to have more > > information as to the identity of the submitter? We should be able of > > properly granting attribution... > > > > The patch seems sane from a first, very much 1m-point-of-view. Of > > course, it is very situation-specific and not generalized for > > following any unexpected symlinks in the directory hierarchy, but I do > > not expect that to be an issue (as we are talking about a very > > specific migration here). I am absolutely unfamiliar with dpkg > > internals and there are some bits that jump to my eye, but I do not > > think there is much use in me discussing very-minor things that should > > be obvious to people who are actually involved with dpkg. > > > > Has this diff been shared with Guillem, or included in any relevant > > bug report? > > Sorry, I don't know anything more than what I have shared - it was > linked and briefly discussed by user 'uau' on #debian-devel this > afternoon. I just happened to be online, noticed it and asked for > permission to share it here, which was granted. I do not know this > user, and I do not know if this patch has been shared or discussed > elsewhere. The author of the patch today on IRC confirmed that the patch is under the same license as dpkg (GPL2+), and when asked if they plan to push it forward, there was no answer. So the license is clear if somebody else wants to take it forward. Also worth noting that a couple of days ago, the author wrote on #debian-devel that some time ago the patch was presented to the dpkg maintainer, who rejected it with an answer along the lines of the usual "usrmerge is broken by design", with no further comment. So, what is the next step? Will the those on this thread who asserted they think a correct patch would be accepted without issues try and take it forward themselves? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1008574: atanks: Fails to start the game, main menu is working normally
Package: atanks Version: 6.6~dfsg-1 Severity: important * What led up to the situation? I installed the game and tried to play, after adjusting some of the options. * What exactly did you do (or not do) that was effective (or ineffective)? I then clicked the "Play" button, chose a few AI opponents and then clicked the "Okay" button. * What was the outcome of this action? Atomic Tanks exited on SIGABRT. The problem is one (or more) of the options I changed, because if I move ~/.atanks/ out of the way and do not touch any of the options, it works. If I reset the options it works too. I attach my ~/.atanks/atanks-config.txt: please note that I edited it by hand and used a few values out of range in the MONEY section, but the problem was there even before that manual edit. * What outcome did you expect instead? The game to start. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (700, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 atanks depends on: ii atanks-data6.6~dfsg-1 ii liballegro4.4 2:4.4.3.1-2 ii libc6 2.33-7 ii libgcc-s1 11.2.0-16 ii libstdc++6 11.2.0-16 atanks recommends no packages. atanks suggests no packages. -- no debconf information *ENV* ACCELERATEDAI=1 BOXMODE=0 CHECKUPDATES=1 COLOURTHEME=1 CUSTOMBACKGROUND=0 DEBRISLEVEL=1 DETAILEDLAND=1 DETAILEDSKY=1 DITHER=1 DIVIDEMONEY=0 DOBOXWRAP=0 DYNAMICMENUBG=1 FALLINGDIRTBALLS=0 FOG=0 FRAMES=60 FULLSCREEN=0 GRAVITY=0.15 INTEREST=1.50 ITEMTECHLEVEL=5 LANDSLIDEDELAY=2 LANDSLIDETYPE=3 LANDTYPE=4 LANGUAGE=0 LIGHTNING=0 MAXFIRETIME=0 METEORS=0 NETWORKING=0 NETWORKPORT=25645 NUMPERMANENTPLAYERS=11 OSMOUSE=1 PLAYMUSIC=0 ROUNDS=5 SATELLITE=0 SCOREBOARD=0 SCOREHITUNIT=500 SCOREROUNDWINBONUS=50 SCORESELFHIT=0 SCORETEAMHIT=0 SCOREUNITDESTROYBONUS=200 SCOREUNITSELFDESTROY=0 SCREENHEIGHT=800 SCREENWIDTH=1600 SELLPERCENT=3.00 SERVERNAME='127.0.0.1' SERVERPORT='25645' SHOWAIFEEDBACK=1 SHOWFPS=0 SOUNDDRIVER=4 SOUNDENABLED=1 STARTMONEY=1999 TEXTFADE=1 TEXTSHADOW=1 TEXTSWAY=1 TURNTYPE=0 VISCOSITY=0.50 VIOLENTDEATH=0 VOLLEYDELAY=10 VOLUMEFACTOR=1 WALLTYPE=4 WEAPONTECHLEVEL=5 WINDSTRENGTH=5 WINDVARIATION=0 *** *PLAYER* NAME=Crippler COLOR=0 DEFENSIVE=-0.523000 PAINSENSITIVITY=0.702000 PLAYED=0 PREFTYPE=1 SELFPRESERVATION=0.911000 TANK_BITMAP=5 TEAM=0 TYPE=0 TYPESAVED=0 VENGEANCETHRESHOLD=0.113000 VENGEFUL=69 WON=0 WEAPONPREFERENCES=0 0 WEAPONPREFERENCES=1 7030 WEAPONPREFERENCES=2 8985 WEAPONPREFERENCES=3 8647 WEAPONPREFERENCES=4 5263 WEAPONPREFERENCES=5 9311 WEAPONPREFERENCES=6 6328 WEAPONPREFERENCES=7 6391 WEAPONPREFERENCES=8 5351 WEAPONPREFERENCES=9 8596 WEAPONPREFERENCES=10 6529 WEAPONPREFERENCES=11 5614 WEAPONPREFERENCES=12 7732 WEAPONPREFERENCES=13 7694 WEAPONPREFERENCES=14 9160 WEAPONPREFERENCES=15 9348 WEAPONPREFERENCES=16 7331 WEAPONPREFERENCES=17 9812 WEAPONPREFERENCES=18 5602 WEAPONPREFERENCES=19 5426 WEAPONPREFERENCES=20 6579 WEAPONPREFERENCES=21 8321 WEAPONPREFERENCES=22 5025 WEAPONPREFERENCES=23 7206 WEAPONPREFERENCES=24 6203 WEAPONPREFERENCES=25 6090 WEAPONPREFERENCES=26 6529 WEAPONPREFERENCES=27 9649 WEAPONPREFERENCES=28 5100 WEAPONPREFERENCES=29 8358 WEAPONPREFERENCES=30 6717 WEAPONPREFERENCES=31 8772 WEAPONPREFERENCES=32 5363 WEAPONPREFERENCES=33 5689 WEAPONPREFERENCES=34 7393 WEAPONPREFERENCES=35 5025 WEAPONPREFERENCES=36 9987 WEAPONPREFERENCES=37 8722 WEAPONPREFERENCES=38 6404 WEAPONPREFERENCES=39 5326 WEAPONPREFERENCES=40 6692 WEAPONPREFERENCES=41 7318 WEAPONPREFERENCES=42 5326 WEAPONPREFERENCES=43 9411 WEAPONPREFERENCES=44 1 WEAPONPREFERENCES=45 9474 WEAPONPREFERENCES=46 8133 WEAPONPREFERENCES=47 6704 WEAPONPREFERENCES=48 8659 WEAPONPREFERENCES=49 8734 WEAPONPREFERENCES=50 7118 WEAPONPREFERENCES=51 5226 WEAPONPREFERENCES=52 6429 WEAPONPREFERENCES=53 7130 WEAPONPREFERENCES=54 7419 WEAPONPREFERENCES=55 7619 WEAPONPREFERENCES=56 2765 WEAPONPREFERENCES=57 3686 WEAPONPREFERENCES=58 7500 WEAPONPREFERENCES=59 984 WEAPONPREFERENCES=60 999 WEAPONPREFERENCES=61 797 WEAPONPREFERENCES=62 923 WEAPONPREFERENCES=63 -2147483648 WEAPONPREFERENCES=64 -2147483648 WEAPONPREFERENCES=65 -2147483648 WEAPONPREFERENCES=66 -2147483648 WEAPONPREFERENCES=67 -2147483648 WEAPONPREFERENCES=68 -2147483648 WEAPONPREFERENCES=69 -2147483648 WEAPONPREFERENCES=70 -2147483648 WEAPONPREFERENCES=71 -2147483648 WEAPONPREFERENCES=72 -2147483648 WEAPONPREFERENCES=73 728 WEAPONPREFERENCES=74 1001 WEAPONPREFERENCES=75 773 WEAPONPREFERENCES=76 713 WEAPONPREFERENCES=77 0 WEAPONPREFERENCES=78 0 WEAPONPREFERENCES=79 1077 *** *PLAYER*
Bug#1008572: ITP: xgboost-predictor-java -- Java implementation of XGBoost predictor for online prediction tasks
Hi Pierre, The original C++/Python implementation xgboost is maintained by deep learning team: https://salsa.debian.org/deeplearning-team/xgboost I have assigned the whole debian science team with maintainer access (max role) to deep learning team. You may choose to maintain the package there if you like. This team is dedicated to hardware acceleration, machine learning, and deep learning. See debian...@lists.debian.org On Mon, 2022-03-28 at 21:36 +0200, Pierre Gruet wrote: > Package: wnpp > Severity: wishlist > Owner: Pierre Gruet > User: debian-scie...@lists.debian.org > Usertags: field..science > X-Debbugs-Cc: debian-de...@lists.debian.org, > debian-scie...@lists.debian.org > > * Package name : xgboost-predictor-java > Version : 0.3.1 > Upstream Author : KOMIYA Atsushi > * URL : > https://github.com/komiya-atsushi/xgboost-predictor-java > * License : Apache-2.0 > Programming Lang: Java > Description : Java implementation of XGBoost predictor for > online prediction tasks > > XGBoost is an optimized distributed gradient boosting library > designed to be > highly efficient, flexible and portable. It implements machine > learning > algorithms under the Gradient Boosting framework. XGBoost provides a > parallel > tree boosting (also known as GBDT, GBM) that solve many data science > problems > in a fast and accurate way. The same code runs on major distributed > environment (Kubernetes, Hadoop, SGE, MPI, Dask) and can solve > problems beyond > billions of examples. > > This is the Java implementation of XGBoost. Right now it is needed as > a > dependency of gatk, but it should be useful more broadly for > scientists or > people from machine learning. > It will be team-maintained in Debian Science team. >
Bug#1003653: Revision of removal of rename.ul from package util-linux
Re: Chris Hofstaedtler > > * which binary package should contain the util-linux rename? > >- bsdextrautils > >- something else > > util-linux-extra. Unrelatedly, other non-essential binaries from > util-linux should also move into this package, but this is only > tangentially related. Hi, I like that package name. > > * where should it be installed? > >- /usr/bin > >- something else? > > /usr/bin/rename > > * should there be a Conflicts or Breaks relation with the perl rename? > > I think this will be necessary. The problem here is that if ul-extra contains things besides rename, and it conflicts with the perl rename, people will rightfully complain that they can't install /usr/bin/fincore-from-ul-extra and /usr/bin/rename-from-perl at the same time. Or would you solve that using alternatives, without the conflicts? (Fwiw I believe the strict rule "alternatives only for compatible interfaces" doesn't apply here - we are looking for a workaround, and there is no rule saying that only hacks X, Y, Z must be used for these. If alternatives are the best tool for the job, it should be used.) Christoph
Bug#1006544: [Pkg-utopia-maintainers] Bug#1006544: firewall-cmd times out with large blocklists
I guess that firewalld is so slow to process 25000 entries is an issue on its own. That said I dunno if firewalld is to blame here or the kernel. Am 28.03.22 um 20:38 schrieb Felix Niederwanger: Hi Michael, I'm this week super busy and will try to get back to you as soon as I can. Might take till next week due to a planned travel trip. Best, Felix On Sat, 2022-03-26 at 09:25 +0100, Michael Biebl wrote: Am 27.02.22 um 11:56 schrieb Felix Niederwanger: Package: firewalld Version: 0.9.3-2 ... Find attached to this email my drop.xml list. I tested this bug in a fresh VM running Debian 10 with all installed updates. Debian 10 (i.e. oldstable aka buster) ships firewalld 0.6.3-5 Did you mean Debian 11 (i.e. stable aka bullseye)? OpenPGP_signature Description: OpenPGP digital signature
Bug#1007832: Acknowledgement (vulkan-tools: vulkaninfo,vkcube seg-faults on head-less cuda/gpu machine)
When checking for possible causes, I noticed that the framebuffer is now (in Debian11) associated with the first gpu. This seems wrong as this is a headless machine, and the nvidia-gpu's are used only as a computational accelerator for cuda workloads, and not for visualization. This is shown with the command lshw -C display which has this entry logical name: /dev/fb0 The full log is attached. When running Debian10, this entry is not shown, and vulkaninfo was working. Is there an (easy?) way to disable /dev/fb0 ? *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:05:00.0 logical name: /dev/fb0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom fb configuration: depth=32 driver=nvidia latency=0 mode=1024x768 visual=truecolor xres=1024 yres=768 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:27 memory:c400-c4ff memory:27fe000-27fefff memory:27ff000-27ff1ff ioport:b000(size=128) memory:c500-c507 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:06:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:27 memory:c200-c2ff memory:27fc000-27fcfff memory:27fd000-27fd1ff ioport:a000(size=128) memory:c300-c307 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:07:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:27 memory:c000-c0ff memory:27fa000-27fafff memory:27fb000-27fb1ff ioport:9000(size=128) memory:c100-c107 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:08:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:27 memory:be00-beff memory:27f8000-27f8fff memory:27f9000-27f91ff ioport:8000(size=128) memory:bf00-bf07 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:0b:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:29 memory:bc00-bcff memory:27f6000-27f6fff memory:27f7000-27f71ff ioport:7000(size=128) memory:bd00-bd07 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:0c:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:29 memory:ba00-baff memory:27f4000-27f4fff memory:27f5000-27f51ff ioport:6000(size=128) memory:bb00-bb07 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:0d:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:29 memory:b800-b8ff memory:27f2000-27f2fff memory:27f3000-27f31ff ioport:5000(size=128) memory:b900-b907 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:0e:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration:
Bug#1008481: Add SDL_IM_MODULE to fcitx4 and fcitx5
On 2022-03-28 21:27, Shengjing Zhu wrote: On Tue, Mar 29, 2022 at 3:05 AM Gunnar Hjalmarsson wrote: But with that said, I don't think it makes sense to spam the users' environment with duplicate variables. Upstream already makes use of the well established XMODIFIERS variable, and by parsing its value they would know whether fcitx(5) is used or not. So we may want to propose that to upstream rather than adding a new application specific variable. 1. I thought XMODIFIERS is for XIM (X Input Method). Not sure why sdl2 checks XMODIFIERS as well. 2. Changing sdl2 upstream takes too long to propagate. SDL_IM_MODULE appeared in sdl2 since 2016 https://github.com/libsdl-org/SDL/commit/808c75d1 User asks for this for Dota2 game, which seems hard to get sdl2 updated... Ok, I rest my case. :) As far as I'm concerned, please feel free to push the change to the repo. -- Gunnar
Bug#975505: packaging mathjax3 with Breaks mathjax2: How big of a problem?
Hi Mattia, Mattia Rizzolo writes: > On Sun, Mar 27, 2022 at 04:46:24PM -0400, Nicholas D Steeves wrote: >> Mattia, could Sigil's upstream be persuaded to switch to Mathjax3 before >> the freeze? Do you know of any other notable packages that this would >> cause problems for? Nothing LaTeX-related, I hope... > > Unfortunately, upstream tried last month, but unconvered plenty of > regressions compared to mathjax2, so this is not going to happen anytime > soon most likely. > See https://github.com/Sigil-Ebook/Sigil/issues/453 for the sigil side, > and https://github.com/mathjax/MathJax/issues/2836 for the bug the main > sigil developer opened against mathjax (even if bug said that most of > the reported bits are already fixed in PRs or such). > Thank you very much for the quick reply, Sigil upstream status, and references! Best, Nicholas signature.asc Description: PGP signature
Bug#975505: Please package v3.0.5 or newer
Hi! Yadd writes: > On 28/03/2022 15:06, Dmitry Shachnev wrote: >> On Mon, Mar 28, 2022 at 02:47:50PM +0200, Yadd wrote: Thank you very much for taking care of this. Yes, thank you Yadd! It's much appreciated work. But why conflicts/breaks? Does it have any file conflicts? I thought there should not be any. >>> >>> Yes we can change paths to avoid conflicts. >> >> Aren't the paths different on their own? >> >> In MathJax 2.x, most of the JS files are under one of these three >> directories: >> config, extensions, jax. It looks like MathJax 3.x does not have any of them. >> >> I was looking at these lists: >> >> https://archlinux.org/packages/community/any/mathjax2/files/ >> https://archlinux.org/packages/community/any/mathjax/files/ >> >>> Sadly I'm not able to build wicked-good-xpath for now >>> (mathjax3->speech-rule-engine->wicked-good-xpath): our closure-compiler >>> looks too old. >> >> It's not just old, it's ancient! The version number is 20130227+dfsg1... >> >> In MathJax v2 I simply disabled that stuff and even excluded it from the >> tarball: >> >> https://salsa.debian.org/js-team/mathjax/-/commit/4ace348cad6ac57c >> >> Maybe you can do the same? It's an accessibility feature so we can live >> without it for some time. > > Not so easy, sre is called in many places in code I've pinged #733586 (closure-compiler request for newer version). Hopefully one of the two maintainers will resume maintenance, but if not, then it's a salvaging candidate. Regards, Nicholas signature.asc Description: PGP signature
Bug#1008518: nmu: libxxf86vm_1:1.1.4-1+b2
On 2022-03-28 11:57:14, Paul Gevers wrote: > Hi Jordan, > > On 28-03-2022 10:20, Jordan Justen wrote: > > nmu libxxf86vm_1:1.1.4-1+b2 . ANY . unstable . -m "riscv64 arch is at > > 1:1.1.4-1 > > while others are at 1:1.1.4-1+b2" > > It may be obvious to you, but, so what? Why is that a problem and how > does rebuilding on all architectures solve that? I want to install libxxf86vm packages, such as libxxf86vm1:riscv64 on amd64. When I try to install it on amd64, apt wants to remove many amd64 packages. I think the difference of 1:1.1.4-1 vs 1:1.1.4-1+b2 might be the cause, but I will admit that I am not certain. As far as building "all architecures" is concerned, I don't know if this is required. If there was a way to only build riscv64 libxxf86vm 1:1.1.4-1+b2 to match the other architectures, then I think that would work as well. When I mentioned this issue on #debian-riscv, it was recommended that I "could `reportbug release.debian.org`, select binNMU to request a rebuild on all arches to get the issue fixed", which is what lead me to file this bug. The reportbug program only provided a single line comment, so I assumed I should keep the explanation short. I apologize if I didn't file the bug properly. -Jordan signature.asc Description: signature
Bug#1008572: ITP: xgboost-predictor-java -- Java implementation of XGBoost predictor for online prediction tasks
Package: wnpp Severity: wishlist Owner: Pierre Gruet User: debian-scie...@lists.debian.org Usertags: field..science X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: xgboost-predictor-java Version : 0.3.1 Upstream Author : KOMIYA Atsushi * URL : https://github.com/komiya-atsushi/xgboost-predictor-java * License : Apache-2.0 Programming Lang: Java Description : Java implementation of XGBoost predictor for online prediction tasks XGBoost is an optimized distributed gradient boosting library designed to be highly efficient, flexible and portable. It implements machine learning algorithms under the Gradient Boosting framework. XGBoost provides a parallel tree boosting (also known as GBDT, GBM) that solve many data science problems in a fast and accurate way. The same code runs on major distributed environment (Kubernetes, Hadoop, SGE, MPI, Dask) and can solve problems beyond billions of examples. This is the Java implementation of XGBoost. Right now it is needed as a dependency of gatk, but it should be useful more broadly for scientists or people from machine learning. It will be team-maintained in Debian Science team.
Bug#1008063: transition: nodejs
On Mon, Mar 28, 2022 at 04:59:58PM +0200, Jérémy Lal wrote: > > Yes, actually all packages depending on libnode-dev/sid now need to depend > on nodejs/sid, or else autopkgtest runs the tests against nodejs/testing, > and that fails. > I'll reupload them if that's all right. > > The other solution is to have /usr/bin/node12, /usr/bin/node14 and > /usr/bin/node > as an alternative link. Which is not going to happen for that transition. Isn't the actual bug that the Breaks of libnode83 against libnode72 does not cover the version in testing permitting obviously non-working combinations of packages, and the correct solution is to make the Breaks of libnode83 against libnode72 unversioned? libnode is not a standalone library but a way to embed into a specific nodejs version, is there a reason why libnode is a separate package and not part of the nodejs package with Provides: libnode83? Other ecosystems are doing it in a similar way, e.g. with perlapi-5.34.0 > Jérémy cu Adrian
Bug#1008571: python3-mediafile should not Depend on tox
Package: python3-mediafile Version: 0.8.1-1 Severity: normal Starting with 0.9.0-1, python3-mediafile started depending on tox. I guess a change in dh-python has made that dependency be added because there is an upstream metadata file having tox as a requirement. While it may be required for testing, I don't think it is a runtime dependency. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-11-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-mediafile depends on: ii python3 3.9.8-1 ii python3-mutagen 1.45.1-2 ii python3-six 1.16.0-3 python3-mediafile recommends no packages. python3-mediafile suggests no packages. -- no debconf information
Bug#1008481: Add SDL_IM_MODULE to fcitx4 and fcitx5
On Tue, Mar 29, 2022 at 3:05 AM Gunnar Hjalmarsson wrote: > > On 2022-03-28 08:28, Shengjing Zhu wrote: > > On Mon, Mar 28, 2022 at 11:37 AM Osamu Aoki wrote: > >> > >> Hi, > >> > >> These bugs seem somewhat similar: > >> > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990316 > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008481 > >> > > > > AFAICT, GLFW_IM_MODULE is different from SDL_IM_MODULE. > > > > I can't find GLFW_IM_MODULE in glfw code, it only appears in kitty's glfw > > fork. > > But SDL_IM_MODULE can be found in sdl2 code. > > > > Ref: > > https://github.com/libsdl-org/SDL/blob/120c76c8/src/core/linux/SDL_ime.c#L46-L49 > > Like Osamu I first thought: "This is similar to bug #990316". But I no > longer think that's the case. As regards Kitty, upstream intentionally > disables the IM support by default. This seems to be something else, and > AFAICT adding that variable would not contradict to anyone's intention. > > But with that said, I don't think it makes sense to spam the users' > environment with duplicate variables. Upstream already makes use of the > well established XMODIFIERS variable, and by parsing its value they > would know whether fcitx(5) is used or not. So we may want to propose > that to upstream rather than adding a new application specific variable. 1. I thought XMODIFIERS is for XIM (X Input Method). Not sure why sdl2 checks XMODIFIERS as well. 2. Changing sdl2 upstream takes too long to propagate. SDL_IM_MODULE appeared in sdl2 since 2016 https://github.com/libsdl-org/SDL/commit/808c75d1 User asks for this for Dota2 game, which seems hard to get sdl2 updated... -- Shengjing Zhu
Bug#733586: closure-compiler: new upstream version available
Control: unblock 886411 by -1 Hi Tony and Thomas, This package came to my attention via #975505, where it was noted that MathJax2 has had to disable functionality because of too ancient of a closure-compiler, and at this time it appears that MathJax3 will have to do the same. Closure-compiler is a candidate for salvaging: https://wiki.debian.org/PackageSalvaging https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging The ideal resolution would be for one of the listed Uploaders to resume maintenance of the package, but orphaning is of course also an option :-) Pirate Praveen writes: > Control: block 886411 by -1 > > On Sat, 20 Jan 2018 20:38:02 +0530 Pirate Praveen > wrote:> Being more familiar with nodejs packaging, I prefer to go back to >> google-closure-compiler-js. But if there is a newer closure-compiler, >> it'd make my work a lot easier. >> > > Hi Tony, > > Digging deeper, I found out even the javascript version is built using > java sources (using gwt). So I have to update the java sources even for > javascript version. Hope you are still interested in updating > closure-compiler and we can collaborate. Hi Pirate! I noticed that you were able to complete #886411 ITP: node-react using some other method (perhaps google-closure-compiler-js, or perhaps disabling functionality?), so I've unset the block relation. It seemed worthwhile keep you in the CC list in case you wanted to create a "switch to closure-compiler" bug, and block it with this one (#733586). Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1008481: Add SDL_IM_MODULE to fcitx4 and fcitx5
On 2022-03-28 08:28, Shengjing Zhu wrote: On Mon, Mar 28, 2022 at 11:37 AM Osamu Aoki wrote: Hi, These bugs seem somewhat similar: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990316 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008481 AFAICT, GLFW_IM_MODULE is different from SDL_IM_MODULE. I can't find GLFW_IM_MODULE in glfw code, it only appears in kitty's glfw fork. But SDL_IM_MODULE can be found in sdl2 code. Ref: https://github.com/libsdl-org/SDL/blob/120c76c8/src/core/linux/SDL_ime.c#L46-L49 Like Osamu I first thought: "This is similar to bug #990316". But I no longer think that's the case. As regards Kitty, upstream intentionally disables the IM support by default. This seems to be something else, and AFAICT adding that variable would not contradict to anyone's intention. But with that said, I don't think it makes sense to spam the users' environment with duplicate variables. Upstream already makes use of the well established XMODIFIERS variable, and by parsing its value they would know whether fcitx(5) is used or not. So we may want to propose that to upstream rather than adding a new application specific variable. -- Cheers, Gunnar
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi Chris, On Mon, Mar 28, 2022 at 07:58:11PM +0200, Chris Hofstaedtler wrote: > I would like to ask a question: under which constitution point will > the CTTE act? Given your reply, I believe that no 6.1.1-4 decision is necessary. The views of the submitter seem sufficiently covered in what you described. I do not think there is a need to codify 6.1.5 advice either. It seems that what happened was mediation. If a resolution is deemed necessary, I'd propose "we decline to overrule the maintainer" with a rationale. We'll likely figure that out on our next meeting in 8 days. On the other hand, I'd like you to commit to including the util-linux rename binary in time for the bookworm release (assuming NEW is processed in a reasonable time). That likely implies that it needs to be uploaded within 2022. Preferrably sooner. Can you confirm that? Helmut
Bug#1008518: nmu: libxxf86vm_1:1.1.4-1+b2
Hi Jordan, On 28-03-2022 10:20, Jordan Justen wrote: nmu libxxf86vm_1:1.1.4-1+b2 . ANY . unstable . -m "riscv64 arch is at 1:1.1.4-1 while others are at 1:1.1.4-1+b2" It may be obvious to you, but, so what? Why is that a problem and how does rebuilding on all architectures solve that? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1008570: src:python-fluids: fails to migrate to testing for too long: unresolved RC issues and blocked by numba
Source: python-fluids Version: 0.1.78-3 Severity: serious Control: close -1 1.0.9-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:python-fluids has been trying to migrate for 61 days [2]. Hence, I am filing this bug. The new version of your package has multiple RC issues and it's blocked by the new dependency of numba (which isn't python3.10 ready yet). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=python-fluids OpenPGP_signature Description: OpenPGP digital signature
Bug#1007259: closed by Debian FTP Masters (reply to Ricardo Mones ) (Bug#1007259: fixed in claws-mail 4.0.0-3)
On Wed, Mar 23, 2022 at 01:05:17AM +0200, Shai Berger wrote: > Yay! Thanks a bunch! My pleasure! -- Ricardo Mones ~ Absence of evidence is not evidence of absence. Carl Sagan
Bug#1008569: ITS: unar
Package: unar Version: 1.10.1-2 Severity: important X-Debbugs-CC: kr...@debian.org as...@debian.org jul...@debian.org Dear package unar maintainers in Debian, After looking into the package you maintain (unar, https://tracker.debian.org/pkg/unar), I found that this package received no maintainer updates in the past 5 years and was not in good shape. As a result, I am filing an ITS (Intent to Salvage) request against your package according to section 5.12 in Debian's Developers' Reference [1]. My current plan is to package the latest upstream release (1.10.7), clean up packaging and orphan this package to allow possible external contribution. Please let me know whether any of you is still willing to maintain this package. According to the criteria listed at [2], I will upload a Non- maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days (April 18, 2022) to continue with the package salvaging. If you find it necessary to pause the ITS process, please let me know immediately by replying this bug report. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://wiki.debian.org/PackageSalvaging -- Best Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1008568: ITP: r-bioc-annotationforge -- Tools for building SQLite-based annotation data packages
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-annotationforge -- Tools for building SQLite-based annotation data packages Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: r-bioc-annotationforge Version : 1.36.0 Upstream Author : Marc Carlson, Hervé Pagès * URL : https://bioconductor.org/packages/AnnotationForge/ * License : Artistic-2.0 Programming Lang: GNU R Description : Tools for building SQLite-based annotation data packages Provides code for generating Annotation packages and their databases. Packages produced are intended to be used with AnnotationDbi. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-annotationforge
Bug#1006998: Update: Compilation now works with kernel 4.19.235-1
Package: linux-source-4.19 Version: 4.19.235-1 Debian 10 was updated to 10.12 on March 26. The kernel version was updated to 4.19.235-1. Compilation now works without error. I tried to find any diffs between kernel 4.19.232-1 and 4.19.235-1 in the include path in my original bug report, but couldn't find any relevant differences. Bug report can be closed; but the cause itself is still unclear to me.
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi Helmut, * Helmut Grohne [220208 21:23]: > Hi Chris, > > On Sun, Jan 23, 2022 at 10:04:34PM +0100, Chris Hofstaedtler wrote: > > I was hoping we could put util-linux' rename into the > > "bsdextrautils" binary package, which has utilities like write, col, > > etc; to avoid putting it into an Essentials: yes package, and to > > avoid a new binary package. However, picking bsdextrautils seems > > ... maybe not ideal if it should Conflict with rename. > > > > I guess the best thing would be to introduce a new binary package, > > but I am out of ideas on naming it. Open for ideas here. > > This paragraph can be vaguely interpreted as an intention to put the > util-linux rename implementation back into some binary package under > some path. Doing so would go a significant way towards what the > submitter of the ctte bug wants. > > We've discussed a number of possible ways to put it back (various > packages, various paths, with or without update-alternatives, with or > without Conflicts). From what you said, I understand that: > * You disagree with putting it in some transitively essential package. > * You think that Debian should make a choice about the rename API and >stick to that. > * You take issue with "rename.ul" as a program name, because it is >inconsistent with other Linux distributions. > * You agree on shipping the util-linux rename executable (with >unspecified filename at this stage) in some Debian binary package in >principle. > > Do you confirm these statements? Yes. I would like to say that my point of view would be "if we change something, lets do the right thing going forward". If we need to break with the past, lets do it now instead of delaying further. > Given these, we think that much of the issue can be resolved > cooperatively. To get there we (as ctte) ask you to explain how you > prefer adding the util-linux rename executable as precisely as you see > it at this stage. > > In your option, > * which binary package should contain the util-linux rename? >- bsdextrautils >- something else util-linux-extra. Unrelatedly, other non-essential binaries from util-linux should also move into this package, but this is only tangentially related. > * how should it be named? >- rename >- rename.ul >- something else > * where should it be installed? >- /usr/bin >- something else? /usr/bin/rename > * should it be managed with update-alternatives? No. My understanding is this would be a bug. Also, I subscribe to the idea that (pseudo-)essential packages should not use the update-alternatives mechanism. This last point might be easier with util-linux-extra. > * should there be a Conflicts or Breaks relation with the perl rename? I think this will be necessary. > If you feel unable to answer any of these, please say so. > > Thank you for taking the time to participate in this discussion. I would like to ask a question: under which constitution point will the CTTE act? > Helmut BR, Chris signature.asc Description: PGP signature
Bug#1006836: transition: python3.10 as default
Hi Markus On Mon, 28 Mar 2022 at 17:30, Markus Blatt wrote: > I just took a look at the tracker and noticed that opm-common is level 3 and > opm-simulators is level 2. If build attempts for level 3 come after level 2 > that migth explain the failure in the logs [1] and opm-common should be in a > level before opm-simulators. If opm-common should be in a level before opm-simulators, then I think opm-simulators needs a Build-Depends on one of opm-common's binary packages. This should help Ben figure out the dependency levels for future transitions. > If there is anything that I need to do on my side as a maintainer then please > let me know. I don't think anything is needed right now, thanks. I will schedule a rebuild of opm-common once graphviz has built, and then retry opm-simulators. Regards Graham
Bug#1008265: CVE-2018-25032: zlib memory corruption on deflate
Hi Mark, On Sat, Mar 26, 2022 at 09:02:31AM +0100, Salvatore Bonaccorso wrote: > Hi Mark, > > On Sat, Mar 26, 2022 at 12:59:15AM +, Mark Brown wrote: > > On Fri, Mar 25, 2022 at 10:50:51PM +0100, Salvatore Bonaccorso wrote: > > > > > Here is a preliminary debdiff to address this. > > > > Thanks, that's roughly what I uploaded - it looks like your mail > > raced with my own update. > > Thanks a lot! We should probably fix the issue as well in stable and > oldstable, but it might be wise to give it a bit of expsure now in > unstable. So TTBOMK no problems were reported back the upload, so I uploaded similar update for buster-security and bullseye-security to security-master. We should be able to release a DSA soonish. Regards, Salvatore
Bug#1008275: libsane: Reinstate libieee1284 support for parallel printers
Hi, Cool. Thank you. :D Cheers, Ralph
Bug#1008567: ipset fails to lookup service name if it is not listed as tcp in /etc/services
Package: ipset Version: 7.10-1 Severity: normal Dear Maintainer, When attempting to use a port name in ipset add, a number of them failed with ipset v7.10: Syntax error: 'bootpc' is invalid as number This seems to be because bootpc is only listed as a udp service in /etc/services. For any service listed as tcp, or both, ipset works as expected. Adding bootpc as a tcp service to /etc/services fixes the situation. Ipset should attempt to lookup the name as both tcp and udp, or /etc/services should return to listing all services as both tcp and udp.. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.103-v8+ (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_CA, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages ipset depends on: ii libc6 2.31-13+rpt2+rpi1+deb11u2 ii libipset13 7.10-1 Versions of packages ipset recommends: ii iptables 1.8.7-1 ipset suggests no packages. -- no debconf information
Bug#1008566: ITP: xrt -- XRay Tracer and wave propagation
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: xrt Version : 1.4.0-1 Upstream Author : Konstantin Klementiev * URL : https://github.com/kklmn/xrt * License : Expat Programming Lang: Python Description : XRay Tracer and wave propagation XRayTracer is a python software library for ray tracing and wave propagation in x-ray regime. It is primarily meant for modeling synchrotron sources, beamlines and beamline elements. Includes a GUI for creating a beamline and interactively viewing it in 3D. This package will be maintained as part of the PaN team and Debian Science Team.
Bug#1008565: ITP: r-bioc-kegg.db -- A set of annotation maps for KEGG
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-kegg.db -- A set of annotation maps for KEGG Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: r-bioc-kegg.db Version : 3.2.3 Upstream Author : Marc Carlson * URL : https://bioconductor.org/packages/KEGG.db/ * License : academic-use-only Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : A set of annotation maps for KEGG A set of annotation maps for KEGG assembled using data from KEGG . This package is deprecated in BioConductor and should not be used in new projects. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-kegg.db
Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy
Hi Alexandre, On 2022-03-23 16:33, Alexandre Rossi wrote: > Seems to work: > > $ ls -la /usr/share/java/htmlcleaner* > lrwxrwxrwx 1 root root 15 18 mars 18:20 > /usr/share/java/htmlcleaner-2.26.jar -> htmlcleaner.jar > -rw-r--r-- 1 root root 176219 18 mars 18:20 /usr/share/java/htmlcleaner.jar > $ sudo dpkg -i > oss/debian/davmail/libhtmlcleaner-java_2.26-1+fix+bad+jar+name+1_all.deb > [...] > $ ls -la /usr/share/java/htmlcleaner* > -rw-r--r-- 1 root root 176219 23 mars 15:27 > /usr/share/java/htmlcleaner-2.26.jar > lrwxrwxrwx 1 root root 20 23 mars 15:27 > /usr/share/java/htmlcleaner.jar -> htmlcleaner-2.26.jar Many thanks for the proposed patch. It seems we need a decision now on which one is actually buggy: maven-debian-helper or java-policy. I would vote for upholding the java-policy if only the symlink placement switch does not break anything (neither reverse dependencies not the update mechanism). Having versionless symlinks parallels nicely lib*-dev shlib scheme and there might be situations where this is beneficial for Java too. Unluckily enough, there are >700 source packages now directly affected by this [1]. [1] https://lintian.debian.org/tags/bad-jar-name Best, Andrius
Bug#1008275: libsane: Reinstate libieee1284 support for parallel printers
Hello Ralph, Am Sonntag, dem 27.03.2022 um 21:14 -0700 schrieb Ralph Little: > Hi, > > On 2022-03-26 16:37, Gunnar Hjalmarsson wrote: > > Control: reopen -1 > > > > Hi Jörg, > > > > Jörg Frings-Fürst wrote: > > > [quote] > > > ifeq (,$(filter hurd-i386,$(DEB_HOST_ARCH))) > > > INS_CONF = --enable-parport-directio > > > else > > > INS_CONF = "" > > > endif > > > [/quote] > > > > > > and > > > > > > [quote] > > > --disable-locking \ > > > $(INS_CONF) > > > [/quote] > > > > > > --enable-parport-directio thus only becomes active in the hurd- > > > i386 > > > architecture. > > > > No. It's the other way around, i.e. it becomes active in all > > architectures except hurd-i386. ;) > > > > Reopening so you can take a stand on that ground. > > > > I tried the logic here just to make sure I understood what was going > on > here: > > ---makefile- > ifeq (,$(filter hurd-i386,$(DEB_HOST_ARCH))) > INS_CONF = --enable-parport-directio > else > INS_CONF = "" > endif > > test: makefile > echo $(INS_CONF) > > > > $ DEB_HOST_ARCH=hurd-i386 make -n -f makefile > echo "" > $ DEB_HOST_ARCH=arm64 make -n -f makefile > echo --enable-parport-directio > > The logic really does seem to be reversed, such that > --enable-parport_directio is enabled for every arch except hurd. > > What is strange though is that if I disable the sane-git PPA to use > 1.0.27 from Ubuntu standard repo, I get this: > > [sanei_debug] Setting debug level of plustek_pp to 50. > [sanei_debug] Setting debug level of sanei_pp to 50. > [sanei_pp] pp_init: called for the first time > [sanei_pp] pp_init: initializing libieee1284 > [sanei_pp] pp_init: 1 ports reported by IEEE 1284 library > [sanei_pp] pp_init: port 0 is `parport0` > [sanei_pp] pp_init: initialized successfully > > So it really is using libieee1284 in this case. > So I'm pretty confused. > Has this build code changed recently? > Sorry, that's my mistake. My text describes the correct function, but the code is wrong. The code was corrected in version 1.1.1-5. So I close this bug. > Cheers, > Ralph CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Skype: joergpenguin Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#1008275: libsane: Reinstate libieee1284 support for parallel printers
Hi Gunnar, Am Sonntag, dem 27.03.2022 um 00:37 +0100 schrieb Gunnar Hjalmarsson: > Control: reopen -1 > > Hi Jörg, > > Jörg Frings-Fürst wrote: > > [quote] > > ifeq (,$(filter hurd-i386,$(DEB_HOST_ARCH))) > > INS_CONF = --enable-parport-directio > > else > > INS_CONF = "" > > endif > > [/quote] > > > > and > > > > [quote] > > --disable-locking \ > > $(INS_CONF) > > [/quote] > > > > --enable-parport-directio thus only becomes active in the hurd-i386 > > architecture. > > No. It's the other way around, i.e. it becomes active in all > architectures except hurd-i386. ;) > > Reopening so you can take a stand on that ground. > Sorry, that's my mistake. My text describes the correct function, but the code is wrong. The bug was fixed in version 1.1.1-5 with bug #1008488 for all architectures except hurd-i386. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Skype: joergpenguin Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#1003292: Unpassworded superuser account now causes errors in log
On Thu, 24 Mar 2022, Michael Banck wrote I had reported that problem here and it got fixed in 2.1.3: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzalando%2Fpatroni%2Fissues%2F2162data=04%7C01%7Cbjh21%40universityofcambridgecloud.onmicrosoft.com%7C9e6d230170b542905a4a08da0d9cf315%7C49a50445bdfa4b79ade3547b4f3986e9%7C0%7C0%7C637837264988923002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=TTrqAXz6csCVvQJgukeP2%2B3DwarS5V%2B9ApPJBUHxqVw%3Dreserved=0 Let me know if you still see this problem. I can confirm that having upgraded to 2.1.3-1.pgdg20.04+1 and removed the superuser password, I'm no longer seeing errors in the system log. Thank you! -- Ben Harris, University of Cambridge Information Services.
Bug#1008564: Assumes /usr/games/polygen is in $PATH; not true for root
Package: cappuccino Version: 0.5.1-9.1 Severity: minor Because there is no .desktop file, and my test desktop is built without a terminal emulator, I tried running cappuccino as root: bash$ ssh root@bootstrap2020 'DISPLAY=:0 XAUTHORITY=$(echo /var/lib/xdm/authdir/authfiles/*)' cappuccino Warning: Permanently added '[localhost]:2022' (ED25519) to the list of known hosts. __main__.py:148: PyGIDeprecationWarning: GObject.timeout_add is deprecated; use GLib.timeout_add instead /bin/sh: 1: polygen: not found __main__.py:72: DeprecationWarning: Gtk.Alignment.set is deprecated /bin/sh: 1: polygen: not found __main__.py:84: PyGIDeprecationWarning: GObject.timeout_add is deprecated; use GLib.timeout_add instead __main__.py:85: PyGIDeprecationWarning: GObject.timeout_add is deprecated; use GLib.timeout_add instead /bin/sh: 1: polygen: not found Traceback (most recent call last): File "__main__.py", line 107, in update_log IndexError: pop from empty list /bin/sh: 1: polygen: not found This is happening because /usr/games/polygen is not in the default $PATH unless you 1) log in as a non-root user; and 2) pass through PAM session. In the above case, neither (1) nor (2) happens. For (2) it does not happen because "ssh host command" bypasses the login shell. These situations are unlikely to occur, but given the failure behaviour is pretty weird, I think simply hard-coding the default path to "/usr/games/polygen" instead of "polygen" would suffice. The manpage didn't suggest any CLI option to easily work around this. PS: note that cappuccino itself is NOT installed in /usr/games/. Moving it there would, I guess, be an equally easy fix. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
Bug#1008563: gscan2pdf hangs after stopping a job halfway
Package: gscan2pdf Version: 2.12.5 Current situation: When I start an action and I stop it halfway gscan2pdf sometimes hangs for it seams no reason and when it doesn't I am able to refert to the previous state of the pages but any next action makes gscan2pdf hang. So in both cases I need to kill the application and start over. Expect: Stop any job halfway. Move back to to the previous state. Start a new action.
Bug#1008562: gnome-shell-extension-weather: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-weather Version: 0.0~git20210509.d714eb1-2 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://gitlab.com/jenslody/gnome-shell-extension-openweather/-/merge_requests/251 The metadata.json for this extension doesn't declare compatibility with GNOME 42. According to upstream git, no actual code changes are needed (not verified, so please test). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008561: gnome-shell-extension-volume-mixer: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-volume-mixer Version: 41.1+dfsg-1 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension doesn't declare compatibility with GNOME 42. I don't know whether actual code changes will be necessary. gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008560: gnome-shell-extension-vertical-overview: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-vertical-overview Version: 8-2 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/RensAlthuis/vertical-overview/issues/98 The metadata.json for this extension doesn't declare compatibility with GNOME 42, and from the upstream issue tracker it looks like real code changes will be needed. gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008559: gnome-shell-extension-top-icons-plus: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-top-icons-plus Version: 27-6 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension doesn't declare compatibility with GNOME 42. I don't know whether actual code changes will be necessary. gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008558: gnome-shell-extension-tiling-assistant: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-tiling-assistant Version: 32-1 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/Leleat/Tiling-Assistant/issues/144 The metadata.json for this extension doesn't declare compatibility with GNOME 42, and from the upstream issue tracker it looks like real code changes will be needed. gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008557: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-system-monitor Version: 40-3 Severity: normal Tags: bookworm sid fixed-upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/paradoxxxzero/gnome-shell-system-monitor-applet/pull/736 The metadata.json for this extension doesn't declare compatibility with GNOME 42. According to upstream git, no actual code changes are needed (not verified, so please test). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. In versions of GNOME Shell up to 3.38, metadata.json didn't matter much, because validation of extensions' metadata against the installed Shell version was disabled by default; but since GNOME 40 the default has changed back to enabling the version check by default, in an effort to avoid issues caused by outdated extensions remaining enabled. As a result, GNOME Shell extensions in bookworm should probably have a dependency like: Depends: gnome-shell (>= x), gnome-shell (<< y~) where x and y are set according to metadata.json. gnome-shell-extension-caffeine is a good example of this technique. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008175: closed by Brian Potkin (Re: Bug#1008175: -o sides=two-sided-long-edge always prints one-sided with lp & lpr)
One additional thing I did not check is the firmware for the printer to see if any updates. Will check this first then will get back to you. My script is for creating a .pdf file from a C source file and auto printing it duplex, then deleting the file,, so yes, this is important for me. Thank you! Cheers! Rick -- Rick Stanley (917) 822-7771 www.rsiny.com Computer Consulting Linux & Open Source Specialist On Mar 28, 2022, 11:09 AM, at 11:09 AM, Debian Bug Tracking System wrote: >This is an automatic notification regarding your Bug report >which was filed against the cups-bsd package: > >#1008175: "-o sides=two-sided-long-edge always prints one-sided with lp >& lpr" > >It has been closed by Brian Potkin . > >Their explanation is attached below along with your original report. >If this explanation is unsatisfactory and you have not received a >better one in a separate message then please contact Brian Potkin > by >replying to this email. > > >-- >1008175: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008175 >Debian Bug Tracking System >Contact ow...@bugs.debian.org with problems > > > > >From: Brian Potkin >To: 1008175-d...@bugs.debian.org >Sent: Mon Mar 28 11:08:22 EDT 2022 >Subject: Re: Bug#1008175: -o sides=two-sided-long-edge always prints >one-sided with lp & lpr > >On Mon 28 Mar 2022 at 06:10:37 -0500, r...@scotsgeek.com wrote: > >> Thanks! Please see the attached. >> >> As regular user: >> ipptool -tv >> "ipps://HP%20LaserJet%20Pro%20M148fdw%20(6CA573)._ipps._tcp.local/" >> get-printer-attributes.test > attributes.txt > >Thank you, Rick. > >All the information you gave has helped upstream to come to the >decision that the issue is a firmware bug. Debian has nowhere to >go with this so I am closing the report. Sorry it did not work >out. > >If using lp/lpr is still something you would like to do, I can >guide you through setting up another print queue that should work. > >Cheers, > >Brian. > > > >From: Rick Stanley >To: Debian Bug Tracking System >Sent: Wed Mar 23 12:33:24 EDT 2022 >Subject: cups-bsd: lp & lpr options sides=one-sided and >sides=two-sided-long-edge are reversed. one-sided prints duplex >(Two-sided) and vice-versa > >Package: cups-bsd >Version: 2.3.3op2-3+deb11u1 >Severity: normal >X-Debbugs-Cc: r...@scotsgeek.com > >Dear Maintainer, > >*** Reporter, please consider answering these questions, where >appropriate *** > > * What led up to the situation? >My script containing "lpr -o sides=two-sided-long-edge test.pdf" that >used to work now does not. The same for lp > * What exactly did you do (or not do) that was effective (or > ineffective)? > had to temporarily use the oposite option > * What was the outcome of this action? > Using sides=one-sided prints duplex as I need > * What outcome did you expect instead? > should have been able to use sides=two-sided-long-edge as it should! > >*** End of the template - remove these template lines *** > > >-- System Information: >Debian Release: 11.2 > APT prefers stable-updates >APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, >'stable') >Architecture: amd64 (x86_64) > >Kernel: Linux 5.10.0-12-amd64 (SMP w/4 CPU threads) >Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), >LANGUAGE not set >Shell: /bin/sh linked to /usr/bin/dash >Init: systemd (via /run/systemd/system) >LSM: AppArmor: enabled > >Versions of packages cups-bsd depends on: >ii cups-client2.3.3op2-3+deb11u1 >ii cups-common2.3.3op2-3+deb11u1 >ii debconf [debconf-2.0] 1.5.77 >ii libc6 2.31-13+deb11u2 >ii libcups2 2.3.3op2-3+deb11u1 > >cups-bsd recommends no packages. > >Versions of packages cups-bsd suggests: >ii cups2.3.3op2-3+deb11u1 >pn inetutils-inetd | inet-superserver >ii update-inetd4.51 > >-- debconf information: > cups-bsd/setuplpd: false
Bug#1008556: gnome-shell-extension-sound-device-chooser: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-sound-device-chooser Version: 11-2 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/kgshank/gse-sound-output-device-chooser/issues/229 The metadata.json for this extension doesn't declare compatibility with GNOME 42, and from the upstream issue tracker it looks like real code changes will be needed. gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008554: gnome-shell-extension-pixelsaver: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-pixelsaver Version: 1.28-1 Severity: normal Tags: bookworm sid User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension declares compatibility with GNOME 42, but in debian/control it still Depends: gnome-shell (<< 42). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008555: gnome-shell-extension-shortcuts: please depend on gnome-shell (<< next major version)
Package: gnome-shell-extension-shortcuts Version: 1.3.2-1 Severity: minor To keep better track of which extensions have and haven't been updated for each new GNOME version, it would be useful if this extension had a dependency of the form gnome-shell (>= x), gnome-shell (<< y) where x is the oldest version in metadata.json, and y is the next major version after the newest version in metadata.json (at the moment y = 43). See g-s-e-caffeine for an example of this setup. Thanks, smcv
Bug#1008552: gnome-shell-extension-kimpanel: should presumably depend on gnome-shell
Package: gnome-shell-extension-kimpanel Version: 0.0~git20220324.4502fe5-1 Severity: normal gnome-shell-extension-kimpanel is an extension for GNOME Shell, but doesn't depend on the gnome-shell package, which seems likely to be wrong. To keep better track of which extensions have and haven't been updated for each new GNOME version, the recommended form of the dependency is: gnome-shell (>= x), gnome-shell (<< y) where x is the oldest version in metadata.json, and y is the next major version after the newest version in metadata.json (at the moment y = 43). See g-s-e-caffeine for an example of this setup. Thanks, smcv
Bug#1006836: transition: python3.10 as default
Hi, I just took a look at the tracker and noticed that opm-common is level 3 and opm-simulators is level 2. If build attempts for level 3 come after level 2 that migth explain the failure in the logs [1] and opm-common should be in a level before opm-simulators. If there is anything that I need to do on my side as a maintainer then please let me know. Cheers, Markus [1] https://buildd.debian.org/status/fetch.php?pkg=opm-simulators=amd64=2021.10-4%2Bb1=1648476056=0
Bug#1008551: gnome-shell-extension-impatience: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-impatience Version: 0.4.6-1 Severity: normal Tags: bookworm sid fixed-upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/timbertson/gnome-shell-impatience/pull/29 The metadata.json for this extension doesn't declare compatibility with GNOME 42. According to the upstream pull request, no actual code changes are necessary (I haven't tested it myself). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. To keep better track of which extensions have and haven't been updated for each new GNOME version, it would be useful if this extension had a dependency of the form gnome-shell (>= x), gnome-shell (<< y) where x is the oldest version in metadata.json, and y is the next major version after the newest version in metadata.json (at the moment y = 43). See g-s-e-caffeine for an example of this setup. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008550: gnome-shell-extension-hide-activities: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-hide-activities Version: 41-1 Severity: normal Tags: bookworm sid fixed-upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/zeten30/HideActivities/pull/5 The metadata.json for this extension doesn't declare compatibility with GNOME 42. According to the upstream pull request, no actual code changes are necessary (I haven't tested it myself). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. To keep better track of which extensions have and haven't been updated for each new GNOME version, it would be useful if this extension had a dependency of the form gnome-shell (>= x), gnome-shell (<< y) where x is the oldest version in metadata.json, and y is the next major version after the newest version in metadata.json (at the moment y = 43). See g-s-e-caffeine for an example of this setup. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008549: gnome-shell-extension-hamster: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-hamster Version: 0.10.0+git20210628-2 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/projecthamster/hamster-shell-extension/pull/349 The metadata.json for this extension doesn't declare compatibility with GNOME 42. According to the upstream pull request, no actual code changes are necessary (but I haven't tested it). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008548: gnome-shell-extension-gamemode: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-gamemode Version: 6-1 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/gicmo/gamemode-extension/issues/52 The metadata.json for this extension doesn't declare compatibility with GNOME 42. I don't know whether actual code changes will be necessary. gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. To keep better track of which extensions have and haven't been updated for each new GNOME version, it would be useful if this extension had a dependency of the form gnome-shell (>= x), gnome-shell (<< y) where x is the oldest version in metadata.json, and y is the next major version after the newest version in metadata.json (at the moment y = 43). See g-s-e-caffeine for an example of this setup. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008547: gnome-shell-extension-freon: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-freon Version: 45+dfsg-1 Severity: normal Tags: bookworm sid fixed-upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension doesn't declare compatibility with GNOME 42. This seems to have been fixed in upstream git (not tested). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. To keep better track of which extensions have and haven't been updated for each new GNOME version, it would be useful if this extension had a dependency of the form gnome-shell (>= x), gnome-shell (<< y) where x is the oldest version in metadata.json, and y is the next major version after the newest version in metadata.json (at the moment y = 43). See g-s-e-caffeine for an example of this setup. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008546: gnome-shell-extension-easyscreencast: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-easyscreencast Version: 1.5.0-1 Severity: normal Tags: bookworm sid User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension doesn't declare compatibility with GNOME 42. I don't know whether the actual code will need changes or not: the conservative assumption is that it probably will (so please test). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. In versions of GNOME Shell up to 3.38, metadata.json didn't matter much, because validation of extensions' metadata against the installed Shell version was disabled by default; but since GNOME 40 the default has changed back to enabling the version check by default, in an effort to avoid issues caused by outdated extensions remaining enabled. As a result, GNOME Shell extensions in bookworm should probably have a dependency like: Depends: gnome-shell (>= x), gnome-shell (<< y~) where x and y are set according to metadata.json. gnome-shell-extension-caffeine is a good example of this technique. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008545: RM: gnome-shell-extension-desktop-icons -- ROM; incompatible with current GNOME Shell, no progress seen on porting
Package: ftp.debian.org Severity: normal We're about to upgrade to gnome-shell 42 in unstable, and gnome-shell-extension-desktop-icons still hasn't been updated to be compatible with gnome-shell 41, so it seems like time to remove it from unstable. The closest replacement is gnome-shell-extension-desktop-icons-ng, but a transitional package would not be useful here, because each extension needs to be enabled separately on a per-user basis (behind the scenes, GNOME Shell configuration has a list of enabled extension UUIDs), meaning that users of g-s-e-desktop-icons need manual action to switch to g-s-e-desktop-icons-ng in any case. This removal request is on behalf of the GNOME team, acked by jbicha (in the extension's Uploaders) on IRC. Thanks, smcv
Bug#1008544: gnome-shell-extension-draw-on-your-screen: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-draw-on-your-screen Version: 11-2 Severity: normal Tags: bookworm sid User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension doesn't declare compatibility with GNOME 42. I don't know whether the actual code will need changes or not: the conservative assumption is that it probably will (so please test). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. In versions of GNOME Shell up to 3.38, metadata.json didn't matter much, because validation of extensions' metadata against the installed Shell version was disabled by default; but since GNOME 40 the default has changed back to enabling the version check by default, in an effort to avoid issues caused by outdated extensions remaining enabled. As a result, GNOME Shell extensions in bookworm should probably have a dependency like: Depends: gnome-shell (>= x), gnome-shell (<< y~) where x and y are set according to metadata.json. gnome-shell-extension-caffeine is a good example of this technique. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008543: gnome-shell-extension-disconnect-wifi: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-disconnect-wifi Version: 29-1 Severity: normal Tags: bookworm sid fixed-upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension doesn't declare compatibility with GNOME 42. This seems to have been fixed in upstream git (not tested). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008542: gnome-shell-extension-desktop-icons-ng: please depend on gnome-shell (<< next major version)
Package: gnome-shell-extension-desktop-icons-ng Version: 43-1 Severity: minor To keep better track of which extensions have and haven't been updated for each new GNOME version, it would be useful if this extension had a dependency of the form gnome-shell (>= x), gnome-shell (<< y) where x is the oldest version in metadata.json, and y is the next major version after the newest version in metadata.json (at the moment y = 43). See g-s-e-caffeine for an example of this setup. Thanks, smcv
Bug#1008063: transition: nodejs
On Mon, Mar 28, 2022 at 4:19 PM Sebastian Ramacher wrote: > On 2022-03-22 20:06:50, Jérémy Lal wrote: > > On Mon, Mar 21, 2022 at 10:42 PM Sebastian Ramacher < > sramac...@debian.org> > > wrote: > > > > > Control: tags -1 confirmed > > > > > > On 2022-03-21 18:54:38 +0100, Jérémy Lal wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: transition > > > > X-Debbugs-Cc: Debian Javascript Maintainers < > > > pkg-javascript-de...@lists.alioth.debian.org> > > > > > > > > Hi, > > > > > > > > this transition correspond to a nodejs 12 -> 14 major major bump. > > > > > > > > I carefully checked (twice, actually) that all build-dependencies of > > > > - libnode-dev (arch-dependent) > > > > - nodejs (arch-independent) > > > > can be rebuilt using latest libnode-dev / nodejs, though of course > > > > only the arch-dependent ones are concerned by this transition. > > > > > > Please go ahead > > > > > > We just just finished fixing some issues > > with nodejs_16.13.2+really14.19.1~dfsg-5: > > - test issues > > - missing important files for typescript-dependent modules > > > > Also i just uploaded a fix for > > node-modern-syslog > > > > node-opencv is known to fail and might be fixed, but it will be removed > if > > not. > > The remaining blockers are some autopkgtest regressions: > > ∙ ∙ autopkgtest for node-expat/2.4.0+ds-1: amd64: Regression ♻ > (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ > (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ > (reference ♻) > ∙ ∙ autopkgtest for node-iconv/3.0.1+~3.0.0-1: amd64: Regression ♻ > (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ > (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ > (reference ♻) > ∙ ∙ autopkgtest for node-jest/27.5.1~ds+~cs69.51.22-4: amd64: Regression > ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ > (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Not a > regression > ∙ ∙ autopkgtest for node-modern-syslog/1.2.0-2: amd64: Regression ♻ > (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ > (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ > (reference ♻) > ∙ ∙ autopkgtest for node-node-forge/1.2.1~dfsg-2: ppc64el: No test > results > ∙ ∙ autopkgtest for node-node-sass/7.0.1+git20211229.3bb51da+dfsg-1: > amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), > armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), > ppc64el: Regression ♻ (reference ♻) > ∙ ∙ autopkgtest for node-npmrc/1.1.1-2: amd64: Regression ♻ (reference > ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference > ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference > ♻) > ∙ ∙ autopkgtest for node-re2/1.17.4+~cs2.13.8-1: amd64: Regression ♻ > (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ > (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ > (reference ♻) > ∙ ∙ autopkgtest for node-sqlite3/5.0.2+ds1-3: amd64: Regression ♻ > (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ > (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ > (reference ♻) > ∙ ∙ autopkgtest for node-ts-jest/27.1.3+~cs0.2.6-2: ppc64el: Pass > ∙ ∙ autopkgtest for node-websocket/1.0.34+~cs10.0.25-1: amd64: > Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: > Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: > Regression ♻ (reference ♻) > > Could you please have a look at them? > Yes, actually all packages depending on libnode-dev/sid now need to depend on nodejs/sid, or else autopkgtest runs the tests against nodejs/testing, and that fails. I'll reupload them if that's all right. The other solution is to have /usr/bin/node12, /usr/bin/node14 and /usr/bin/node as an alternative link. Which is not going to happen for that transition. Jérémy
Bug#1008541: vagrant: Cant create boxes running ssh 8.8
Package: vagrant
Severity: normal
Dear Maintainer,
It's not possible to start a VM on bullseye with this Vagrantfile:
Vagrant.configure("2") do |config|
config.vm.box = "generic/alpine315"
end
It's stuck while trying the use SSH. generic/alpine310 is fine for instance.
After debugging, it turns out that it's due to ssh 8.8 running inside the guest.
It has been:
- fixed in ruby net-ssh:
https://github.com/net-ssh/net-ssh/commit/a45f54fe1de434605af0b7195dd9a91bccd2cec5
- workarounded in vagrant with lib/vagrant/patches/net-ssh.rb
Doing a quick backport of sid vagrant seems to fix the issue.
I'm not sure which package should be fixed (rubygem-net-ssh or vagrant)
so bugging against vagrant since it's this package not working.
Thanks,
Arnaud
-- System Information:
Debian Release:
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-12-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#1008540: cpupower-gui: Please package version 1.0 released in november 2020
Package: cpupower-gui Version: 0.7.2-2 Severity: normal Dear Maintainer, The subject says it all. Christian -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.1-2 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cpupower-gui depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii gir1.2-gtk-3.0 3.24.33-1 ii hicolor-icon-theme 0.17-2 ii libgtk-3-0 3.24.33-1 ii policykit-1 0.105-33 ii python3 3.9.8-1 ii python3-dbus 1.2.18-3+b1 ii python3-gi 3.42.0-3 cpupower-gui recommends no packages. Versions of packages cpupower-gui suggests: pn lxqt-policykit pn lxsession pn mate-polkit pn policykit-1-gnome -- no debconf information
Bug#1008539: gnome-shell-extension-dashtodock: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-dashtodock Version: 71-1 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/micheleg/dash-to-dock/pull/1656 The metadata.json for this extension doesn't declare compatibility with GNOME 42, and it looks like some code changes are necessary. There is a PR for this upstream, and Ubuntu maintains gnome-shell-extension-ubuntu-dock which I believe is a fork of this codebase. gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008538: gnome-shell-extension-dash-to-panel: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-dash-to-panel Version: 45-1 Severity: normal Tags: bookworm sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 Forwarded: https://github.com/home-sweet-gnome/dash-to-panel/pull/1584 The metadata.json for this extension doesn't declare compatibility with GNOME 42, and it looks like some code changes are necessary. There is a PR for this upstream, although it isn't necessarily perfect. gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008514: FTBFS -- upstream test suite failure
Real error is:
Transforming async functions is not implemented. Use `transforms: {
asyncAwait: false }` to skip transformation and disable this error.
Bug#1008537: gnome-shell-extension-autohidetopbar: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-autohidetopbar Version: 20211109-1 Severity: normal Tags: bookworm sid fixed-upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension doesn't declare compatibility with GNOME 42. New upstream releases appear to have fixed this. gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008536: gnome-shell-extension-arc-menu: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-arc-menu Version: 49+forkv20-1 Severity: normal Tags: bookworm sid User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension doesn't declare compatibility with GNOME 42. I don't know whether the actual code will need changes or not: the conservative assumption is that it probably will (so please test). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. In versions of GNOME Shell up to 3.38, metadata.json didn't matter much, because validation of extensions' metadata against the installed Shell version was disabled by default; but since GNOME 40 the default has changed back to enabling the version check by default, in an effort to avoid issues caused by outdated extensions remaining enabled. As a result, GNOME Shell extensions in bookworm should probably have a dependency like: Depends: gnome-shell (>= x), gnome-shell (<< y~) where x and y are set according to metadata.json. gnome-shell-extension-caffeine is a good example of this technique. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1008535: gnome-shell-extension-hard-disk-led: does not declare compatibility with GNOME Shell 42
Package: gnome-shell-extension-hard-disk-led Version: 29-1 Severity: normal Tags: bookworm sid User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-42 The metadata.json for this extension doesn't declare compatibility with GNOME 42. I don't know whether the actual code will need changes or not: the conservative assumption is that it probably will (so please test). gnome-shell 42 is in experimental and will be entering unstable soon, at which point this will become a RC bug. In versions of GNOME Shell up to 3.38, metadata.json didn't matter much, because validation of extensions' metadata against the installed Shell version was disabled by default; but since GNOME 40 the default has changed back to enabling the version check by default, in an effort to avoid issues caused by outdated extensions remaining enabled. As a result, GNOME Shell extensions in bookworm should probably have a dependency like: Depends: gnome-shell (>= x), gnome-shell (<< y~) where x and y are set according to metadata.json. gnome-shell-extension-caffeine is a good example of this technique. During the GNOME Shell 42 transition, this extension will be removed from testing if it continues to be incompatible. Thanks, smcv
Bug#1003366: Processed: Re: Bug#1007838: d-i.debian.org: Installer iSCSI does not work in Debian 11
Hello, On Fri, 2022-03-18 at 11:10 +0100, Cyril Brulebois wrote: > Thanks Eugene, > > Eugene Losowski-Gallagher > (2022-03-18): > > This looks like a duplicate of: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003366 > > Same issue (but with more diagnostics). > > Since one isn't supposed to be using iscsid within the installer, I'd > suggest dropping it from the udeb entirely, so that people don't > waste > time trying to start a daemon that's not supposed to be started > there? > I agree. My recommended setup for `root on iscsi` is documented in the README.Debian. > Alternatively, if that daemon can still be useful within the > installer, > I can look into implementing a double build for open-iscsi, building > with systemd support for the main binary, and without it for the udeb > binary. > > It could certainly be integrated into the installer in some form. But the setup has to be carefully stacked. And there will be multiple configuration scenarios (sw iscsi, hw iscsi, offload, multipath etc) that need to be tested in multiple combinations. Lately, I haven't had the volunteer time that I once had, to commit to these packages. So any help in implementing, testing and maintaining these features is welcome. > In any cases, that's a bit of a side quest, and the real issue is why > the regular installer tools aren't able to set up iSCSI storage. :) > (And that part I'm not familiar enough at this stage to be able to > debug.) I haven't checked this particular case. But, in general, you didn't much need to run the daemon in the installer. You just discover, and then establish the connecitons to the target and be done, for the part of the installer. On real boot, when init fires up iscsid daemon, it'll take over those connections and do the necessary housekeeping thenceforth. This is all around 8 years old setup knowledge across distributions. Not sure what the current approach is. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#1006424: AW: Bug#1006424: mirror submission for mirror.informatik.tu-freiberg.de
Hi Julien, thanks for the tips. I have configured ftpsync to generate the tracefile correctly and I have adjusted the upstream mirror as well. Could you maybe run the script again or should I really resubmit? Best regards, Christian -Ursprüngliche Nachricht- Von: Julien Cristau Gesendet: Donnerstag, 24. März 2022 17:18 An: Schubert Christian ; 1006424-d...@bugs.debian.org Betreff: Re: Bug#1006424: mirror submission for mirror.informatik.tu-freiberg.de Hi Christian, our scripts notice a couple of issues: o The tracefile at http://mirror.informatik.tu-freiberg.de/debian/project/trace/mirror.informat ik.tu-freiberg.de is missing some required information. We expect at least the Maintainer and Upstream-mirror values to be filled in, and your tracefile is missing one or both of them. o we recommend mirrors not sync directly from service aliases such as ftp..debian.org (only http is guaranteed to be available at ftp..d.o sites). Maybe change your config to sync from the site currently backing the ftp..debian.org service you sync from, i.e. debian.inf.tu-dresden.de? Feel free to resubmit once at least the latter is fixed. Thanks, Julien On Fri, Feb 25, 2022 at 09:24:32AM +, Christian Schubert wrote: > Package: mirrors > Severity: wishlist > User: mirr...@packages.debian.org > Usertags: mirror-submission > > Submission-Type: new > Site: mirror.informatik.tu-freiberg.de > Type: leaf > Archive-architecture: amd64 arm64 i386 mips64el ppc64el > Archive-http: /debian/ > Archive-rsync: debian/ > Maintainer: Christian Schubert > Country: DE Germany > Location: TU Bergakademie Freiberg > > > > > Trace Url: > http://mirror.informatik.tu-freiberg.de/debian/project/trace/ > Trace Url: > http://mirror.informatik.tu-freiberg.de/debian/project/trace/ftp-maste > r.debian.org Trace Url: > http://mirror.informatik.tu-freiberg.de/debian/project/trace/mirror.in > formatik.tu-freiberg.de > smime.p7s Description: S/MIME cryptographic signature
Bug#1006822: Chromium
Hello, I have the same issue: chromium dose not start with this message: ERROR:sandbox_linux.cc(377)] InitializeSandbox() called with multiple threads in process gpu-process. I have not wayland. chromium --ozone-platform=wayland chromium --ozone-platform=x11 chromium --no-sandbox None of that does no work. Regards -- Rpnpif
Bug#1008063: transition: nodejs
On 2022-03-22 20:06:50, Jérémy Lal wrote: > On Mon, Mar 21, 2022 at 10:42 PM Sebastian Ramacher > wrote: > > > Control: tags -1 confirmed > > > > On 2022-03-21 18:54:38 +0100, Jérémy Lal wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > X-Debbugs-Cc: Debian Javascript Maintainers < > > pkg-javascript-de...@lists.alioth.debian.org> > > > > > > Hi, > > > > > > this transition correspond to a nodejs 12 -> 14 major major bump. > > > > > > I carefully checked (twice, actually) that all build-dependencies of > > > - libnode-dev (arch-dependent) > > > - nodejs (arch-independent) > > > can be rebuilt using latest libnode-dev / nodejs, though of course > > > only the arch-dependent ones are concerned by this transition. > > > > Please go ahead > > > We just just finished fixing some issues > with nodejs_16.13.2+really14.19.1~dfsg-5: > - test issues > - missing important files for typescript-dependent modules > > Also i just uploaded a fix for > node-modern-syslog > > node-opencv is known to fail and might be fixed, but it will be removed if > not. The remaining blockers are some autopkgtest regressions: ∙ ∙ autopkgtest for node-expat/2.4.0+ds-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) ∙ ∙ autopkgtest for node-iconv/3.0.1+~3.0.0-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) ∙ ∙ autopkgtest for node-jest/27.5.1~ds+~cs69.51.22-4: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Not a regression ∙ ∙ autopkgtest for node-modern-syslog/1.2.0-2: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) ∙ ∙ autopkgtest for node-node-forge/1.2.1~dfsg-2: ppc64el: No test results ∙ ∙ autopkgtest for node-node-sass/7.0.1+git20211229.3bb51da+dfsg-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) ∙ ∙ autopkgtest for node-npmrc/1.1.1-2: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) ∙ ∙ autopkgtest for node-re2/1.17.4+~cs2.13.8-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) ∙ ∙ autopkgtest for node-sqlite3/5.0.2+ds1-3: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) ∙ ∙ autopkgtest for node-ts-jest/27.1.3+~cs0.2.6-2: ppc64el: Pass ∙ ∙ autopkgtest for node-websocket/1.0.34+~cs10.0.25-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) Could you please have a look at them? Cheers Sebastian -- Sebastian Ramacher
Bug#1008533: RFP: elpa-osm -- OpenStreetMap viewer for Emacs
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-osm Version : 0.6 Upstream Author : Daniel Mendler * URL : https://github.com/minad/osm * License : GPL-3 Programming Lang: Elisp Description : OpenStreetMap viewer for Emacs Features * Zoomable and moveable map display * Display of tracks and POIs from GPX file * Parallel fetching of tiles with curl * Moving in large and small steps * Mouse support (dragging, clicking, menu) * Map scale indicator * Go to coordinate * Search for location by name * Org and Elisp link support * Bookmarked positions with pins * Multiple preconfigured tile servers - That thing is just incredible. A "slippery-map" viewer for emacs that works, and works well. A beautiful work of art. We should definitely have this in debian, and deps seem minimal.
Bug#975505: Please package v3.0.5 or newer
On 28/03/2022 15:06, Dmitry Shachnev wrote: On Mon, Mar 28, 2022 at 02:47:50PM +0200, Yadd wrote: Thank you very much for taking care of this. But why conflicts/breaks? Does it have any file conflicts? I thought there should not be any. Yes we can change paths to avoid conflicts. Aren't the paths different on their own? In MathJax 2.x, most of the JS files are under one of these three directories: config, extensions, jax. It looks like MathJax 3.x does not have any of them. I was looking at these lists: https://archlinux.org/packages/community/any/mathjax2/files/ https://archlinux.org/packages/community/any/mathjax/files/ Sadly I'm not able to build wicked-good-xpath for now (mathjax3->speech-rule-engine->wicked-good-xpath): our closure-compiler looks too old. It's not just old, it's ancient! The version number is 20130227+dfsg1... In MathJax v2 I simply disabled that stuff and even excluded it from the tarball: https://salsa.debian.org/js-team/mathjax/-/commit/4ace348cad6ac57c Maybe you can do the same? It's an accessibility feature so we can live without it for some time. Not so easy, sre is called in many places in code
Bug#1008532: ITP: fcitx5-mcbopomofo -- McBopomofo input method for fcitx5
Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬)
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: fcitx5-mcbopomofo
Version : 2.2.2
Upstream Author : The McBopomofo Authors
* URL : https://github.com/openvanilla/fcitx5-mcbopomofo
* License : Expat
Programming Lang: C++
Description : McBopomofo input method for fcitx5
McBopomofo input method for Linux fcitx5 user.
This package will be maintained under Debian Input Method Team
.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#1008531: 0ad: assertion failure if hyperthreading (SMT) is supported but disabled
Package: 0ad Version: 0.0.25b-1.1 Severity: normal Steps to reproduce: * Have a hyperthreading-capable CPU (in my case an Intel Core i5-8350U with 4 cores and 8 hyperthreads) * Boot with nosmt=1 on the kernel command line * lscpu * 0ad Expected result: 0ad runs Actual result: > $ lscpu > ... > CPU(s): 8 > On-line CPU(s) list: 0-3 > Off-line CPU(s) list: 4-7 > ... An 0ad crash report dialog pops up with the following text: > Assertion failed: "ret == 0" > Location: lcpu.cpp:174 (os_cpu_SetThreadAffinityMask) > > Call stack: > > (0x56077fc3ae75) /usr/games/pyrogenesis(+0x605e75) [0x56077fc3ae75] > (0x56077fbdb0f7) /usr/games/pyrogenesis(+0x5a60f7) [0x56077fbdb0f7] > (0x56077fbdcbf8) /usr/games/pyrogenesis(+0x5a7bf8) [0x56077fbdcbf8] > (0x56077fbdd0b4) /usr/games/pyrogenesis(+0x5a80b4) [0x56077fbdd0b4] > (0x56077fc3ab16) /usr/games/pyrogenesis(+0x605b16) [0x56077fc3ab16] > (0x56077fc3ac89) /usr/games/pyrogenesis(+0x605c89) [0x56077fc3ac89] > (0x56077fc6d39a) /usr/games/pyrogenesis(+0x63839a) [0x56077fc6d39a] > (0x56077fc6cd23) /usr/games/pyrogenesis(+0x637d23) [0x56077fc6cd23] > (0x56077fc6d8fa) /usr/games/pyrogenesis(+0x6388fa) [0x56077fc6d8fa] > (0x56077fc33a25) /usr/games/pyrogenesis(+0x5fea25) [0x56077fc33a25] > (0x56077fc6cd23) /usr/games/pyrogenesis(+0x637d23) [0x56077fc6cd23] > (0x56077fc33faa) /usr/games/pyrogenesis(+0x5fefaa) [0x56077fc33faa] > (0x56077f90c6fa) /usr/games/pyrogenesis(+0x2d76fa) [0x56077f90c6fa] > (0x56077f90423b) /usr/games/pyrogenesis(+0x2cf23b) [0x56077f90423b] > (0x56077f6e744f) /usr/games/pyrogenesis(+0xb244f) [0x56077f6e744f] > (0x56077f6d38ea) /usr/games/pyrogenesis(+0x9e8ea) [0x56077f6d38ea] > > errno = 22 (Invalid alignment) > OS error = ? Workaround: after clicking Suppress in the crash report dialog, the game seems to work fine. smcv -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages 0ad depends on: ii 0ad-data 0.0.25b-1 ii 0ad-data-common0.0.25b-1 ii dpkg 1.21.4 ii libboost-filesystem1.74.0 1.74.0-14 ii libc6 2.33-7 ii libcurl3-gnutls7.82.0-2 ii libenet7 1.3.13+ds-1 ii libfmt88.1.1+ds1-2 ii libgcc-s1 12-20220319-1 ii libgl1 1.4.0-1 ii libgloox18 1.0.24-2+b1 ii libicu67 67.1-7 ii libminiupnpc17 2.2.3-1+b1 ii libopenal1 1:1.19.1-2 ii libpng16-161.6.37-3 ii libsdl2-2.0-0 2.0.20+dfsg-2 ii libsodium231.0.18-1 ii libstdc++6 12-20220319-1 ii libvorbisfile3 1.3.7-1 ii libwxbase3.0-0v5 3.0.5.1+dfsg-4 ii libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-4 ii libx11-6 2:1.7.2-2+b1 ii libxml22.9.13+dfsg-1 ii zlib1g 1:1.2.11.dfsg-4 0ad recommends no packages. 0ad suggests no packages. -- no debconf information
