Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Hi Paul, Paul Gevers писал 2022-03-03 00:44: > On 01-03-2022 12:01, Paul Gevers wrote: >> This "fix" suggest there may be more breakage, normally the Release Team >> would schedule binNMU's. Can you please elaborate how ABI is normally >> maintained within swi-prolog, such that the rebuilds can be detected and >> requested? I fail to see how in the case of logol and swi-prolog the right >> versions are chosen. In other words, I think the "fixed" logol can migrate >> to testing even if swi-prolog does not and will be broken in testing until >> swi-prolog can migrate. Normally *versioned* dependencies should prevent >> this. > > I just read the backlog of the bug report (by default, submitters of > bug reports in Debian don't get notified of messages, I missed the > discussion). It seems my worry was already raised. The bug was > reassigned to logol, so the swi-prolog maintainers missed my message. > >> I checked, there are more reverse build dependencies of swi-prolog, I'm >> afraid there's more breakage that hasn't been detected yet. (eye seems to go >> in lockstep, so that package currently seems OK). > > Maybe swi-prolog maintainers can comment. Thanks for your input. Since the problem is resolved now, could you please unblock migration of swi-prolog, logol, and eye (another package depending on swi-prolog). swi-prolog package (namely, swi-prolog-core) provides an easy way to require some particular ABI since 8.2.0+dfsg-2 uploaded on Jun 9, 2020. Specifically, in this case logol requires version 67 of binary ABI (pre-compiled Prolog code), where the version of swi-prolog in unstable is at version 68. In case of logol, its fixed version needs to depend on swi-prolog-binary-68 (again, provided by swi-prolog-core). In this case it will be easier to track problems with ABI changes. There are more ABI stuff in swi-prolog which can be tracked the same way. It is documented in d/Debian.NEWS and d/README.Debian and there are references to SWI-Prolog upstream reference guide. More specifically, swi-prolog provides 5 virtual packages, each of them containing (a part) of some specific ABI version claimed by the current swi-prolog version. All these components are extensively documented in SWI-Prolog upstream reference guide. These virtual packages were introduced to prevent the same ABI-incompatibility problems with another Debian package, eye. Cheers! Lev
Bug#1006711: ITP: js-of-ocaml-ocamlbuild -- compiler from OCaml bytecode to JavaScript (ocamlbuild plugin)
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: js-of-ocaml-ocamlbuild Version : git Upstream Author : Jacques-Pascal Deplaix * URL : https://github.com/ocsigen/js_of_ocaml-ocamlbuild * License : LGPL 2.1 with OCaml linking exception Programming Lang: OCaml Description : compiler from OCaml bytecode to JavaScript (ocamlbuild plugin) Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes it possible to run pure OCaml programs in JavaScript environment like browsers and Node.js. . This package contains the ocamlbuild plugin. This package was part of js-of-ocaml, but has been split out in the latest version. Eliom depends on it. It will be maintained in the OCaml team.
Bug#1004433: Patches for CVE-2022-23959
Hi Andreas, On Mon, Feb 28, 2022 at 09:03:44AM +0100, Andreas Unterkircher wrote: > > It appreciate if you could test bullseye as well. Thanks! > > Have updated a server with Buster (on which I've tested Varnish > v6.1.1-1+deb10u3 before) to Bullseye and upgraded Varnish to > 6.5.1-1+deb11u2. > > The results are pretty much the same as with Buster. > > The hosted pages work correctly with HTTP 1.1 trough Varnish. > The same for HTTP2. > Locust against Varnish with 100 req/sec gives stable results for 10min > testing. > > user@host:~$ sudo varnishd -V > varnishd (varnish-6.5.1 revision 1dae23376bb5ea7a6b8e9e4b9ed95cdc9469fb64) > Copyright (c) 2006 Verdens Gang AS > Copyright (c) 2006-2020 Varnish Software > user@host:~$ sudo varnishstat -n $(hostname) -1 > MGT.uptime1054 1.00 Management process uptime > MGT.child_start 1 0.00 Child process started > MGT.child_exit 0 0.00 Child process normal exit > MGT.child_stop 0 0.00 Child process unexpected exit > MGT.child_died 0 0.00 Child process died (signal) > MGT.child_dump 0 0.00 Child process core dumped > MGT.child_panic 0 0.00 Child process panic > MAIN.summs 7445070.57 stat summ operations > MAIN.uptime 1055 1.00 Child process uptime > MAIN.sess_conn 2539324.07 Sessions accepted > MAIN.sess_fail 0 0.00 Session accept failures > MAIN.sess_fail_econnaborted0 0.00 Session accept > failures: connection aborted > MAIN.sess_fail_eintr 0 0.00 Session accept > failures: interrupted system call > MAIN.sess_fail_emfile 0 0.00 Session accept > failures: too many open files > MAIN.sess_fail_ebadf 0 0.00 Session accept > failures: bad file descriptor > MAIN.sess_fail_enomem 0 0.00 Session accept > failures: not enough memory > MAIN.sess_fail_other 0 0.00 Session accept > failures: other > MAIN.client_req_4000 0.00 Client requests > received, subject to 400 errors > MAIN.client_req_4170 0.00 Client requests > received, subject to 417 errors > MAIN.client_req3503033.20 Good client requests > received > MAIN.cache_hit 3370331.95 Cache hits Thanks a lot for your testing, this is very much appreciated! Florian, should we go ahead with the DSA release? Regards, Salvatore
Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.15-0+deb11u1
Hi Otto, On Wed, Mar 02, 2022 at 04:14:48PM -0800, Otto Kekäläinen wrote: > > > According to https://release.debian.org/ the next stable update is > > > due > > > in February. Please include this update to MariaDB. > > > > > > > That was the plan, yes. As you probably noticed, we're a little behind > > schedule > > That's fine as long as it is just about a couple of weeks, and not > long enough for there to be yet another upstream release (so that the > work on this release was not in vain). Btw, I just want to make a little comment on this: It's never in vain, because once it's uploaded it has pre-advance testing for those looking at the proposed-updates before a point release. If a further update is needed this can be done then on top. You will see some cases where you have multiple uploas done there (for making a own example, I prepared src:mailman updates which did not warrant a DSA, with one last upload including regression fixes) and so resulted in conclusive right now 4 versions in https://release.debian.org/proposed-updates/oldstable.html Regards, Salvatore
Bug#1006689: does not purge cleanly
Control: tags -1 + moreinfo unreproducible Hi Marc, Thanks for your report. On Wed, Mar 02, 2022 at 02:19:32PM +0100, Marc Haber wrote: > Package: nfs-kernel-server > Version: 1:2.6.1-1 > Severity: normal > > Hi, > > I noticed that nfs-blkmap.service keeps failing on my notebook. Since > I'm not using NFS anyway, I found out that this service belongs to > nfs-kernel-server and tried to purge the package. This should be possible > since I dont have dependencies installed, but it fails: > > [4/4996]mh@drop:~ $ sudo apt purge nfs-kernel-server > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > The following packages will be REMOVED: > nfs-kernel-server* > 0 upgraded, 0 newly installed, 1 to remove and 4 not upgraded. > After this operation, 650 kB disk space will be freed. > Do you want to continue? [Y/n] > (Reading database ... 492241 files and directories currently installed.) > Removing nfs-kernel-server (1:2.6.1-1) ... > Failed to stop nfs-kernel-server.service: Unit nfs-kernel-server.service not > loaded. > invoke-rc.d: initscript nfs-kernel-server, action "stop" failed. > dpkg: error processing package nfs-kernel-server (--remove): > installed nfs-kernel-server package pre-removal script subprocess returned > error exit status 5 > dpkg: too many errors, stopping > nfs-mountd.service is a disabled or a static unit not running, not starting > it. > nfs-server.service is a disabled or a static unit not running, not starting > it. > nfsdcld.service is a disabled or a static unit not running, not starting it. > Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. > Failed to restart nfs-kernel-server.service: Unit nfs-kernel-server.service > failed to load properly, please adjust/correct and reload service manager: > File exists > See system logs and 'systemctl status nfs-kernel-server.service' for details. > invoke-rc.d: initscript nfs-kernel-server, action "restart" failed. > ○ nfs-kernel-server.service > Loaded: error (Reason: Unit nfs-kernel-server.service failed to load > properly, please adjust/correct and reload service manager: File exists) > Active: inactive (dead) > Warning: The unit file, source configuration file or drop-ins of > nfs-kernel-server.service changed on disk. Run 'systemctl daemon-reload' to > reload units. > Failed to restart nfs-kernel-server, ignoring. > Errors were encountered while processing: > nfs-kernel-server > Processing was halted because there were too many errors. > needrestart is being skipped since dpkg has failed > E: Sub-process /usr/bin/dpkg returned an error code (1) > 100 [5/4997]mh@drop:~ $ sudo apt purge nfs-kernel-server > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > The following packages will be REMOVED: > nfs-kernel-server* > 0 upgraded, 0 newly installed, 1 to remove and 4 not upgraded. > After this operation, 650 kB disk space will be freed. > Do you want to continue? [Y/n] > (Reading database ... 492241 files and directories currently installed.) > Removing nfs-kernel-server (1:2.6.1-1) ... > Failed to stop nfs-kernel-server.service: Unit nfs-kernel-server.service not > loaded. > invoke-rc.d: initscript nfs-kernel-server, action "stop" failed. > dpkg: error processing package nfs-kernel-server (--remove): > installed nfs-kernel-server package pre-removal script subprocess returned > error exit status 5 > dpkg: too many errors, stopping > nfs-mountd.service is a disabled or a static unit not running, not starting > it. > nfs-server.service is a disabled or a static unit not running, not starting > it. > nfsdcld.service is a disabled or a static unit not running, not starting it. > Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. > Failed to restart nfs-kernel-server.service: Unit nfs-kernel-server.service > failed to load properly, please adjust/correct and reload service manager: > File exists > See system logs and 'systemctl status nfs-kernel-server.service' for details. > invoke-rc.d: initscript nfs-kernel-server, action "restart" failed. > ○ nfs-kernel-server.service > Loaded: error (Reason: Unit nfs-kernel-server.service failed to load > properly, please adjust/correct and reload service manager: File exists) > Active: inactive (dead) > Warning: The unit file, source configuration file or drop-ins of > nfs-kernel-server.service changed on disk. Run 'systemctl daemon-reload' to > reload units. > Failed to restart nfs-kernel-server, ignoring. > Errors were encountered while processing: > nfs-kernel-server > Processing was halted because there were too many errors. > needrestart is being skipped since dpkg has failed > E: Sub-process /usr/bin/dpkg returned an error code (1) > 100 [6/4997]mh@drop:~ $ > > I was able to get rid of the package by emptying out the prerm > script, but that should be easier. I was not able to reproduce this behaviour and
Bug#1006710: should get rid of scripts/install-manpages
Package: adduser Version: 3.118 Severity: minor the script that we use to install manpages currently needs root. We should try to convert the package build to using dh_installmanpages so that we can probably can get away with Rules-Requres-Root: no Greetings Marc
Bug#1006553: btrfs-progs: integration with util-linux fsck
On Thu, Mar 3, 2022 at 5:49 AM Adam Borowski wrote: > > On Sun, Feb 27, 2022 at 08:32:17PM +0200, Martin-Éric Racine wrote: > > Package: btrfs-progs > > Version: 5.15.1-1 > > Severity: important > > > As per the enclosed screenshot, btrfs-progs splatters its filesystem > > checking message all over the place. It would be desirable to integrate > > it with the util-linux fsck run that follows. > > btrfs, like all modern filesystems except for ext4, doesn't run fsck at > mount time at all. And the reason ext4 does stopped make sense around the > turn of the millenium, when every unsafe shutdown caused possible filesystem > corruption, often catastrophic. Such automated fsck is a throwback to the > ext2/ext/sysvfs times when it was a hail mary attempt to fix such damage. > > As btrfs devs believe that all regular checks are supposed to be done > online, on a mounted filesystem, fsck.btrfs is not even a primary recovery > tool, and as thus there's even less point in running fsck at mount time. > > Thus, I'm not going to add any such checks, sorry. It would be a good idea to actually read the bug report before replying. Your reply doesn't address the issue AT ALL. It addresses an entirely different matter. Martin-Éric
Bug#1006709: RM: libnfsidmap-regex -- ROM; not needed anymore as provided with src:nfs-utils
Package: ftp.debian.org Severity: normal The functionality of it was upstreamed with the new version of src:nfs-utils (2.x) according upstream of src:libnfsidmap-regex. Please remove this from the archive. Thanks, Gurkan
Bug#979067: Continue work on pinta in Debian
Hi Mike, Hi Mike, 在 2022-03-01星期二的 22:23 +，Mike Gabriel写道： > Hi Boyuan, hi Iain, dear Mono Team, > > I am writing to you (Boyuan, Iain) as the two last uploaders of the > "pinta" package in Debian. > > I have a customer that is interested in reviving pinta and bringing a > new upstream version of it into Debian (and paying for that). > > Does anyone see constraints or troubles ahead in doing this? I'd > thought that before I start spending time on this endeavour, I'd > better ask around. My previous NMU was merely a trivial clean-up. I am not familiar with Mono either. Please consider still use https://salsa.debian.org/dotnet-team/pinta for the packaging work. To avoid confusion, I have deleted https://salsa.debian.org/byang/pinta . Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)
Source: hw-detect Version: 1.147 Severity: normal User: de...@kali.org Usertags: origin-kali Dear Maintainer, A Kali Linux user reported a fail install on a Dell XPS 9510. For the background, the Kali Linux installer is a super lightweight fork of the Debian installer, kept in sync with Debian. For additional references: * The bug report against Kali Linux is at: https://gitlab.com/kalilinux/build-scripts/live-build-config/-/issues/47 * The user provided screenshots of the installer logs, available at: https://imgur.com/a/QMDMWug. The 3 first screenshots are with an unmodified installer, while for the later screenshots, the user disabled /bin/check-missing-firmware with a 'exit 0'. * The Debian installer is expected to work with this particular model of laptop: https://wiki.debian.org/InstallingDebianOn/Dell/Dell_XPS_15_9510 I don't want to discuss the bug reported in Kali here, that is not the intent. The reason I'm opening this bug against Debian is because, while looking at the logs, a few lines caught my eyes. This is in the screenshot #3 in the imgur.com link above: check-missing-firmware: removing-and-loading kernel module iwlwifi check-missing-firmware: modprobe: FATAL: Module iwlwifi is in use. I wonder if those lines are harmless, or if it really indicates that the iwlwifi module can't be reloaded, therefore the wifi is not functional. Since someone documented on the Debian wiki that the firmware-iwlwifi is needed, and then the WiFi works, it seems that either those lines are harmless, or the iwlwifi is not always successfully reloaded. Thanks! Arnaud
Bug#1006707: python3.10 -m venv installs pip to incorrect path VENV_ROOT/local/bin/pip
Package: python3.10
Version: 3.10.2-5
Severity: important
As of python3.10 3.10.2-3, python3.10 -m venv installs pip to the wrong path:
# apt update
# apt install python3.10-venv
# python3.10 -m venv /tmp/my-venv
# . /tmp/my-venv/bin/activate
# type pip
bash: type: pip: not found
# pip --version
bash: pip: command not found
# echo $PATH
/tmp/my-venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# ls /tmp/my-venv/bin
Activate.ps1 activate activate.csh activate.fish python python3 python3.10
# ls /tmp/my-venv/local/bin
pip pip3 pip3.10
There’s a similar problem with virtualenv; although virtualenv still installs
pip to the correct path, that pip installs other binaries to the wrong path:
# deactivate
# apt install python3-virtualenv
# virtualenv -p python3.10 /tmp/my-virtualenv
# /tmp/my-virtualenv/bin/pip install black
# . /tmp/my-virtualenv/bin/activate
# type black
bash: type: black: not found
# black --version
bash: black: command not found
# ls /tmp/my-virtualenv/local/bin
black black-primer blackd
This all worked correctly in 3.10.2-2.
# deactivate
# echo deb https://snapshot.debian.org/archive/debian/20220224T145813Z/ sid
main >> /etc/apt/sources.list
# apt update
# apt install
{libpython3.10-minimal,libpython3.10-stdlib,python3.10,python3.10-minimal,python3.10-venv}=3.10.2-2
# rm -rf /tmp/my-venv /tmp/my-virtualenv
# python3.10 -m venv /tmp/my-venv
# . /tmp/my-venv/bin/activate
# type pip
pip is /tmp/my-venv/bin/pip
# pip --version
pip 22.0.2 from /tmp/my-venv/lib/python3.10/site-packages/pip (python 3.10)
# deactivate
# virtualenv -p python3.10 /tmp/my-virtualenv
# /tmp/my-virtualenv/bin/pip install black
# . /tmp/my-virtualenv/bin/activate
# type black
black is /tmp/my-virtualenv/bin/black
# black --version
black, 22.1.0 (compiled: yes)
Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.15-0+deb11u1
> > According to https://release.debian.org/ the next stable update is > > due > > in February. Please include this update to MariaDB. > > > > That was the plan, yes. As you probably noticed, we're a little behind > schedule That's fine as long as it is just about a couple of weeks, and not long enough for there to be yet another upstream release (so that the work on this release was not in vain). > > mariadb-10.5 (1:10.5.15-0+deb11u1) bullseye; urgency=medium .. > Please go ahead. Uploaded both 10.5 and 10.3. There are also new upstream Galera bugfix releases (both series 3 and 4). I intend to import and QA these, and file buster-pu and bullseye-pu bugs to have them included too.
Bug#1006704: nmu: memlockd_1.3-2: rebuild to fix missing binary issue (Closes: #1000229)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu The current memlockd .deb does not contain /usr/sbin/memlockd, but simply rebuilding the package fixes the issue. This was reported in #1000229 and confirmed by me using debuild and pbuilder. Please rebuild the package using a binNMU in order to fix the issue and close the bug. nmu memlockd_1.3-2 . ANY . unstable . -m "rebuild to fix missing binary issue (Closes: #1000229)" -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1004928: package upload will be done soon
A package fixing these bugs will be uploaded soon ... Thorsten
Bug#964947: dhcpcd5: New upstream version available: 9.1.4
On March 2, 2022 6:10:32 PM GMT+01:00, "Martin-Éric Racine" wrote: >On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine > wrote: >> >> On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R. wrote: >> > >> > El 28/02/22 a las 16:52, Martin-Éric Racine escribió: >> > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine >> > > wrote: >> > > > >> > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine >> > > > wrote: >> > > > > >> > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. >> > > > > wrote: >> > > > > > * Could you please fix the indentation of the your new entry in >> > > > > > d/copyright? >> > > > > >> > > > > IMHO, the whole file's indentation needs to be fixed. I had troubles >> > > > > aligning my addition, because the file currently uses TAB+2SPACES. >> > > > > There really should be a linting tool for that. >> > > > >> > > > Actually, it seems that wrap-and-sort can be used for d/copyright too. >> > > > I somehow was under the impression that it's only used for d/control. >> > > > I'm extremely tempted to run it on the whole package. >> > > >> > > Reading back on Bug #964947, I notice that the request was for both >> > > packaging current upstream and dropping the 5 out of the package name. >> > > I would tend to agree. The 5 really only was meant as an upstream >> > > branch tag. The source and binary really should be called 'dhcpcd' >> > > since it essentially is a fork of the abandoned source of the same >> > > name. >> > >> > Changing the source name means creating (or reintroducing) a different >> > debian package. Just in case: >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743218 >> > >> > Changing the binary name only means it would have to pass by NEW… >> >> Merely changing the binary name sounds perfectly reasonable to me. > >Please note that I have re-uploaded the package to Mentors. The log >file is more explicit about cosmetic changes and about ./configure >caveats. > Thank you. And sorry for the radio silence, I got busier than expected the last couple of days. I hope I can process it by Friday. Cheers, Santiago -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
Bug#1005149: ansible: misbuilds with two supported Python versions
Control: tags -1 pending Hello all, Due to the severity of this issue, I have uploaded a NMU to the delayed queue, set to 10 days. The NMU is changing the build-dependency from python3-all to python3, so it builds for a single python release at a time. Debdiff attached. Lee, let me know if you need help with sponsors or maintenance of the package. For the record, this seems to be the same issue affecting ansible-core at #1001040 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001040 Thanks, -- Samuel Henrique ansible_2.10.7+merged+base+2.10.8+dfsg-1.1.debdiff Description: Binary data
Bug#1001040: ansible-core: No such file or directory: '/usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py'
Control: tags -1 pending Hello all, Due to the severity of this issue, I have uploaded a NMU to the delayed queue, set to 10 days. The NMU is changing the build-dependency from python3-all to python3, so it builds for a single python release at a time. Debdiff attached. Lee, let me know if you need help with sponsors or maintenance of the package. For the record, this seems to be the same issue affecting ansible at #1005149 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005149 Thanks, -- Samuel Henrique ansible-core_2.12.0-1.1.debdiff Description: Binary data
Bug#1006703: dtrace predictable temp file causes race
Package: systemtap-sdt-dev Version: 4.6-1 Severity: normal dtrace generates .c code in a predictable temporary file which makes it susceptible to crashes. I've seen this happen in practice when rebuilding libvirt/focal on a system with 48 cores. The race window is wide enough that the crash is nearly 100% reproducible. I submitted a patch upstream that has now been accepted: https://sourceware.org/git/?p=systemtap.git;a=commit;h=0de9020c970bceda73e32bbd169c12e7579f21ec Can we get that fix applied to Debian? -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-rc4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemtap-sdt-dev depends on: ii python3 3.9.8-1 systemtap-sdt-dev recommends no packages. systemtap-sdt-dev suggests no packages. -- no debconf information
Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
On Thu, Mar 3, 2022 at 8:16 AM John Paul Adrian Glaubitz wrote: > > Hello! > > On 3/2/22 21:14, Otto Kekäläinen wrote: > > A recent build regression on ppc64el is preventing a new MariaDB version > > from migrating from unstable to testing. > > > > Could any experts on this list help out? > > I don't know where this code is coming from, but this is definitely wrong: > > > https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/mysys/CMakeLists.txt#L145 > > The code is forcing compiler flags based on the architecture and thus > overriding the > baseline. This is a baseline violation and not allowed per Debian Policy. > > And, in particular, it violates the baseline of the ppc64 port which is using > POWER5, > not POWER8. John, The selective CFLAGS on specific files are there to enable optimizations in certain functions. Elsewhere in the code there is runtime detection made of the VSX/vpmsum to actually use the code. So for POWER5 it should be there but dormant. Likewise for the bug here. We've got a htmxlintrin.h header insisting on the -mhtm, backed up the compiler that doesn't define the __builtin_tbegin builtins without the cflags. We use the htm target function attribute to compile specific functions that use it, however the use of instructions is still behind a runtime check. We can't include the header check inside a function, otherwise we are defining an inline function within a function. My work in progress fix is along these lines: https://github.com/MariaDB/server/commit/6df3911b61ba669285c08b1456276217c7881292 note just below the standard view of this commit at the bottom, there is transactional_lock_enabled that does runtime detection. But it's still failing (https://buildbot.mariadb.org/#/grid?branch=bb-10.6-danielblack-MDEV-27936-ppc64-htm-build-fail , for sid only, and only recent (https://buildbot.mariadb.org/#/grid?branch=10.6)), proving sid is true to its name. If this still violates the policy, I'd like to know now so I can implement solutions that drop support for ppc64 POWER5+ and support hardware like ppc64le, POWER8+ that we actually do have hardware for and can support.
Bug#979067: getting pinta updated in Debian
Hello Mike, I have some experience with Mono packaging in Fedora. I know of the dotnet SIG in Fedora. They made a massive effort, involving Microsoft employees, to get dotnet core built according to the Fedora rules (build from source, not using external files, etc). https://fedoraproject.org/wiki/SIGs/DotNet https://fedoraproject.org/wiki/DotNet You can find the spec files here: https://src.fedoraproject.org/rpms/dotnet6.0/tree/rawhide I don't know enough about Debian packaging so I don't know if that is of any help. Pinta has not been updated to version 2.0.2 for Fedora yet, see this discussion: https://lists.fedoraproject.org/archives/list/dotnet-...@lists.fedoraproject.org/thread/2W7DBQ6E5FXSHVMKG7SUT4YZAYPXZUEC/ It is really difficult to package dotnet packages, because of all the nuget dependancies. We have not figured that out for Fedora. Or did not have the volunteers yet to do that. Alternatives to dotnet: Mono, dotgnu https://www.gnu.org/software/dotgnu/ "As of December 2012, the DotGNU project has been decommissioned." Mono: it is the alternative to .NET Framework, which Microsoft will support for many years to come. But the new stuff is happening in dotnet, so projects like Pinta are moving from Mono to dotnet. I hope this helps, Timotheus I am currently looking into requirements of getting pinta in Debian updated to the latest upstream version. My problem: I am not at all a .NET developer or maintainer, so this is a piece of work with a steep learning curve for me. What I found now are AUR packages for pinta (and its dependency dotnet-runtime) that are quite up-to-date: https://archlinux.org/packages/community/any/pinta/ https://archlinux.org/packages/community/x86_64/dotnet-core/ It basically looks like we need to get dotnet-core into Debian and then update pinta to latest 2.0.2 upstream release and we are done. However, dotnet-core seems to be massive and I wonder if that can be avoided as its API is provided by something else in Debian. I am asking this possibly stupid question because I am astounded that noone has ever packaged dotnet-core, filed an RFP or ITP for it, etc. Furthermore, it seems that dotnet-core has been licensed under a DFSG-compliant MIT license variant [1]. Do I miss anything here? Is there a hidden blocker? Or is it just that noone has been interested in dotnet-core (and/or a pinta version bump), so far / recently? Thanks for feedback! Mike [1] https://github.com/dotnet/core/blob/main/LICENSE.TXT
Bug#1006702: mariadb-10.6: Baseline violation on at least i386 via CXXFLAGS
Source: mariadb-10.6 Version: 1:10.6.7-2 Severity: serious Justification: baseline violation Hello! The file mysys/CMakeFiles.txt overrides the compiler machine flags [1] and causes mariadb-10.6 to be build with the CPU baseline of the buildd which results in binaries that will crash on the target platform such as i386. As can be seen in the build log for i386, the code is being built with "-msse4.2 -mpclmul" with at least SSE 4.2 which is not available before Intel Core i7, according to Wikipedia [3]. On ppc64, the code is being built with VSX, Crypto and POWER8 vector instructions which are all not available on the POWER5 baseline that the ppc64 port in Debian uses. I suggest patching out the whole section in mysys/CMakeFiles.txt which may also help fixing testsuite failures on some architectures. Thanks, Adrian > [1] > https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/mysys/CMakeLists.txt#L62 > [2] > https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6=i386=1%3A10.6.7-2=1646205322=0 > [3] https://en.wikipedia.org/wiki/SSE4#SSE4.2 -- .''`. 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
Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
Hello! On 3/2/22 21:14, Otto Kekäläinen wrote: > A recent build regression on ppc64el is preventing a new MariaDB version from > migrating from unstable to testing. > > Could any experts on this list help out? I don't know where this code is coming from, but this is definitely wrong: > https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/mysys/CMakeLists.txt#L145 The code is forcing compiler flags based on the architecture and thus overriding the baseline. This is a baseline violation and not allowed per Debian Policy. And, in particular, it violates the baseline of the ppc64 port which is using POWER5, not POWER8. Adrian -- .''`. 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
Bug#1006622: Acknowledgement (network-manager: Upgrade from 1.34.0-2 to any higher version breaks IPv6 config on mobile broadband)
Current Workaround, if you are affected by this (on debian unstable): Use version 1.34.0-2 from https://snapshot.debian.org/archive/debian/20220121T093818Z
Bug#1006622: Acknowledgement (network-manager: Upgrade from 1.34.0-2 to any higher version breaks IPv6 config on mobile broadband)
Upstream Bugreport: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/944
Bug#1006527: [debian-mysql] Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-27936 This was actually already in progress upstream. Sorry for escalating to list before noticing this.
Bug#1006664: Revert?
On Thu, 3 Mar 2022 01:54:42 +0530 Nilesh Patra wrote: > > python3-unicodedata2 has disappeared from the NEW queue, has it been > > rejected? > > https://tracker.debian.org/pkg/python-unicodedata2 I must have caught it at just the wrong moment. Thanks. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpEYXl00KIbq.pgp Description: OpenPGP digital signature
Bug#1006701: requires golang-github-urfave-cli-v2-dev >= 2.3
Source: rootlesskit Version: 0.14.6-1 Severity: normal rootlesskit uses the "nindent" template function in its help output. This wasn't added to golang-github-urfave-cli-v2 until version 2.3: See: https://github.com/urfave/cli/commit/be9c0378 $ git tag --contains be9c0378 v2.3.0 rootlesskit compiles fine with cli 2.2.0-3, but fails at runtime: $ rootlesskit -h panic: template: help:11: function "trim" not defined goroutine 1 [running]: text/template.Must(...) text/template/helper.go:23 github.com/urfave/cli/v2.printHelpCustom(0x9adb40, 0xc10020, 0xc000156000, 0xb8b, 0x8ec480, 0xc01b00, 0x0) github.com/urfave/cli/v2/help.go:273 +0x50b github.com/urfave/cli/v2.printHelp(0x9adb40, 0xc10020, 0xc000156000, 0xb8b, 0x8ec480, 0xc01b00) github.com/urfave/cli/v2/help.go:288 +0x6d github.com/urfave/cli/v2.ShowAppHelp(0xc60f00, 0xc8ec01, 0x38) github.com/urfave/cli/v2/help.go:81 +0x190 github.com/urfave/cli/v2.(*App).RunContext(0xc01b00, 0x9b6c00, 0xc22060, 0xc0e080, 0x2, 0x2, 0x0, 0x0) github.com/urfave/cli/v2/app.go:263 +0xa59 github.com/urfave/cli/v2.(*App).Run(...) github.com/urfave/cli/v2/app.go:215 main.main() github.com/rootless-containers/rootlesskit/cmd/rootlesskit/main.go:221 +0x1fb8 I therefore suggest versioning the build-dep to e.g. (>= 2.3.0). -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-rc4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#921213: stacktrace when running qbittorrent for sometime.
It looks to me as strictly related to #926062 and #933870. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926062#39 Regards BZ
Bug#1006664: Revert?
> python3-unicodedata2 has disappeared from the NEW queue, has it been > rejected? https://tracker.debian.org/pkg/python-unicodedata2 > Can we go back to 4.28.5-1 ? Not needed now, thanks to Sean for processing it in time Regards, Nilesh signature.asc Description: PGP signature
Bug#1006700: squidguard crashes with an error 4, segfault at libc-2.31.so
Package: squidguard Version: 1.6.0-2 Severity: normal X-Debbugs-Cc: fernando.alves.ra...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- 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/8 CPU threads) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages squidguard depends on: ii debconf [debconf-2.0] 1.5.77 ii libc6 2.31-13+deb11u2 ii libdb5.3 5.3.28+dfsg1-0.8 ii libldap-2.4-2 2.4.57+dfsg-3 Versions of packages squidguard recommends: ii liburi-perl 5.08-1 ii libwww-perl 6.52-1 ii squid4.13-10 Versions of packages squidguard suggests: pn ldap-utils pn squidguard-doc -- debconf information: squidguard/dbreload: true Best regards,
Bug#1005742: golang-mvdan-sh_3.4.2-1_amd64.changes REJECTED
Hi Andreas, please do the TODOs and also mention Andrey Nering and Olliver Schinagl in your debian/copyright. Thanks! Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
Bug#1006664: Revert?
python3-unicodedata2 has disappeared from the NEW queue, has it been rejected? Is it possible to revert python3-fonttools to a version which does NOT need python3-unicodedata2 ? This is starting to block a large number of changes to a large number of packages. Can we go back to 4.28.5-1 ? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpJvYy9CU8bk.pgp Description: OpenPGP digital signature
Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
Hello! A recent build regression on ppc64el is preventing a new MariaDB version from migrating from unstable to testing. Could any experts on this list help out? Please use reply-to-all, I don't subscribe to the list. Builds on both ppc64 and ppc64el fail due to misc errors related to htmxlintrin: htmxlintrin.h:25:3: error: #error "HTM instruction set not enabled" htmxlintrin.h:58:25: error: ‘__builtin_tbegin’ was not declared in this scope; did you mean ‘__builtin_tan’? htmxlintrin.h:71:28: error: ‘__builtin_get_texasr’ was not declared in this scope; did you mean ‘__builtin_gettext’? htmxlintrin.h:108:3: error: ‘__builtin_tresume’ was not declared in this scope; did you mean ‘__builtin_trunc’? htmxlintrin.h:158:7: error: ‘__builtin_ttest’ was not declared in this scope; did you mean ‘__builtin_strstr’? Details at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006527
Bug#1005479: toil: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
Hi Paul, On 3/2/22 11:51 PM, Paul Gevers wrote: I tried re-triggering it to check once again but looks like runners are not up unfortunately. You mean the salsa ones, right? Yes And so if you could trigger a test suite for this package at your end once, and help debug it, that'd be really nice. What do you propose I look for? I'm not very good at debugging random software. Me neither, but I could propose to check for two things: a) As per Sascha's idea[1], if you can simply run the test once, and check there is nothing(no daemon/service) removing files in /tmp/.. dir b) If you could bypass the unlink (patch pasted below to do so) and check once, that would be great [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005479#10 --- a/src/toil/jobStores/fileJobStore.py +++ b/src/toil/jobStores/fileJobStore.py @@ -489,13 +489,16 @@ return except OSError as e: if e.errno == errno.EEXIST: -# Overwrite existing file, emulating shutil.copyfile(). -os.unlink(localFilePath) -# It would be very unlikely to fail again for same reason but possible -# nonetheless in which case we should just give up. -os.link(jobStoreFilePath, localFilePath) -# Now we succeeded and don't need to copy -return +try: +# Overwrite existing file, emulating shutil.copyfile(). +os.unlink(localFilePath) +# It would be very unlikely to fail again for same reason but possible +# nonetheless in which case we should just give up. +os.link(jobStoreFilePath, localFilePath) +# Now we succeeded and don't need to copy +return +except: +pass elif e.errno == errno.EXDEV: # It's a cross-device link even though it didn't appear to be. # Just keep going and hit the file copy case. OpenPGP_signature Description: OpenPGP digital signature
Bug#1006193: Remove luit, now packaged separately
On Wed, Mar 02, 2022 at 08:15:15PM +0100, Sven Joachim wrote: > On 2022-02-21 10:14 +1100, Brendan O'Dea wrote: > > > Package: x11-utils > > Version: 7.7+5 > > Severity: normal > > Tags: patch > > X-Debbugs-Cc: b...@debian.org > > > > Merge request to remove luit from x11-utils: > > > > https://salsa.debian.org/xorg-team/app/x11-utils/-/merge_requests/1 > > > > now packaged separately, this commit removes luit and adds a recommends for > > the new package. > > Thanks, I have merged that now. Are there any packages besides xterm > that use luit? On codesearch.debian.net I found some 75 hits[1], but > they seem to be either completely unrelated or only commentaries. I'm not aware of any other direct dependencies such as xterm. The occasional mention that I see for luit is for running it manually from the command-line, e.g., to make a shell for using emacs with some legacy character set. > Cheers, >Sven > > > 1. https://codesearch.debian.net/search?q=%5Cbluit%5Cb=0 > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1006687: libchipcard6: card.c leaks memory
Control: forwarded -1
https://www.aquamaniac.de/rdm/projects/libchipcard/repository/revisions/913b862a8a0678be0a2bd9f85213dea24081e2bf/diff/src/lib/client/base/card.c
Hi Michael,
thank you for reporting the issue to the Debian bug tracker. Assuming
your consent to distributing your patch under the LGPL v2.1 license, I
dared to commit it to the upstream Git repository on branch
"libchipcard5", which you can find here:
https://www.aquamaniac.de/rdm/projects/libchipcard/repository/revisions/913b862a8a0678be0a2bd9f85213dea24081e2bf/diff/src/lib/client/base/card.c
Unfortunately the patch didn't apply cleanly to the master branch. The
file card.c was since moved to src/libchipcard/base/card.c, yet changed
substantially so that a careful review would be appropriate.
Nevertheless, thank you to your contribution to Debian and Libchipcard.
Kind regards,
Micha
Am 02.03.22 um 13:36 schrieb Michael Klein:
Package: libchipcard6
Version: 5.1.5rc2-7
Severity: normal
Tags: patch upstream
Dear Maintainer,
while running a small inhouse application under AddressSanitizer I
stumbled over a few small memory leaks in card.c:
- the LC_CARD struct members readerType and driverType are not freed in
LC_Card_free()
- LC_Card_Select{Df,Ef,EfById}() leaks a GWEN_BUFFER local to the function
-- System Information:
Debian Release: 11.0
APT prefers impish-updates
APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500,
'impish'), (100, 'impish-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.13.0-30-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_DE.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 libchipcard6 depends on:
ii libc6 2.34-0ubuntu3
ii libchipcard-data 5.1.5rc2-7
ii libgwenhywfar79 5.6.0-2
ii libpcsclite1 1.9.3-2
ii zlib1g1:1.2.11.dfsg-2ubuntu7
libchipcard6 recommends no packages.
libchipcard6 suggests no packages.
-- no debconf information
Bug#1006699: kde-cli-tools: kde-cli-toold installation blocked by another package already installed kde-runtime
Hi, I can add a Breaks in kde-cli-tools but I won't stop the migration, because your situation is quite the exception. kde-runtime shouldn't exist on your computer anymore. It is an old Qt 4 library that was removed from Debian a couple of years ago. Why you still have it installed and why you never removed it, I don't know. -- Med vänliga hälsningar Patrick Franz
Bug#1006686: libchipcard-dev: now with patch
Control: tags -1 fixed-upstream Hi Michael, thank you for reporting the issue to the Debian bug tracker. Assuming your consent to distributing your patch under the LGPL v2.1 license, I dared to commit it to the upstream Git repository, which you can find here: https://www.aquamaniac.de/rdm/projects/libchipcard/repository/revisions/61eb11ada0cb5f9b16a7cb519f4165a4876ba636/diff/libchipcard-client.pc.in The file libchipcard-server.pc.in, which you also modified in your patch, doesn't exist anymore. Thank you to your contribution to Debian and Libchipcard. Kind regards, Micha Am 02.03.22 um 13:30 schrieb Michael Klein: Package: libchipcard-dev Followup-For: Bug #1006686 Dear Maintainer, this fixes it. -- System Information: Debian Release: 11.0 APT prefers impish-updates APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 'impish'), (100, 'impish-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-30-generic (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=de_DE.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 libchipcard-dev depends on: ii libchipcard-data 5.1.5rc2-7 ii libchipcard6 5.1.5rc2-7 libchipcard-dev recommends no packages. libchipcard-dev suggests no packages. -- no debconf information
Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Hi, On 01-03-2022 12:01, Paul Gevers wrote: This "fix" suggest there may be more breakage, normally the Release Team would schedule binNMU's. Can you please elaborate how ABI is normally maintained within swi-prolog, such that the rebuilds can be detected and requested? I fail to see how in the case of logol and swi-prolog the right versions are chosen. In other words, I think the "fixed" logol can migrate to testing even if swi-prolog does not and will be broken in testing until swi-prolog can migrate. Normally *versioned* dependencies should prevent this. I just read the backlog of the bug report (by default, submitters of bug reports in Debian don't get notified of messages, I missed the discussion). It seems my worry was already raised. The bug was reassigned to logol, so the swi-prolog maintainers missed my message. I checked, there are more reverse build dependencies of swi-prolog, I'm afraid there's more breakage that hasn't been detected yet. (eye seems to go in lockstep, so that package currently seems OK). Maybe swi-prolog maintainers can comment. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1006193: Remove luit, now packaged separately
On 2022-02-21 10:14 +1100, Brendan O'Dea wrote: > Package: x11-utils > Version: 7.7+5 > Severity: normal > Tags: patch > X-Debbugs-Cc: b...@debian.org > > Merge request to remove luit from x11-utils: > > https://salsa.debian.org/xorg-team/app/x11-utils/-/merge_requests/1 > > now packaged separately, this commit removes luit and adds a recommends for > the new package. Thanks, I have merged that now. Are there any packages besides xterm that use luit? On codesearch.debian.net I found some 75 hits[1], but they seem to be either completely unrelated or only commentaries. Cheers, Sven 1. https://codesearch.debian.net/search?q=%5Cbluit%5Cb=0
Bug#1006697: inkscape: Inkscape doesn't open GUI unless option -g is added
Control: tag -1 moreinfo unreproducible On Wed, Mar 02, 2022 at 06:21:20PM +0100, Krzysztof Sobiecki wrote: > I have installed Inkscape. But when tried to run it, nothing shows up. > Including right-click on svg file and choosing Inkscape, > using Inkscape icon in Gnome, running Inkscape from command line. > Only thing that helped was adding -g in command line(or to .desktop). > I have deleted Inkscape configuration(.config/.local) but it didn't help. Interesting. I don't see that, so I'd like to ask you: 1) if you just run `inkscape`, what's the output? 2) if you see an actual crash, please run that under gdb (with the -dbgsym installed) 3) can you also reproduce this with version 1.1.1-3 ? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1005479: toil: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
Hi, On 02-03-2022 16:53, Nilesh Patra wrote: Sascha even pointed out that it goes fine on reproducible build machines, and this package runs same build time test as autopkgtest Yes, but normally not in lxc. The salsa pipeline was passing as well[1] which IIRC uses similar setup as debci. True, as far as I'm aware. I tried re-triggering it to check once again but looks like runners are not up unfortunately. You mean the salsa ones, right? ci.d.n runners should all be up. And so if you could trigger a test suite for this package at your end once, and help debug it, that'd be really nice. What do you propose I look for? I'm not very good at debugging random software. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1006698: RFS: rednotebook/2.24+ds-1~bpo10+1 -- Modern desktop diary and personal journaling tool
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rednotebook": * Package name: rednotebook Version : 2.24+ds-1~bpo10+1 Upstream Author : Jendrik Seipp * URL : https://rednotebook.app * License : LGPL-3+, PSF-2, CC0-1.0, GPL-2+, GPL-3+ * Vcs : https://github.com/jendrikseipp/rednotebook Section : text It builds those binary packages: rednotebook - Modern desktop diary and personal journaling tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rednotebook/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.24+ds-1~bpo10+1.dsc Changes since the last upload: rednotebook (2.24+ds-1~bpo10+1) buster-backports; urgency=medium . * Rebuild for buster-backports. Regards Phil -- *** Playing the game for the games own sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#991378: This bug is still alive
On Fri, Jan 07, 2022 at 10:31:26PM -0500, Michael Stone wrote: > agreed, someone should fix xdg-desktop-portal to not cause errors Regardless of how this can be solved in xdg-desktop-portal (and as far as I'm aware there is no fix at the moment) this can also be solved by a patch in gnulib/coreutils. Coreutils 9.0 is already out and contains the solution for this problem, so once the package is updated this will be solved. This also happens in bullseye, in that case the one-liner mentioned by Vincent Lefevre can be cherry-picked. Berto
Bug#1006681: atop: ethernet speed broken
On 02.03.2022 16:53, Marc Haber wrote: Hi, On Wed, Mar 02, 2022 at 12:28:43PM +0300, Nickolay Novikov wrote: Atop always show zero speed for ethernet network interfaces. For example: NET | eth0 | pcki 17472 | pcko 18327 | sp0 Mbps | si 46 Mbps | so 10 Mbps | erri 0 | erro 0 | is it possible for you to install Debian testing on a reference system and see whether atop 2.7.1 from testing works for you? I built atop version 2.7.1-1 from bookworm on host with debian bullseye. This version works correctly. Is it possible to push it to bullseye? Upstream commit commit 1a8228cb859fb754c3c9db4d08671e9ea7fbc207 Author: Gerlof Langeveld Date: Sat Nov 20 14:53:46 2021 +0100 Speed and duplex mode not correctly filled for interface In case of handshaked ETHTOOL_GLINKSETTINGS the speed and duplex mode were not correctly filled. M ifprop.c might have addressed this and solved the issue in atop 2.7.1 Greetings Marc
Bug#1006697: inkscape: Inkscape doesn't open GUI unless option -g is added
Package: inkscape Version: 1.1.2-3 Severity: important X-Debbugs-Cc: sob...@gmail.com Dear Maintainer, I have installed Inkscape. But when tried to run it, nothing shows up. Including right-click on svg file and choosing Inkscape, using Inkscape icon in Gnome, running Inkscape from command line. Only thing that helped was adding -g in command line(or to .desktop). I have deleted Inkscape configuration(.config/.local) but it didn't help. Thanks Krzysztof Sobiecki -- System Information: Debian Release: bookworm/sid APT prefers experimental APT policy: (501, 'experimental'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-rc5-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inkscape depends on: ii lib2geom1.1.0 1.1-2+b1 ii libatkmm-1.6-1v5 2.28.2-1 ii libboost-filesystem1.74.0 1.74.0-14 ii libc6 2.34-0experimental3 ii libcairo2 1.16.0-5 ii libcairomm-1.0-1v5 1.12.2-4 ii libcdr-0.1-1 0.1.6-2 ii libdbus-glib-1-2 0.112-2 ii libfontconfig1 2.13.1-4.4 ii libfreetype6 2.11.1+dfsg-1 ii libgc1 1:8.0.6-1.1 ii libgcc-s1 12-20220214-1 ii libgdk-pixbuf-2.0-02.42.6+dfsg-2 ii libglib2.0-0 2.71.2-1 ii libglibmm-2.4-1v5 2.66.2-2+b1 ii libgomp1 12-20220214-1 ii libgsl27 2.7.1+dfsg-3 ii libgspell-1-2 1.9.1-4 ii libgtk-3-0 3.24.31-1 ii libgtkmm-3.0-1v5 3.24.5-1 ii libharfbuzz0b 2.7.4-1 ii libjpeg62-turbo1:2.1.2-1 ii liblcms2-2 2.12~rc1-2 ii libmagick++-6.q16-88:6.9.11.60+dfsg-1.3+b2 ii libpango-1.0-0 1.50.4+ds-1 ii libpangocairo-1.0-01.50.4+ds-1 ii libpangoft2-1.0-0 1.50.4+ds-1 ii libpangomm-1.4-1v5 2.46.2-1 ii libpng16-161.6.37-3 ii libpoppler-glib8 22.02.0-2 ii libpoppler102 20.09.0-3.1 ii libpotrace01.16-2 ii libreadline8 8.1.2-1 ii librevenge-0.0-0 0.0.4-6+b1 ii librsvg2-common2.52.5+dfsg-3+b1 ii libsigc++-2.0-0v5 2.10.4-2 ii libsoup2.4-1 2.74.2-3 ii libstdc++6 12-20220214-1 ii libvisio-0.1-1 0.1.7-1+b1 ii libwpg-0.3-3 0.3.3-1 ii libx11-6 2:1.7.2-2+b1 ii libxml22.9.13+dfsg-1 ii libxslt1.1 1.1.34-4 ii python33.9.8-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages inkscape recommends: ii aspell 0.60.8-4 ii fig2dev 1:3.2.8b-1 ii imagemagick 8:6.9.12.20+dfsg1-1.2 ii imagemagick-6.q16 [imagemagick] 8:6.9.12.20+dfsg1-1.2 pn libimage-magick-perl ii libwmf-bin 0.2.12-5 ii python3-lxml 4.8.0-1 ii python3-numpy1:1.22.1-1 ii python3-scour0.38.2-2 Versions of packages inkscape suggests: pn dia ii inkscape-tutorials1.1.2-3 pn libsvg-perl pn pstoedit pn python3-uniconvertor ii ruby 1:3.0 -- debconf-show failed
Bug#964947: dhcpcd5: New upstream version available: 9.1.4
On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine wrote: > > On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R. wrote: > > > > El 28/02/22 a las 16:52, Martin-Éric Racine escribió: > > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine > > > wrote: > > > > > > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine > > > > wrote: > > > > > > > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. > > > > > wrote: > > > > > > * Could you please fix the indentation of the your new entry in > > > > > > d/copyright? > > > > > > > > > > IMHO, the whole file's indentation needs to be fixed. I had troubles > > > > > aligning my addition, because the file currently uses TAB+2SPACES. > > > > > There really should be a linting tool for that. > > > > > > > > Actually, it seems that wrap-and-sort can be used for d/copyright too. > > > > I somehow was under the impression that it's only used for d/control. > > > > I'm extremely tempted to run it on the whole package. > > > > > > Reading back on Bug #964947, I notice that the request was for both > > > packaging current upstream and dropping the 5 out of the package name. > > > I would tend to agree. The 5 really only was meant as an upstream > > > branch tag. The source and binary really should be called 'dhcpcd' > > > since it essentially is a fork of the abandoned source of the same > > > name. > > > > Changing the source name means creating (or reintroducing) a different > > debian package. Just in case: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743218 > > > > Changing the binary name only means it would have to pass by NEW… > > Merely changing the binary name sounds perfectly reasonable to me. Please note that I have re-uploaded the package to Mentors. The log file is more explicit about cosmetic changes and about ./configure caveats. Martin-Éric
Bug#1006696: network-manager-openvpn: No warning to the user when some elements from the .ovpn cannot be imported
Package: network-manager-openvpn Version: 1.8.16-1 Severity: wishlist X-Debbugs-Cc: jo...@alternativaslibres.es Dear Maintainer, When importing .ovpn files into network manager, there is no warning or message whatsoever to the user that some of the elements could not be imported. It would be desired that, either on the GUI or when using nmcli, if any of the settings on the .ovpn file are not (or cannot) be imported, these are listed or at least a warning is shown indicating to the user that they might need to take additional steps to have their connection behave (or work) on Network Manager in a similar manner as what they would expect if they were using openvpn connection.ovpn on the command line. One obvious example of this could be when the .ovpn file contains "up" or "down" scripts or commands. Probably some users would like something to be automagically added into /etc/NetworkManager/dispatcher.d, but since this could be problematic or hard to do (without taking into account other scripts already there, or which name will the tun/tap interface will have, etc.), maybe just showing a message to the user indicating something along the lines of: "Up/Down scripts in the .ovpn file could not be imported automatically. Please consider using a script under /etc/NetworkManager/dispatcher.d as necessary (with reference to the documentation or NetworkManager-dispatcher manpage)" This issue could be considered somewhat related to issue #818147. However, since what is being requested is different, I preferred to open a separate issue on the bug tracker. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-openvpn depends on: ii adduser 3.118 ii libc62.33-7 ii libglib2.0-0 2.70.4-1 ii libnm0 1.36.0-1 ii network-manager 1.36.0-1 ii openvpn 2.5.5-1 network-manager-openvpn recommends no packages. network-manager-openvpn suggests no packages. -- no debconf information
Bug#997851: Update on doas package status
This issue has been open for several months now without an update and I'd like to encourage its resolution. The upstream doas project is still getting issue reports [1] which are resulting from confusion in the naming between "doas" versus "OpenDoas". Ideally this package should have its name changed or point to the upstream corresponding with the package name. I'd also like to respond to the post linked to by Andrea Pappacoda in the previous comment if I may. I have two thoughts on that. One is that the bugs reported as concerns were fixed and aren't relevant anymore and were handled before this Debian bug report was filed. I thin it should be considered out of date. The other is that one of the supposed flaws reported was incorrect (due to a misunderstanding on the filer's part on how UIDs were handled by doas) and, when this was explained to the person filing the issue they went on a misinformation and harassment campaign across multiple social media platforms against the slicer69/doas port. Blog posts like the one linked to above about "slicer69-doas" were the result and based on the misunderstanding of security issues by the original person filing the bug report. I'm not saying there weren't bug issues during the porting process, just that some of them which were (in the above post's words "treated superficially") were actually dismissed for being incorrect or not what the issue reporter claimed. None of them were particular serious either as they'd require root access to exploit. This may not be entirely relevant to the decision on how to name Debian packages, but I wanted to clear the record as I feel the article linked to by Pappacoda isn't representative of the real situation in terms of doas vs OpenDoas. Both projects are good at what they do and both have had some flaws fixed. I don't think one should be considered "better" or "more of a true doas" over the other. But I do think Debian's naming approach should reflect upstream to avoid confusion. I do agree with Pappacoda that having Debian "doas" be a virtual package with "opendoas" and "doas-portable" being the underlying real packages makes sense. 1. https://github.com/slicer69/doas/pull/99
Bug#1005479: toil: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
Hi Paul, On 3/2/22 9:09 PM, Paul Gevers wrote: On 02-03-2022 14:58, Nilesh Patra wrote: @Paul, could you please help reproduce this in the debci environment and help us with any clues as to what might be wrong? The autopkgtest command line is at the top of each log. I am aware, and I use something $similar, but that is not working for me and Sascha locally, hence asked for help :) Sascha even pointed out that it goes fine on reproducible build machines, and this package runs same build time test as autopkgtest The salsa pipeline was passing as well[1] which IIRC uses similar setup as debci. I tried re-triggering it to check once again but looks like runners are not up unfortunately. And so if you could trigger a test suite for this package at your end once, and help debug it, that'd be really nice. [1]: https://salsa.debian.org/med-team/toil/-/jobs/2396200 Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Bug#1005479: toil: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
Hi, On 02-03-2022 14:58, Nilesh Patra wrote: @Paul, could you please help reproduce this in the debci environment and help us with any clues as to what might be wrong? The autopkgtest command line is at the top of each log. | File "/usr/lib/python3/dist-packages/toil/jobStores/fileJobStore.py", line 498, in read_file |os.link(jobStoreFilePath, local_path) | OSError: [Errno 18] Invalid cross-device link: '/tmp/autopkgtest-lxc.rgt3f050/downtmp/build.YHo/src/jobstore-test-de9381ff-d8be-4b36-a691-be2c5fa759d2/files/no-job/file-d7145278c6b84845bd03cf5cff29e690/stream' -> '/home/debci/tmp/tmp1lgiu28c' > It looks (to me) that home and tmp are mounted on different partitions and os.link does not work with such a setting. I *think* the /tmp inside the lxc is mapped to /tmp of the host. /home is completely native to the container. (Not sure if all this matters). On *some* architectures /tmp and /var/lib/lxc of the host are on a separate partitions with respect to the rest. I'm pretty sure that for all our architectures all files inside the container are on the same partition. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#997969: Failure with latest upstream
Control: forwarded -1 https://github.com/stefanberger/libtpms/issues/298 With 0.10.0~dev1 it doesn't build too. F. signature.asc Description: PGP signature
Bug#971783: Any news ?
Hi Mike, there is a workarround to auto restart the mate-volume-control-status-icon when it suddenly stops: $ systemctl --user edit app-mate\\x2dvolume\\x2dcontrol\\x2dstatus\\x2dicon-autostart.service Add between commented lines: [Service] Restart=always $ systemctl --user daemon-reload $ systemctl --user restart app-mate\\x2dvolume\\x2dcontrol\\x2dstatus\\x2dicon-autostart.service Max. 15 février 2022 22:01 "Mike Gabriel" a écrit: > On So 13 Feb 2022 10:37:22 CET, Maxime G. wrote: > >> Hello. >> >> In Debian stable we try to have stable packages. But >> volume-control-applet is not stable and crashes. >> Despite the logs I sent earlier, here is a way to reproduce the problem: >> - Connect a bluetooth speaker. >> - Switch the main output of pulseaudio to the speaker. >> - Play a media (web browser or player) >> - Turn off the bluetooth speaker. >> -> volume-control-applet crash >> >> Thank you. > > This will surely help finding the issue. I haven't had time for this, > yet. But with a fool proof way of reproducing this, chances to get > this fixes are getting bigger. > > Thanks, > Mike > > -- > > DAS-NETZWERKTEAM > c\o Technik- und Ökologiezentrum Eckernförde > Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde > mobile: +49 (1520) 1976 148 > landline: +49 (4351) 850 8940 > > GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 > mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
Hi, Am Mittwoch, dem 02.03.2022 um 16:43 +0200 schrieb Per Lundberg: [...] > (Speaking about tomcat10, I noted the package in experimental is really > old - doesn't seem to have been updated for a few years. Do you know if > anyone is working on updating the package to e.g. Tomcat 10.0.17 or will > it perhaps happen later in the Bookworm release cycle?) I intend to update it in the near future. I believe the initial goal was to make it co-installable with Tomcat 9. Currently there are still some file conflicts which have to be resolved before we can upload Tomcat 10 to unstable. > > Also, I wonder if it wouldn't even make sense to remove openjdk-8-jdk > altogether from unstable at this point. The fact that it's present there > is actually a bit confusing, since it gives the (completely false) > impression that JDK 8 will be supported in future versions of Debian. If > you agree, I can file a separate removal bug on that package. (I'm not > currently a Debian maintainer myself, so I cannot help out more than > that. ;) We still need OpenJDK 8 to bootstrap Kotlin. Please don't ask for its removal. It would be great if we could use OpenJDK 11 instead but we are not there yet. > > As for the actual libeclipse-jdt-core-java package, is there any > particular reason for going with the 4.21 version in Debian unstable & > bookworm? I am just curious. It feels like a somewhat odd decision to go > with a more recent version than the 4.20 version which Apache bundles in > their distribution. But perhaps there are other Debian packages which > can find use of the newer package, or has it perhaps just been done to > be able to ship the "latest and greatest" version of this package with > Bookworm? (I mean: to not ship something which is "old" already at the > time of release.) I guess there was no particular reason other than upgrading to the latest available version back then. I have not investigated yet if another Debian package requires 4.21 specifically but since we don't really support Java 8 anymore I think we can just move forward. Tomcat 9 will be gone next year and since we rather have to invest time into fixing OpenJDK 17 bugs than making packages Java 8 compatible, I would say let's keep it as is. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#791391: Testing again use of auto setting
Hello, I had a very similar issue in Debian 9. A Debian 9 system that indeed has interface configured with allow-hotplug stanza in /etc/network/interfaces file, it fails to mount nfs shares (over nfs4.0). From the journal it seems that dhclient finishes **after** networking.service is activated. Networking.service is the one that calls ifup -a. Hence other services including nfs mounts are started early. But if auto ensxx is added to interfaces then ordering is correct (networking service is activated after ifup -a). I don't know if this is documented somewhere. But it is important to note! VG Debian 9.13 ifupdown 0.8.19 systemd 232-25+deb9u13 /etc/fstab 10.2.0.10:/data/oc-data /data/oc-data nfs timeo=20,_netdev 0 0 /etc/network/intefaces # The primary network interface allow-hotplug ens14 iface ens14 inet dhcp Logs excerpt from "journalctl -b" after a failed auto mount reboot allow-hotplug ens14 iface ens14 inet dhcp Μάρ 02 15:37:08 host1 systemd[1]: Started Raise network interfaces. Μάρ 02 15:37:10 host1 systemd[1]: Reached target Remote File Systems (Pre). Μάρ 02 15:37:10 host1 systemd[1]: Reached target RPC Port Mapper. Μάρ 02 15:37:10 host1 systemd[1]: Reached target Network is Online. Μάρ 02 15:37:10 host1 dhclient[439]: Copyright 2004-2016 Internet Systems Consortium Μάρ 02 15:37:10 host1 systemd[1]: Mounting /data/oc-data... Μάρ 02 15:37:11 host1 dhclient[439]: DHCPDISCOVER on ens14 to 255.255.255.255 port 67 interval 7 Μάρ 02 15:37:11 host1 dhclient[439]: DHCPREQUEST of 10.2.0.4 on ens14 to 255.255.255.255 port 67 Μάρ 02 15:37:11 host1 dhclient[439]: DHCPOFFER of 10.2.0.4 from 10.2.0.1 Μάρ 02 15:37:11 host1 dhclient[439]: DHCPACK of 10.2.0.4 from 10.2.0.1 Μάρ 02 15:37:11 host1 systemd[1]: data-oc\x2ddata.mount: Mount process exited, code=exited status=32 Μάρ 02 15:37:11 host1 systemd[1]: Failed to mount /data/oc-data. --- #allow-hotplug ens14 auto ens14 iface ens14 inet dhcp Μάρ 02 16:17:52 host1 systemd[1]: Starting Raise network interfaces.. Μάρ 02 16:17:56 host1 dhclient[455]: DHCPOFFER of 10.2.0.4 from 10.2.0.1 Μάρ 02 16:17:56 host1 ifup[420]: DHCPOFFER of 10.2.0.4 from 10.2.0.1 Μάρ 02 16:17:56 host1 dhclient[455]: DHCPACK of 10.2.0.4 from 10.2.0.1 Μάρ 02 16:17:56 host1 ifup[420]: DHCPACK of 10.2.0.4 from 10.2.0.1 Μάρ 02 16:17:57 host1 ifup[420]: bound to 10.2.0.4 -- renewal in 2959 seconds. Μάρ 02 16:17:57 host1 systemd[1]: Started Raise network interfaces. Μάρ 02 16:17:57 host1 systemd[1]: Reached target Network. Μάρ 02 16:17:57 host1 systemd[1]: Reached target Network is Online. Μάρ 02 16:17:57 host1 systemd[1]: Mounting /data/oc-data... Μάρ 02 16:17:59 host1 systemd[1]: Mounted /data/oc-data. allow-hotplug ens14 auto ens14 iface ens14 inet dhcp Μάρ 02 16:28:23 host1 systemd[1]: Starting Raise network interfaces... Μάρ 02 16:28:25 host1 sh[375]: DHCPOFFER of 10.2.0.33 from 10.2.0.1 Μάρ 02 16:28:25 host1 dhclient[422]: DHCPOFFER of 10.2.0.33 from 10.2.0.1 Μάρ 02 16:28:25 host1 dhclient[422]: DHCPACK of 10.2.0.33 from 10.2.0.1 Μάρ 02 16:28:25 host1 sh[375]: DHCPACK of 10.2.0.33 from 10.2.0.1 Μάρ 02 16:28:26 host1 dhclient[422]: bound to 10.2.0.33 -- renewal in 2976 seconds. Μάρ 02 16:28:26 host1 systemd[1]: Started Raise network interfaces. Μάρ 02 16:28:26 host1 systemd[1]: Reached target Network. Μάρ 02 16:28:26 host1 systemd[1]: Reached target Network is Online. Μάρ 02 16:28:26 host1 systemd[1]: Mounting /data/oc-data...
Bug#1006208: [Pkg-shadow-devel] Bug#1006208: shadow: trying to improve man pwck
Thank you. I will take these diffs (4 I believe?), do one final review, and push to github.com/shadow-maint/shadow under commits with you as Author. On Mon, Feb 21, 2022 at 12:40:07PM +0100, Markus Hiereth wrote: > Source: shadow > Version: 4.8.1 > Severity: minor > > Dear Serge, > > in accordance your mail from 2022-02-20 (attached) an edited manual xml file > and the respective patch file. > > Best regards > Markus > On Wed, Feb 16, 2022 at 09:42:34PM +0100, Markus Hiereth wrote: > > Hi Serge and shadow-utils developers > > > > a few remarks on this manual page. I do not know whether a bug report > > or a patch are appreciated. > > > > Best regards > > Markus > > > > > > 69 > > 70 pwck > > 71 verify integrity of password files > > 72 > > > > s/verify integrity/verify the integrity > > > > > > > > 75 > > 76 pwck > > 77 options > > 78 > > 79 > > 80 passwd > > 81 > > 82 > > 83 > > 84 shadow > > 85 > > 86 > > 87 > > 88 > > > > Replaceables appear in capital letters elsewhere, the name of the > > argument shall indicate that the name of the two files is not > > pre-defined, thus write: > > > > 80 PASSWORDFILE > > 84 SHADOWFILE > > > > > > > > 128 shadow checks are enabled when a second file > > 129 parameter is specified or when /etc/shadow > > 130 exists on the system. > > > > I think "shadow" in "shadow checks" is meant in a general > > sense. Therefore, if xml is used for mark-up, it should not be the filename > > element, but the replaceable element. Or write: > > > > 128 Checks for shadowed password information are enabled when a second > > 129 file parameter is specified or when /etc/shadow > > That's all fine. > > > > > > > 162 checks will still be made. All other errors are warning and the user > > 163 is encouraged to run the usermod command to > > correct > > > > Is "warning" here the participe present from the verb "to warn". In > > case it is the plural of the noun "a warning", add the plural-s. Or write: > > > > ... All other errors warn the user and encourage him to run the > > usermod > > It's just meant as the plural of warning, so simplest would be to just > say 'All other errors are warnings and..." > > thanks, > -serge > --- shadow-4.8.1/man/pwck.8.xml 2019-10-05 03:23:58.0 +0200 > +++ shadow-4.8.1_mh/man/pwck.8.xml2022-02-21 12:30:25.634576331 +0100 > @@ -68,7 +68,7 @@ > > > pwck > -verify integrity of password files > +verify the integrity of password files > > > > @@ -77,11 +77,11 @@ >options > > > - passwd > + PASSWORDFILE > > > > - shadow > + SHADOWFILE > > > > @@ -123,11 +123,10 @@ > a valid login shell > > > - > > - shadow checks are enabled when a second file > - parameter is specified or when /etc/shadow > - exists on the system. > + Checks for shadowed password information are enabled when the second > + file parameter SHADOWFILE is specified or > + when /etc/shadow exists on the system. > > >These checks are the following: > @@ -159,7 +158,7 @@ >prompted to delete the entire line. If the user does not answer >affirmatively, all further checks are bypassed. An entry with a >duplicated user name is prompted for deletion, but the remaining > - checks will still be made. All other errors are warning and the user > + checks will still be made. All other errors are warnings and the user >is encouraged to run the usermod command to correct >the error. > > > >"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [ > > > > > > > > ]> > > > > > Julianne Frances > Haugh > Creation, 1992 > > > Thomas > Kłoczko > kloc...@pld.org.pl > shadow-utils maintainer, 2000 - 2007 > > > Nicolas > François > nicolas.franc...@centraliens.net > shadow-utils maintainer, 2007 - now > > > > pwck > 8 > System Management Commands > shadow-utils > _UTILS_VERSION; > > > pwck > verify the integrity of password files > > > > > pwck > options > > > PASSWORDFILE > > > > SHADOWFILE > > > > > > > > DESCRIPTION > > The pwck command verifies the integrity of the > users and authentication information. It checks that all entries in > /etc/passwd and /etc/shadow > (or the files in > /etc/tcb, when USE_TCB is > enabled) > have the proper format and contain valid data. > The user
Bug#1006694: debianutils: update-shells --root default and merged-/usr support
Source: debianutils Version: 5.7-0.1 Severity: normal Tags: patch User: debian-d...@lists.debian.org Usertags: dpkg-root-support X-Debbugs-Cc: jo...@debian.org Hi, I'm filing this as a tracking bug with usertags for the following two MR I filed on salsa: https://salsa.debian.org/debian/debianutils/-/merge_requests/21 https://salsa.debian.org/debian/debianutils/-/merge_requests/22 I think MR !22 is optional and only useful if you agree that it would make sense to have the same defaults for the --root argument as update-alternatives and dpkg-divert. Thanks! cheers, josch
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
Hi Markus, On 2022-03-02 14:15, Markus Koschany wrote: As a matter of fact OpenJDK 11 is the only supported Java version in oldstable, stable and testing right now. We plan to release with Java 17 next year and one of our goals is to ship only Tomcat 10 in Debian 12 "Bookworm". I think you are right that we should tighten the dependency to java11-runtime-headless to avoid any confusion but as I said, OpenJDK 11 is the only supported JDK/JRE at the moment. If you cannot upgrade your application to Java 11, then you could create a custom Tomcat 9 package or simply downgrade libeclipse-jdt-core-java to 4.20 again. Thanks for clarifying these things and mentioning the plan from the Debian Java maintainers in this case. I remember discussing something similar (JDK 11 only to be supported) a few years ago with you in fact; the problem was with visualvm at that time. :) (Speaking about tomcat10, I noted the package in experimental is really old - doesn't seem to have been updated for a few years. Do you know if anyone is working on updating the package to e.g. Tomcat 10.0.17 or will it perhaps happen later in the Bookworm release cycle?) Also, I wonder if it wouldn't even make sense to remove openjdk-8-jdk altogether from unstable at this point. The fact that it's present there is actually a bit confusing, since it gives the (completely false) impression that JDK 8 will be supported in future versions of Debian. If you agree, I can file a separate removal bug on that package. (I'm not currently a Debian maintainer myself, so I cannot help out more than that. ;) As for the actual libeclipse-jdt-core-java package, is there any particular reason for going with the 4.21 version in Debian unstable & bookworm? I am just curious. It feels like a somewhat odd decision to go with a more recent version than the 4.20 version which Apache bundles in their distribution. But perhaps there are other Debian packages which can find use of the newer package, or has it perhaps just been done to be able to ship the "latest and greatest" version of this package with Bookworm? (I mean: to not ship something which is "old" already at the time of release.) Best regards, Per
Bug#1006633: procmail is unmaintained upstream
Hi Stephen (and Santiago), Do you plan to pass a significant security audit over the procmail code base and fuzz the binary? I don't think fixing the handful of security issues that were publicly disclosed is enough, to be honest. I don't know how else to put this; I am truly grateful for the amazing work you've done on all those projects. I have used procmail myself extensively, probably for almost two decades, before switching away, and it was amazing for the time I used it. But software security has changed a lot in the past 20 years. Even C has moved on. The current codebase is littered with things like strcpy and difficult to parse macros. The coding style is historically interesting, but would be rather surprising to many reviewers. With my security researcher hat on, I am confident there are still significant security issues in procmail, even with the fixes committed to the git repository you have pointed out. I do not believe that, in its current state, procmail should be shipped in the next Debian release, let alone with SUID bits by default. So while it's interesting that you are making procmail active again, maybe we could be careful about including it in the next Debian release? Let's see if it can be brought back to shape and deal with the modern threats email servers are currently faced with. I don't mean to necessarily completely remove procmail from Debian if it eventually finds its way towards a more secure and maintainable codebase, but I strongly feel it's not fit for release in its current shape. Thank you for your understanding, a.
Bug#1002166: RM: sdrangelove -- RoM; dead upstream
Control: clone -1 -2 Control: retitle -2 RM: sdrangelove -- RoM; dead upstream Control: severity -2 normal Control: reassign -2 ftp.debian.org > > Source: sdrangelove > > Version: 0.0.1.20150707-5 > > Severity: serious > > Justification: FTBFS > > Tags: bookworm sid ftbfs > > User: lu...@debian.org > > Usertags: ftbfs-20211220 ftbfs-bookworm > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed to build > > on amd64. > > sdrangelove hasn't really been touched upstream since 2015 (except 3 > more or less boring git commits), so I propose we remove it. Doing that now: Please remove sdrangelove from unstable. Christoph
Bug#1006692: glibc: libc6 postinst: do not re-exec init if DPKG_ROOT is set
Source: glibc
Version: 2.33-7
Severity: normal
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support
X-Debbugs-Cc: jo...@debian.org
Hi,
when glibc is installed with $DPKG_ROOT set to a non-empty string, then
"systemctl daemon-reexec" or "telinit" should not be executed, similarly
to when the postinst is run inside a chroot. I filed a MR [1] and put
the patch at the end of this mail.
Thanks!
cheers, josch
[1] https://salsa.debian.org/glibc-team/glibc/-/merge_requests/5
--- a/debian/debhelper.in/libc.postinst
+++ b/debian/debhelper.in/libc.postinst
@@ -157,6 +157,9 @@ then
if ischroot 2>/dev/null; then
# Don't bother trying to re-exec init from a chroot:
TELINIT=no
+elif [ -n "${DPKG_ROOT:-}" ]; then
+# Do not re-exec init if we are operating on a chroot from outside:
+TELINIT=no
elif [ -d /run/systemd/system ]; then
# Restart systemd on upgrade, but carefully.
# The restart is wanted because of LP: #1942276 and Bug: #993821
Bug#1006679: libosip2: please consider updating
If anyone wants to update libosip2 And libexosip2, I would be very happy to help. Only the newer versions would be of some interests anyway. Aymeric (author) Le mer. 2 mars 2022 à 11:12, Jonas Smedegaard a écrit : > Quoting Gavin Henry (2022-03-02 10:48:15) > > Mine does - https://mentors.debian.net/package/sentrypeer/ > > > > That's why I mentioned it, but SentryPeer isn't in yet. > > Ah, good to know - thanks! > > Also, SentryPeer looks quite cool! I noticed the ITP for it, and am > looking forward to see that in Debian: Thanks for working on that. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#1005479: toil: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
control: severity -1 serious control: tags -1 moreinfo On Sat, 19 Feb 2022 19:11:52 +0100 Sascha Steinbiss wrote: > Unfortunately I cannot reproduce this. +1 > toil 5.6.0-2 builds in unstable > with no problems locally (amd64) and on the Reproducible Builds build > cluster [1] on amd64, arm64, i386 and armhf. See attached diff of build > logs. CC'ed elbrus. @Paul, could you please help reproduce this in the debci environment and help us with any clues as to what might be wrong? > My hunch after looking at the error message would be a timing issue with > /tmp cleanups running while the tests are running? The tests take a long > time so maybe something may have deleted test data at the wrong time? Could be; also on looking at recent debci logs[2] | File "/usr/lib/python3/dist-packages/toil/jobStores/fileJobStore.py", line 498, in read_file |os.link(jobStoreFilePath, local_path) | OSError: [Errno 18] Invalid cross-device link: '/tmp/autopkgtest-lxc.rgt3f050/downtmp/build.YHo/src/jobstore-test-de9381ff-d8be-4b36-a691-be2c5fa759d2/files/no-job/file-d7145278c6b84845bd03cf5cff29e690/stream' -> '/home/debci/tmp/tmp1lgiu28c' It looks (to me) that home and tmp are mounted on different partitions and os.link does not work with such a setting. Maybe you could simply do an atomic copy and try once. > I will lower the severity since I cannot confirm this to be a constant > FTBFS. Unfortunately, that does not help us much. It is failing in debci even on a fresh run today as you can also see in excuses[3] and so we need to fix it. I have re-bumped to serious and added a moreinfo tag, so atleast this is in the next tasks to check. > [1] > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/toil.html [2]: https://ci.debian.net/data/autopkgtest/testing/amd64/t/toil/19660240/log.gz [3]: https://qa.debian.org/excuses.php?package=toil Regards, Nilesh signature.asc Description: PGP signature
Bug#1006691: nvidia-cudnn: does not remove temporary downloaded files
Package: nvidia-cudnn Version: 8.2.4.15~cuda11.4 Severity: normal Thanks for this useful package! The script has a --keep option advertised, but it is not actually implemented; the downloaded files are kept in /tmp whether or not this option is used. Best wishes, Julian
Bug#1006681: atop: ethernet speed broken
Hi, On Wed, Mar 02, 2022 at 12:28:43PM +0300, Nickolay Novikov wrote: > Atop always show zero speed for ethernet network interfaces. For example: > NET | eth0 | pcki 17472 | pcko 18327 | sp0 Mbps | si 46 > Mbps | so 10 Mbps | erri 0 | erro 0 | is it possible for you to install Debian testing on a reference system and see whether atop 2.7.1 from testing works for you? Upstream commit commit 1a8228cb859fb754c3c9db4d08671e9ea7fbc207 Author: Gerlof Langeveld Date: Sat Nov 20 14:53:46 2021 +0100 Speed and duplex mode not correctly filled for interface In case of handshaked ETHTOOL_GLINKSETTINGS the speed and duplex mode were not correctly filled. M ifprop.c might have addressed this and solved the issue in atop 2.7.1 Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006685: kde-plasma-desktop: KDE does not display Emojis correctly
Hi Max, > One can reproduce it by running `echo "Heart Face Emoji 殺"` in Konsole > or by opening https://www.youtube.com/watch?v=YaYoJziCgto in Fireofox or > Konqueror. The emojis will be displayed only as blank rectangles. > > The problem does not occur on Ubuntu. It also does not occur when using > Debian/Xfce and when using the Xfce-Terminal from within a Plasma Qt has not auto-fallback, so this has to be activated for fontconfig. I just tried it myself on Arch (I am running) and didn't see the emojis. Then I did: - install fonts-noto-emoji - added configuration to /etc/fonts/local.conf (easily findable on the internet what is necessary) And now emojis are properly shown in konsole, as well as other Qt based programs. > I tried to set a different font, but to no avail. Maybe I have not tried > hard enough. However, I think Emojis should be displayed properly in the > default configuration. The problem is that: - the default font you set is for text, and emojis are most likely not contained in the font you set - the libraries in use need to deal with missing glyphs in the defined font, and there are several ways to do it. One is to display TOFU This is not specific to KDE, but to fontconfig and how Debian handles fallback fonts. Best Norbert -- PREINING Norbert https://www.preining.info Fujitsu Research +IFMGA Guide +TU Wien+TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#1001542: perl: Hurd: sysread() fails with a "Bad file descriptor" error
On Tue, Mar 01, 2022 at 07:26:24PM +0200, Niko Tyni wrote:
> Hi, sorry for the delay.
>
> On Sun, Dec 12, 2021 at 12:15:50AM +0200, Peter Pentchev wrote:
> > Package: perl
> > Version: 5.32.1-6
> > Severity: normal
>
> > [roam@exodar ~]$ perl -e 'use v5.10; use strict; use warnings; sysopen my
> > $fh, "/bin/ls", 0 or die "sysopen: $!\n"; say "fd ".fileno $fh; my $data;
> > sysread $fh, $data, 32 or die "sysread: $!\n"; say length $data;'
> > fd 3
> > sysread: Bad file descriptor
>
> Quoting https://www.gnu.org/software/libc/manual/html_node/Access-Modes.html
>
> On GNU/Hurd systems (but not on other systems), O_RDONLY and O_WRONLY
> are independent bits that can be bitwise-ORed together, and it is
> valid for either bit to be set or clear. This means that O_RDWR is the
> same as O_RDONLY|O_WRONLY. A file access mode of zero is permissible;
> it allows no operations that do input or output to the file, but does
> allow other operations such as fchmod.
>
> Indeed, using Fcntl::O_RDONLY instead of 0 works fine for me on exodar.
>
> Python behaves the same btw:
>
> exodar% python3 -c 'import os; print(len(os.read(os.open("/bin/ls", 0),
> 32)))'
> Traceback (most recent call last):
> File "", line 1, in
> OSError: [Errno 1073741833] Bad file descriptor
>
> Closing, but let me know if there are still issues.
Oh wow. That was embarrassing. Thanks a *lot* for looking at this and
for pointing out the blindingly obvious.
I really have no idea how that happened... I mean, I *never* write
open(..., 0) in C; I have no idea why I wrote it there and why
I did not notice it afterwards.
Thanks again, sorry for wasting your time, and keep up the great work!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#1006690: silx autopkg tests fail (missing test dependency)
Package: src:silx Version: 1.0.0+dfsg-2 Severity: serious Tags: sid bookworm silx autopkg tests fail (missing test dependency): [...] autopkgtest [21:49:30]: test command1: [--- Testing with python3.10: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/silx/test/__init__.py", line 32, in import pytest ModuleNotFoundError: No module named 'pytest' autopkgtest [21:49:30]: test command1: ---] autopkgtest [21:49:31]: test command1: - - - - - - - - - - results - - - -
Bug#989660: Backport the fix to bullseye-updates
Hello, Is there any hope to backport the fix to bullseye-updates? This bug causes the code to be corrupted every time it's saved and autoformat is turned on. Best, Amr
Bug#930565: dev-ref: should use distro-info instead of hardcoding version numbers
On Sat, 15 Jun 2019 16:26:33 + Holger Levsen wrote: […] and then for bullseye we should use distro-info(-data). (wondering how to do this sensibly at run time and not at build time...) What is "run time" for manual (pdf, html, etc…), do you mean when the manual is actually shown in the browser for instance with html? I was thinking about using python distro-info to set variables to format rst_epilog with along with _version and _date. But I guess this is not what you expect. k OpenPGP_signature Description: OpenPGP digital signature
Bug#1006689: does not purge cleanly
Package: nfs-kernel-server Version: 1:2.6.1-1 Severity: normal Hi, I noticed that nfs-blkmap.service keeps failing on my notebook. Since I'm not using NFS anyway, I found out that this service belongs to nfs-kernel-server and tried to purge the package. This should be possible since I dont have dependencies installed, but it fails: [4/4996]mh@drop:~ $ sudo apt purge nfs-kernel-server Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: nfs-kernel-server* 0 upgraded, 0 newly installed, 1 to remove and 4 not upgraded. After this operation, 650 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 492241 files and directories currently installed.) Removing nfs-kernel-server (1:2.6.1-1) ... Failed to stop nfs-kernel-server.service: Unit nfs-kernel-server.service not loaded. invoke-rc.d: initscript nfs-kernel-server, action "stop" failed. dpkg: error processing package nfs-kernel-server (--remove): installed nfs-kernel-server package pre-removal script subprocess returned error exit status 5 dpkg: too many errors, stopping nfs-mountd.service is a disabled or a static unit not running, not starting it. nfs-server.service is a disabled or a static unit not running, not starting it. nfsdcld.service is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. Failed to restart nfs-kernel-server.service: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists See system logs and 'systemctl status nfs-kernel-server.service' for details. invoke-rc.d: initscript nfs-kernel-server, action "restart" failed. ○ nfs-kernel-server.service Loaded: error (Reason: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists) Active: inactive (dead) Warning: The unit file, source configuration file or drop-ins of nfs-kernel-server.service changed on disk. Run 'systemctl daemon-reload' to reload units. Failed to restart nfs-kernel-server, ignoring. Errors were encountered while processing: nfs-kernel-server Processing was halted because there were too many errors. needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) 100 [5/4997]mh@drop:~ $ sudo apt purge nfs-kernel-server Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: nfs-kernel-server* 0 upgraded, 0 newly installed, 1 to remove and 4 not upgraded. After this operation, 650 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 492241 files and directories currently installed.) Removing nfs-kernel-server (1:2.6.1-1) ... Failed to stop nfs-kernel-server.service: Unit nfs-kernel-server.service not loaded. invoke-rc.d: initscript nfs-kernel-server, action "stop" failed. dpkg: error processing package nfs-kernel-server (--remove): installed nfs-kernel-server package pre-removal script subprocess returned error exit status 5 dpkg: too many errors, stopping nfs-mountd.service is a disabled or a static unit not running, not starting it. nfs-server.service is a disabled or a static unit not running, not starting it. nfsdcld.service is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. Failed to restart nfs-kernel-server.service: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists See system logs and 'systemctl status nfs-kernel-server.service' for details. invoke-rc.d: initscript nfs-kernel-server, action "restart" failed. ○ nfs-kernel-server.service Loaded: error (Reason: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists) Active: inactive (dead) Warning: The unit file, source configuration file or drop-ins of nfs-kernel-server.service changed on disk. Run 'systemctl daemon-reload' to reload units. Failed to restart nfs-kernel-server, ignoring. Errors were encountered while processing: nfs-kernel-server Processing was halted because there were too many errors. needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) 100 [6/4997]mh@drop:~ $ I was able to get rid of the package by emptying out the prerm script, but that should be easier. Greetings Marc -- Package-specific info: -- rpcinfo -- -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.11-zgws1 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Bug#1006688: reportbug: Debian 11 KDE (Mirror download not working on Google Chrome Version 99.0.4844.51)
Package: reportbug Version: 7.10.3+deb11u1 Severity: minor X-Debbugs-Cc: hugo.lalint...@gmail.com Dear Maintainer, cant download mirrors on Google chrome Version 99.0.4844.51 Im using debian 11 KDE. Example: I try download it and when I click the FTP link nothing happens so need change to another browser to download it. On firefox is working fine. * ** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: ** Environment settings: INTERFACE="text" ** /root/.reportbugrc: reportbug_version "7.10.3+deb11u1" mode novice ui text realname "Hugo B" email "hugo.lalint...@gmail.com" no-check-uid no-cc list-cc-me smtphost reportbug.debian.org -- 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/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt2.2.4 ii python33.9.2-3 ii python3-reportbug 7.10.3+deb11u1 ii sensible-utils 0.0.14 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn default-mta | postfix | exim4 | mail-transport-agent pn dlocate pn emacs-bin-common ii file 1:5.39-3 ii gnupg 2.2.27-2 pn python3-urwid pn reportbug-gtk ii xdg-utils 1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.2.4 ii file 1:5.39-3 ii python33.9.2-3 ii python3-apt2.2.1 ii python3-debian 0.1.39 ii python3-debianbts 3.1.0 ii python3-requests 2.25.1+dfsg-2 ii sensible-utils 0.0.14 python3-reportbug suggests no packages. -- no debconf information
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
Hello Per, Am Mittwoch, dem 02.03.2022 um 12:54 +0200 schrieb Per Lundberg: > reassign 1006647 tomcat9 > thanks > > This might better belong to this package, since the problem is that > tomcat9-common depends on default-jre-headless | java8-runtime-headless > > java8-runtime, while in reality it requires Java 11. (because of > Eclipse JDT 4.21, see original bug report for details) > > If we are unable to fully resolve this, I think that we should at least > fix these incorrect dependencies to make the package depend on > "default-jre-headless | java11-runtime-headless | java11-runtime" > instead. But as previously mentioned, I would much rather see us move to > Eclipse JDT 4.20 instead so we can retain Java 8 support until Debian at > some point upgrades to Tomcat 10.1 (at which point requiring Java 11 is > inevitable). As a matter of fact OpenJDK 11 is the only supported Java version in oldstable, stable and testing right now. We plan to release with Java 17 next year and one of our goals is to ship only Tomcat 10 in Debian 12 "Bookworm". I think you are right that we should tighten the dependency to java11-runtime-headless to avoid any confusion but as I said, OpenJDK 11 is the only supported JDK/JRE at the moment. If you cannot upgrade your application to Java 11, then you could create a custom Tomcat 9 package or simply downgrade libeclipse-jdt-core-java to 4.20 again. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1006685: kde-plasma-desktop: KDE does not display Emojis correctly
Package: kde-plasma-desktop Version: 5:111 Severity: normal Dear Maintainer, for several years KDE on Debian seems to be unable to display emojis correctly. I experience this problem on Debian testing and on Debian stable. One can reproduce it by running `echo "Heart Face Emoji 殺"` in Konsole or by opening https://www.youtube.com/watch?v=YaYoJziCgto in Fireofox or Konqueror. The emojis will be displayed only as blank rectangles. The problem does not occur on Ubuntu. It also does not occur when using Debian/Xfce and when using the Xfce-Terminal from within a Plasma session. Thus, I can have a Konsole and Xfce-Terminal side by side with the former showing the problem and the latter not so. I reproduced the problem by setting up a Debian/Testing in a virtual machine yesterday. I tried to set a different font, but to no avail. Maybe I have not tried hard enough. However, I think Emojis should be displayed properly in the default configuration. -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.16.10 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kde-plasma-desktop depends on: ii kde-baseapps 4:20.12.0+5.111 ii plasma-desktop4:5.20.5-4 ii plasma-workspace 4:5.20.5-6 ii udisks2 2.9.2-2+deb11u1 ii upower0.99.11-2 Versions of packages kde-plasma-desktop recommends: ii kwin-x11 4:5.20.5-1 ii sddm 0.19.0-3 ii xserver-xorg 1:7.7+22 Versions of packages kde-plasma-desktop suggests: ii kdeconnect 20.12.3-2 -- no debconf information
Bug#1006684: libappstream4: flatpak search assertion failure since port to libappstream: g_atomic_pointer_get (value_location) == 0
Package: libappstream4
Version: 0.15.2-2
Severity: normal
Tags: patch
Forwarded: https://github.com/ximion/appstream/issues/384
Steps to reproduce: run the test suite from Flatpak git HEAD or 1.13.1
(coming soon to experimental, but I will have to disable the tests that
trigger this assertion failure in order to get autopkgtest to pass).
Expected result: tests succeed
Actual result: several tests fail with this assertion failure in libappstream:
(flatpak search:260854): GLib-CRITICAL **: 14:05:04.766: g_once_init_leave:
assertion 'g_atomic_pointer_get (value_location) == 0' failed
.../tests/test-repo.sh: line 109: 260854 Trace/breakpoint trap (core dumped)
${FLATPAK} search Hello > search-results
Please see https://github.com/ximion/appstream/issues/384 for more details
and https://github.com/ximion/appstream/pull/385 for a merge request that
appears to resolve it.
Thanks,
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-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 libappstream4 depends on:
ii libc62.33-7
ii libcurl3-gnutls 7.81.0-1
ii libglib2.0-0 2.70.4-1
ii libstemmer0d 2.2.0-1
ii libxml2 2.9.13+dfsg-1
ii libxmlb2 0.3.6-2
ii libyaml-0-2 0.2.2-1
libappstream4 recommends no packages.
libappstream4 suggests no packages.
-- no debconf information
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
reassign 1006647 tomcat9 thanks This might better belong to this package, since the problem is that tomcat9-common depends on default-jre-headless | java8-runtime-headless | java8-runtime, while in reality it requires Java 11. (because of Eclipse JDT 4.21, see original bug report for details) If we are unable to fully resolve this, I think that we should at least fix these incorrect dependencies to make the package depend on "default-jre-headless | java11-runtime-headless | java11-runtime" instead. But as previously mentioned, I would much rather see us move to Eclipse JDT 4.20 instead so we can retain Java 8 support until Debian at some point upgrades to Tomcat 10.1 (at which point requiring Java 11 is inevitable). Best regards, Per
Bug#1006326: issues connecting to https://bugs.debian.org/cgi-bin/soap.cgi (generation of wnpp related pages)
Hello
I have added some lines to the wnpp.pl script (see commit below) so when it
fails, it shows the point of the process when the connection failed.
Kind regards,
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
commit 2727d89ba5faed7d30faab1c58cf3b6e7c6fe841 (HEAD -> master, origin/master,
origin/HEAD)
Author: Laura Arjona Reina
Date: Wed Mar 2 11:40:34 2022 +0100
add messages and numbers to be shown when the connections to bugs.d.o fails
(related: bug #1006326 )
diff --git a/english/devel/wnpp/wnpp.pl b/english/devel/wnpp/wnpp.pl
index 53aff43cefc..ef34ff41c2d 100644
--- a/english/devel/wnpp/wnpp.pl
+++ b/english/devel/wnpp/wnpp.pl
@@ -40,10 +40,15 @@ while () {
my $soap = SOAP::Lite->uri('Debbugs/SOAP')->proxy('https://bugs.debian.org/cgi-bin/soap.cgi')
or die "Couldn't make connection to SOAP interface: $@";
-my $bugs = $soap->get_bugs(package=>'wnpp')->result;
+my $bugs = $soap->get_bugs(package=>'wnpp')->result
+ or die "Failed to get the list of bugs for package wnpp";
my $status = {};
+my $count = 0;
+my $total = @$bugs;
while (my @slice = splice(@$bugs, 0, 500)) {
-my $tmp = $soap->get_status(@slice)->result() or die;
+$count = $count + 1;
+my $tmp = $soap->get_status(@slice)->result()
+or die "Failed to get status for bunch $count (of 500 bugs), total bugs to
process: $total)";
%$status = (%$status, %$tmp);
}
Bug#1006633: procmail is unmaintained upstream
On Wed, Mar 2, 2022 at 11:28 AM Santiago Vila wrote: > Note: It's almost always better not to include a debian/* directory at all. > Noted. Incidentally, all historical release tags are now back in the repository for as long as the repository goes back. -- Stephen.
Bug#1006633: procmail is unmaintained upstream
El 2/3/22 a las 11:07, Stephen R. van den Berg escribió: I'd be willing to include a Debian directory with all the things you need to ease Debian packaging, just tell me what I should put in there. Note: It's almost always better not to include a debian/* directory at all. Thanks.
Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX
Package: libmgl-dev Version: 8.0.1-1 Severity: normal X-Debbugs-Cc: joubert...@gmail.com Dear Maintainer, Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm facing the following error: CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES) Call Stack (most recent call first): /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544 (find_package_handle_standard_args) /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47 (find_package) /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency) [...] It appears the libmgl-dev package is missing a dependency on an OpenMP related package. Installing libomp-dev fixes the issue though I'm not sure this is the correct package to depend on. Thanks, Sylvain -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 'unstable'), (90, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmgl-dev depends on: ii libgl-dev 1.4.0-1 ii libgsl-dev2.7.1+dfsg-3 ii libmgl-fltk8 8.0.1-1 ii libmgl-glut8 8.0.1-1 ii libmgl-mpi8 8.0.1-1 ii libmgl-qt5-8 8.0.1-1 ii libmgl-wnd8 8.0.1-1 ii libmgl-wx88.0.1-1 ii libmgl8 8.0.1-1 ii libpng-dev1.6.37-3 libmgl-dev recommends no packages. libmgl-dev suggests no packages. -- no debconf information
Bug#1006633: procmail is unmaintained upstream
As of May 2020, the dormant state of procmail upstream maintenance has been changed back to active. As Santiago Vila can attest to, I have taken up active maintenance of procmail again since the past two years (lockdowns appear to have its uses after all). All bugreports have been actively fixed since May 2020. It's time for a new release version v3.24. The latest version can now always be found at: https://github.com/BuGlessRB/procmail Official releases are tagged, as in this case: v3.24 The repository currently has tags going back to v3.20 I'd be willing to include a Debian directory with all the things you need to ease Debian packaging, just tell me what I should put in there. On Tue, Mar 1, 2022 at 3:58 PM Antoine Beaupré wrote: > On 2022-03-01 15:37:42, Santiago Vila wrote: > > severity 1006633 important > > retitle 1006633 procmail is unmaintained upstream > > I think that title is a mischaracterisation. Procmail is not just > unmaintained upstream, it's known to be insecure. > > > Hi. > > Hi, > > > I could understand that we want to get rid of unmaintained software, but > > please do not inflate severities, at least while the discussion takes > > place and a consensus that the package should be removed has not been > > reached. This package is optional, and we are not forcing anybody to use > > it. If we had kept the extra priority, I would be glad to put it in > > "extra", but extra does not exist anymore. > > I disagree with this assesment. If this was any leaf package with normal > permissions, I wouldn't mind. but procmail installs a SUID binary and, > because of that, should be subject to much stricter rules. > > There were two bug reports asking for the SUID bit to be dropped or at > least be configurable (#298058, #264011), both of which were closed in > favor of dpkg-statoverride. But that, in my opinion, is not the right > mechanism: we should "fail closed" and default to a more secure option, > with the burden on the caller to enable a more dangerous option. > > So this is not just some random package that's unmaintained. It's a key, > high profile security risk. > > Also, I understand that we're not responsible for all the "guns" we ship > for people to "shoot in the foot" with. I get that. But this one doesn't > say anywhere on the tin that we're basically the upstream now. > > > There are some things which need a clarification because they are not > > 100% accurate. > > > > El 1/3/22 a las 3:11, Antoine Beaupre escribió: > >> # unmaintained > >> > >> procmail is unmaintained. the "Final release", according to > >> Wikipedia[1], dates back to September 10, 2001 (3.22). this is the > >> release that is shipped with Debian, although we do have *26* > >> debian-specific uploads on top of that (3.22-26, in all suites since > >> buster). > > > > The Debian package is actually based on version "3.23pre" since version > > 3.22-21, dated 2013-10-15. I know this is a very minor correction, but I > > think it's important to state the facts right. > > "3.23pre" doesn't really sound like a release at all to me... > > > While it's true that procmail has not been maintained upstream for a > > long time, Debian is absolutely in his right to maintain its own version > > without an upstream, that's one of the properties of free software. > > Sure. We have every right to ship dead and unmaintained software if we > really, really want to. My argument is that we *shouldn't*. > > >> the last maintainer of procmail explicitly advised us (in #769938) and > >> other projects (e.g. OpenBSD, in [2]) to stop shipping it. > > > > Same as before, Debian is in his right to follow this advice or not. > > Yes, but is it *right* to ignore it? I strongly doubt that. > > I'm not making a legal argument here. I'm making an ethical argument: > procmail is unmaintained and insecure, and we shouldn't ship it. > > There are plenty of programs we remove from Debian because they are > unmaintained upstream, even *without* being insecure. That's fine. We > are a free software clearing house, not a dump. > > >> That Debian bug report is still open, and concerns a NULL pointer > >> dereference. > > > > I've just make an upload to fix such bug. > > I'm sorry, but the fact that it took over 7 years to do this is > telling. That bug isn't fixed upstream, for example. > > > Debian security people: Is there a CVE for Bug #769938? Maybe this > > should backported for stable as well. > > > >> I do not know if it is exploitable. Strangely, the > >> original procmail author (Stephen R. van den Berg, presumably) wrote > >> in that bug report *last year* saying that was "Fixed in upcoming 3.23 > >> release", which has been targeted for release for all of those last 20 > >> years. > > > > I guess he did not refer to the version which was "upcoming 20 years > > ago", but to the git version on which he was working in the last years. > > But the 3.22-1 upload explicitly refers to that 3.23pre release: > > procmail (3.22-1) unstable;
Bug#1006679: libosip2: please consider updating
Quoting Gavin Henry (2022-03-02 10:48:15) > Mine does - https://mentors.debian.net/package/sentrypeer/ > > That's why I mentioned it, but SentryPeer isn't in yet. Ah, good to know - thanks! Also, SentryPeer looks quite cool! I noticed the ITP for it, and am looking forward to see that in Debian: Thanks for working on that. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1006681: atop: ethernet speed broken
Package: atop Version: 2.6.0-2 Atop always show zero speed for ethernet network interfaces. For example: NET | eth0 | pcki 17472 | pcko 18327 | sp0 Mbps | si 46 Mbps | so 10 Mbps | erri 0 | erro 0 | While ethtool shows correctly. I have uptodate Debian GNU/Linux 11 (bullseye) with Linux kernel 5.15.0-0.bpo.2-amd64 #1 SMP Debian 5.15.5-2~bpo11+1 (2022-01-02) x86_64 GNU/Linux
Bug#1000201: unbound: Fails to download zones via HTTPS
Hello, I ran into this recently as well. I just want to add that the above report mentions a single patch, however it seems to me the related github issue resulted in two patches. The issue: https://github.com/NLnetLabs/unbound/issues/429 The patches: https://github.com/NLnetLabs/unbound/commit/bc4bdbabeab1388e41ce64714203b4fd3fab18be https://github.com/NLnetLabs/unbound/commit/ff0c5f863d02c29a0eb11f0130110b390656b558 They are both included in unbound 1.13.2. -- Regards, Patrik Lundin
Bug#1006664: python3-fonttools has unmet dependencies
Control: affects 1006664 python3-matplotlib Control: severity 1006664 grave Raising the severity to Grave since it makes the package unusable (uninstallable). Could argue for Severity: Critical, since it breaks unrelated software (it breaks any package that depends on python3-matplotlib, and there are a lot of them).
Bug#1006679: libosip2: please consider updating
Mine does - https://mentors.debian.net/package/sentrypeer/ That's why I mentioned it, but SentryPeer isn't in yet.
Bug#1006680: guake.desktop link broken in 3.8.5
Package: Guake Version: 3.8.5-1 Forwarding a bug report from the Guake bug tracker for a malformed guake.desktop file that points to /guake/data/autostart-guake.desktop instead of /guake/autostart-guake.desktop. Original bug report and more detail on fact finding process so far can be found at: https://github.com/Guake/guake/issues/2048 The first reporter is using Linux kali 5.16.0-kali1-amd64 Debian 5.16.7-2kali1 (2022-02-10) x86_64 GNU/Linux
Bug#1006679: libosip2: please consider updating
Quoting Yangfl (2022-03-02 10:12:11) > Source: libosip2 > Severity: wishlist > > It has been 5 years since last update. Please consider updating > package to the latest release. Seems no other packages depend on this, so maybe the better option is to drop it? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1006679: libosip2: please consider updating
Source: libosip2 Severity: wishlist It has been 5 years since last update. Please consider updating package to the latest release.
Bug#983146: 983146 RFS: bung/3.2.1-1 [ITP] -- backup next generation
On Wed, Mar 02, 2022 at 12:39:38PM +0530, Charles wrote: > > When that doubt is resolved I will create 3.2.1-2 including a watch file do
Bug#855073: qbittorrent: Data Loss after reboot
I was able to systematically reproduce the bug in stretch (qbittorrent_3.3.7-3+deb9u1 / libtorrent-rasterbar9_1.1.1-1+b1). I upgraded the latter to 1.1.4-1 (from snapshot.debian.org) and the bug disappeared. So likely the bug affected the package libtorrent-rasterbar and it is fixed now. Regards BZ
Bug#992080: udiskie bug
control: fixed -1 2.4.1-1 control: close -1 Closing please reopen if the fix didn't work. G. On Wed, 16 Feb 2022 19:56:36 +0100 Gianfranco Costamagna wrote: On Tue, 10 Aug 2021 16:31:36 -0700 Nolan wrote: > It may be obvious, but I forgot to mention that this is on Bullseye, up > to date as of today (Aug 10th). > > This bug is likely related to #991552. > > Hello, I probably fixed this bug in debian/2.4.1-2, please check if now it works correctly. Thanks! Gianfranco
Bug#1006678: ukui-settings-daemon: FTBFS against libkscreen 5.24.2
Package: ukui-settings-daemon Version: 3.1.1-1 Severity: serious Tags: ftbfs In current Debian unstable (and Ubuntu Jammy), ukui-settings-daemon FTBFS against the latest Plasma libkscreen 5.24.2. xrandr-output.cpp: In static member function ‘static void xrandrOutput::readInOutputs(KScreen::ConfigPtr, const QVariantList&)’: xrandr-output.cpp:368:21: error: ‘class KScreen::Output’ has no member named ‘setLogicalSize’ 368 | output->setLogicalSize(QSizeF()); | ^~
