Bug#1070319: fails to build without a non lo IP address
I've forwarded this to our internal team. Thanks for the report!
Bug#979332: Anyone working on this ? Is it just need some packaging work?
Hi I would like to see some progress on this as I use dokuwiki. I am willing to help out but I don't know what the resolution would look like. Is it just a matter of re-packaging something more modern in a way that avoids a particular issue? I am certainly no PHP expert so it would be a fair amount of learning for me to work on that if that is required? Andrew
Bug#895897: Further comments on apt purge
Note that apt purge ~c does something, but apt(8) does not mention the support for the ~c parameter. On my system, it seems to be attempting to remove all packages that have the "c" second character status in dpkg -l. Unfortunately, this includes packages such as "locales" which I think are normally "ic", so this command does not seem appropriate for removing "rc" packages as suggested elsewhere. The following packages will be REMOVED: bsdmainutils* grub-legacy-ec2* isc-dhcp-client* language-pack-en-base* linux-image-6.5.0-17-generic* linux-image-6.5.0-25-generic* linux-modules-6.5.0-17-generic* linux-modules-6.5.0-25-generic* linux-modules-extra-6.5.0-17-generic* linux-modules-extra-6.5.0-25-generic* locales* openvswitch-switch* reportbug* resolvconf* ufw* upower*
Bug#1069450: socket_wrapper and the time_t 64-bit is hard
Just a warning that trying to brute force a fix for this is likely to end badly. A lot of developer time was spent to get to this current delicate situation, which relied on the narrow behaviour that is now eliminated by the Debian time_t 64 transition rules. Socket-wrapper starts with: /* * Make sure we do not redirect (f)open(at)() or fcntl() to their 64bit * variants */ #undef _FILE_OFFSET_BITS This was added in https://gitlab.com/cwrap/socket_wrapper/-/commit/bbe14cc3200ca553b13ed49357e2e88ba487eeaa Setting -D_FILE_OFFSET_BITS=64 will break the fcntl64 wrapper and so break Samba's tests. I don't know if there is a good fix for this actually. Andrew Bartlett
Bug#1057689: minetest: calls home for upstream version check
Hi, I have no idea how to check what changes have been made due to the poor UX of the debian website. I would just like to point out that the correct way to disable the update checker is to pass -DENABLE_UPDATE_CHECKER=0 to cmake. You don't need to patch defaultsettings.cpp or minetest.conf Also, if you disable the update checker it would be great if you could update Minetest quicker, at least in Debian testing On Wed, 6 Mar 2024 22:32:23 +0100 David Heidelberg wrote: > Hello! > > as a workaround you can set empty `update_information_url` in > `~/.minetest/minetest.conf`. > > For Debian developer maintaining minetest, this can be patched in > `src/defaultsettings.cpp` same way by setting it to empty string. > > Please, consider this message also as a request to bump minetest up to > 5.8.0 version. > > Thank you! > > -- > David Heidelberg
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
On 4/10/24 3:50 PM, Andrey Rakhmatullin wrote: On Wed, Apr 10, 2024 at 03:05:04PM -0500, Andrew Davis wrote: is that not right? Maybe my lintian version is old, I'm on v2.114, I'll see if updating that helps. 2.114 is older than stable, and for packages aimed at unstable you need to use tools from unstable. That makes sense, seems my build environment (based on sid) got out of date and updating man/groff shows the warning now, thanks! Fixed warnings and pushed new source package. Thanks, Andrew
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
On 4/10/24 2:12 PM, Andrey Rakhmatullin wrote: On Wed, Apr 10, 2024 at 12:39:47PM -0500, Andrew Davis wrote: - debian/k3conf.1 has a *roff warning, lintian also catches it. I don't see this warning, W: k3conf: groff-message error: automatically ending diversion 'an*link-text-div' on exit [usr/share/man/man1/k3conf.1.gz:3] Are you running lintian on the binary .changes? I've run it on several of the files, including the binary .changes, # lintian -i -I --show-overrides k3conf_0.3-1_amd64.changes is that not right? Maybe my lintian version is old, I'm on v2.114, I'll see if updating that helps. it just shows "maintainer-manual-page" item. Which I know nothing about You should use lintian-explain-tags(1) to read tag descriptions. That works, thanks for hint. Also just found lintian -i flag, seems that could be a good default now given the help site for the short version is gone. Andrew
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
On 4/5/24 2:13 PM, Andrey Rakhmatullin wrote: I have several suggestions for this: - Can you provide debian/watch? It should be possible. Okay, I'll add a watch file. - debian/k3conf.1 has a *roff warning, lintian also catches it. I don't see this warning, it just shows "maintainer-manual-page" item. Which I know nothing about, the help link it generates points to a site[0] that has down for about 6 months now[1][2].. Andrew [0] https://lintian.debian.org/tags/maintainer-manual-page [1] https://lists.debian.org/debian-devel/2023/11/msg00171.html [2] https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/160
Bug#1067908: Acknowledgement (Enable I6300ESB_WDT)
X-Debbugs-CC: debian-cl...@lists.debian.org
Bug#774068: ExtUtils-MakeMaker and NO_PERLLOCAL
On 11/06/2022 12:58, Damyan Ivanov wrote: -=| Niko Tyni, 30.12.2014 11:47:23 +0200 |=- (cc'ing the debian-perl list) On Tue, Dec 30, 2014 at 08:38:56AM +, Damyan Ivanov wrote: -=| Andrew Beverley, 29.12.2014 00:16:14 + |=- Is there any harm in having the option in there, especially as the upstream version of EU-MM defaults to creating perllocal.pod files, and provides this option to prevent it happening? As I see it, adding and maintaining a line to 2000+ debian/rules files is a bit of a burden. Not an unbearable one, but we embraced the tiny dh rules exactly because they made things really simple. Presumably Debian's version uses a patched version of EU-MM, which was required before this option was available. I wonder if debhelper would be the right place to add this. This would solve the problem this patch solves, and maybe also simplify the patch in the perl package package [1] [1] https://anonscm.debian.org/cgit/perl/perl.git/tree/debian/patches/debian/no_packlist_perllocal.diff Right, that seems like the right long term approach to me. Ideally, debhelper could pass both NO_PACKLIST and NO_PERLLOCAL to EU::MM, and the above patch wouldn't be needed at all. This would be a similar transition to the (still unfinished) PREFIX one, see #579461 and https://lintian.debian.org/tags/debian-rules-makemaker-prefix-is-deprecated.html Packages not using the short form dh rules would need to be modified before the patch could be removed. The required steps would be something like 1) change the Perl policy to recommend NO_PACKLIST + NO_PERLLOCAL 2) change debhelper v9 to use them 3) add a lintian check and/or do a mass bug filing for the other packages 4) wait for (most of) the packages to be fixed 5) change the Perl policy to require NO_PACKLIST + NO_PERLLOCAL 6) remove the patch from the perl package I've been thinking about this. Even made the changes in debhelper¹ and considered a possible wording for the Perl policy. ¹ https://salsa.debian.org/dmn/debhelper/-/commits/b9cdc9696464f67f0c75479383a002ff666ffd6b Then it occured to me that this is a titanic work that would take months if not years - rebuilding the archive, analyzing the results, providing patches to the packages that need them and track their progress. All this so that a patch is dropped from Debian's EU:MM and packages created with dh-make-perl could be built in a rather non-standard environment. And perhaps the other patches to Debian's EU:MM also have some purpose that would still be missing, so another round of the same would be needed. Somehow, to me it seems that the gain is not worth the effort. By a huge margin. So how about this instead: Add a special option to dh-make-perl like '--pristine-upstream-eumm' that causes it to make whatever changes are necessary to the resulting package for it to build with the non-standard envronment. Including a warning to the docs that such a package is not intented for the official Debian archive. Andrew, are you still interested in this and willing to provide a merge request/patch that provides such an option? Thanks for coming back to this and for the willingness to solve it. If you have solved the issue by other means (e.g. --data-dir), then perhaps we should just close this bugreport. I've actually now always been in the habit of prefixing any use of cpan2deb with the following, which I think solves the problem: PERL_MM_OPT='NO_PACKLIST=1 NO_PERLLOCAL=1' Reading through the history of this bug though, I'm not sure I really need that anymore, as I don't think I'm using a local version of EU::MM (presumably the one now shipped with Debian is new enough for most purposes). So yes, I think just closing the bug report is best. At least there is a history here for anyone else encountering the same issues. Many thanks for your assistance. Andy
Bug#1067908: Acknowledgement (Enable I6300ESB_WDT)
I misspoke - a different watchdog will be provided for arm, so this request is for amd64 only. On Thu, Mar 28, 2024 at 11:15 AM Debian Bug Tracking System wrote: > > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1067908: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067908. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Kernel Team > > If you wish to submit further information on this problem, please > send it to 1067...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1067908: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067908 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#1067908: Enable I6300ESB_WDT
Package: linux-image-cloud-amd64 Version: 6.1.76-1 Severity: wishlist GCE will introduce a virtual watchdog timer device, implemented to appear as an Intel 6300ESB. The team implementing the device reports that the driver is not available on Debian. It looks like it's been in the kernel for ~19 years, so it should be a matter of setting CONFIG_I6300ESB_WDT=m (and any dependencies). If it's possible to get this into Debian 11 as well, that would be good. Cloud kernels only would be sufficient. arm64 as well.
Bug#1067652: RFP: logisim-evolution -- Logisim-evolution is educational software for designing and simulating digital logic circuits
Package: wnpp Severity: wishlist * Package name: logisim-evolution Version : 3.8.0 Upstream Contact: Logisim-evolution development team * URL : https://github.com/logisim-evolution/logisim-evolution * License : GPL-3.0 Programming Lang: Java Description : Digital logic design tool and simulator Logisim-evolution is educational software for designing and simulating digital logic circuits. It is a continuation of the old "Logisim" software by Carl Burch. It's worth noting that the origin "Logisim" software has been abandoned, and the "logisim" package in Debian has been orphaned for several years. The upstream development team maintains deb-format packaging as well as snaps and flatpacks. This software is used by engineering students the world over to learn about and practice with logic circuits and FPGAs. I believe it should be included as part of Debian
Bug#1066997: mlterm cannot launch mlconfig because it doesn’t support --geometry
Package: mlterm
Version: 3.9.3-1+b1
Severity: important
Tags: a11y
X-Debbugs-Cc: a.t.chadw...@gmail.com
Dear Maintainer,
The mlconfig helper does not support --geometry, so it can’t be invoked by
the user using its Ctrl+MouseButton3 binding, which tries to use this
option. If mlterm is run from a different terminal, it instead prints the
message “Unknown option --geometry” when this combination is pressed,
without giving any other indication of what it’s trying to do. See the
trace below for that detail.
I think that mlterm should invoke this command without --geometry, or the
mlconfig helper should be patched to support the --geometry option. I can
confirm that this functionality was working correctly under Debian 12’s
version of mlterm and its supporting binaries.
thanks for looking at this,
Andrew
-- Trace for message:
$ rm -fr ~/.mlterm
$ strace -ff mlterm 2>&1 | grep geometry
[pid 136423] execve("mlconfig", ["mlconfig", "--geometry", "+1371+345",
"--display", ":0.0"], 0x7fffd47338b8 /* 59 vars */) = -1 ENOENT (No such file
or directory)
[pid 136423] execve("/usr/lib/x86_64-linux-gnu/mlterm/mlconfig",
["/usr/lib/x86_64-linux-gnu/mlterm"..., "--geometry", "+1371+345", "--display",
":0.0"], 0x7fffd47338b8 /* 59 vars */) = 0
[pid 136423] write(2, "Unknown option --geometry\n", 26Unknown option --geometry
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (5, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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 mlterm depends on:
ii libc62.37-15
ii libfreetype6 2.13.2+dfsg-1+b1
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1
ii libglib2.0-0 2.78.4-1
ii libx11-6 2:1.8.7-1
ii mlterm-common3.9.3-1+b1
Versions of packages mlterm recommends:
ii mlterm-tools 3.9.3-1+b1
Versions of packages mlterm suggests:
pn fonts-arphic-bsmi00lp
pn fonts-arphic-gbsn00lp
ii fonts-freefont-ttf20211204+svn4273-2
ii fonts-ipafont-gothic [fonts-japanese-gothic] 00303-23
ii fonts-nanum 20200506-1
pn mlterm-im-m17nlib
pn mlterm-im-scim
pn mlterm-im-uim
pn t1-cyrillic
ii unifont 1:15.1.01-1
pn xfonts-efont-unicode
-- no debconf information
Bug#1066185: pekwm: New upstream version available: 0.3.0
Package: pekwm Version: 0.1.18-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, A new version of pekwm, 0.30.0, has been available from upstream since Jan 2023. I understand that it comes with a bunch of desktop-focused utilities now. Please can you consider updating the version in Debian, when convenient, for the next stable release? https://github.com/pekwm/pekwm/releases/tag/release-0.3.0 https://pekdon.pekwm.se/posts/pekwm_release_history/ many thanks, Andrew
Bug#1053565: RFS: openvpn3-client/21+dfsg-1 [ITP] -- virtual private network daemon (version 3)
Package: sponsorship-requests Followup-For: Bug #1053565 X-Debbugs-Cc: ajq...@debian.org Hi Marc, Thank you for your efforts in packaging this package into Debian. I noticed that you conducted a thorough license check and re-uploaded the package into mentors. However, there are still some lintian warnings/errors present in the `debian/copyright` file. Please ensure to check this on the webpage after uploading, or preferably, run a local lintian check before uploading or committing. Additionally, Tobi suggested that the Python component might be better suited in a dedicated Python module package. What are your thoughts on this? Best regards, -Andrew
Bug#1065678: josm: JOSM hangs when downloading Bing imagery, but only the first time in a session
On Sat, 2024-03-09 at 07:49 +0100, Sebastiaan Couwenberg wrote: > the workaround is to add the OSM Carto layer first, and then > add the Bing layer. This proposed workaround does not work for me. I need to kill and restart a hung JOSM, and launch it again to get working a Bing layer. Then (for my main working JOSM), the problem is worked around for a few hours (estimated) while I edit. The hang even affects the GUI: nothing responds within it as soon as the menu item is selected, and the menu itself becomes unresponsive and does not withdraw. I have commented upstream that for now this seems to be a Debian issue. See the comments at https://josm.openstreetmap.de/ticket/23540 for further detail. Summary: I cannot reproduce this with upstream's josm- tested.jar, but only with the jarfile in Debian's DFSG build. I am using the same Debian Java for both tests, using $ java -Djosm.home=/tmp/something_new_and_unique \ -jar path/to/a/josm.jar \ --skip-plugins --debug for consistency. I will continue reporting here, since this seems to be a Debian- specific issue. I don't have much else to add, however. Happy to try out fixes as they emerge. regards, Andrew
Bug#1065678: josm: JOSM hangs when downloading Bing imagery, but only the first time in a session
ch of url: https://ecn.t1.tiles.virtualearth.net/tiles/a21.jpeg?g=14355=odbl 2024-03-08 20:17:01.647 FINE: JCS - Submitting job for execution for url: https://ecn.t1.tiles.virtualearth.net/tiles/a12.jpeg?g=14355=odbl 2024-03-08 20:17:01.647 FINE: JCS - starting fetch of url: https://ecn.t1.tiles.virtualearth.net/tiles/a12.jpeg?g=14355=odbl 2024-03-08 20:17:01.647 FINE: JCS - starting HttpClient GET request for URL: https://ecn.t1.tiles.virtualearth.net/tiles/a21.jpeg?g=14355=odbl 2024-03-08 20:17:01.647 FINE: JCS - starting HttpClient GET request for URL: https://ecn.t2.tiles.virtualearth.net/tiles/a30.jpeg?g=14355=odbl 2024-03-08 20:17:01.647 FINE: JCS - Submitting job for execution for url: https://ecn.t3.tiles.virtualearth.net/tiles/a32.jpeg?g=14355=odbl 2024-03-08 20:17:01.648 FINE: Contacting Server... --->8-- And so on. The program is now fully usable. I would guess this is a cache directory liveness issue. That’s because the misbehaviour can also be provoked by deleting JOSM’s cache (which is normally ~/.cache/JOSM) before launching JOSM with your normal prefs, plugins, and presets. JOSM will then hang regardless of when it’s launched: the hang happens when JOSM is doing its Bing cache initialization or a full refresh (perhaps some magic numbers for the service?) The workaround is to launch JOSM and try and download Bing imagery, let it hang, then kill it and start it again. A bit annoying to have to do before each editing session, but it works. thanks for maintaining, Andrew -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (5, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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 josm depends on: ii default-jre [java9-runtime] 2:1.17-75 ii fonts-noto 20201225-2 ii jmapviewer 2.19+dfsg-1 ii libcommons-compress-java1.25.0-1 ii libgettext-commons-java 0.9.6-6 ii openjdk-17-jre [java9-runtime] 17.0.10+7-1 ii openjfx 11.0.11+1-3.1 ii proj-data 9.3.1-1 Versions of packages josm recommends: ii josm-l10n 0.0.svn18969+dfsg-1 josm suggests no packages. -- Configuration Files: /etc/default/josm changed: -- no debconf information
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "k3conf": * Package name : k3conf Version : 0.3-1 Upstream contact : Texas Instruments * URL : https://git.ti.com/cgit/k3conf/k3conf * License : BSD-3-clause * Vcs : https://salsa.debian.org/ti-team/k3conf Section : devel The source builds the following binary packages: k3conf - Powerful Diagnostic Tool for Texas Instruments K3 based Processors To access further information about this package, please visit the following URL: https://mentors.debian.net/package/k3conf/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/k/k3conf/k3conf_0.3-1.dsc Changes for the initial release: k3conf (0.3-1) unstable; urgency=medium . * Initial release. Closes: #1037141 Regards,
Bug#989775: OpenJPEG 2.5.2 fixes CVE-2021-3575
CVE-2021-3575 OpenJPEG 2.5.1 has been released https://groups.google.com/g/openjpeg/c/othStX49Yc8 and includes a fix https://github.com/uclouvain/openjpeg/pull/1509 for CVE-2021-3575. OpenJPEG 2.5.2 updates 2.5.1 with a minor bug fix. https://github.com/uclouvain/openjpeg/blob/v2.5.2/NEWS.md -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#1064942: libexo-2-dev: new upstream available: 4.19.0
Package: libexo-2-dev Version: 4.18.0-1+b1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Debian Xfce maintainers, A new unstable upstream version of libexo-2 is available: 4.19.0 (Oct 2023). This version is now a build requirement of Thunar from git, since c5d8bfaa (Oct 2023), and probably other parts of Future Xfce too. Please could you consider uploading a 4.19.0 build to experimental to support development work, as was done during the bookworm development cycle? thanks, Andrew [... ./autogen.sh-ing thunar-dev ...] checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for gtk-doc... yes checking for gtkdoc-check... gtkdoc-check.test checking for gtkdoc-check... /usr/bin/gtkdoc-check checking for gtkdoc-rebase... /usr/bin/gtkdoc-rebase checking for gtkdoc-mkpdf... /usr/bin/gtkdoc-mkpdf checking whether to build gtk-doc documentation... no checking for glib-2.0 >= 2.10.0 gobject-2.0 >= 2.10.0... yes checking for pkg-config... (cached) /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for exo-2 >= 4.19.0... found, but 4.18.0 *** The required package exo-2 was found on your system, *** but the installed version (4.18.0) is too old. *** Please upgrade exo-2 to atleast version 4.19.0, or adjust *** the PKG_CONFIG_PATH environment variable if you installed *** the new version of the package in a nonstandard prefix so *** pkg-config is able to find it. make: *** [Makefile:28: configure] Error 1
Bug#989775: CVE-2021-3575
OpenJPEG 2.5.1 has been released https://groups.google.com/g/openjpeg/c/othStX49Yc8 and includes a fix https://github.com/uclouvain/openjpeg/pull/1509 for CVE-2021-3575. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#1064337: [Pkg-samba-maint] Bug#1064337: samba: NMU diff for 64-bit time_t transition
On Tue, 2024-02-20 at 10:52 +0300, Michael Tokarev wrote: > 20.02.2024 09:30, Steve Langasek wrote: > > Source: sambaVersion: 2:4.20.0~rc2+dfsg-1Severity: importantTags: > > patch pending sid trixieUser: debian-...@lists.debian.org > > Usertags: time-t > > -Package: libsmbclient+Package: libsmbclient0 > Well. Maybe this is ok. I still haven't seen samba-libs analysis > abouttime_t abi, but smbclient never had a version in soname. > libsmbclient is definitely a public library. > > -Package: libldb2+Package: libldb2t64 > And this one is definitely not needed. Very much agreed :-) > libldb is an internal-to-samba library, which is used by exactlyone > package in debian, sssd, for which you're adding Breaks.I'm already > adding the same Breaks in the next version of libldb,because libldb > has become incompatible with sssd *again* (thenew packages of samba > 4.20 is in experimental, not yet with theBreaks since I'm waiting for > a rebuild of sssd). Due the natureof these libs (samba-libs and > libldb), it is a stuff which is notused outside, and it does not need > time_t transition. > Where's the analysis of libsmbclient ABI? I checked the header, and there are a lot of references to "struct timespec" in the main structures, plus one of time_t in a printing thing. Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead https://catalyst.net.nz/services/sambaCatalyst.Net Ltd Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company Samba Development and Support: https://catalyst.net.nz/services/samba Catalyst IT - Expert Open Source Solutions
Bug#1064337: samba: NMU diff for 64-bit time_t transition
Kia Ora Steve, So long since we had a chance to work together, and I thank you for your work on Debian. Can we have a chat about this? sssd does not, as I read it, use any time_t relevant parts of ldb, and is the only external user of LDB in Debian that we know of. Also, the debdiff changes the description of libsmbclient to libsmbclient0 unintentionally in the free text. I think therefore with some care we can reduce the impact of this significantly, down to libsmbclient, which seems to use struct timespec. Andrew Bartlett On Mon, 2024-02-19 at 22:30 -0800, Steve Langasek wrote: > Source: sambaVersion: 2:4.20.0~rc2+dfsg-1Severity: importantTags: > patch pending sid trixieUser: debian-...@lists.debian.org > Usertags: time-t > NOTICE: these changes must not be uploaded to unstable yet! > Dear maintainer, > As part of the 64-bit time_t transition required to support 32- > bitarchitectures in 2038 and beyond( > https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > sambaas a source package shipping runtime libraries whose ABI either > is affectedby the change in size of time_t, or could not be analyzed > viaabi-compliance-checker (and therefore to be on the safe side we > assume isaffected). > To ensure that inconsistent combinations of libraries with > theirreverse-dependencies are never installed together, it is > necessary tohave a library transition, which is most easily done by > renaming theruntime library package. > Since turning on 64-bit time_t is being handled centrally through a > changeto the default dpkg-buildflags (https://bugs.debian.org/1037136 > ), it isimportant that libraries affected by this ABI change all be > uploaded closetogether in time. Therefore I have prepared a 0-day > NMU for samba whichwill initially be uploaded to experimental if > possible, then to unstableafter packages have cleared binary NEW. > Please find the patch for this NMU attached. > This NMU has not been uploaded to experimental yet because it is > waiting onan update of the binary package override database from the > ftp team forlibsmbclient, which was late identified as a package name > requiring specialhandling. > If you have any concerns about this patch, please reach out > ASAP. Therewill be a period of several days before we begin uploads > to unstable; so ifinformation becomes available that your package > should not be included inthe transition, there is time for us to > amend the planned uploads. -- Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead https://catalyst.net.nz/services/sambaCatalyst.Net Ltd Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company Samba Development and Support: https://catalyst.net.nz/services/samba Catalyst IT - Expert Open Source Solutions
Bug#1063705: ACPI Error disable RealTimeClock
Hello friends,ACPI Error: Could not disable RealTimeClock events ... I Have a BMAX mini-pc Celeron N3350 with a crap BIOS American Megatrends.Devuan upgrade from linux-image-6.1.0-15-amd64 to 6.1.0-18 introduced this bug feature.I tried changing the clocksource.echo hpet|acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksourceWhen I change from tsc to hpet to acpi_pm I still get the same Error message in syslog, when I hwclock --systohc.BEST REGARDSP.s. If I boot acpi=off it does not get very far and totally freezes, can't REISUB, need to pull the power plug.
Bug#1063835: roundcube: When upgrading from roundcube 1.4.15+dfsg.1-1~deb11u2 to 1.6.5+dfsg-1~deb12u1 error "table roundcube.filestore does not exist" is thrown, not handled
Package: roundcube Version: 1.6.5+dfsg-1~deb12u1 Severity: important When upgrading roundcube to the latest version, the mariadb schema upgrade fails due to a missing table "roundcube.filestore". This table apparently never existed, however this did not seem to cause any noticeable issues before the upgrade. It appears therefore that the schema migration makes too many assumptions about the state of the current database, and so does not handle the missing (but apparently optianal) table gracefully. Missing tables should be created if they do not exist.. -- System Information: Debian Release: 11.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-11-amd64 (SMP w/3 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages roundcube depends on: ii dpkg1.21.22 ih roundcube-core 1.6.5+dfsg-1~deb12u1 roundcube recommends no packages. roundcube suggests no packages. Versions of packages roundcube-core depends on: ii dbconfig-common 2.0.19 ii debconf [debconf-2.0] 1.5.77 ii dpkg1.21.22 ii libjs-bootstrap44.5.2+dfsg1-8~deb11u1 ii libjs-codemirror5.59.2+~cs0.23.109-1 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-minicolors 2.2.6+dfsg-4 ii libjs-jquery-ui 1.12.1+dfsg-8+deb11u1 ii libjs-jstimezonedetect 1.0.6-5 ii libmagic1 1:5.39-3+deb11u1 ii php 2:7.4+76 ii php-auth-sasl 1.1.0-1 ii php-common 2:76 ii php-guzzlehttp-guzzle 7.4.5-1 ii php-intl2:7.4+76 ii php-mail-mime 1.10.10-1 ii php-masterminds-html5 2.7.4+dfsg-2 ii php-mbstring2:7.4+76 ii php-net-sieve 1.4.6-1 ii php-net-smtp1.10.1-1 ii php-pear1:1.10.12+submodules+notgz+20210212-1 ii php7.4 [php]7.4.33-1+deb11u4 ii php7.4-cli [php-cli]7.4.33-1+deb11u4 ii php7.4-intl [php-intl] 7.4.33-1+deb11u4 ii php7.4-json [php-json] 7.4.33-1+deb11u4 ii php7.4-mbstring [php-mbstring] 7.4.33-1+deb11u4 ii roundcube-mysql 1.6.5+dfsg-1~deb12u1 ii ucf 3.0043 Versions of packages roundcube-core recommends: ii apache2 [httpd-cgi] 2.4.57-2 pn php-enchant ii php-gd 2:7.4+76 ii php7.4-gd [php-gd] 7.4.33-1+deb11u4 pn roundcube-skin-classic pn roundcube-skin-larry Versions of packages roundcube-core suggests: pn php-bacon-qr-code pn php-bjeavons-zxcvbn-php pn php-crypt-gpg pn php-net-ldap3 pn php-roundcube-rtf-html-php iu roundcube-plugins 1.6.5+dfsg-1~deb12u1 -- debconf information: roundcube/mysql/admin-pass: (password omitted) roundcube/mysql/app-pass: (password omitted) roundcube/app-password-confirm: (password omitted) roundcube/password-confirm: (password omitted) roundcube/internal/skip-preseed: false roundcube/internal/reconfiguring: false roundcube/mysql/authplugin: default roundcube/database-type: mysql roundcube/db/app-user: roundcube@localhost roundcube/remote/port: roundcube/missing-db-package-error: abort roundcube/hosts: roundcube/db/dbname: roundcube roundcube/remote/newhost: roundcube/language: en_US roundcube/purge: false roundcube/dbconfig-remove: true roundcube/remove-error: abort roundcube/restart-webserver: true roundcube/dbconfig-upgrade: true roundcube/mysql/admin-user: debian-sys-maint roundcube/upgrade-error: abort roundcube/dbconfig-reinstall: false roundcube/passwords-do-not-match: roundcube/install-error: abort roundcube/remote/host: localhost roundcube/upgrade-backup: true roundcube/mysql/method: Unix socket roundcube/reconfigure-webserver: apache2, lighttpd roundcube/dbconfig-install: true
Bug#1063270: The "64bits time_t transition" in Debian/Xen
On 12/02/2024 5:27 pm, zithro wrote:
> Hey all,
>
> the Debian project is focused on the "2038 time_t" switch.
> So the maintainers of the Debian Xen package must ensure that all
> imported Xen code conforms to the new Debian standards.
>
> I was asked by Andrew Cooper to post here about this, I'll quote him :
> "So I had been idly wondering whether Xen would match up to Debian's new
> policy, and it appears not
> this topic really needs to be brought up on the xen-devel mailing list
> do you have any more details as to what has gone wrong?
> this is something we ought to arrange to happen in CI by default
> but it sounds like there's some work needed first"
>
> (Not answering the question because I'm just a messenger).
xen.git/xen$ git grep -w time_t -- :/
../tools/console/client/main.c:106: time_t start, now;
../tools/console/daemon/io.c:272: time_t now = time(NULL);
../tools/libs/light/libxl_qmp.c:116: time_t timeout;
../tools/libs/light/libxl_qmp.c:585:
time_t ask_timeout)
../tools/libs/light/libxl_x86.c:516: time_t t;
../tools/libs/toollog/xtl_logger_stdio.c:61: time_t now = time(0);
../tools/tests/xenstore/test-xenstore.c:453: time_t stop;
../tools/xenmon/xenbaked.c:98:time_t start_time;
../tools/xenstored/core.c:109: time_t now;
../tools/xenstored/core.h:150: time_t ta_start_time;
../tools/xenstored/domain.c:143: time_t mem_last_msg;
../tools/xenstored/domain.c:188:static time_t wrl_log_last_warning; /*
0: no previous warning */
../tools/xenstored/domain.c:1584: time_t now;
../tools/xenstored/lu.c:160: time_t now = time(NULL);
../tools/xenstored/lu.c:185: time_t now = time(NULL);
../tools/xenstored/lu.c:292: time_t now = time(NULL);
../tools/xenstored/lu.h:32: time_t started_at;
../tools/xentop/xentop.c:947: time_t curt;
../tools/xl/xl_info.c:742:static char *current_time_to_string(time_t now)
../tools/xl/xl_info.c:759:static void print_dom0_uptime(int short_mode,
time_t now)
../tools/xl/xl_info.c:810:static void print_domU_uptime(uint32_t domuid,
int short_mode, time_t now)
../tools/xl/xl_info.c:847: time_t now;
../tools/xl/xl_vmcontrol.c:336: time_t start;
../tools/xl/xl_vmcontrol.c:495: time_t now;
../tools/xl/xl_vmcontrol.c:504: if (now == ((time_t) -1)) {
../tools/xs-clients/xenstore_control.c:33: time_t time_start;
arch/x86/cpu/mcheck/mce.h:224: uint64_t time; /* wall time_t when
error was detected */
arch/x86/time.c:1129: * machines were long is 32-bit! (However, as
time_t is signed, we
I don't see any ABI problems from using a 64bit time_t. The only header
file with a time_t is xenstored/lu.h which is a private header and not a
public ABI.
I guess we fell into the "could not be analysed via
abi-compliance-checker" case?
~Andrew
Bug#1063149: [Pkg-samba-maint] Bug#1063149: "SyntaxWarning: invalid escape sequence '\s'" errors on updating
On Mon, 2024-02-05 at 15:57 +0300, Michael Tokarev wrote: > 05.02.2024 14:51, Daniel Vacek: > > Setting up python3-samba (2:4.19.4+dfsg-3) > > .../usr/lib/python3/dist- > > packages/samba/tests/dns_forwarder_helpers/server.py:80:SyntaxWarni > > ng: invalid escape sequence '\s' > .. > > I guess this could be backported till new upstream version is > > packaged. > > This is a wontfix for now. I already did similar fix before for > #1057668(added a backported patch python-fix-invalid-escape- > sequences.patch). > These are just warnings, a minor annoyance, nothing more.Hopefully > will be fixed by the next upstream version. > /mjt Daniel and Erwan, While I know it isn't standard Debian practice, please report this kind of thing upstream to the Samba bugzilla if possible. In this case I will note that this is fixed in Samba master and will be released in Samba 4.20. commit 26ff87dcfeaf5a2aff5f28c0aa5d99437c79a68cAuthor: Joseph Sutton < josephsut...@catalyst.net.nz>Date: Mon Sep 11 11:59:34 2023 +1200 python:tests: Fix invalid escape sequencesSigned-off-by: Joseph Sutton Reviewed-by: Andrew Bartlett (Why any code under 'tests' is being installed onto production systems is a different matter, probably worthy of a different bug in both places). Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/ Samba Team Member (since 2001) https://samba.org Samba Team Leadhttps://catalyst.net.nz/services/samba Catalyst.Net Ltd Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company Samba Development and Support: https://catalyst.net.nz/services/samba Catalyst IT - Expert Open Source Solutions
Bug#1059222: src:pv: fails to migrate to testing for too long: FTBFS on armhf
> This is a quick word to let you know that I've disabled valgrind tests > on armhf in the Debian package. They were failing since the 1.8.5 upload > [...] Thank you, I agree with this approach. The evidence I have seen so far suggests that the failures are due to issues with the way valgrind itself behaves on that architecture. -- Andrew Wood
Bug#1060280: linux-image-4.19.0-25-cloud-amd64: PCI ATS quirk patch needed for IDPF
Package: src:linux Version: 4.19.289-2 Severity: normal Dear Maintainer, Intel has introduced a new network card. They have submitted the driver to the upstream kernel. We don't know if it's reasonable to ask that this driver be backported to Debian, or to older versions of Debian, but in order to use an out-of-tree driver on older versions, a PCI ATS quirks patch is needed for some early versions of the hardware. Thus we're asking if it's possible to backport that quirks patch to older versions of Debian, so that users can use the out-of-tree driver. The patch was released in Linux 6.7: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.7=a18615b1cfc04f00548c60eb9a77e0ce56e848fd It's been backported to 5.15 in the LTS kernels, but customers may need it in older kernels for Debian. -- Package-specific info: ** Kernel log: boot messages should be attached -- System Information: Debian Release: 10.13 APT prefers oldoldstable-updates APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-24-cloud-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-4.19.0-25-cloud-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.133+deb10u1 ii kmod26-1 ii linux-base 4.6 Versions of packages linux-image-4.19.0-25-cloud-amd64 recommends: ii apparmor 2.13.2-10 ii firmware-linux-free 3.4 Versions of packages linux-image-4.19.0-25-cloud-amd64 suggests: pn debian-kernel-handbook ii grub-pc 2.06-3~deb10u4 pn linux-doc-4.19 Versions of packages linux-image-4.19.0-25-cloud-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#1058711: ipmitool: sel time set fails: "Specified time could not be parsed"
On Sat, 2023-12-16 at 08:32 +0100, Jörg Frings-Fürst wrote: > Hi Andrew, > > Am Samstag, dem 16.12.2023 um 08:12 +0100 schrieb Jörg Frings-Fürst: > > Hello Andrew, > > > > > > the ipmitool code in this area has not changed for years. If I > > remember > > correctly, there was a change in the shell where a parameter was > > activated by > > default. > > > > > > Can you escape the outer "? Like this > > > > ipmitool sel time set \"$(date "+%m/%d/%Y %T")\" > > the % must be escaped to > > ipmitool sel time set \"$(date "+\%m/\%d/\%Y \%T")\" hello - this still fails: # ipmitool sel time set \"$(date "+\%m/\%d/\%Y \%T")\" Specified time could not be parsed i don't think that shell escapes are the issue. the same command on the same system will succeed or fail depending on the installed version of the ipmitool package. here is a transcript of a test without the added complexity of the `date` call. it still shows the version- specific behavior: # ipmitool -V ipmitool version 1.8.18 # ipmitool sel time set "12/14/2023 11:40:47" 12/14/2023 11:40:47 # apt -y install ipmitool=1.8.19-4 [...] # ipmitool -V ipmitool version 1.8.19 # ipmitool sel time set "12/14/2023 11:40:47" IANA PEN registry open failed: No such file or directory Specified time could not be parsed # dpkg -i /tmp/ipmitool_1.8.18-10.1_amd64.deb [...] # ipmitool -V ipmitool version 1.8.18 # ipmitool sel time set "12/14/2023 11:40:47" 12/14/2023 11:40:47 as far as i can tell 1.8.18 works as expected and 1.8.19 does not. for what it's worth the "IANA PEN registry" message does not appear when testing with 1.8.19-6 but the "Specified time could not be parsed" error remains. i also tried escaping quotes without effect: # ipmitool sel time set \"12/14/2023 11:40:47\" # ipmitool sel time set \""12/14/2023 11:40:47\"" thank you. andy -- andrew bezella internet archive
Bug#1058711: ipmitool: sel time set fails: "Specified time could not be parsed"
On Fri, 2023-12-15 at 16:10 +0100, Jörg Frings-Fürst wrote: [...] thank you for the quick reply! > Please can you test with > > ipmitool sel time set now this reports success (and i changed our crontab over to it yesterday): # ipmitool sel time set now 12/15/2023 04:20:53 PM UTC > and with > > ipmitool sel clear && ipmitool sel time set "$(date "+%m/%d/%Y %T")" this fails (tried repeatedly just in case it actually needed "a few seconds"): # ipmitool sel clear && ipmitool sel time set "$(date "+%m/%d/%Y %T")" Clearing SEL. Please allow a few seconds to erase. Specified time could not be parsed i also tested on an older system where i upgraded only the ipmitool package with the same results. one slight correction to my original bug report: i first noticed the issue w/1.8.19-4 (i had reported "1.8.19-6") hope that helps. thanks again. andy -- andrew bezella internet archive
Bug#1058711: ipmitool: sel time set fails: "Specified time could not be parsed"
Package: ipmitool Version: 1.8.19-6 Severity: normal Dear Maintainer, after upgrading a system from bullseye to bookworm i found that the ipmitool command we had been using to set the bmc time was failing. the crontab entry was: ipmitool sel time set "$(date "+%m/%d/%Y %T")" this worked up to ipmitool 1.8.18-10.1 and started failing with 1.8.19-6. i confirmed the usage and the problem via: # ipmitool sel time set usage: sel time set "mm/dd/ hh:mm:ss" # ipmitool sel time set "12/14/2023 11:40:47" Specified time could not be parsed investigation showed that a cleaner solution in our case is: # ipmitool sel time set now but the inability to set an arbitrary time looks like a bug. thanks in advance. andy -- System Information: Debian Release: 12.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/64 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages ipmitool depends on: ii init-system-helpers 1.65.2 ii libc62.36-9+deb12u3 ii libfreeipmi171.6.10-1+b1 ii libreadline8 8.2-1.3 ii libssl3 3.0.11-1~deb12u2 Versions of packages ipmitool recommends: pn openipmi ipmitool suggests no packages. -- no debconf information
Bug#1057684: [request-tracker-maintainers] Bug#1057684: request-tracker5: leaves alternatives after purge: /usr/sbin/rt-clean-attributes -> /etc/alternatives/rt-clean-attributes
Hi Andreas, > during a test with piuparts I noticed your package left unowned files on > the system after purge, which is a violation of policy 6.8: > > The leftover files are actually alternatives that were installed by the > package but have not been properly removed. Thank you for for reporting this, I thought I had it nicely clean, but it seems my testing didn't pick up all the things. #sigh I'll fix these issues. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#984946: Bug report libpigpiod-if-dev
Indeed, the libpigpiod-if-dev package is unusable without pigpio.h
Bug#1055616: ansible-core: ansible.builtin.setup does not include facts from facter.
On Fri, 2023-11-10 at 12:39 +0100, Lee Garrett wrote: > Hi Andrew, hello - > On 08.11.23 22:40, andrew bezella wrote: > > > [...] > > i was eventually able to build an updated version of bookworm's > > ansible-core .deb including commit id 4b0d014. this task was made > > more difficult by the current FTBFS status of ansible-core but the > > patch allowed ansible.builtin.setup to include facts from facter: > > Can you elaborate please? AFAICS ansible-core builds fine in stable > and sid. it wouldn't build in pbuilder and it shows up on the "Packages in bookworm/amd64 which failed to build from source" page[1]. but from the changelog it looks like you found and fixed the locale issue that i was running up against: ERROR: Ansible requires the locale encoding to be UTF-8; Detected None. i spent a bunch of time fiddling w/pbuilder to find the "right" answer but eventually just brute-forced it[2]. your solution is much better! thank you for the prompt turnaround. i would suggest/ask that the facter fix be included in bookworm, too; the lack of expected facts can have unexpected and significant impact on a playbook's run. thanks again! andy 1. https://tests.reproducible-builds.org/debian/bookworm/amd64/index_FTBFS.html 2. https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/1947424/comments/10 -- andrew bezella internet archive
Bug#1055616: ansible-core: ansible.builtin.setup does not include facts from facter.
Package: ansible-core
Version: 2.14.3-1
Severity: normal
Dear Maintainer,
i installed ansible-core and facter 4.3.0-2 in bookworm. when testing
i found that the facts from facter were not being included by the
setup module:
% ansible -b localhost -m ansible.builtin.setup -a 'filter=facter_*'
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | SUCCESS => {
"ansible_facts": {},
"changed": false
}
this issue has appeared upstream and was resolved by:
setup module, retry facter to handle --puppet errors by bcoca · Pull Request
#80645 · ansible/ansible · GitHub
https://github.com/ansible/ansible/pull/80645
i was eventually able to build an updated version of bookworm's
ansible-core .deb including commit id 4b0d014. this task was made
more difficult by the current FTBFS status of ansible-core but the
patch allowed ansible.builtin.setup to include facts from facter:
% ansible -b localhost -m ansible.builtin.setup -a 'filter=facter_*'
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | SUCCESS => {
"ansible_facts": {
"facter_disks": {
"sda": {
[...]
"facter_timezone": "UTC",
"facter_virtual": "physical"
},
"changed": false
}
thanks in advance for addressing this.
andy
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-13-amd64 (SMP w/64 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ansible-core depends on:
ii openssh-client1:9.2p1-2+deb12u1
ii python3 3.11.2-1+b1
ii python3-cryptography 38.0.4-3
ii python3-distutils 3.11.2-3
ii python3-dnspython 2.3.0-1
ii python3-httplib2 0.20.4-3
ii python3-jinja23.1.2-1
ii python3-netaddr 0.8.0-2
ii python3-packaging 23.0-1
ii python3-paramiko 2.12.0-2
ii python3-pycryptodome 3.11.0+dfsg1-4
ii python3-resolvelib0.9.0-2
ii python3-yaml 6.0-3+b2
Versions of packages ansible-core recommends:
ii ansible 7.3.0+dfsg-1
pn python3-argcomplete
pn python3-jmespath
pn python3-kerberos
pn python3-libcloud
ii python3-selinux 3.4-1+b6
pn python3-winrm
pn python3-xmltodict
Versions of packages ansible-core suggests:
pn cowsay
pn sshpass
-- no debconf information
>From 4b0d014d5840333457bd118c5fae5cf58325a877 Mon Sep 17 00:00:00 2001
From: Brian Coca
Date: Mon, 8 May 2023 16:53:53 -0400
Subject: [PATCH] setup module, retry facter to handle --puppet errors (#80645)
* setup module, retry facter to handle --puppet errors
facter versions have changed how they deal with the --puppet flag
when puppet is not present, most versions will just ignore it and not error,
but initial versions of facter 4 changed the behaviour (later reverted).
fixes #80496
---
changelogs/fragments/setup_facter_fix.yml | 2 ++
.../module_utils/facts/other/facter.py| 23 +++
2 files changed, 10 insertions(+), 15 deletions(-)
create mode 100644 changelogs/fragments/setup_facter_fix.yml
diff --git a/changelogs/fragments/setup_facter_fix.yml
b/changelogs/fragments/setup_facter_fix.yml
new file mode 100644
index 00..78a6b005a4abf2
--- /dev/null
+++ b/changelogs/fragments/setup_facter_fix.yml
@@ -0,0 +1,2 @@
+bugfixes:
+ - setup module (fact gathering) will now try to be smarter about different
versions of facter emitting error when --puppet flag is used w/o puppet.
diff --git a/lib/ansible/module_utils/facts/other/facter.py
b/lib/ansible/module_utils/facts/other/facter.py
index 3f83999d419d5c..063065251dd36e 100644
--- a/lib/ansible/module_utils/facts/other/facter.py
+++ b/lib/ansible/module_utils/facts/other/facter.py
@@ -1,17 +1,5 @@
-# This file is part of Ansible
-#
-# Ansible is free software: you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation, either version 3 of the License, or
-# (at your option) any later version.
-#
-# Ansible is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with Ansible. If not, see
Bug#1055479: fonts-fantasque-sans: New upstream version 1.8.0 (16 Nov 2019)
Package: fonts-fantasque-sans Version: 1.7.2~alpha.3~dfsg-2 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, Upstream have released a new version of this font. Please can the Debian package be updated? https://github.com/belluzj/fantasque-sans/releases/tag/v1.8.0 many thanks, Andrew
Bug#1055453: update
More information: I built from source on an arm7l schroot on my x86_64 box. There was a build failure due to permissions creating the mutex. I guessed this was a red herring due to something in my build environment, and managed to work around it by changing the mutex mechanism via a CFLAGS option The resulting .deb actually worked on my Raspberry Pi Zero 2 W. However, it was the current sid version 2.4.14.2 not 2.4.12.3 which is what was failing for me Note also I was building in vanilla debian bookworm arm7l, I don't know if Raspbian have differences. See also discussion on upstream github https://github.com/OpenIDC/mod_auth_openidc/discussions/1067
Bug#1055453: libapache2-mod-auth-openidc: Crashes on startup on armhf
Package: libapache2-mod-auth-openidc Version: 2.4.12.3-2 Severity: important X-Debbugs-Cc: and...@dev.sunshineriding.co.uk Dear Maintainer, Apache doesn't start up with the module enabled on a raspberry pi zero 2 W If I disable the module it runs OK Looks like a memory alignment issue systemctl status reports: BEGIN x apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; preset: enabled) Active: failed (Result: signal) since Mon 2023-11-06 15:55:19 GMT; 22s ago Duration: 15ms Docs: https://httpd.apache.org/docs/2.4/ Process: 2167 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS) Main PID: 2171 (code=killed, signal=BUS) CPU: 251ms Nov 06 15:55:19 raspberrypi systemd[1]: apache2.service: Main process exited, code=killed, status=7/BUS Nov 06 15:55:19 raspberrypi systemd[1]: apache2.service: Failed with result 'signal'. END dmesg has [10932.990013] Alignment trap: apache2 (2111) PC=0x76bdc824 Instr=0xed837b00 Address=0x751be419 FSR 0x801 [10932.990044] Alignment trap: not handling instruction ed837b00 at [<76bdc824>] [10932.990050] 8<--- cut here --- [10932.990074] Unhandled fault: alignment exception (0x801) at 0x751be419 [10932.990091] [751be419] *pgd=04221835, *pte=1553a75f, *ppte=1553ac7f The same error happens every time. -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 12 (bookworm) Release:12 Codename: bookworm Architecture: armv7l Kernel: Linux 6.1.0-rpi4-rpi-v7 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libapache2-mod-auth-openidc depends on: ii apache2-bin [apache2-api-20120211] 2.4.57-2 ii libapr1 1.7.2-3 ii libaprutil1 1.6.3-1 ii libc6 2.36-9+rpt2+deb12u3 ii libcjose0 0.6.2.1-1+deb12u1 ii libcurl47.88.1-10+rpi1 ii libhiredis0.14 0.14.1-3 ii libjansson4 2.14-2 ii libpcre2-8-010.42-1 ii libssl3 3.0.11-1~deb12u1+rpt1 libapache2-mod-auth-openidc recommends no packages. libapache2-mod-auth-openidc suggests no packages. -- no debconf information
Bug#1055212: librust-pyo3-dev: 0.17 version does not support sub-interpreters and leads to ImportError
Package: librust-pyo3-dev Version: 0.17.3-1 Severity: important Tags: upstream X-Debbugs-Cc: akorni...@gmail.com Dear Maintainer, * PyO3 0.17 introduced a serious regression/issue with related software (ceph, mod_wsgi and so on). Here is the issue with all the links and detailed description: https://github.com/PyO3/pyo3/issues/3451 * PyO3 0.20 seems to have this fixed according to the included PR https://github.com/PyO3/pyo3/pull/3446 -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (1001, 'stable-updates'), (1001, 'stable-security'), (1001, 'unstable'), (1001, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-0-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librust-pyo3-dev depends on: pn librust-anyhow-1+default-dev pn librust-cfg-if-1+default-dev pn librust-chrono-0.4+default-dev pn librust-chrono-0.4-dev pn librust-eyre-0.6+default-dev | librust-eyre-0.5+default-dev | libru st-eyre-0.4+default-dev pn librust-hashbrown-0.12+default-dev | librust-hashbrown-0.11+default -dev | librust-hashbrown-0.10+default-dev | librust-hashbrown-0.9+d efault-dev pn librust-hashbrown-0.13+default-dev | librust-hashbrown-0.12+default -dev | librust-hashbrown-0.11+default-dev | librust-hashbrown-0.10+ default-dev | librust-hashbrown-0.9+default-dev pn librust-indexmap-1.9+default-dev | librust-indexmap-1.8+default-dev | librust-indexmap-1.7+default-dev | librust-indexmap-1.6+default- dev pn librust-indoc-1+default-dev pn librust-indoc-2+default-dev pn librust-inventory-0.3+default-dev pn librust-libc-0.2+default-dev pn librust-memoffset-0.6+default-dev pn librust-num-bigint-0.4+default-dev pn librust-num-complex-0.4+default-dev | librust-num-complex-0.3+defau lt-dev | librust-num-complex-0.2+default-dev pn librust-parking-lot-0.12+default-dev | librust-parking-lot-0.11+def ault-dev pn librust-pyo3-build-config-0.17+abi3-dev pn librust-pyo3-build-config-0.17+abi3-py310-dev pn librust-pyo3-build-config-0.17+abi3-py37-dev pn librust-pyo3-build-config-0.17+abi3-py38-dev pn librust-pyo3-build-config-0.17+abi3-py39-dev pn librust-pyo3-build-config-0.17+default-dev pn librust-pyo3-build-config-0.17+resolve-config-dev pn librust-pyo3-build-config-0.19+abi3-dev pn librust-pyo3-build-config-0.19+abi3-py310-dev pn librust-pyo3-build-config-0.19+abi3-py311-dev pn librust-pyo3-build-config-0.19+abi3-py37-dev pn librust-pyo3-build-config-0.19+abi3-py38-dev pn librust-pyo3-build-config-0.19+abi3-py39-dev pn librust-pyo3-build-config-0.19+default-dev pn librust-pyo3-build-config-0.19+resolve-config-dev pn librust-pyo3-ffi-0.17.3+abi3-dev pn librust-pyo3-ffi-0.17.3+abi3-py310-dev pn librust-pyo3-ffi-0.17.3+abi3-py37-dev pn librust-pyo3-ffi-0.17.3+abi3-py38-dev pn librust-pyo3-ffi-0.17.3+abi3-py39-dev pn librust-pyo3-ffi-0.17.3+default-dev pn librust-pyo3-ffi-0.17.3+extension-module-dev pn librust-pyo3-ffi-0.17.3+generate-import-lib-dev pn librust-pyo3-ffi-0.19.0+abi3-dev pn librust-pyo3-ffi-0.19.0+abi3-py310-dev pn librust-pyo3-ffi-0.19.0+abi3-py311-dev pn librust-pyo3-ffi-0.19.0+abi3-py37-dev pn librust-pyo3-ffi-0.19.0+abi3-py38-dev pn librust-pyo3-ffi-0.19.0+abi3-py39-dev pn librust-pyo3-ffi-0.19.0+default-dev pn librust-pyo3-ffi-0.19.0+extension-module-dev pn librust-pyo3-ffi-0.19.0+generate-import-lib-dev pn librust-pyo3-macros-0.17.3+abi3-dev
Bug#1055128: [request-tracker-maintainers] Bug#1055128: request-tracker5: Incorrect CVE mentioned in request-tracker5 changelog
Control: found 1055128 5.0.5+dfsg-1 On Wed, 2023-11-01 at 09:11 +1100, Geoff Crompton wrote: > I noticed in the changelog entry for 5.0.3+dfsg-3~deb12u2 > CVE-2023-41620 is mentioned. But the description fro that CVE matches > the description for CVE-2023-41260 on > https://docs.bestpractical.com/release-notes/rt/5.0.5 > > I think there is a minor typo in the changelog. I noticed this typo is > also present in the changelog for 5.0.5+dfsg-1 on > https://metadata.ftp-master.debian.org/changelogs//main/r/request- > tracker5/request-tracker5_5.0.5+dfsg-1_changelog. Dammit. I was double checking those. Thank you for raising this. I've pushed commits to fix these in the next upload of each version, but I won't upload new versions just to fix this. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#996356: Confirmed at Google
We believe we've also observed this bug at Google on Debian 11. We confirmed that packets are received by the kernel, but dhclient doesn't catch them. The root cause appears to be a race condition, and we provided some details in https://gitlab.isc.org/isc-projects/dhcp/-/issues/264 to ISC, but we understand dhclient is being deprecated. The bug was also reported to Ubuntu at https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139 and there's a detailed discussion of the bug, reproduction cases, and proposed fixes, the last of which was accepted into Ubuntu Jammy. We built a test package with Ubuntu's fix applied to Debian 11 and confirmed over the weekend (more than 100k runs) that it resolves the issue. Because of some risk that the fix could cause issues elsewhere, the patch included an option to revert the change at runtime. I haven't found evidence of anyone needing to use that option. Oddly we also find that Debian 12 does not have this issue, even though the later version of dhclient does not include any fix for this. There must be some other reason why the race condition is not hit there.
Bug#1054917: evolution-ews: Importing ics calendar to Exchange server gets TZ wrong
Sure, here you go: https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/248 On Sat, 2023-10-28 at 12:24 -0400, Jeremy Bícha wrote: > On Sat, Oct 28, 2023 at 12:21 PM Andrew Perrin > wrote: > > Importing .ics calendar files downloaded from elsewhere, for > > example > > sports schedules > > from GoHeels.com, that have DTSTART and DTEND fields demarcated in > > UTC > > with Z at the end to > > identify > > Could you report this issue to the upstream developers and reply here > with the link to the issue? > > https://gitlab.gnome.org/GNOME/evolution-ews/-/issues > > Thank you, > Jeremy Bícha
Bug#1054917: evolution-ews: Importing ics calendar to Exchange server gets TZ wrong
Package: evolution-ews Version: 3.50.0-1 Severity: normal Dear Maintainer, * What led up to the situation? Importing .ics calendar files downloaded from elsewhere, for example sports schedules from GoHeels.com, that have DTSTART and DTEND fields demarcated in UTC with Z at the end to identify * What exactly did you do (or not do) that was effective (or ineffective)? Importing to an Exchange calendar connected to Evolution results in the event's time being set to the UTC time in the local time zone - for example, an event with DTSTART:20230909T211500Z DTEND:20230910T001500Z is imported as starting at 9:15 pm Eastern (my local time zone) and ending the following day at 12:15 am Eastern. The correct time would be 5:15 pm - 8:15 pm Eastern. Importing the same .ics file to a local calendar via Evolution sets the time zone as expected, and importing the same .ics file to the Exchange calendar via Office 365 (web interface) sets the time zone as expected, so I believe the problem is with Evolution's interface with the Exchange calendar. Thank you for your work! -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution-ews depends on: ii evolution3.50.0-1 ii evolution-data-server3.50.0-1 ii libc62.37-12 ii libcamel-1.2-64 3.50.0-1 ii libebackend-1.2-11 3.50.0-1 ii libebook-1.2-21 3.50.0-1 ii libebook-contacts-1.2-4 3.50.0-1 ii libecal-2.0-23.50.0-1 ii libedata-book-1.2-27 3.50.0-1 ii libedata-cal-2.0-2 3.50.0-1 ii libedataserver-1.2-273.50.0-1 ii libedataserverui-1.2-4 3.50.0-1 ii libevolution 3.50.0-1 ii libglib2.0-0 2.78.0-2 ii libgtk-3-0 3.24.38-5 ii libical3 3.0.16-1+b1 ii libjson-glib-1.0-0 1.8.0-1 ii libmspack0 0.11-1 ii libpango-1.0-0 1.51.0+ds-2 ii libsoup-3.0-03.4.3-1 ii libxml2 2.9.14+dfsg-1.3 evolution-ews recommends no packages. evolution-ews suggests no packages. -- no debconf information
Bug#1040996: Davical defines a Content-Security-Policy without scoping it to its own resources
Hi Alain, Thanks for the bug report. I have added a fix to DAViCal so the CSP is only applied to the Directory as suggested. I'm looking at your .well-known request, but I don't think DAViCal and NextCloud can co-exist so easily as it looks like they both have overlapping well-known paths. I would expect they need to go into their own vhost. And while I could limit the rewrites, we still have: RewriteRule ^(.*)$ /caldav.php$1 [NC,L] I think there'll be far too many different options to want to split that out. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1040996: [DAViCal-devel] Bug#1040996: Why "form-action 'self' sis.redsys.es"?
On Mon, 2023-10-23 at 10:05 +0200, Philipp Marek via DAViCal-devel wrote: > For that config line, why is > > form-action 'self' sis.redsys.es > > set up as a default? > > I guess that's a left-over for testing from upstream, > but that should be removed in the official default config file. That is a mistake which I accidentally introduced. Funnily enough was raised on the davical-devel mailing list today. I have already submitted an MR to resolve this. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1054018: Acknowledgement (splint: Segmentation violation in transferChecks.c)
Sorry to immediately reply to my own post, but I found which part of the input was triggering the bug. In the pv__format() function, from line 788, there is a large "switch" section. Two of the cases in that switch declare some local variables (lines 917 and 996). Moving both of those local variable declarations out to the block enclosing the "switch" (line 769) stops splint from crashing out. So it was local variable declarations inside a "case" statement that were triggering the fault. -- Andrew Wood
Bug#1054018: splint: Segmentation violation in transferChecks.c
Package: splint Version: 1:3.1.2+dfsg-5 Severity: normal Dear Maintainer, I have been using splint to clean up the PV code[1], and after restructuring src/pv/display.c, found that splint now exits with a segmentation violation when processing that file: *** Segmentation Violation *** Location (not trusted): display.c:917:25 *** Last code point: transferChecks.c:3445 *** Previous code point: transferChecks.c:3437 The changes to "display.c" and "pv-internal.h" that triggered this bug were reasonably significant and introduced sub-structures to the main state structure. I don't know if that's related but I haven't been able to make splint happy with the "display_buffer" variable, as it says it's undefined. A tarball which illustrates the problem is attached; running "bug.sh" should reproduce the error. If additional context is needed, this is effectively an excerpt from PV's git repository[2]. Prior to making these changes, splint was running on all ".c" files in the project without incident. [1] - https://u33067285.ct.sendgrid.net/ls/click?upn=w3EznbKywG7cJlyycYu1XCPHPvMClRoEqyVXd3jgvNQMqaQf9MHqASWGIW0yfqCMpHPmEg1pi6gHqjfiHAkxkw-3D-3DXiSd_kfytytOqXJMoRhb2oyNeM0XjBzsVuOf-2Bk81owLo9uR9sYpCwlpdJYjR1UX-2B0r3O1z54te5elY894ejASOMvPLVUZFY3BC20nFfPdi1-2Bh5-2Fq-2FmyG3mQaYR6TAFOqAmm5OR0Aq8GyFNo3fMSqUICYCAFC0EbZ88J7D1nnCO6z36UOpC5xM4OEWogay4wg7yMLTqQLiArJ4r1-2FAqlCcJ45lqg-3D-3D [2] - https://u33067285.ct.sendgrid.net/ls/click?upn=w3EznbKywG7cJlyycYu1XKXbhztQw403AUCQDYEK2jas0KMgMBTrvzP8mbx5v65USWjq_kfytytOqXJMoRhb2oyNeM0XjBzsVuOf-2Bk81owLo9uR9sYpCwlpdJYjR1UX-2B0r3O1Dsssxr72O5Bf6AQAAS5zPvu-2BC2Tyo2veuYggU-2FXk7Z1NDN-2FOaiRbi8GG-2FzMnWMy1jYPyDeBmjOKBXezCBy-2FVeFp-2F3MeM6SqF5UOgpEn8xRUs8z-2F-2BoGWVK9NWr47Ytt7-2Bf-2Fv8CPqp6Z-2BeVp81gXlV0A-3D-3D -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/1 CPU thread; PREEMPT) Kernel taint flags: TAINT_SOFTLOCKUP 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 splint depends on: ii libc62.36-9+deb12u3 ii libfl2 2.6.4-8.2 ii splint-data 1:3.1.2+dfsg-5 splint recommends no packages. Versions of packages splint suggests: pn splint-doc-html -- no debconf information reproduce-splint-bug.tar.gz Description: application/gzip
Bug#1053438: molly-guard: Support configuration management tools like Ansible
Package: molly-guard Version: 0.7.2 Severity: wishlist Tags: patch Dear Maintainer, While working on adding a snippet to molly-guard to check for running VMs and prompt if there are any, we discovered that the standard approach for systems managed by Ansible is to bypass molly-guard completely. See https://docs.ansible.com/ansible/8/collections/ansible/builtin/reboot_module.html and search for molly-guard. We use Ansible, and I think this sucks, as I want molly-guard to protect reboots for other situations. I have modified molly-guard to detect being run by Ansible and not ask questions, just exit 1 and refuse to take action. We have deployed this to some of our fleet and have found it to work fine. Would you please consider merging this change? Changes are here: https://salsa.debian.org/puck/molly-guard/-/commits/conf-mgmt This also includes patches for general housekeeping of the package. In addition, I have considered whether the prompt logic and sigh() should be moved into shutdown.in and allowed to be generic. I'd be interested to hear your thoughts, and I'd be happy to have a punt at that. Kind regards, Andrew -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_AUX Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages molly-guard depends on: ii procps 2:4.0.2-3 molly-guard recommends no packages. molly-guard suggests no packages. -- no debconf information
Bug#1053337: qgis_process ails with Command --noversioncheck not known
Subject: qgis_process ails with Command --noversioncheck not known Package: qgis X-Debbugs-Cc: andrew.harv...@gmail.com Version: 3.28.11+dfsg-1 Severity: important Dear Maintainer, Executing qgis_process --help results in the error Command --noversioncheck not known! It was expected to output the help page It appears this is due to sourcing /etc/default/qgis which includes the --noversioncheck option although that option only applies to qgis and not qgis_process. Calling qgis_process.bin directly and making sure to include the grass path works around the issue. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qgis depends on: ii libc62.37-10 ii libgcc-s113.2.0-4 ii libgdal333.7.2+dfsg-1 ii libgeos-c1v5 3.12.0-1 ii libproj259.3.0-1 ii libqgis-3d3.28.113.28.11+dfsg-1 ii libqgis-analysis3.28.11 3.28.11+dfsg-1 ii libqgis-app3.28.11 3.28.11+dfsg-1 ii libqgis-core3.28.11 3.28.11+dfsg-1 ii libqgis-gui3.28.11 3.28.11+dfsg-1 ii libqt5core5a 5.15.10+dfsg-3 ii libqt5gui5 5.15.10+dfsg-3 ii libqt5keychain1 0.14.1-1 ii libqt5network5 5.15.10+dfsg-3 ii libqt5webkit55.212.0~alpha4-33 ii libqt5widgets5 5.15.10+dfsg-3 ii libstdc++6 13.2.0-4 ii ocl-icd-libopencl1 [libopencl1] 2.3.2-1 ii python3-qgis 3.28.11+dfsg-1 ii qgis-common 3.28.11+dfsg-1 ii qgis-providers 3.28.11+dfsg-1 Versions of packages qgis recommends: pn qgis-plugin-grass Versions of packages qgis suggests: ii gpsbabel 1.8.0+ds-7 -- no debconf information
Bug#1051921: CVE-2023-1393 and TigerVNC
Package: tigervnc-standalone-server Version: 1.12.0+dfsg-8 RedHat have released updates to tigervnc to address CVE-2023-1393, e.g. https://access.redhat.com/errata/RHSA-2023:1592 but https://security-tracker.debian.org/tracker/CVE-2023-1393 does not mention tigervnc, and the latest version predates the CVE. I guess this relates to the binary package tigervnc-standalone-server but the fix might be needed in one or more of the other tigervnc binary packages. Upstream discussion at https://groups.google.com/g/tigervnc-users/c/5dq5O2OAoQI -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#1050378: python3-selenium package in Trixie
Just to confirm, I have the exact same problem as reported by Frank de Bruijn . I have tried uninstalling and reinstalling with no improvement. Cheers, Andrew King
Bug#1050463: RFP: picosnitch -- monitor network traffic per executable
Package: picosnitch Severity: wishlist * Package name: picosnitch Version : 0.14.1 Upstream Author : Eric Lesiuta * URL : https://github.com/elesiuta/picosnitch * License : GPL-3 Programming Lang: Python (BPF) Description : monitor network traffic per executable Picosnitch is a per application bandwidth monitor which notifies users when new apps make internet connections, or when the hash of an application has changed since its last connection. It has a terminal based UI for browsing and filtering traffic history on: time, executable, sha256, parent of the executable, uid, local/remote ports, local/remote addresses, or domain. There is also an optional GUI for viewing bandwidth graphs using plotly dash (https://pypi.org/project/dash/) which needs to be installed separately with pip or pipx. It would be nice if this could be packaged in Debian as well.
Bug#986707: rt4-db-mysql: should declare an incompatibility with mysql 8
The problem I can see with conflicting with mysql-server-8.0 is that a user could have both MySQL and MariaDB installed on the same server, as they should be able to co-exist (listen on different ports). If we conflict, then we prevent that. The issue is that in Debian default-mysql-client and virtual-mysql-client (and -server) depend on mariadb, but in Ubuntu they depend on mysql. Perhaps we should explicitly depend on the mariadb packages. Thinking about this is a bit further, this does seem the best option. RT 5.0.4 supports MySQL 8, which is now in Debian Unstable, so this'd only apply to the RT4 packages now. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1050048: [request-tracker-maintainers] Bug#1050048: request-tracker5: depends on obsolete package fonts-noto-hinted
Control: tag -1 + pending Upload currently blocked while I try and find the dependency that is causing our tests to fail. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1034417: samba: Samba can no longer authenticate users via Kerberos from a standalone KDC
On Thu, 2023-08-10 at 10:03 +0300, Michael Tokarev wrote: > Control: tag -1 - moreinfo + wontfixControl: severity -1 minor > 15.04.2023 00:03, Daniel Lakeland wrote:... > > Hi Michael, my concern is mainly to document the existence of this > > problem for others who might use this similar config. I'm 100% sure > > I'm not the only one in the world. There are debian bugs going back > > a while where others have this kind of set up and had issues. I'll > > continue to try to figure out the work around, and then document > > the method I came up with here, and then we can close the bug so > > it's preserved for others with similar issues? > > It looks like you're one of maybe just a few people in the worldwho > uses this config with samba and stand-alone ldap and kdc, aftersamba > made everything to be internal because separate componentswere > basically unmanageable. > In order for this bug report to not disturb my workflow (not to > paymore attention to it every time I look at samba bugs), - since > itis for documentation purpose only, I'm lowering severity of it > andadding a "wontfix" tag. > Thanks, > /mjt Per https://lists.samba.org/archive/samba/2023-April/244999.html it *might* work if the MIT KDC were adjusted not to issue a PAC https://web.mit.edu/kerberos/krb5-1.20/ suggests disable_pac in the realm configuration on the KDC. Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead https://catalyst.net.nz/services/sambaCatalyst.Net Ltd Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company Samba Development and Support: https://catalyst.net.nz/services/samba Catalyst IT - Expert Open Source Solutions
Bug#1011163: samba: FTBFS on kfreebsd
This looks like a build environment issue being unable to find a compiler. Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead https://catalyst.net.nz/services/sambaCatalyst.Net Ltd Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company Samba Development and Support: https://catalyst.net.nz/services/samba Catalyst IT - Expert Open Source Solutions
Bug#1042985: libgnupg-interface-perl: FTBFS with Perl 5.38: Insecure directory in $ENV{PATH} while running with -T switch
Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=149323 Control: tag -1 + fixed pending Hi Niko, Thank you for Cc'ing me, yes, I'm still interested. I've had a look, and prepared a patch and forwarded it to upstream. This is now in Salsa - I can't upload it as I'm not an Uploader nor a DD (yet). The test which broke is one I wrote to test GnuPG::Interface when running taint mode as there are packages in Debian that use that and they break when GnuPG::Interface breaks. > Hm, possibly perl should add a Breaks for earlier versions once this is > fixed. Yeah, seems sensible. I expect this'll probably affect other packages as well. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz | signature.asc Description: This is a digitally signed message part
Bug#1043041: RM: rt-extension-elapsedbusinesstime/experimental -- ROM; No longer required in experimental
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: rt-extension-elapsedbusinesst...@packages.debian.org Control: affects -1 + src:rt-extension-elapsedbusinesstime Hi, This package has been uploaded to unstable, please remove it from experimental. Kind regards, Andrew
Bug#1042008: xrdp: Please add an override for needrestart to avoid accidentally breaking apt upgrades
Package: xrdp
Version: 0.9.21.1-1
Severity: normal
X-Debbugs-Cc: a.t.chadw...@gmail.com
Dear Maintainer,
XRDP should be integrated with needrestart so that the default behaviour of
NeedRestart::UI::Debconf’s dialogs becomes safer. Currently, the xrdp and
xrdp-sesman services are selected automatically for restarting when
libraries affecting running desktop packages in xrdp session are updated.
This is unlike all normal local display managers, which have a specific
exemption because the user might be running their system upgrade from a
graphical session.
$ cat /etc/needrestart/needrestart.conf
[...]
# Override service default selection (hash of regex).
$nrconf{override_rc} = {
[...]
# display managers
qr(^gdm) => 0,
qr(^kdm) => 0,
qr(^nodm) => 0,
qr(^sddm) => 0,
qr(^wdm) => 0,
[...]
These overrides prevent the upgrade getting accidentally terminated should
the admin applying the upgrade click through the dialogs without looking,
by giving them safe default behaviour.
This hash defined in the main conffile can be extended to support
additional service regexes with a drop-in conffile stub:
$ cat /etc/needrestart/conf.d/xrdp.conf
# Ensure that the xrdp display manager isn’t offered for restart.
$nrconf{override_rc}{qr(^xrdp)} = 0;
This causes the XRDP services to be initially *deselected* in the
needrestart dialogs that are hooked by apt, instead of *selected*
initially. This is safer because clicking through the needrestart dialog
does not cause an apt or apt-get launched in a graphical session to
terminate when xrdp restarts. Xrdp becomes like any other graphical display
manager.
(Brought to you by me having to remember to do this every time. Sometimes I
am lazy and, well, oops.)
many thanks,
Andrew
Bug#1040975: CW font disabled in groff-base v1.23
Control: reassign -1 groff-base Control: affects -1 perl Hey, I think a change in groff-base to re-enable the CW font alias might be reasonable. This affects a number of other packages, not just perl (via pod2man), for example: puck@dirk:~$ man --warnings /usr/share/man/man1/strace.1.gz > /dev/null troff::88: warning: macro 'IX' not defined troff::119: warning: cannot select font 'CW' troff::124: warning: cannot select font 'CW' ... (Lintian excludes the IX macro which is why that is present) Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz | signature.asc Description: This is a digitally signed message part
Bug#1040975: perl: pod2man uses CW, groff-base no longer supports this by default
Package: perl
Version: 5.36.0-7
Severity: normal
Dear Maintainer,
groff-base v1.23 has been uploaded to unstable, which disables the CW macro
by default. This causes errors like this to be generated with pod2man now:
puck@dirk:~$ pod2man /usr/share/perl/5.36.0/version.pod | nroff -man | grep CW
troff::145: warning: cannot select font 'CW'
troff::182: warning: cannot select font 'CW'
troff::191: warning: cannot select font 'CW'
troff::205: warning: cannot select font 'CW'
troff::207: warning: cannot select font 'CW'
...
This is causing lintian to be upset when build packages, e.g.:
W: rt-extension-mergeusers-common: groff-message troff::115:
warning: cannot select font 'CW'
[usr/share/man/man3/RT::Extension::MergeUsers.3pm.gz:1]
This version of groff-base introduces a new option in /etc/groff/man.local:
.\" "CW" is not a portable font name, but some man pages use it anyway.
.\" Uncomment this to suppress warnings produced by such pages. This
.\" test remaps the font to roman ("R") on nroff (terminal) devices. You
.\" might prefer to remap it to bold ("B") instead.
.\" .if n .ftr CW R
Now, is it pod2man or groff-base that is at fault here? Perl 5.38 still uses
CW in pod2man by default.
Cheers,
Andrew
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=C.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 perl depends on:
ii dpkg 1.21.22
ii libperl5.365.36.0-7
ii perl-base 5.36.0-7
ii perl-modules-5.36 5.36.0-7
Versions of packages perl recommends:
ii netbase 6.4
Versions of packages perl suggests:
pn libtap-harness-archive-perl
ii libterm-readline-gnu-perl1.45-1
ii libterm-readline-perl-perl 1.0303-2.1
ii make 4.3-4.1
ii perl-doc 5.36.0-7
-- no debconf information
Bug#1040650: console-setup: transition from /etc/default/keyboard to /etc/vconsole.conf
On Sat, Jul 08, 2023 at 03:05:20PM +, snv5gh+elqseqrl4eotk@cs.email wrote: > Package: console-setup > Version: 1.221 > Severity: normal > > Dear Maintainer, > > Similarly to #1038798 please transition away from the debianism > /etc/default/keyboard to /etc/vconsole.conf which is used by many other > systems, and is systemd default. Thank you. > Both are present. Both contain similar information but one is tied to XKB. It's quite possible that one will disappear as Wayland comes in for everything?
Bug#1039742: [DAViCal-devel] Bug#1039742: Add support for phpunit 10
Hi Athos, Thank you! As upstream, I've merged the MR -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1040174: nvidia-driver: Can't upgrade to nvidia-driver-525.116.04-1 on debian unstable: build fails
Package: nvidia-driver Version: 525.116.04-1 Severity: important X-Debbugs-Cc: andrewgop...@tutanota.com Dear Maintainer, Today, after a long time of not checking for upgrades, I finally upgraded all of my packages. ALl of the other packages upgraded just fine, but my nvidia driver faild to build. I was pointed to a make.log file, which showed an error at the end saying that "asm/orc_header.h" was not found. I've already tried rebooting and purging all nvidia packages then reinstalling. I also tried to find the orc_header.h, but both /usr/include/asm-generic and /usr/include/x86_64-linux-gnu/asm do not contain the file. -- Package-specific info: uname -a: Linux gopherbox 6.3.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1 (2023-06-12) x86_64 GNU/Linux /proc/version: Linux version 6.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1 (2023-06-12) lspci 'display controller [030?]': 27:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: eVga.com. Corp. GP107 [GeForce GTX 1050 Ti] [3842:6251] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel modules: nvidia dmesg: Device node permissions: video:x:44:andrewgopher Alternative 'nvidia': nvidia - auto mode link best version is /usr/lib/nvidia/current link currently points to /usr/lib/nvidia/current link nvidia is /usr/lib/nvidia/nvidia slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libGLESv1_CM_nvidia.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLESv1_CM_nvidia.so.1 slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1 slave nvidia--libGLESv2_nvidia.so.2-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLESv2_nvidia.so.2 slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2 slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libcuda.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so slave nvidia--libcuda.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libcuda.so slave nvidia--libcuda.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so.1 slave nvidia--libcuda.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libcuda.so.1 slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so slave nvidia--libnvcuvid.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvcuvid.so slave nvidia--libnvcuvid.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvcuvid.so slave nvidia--libnvcuvid.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvcuvid.so.1 slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1 slave nvidia--libnvidia-allocator.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-allocator.so.1 slave nvidia--libnvidia-allocator.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-allocator.so.1 slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 slave nvidia--libnvidia-encode.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-encode.so.1 slave nvidia--libnvidia-encode.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1 slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 slave nvidia--libnvidia-ptxjitcompiler.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-ptxjitcompiler.so.1 slave nvidia--libnvidia-ptxjitcompiler.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.1 slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1 slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy slave nvidia--nvidia-application-profiles-key-documentation is /usr/share/nvidia/nvidia-application-profiles-key-documentation slave nvidia--nvidia-blacklists-nouveau.conf is /etc/nvidia/nvidia-blacklists-nouveau.conf slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump slave nvidia--nvidia-drm-outputclass.conf is /etc/nvidia/nvidia-drm-outputclass.conf slave nvidia--nvidia-drm_gbm.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/gbm/nvidia-drm_gbm.so slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf slave
Bug#903960: Possibly fixed?
Hey, The upstream bug in gtk has been closed, with the fix being merged into gtk- 3-24 branch in Nov 2019 and was included in GTK 3.24.13. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1038344: bookworm-pu: package request-tracker5/5.0.3+dfsg-2+deb12u1
On Mon, 2023-06-26 at 07:01 +0100, Jonathan Wiltshire wrote:
> On Mon, Jun 26, 2023 at 04:42:27PM +1200, Andrew Ruthven wrote:
> > Changelog updated as requested, and uploaded to bookworm.
>
> You need a tilde in the version, not a plus ("lower than"). I'll reject
> the
> upload, you can upload a fixed version whenever you like.
Doh. Fixed.
Cheers,
Andrew
--
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |
Bug#1038344: bookworm-pu: package request-tracker5/5.0.3+dfsg-2+deb12u1
On Sun, 2023-06-25 at 17:43 +0100, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > I just happened to look at this; otherwise as it was still tagged > "moreinfo" it would probably have been waiting for attention for quite a > while. Oops, I did wonder if I should change the tag. > As 5.0.3+dfsg-3 in unstable is limited to these changes anyway, you can > backport it directly and the version history makes things a bit clearer > for > some infrastructure. Just add a changelog entry on top of the unstable > version, "Backport to bookworm" or something, version 5.0.3+dfsg- > 3~deb12u1, > target bookworm. Don't remove the changelog for 5.0.3+dfsg-3. > > Example: > https://release.debian.org/proposed-updates/bookworm_diffs/onionshare_2.6-5~deb12u1.debdiff > > Other than that, please go ahead. Awesome, thank you. I figured it'd make life easier to upload only these changes to unstable initially. Changelog updated as requested, and uploaded to bookworm. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1038201: firewalld: Firewalld not forwarding packets from private LAN servers
Dear Maintainer, I have struggled with this for a few days. It is not a bug, but an incompatible change in Firewalld since Bullseye. Default policy is now not to allow forwarding between zones. Policy needs to be set manually. For example: firewall-cmd --permanent --new-policy allowForward firewall-cmd --permanent --policy allowForward --set-target ACCEPT firewall-cmd --permanent --policy allowForward --add-ingress-zone internal firewall-cmd --permanent --policy allowForward --add-egress-zone external firewall-cmd --reload See https://firewalld.org/2020/09/policy-objects-introduction and Firewalld Git Bug #866 and #917. Trust that helps. Andrew
Bug#1038344: bookworm-pu: package request-tracker5/5.0.3+dfsg-2+deb12u1
[Resent Cc'ing in the bug, Evolution dropped it first time round, sigh] On Sat, 2023-06-17 at 13:05 +0100, Adam D. Barratt wrote: > You appear to have attached a binary debdiff. Please provide a _source_ > debdiff for checking. My apologies, first time I've done this. I had generated it as well. Please find the source debdiff attached. The patches are managed using git-dpm which is why the git commit ID has changed for all of them. The patch in question is debianize_version.diff . Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz | diff -Nru request-tracker5-5.0.3+dfsg/debian/changelog request-tracker5-5.0.3+dfsg/debian/changelog --- request-tracker5-5.0.3+dfsg/debian/changelog 2022-07-22 01:28:17.0 +1200 +++ request-tracker5-5.0.3+dfsg/debian/changelog 2023-06-11 14:19:13.0 +1200 @@ -1,3 +1,11 @@ +request-tracker5 (5.0.3+dfsg-2+deb12u1) bookworm; urgency=medium + + * Strip Debian version suffix from generated hyperlinks to upstream docs +(Closes: 1033304). + * Fix the changelog date entry for the 5.0.3+dfsg-2 release. + + -- Andrew Ruthven Sun, 11 Jun 2023 14:19:13 +1200 + request-tracker5 (5.0.3+dfsg-2) unstable; urgency=medium * Add more fields to d/upstream/metadata @@ -13,7 +21,7 @@ * Remove dependency on lsb-base as it is an obsolete package. * Refresh d/copyright - -- Andrew Ruthven Fri, 22 Jul 2022 01:28:17 +1200 + -- Andrew Ruthven Sat, 04 Feb 2023 12:30:17 +1300 request-tracker5 (5.0.3+dfsg-1.1) unstable; urgency=medium diff -Nru request-tracker5-5.0.3+dfsg/debian/.git-dpm request-tracker5-5.0.3+dfsg/debian/.git-dpm --- request-tracker5-5.0.3+dfsg/debian/.git-dpm 2022-07-22 01:28:17.0 +1200 +++ request-tracker5-5.0.3+dfsg/debian/.git-dpm 2023-06-05 20:13:11.0 +1200 @@ -1,6 +1,6 @@ # see git-dpm(1) from git-dpm package -c18433eb098f64a7c1d81502e7bcc689a2df0943 -c18433eb098f64a7c1d81502e7bcc689a2df0943 +28481171ee3345c8bed6efb9d5a46cfce1547fc0 +28481171ee3345c8bed6efb9d5a46cfce1547fc0 52cb0ca22325e7a067f0a3411ffb55ef03d47aa4 52cb0ca22325e7a067f0a3411ffb55ef03d47aa4 request-tracker5_5.0.3+dfsg.orig.tar.gz diff -Nru request-tracker5-5.0.3+dfsg/debian/patches/debianize_charts.diff request-tracker5-5.0.3+dfsg/debian/patches/debianize_charts.diff --- request-tracker5-5.0.3+dfsg/debian/patches/debianize_charts.diff 2022-07-22 01:28:17.0 +1200 +++ request-tracker5-5.0.3+dfsg/debian/patches/debianize_charts.diff 2023-06-05 20:13:11.0 +1200 @@ -1,4 +1,4 @@ -From 90ca199172517271447e571d777964324343ef1a Mon Sep 17 00:00:00 2001 +From e4a897eeca21986a0fe788ad15edb6f500c99772 Mon Sep 17 00:00:00 2001 From: Andrew Ruthven Date: Thu, 9 Jul 2020 23:03:35 +1200 Subject: On Debian there is no need to install the GD modules if GD is diff -Nru request-tracker5-5.0.3+dfsg/debian/patches/debianize_commands.diff request-tracker5-5.0.3+dfsg/debian/patches/debianize_commands.diff --- request-tracker5-5.0.3+dfsg/debian/patches/debianize_commands.diff 2022-07-22 01:28:17.0 +1200 +++ request-tracker5-5.0.3+dfsg/debian/patches/debianize_commands.diff 2023-06-05 20:13:11.0 +1200 @@ -1,4 +1,4 @@ -From 13f2358416863200df51361f2643e7ec35680748 Mon Sep 17 00:00:00 2001 +From 2b5ef414f9d88dc4321d602dda5556c6bd04eb90 Mon Sep 17 00:00:00 2001 From: Andrew Ruthven Date: Thu, 9 Jul 2020 22:53:09 +1200 Subject: Use Debian location of commands and data diff -Nru request-tracker5-5.0.3+dfsg/debian/patches/debianize_extensions.diff request-tracker5-5.0.3+dfsg/debian/patches/debianize_extensions.diff --- request-tracker5-5.0.3+dfsg/debian/patches/debianize_extensions.diff 2022-07-22 01:28:17.0 +1200 +++ request-tracker5-5.0.3+dfsg/debian/patches/debianize_extensions.diff 2023-06-05 20:13:11.0 +1200 @@ -1,4 +1,4 @@ -From 4ea4ef63b501e9c635c0d18340f15107427f59be Mon Sep 17 00:00:00 2001 +From 83787c6f7b0c8f3683bc06c756575e444e2fc808 Mon Sep 17 00:00:00 2001 From: Andrew Ruthven Date: Thu, 9 Jul 2020 22:33:55 +1200 Subject: Point to Debian locaton of mason_data. diff -Nru request-tracker5-5.0.3+dfsg/debian/patches/debianize_version.diff request-tracker5-5.0.3+dfsg/debian/patches/debianize_version.diff --- request-tracker5-5.0.3+dfsg/debian/patches/debianize_version.diff 2022-07-22 01:28:17.0 +1200 +++ request-tracker5-5.0.3+dfsg/debian/patches/debianize_version.diff 2023-06-05 20:13:11.0 +1200 @@ -1,4 +1,4 @@ -From 55312fbba42fbedd49061601741d5960061d5703 Mon Sep 17 00:00:00 2001 +From e00d7b16bc8b70db0125349ead6841adfa1d4c32 Mon Sep 17 00:00:00 2001 From: Dominic Hargreaves Date: Thu, 31 Dec 2015 12:17:56 + Subject: Extract the correct (Debian) version number in configure.ac @@ -8,9 +8,10 @@ Patch-Name: debianize_version.diff --- - configure.ac | 8 - share/html/Elements/Footer | 2 +- - 2 files changed, 5 insertions(+), 5 deletions(-) + config
Bug#1038344: bookworm-pu: package request-tracker5/5.0.3+dfsg-2+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: request-track...@packages.debian.org Control: affects -1 + src:request-tracker5 [ Reason ] The version in bookworm includes a bug where the suffix we append to the upstream version is included in a generated URL for accessing documentation about configuration settings presented in the UI. Bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033304 We weren't able to include this in the bookworm releases as our packages suffered a FTBFS issue due to a rhino and closure-compiler issue, as discussed here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036159 By the time the issues with closure-compiler and rhino were resolved it was too late to get a fixed version of request-tracker5 into bookworm. I have also included a minor fix to the date string in d/changelog for 5.0.3+dfsg-2 as I failed to update the date when I uploaded that version, and then due to the FTBFS issue I wasn't able to resolve it when I spotted it. Version 5.0.3+dfsg-3 in unstable only includes the fixes which are proposed for bookworm. [ Impact ] When an RT administrator attempts to look up the documentation for a configuration setting, they'll get a 404. [ Tests ] I have installed the proposed packages on my personal RT installation running bookworm, and verified that the generated links are correct and work. [ Risks ] Low risk. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] d/patch/debianize_version.diff now modifies share/html/Admin/Tools/Config/Elements/Option to strip everything after and including '+dfsg-' from the version string. [ Other info ] I acknowledge that it would be preferable to link to documentation contained within the running system, but our packages don't currently configure the generated documentation to be accessible via the web. File lists identical (after any substitutions)
Bug#1037316: www.debian.org: Download links on www.debian.org after release = no iso images, only BT
On Sun, Jun 11, 2023 at 12:54:43PM +0200, Holger Wansing wrote: > Hi, > > Am 11. Juni 2023 11:29:54 MESZ schrieb "Andrew M.A. Cater" > : > >Package: www.debian.org > >Severity: important > > > >Dear Maintainer, > > > >*** Reporter, please consider answering these questions, where appropriate > >*** > > > > * What led up to the situation? > > > >Following Bookworm release and new layout: download links missing on > >www.debian.org for live CDs and some other images. Only BT links are there. > > > > * What exactly did you do (or not do) that was effective (or > > ineffective)? > > > >Followed download link on front page https://www.debian.org https://www.debian.org/download links to https://www.debian.org/distrib/ This page is missing links to larger images like DVD and the only links are the links to torrents. Debian Live links are also only torrents https://www.debian.org/CD/ still has suggestions for 11.7 https://www.debian.org/CD/http-ftp/ then needs rewrite Most of these are in progress somewhere, I know, and stuff is busy, busy Thanks, Andy > > > > * What was the outcome of this action? > > > >Redirect to appropriate page but links missing. > > > > * What outcome did you expect instead? > > > >Download links to full CD/DVD/debian-live DVD images > > > > Please report the exact link of the page where you encounter this! > > Holger > > > > -- > Sent from /e/ OS on Fairphone3
Bug#1037316: www.debian.org: Download links on www.debian.org after release = no iso images, only BT
Package: www.debian.org Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Following Bookworm release and new layout: download links missing on www.debian.org for live CDs and some other images. Only BT links are there. * What exactly did you do (or not do) that was effective (or ineffective)? Followed download link on front page * What was the outcome of this action? Redirect to appropriate page but links missing. * What outcome did you expect instead? Download links to full CD/DVD/debian-live DVD images
Bug#1037248: ITP: libcss-inliner-perl -- Convert CSS
Package: wnpp Owner: Andrew Ruthven Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libcss-inliner-perl Version : 4018 Upstream Author : Kevin Kamel * URL : https://metacpan.org/release/CSS-Inliner * License : Artistic or GPL-1+ Programming Lang: Perl Description : Convert CSS
Bug#1037246: ITP: libhtml-query-perl -- perform jQuery-like queries on HTML::Element trees
Package: wnpp Owner: Andrew Ruthven Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libhtml-query-perl Version : 0.09 Upstream Author : Kevin Kamel * URL : https://metacpan.org/release/HTML-Query * License : Artistic or GPL-1+ Programming Lang: Perl Description : perform jQuery-like queries on HTML::Element trees The HTML::Query module is an add-on for the HTML::Tree module set. It provides a simple way to select one or more elements from a tree using a query syntax inspired by jQuery. This selector syntax will be reassuringly familiar to anyone who has ever written a CSS selector. HTML::Query is not an attempt to provide a complete (or even near-complete) implementation of jQuery in Perl (see Ingy's pQuery module for a more ambitious attempt at that). Rather, it borrows some of the tried and tested selector syntax from jQuery (and CSS) that can easily be mapped onto the look_down() method provided by the HTML::Element module. The package will be maintained under the umbrella of the Debian Perl Group. This package is being added to Debian as it is dependency for CSS::Inliner which will be used by v5.0.4 of Request Tracker. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1014124: nomacs: CVE-2020-23884
I think this should be filled against https://tracker.debian.org/pkg/qtimageformats-opensource-src Explanation: https://github.com/nomacs/nomacs/issues/516#issuecomment-1578313635
Bug#1037117: ITP: libbadger-perl -- Badger application programming toolkit
Package: wnpp Owner: Andrew Ruthven Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libbadger-perl Version : 0.16 Upstream Author : Andy Wardley * URL : https://metacpan.org/release/Badger * License : Artistic or GPL-1+ Programming Lang: Perl Description : Badger application programming toolkit The Badger toolkit is a collection of Perl modules designed to simplify the process of building object-oriented Perl applications. It provides a set of foundation classes upon which you can quickly build robust and reliable systems that are simple, skimpy and scalable. The package will be maintained under the umbrella of the Debian Perl Group. This package is being added to Debian as it is an indirect build dependency for CSS::Inliner which will be used by v5.0.4 of Request Tracker. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1037110: ITP: libgraphviz2-perl -- Perl interface to the GraphViz graphing tool
Package: wnpp Owner: Andrew Ruthven Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libgraphviz2-perl Version : 2.67 Upstream Author : Ron Savage * URL : https://metacpan.org/release/GraphViz2 * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl interface to the GraphViz graphing tool This module provides an interface to layout and image generation of directed and undirected graphs in a variety of formats (PostScript, PNG, etc.) using the "dot", "neato", "twopi", "circo" and "fdp" programs from the GraphViz project (http://www.graphviz.org/ or http://www.research.att.com/sw/tools/graphviz/). This is a complete rewrite of the module in libgraphviz-perl which extends support to all the latest features of Graphviz. It is not backwards compatible with libgraphviz-perl. In addition, the GraphViz Perl module is deprecated[0], GraphViz2 is the replacement. GraphViz2 is a dependency of Request Tracker v5.0.4. The package will be maintained under the umbrella of the Debian Perl Group. [0] https://metacpan.org/pod/GraphViz -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz | signature.asc Description: This is a digitally signed message part
Bug#1037109: ITP: libtest-snapshot-perl -- test against data stored in automatically-named file
Package: wnpp Owner: Andrew Ruthven Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name : libtest-snapshot-perl Version : 0.06 Upstream Author : Ed J * URL : https://metacpan.org/release/Test-Snapshot * License : GPL-1+ or Artistic Programming Lang: Perl Description : test against data stored in automatically-named file Not connected with Test::Snapshots, which is based on a similar concept but for running executables. Implements a function to automate the storing and updating of expected test outputs. This is based on the idea known in frontend development circles as "snapshot testing", hence the module name. The package will be maintained under the umbrella of the Debian Perl Group. This module is required for building the GraphViz2 Perl module which I'm about to file an ITP about. [Apologies for the previous email, first time I've submitted an ITP for a number of years!] -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz | signature.asc Description: This is a digitally signed message part
Bug#1036715: grub-efi-arm64: i.MX8QM Synchronous Abort on EFI boot
Package: grub-efi-arm64 Version: 2.06-3~deb11u5 Severity: important X-Debbugs-Cc: andrewjlamar...@gmail.com Dear Maintainer, [Impact] When using GRUB as a second stage bootloader on an i.MX SPEAR-MX8 with the CustomBoard dev kit, a Synchronous Abort occurs. U-Boot is the first stage. This board has 4x A53, 2x A72 and 2x Cortex M4 CPUs. [Tests] * "Vanilla" kernels from https://github.com/varigit/linux-imx on 5.10 and 5.15 fail to boot. * Using U-Boot from https://github.com/varigit/uboot-imx is fine, able to boot kernel directly without issue, and is compiled with EFI support Seems to maybe be related to https://bugs.launchpad.net/ubuntu/+source/grub2-unsigned/+bug/1987924, only this abort happens every time. Here's the debug trace: kern/efi/fdt.c:38: found registered FDT @ 0x8810 loader/efi/fdt.c:63: allocating 136192 bytes for fdt loader/arm64/linux.c:89: Initrd @ 0xdc0e8000-0xdca8e2ad loader/efi/fdt.c:97: Installed/updated FDT configuration table @ 0xdc0c6000 loader/arm64/linux.c:144: linux command line: 'BOOT_IMAGE=/boot/image/vmlinuz boot=live cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory quiet rootdelay=5 noautologin net.ifnames=0 biosdevname=0 coherent_pool=4M console=ttyLP0,115200n8 systemd.show_status=1' loader/arm64/linux.c:159: starting image 0xfd24d530 "Synchronous Abort" handler, esr 0x96000210 elr: 8005b890 lr : 8005b880 (reloc) elr: ff631890 lr : ff631880 x0 : x1 : fd1e10d0 x2 : x3 : ff63184c x4 : x5 : 0001 x6 : ff63d0e8 x7 : x8 : 0100 x9 : 0001f028 x10: fd1e13bc x11: 0001f01c x12: fd1e14b8 x13: da35 x14: fd1e145c x15: 67616d692f746f6f x16: ff63184c x17: fbf31300 x18: fd1f3d50 x19: 5b01 x20: x21: fd1e10d0 x22: fd1fc7e0 x23: fd1fb260 x24: ff7f x25: dbca5000 x26: fd1e1640 x27: fd1fb280 x28: dbca x29: fd1e1000 Code: aa0003f6 1280 f94002d3 b9003260 (b9402660) UEFI image [0xfc0eb000:0xfc1c0fff] '/EFI\debian\grubarm.efi' UEFI image [0xda55:0xdc0b] Resetting CPU ... ### ERROR ### Please RESET the board ### -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Versions of packages grub-efi-arm64 depends on: ii debconf [debconf-2.0] 1.5.77 ii grub-common2.06-3~deb11u5 ii grub-efi-arm64-bin 2.06-3~deb11u5 ii grub2-common 2.06-3~deb11u5 ii ucf3.0043 grub-efi-arm64 recommends no packages. grub-efi-arm64 suggests no packages. -- debconf information excluded
Bug#1036171: debian-installer: /etc/apt/sources.list isn't populated if mirror can't be reached during installation
Package: debian-installer Version: 20230515 Severity: important X-Debbugs-Cc: and...@lists.savchenko.net # PROBLEM DESCRIPTION User is unable to perform `apt update` right after installation. # STEPS TO REPRODUCE 1. Start Bookworm installation and connect to a network where device is issued non-routed IP by the DHCP server. 2. Installer will get stuck trying to fetch up-to-date packages from the mirror. 3. Press "Cancel" and proceed with the installation as usual. Upon boot you will find that /etc/apt/sources.list contains only the following line: ``` deb cdrom:[Debian GNU/Linux bookworm-DI-rc2 _Bookworm_ - Official RC amd64 DVD Binary-1 with firmware 20230428-12:34]/ bookworm main non-free-firmware ``` # EXPECTED BEHAVIOUR source.list contains the default remote mirror: ``` deb https://deb.debian.org/debian bookworm main contrib non-free non-free-firmware ``` -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1035538: nautilus: Missing dependency on "eject" package
Package: nautilus Version: 43.2-1 Severity: important Dear Maintainer, If the eject package isn't installed, when you try to eject a USB device (I didn't test anything else), then Nautilus is unable to eject the device and throws up an error like: Error ejecting /dev/sda: Error spawning command-line `eject '/dev/sda'': Failed to execute chidl process "eject" (No such file or directory) (g-exec-error-quark, 8). I reckon that the natilus package should depend on the eject package. Cheers, Andrew -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_AUX Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nautilus depends on: ii bubblewrap 0.8.0-2 ii desktop-file-utils 0.26-1 ii gsettings-desktop-schemas 43.0-1 ii gvfs1.50.3-1 ii libadwaita-1-0 1.2.2-1 ii libc6 2.36-9 ii libcairo2 1.16.0-7 ii libcloudproviders0 0.3.1-2 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgexiv2-2 0.14.0-1+b1 ii libglib2.0-02.74.6-2 ii libglib2.0-data 2.74.6-2 ii libgnome-autoar-0-0 0.4.3-1 ii libgnome-desktop-4-243.2-2 ii libgstreamer-plugins-base1.0-0 1.22.0-3 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-4-1 4.8.3+ds-2 ii libnautilus-extension4 43.2-1 ii libpango-1.0-0 1.50.12+ds-1 ii libportal-gtk4-10.6-4 ii libportal1 0.6-4 ii libselinux1 3.4-1+b5 ii libtracker-sparql-3.0-0 3.4.2-1 ii nautilus-data 43.2-1 ii shared-mime-info2.2-1 ii tracker 3.4.2-1 ii tracker-extract 3.4.3-1 ii tracker-miner-fs3.4.3-1 Versions of packages nautilus recommends: ii gnome-sushi 43.0-2 ii gvfs-backends 1.50.3-1 pn libgdk-pixbuf2.0-bin ii librsvg2-common 2.54.5+dfsg-1 Versions of packages nautilus suggests: ii eog 43.2-1 ii evince [pdf-viewer] 43.1-2+b1 pn nautilus-extension-brasero ii nautilus-sendto 3.8.6-3.1 ii totem 43.0-2 ii vlc [mp3-decoder] 3.0.18-2 ii xdg-user-dirs 0.18-1 -- no debconf information
Bug#1035402: libtpm2-pkcs11-1: libtpm2_pkcs11.so.1 exposes too many symbols, fails to work with strongswan
Package: libtpm2-pkcs11-1 Version: 1.9.0-0.1 Severity: important Tags: patch X-Debbugs-Cc: andr...@twosigma.com The patch set-version-of-library.patch inadvertently suppresses the use of "-Wl,--version-script" later in Makefile.am, which leads to many internal symbols being exposed and/or resolved improperly at runtime. One of these is mutex_create(). Strongswan also has a symbol by that name, so when libstrongswan calls C_Initialize(), the resulting call (from inside libtpm2_pkcs11.so.1) resolves to the strongswan symbol. That function returns a pointer (not an unsigned long), the C_Initialize() call fails, and Strongswan cannot use the PKCS11 stack. The charon process logs a message like this when this happens: 2023-04-11T21:59:51.231215+00:00 spindle charon: 00[CFG] C_Initialize() error for 'tpm2-pkcs11': (-2052707168) The attached patch (against the offending patch) arranges for the version-script to be used properly, and also reduces the libtpm2-pkcs11-1.symbols file to the list of symbols that are now supposed to be exported. -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libtpm2-pkcs11-1 depends on: ii libc6 2.36-9 ii libsqlite3-0 3.40.1-2 ii libssl3 3.0.8-1 ii libtss2-esys-3.0.2-0 3.2.1-3 ii libtss2-mu0 3.2.1-3 ii libtss2-rc0 3.2.1-3 ii libtss2-tctildr0 3.2.1-3 ii libyaml-0-2 0.2.5-1 libtpm2-pkcs11-1 recommends no packages. libtpm2-pkcs11-1 suggests no packages. -- no debconf information diff --git a/debian/libtpm2-pkcs11-1.symbols b/debian/libtpm2-pkcs11-1.symbols index d51dfe31..e8b9113f 100644 --- a/debian/libtpm2-pkcs11-1.symbols +++ b/debian/libtpm2-pkcs11-1.symbols @@ -68,379 +68,3 @@ libtpm2_pkcs11.so.1 libtpm2-pkcs11-1 #MINVER# C_VerifyUpdate@Base 1.2.0 C_WaitForSlotEvent@Base 1.2.0 C_WrapKey@Base 1.2.0 - __real_db_tobject_new@Base 1.5.0 - __real_init_pobject@Base 1.5.0 - __real_init_sealobjects@Base 1.5.0 - __real_init_tobjects@Base 1.5.0 - __real_tobject_new@Base 1.5.0 - __real_twistbin_new@Base 1.5.0 - _db_update_tobject_attrs@Base 1.6.0 - _g_ecc_curve_nids_templ@Base 1.5.0 - _g_rsa_keysizes_templ@Base 1.5.0 - _session_ctx_opdata_get@Base 1.2.0 - _tobject_user_decrement@Base 1.6.0 - _tobject_user_increment@Base 1.6.0 - aes256_gcm_decrypt@Base 1.2.0 - aes256_gcm_encrypt@Base 1.2.0 - apply_pkcs7_pad@Base 1.6.0 - attr_CK_BBOOL@Base 1.2.0 - attr_CK_KEY_TYPE@Base 1.2.0 - attr_CK_OBJECT_CLASS@Base 1.2.0 - attr_CK_ULONG@Base 1.2.0 - attr_add_missing_attrs@Base 1.2.0 - attr_common_add_RSA_publickey@Base 1.2.0 - attr_common_add_data@Base 1.3.2 - attr_common_add_storage@Base 1.5.0 - attr_get_attribute_by_type@Base 1.2.0 - attr_get_attribute_by_type_raw@Base 1.2.0 - attr_get_name@Base 1.7.0 - attr_list_add_bool@Base 1.2.0 - attr_list_add_buf@Base 1.2.0 - attr_list_add_int@Base 1.2.0 - attr_list_add_int_seq@Base 1.9.0 - attr_list_append_attrs@Base 1.2.0 - attr_list_append_entry@Base 1.3.2 - attr_list_dup@Base 1.5.0 - attr_list_free@Base 1.2.0 - attr_list_get_CKA_CLASS@Base 1.3.2 - attr_list_get_CKA_KEY_TYPE@Base 1.6.0 - attr_list_get_CKA_PRIVATE@Base 1.3.2 - attr_list_get_CKA_TOKEN@Base 1.5.0 - attr_list_get_count@Base 1.2.0 - attr_list_get_ptr@Base 1.2.0 - attr_list_invoke_handlers@Base 1.2.0 - attr_list_new@Base 1.2.0 - attr_list_raw_invoke_handlers@Base 1.2.0 - attr_list_update_entry@Base 1.3.2 - attr_pfree_cleanse@Base 1.3.2 - attr_typify@Base 1.2.0 - backend_add_object@Base 1.5.0 - backend_create_token_seal@Base 1.5.0 - backend_ctx_free@Base 1.5.0 - backend_ctx_new@Base 1.5.0 - backend_ctx_reset@Base 1.5.0 - backend_destroy@Base 1.5.0 - backend_esysdb_add_object@Base 1.5.0 - backend_esysdb_create_token_seal@Base 1.5.0 - backend_esysdb_ctx_free@Base 1.5.0 - backend_esysdb_ctx_new@Base 1.5.0 - backend_esysdb_ctx_reset@Base 1.5.0 - backend_esysdb_destroy@Base 1.5.0 - backend_esysdb_get_tokens@Base 1.5.0 - backend_esysdb_init@Base 1.5.0 - backend_esysdb_init_user@Base 1.5.0 - backend_esysdb_rm_tobject@Base 1.5.0 - backend_esysdb_token_changeauth@Base 1.5.0 - backend_esysdb_token_unseal_wrapping_key@Base 1.5.0 - backend_esysdb_update_tobject_attrs@Base 1.5.0 - backend_esysdb_update_token_config@Base 1.5.0 - backend_fapi_add_object@Base 1.5.0 - backend_fapi_add_tokens@Base 1.5.0 - backend_fapi_create_token_seal@Base 1.5.0 - backend_fapi_ctx_free@Base 1.5.0 - backend_fapi_ctx_new@Base 1.5.0 - backend_fapi_destroy@Base 1.5.0 - backend_fapi_init@Base 1.5.0 - backend_fapi_init_user@Base 1.5.0 - backend_fapi_rm_tobject@Base 1.5.0 - backend_fapi_token_changeauth@Base 1.5.0 - backend_fapi_token_unseal_wrapping_key@Base 1.5.0 - backend_fapi_update_tobject_attrs@Base 1.5.0 - backend_get_tokens@Base 1.5.0 - backend_init@Base 1.5.0 -
Bug#1030749: Bug#1031587: [request-tracker-maintainers] Bug#1031587: Handling of the request-tracker4 -> request-tracker5 transition in bookworm
Hi folks, > Sorry for the long delay. Myself and, I think, Andrew have been short > on time. Yes, my apologies, I've been very busy the last couple of months. > The transition is basically ready to go, but I've been rethinking the > need > to drop request-tracker4, given it will all be quite tight. It turns > out that > request-tracker4 is still supported upstream > (https://bestpractical.com/release-policy) > and there's no specific EoL set. When we first started the plan to > deprecate request-tracker4 in Debian, I think we were assuming > otherwise. > The package is in good shape and I believe otherwise ready to be > released. > > If Andrew is in agreement, I therefore think we should let request- > tracker4 > be released with the next release. We can reconsider whether to drop > it from > the release + 1 at a more leisurely pace. The work we've done to date > will not > be wasted effort. Yes, I'm okay with keeping request-tracker4 in Bookworm, as Dominic says, the package is in good shape. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1034536: gnome-terminal: entire terminal window can go blank e.g., when accessing remote serial console over ipmi
Package: gnome-terminal Version: 3.46.8-1 Severity: normal Dear Maintainer, when using gnome-terminal i sometimes find that the entire window (including the title bar and the tabs as well as all the text area) has gone completely blank. it is still responsive to key strokes. this typically happens when i am using conserver to connect to a host's serial console over ipmi while rebooting the remote host. if my laptop's screen locks or if i switch to another workspace and then return, often i find gnome-termninal in this completely black state. i used rxvt-unicode for many years in this workflow without experiencing this issue. i apologize for the vague nature of this bug report and hope i am directing it at the proper component. thanks in advance. andy -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8:en.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.6-1 ii dbus-x11 [dbus-session-bus] 1.14.6-1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gnome-terminal-data 3.46.8-1 ii gsettings-desktop-schemas 43.0-1 ii libatk1.0-0 2.46.0-5 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-1 ii libgtk-3-03.24.37-2 ii libpango-1.0-01.50.12+ds-1 ii libstdc++612.2.0-14 ii libuuid1 2.38.1-5+b1 ii libvte-2.91-0 0.70.3-1 ii libx11-6 2:1.8.4-2 Versions of packages gnome-terminal recommends: ii gvfs 1.50.3-1 ii nautilus-extension-gnome-terminal 3.46.8-1 ii yelp 42.2-1 gnome-terminal suggests no packages. -- no debconf information
Bug#1034366: mutter: Alt+Tab broken for 'sloppy' focus mode on Wayland
Source: mutter Version: 43.3-5 Severity: normal Dear Maintainer, this issue was reported upstream and there are details in: Alt+Tab broken for 'sloppy' focus mode on Wayland (#888) https://gitlab.gnome.org/GNOME/mutter/-/issues/888 there is a fix that has been merged into GNOME 44: Fix Sloppy/mouse focus mode on Wayland (!2828) https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828 if it would be possible to cherry-pick this it would be appreciated. thanks in advance. andy -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8:en.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1034365: evolution: search folder continues to show messages marked as deleted
Package: evolution Version: 3.46.4-1 Severity: normal Dear Maintainer, i have a search folder that aggegrates a number of imapx INBOXes into a single location and have the accounts set to mark messages as deleted (i.e., they do not "Use a real folder for Trash"). the "Show Deleted Messages" option is not selected. when i mark a message as deleted from the search folder, it is updated in the list as a strike-through but is still shown in the list of messages. when i take an action such as opening another message in the mail browser the list finally updates and the message disappears from view. given my settings, i would expect a deleted message to be immediately removed from the list of messages in the search folder. this worked as expected at some point in the (now distant) past. there is an upstream bug that is perhaps related: Search folder doesn't reflect correct state of local mail folder (#1740) https://gitlab.gnome.org/GNOME/evolution/-/issues/1740 thanks in advance. andy -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8:en.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution depends on: ii dbus [default-dbus-system-bus] 1.14.6-1 ii evolution-common3.46.4-1 ii evolution-data-server 3.46.4-2 ii libc6 2.36-8 ii libcamel-1.2-64 3.46.4-2 ii libecal-2.0-2 3.46.4-2 ii libedataserver-1.2-27 3.46.4-2 ii libevolution3.46.4-1 ii libglib2.0-02.74.6-1 ii libgtk-3-0 3.24.37-2 ii libical33.0.16-1+b1 ii libnotify4 0.8.1-1 ii libwebkit2gtk-4.1-0 2.40.0-3 ii libxml2 2.9.14+dfsg-1.1+b3 ii psmisc 23.6-1 Versions of packages evolution recommends: ii evolution-plugin-bogofilter 3.46.4-1 ii evolution-plugin-pstimport 3.46.4-1 ii evolution-plugins3.46.4-1 ii yelp 42.2-1 Versions of packages evolution suggests: pn evolution-ews pn evolution-plugins-experimental ii gnupg 2.2.40-1.1 ii network-manager 1.42.4-1 -- no debconf information
Bug#1033304: request-tracker5: debianisation of version interferes with doc linking
Hey, Thank you for the bug report. I'm just testing a fix now. This doesn't affect the RT4 packages as RT4 doesn't have a web interface for configuring RT, and even when viewing the config, it doesn't link to the docs. Cheers, Andrew On Wed, 2023-03-22 at 11:51 +1100, AP wrote: > > RT5 (and possibly RT4) uses the version number to generate a URL for > its documentation. > This URL is in use when configuring the system via the web interface > (click on a config > name and it takes you to the help for it). > > As a result the help results in a 404 until you manually remove the > debian component of > the version. > > This error is the result of the debianize_version.diff patch which > changes the version > globally. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Bug#1033091: clipman: Outdated clipman version in Debian Sid
Package: clipman Version: 1.2.0+git20200218.39fd4fe-2+b5 Severity: normal X-Debbugs-Cc: cchlori...@gmail.com Dear Maintainer, Can you please update the clipman package? The latest upstream version is 1.6.1, which came out a while ago and has some improvements over the version in Sid. Thanks for maintaining the clipman package! -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clipman depends on: ii libc6 2.36-8 ii wl-clipboard 2.1.0-0.1+b1 clipman recommends no packages. clipman suggests no packages. -- no debconf information
Bug#1032865: golang-github-urfave-cli-v2: New upstream version available
Source: golang-github-urfave-cli-v2 Version: 2.3.0-2 Severity: wishlist X-Debbugs-Cc: apoll...@debian.org Dear Maintainer, There is a newer version of golang-github-urfave-cli-v2 available, could you please update the package? https://github.com/urfave/cli/releases/tag/v2.25.0 -- System Information: Debian Release: rodete Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.11-1rodete1-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1032839: gnome-control-centre: Printer dialogue in GNOME Settings on bookworm. No Unlock button on window
Package: gnome-control-centre Severity: important 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 *** Attempting to add a printer because installed system printer not found. Gnome Settings -> Printer dialogue sugggests that the feature needs to be unlocked. No unlock button on screen bar in focus. Padlock icon and message only. There is a root user with a password: the first user also has sudo privileges. -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1032556: neovim-qt: New upstream version available: 0.2.17 (2022-07-02)
Package: neovim-qt Version: 0.2.16-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainers, There is a new version of neovim-qt available upstream. Please could the Debian repos be updated with it when it’s convenient? https://github.com/equalsraf/neovim-qt/tags https://github.com/equalsraf/neovim-qt/releases/tag/v0.2.17 https://tracker.debian.org/pkg/neovim-qt Version 0.2.17 in particular fixes a number of emoji rendering bugs: please see https://github.com/equalsraf/neovim-qt/issues/482#issuecomment-751175003 for an example and a list. many thanks, Andrew Chadwick
Bug#1032492: xfce4-goodies: Please consider adding xfce4-docklike-plugin
Package: xfce4-goodies Version: 4.18.0 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainers, Would it be possible to package the new(-ish) “Docklike Taskbar” plugin for Xfce? A proper dock-ish launcher on the panel is something Xfce could really do with. - https://docs.xfce.org/panel-plugins/start - https://docs.xfce.org/panel-plugins/xfce4-docklike-plugin/start - https://gitlab.xfce.org/panel-plugins/xfce4-docklike-plugin This plugin was languishing for about a year, but it seems to be getting some code love again upstream from a new maintainer. regards, Andrew Chadwick
Bug#1032403: calendar: Outdated entry "Mar 05 Mother-in-Law Day, USA"
Package: calendar Version: 12.1.8 Severity: minor Dear Maintainer, i noticed that `calendar` reports: Mar 05 Mother-in-Law Day, USA cf. `/usr/share/calendar/calendar.usholiday`. it appears that while the first observance was celebrated on March 5, 1934[1] it is currently the fourth Sunday in October[2]. 1. https://web.archive.org/web/20230306051540/https://nationaldaycalendar.com/national-mother-in-law-day-fourth-sunday-in-october/ 2. https://www.google.com/search?q=Mother-in-Law+Day%2C+USA thank you. andy -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8:en.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages calendar depends on: ii cpp 4:12.2.0-3 ii libbsd0 0.11.7-2 ii libc62.36-8 calendar recommends no packages. calendar suggests no packages. -- no debconf information
Bug#1032083: python-editor: New upstream version 1.0.4, *BUT* name conflict with PyPi
Source: python-editor Version: 1.0.3-3 Severity: normal X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, There is a new upstream version of this package available, version 1.0.4, released in Feb 2019. Please can it be packaged for Debian? Git: https://github.com/fmoo/python-editor PyPi: none? Interface: editor.edit() Author: fmoo However, and perhaps more notably, there is an unrelated package called “editor” in PyPi that does the same thing, but which turns out to be significantly more modern and more regularly maintained. Git: https://github.com/rec/editor PyPi: https://pypi.org/project/editor/ Interface: editor.editor() Author: rec (Tom Ritchford) I suspect that *this* is what many Python application devs will be using when they need to launch an editor, because they’ll be looking in PyPi first. I’ve made that mistake myself, thinking it’s a newer version of the Debian packaged “editor”, then got worried by the apparently huge version bump and changed interface before twigging that the two projects are unrelated. I suppose handling the name clash is really a policy matter for Debian’s Python team. Does it even matter? Do, or should, Debian builds of python packages generally have the same name as their PyPi equivalents? It’s pretty confusing if they don’t match up. Perhaps the solution would be to rename “python-editor” to “python-editor-fmoo” or similar, with sensible migration headers, and package a new “python-editor” whose name matches PyPi. Or some virtual package or Alternatives mechanism, maybe. Anyway, thanks for your consideration, whichever way this goes :) regards, Andrew
Bug#1032049: knot-resolver: Unable to enable HTTP module
Package: knot-resolver
Version: 5.3.1-1+deb11u1
Severity: normal
X-Debbugs-Cc: and...@lists.savchenko.net
Dear Maintainer,
HTTP module in knot-resolver can't be enabled by adding `http` directive
in its config file.
I have tried the separate `modules.load('http')` statement via
config and control socket / `kresc`, but to no avail.
`kresd.conf` attached below. While `kresc` reports that the module is
loaded, no new port is opened and stats can't be fetched via `curl`.
`stats.list()` works as expected, this confirms that there is a valid
data to expose via http.
-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-20-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages knot-resolver depends on:
ii adduser3.118
ii debconf [debconf-2.0] 1.5.77
ii dns-root-data 2021011101
ii libc6 2.31-13+deb11u5
ii libdnssec8 3.0.5-1+deb11u1
ii libedit2 3.1-20191231-2+b1
ii libfstrm0 0.6.0-1+b1
ii libgcc-s1 10.2.1-6
ii libgnutls303.7.1-5+deb11u3
ii libknot11 3.0.5-1+deb11u1
ii liblmdb0 0.9.24-1
ii libluajit-5.1-22.1.0~beta3+dfsg-5.3
ii libnghttp2-14 1.43.0-1
ii libprotobuf-c1 1.3.3-1+b2
ii libstdc++6 10.2.1-6
ii libsystemd0247.3-7+deb11u1
ii libuv1 1.40.0-2
ii libzscanner3 3.0.5-1+deb11u1
ii lua-sec1.0-1
ii lua-socket 3.0~rc1+git+ac3201d-4
Versions of packages knot-resolver recommends:
ii knot-resolver-module-http 5.3.1-1+deb11u1
ii lua-basexx 0.3-2.1
ii lua-cqueues20200726-1
knot-resolver suggests no packages.
-- Configuration Files:
/etc/default/kresd [Errno 13] Permission denied: '/etc/default/kresd'
/etc/knot-resolver/kresd.conf changed:
-- Listen locally, ipv4-only
net = { '127.0.0.1' }
net.ipv6 = false
-- Enable optional modules
modules = {
'policy', -- NXDOMAIN "bad" queries
'hints', -- read /etc/hosts and whatever is defined below
'stats', -- internal statistics
'serve_stale < cache', -- serve stale record if parent NS is unreachable
'rebinding < iterate', -- prevent rebinding attack, TODO: Remove?..
'prefill',
'predict',
'view',
http = {
host = '127.0.0.1',
port = 8053
}
}
-- Accept exclusively from localhost
view:addr('127.0.0.1/8', function (req, qry) return policy.PASS end)
view:addr('0.0.0.0/0', function (req, qry) return policy.DROP end)
-- Block Firefox DoH
policy.add(policy.suffix(policy.DENY, {todname('use-application-dns.net')}))
-- Add blocked hosts, reload on file change
-- MUST be in a special .RPZ format
-- https://knot-resolver.readthedocs.io/en/stable/modules-policy.html#policy.rpz
policy.add(policy.rpz(policy.DENY, '/etc/knot-resolver/black.rpz'))
policy.add(policy.rpz(policy.DENY, '/etc/knot-resolver/blacklist-fgs.txt'))
-- DNS-over-TLS
policy.add(policy.all(policy.TLS_FORWARD({
{'9.9.9.9', hostname='dns.quad9.net'},
{'149.112.112.112', hostname='dns.quad9.net'},
{'1.1.1.1', hostname='1dot1dot1dot1.cloudflare-dns.com'},
{'1.0.0.1', hostname='one.one.one.one'}
})))
-- DNS-over-UDP
-- policy.add(policy.all(policy.FORWARD({'9.9.9.9', '1.1.1.1'})))
--- Root zone preload
prefill.config({
['.'] = {
url = 'https://www.internic.net/domain/root.zone',
ca_file = '/etc/ssl/certs/ca-certificates.crt',
interval = 86400 -- 24h
}
})
-- Cache config
cache.size = 32 * MB
cache.max_ttl(172800) -- 48h
cache.min_ttl(60) -- 1m
--- Prefetch learning (15-minute blocks over 24 hours)
predict.config({
window = 15, -- 15 minutes sampling window
period = 24*(60/15) -- track last 24 hours
})
-- debconf-show failed
Bug#992415: pinentry-tty: Segfault as host is entering S3/S0ix
Just an update, this can't be replicated in Bookworm. Please close the bug.
Bug#1031594: os-prober is disabled by default in /etc/default/grub - Windows not found
Package: os-prober Version: 1.79 Severity: normal Dear Maintainer, In testing for Debian Bookworm Alpha 2 release Windows not found when dist-upgrade from existing 11.6 system Disabled in /etc/default/grub * grub2: Add commented-out GRUB_DISABLE_OS_PROBER to /etc/default/grub to make it easier for users to turn os-prober back on if they want it (#1013797, #1009336) This needs to be discussed
Bug#1031587: [request-tracker-maintainers] Bug#1031587: Handling of the request-tracker4 -> request-tracker5 transition in bookworm
On Sun, 2023-02-19 at 00:12 +0200, Adrian Bunk wrote: > https://release.debian.org/testing/freeze_policy.html#soft > > ... > Dropping or adding binary packages to a source package, moving > binaries between source packages or renaming source or binary > packages is no longer allowed. Packages with these changes will not > be allowed to migrate to testing. These changes are also no longer > appropriate in unstable. > ... > > > The problem is that opening of #1030749 is de facto > a request-tracker4 -> request-tracker5 transition that > happened 4 weeks after the deadline for transitions. The soft freeze date snuck up on us. :( Given the minimal impact to packages, is this a transition? If you look at the release and EOL dates on https://bestpractical.com/release-policy/ you'll see that Best Practical typically end of life releases 3-4 years after the next release. 5.0 was released in 2020, therefore it is worth considering that 4.4 will most likely be EOL in 2023 or 2024. For practical support reasons, we're concerned about releasing Bookworm with 4.4. > There are two options for resolving this: > 1. Treat #1030749 as a forbidden transition and ship both versions > of request-tracker in bookworm, or > 2. grant reverse dependencies an exception from the soft freeze > rules for the request-tracker4 -> request-tracker5 transition. > > > For option 2 I looked at the 9 reverse dependencies of request- > tracker4 > in the autoremoval list: > > RT extension installer that has to stop depending on > both versions: > - libmodule-install-rtx-perl This will need to updated after all the below packages are updated. > No package remame required, has to upgrade to the upstream version > that supports request-tracker5: > - librt-extension-commandbymail-perl We've had updated packaging ready to go for a while, but it looks like we'd forgotten to upload it. Current proposed package does introduce new packages, but we could drop that and re-use the existing package name. > Ships packages for both versions and has to drop the > request-tracker4 package: > - rt-extension-assets-import-csv > > request-tracker4 -> request-tracker5 transition prepared > in experimental: > - rt-extension-customfieldsonupdate > - rt-extension-calendar > - rt-extension-jsgantt > - rt-extension-nagios > - rt-extension-smsnotify Some of these will need to be updated, but that is relatively straightforward. > Update to latest upstream version and package rename required: > - rt-extension-repeatticket Again, we have updated packaging ready, again includes new package names. But the splitting into new packages can be dropped. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
