Bug#1023585: In support for creation of the debian-loongarch list
Hi, While I'm not as closely involved in the Debian loong64 port as some others do (I primarily work upstream, and Gentoo when I'm packaging; after all I'm primarily a Gentoo dev), I personally agree that creation of a debian-loongarch mailing list will help communication in many ways. The Linux/LoongArch mailing list (loonga...@lists.linux.dev) currently has 44 subscribers, as can be checked on the lists.linux.dev site, and IMO it's only because talking there requires one to speak English; similar user and/or dev groups on WeChat easily reach hundreds of members. I expect a similar number of interested parties would subscribe here after the list is created. Which brings my next question: do we want to allow Chinese in this list (people can be asked to write bilingual mails and translate/clarify if necessary), or do we want to create a parallel debian-loongarch-zh list for that? Per the Debian mailing list CoC [1], the language to use is English unless explicitly allowed otherwise. But I fear that if people are forced to speak English, a majority of them would simply go away and create an equivalent WeChat group and just continue there. In order for the list to serve as the new go-to venue for coordination and communication around the port, and not get ignored, I think allowing at least bilingual mails (when the author is not confident enough that their English expression wouldn't create confusion / misunderstanding) is necessary. As a matter of fact, even most contributors to this port do the above; FWIW, they mostly only appear on official Debian services (bugs, wiki, irc) because other DDs have to be involved, and all other coordination happen in a WeChat group (that I also got invited into, so I know). IMO creation of such an open list *should* mean substantially decreasing private discussions like this, and we probably want to facilitate that, so people don't have to first go learn technical English for a half year before starting to participate and contribute, and valuable discussions don't get permanently buried in someone's private chat history. [1]: https://www.debian.org/MailingLists/#codeofconduct
Bug#967684: Upstream needs help
Upstream started porting to GTK3 some years ago and hit a wall regarding bitmap conversion. https://github.com/gEDA-pcb-developers/pcb/tree/LP1952989 -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7 GPG Fingerprints: 6E2E E4BB 72E2 F417 D066 6ABF 7B30 B496 A7EF 5761 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: PGP signature
Bug#1036205: unblock: kanboard/1.2.26+ds-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: kanbo...@packages.debian.org, j...@nahmias.net
Control: affects -1 + src:kanboard
Please unblock package kanboard
[ Reason ]
- Fix RC bug #1035598, caused by improper quoting in the test for
lighty-enable-mod
- Fix a few issues discovered with the debian patch to use the newer version
of symfony that is in bookworm, which break common use cases /
configurations (including the package default one).
- Fix an oversight in the default lighttpd configuration provided with
kanboard which doesn't exempt the jsonrpc API endpoint from redirection to
the login page.
- Add autopkgtests to cover the above issues.
[ Impact ]
RC bug will cause kanboard to be removed from bookworm.
[ Tests ]
I've added a basic autopkgtest to test the jsonrpc API endpoint using
the default (lighttpd) config.
Added an autopkgtest to specifically test the installation of kanboard
with apache.
Did NOT add a similar jsonrpc autopkgtest for running under apache, as
this would require shipping a default config for apache, which feels like
too much of a new feature and thus unsuitable for an unblock at this point
of the release cycle. However, if the RT would be willing to include this
I'd be happy to do so; otherwise, I plan to defer until trixie opens.
[ Risks ]
Kanboard is a leaf package.
Fixes are targetted and address important/RC issues.
Autopkgtests are included to cover the issues and insure against regressions.
[ 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 testing
[ Other info ]
unblock kanboard/1.2.26+ds-2
This is my first unblock request in quite some time. Any feedback you wish to
provide would be greatly appreciated!
Thanks for all you do to make Debian,
--Joe
diff -Nru kanboard-1.2.26+ds/debian/35-kanboard.conf
kanboard-1.2.26+ds/debian/35-kanboard.conf
--- kanboard-1.2.26+ds/debian/35-kanboard.conf 2022-07-22 12:48:59.0
-0400
+++ kanboard-1.2.26+ds/debian/35-kanboard.conf 2023-05-15 21:45:51.0
-0400
@@ -7,6 +7,7 @@
alias.url += ( "/kanboard/" => "/usr/share/kanboard/" )
index-file.names += ( "index.php" )
url.rewrite-once = (
+"^/kanboard/jsonrpc\.php" => "",
"^/kanboard/assets/.+" => "",
"^/kanboard/favicon\..*$" => "",
"" => "/kanboard/index.php${qsa}",
diff -Nru kanboard-1.2.26+ds/debian/changelog
kanboard-1.2.26+ds/debian/changelog
--- kanboard-1.2.26+ds/debian/changelog 2023-01-14 19:54:15.0 -0500
+++ kanboard-1.2.26+ds/debian/changelog 2023-05-16 22:49:38.0 -0400
@@ -1,3 +1,23 @@
+kanboard (1.2.26+ds-2) unstable; urgency=medium
+
+ * properly test for lighty-enable-mod.
+This fixes a bug in how the postinst/prerm maint scripts check whether
+to enable kanboard for lighttpd, which caused it to fail when lighttpd
+was not installed. (Closes: #1035598)
+ * adapt some more areas to the new Symfony EventDispatcher API
+fix a couple of spots where we missed updating to the new dispatch() API:
+- standard db-based Auth
+- jsonrpc Auth
+ * do not redirect access to Kanboard's JSONRPC API.
+It uses its own authentication and shouldn't be bounced to the standard
+login page.
+ * add autopkgtest to ensure Kanboard JSONRPC API (minimally) works
+ * add apache install autopkgtest
+ * test(jsonrpc): make curl report errors in a cleaner way
+ * test(jsonrpc): add php-fpm as test dep
+
+ -- Joseph Nahmias Tue, 16 May 2023 22:49:38 -0400
+
kanboard (1.2.26+ds-1) unstable; urgency=medium
* [1f43019] New upstream version 1.2.26+ds
diff -Nru kanboard-1.2.26+ds/debian/patches/adapt_to_newer_symfony.patch
kanboard-1.2.26+ds/debian/patches/adapt_to_newer_symfony.patch
--- kanboard-1.2.26+ds/debian/patches/adapt_to_newer_symfony.patch
2022-07-24 09:00:23.0 -0400
+++ kanboard-1.2.26+ds/debian/patches/adapt_to_newer_symfony.patch
2023-05-15 21:45:51.0 -0400
@@ -623,3 +623,41 @@
return false;
}
+--- a/app/Api/Middleware/AuthenticationMiddleware.php
b/app/Api/Middleware/AuthenticationMiddleware.php
+@@ -7,6 +7,7 @@ use JsonRPC\Exception\AuthenticationFail
+ use JsonRPC\MiddlewareInterface;
+ use Kanboard\Auth\ApiAccessTokenAuth;
+ use Kanboard\Core\Base;
++use Symfony\Contracts\EventDispatcher\Event;
+
+ /**
+ * Class AuthenticationApiMiddleware
+@@ -28,7 +29,7 @@ class AuthenticationMiddleware extends B
+ */
+ public function execute($username, $password, $procedureName)
+ {
+-$this->dispatcher->dispatch('app.bootstrap');
++$this->dispatcher->dispatch(new Event, 'app.bootstrap');
+ session_set('scope', 'API');
+
+ if ($this->isUserAuthenticated($username, $password)) {
+--- a/app/Middleware/BootstrapMiddleware.php
Bug#1023585: Request a mailing list for new architecture "loongarch64" (LoongArch 64 bits little-endian)
Thanks for reading. I hope that loongarch64 can recive more support from Debian community and seting up a special mail list is a good idea. Jeremiah from Beijing
Bug#1036204: unblock: uhd/4.3.0.0+ds1-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: u...@packages.debian.org
Control: affects -1 + src:uhd
Please unblock package uhd
[ Reason ]
Version 4.3.0.0+ds1-5 fixes the RC bug #1036072
libuhd4.3.0: please add Breaks against libuhd3.15.0 for smoother
upgrades from bullseye
[ Impact ]
Allows smooth upgrade from bullseye to bookworm.
[ Tests ]
Not quite reproducing the conditions of bug #1036072,
but installed on my own testing system.
[ Risks ]
very low: only control files change with the targeted fix.
[ 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 testing
[ Other info ]
n/a
unblock uhd/4.3.0.0+ds1-5
diff -Nru uhd-4.3.0.0+ds1/debian/changelog uhd-4.3.0.0+ds1/debian/changelog
--- uhd-4.3.0.0+ds1/debian/changelog 2022-12-15 22:21:07.0 -0500
+++ uhd-4.3.0.0+ds1/debian/changelog 2023-05-16 20:46:55.0 -0400
@@ -1,3 +1,14 @@
+uhd (4.3.0.0+ds1-5) unstable; urgency=medium
+
+ [ Andreas Beckmann ]
+ * libuhd4.3.0: Add Breaks: libuhd3.15.0 for smoother upgrades from bullseye.
+(Closes: #1036072)
+
+ [ A. Maitland Bottoms ]
+ Apply above for bookworm
+
+ -- A. Maitland Bottoms Tue, 16 May 2023 20:46:55 -0400
+
uhd (4.3.0.0+ds1-4) unstable; urgency=medium
[ Luca Boccassi ]
diff -Nru uhd-4.3.0.0+ds1/debian/control uhd-4.3.0.0+ds1/debian/control
--- uhd-4.3.0.0+ds1/debian/control 2022-09-12 22:47:53.0 -0400
+++ uhd-4.3.0.0+ds1/debian/control 2023-05-16 20:39:46.0 -0400
@@ -63,6 +63,7 @@
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, ${shlibs:Depends}
Suggests: uhd-host
+Breaks: libuhd3.15.0 (<< 4)
Multi-Arch: same
Description: universal hardware driver for Ettus Research products - library
Host library for the Universal Hardware Driver for Ettus Research products.
Bug#1035911: [pre-approval] unblock: dpkg/1.21.22
Control: tags -1 moreinfo Hi! On Tue, 2023-05-16 at 23:44:29 +0200, Sebastian Ramacher wrote: > Control: tags -1 moreinfo confirmed > > On 2023-05-11 04:45:47 +0200, Guillem Jover wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > X-Debbugs-Cc: d...@packages.debian.org > > Control: affects -1 + src:dpkg > > Please pre-approve the dpkg 1.21.22 upload. > > Please go ahead and remove the moreinfo tag once the upload is available > in unstable. Thanks! It's been uploaded and built on all release architectures, if it's not yet in unstable it should be in the next dinstall run. Thanks, Guillem
Bug#1023585: I'm really looking forward to running debain on the Loongson architecture
Dear Maintainer,I'm a developer of loongarch. I am very supportive of Longson's construction in the community and hope to support more basic components. Hope the Longson is getting stronger and stronger. BR GuoCe
Bug#1036203: cue2toc: please consider upgrading to 3.0 source format
Source: cue2toc Version: 0.4-5 Severity: wishlist Please switch to the 3.0 (quilt) source format.
Bug#1036202: dpkg-sig: please consider upgrading to 3.0 source format
Source: dpkg-sig Version: 0.13.1+nmu4 Severity: wishlist Please switch to the 3.0 (native) source format.
Bug#1036201: RM: ipkungfu -- RoQA; RC-buggy; orphaned; low popcon; dead upstream
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove ipkungfu. It has long-standing, trivial RC bugs and is orphaned. Upstream seems to be dead. The package has no reverse dependencies.
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Tue, 16 May 2023 at 09:27, Simon McVittie wrote: > > On Tue, 16 May 2023 at 02:50:48 +0100, Luca Boccassi wrote: > > This sounds like a very interesting use case, and the first real one > > mentioned, which is great to see - but I do not fully follow yet, from > > what you are saying it seems to me that what you need is for your > > binaries to use the usual pt_interp, that bit is clear. But why does > > it matter if /usr/bin/ls on the host uses a different one? > > We don't need to run the ls from the host, but we do need to run > glibc-related executables like ldconfig and localedef from either the > host or the container runtime, whichever is newer. Because glibc is > a single source package, executables and libraries within the glibc > bubble sometimes make use of private symbols in libraries that are also > within the glibc bubble (and IMO they have a right to do so), even though > executables from outside glibc would be discouraged or disallowed from > doing so. This means that when we have chosen a particular version of > glibc (which, again, must be whichever one is newer), we try to use its > matching version for *everything* originating in the glibc source package. > > In principle we could get exactly the same situation if we've imported a > library from the host system (as a dependency of the graphics stack) that > calls an executable as a subprocess and expects it to be >= the version > it was compiled for - hopefully not (/usr)/bin/ls, but potentially others. Thanks for the clarification, so if I understood correctly, your use case is that sometimes (eg: when they are newer) you pull binaries (eg: ldconfig) from the host, and run them from the container? So, in case let's say ldconfig on the host points to /usr/lib/ld, but because your container is not usr-merged, it wouldn't find the interpreter and fail? > The wider point than my specific use-case, though, is that when there's a > standard, you can't predict what other software authors have looked at the > statement "you can rely on this" and ... relied on it. See also Russ's > (as ever, excellent) mails to the same thread. > > I appreciate that you are trying to explore the edges of the > problem/constraint space and say "what if we did this, could that work?", > and it's good that you are doing that; but part of that process is > working with the other people on this list when they say "no, we can't > do that because...", and respecting their input. I respect and appreciate the input, but I want to understand it too, hence the "because..." part is what I was looking for - so thanks for providing it, it is really useful. Kind regards, Luca Boccassi
Bug#1036199: RM: labrea -- RoQA; RC-buggy; low popcon; dead upstream
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove labrea. Trivial RC bugs have not been fixed for quite some time. Upstream seems to be inactive since 2003. The package has no reverse dependencies.
Bug#1036198: RM: libsnmp-multi-perl -- RoQA; RC-buggy; low popcon; missed bullseye/bookworm
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove libsnmp-multi-perl. Trivial RC bugs have not been fixed for quite some time so the package has not made it into bullseye and has not migrated to testing since. The package has no reverse dependencies and upstream is inactive.
Bug#1036197: ibus-pinyin setup broken with Python >= 3.10 due to gettext.bind_textdomain_codeset
Package: ibus-pinyin
Version: 1.5.0-8
Severity: important
Dear Maintainer,
How to reproduce?
- ensure you are running a flavour of Debian that features Python >= 3.10
- install ibus and ibus-pinyin
- run ibus-setup in a terminal
- select the "Input Method" tab
- click "Add" > Chinese > Pinyin > Add
- select "Chinese - Pinyin"
- click Preferences
Outcome:
1. no dialog appear on screen
2. the following Python stacktrace appears in the terminal:
Traceback (most recent call last):
File "/usr/share/ibus-pinyin/setup/main.py", line 428, in
main()
File "/usr/share/ibus-pinyin/setup/main.py", line 424, in main
PreferencesDialog(name).run()
^^^
File "/usr/share/ibus-pinyin/setup/main.py", line 44, in __init__
gettext.bind_textdomain_codeset("ibus-pinyin", "UTF-8")
^^^
AttributeError: module 'gettext' has no attribute 'bind_textdomain_codeset'
The python documentation[1] reports that
gettext.bind_textdomain_codeset(domain, codeset=None) is "Deprecated since
version 3.8, removed in version 3.10", hence the stacktrace.
Let me know if you need further information.
[1] https://docs.python.org/3.10/library/gettext.html
-- System Information:
Debian Release: 12.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-8-amd64 (SMP w/4 CPU threads; PREEMPT)
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 ibus-pinyin depends on:
ii gir1.2-gtk-3.0 3.24.37-2
ii gir1.2-ibus-1.0 1.5.27-5
ii libc62.36-9
ii libgcc-s112.2.0-14
ii libglib2.0-0 2.74.6-2
ii libibus-1.0-51.5.27-5
ii liblua5.4-0 5.4.4-3
ii libpyzy-1.0-0v5 1.0.1-8
ii libsqlite3-0 3.40.1-2
ii libstdc++6 12.2.0-14
ii python3 3.11.2-1+b1
ii python3-gi 3.42.2-3+b1
ii python3-xdg 0.28-2
ibus-pinyin recommends no packages.
ibus-pinyin suggests no packages.
-- no debconf information
Bug#1036196: RM: randomsound -- RoQA; RC-buggy; orphaned; low popcon; dead upstream
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove randomsound. It has long-standing, trivial RC bugs and is orphaned. Upstream seems to be dead. The package has no reverse dependencies.
Bug#1035844: matrix-sydent fails to purge without adduser
On Tue, 16 May 2023 23:31:16 +0200, Johannes Schauer Marin Rodrigues said: > since time is running short, I am going to NMU matrix-sydent on > Thursday with a delay of 2 days unless you disagree and/or want to do > this yourself. Hi josch, Thanks for the report and the offer to fix it. I'm not objecting to your NMU, but I wanted to point out that matrix-sydent isn't in testing (and AFAICT never has been), so it isn't holding up the release. So I don't think there's any particular rush to fix this issue. There's also another RC bug (https://bugs.debian.org/1029442) that would block it from migrating. -- Hubert Chathi -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Bug#965503: dvi2ps-fontdata: Removal of obsolete debhelper compat 5 and 6 in bookworm
I am uploading a NMU to fix this.diff -Nru dvi2ps-fontdata-1.0.1/debian/changelog
dvi2ps-fontdata-1.0.1/debian/changelog
--- dvi2ps-fontdata-1.0.1/debian/changelog 2023-05-17 01:15:46.0
+0200
+++ dvi2ps-fontdata-1.0.1/debian/changelog 2023-05-17 01:09:25.0
+0200
@@ -1,3 +1,11 @@
+dvi2ps-fontdata (1.0.1-3.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update debhelper to compat 7. (Closes: #965503)
+ * Convert to source format 3.0 (quilt).
+
+ -- Bastian Germann Wed, 17 May 2023 01:09:25 +0200
+
dvi2ps-fontdata (1.0.1-3.1) unstable; urgency=medium
* Non maintainer upload by the Reproducible Builds team.
diff -Nru dvi2ps-fontdata-1.0.1/debian/compat
dvi2ps-fontdata-1.0.1/debian/compat
--- dvi2ps-fontdata-1.0.1/debian/compat 2023-05-17 01:15:46.0 +0200
+++ dvi2ps-fontdata-1.0.1/debian/compat 2023-05-17 01:08:01.0 +0200
@@ -1 +1 @@
-5
+7
diff -Nru dvi2ps-fontdata-1.0.1/debian/control
dvi2ps-fontdata-1.0.1/debian/control
--- dvi2ps-fontdata-1.0.1/debian/control2023-05-17 01:15:46.0
+0200
+++ dvi2ps-fontdata-1.0.1/debian/control2023-05-17 01:08:23.0
+0200
@@ -2,7 +2,7 @@
Section: tex
Priority: optional
Maintainer: OHURA Makoto
-Build-Depends: debhelper (>> 5.0.0)
+Build-Depends: debhelper (>= 7)
Build-Depends-Indep: sharutils
Standards-Version: 3.8.4
diff -Nru dvi2ps-fontdata-1.0.1/debian/patches/debian.patch
dvi2ps-fontdata-1.0.1/debian/patches/debian.patch
--- dvi2ps-fontdata-1.0.1/debian/patches/debian.patch 1970-01-01
01:00:00.0 +0100
+++ dvi2ps-fontdata-1.0.1/debian/patches/debian.patch 2023-05-17
01:09:25.0 +0200
@@ -0,0 +1,423 @@
+--- /dev/null
dvi2ps-fontdata-1.0.1/dvi2ps/fontsk/asc-three
+@@ -0,0 +1,6 @@
++# built-in morisawa fonts for pTeX / ASCII Nihongo TeX
++# First, convert pTeX dvi -> built-in kanji dvi by virtual font
++font jvf * 0 $tmf/vf/ptex/a2$bk/%f.vf
++#font jvf * 0 %f.vf
++# then, use built-in kanji
++fontdesc bikan-$ext
+--- /dev/null
dvi2ps-fontdata-1.0.1/dvi2ps/fontsk/bikan-three
+@@ -0,0 +1,9 @@
++# built-in morisawa fonts (dvi2ps-fontdata-three)
++font jfm * 0 $tmf/tfm/jp/
++font jfm * 0 $tmf/tfm/dvips/
++# dvi2ps-fontdata-three
++map fmb JSNRFutoMinA101-Bold-H
++map fgb JSNRFutoGoB101-Bold-H
++map jl JSNRJun101-Light-H
++map rml-jis JSNRRyumin-Light-H
++map gbm-jis JSNRGothicBBB-Medium-H
+--- /dev/null
dvi2ps-fontdata-1.0.1/dvi2ps/styles/three.dtx
+@@ -0,0 +1,237 @@
++% \CheckSum{140}
++% \iffalse
++%
++% モリサワ基本5書体を使うためのパッケージ
++%
++% 奥村晴彦
++%
++% [2002-12-19] いろいろなものに収録していただく際にライセンスを明確にする
++% 必要が生じてきました。アスキーのものが最近はmodified BSDライセンスになっ
++% ていますので，私のものもそれに準じてmodified BSDとすることにします。
++%
++% modified for dvi2ps-fontdata-three of Debian by Atsuhito KOHDA
++%
++%
++%\NeedsTeXFormat{pLaTeX2e}
++%\ProvidesPackage{three}[2003/2/24 kohda]
++%<*driver>
++\documentclass{jsarticle}
++\usepackage{doc}
++\usepackage{three}
++\addtolength{\textwidth}{-1in}
++\addtolength{\evensidemargin}{1in}
++\addtolength{\oddsidemargin}{1in}
++\addtolength{\marginparwidth}{1in}
++\setlength\marginparsep{5pt}
++\setlength\marginparpush{0pt}
++% \OnlyDescription
++\DisableCrossrefs
++\setcounter{StandardModuleDepth}{1}
++\GetFileInfo{three.sty}
++\begin{document}
++ \DocInput{three.dtx}
++\end{document}
++%
++%
++% \fi
++%
++% \title{モリサワ追加3書体パッケージ}
++% \author{香田 温人}
++% \date{\filedate}
++% \maketitle
++%
++% \MakeShortVerb{\|}
++%
++% \section{はじめに}
++%
++% これはモリサワ追加3書体を使うためのパッケージです。
++% 奥村晴彦氏の morisawa.dtx のフォント名を，桜井氏の VF 用に変更した
++% だけのものです。
++%
++% |\textgt{\bfseries 太ゴ}| と書くと\textgt{\bfseries 太ゴ}になります。
++%
++% |\textmg{じゅん}| または |{\mgfamily じゅん}| と書くと\textmg{じゅん}になります。
++%
++% 本文を太ミンにするには |\renewcommand{\mcdefault}{fmb}| とします。
++%
++% \StopEventually{}
++%
++% \section{オプションの定義}
++%
++%\begin{macrocode}
++%<*three>
++\newif\if@fake \@fakefalse
++\DeclareOption{fake}{\@faketrue}
++\ProcessOptions\relax
++%\end{macrocode}
++%
++% \section{各フォントの定義}
++%
++% \texttt{fd} ファイルを使用するのはやめました。
++%
++% 明朝体です。ボールドを太ミンにするには
++%\begin{verbatim}
++% \DeclareFontShape{JY1}{rml}{bx}{n}{<-> s * [0.961] FutoMinA101-Bold-J}{}
++%\end{verbatim}
++% とすればいいのですが，ここでは互換性のため明朝のボールドを中ゴシックにします。
++%
++%\begin{macrocode}
++\DeclareKanjiFamily{JY1}{rml}{}
++\DeclareKanjiFamily{JT1}{rml}{}
++\if@fake
++ \DeclareFontShape{JY1}{rml}{m}{n}{<-> s * [0.961] min10}{}
++ \DeclareFontShape{JY1}{rml}{bx}{n}{<-> s * [0.961] goth10}{}
++ \DeclareFontShape{JT1}{rml}{m}{n}{<-> s * [0.961] tmin10}{}
++ \DeclareFontShape{JT1}{rml}{bx}{n}{<-> s * [0.961] tgoth10}{}
++\else
++ \DeclareFontShape{JY1}{rml}{m}{n}{<-> s * [0.961] jis}{}
++ \DeclareFontShape{JY1}{rml}{bx}{n}{<-> s * [0.961] jisg}{}
++ \DeclareFontShape{JT1}{rml}{m}{n}{<-> s * [0.961] tmin10}{}
++ \DeclareFontShape{JT1}{rml}{bx}{n}{<-> s * [0.961] tgoth10}{}
++\fi
++%\end{macrocode}
++%
++% 太明朝体です。
++%
++%
Bug#1036195: RM: ez-ipupdate -- RoQA; RC-buggy; low popcon; dead upstream
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove ez-ipupdate. Trivial RC bugs have not been fixed for quite some time. Upstream seems to be dead. The package has no reverse dependencies.
Bug#1036194: coreutils: pr: writes errors as encountered even if writing to teletype
Package: coreutils Version: 8.32-4+b1 Version: 9.1-1 Severity: normal Dear Maintainer, POSIX Issue 8 Draft 3 (and all previous) says: 110716 DESCRIPTION 110722 If standard output is associated with a terminal, diagnostic messages shall be deferred until the 110723 pr utility has completed processing. 110829 ASYNCHRONOUS EVENTS 110830 If pr receives an interrupt while writing to a terminal, it shall flush all accumulated error 110831 messages to the screen before terminating. The UNIX® SYSTEM V RELEASE 4 User's Reference Manual says: Diagnostic reports (failed options) are reported at the end of standard output associated with a terminal, rather than interspersed in the output. Why, then $ pr -F <(echo a) /ENOENT <(echo a) 2023-05-17 00:35/dev/fd/63Page 1 a pr: /ENOENT: No such file or directory 2023-05-17 00:35/dev/fd/62Page 1 a Best, -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: amd64, i386 Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages coreutils depends on: ii libacl1 2.3.1-3 ii libattr1 1:2.5.1-4 ii libc62.36-9 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libselinux1 3.4-1+b5 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1036193: O: libapache-mod-auth-kerb -- publishing tool for DocBook, Linuxdoc and Asciidoc
Package: wnpp I hereby orphan libapache-mod-auth-kerb as it is obviously not maintained anymore. Please only consider adopting it if you can afford the time and have the skills to maintain it. You can have a look at #976156 for an introduction to what is to do.
Bug#1036159: [request-tracker-maintainers] Bug#1036159: request-tracker5: fails to build at build-final-ckeditor.sh stage
Thanks It is a known issue https://alioth-lists.debian.net/pipermail/pkg-request-tracker-maintainers/2023-April/005086.html This is bug 1031452, in rhino package, supposedly fixed... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031452
Bug#1036192: RM: initz -- RoQA; RC-buggy; orphaned; low popcon; dead upstream
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove initz. The old, trivial RC bug #965594 has not been fixed. Upstream seems to be dead. The package has no reverse dependencies.
Bug#1034261: autofs attempts communication with portmapper (port 111) even for NFS4 mounts
Many thanks for the fast response. I just realized that I gave an incorrect link to the corresponding bug report at Ubuntu. It should have been this one: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1970264 Best, ~Michael
Bug#1036016: unblock: amavisd-new/1:2.13.0-3
Control: tags -1 - moreinfo Quoting Sebastian Ramacher (2023-05-16 23:24:42) > Okay, then please go ahead and remove the moreinfo tag once the package is > available in unstable. version 1:2.13.0-3 has been uploaded to unstable four days ago and implements exactly (and only) this change: https://tracker.debian.org/news/1431032/accepted-amavisd-new-12130-3-source-into-unstable/ Thanks! cheers, josch signature.asc Description: signature
Bug#1035911: [pre-approval] unblock: dpkg/1.21.22
Control: tags -1 moreinfo confirmed On 2023-05-11 04:45:47 +0200, Guillem Jover wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: d...@packages.debian.org > Control: affects -1 + src:dpkg > > Hi! > > Please pre-approve the dpkg 1.21.22 upload. Please go ahead and remove the moreinfo tag once the upload is available in unstable. Cheers -- Sebastian Ramacher
Bug#1034755: x2gothinclient-common: about .postinst and .postrm scripts
Hi, On Sun, 14 May 2023 18:29:56 +0200 Patrice Duroux wrote: > Here is a patch for the .postrm script useing deluser/delgroup on purge. that patch looks good. Thanks! Since time is running short, I am going to NMU x2gothinclient on Thursday with a delay of 2 days unless you disagree and/or want to do this yourself. Thanks! cheers, josch signature.asc Description: signature
Bug#1035435: webdis: fails to purge - command (deluser|adduser) in postrm not found
On Wed, 03 May 2023 14:45:01 +0200 Andreas Beckmann wrote: > There is ongoing discussion how to handle system users on package > removal, see https://bugs.debian.org/621833 > Consensus seems to be not to remove system users (to avoid reusing UIDs > which could grant access to the wrong files) but to "lock" them (where > "locking"/"unlocking" is not yet precisely defined). Until that has > been decided it should be sufficient to have the postrm script ignore > any errors from deluser: > deluser ... || true since time is running short, I am going to NMU webdis on Thursday with a delay of 2 days unless you disagree and/or want to do this yourself. Thanks! cheers, josch signature.asc Description: signature
Bug#1035845: tcpcryptd fails to purge without adduser
Hi, Quoting jo...@debian.org (2023-05-10 07:56:44) > To work around this problem, at least 125 source packages [codesearch] simply > ignore failures of calling the passwd or adduser tools during purge. The > following patch should fix this package by doing the same: > > --%<- > diff -Nru tcpcrypt-0.5/debian/tcpcryptd.postrm > tcpcrypt-0.5/debian/tcpcryptd.postrm > --- tcpcrypt-0.5/debian/tcpcryptd.postrm2016-04-01 23:45:55.0 > +0200 > +++ tcpcrypt-0.5/debian/tcpcryptd.postrm2023-05-10 07:54:45.0 > +0200 > @@ -6,7 +6,7 @@ > purge) > # add a debian-tcpcryptd user if one does not already exist > if getent passwd "$TCPCRYPT_USER" >/dev/null ; then > -deluser "$TCPCRYPT_USER" > +deluser "$TCPCRYPT_USER" || true > fi > ;; > esac > -->%- > > If you prefer I can fix this via an NMU. since time is running short, I am going to NMU tcpcryptd on Thursday with a delay of 2 days unless you disagree and/or want to do this yourself. Thanks! cheers, josch signature.asc Description: signature
Bug#1034261: autofs attempts communication with portmapper (port 111) even for NFS4 mounts
Control: severity -1 serious On Di 16 Mai 2023 19:20:23 CEST, Michael Kiermaier wrote: I consider this bug quite severe as it may break working setups after an update. The corresponding bug report for Ubuntu might be this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034261 It is the same bug reported on the autofs mailing list here: https://www.spinics.net/lists/autofs/msg02389.html Apparently, it has been introduced in the transition of autofs from 5.1.7 to 5.1.8. A fix has been posted here: https://www.spinics.net/lists/autofs/msg02391.html and again https://www.spinics.net/lists/autofs/msg02434.html I share your view on this, thus bumping severity. The security team asked me to get the proposed patch into bookworm before the release. This patch will need to be applied to Debian's version of autofs: https://mirrors.edge.kernel.org/pub/linux/daemons/autofs/v5/patches-5.1.9/autofs-5.1.8-fix-nfsv4-only-mounts-should-not-use-rpcbind.patch https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/commit/?id=80845bbcbc264f19c6c6a81d680e1f2b1ea6d3cc I will work on this tomorrow. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgphirbvPsqDb.pgp Description: Digitale PGP-Signatur
Bug#1035844: matrix-sydent fails to purge without adduser
Hi,
Quoting jo...@debian.org (2023-05-10 07:49:26)
> To work around this problem, at least 125 source packages [codesearch] simply
> ignore failures of calling the passwd or adduser tools during purge. The
> following patch should fix this package by doing the same:
>
> --%<-
> diff -Nru matrix-sydent-2.5.1/debian/postrm matrix-sydent-2.5.1/debian/postrm
> --- matrix-sydent-2.5.1/debian/postrm 2021-06-01 21:17:05.0 +0200
> +++ matrix-sydent-2.5.1/debian/postrm 2023-05-10 07:46:13.0 +0200
> @@ -25,7 +25,7 @@
> dpkg-statoverride --force-all --quiet --remove "${DIR}"
> done
>
> - getent passwd "${USER}" >/dev/null && deluser "${USER}"
> + getent passwd "${USER}" >/dev/null && deluser "${USER}" || true
>
> rm -f /var/lib/${NAME}/*
> if [ -d /var/lib/${NAME} ]; then
> -->%-
>
> If you prefer I can fix this via an NMU.
since time is running short, I am going to NMU matrix-sydent on Thursday with a
delay of 2 days unless you disagree and/or want to do this yourself.
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#1036191: RM: finance-yahooquote -- RoQA; RC-buggy; low popcon; dead upstream
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove finance-yahooquote. The long-standing RC bug #882305 has not been fixed (neither upstream nor in the package). Upstream seems to be dead. The package has no reverse dependencies.
Bug#1036190: kmail: Crash on startup when GHNS is disabled in kde5rc
Package: kmail Version: 4:22.12.3-1 Severity: important Dear Maintainer, In Debian 11 it was possible to remove the "Get Hot New Stuff" (GHNS) button from all KDE applications seamlessly via Kiosk configuration. [0] The version of kmail in Testing makes a fragile assumption about the availability of GHNS functions and crashes deterministically when started with this option. To reproduce, add the following two lines to '/etc/kde5rc': [KDE Action Restrictions][$i] ghns=false [0] https://develop.kde.org/docs/administration/kiosk/keys/#ghns -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) 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 kmail depends on: ii akonadi-server 4:22.12.3-1 ii kdepim-runtime 4:22.12.3-1 ii kio 5.103.0-1 ii libc62.36-9 ii libgcc-s112.2.0-14 ii libgpgmepp6 1.18.0-3+b1 ii libkf5akonadiagentbase5 [libkf5akonadiagentbase5-22 4:22.12.3-1 .12] ii libkf5akonadicontact5 [libkf5akonadicontact5-22.12] 4:22.12.3-1 ii libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]4:22.12.3-1 ii libkf5akonadimime5 [libkf5akonadimime5-22.12]4:22.12.3-1 ii libkf5akonadisearch-bin 4:22.12.3-1 ii libkf5akonadisearch-plugins 4:22.12.3-1 ii libkf5akonadisearchdebug5 [libkf5akonadisearchdebug 4:22.12.3-1 5-22.12] ii libkf5akonadisearchpim5 [libkf5akonadisearchpim5-22 4:22.12.3-1 .12] ii libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22 4:22.12.3-1 .12] ii libkf5bookmarks5 5.103.0-1 ii libkf5calendarcore5abi2 5:5.103.0-1 ii libkf5calendarutils5 [libkf5calendarutils5-22.12]4:22.12.3-1 ii libkf5codecs55.103.0-1 ii libkf5completion55.103.0-1 ii libkf5configcore55.103.0-1 ii libkf5configgui5 5.103.0-1 ii libkf5configwidgets5 5.103.0-1 ii libkf5contacts5 5:5.103.0-1 ii libkf5coreaddons55.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5dbusaddons55.103.0-1 ii libkf5grantleetheme-plugins 22.12.3-1 ii libkf5gravatar5abi2 [libkf5gravatar5-22.12] 4:22.12.3-1 ii libkf5guiaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5iconthemes55.103.0-1 ii libkf5identitymanagement5 [libkf5identitymanagement 22.12.3-1 5-22.12] ii libkf5identitymanagementwidgets5 [libkf5identityman 22.12.3-1 agementwidgets5-22.12] ii libkf5itemmodels55.103.0-1 ii libkf5itemviews5 5.103.0-1 ii libkf5jobwidgets55.103.0-1 ii libkf5kcmutils5 5.103.0-3 ii libkf5kiocore5 5.103.0-1 ii libkf5kiofilewidgets55.103.0-1 ii libkf5kiogui55.103.0-1 ii libkf5kiowidgets55.103.0-1 ii libkf5kontactinterface5 [libkf5kontactinterface5-22 22.12.3-1 .12] ii libkf5ksieveui5 [libkf5ksieveui5-22.12] 4:22.12.3-1 ii libkf5ldap5abi1 [libkf5ldap5-22.12] 22.12.3-1 ii libkf5libkdepim5 [libkf5libkdepim5-22.12]4:22.12.3-1 ii libkf5libkleo5 [libkf5libkleo5-22.12]4:22.12.3-1 ii libkf5mailcommon5abi2 [libkf5mailcommon5-22.12] 4:22.12.3-1 ii libkf5mailtransport5 [libkf5mailtransport5-22.12]22.12.3-1 ii libkf5mailtransportakonadi5 [libkf5mailtransportako 22.12.3-1 nadi5-22.12] ii libkf5messagecomposer5abi1 [libkf5messagecomposer5- 4:22.12.3-1 22.12] ii libkf5messagecore5abi1 [libkf5messagecore5-22.12]4:22.12.3-1 ii libkf5messagelist5abi1 [libkf5messagelist5-22.12]4:22.12.3-1 ii libkf5messageviewer5abi1 [libkf5messageviewer5-22.1 4:22.12.3-1 2] ii libkf5mime5abi1 [libkf5mime5-22.12] 22.12.3-1 ii libkf5mimetreeparser5abi1 [libkf5mimetreeparser5-22 4:22.12.3-1 .12] ii libkf5notifications5
Bug#1035290: kismet: fails to purge - command (deluser|adduser) in postrm not found
Hi, On Sun, 30 Apr 2023 05:08:50 +0200 Andreas Beckmann wrote: > during a test with piuparts I noticed your package failed to purge due > to a command not found. According to policy 7.2 you cannot rely on the > depends being available during purge, only the essential packages are > available for sure. > > The fix should be easy: your package is using adduser or deluser from > the adduser package, which is only priority important. Using useradd or > userdel from the passwd package (priority required) should fix this > problem. > > There is ongoing discussion how to handle system users on package > removal, see https://bugs.debian.org/621833 > Consensus seems to be not to remove system users (to avoid reusing UIDs > which could grant access to the wrong files) but to "lock" them (where > "locking"/"unlocking" is not yet precisely defined). Until that has > been decided it should be sufficient to have the postrm script ignore > any errors from deluser: > deluser ... || true since time is running out, would you mind if I NMU kismet with this change and file the unblock request? Thanks! cheers, josch signature.asc Description: signature
Bug#1036016: unblock: amavisd-new/1:2.13.0-3
Control: tags -1 confirmed On 2023-05-16 23:01:00 +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Sebastian Ramacher (2023-05-16 22:11:58) > > > [ Risks ] > > > > > > Low risk as the diff simply is: > > > > > > diff -Nru amavisd-new-2.13.0/debian/amavisd-new.postrm > > > amavisd-new-2.13.0/debian/amavisd-new.postrm > > > --- amavisd-new-2.13.0/debian/amavisd-new.postrm 2023-02-23 > > > 05:59:36.0 +0100 > > > +++ amavisd-new-2.13.0/debian/amavisd-new.postrm 2023-05-12 > > > 00:41:50.0 +0200 > > > @@ -33,7 +33,7 @@ > > > dpkg-statoverride --remove $i || true > > > done > > > > > > -userdel amavis > > > +userdel amavis || true > > > > userdel is from passwd and not from adduser. Am I missing something? > > Correct. But passwd is not Essential:yes and only gets pulled in by adduser. > The passwd package missing was part of my analysis in #1035654 because in that > test I only had Essential:yes packages installed (or otherwise I would not've > found this bug). Okay, then please go ahead and remove the moreinfo tag once the package is available in unstable. Cheers -- Sebastian Ramacher
Bug#1036189: mirror submission for mirror.crdf.fr
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.crdf.fr Type: leaf Archive-architecture: amd64 Archive-http: /debian/ Maintainer: CRDF Labs Country: FR France Location: Paris Sponsor: CRDF Labs https://www.crdf.fr Trace Url: http://mirror.crdf.fr/debian/project/trace/ Trace Url: http://mirror.crdf.fr/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.crdf.fr/debian/project/trace/mirror.crdf.fr
Bug#1036188: mirror submission for mirror.crdf.fr
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.crdf.fr Type: leaf Archive-architecture: amd64 Archive-http: /debian/ Maintainer: CRDF Labs Country: FR France Location: Paris Sponsor: CRDF Labs https://www.crdf.fr Trace Url: http://mirror.crdf.fr/debian/project/trace/ Trace Url: http://mirror.crdf.fr/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.crdf.fr/debian/project/trace/mirror.crdf.fr
Bug#1036187: vfu: several notes about clipboard
Package: vfu Severity: wishlist X-Debbugs-Cc: gmtmpa...@gmail.com Dear Maintainer, Have several thoughts about clipboard improving 1) Now you need to select file (using SPACE) before adding it into clipboard. Even when you want to add one file. I think it would be better to add file under cursor into the clipboard when nothing selected. So adding single file will be a bit easier 2) When you add new file into the clipboard - previously added files will be removed from the clipboard. Seems to me it would be better to keep previously added files in the clipboard. So you can add multiple files from different directories -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads) 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
Bug#1011530: FTBFS: fails to include system headers
Hello! On Tue, 2023-05-16 at 22:13 +0200, Bastian Germann wrote: > I am uploading a NMU to fix this. > Please find the debdiff attached. Please don't do NMUs without using a delay [1]. I did not get a chance to review your change. Adrian > [1] https://ftp-master.debian.org/deferred.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1036174: [Debian-med-packaging] Bug#1036174: FTBFS with nocheck option
Control: tags -1 + ftbfs confirmed Control: severity -1 important Hi Sven, Sven Mueller, on 2023-05-16: > When doing a build via pbuilder/sbuild and setting the `nocheck` > profile, the build-dependency on hevea is disabled (!nocheck). > However, it is still executed. Log excerpt below: > > cd Doc && make > make[2]: Entering directory '/<>/Doc' > sed "s/\@VERSION\@/1.80/g" version.in > version.sh > chmod +x version.sh > hevea -exec ./version.sh -exec xxdate.exe -fix Tutorial.tex > make[2]: hevea: No such file or directory > make[2]: *** [Makefile:18: Tutorial.html] Error 127 > make[2]: Leaving directory '/<>/Doc' > make[1]: *** [debian/rules:65: override_dh_auto_build] Error 2 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:42: binary-indep] Error 2 > dpkg-buildpackage: error: debian/rules binary-indep subprocess > returned exit status 2 Thank you for your report, I confirm the behavior on my end. > - I guess it was meant to be "!nodoc" instead of "!nocheck"? Incidently, I noticed that nodoc builds are also failing with: # dh_installdocs seems to refuse copying zero length files (for instance Tests/Blast/tab_2226_tblastn_002.txt) but these are needed for the tests as well cp -a debian/tmp_tests/* /<>/debian/python-biopython-doc/usr/share/doc/python-biopython-doc/ cp: cannot stat 'debian/tmp_tests/*': No such file or directory This is probably just one $(filter nodoc, …) away from being solved hopefully. Thinking out loud, I'm not sure about the severity of the bug. FTBFS bugs are normally Release Critical, but support for the build options is just recommended, so perhaps the present situation is fair enough. I raised the severity to "important" in doubt, but feel free to adjust accordingly. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Billy Sherwood - On Impact signature.asc Description: PGP signature
Bug#1034261: autofs attempts communication with portmapper (port 111) even for NFS4 mounts
For reference, upstream commit is at https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/commit/?id=80845bbcbc264f19c6c6a81d680e1f2b1ea6d3cc . Regards, Salvatore
Bug#1036016: unblock: amavisd-new/1:2.13.0-3
Hi, Quoting Sebastian Ramacher (2023-05-16 22:11:58) > > [ Risks ] > > > > Low risk as the diff simply is: > > > > diff -Nru amavisd-new-2.13.0/debian/amavisd-new.postrm > > amavisd-new-2.13.0/debian/amavisd-new.postrm > > --- amavisd-new-2.13.0/debian/amavisd-new.postrm 2023-02-23 > > 05:59:36.0 +0100 > > +++ amavisd-new-2.13.0/debian/amavisd-new.postrm 2023-05-12 > > 00:41:50.0 +0200 > > @@ -33,7 +33,7 @@ > > dpkg-statoverride --remove $i || true > > done > > > > -userdel amavis > > +userdel amavis || true > > userdel is from passwd and not from adduser. Am I missing something? Correct. But passwd is not Essential:yes and only gets pulled in by adduser. The passwd package missing was part of my analysis in #1035654 because in that test I only had Essential:yes packages installed (or otherwise I would not've found this bug). Thanks! cheers, josch signature.asc Description: signature
Bug#1036186: RM: dvi2ps-fontdesc-morisawa5 -- RoQA; orphaned; RC-buggy; low popcon
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove dvi2ps-fontdesc-morisawa5. The package has a trivial RC bug. It is orphaned and upstream (even though it is a native package) seems to be dead. The package has no reverse dependencies.
Bug#1031105: unshared debootstrap fails if auto-apt-proxy is installed
Control: tag -1 + patch Hi, Quoting Antonio Terceiro (2023-05-16 22:30:02) > Maybe I am missing something, but debootstrap has no knowledge about > auto-apt-proxy, it does: https://sources.debian.org/src/debootstrap/1.0.128%2Bnmu2/debootstrap/#L457 > why would debootstrap be the one responsible for disabling auto-apt-proxy? > Shouldn't mmdebstrap setup a reasonable (empty) /tmp since it's the one who > is setting up the unshared user namespace? being in an unshared user namespace does not mean you are inside a chroot. Since we are not inside a chroot, the unshared user sees files in /tmp with different permissions than the outside user. It is not reasonable to expect mmdebstrap to hose things in /tmp. Here is a possible fix: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/90 With this change, debootstrap will skip running auto-apt-proxy when the http_proxy environment variable is set to the empty string. Thanks! cheers, josch signature.asc Description: signature
Bug#1036185: RM: thp -- RoQA; RC-buggy; low popcon; dead upstream
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove thp. The long-standing RC bug #831952 has not been fixed (neither upstream nor in the package). Upstream seems to be dead. The package has no reverse dependencies.
Bug#1036026: unblock: libssh/0.10.5-1
Control: tags -1 moreinfo confirmed On 2023-05-13 15:49:12 +0200, Martin Pitt wrote: > --- libssh-0.10.4/debian/changelog2022-09-19 08:41:22.0 + > +++ libssh-0.10.5/debian/changelog2023-05-10 06:00:26.0 + > @@ -1,3 +1,26 @@ > +libssh (0.10.5-1) unstable; urgency=high > + > + [ Martin Pitt ] > + * New upstream security release (thus high urgency): > +- Fix authenticated remote DoS through potential NULL dereference during > rekeying > + with algorithm guessing (CVE-2023-1667) > + https://www.libssh.org/security/advisories/CVE-2023-1667.txt > +- Client authentication bypass in pki_verify_data_signature() in > low-memory > + conditions with OpenSSL backend; gcrypt backend is not affected > + https://www.libssh.org/security/advisories/CVE-2023-2283.txt > + (CVE-2023-2283, Closes: #1035832) > + * Bump Standards-Version to 4.6.2. No changes necessary. > + * Drop debian/source/lintian-overrides. It now causes a > "mismatched-override" > +warning, and apparently is not necessary any more. > + * debian/copyright: Drop files which don't exist any more. > +Spotted by lintian's "superfluous-file-pattern" warnings. > + > + [ Debian Janitor ] > + * Bump debhelper from old 12 to 13. It's too late for debhelper compat bumps. See https://release.debian.org/bookworm/FAQ.html Please re-upload without that change and remove the moreinfo tag once that happened. Cheers -- Sebastian Ramacher
Bug#1036184: O: tldp -- publishing tool for DocBook, Linuxdoc and Asciidoc
Package: wnpp I hereby orphan tldp as it is obviously not maintained anymore. The RC bug #867261 was fixed with upstream version 0.7.15. Please only consider adopting it if you can afford the time and have the skills to maintain it.
Bug#1031105: unshared debootstrap fails if auto-apt-proxy is installed
On Sat, 11 Feb 2023 21:12:33 +0100 Johannes Schauer Marin Rodrigues wrote: > Package: debootstrap > Version: 1.0.128+nmu2 > Severity: normal > X-Debbugs-Cc: terce...@debian.org > Control: affects -1 auto-apt-proxy mmdebstrap > > Hi, > > currently the mmdebstrap autopkgtest in experimental fails because debootstrap > cannot be run with the user namespace unshared if auto-apt-proxy is installed > and /tmp/.auto-apt-proxy-0 exists. Steps to reproduce: > > $ mmdebstrap --variant=custom --mode=unshare --setup-hook='env container=lxc > debootstrap unstable "$1" http://127.0.0.1/debian' /dev/null > > The error message is: > > E: insecure cache dir /tmp/.auto-apt-proxy-0. Must be owned by UID 0 and have > permissions 700 > > The reason for this error is, that debootstrap will run auto-apt-proxy which > will find that /tmp/.auto-apt-proxy-0 exists but since the user namespace of > the process is unshared, it will be owned by user "nobody" from its > perspective. > > Please provide a way to allow disabling running auto-apt-proxy when running > debootstrap. Maybe I am missing something, but debootstrap has no knowledge about auto-apt-proxy, why would debootstrap be the one responsible for disabling auto-apt-proxy? Shouldn't mmdebstrap setup a reasonable (empty) /tmp since it's the one who is setting up the unshared user namespace? signature.asc Description: PGP signature
Bug#1035056: [pre-approval] plasma-desktop 5.27.X
Hi, On 16-05-2023 13:37, Aurélien COUDERC wrote: Le dimanche 14 mai 2023, 22:05:19 CEST Paul Gevers a écrit : On 28-04-2023 15:29, Hefee wrote: we know the freeze policy and we know our request doesn’t meet the freeze policy requirements to the letter. People that read a lot of my replies will recognize it when I say that I don't care about the letter, but about the intent behind it. As Patrick wrote there are over a hundred bugs fixed in 5.27.3, .4 and .5 releases that we’re currently not shipping in bookworm. Is that complete list of bugs available somewhere, such that we can get an impression one the type of bugs that are fixed? I guess it's: https://kde.org/announcements/changelogs/plasma/5/5.27.2-5.27.3/ and likewise for the other versions. We don’t have the personpower to backport all these fixes to 5.27.2 individually and even if we did it would be a questionable option. I think we are aligned on that. But having said that, are there bug you have particularly on your radar? And would it be an option to not cherry pick backport bug fixes, but cherry pick packages with their bug fixes? @ all, I'll not be available the next 5 days because of holidays. I wish I had more time to answer now, because the Full Freeze is approaching fast. By all means continue the discussion while I'm gone. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1011530: FTBFS: fails to include system headers
I am uploading a NMU to fix this.
Please find the debdiff attached.diff -Nru mac-fdisk-0.1/debian/changelog mac-fdisk-0.1/debian/changelog
--- mac-fdisk-0.1/debian/changelog 2023-05-16 22:13:04.0 +0200
+++ mac-fdisk-0.1/debian/changelog 2023-05-16 21:26:00.0 +0200
@@ -1,3 +1,13 @@
+mac-fdisk (0.1-18.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Convert to source format 3.0 (quilt). (Closes: #1007407)
+ * Include system headers and prevent old error handling (Closes: #1011530)
+ * d/rules: Add missing targets.
+ * Change section to otherosfs.
+
+ -- Bastian Germann Tue, 16 May 2023 21:26:00 +0200
+
mac-fdisk (0.1-18) unstable; urgency=medium
* New maintainer:
diff -Nru mac-fdisk-0.1/debian/control mac-fdisk-0.1/debian/control
--- mac-fdisk-0.1/debian/control2023-05-16 22:13:04.0 +0200
+++ mac-fdisk-0.1/debian/control2023-05-16 21:26:00.0 +0200
@@ -1,5 +1,5 @@
Source: mac-fdisk
-Section: base
+Section: otherosfs
Priority: optional
Build-Depends: debhelper
Maintainer: John Paul Adrian Glaubitz
@@ -32,7 +32,6 @@
Package: mac-fdisk-cross
Architecture: i386 m68k
-Section: otherosfs
Depends: ${shlibs:Depends}
Description: Apple disk partition manipulation tool, cross version
The fdisk utilities from the MkLinux project, adopted for Linux/m68k.
@@ -47,7 +46,6 @@
Package: pmac-fdisk-cross
Architecture: i386 m68k
-Section: otherosfs
Depends: ${shlibs:Depends}
Description: fdisk partition manipulation tool for PowerPC, cross version
The fdisk utilities from the MkLinux project, adopted for Linux/ppc.
diff -Nru mac-fdisk-0.1/debian/mac-fdisk.8.in
mac-fdisk-0.1/debian/mac-fdisk.8.in
--- mac-fdisk-0.1/debian/mac-fdisk.8.in 1970-01-01 01:00:00.0 +0100
+++ mac-fdisk-0.1/debian/mac-fdisk.8.in 2023-05-16 21:26:00.0 +0200
@@ -0,0 +1,262 @@
+.TH MAC-FDISK 8 "1 December 2001" "Debian" "Apple Disk Partitioning Manual"
+.SH NAME
+mac-fdisk \- Apple partition table editor for Linux
+.SH SYNOPSIS
+.B mac-fdisk
+.B "[ \-h | \--help ] [ \-v | \--version ] [ \-l | \--list device ... ]"
+.br
+.B mac-fdisk
+.B "[ \-r | \--readonly ] device ... "
+.SH DESCRIPTION
+.B mac-fdisk
+is a command line type program which partitions disks using the standard Apple
+disk partitioning scheme described in "Inside Macintosh: Devices".
+The
+.I device
+is usually one of the following:
+
+.nf
+.RS
+/dev/sda
+/dev/sdb
+/dev/sdc
+/dev/sdd
+/dev/sde
+/dev/sdf
+/dev/sdg
+/dev/hda
+/dev/hdb
+
+.RE
+.fi
+/dev/sda is the first hard disk on the SCSI bus (i.e. the
+one with the lowest id), /dev/sdb is the second hard disk, and so on.
+The
+.I partition
+is a
+.I device
+name followed by a partition number.
+The partition number is the index (starting from one) of the partition
+map entry in the partition map (and the partition map itself occupies the
+first entry).
+For example,
+.B /dev/sda2
+is the partition described by the second entry in the partiton map on /dev/sda.
+
+.SH OPTIONS
+.TP
+.B \-v | \--version
+Prints version number of the
+.B mac-fdisk
+program.
+.TP
+.B \-h | \--help
+Prints a list of available commands for the
+.B mac-fdisk
+program.
+.TP
+.B \-l | \--list
+Lists the partition tables for the specified
+.IR device(s).
+With no
+.IR device(s)
+given, lists all SCSI and IDE devices found in the system.
+.TP
+.B \-r | \--readonly
+Prevents
+.B mac-fdisk
+from writing to the device.
+.SH "Editing Partition Tables"
+An argument which is simply the name of a
+.I device
+indicates that
+.B mac-fdisk
+should edit the partition table of that device. Once started,
+.B mac-fdisk
+presents an interactive command prompt to edit the partition table.
+The partition editing commands are:
+
+.nf
+.RS
+hlist available commands
+pprint (list) the current edited partition table status
+Pprint ordered by base address
+iinitialize the partition map
+schange size of partition map
+bcreate new 800K Apple_Bootstrap partition (used by yaboot)
+ccreate new standard Linux type partition
+Ccreate new partition, specifying the partition type
+ddelete a partition
+rreorder partition entry
+wwrite the partition table to disk
+qquit
+
+.RE
+.fi
+Commands which take arguments prompt for each argument in turn.
+You can also type the arguments separated by spaces
+and those prompts will be skipped. The
+.B i
+and
+.B w
+commands will prompt for confirmation. None of the editing you do will
+actually affect the state of the disk you are partitioning until the
+.B w
+command is issued. Then the map in its edited state will be
+permanently written to the disk.
+
+Partitions are always specified by their number, the index of the
+partition entry in the partition map. Many commands will change the
+index numbers of partitions which follow the affected partition; you are
+encouraged to use the
+.B p
+command to print the partition table as frequently as necessary. For SCSI
+disks, the partition
Bug#1036147: iptables-persistent: ship drop-ins in /lib/ and use aliases instead of alternatives
Hello On Tue, May 16, 2023, at 2:56 AM, Luca Boccassi wrote: > Source: iptables-persistent > Version: 1.0.19 > Severity: important > Tags: patch > > Please consider merging and uploading this, as I would like to have > this fixed for Bookworm. I can take care of the necessary paperwork > with the release team to request an unblock, to save you time. Thank > you! > I plan to work on this during this week, thanks for the patch
Bug#1036016: unblock: amavisd-new/1:2.13.0-3
Control: tags -1 moreinfo On 2023-05-13 04:24:26 +0200, Johannes Schauer Marin Rodrigues wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: amavisd-...@packages.debian.org, b...@debian.org > Control: affects -1 + src:amavisd-new > > Please unblock package amavisd-new > > [ Reason ] > > In the context of #1035654 me and Andreas Beckmann discovered nine source > packages that fail to purge without the adduser package installed. Accepting > this change would reduce that number to eight and close #1035841 in testing. > > [ Impact ] > > That depends on the resolution of #1035654. We want to avoid the > situation where a user removes the package, then upgrades to apt that > doesn't depend on adduser, then removes adduser and then attempts to > purge this package. > > [ Tests ] > > See the script I posted in #1035654. > > [ Risks ] > > Low risk as the diff simply is: > > diff -Nru amavisd-new-2.13.0/debian/amavisd-new.postrm > amavisd-new-2.13.0/debian/amavisd-new.postrm > --- amavisd-new-2.13.0/debian/amavisd-new.postrm 2023-02-23 > 05:59:36.0 +0100 > +++ amavisd-new-2.13.0/debian/amavisd-new.postrm 2023-05-12 > 00:41:50.0 +0200 > @@ -33,7 +33,7 @@ > dpkg-statoverride --remove $i || true > done > > -userdel amavis > +userdel amavis || true userdel is from passwd and not from adduser. Am I missing something? Cheers -- Sebastian Ramacher
Bug#1036183: gdm3: PATH not set properly on non-GNOME wayland sessions
Package: gdm3 Version: 43.0-3 Severity: important Starting a wayland environment other than GNOME's (KWin/Plasma, sway, or weston) leads to PATH being set to: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin instead of: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games Bug filed upstream: https://gitlab.gnome.org/GNOME/gdm/-/issues/846
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 20:13, Nilesh Patra wrote: | Uh, no. Maybe you misunderstood my suggestion. The t-p-u way was for Indeed! | r-base can continue to stay where it already is at the moment :) Yep. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1035918: [Pkg-shadow-devel] Bug#1035918: shadow fr.po update
On Thu, May 11, 2023 at 09:48:27AM +0200, bu...@no-log.org wrote: > Package: shadow > Version: N/A > Severity: wishlist > Tags: patch l10n > > Dear Maintainer, > > Please find attached the french updated translation of shadow-man-page, > proofread by the debian-l10n-french mailing list contributors. > > This file should be put as debian/po/fr.po in your package build tree. Hi, Thanks for the update. Just as a heads-up, we applied this upstream. We had to update it due to some format changes. You can see the result at curl -L https://github.com/shadow-maint/shadow/pull/727.diff -serge
Bug#1036182: bullseye-pu: package spyder/4.2.1+dfsg1-3+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: spy...@packages.debian.org
Control: affects -1 + src:spyder
[ Reason ]
I mistakenly took only one of the four commits that made up the
duplicate-code-on-save bug fix in the deb11u1 update
(https://github.com/spyder-ide/spyder/pull/14759/commits); the result
has turned out to be quite broken ("Run file" no longer works!), but I
didn't realise this when I uploaded +deb11u1. Of the other three
commits, one was purely cosmetic (whitespace consistency), 1.5 related
to the test suite (which is not included in the bullseye version of
spyder) and the remaining 0.5 of a commit (one line) was critical.
[ Impact ]
The "Run file" functionality is lost in many (most?) cases.
[ Tests ]
There are no automated tests in bullseye, unfortunately (which I why I
didn't discover this at the time). Manual testing has indicated that
this patch fixes the issue.
[ Risks ]
I don't see any risk in applying this patch.
[ 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 ]
Apply half of the commit
https://github.com/spyder-ide/spyder/pull/14759/commits/b38e483eb5707db845921345084f4b7de20b6148
which was left out of the original patch.
[ Other info ]
That I'll be more careful next time?!
Best wishes,
Julian
diff -Nru spyder-4.2.1+dfsg1/debian/changelog
spyder-4.2.1+dfsg1/debian/changelog
--- spyder-4.2.1+dfsg1/debian/changelog 2023-01-09 19:58:36.0 +
+++ spyder-4.2.1+dfsg1/debian/changelog 2023-05-15 21:56:49.0 +0100
@@ -1,3 +1,10 @@
+spyder (4.2.1+dfsg1-3+deb11u2) bullseye; urgency=medium
+
+ * Fix broken patch in previous update, with thanks to Baptiste Pellegrin
+(closes: #1036128)
+
+ -- Julian Gilbey Mon, 15 May 2023 21:56:49 +0100
+
spyder (4.2.1+dfsg1-3+deb11u1) bullseye; urgency=medium
* Fix duplicate-code-on-save bug (closes: #989660)
diff -Nru
spyder-4.2.1+dfsg1/debian/patches/Prevent-double-saving-when-running-a-file.patch
spyder-4.2.1+dfsg1/debian/patches/Prevent-double-saving-when-running-a-file.patch
---
spyder-4.2.1+dfsg1/debian/patches/Prevent-double-saving-when-running-a-file.patch
2023-01-09 19:58:36.0 +
+++
spyder-4.2.1+dfsg1/debian/patches/Prevent-double-saving-when-running-a-file.patch
2023-05-15 21:56:49.0 +0100
@@ -158,7 +158,7 @@
if self.get_option('save_all_before_run'):
-self.save_all(save_new_files=save_new_files)
+all_saved = self.save_all(save_new_files=save_new_files)
-+if not all_saved:
++if all_saved is not None and not all_saved:
+return
if self.__last_ec_exec is None:
return
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
Hi Wookey On Tue, May 16, 2023 at 8:19 PM Wookey wrote: > I used 0~0-1 to start with. 0~ is a quite a good way of > versioning things like this that don't have versions. (that 0~ lets > you switch neatly to real versions in the future should they > appear). Adding git hashes mostly makes for unreadable versions and > doesn't add much IMHO, but we can do that if it's important. Yes, the git hash clutters up the version, but at least you can easily identify which exact commit is packaged. The date alone might not be sufficient, in particular with rebasing. > Debian generally tries to pick a version and make depending packages > work with it, rather than try to suport multiple versions unless it > really is necessary. I do not have a good feel for what the best > approach here is, and would greatly appreciate input from someone more > familiar with the codebase on what the best approach in debian might be. I see. I just wonder how useful such a package is. Many packages might have a hard time using it without significant upstream changes. Just as an example, even gRPC (another Google project itself) uses a 2 year old version, which is incompatible with what Fedora packaged last year, which is already incompatible with current master. It's kind of a mess... > I will put my unfinished project on salsa, file an ITP, and find my > notes, then mail you and we can see if we can sort this with a > reasonable level of effort. Sure, I would be very happy to help. Oliver
Bug#1034824: tomcat9 should not be released with Bookworm
Hi, On 12-05-2023 21:49, Paul Gevers wrote: I'll check on Sunday on the proposal, unless somebody beats me to it. I don't have time before then. This dropped off my radar and I don't expect I have decent time to look at this until a week from now. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1036181: O: libapache-mod-auth-radius -- Apache 2.x module for RADIUS authentication
Package: wnpp I hereby orphan libapache-mod-auth-radius as it is obviously not maintained anymore. Please only consider adopting it if you can afford the time and have the skills to maintain it.
Bug#1036180: RM: latrace -- RoQA; orphaned; RC-buggy; low popcon; dead upstream
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Please remove latrace. The package is not useful anymore because of #907308. It is orphaned and upstream seems to be dead (else they would have fixed the bug). The package has no reverse dependencies.
Bug#1028325: RM: myodbc -- RoQA, unmaintained, FTBFS since years
Control: reassign -1 ftp.debian.org Control: severity -1 normal On Mon, 9 Jan 2023 16:47:04 +0100 Tobias Frost wrote: If there is no answer, I will reassing the bug for removal in exactly 3 months. Doing that now.
Bug#1035831: tech-ctte: Reinstate merged-/usr file movement moratorium
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 09 May 2023 21:26:10 +0100, Hi, Sean Whitton wrote: > === BEGIN > > OPTION A: > > Under Constitution 6.1.5, the Technical Committee recommends that the > maintainers of individual packages should not proactively move files > from the root filesystem to corresponding locations under /usr in the > data.tar.* of packages. So, /foo/bar should not move to /usr/foo/bar. > > Files that are in /usr in the Debian 12 release should remain in /usr, > while files that are in /bin, /lib* or /sbin in the Debian 12 release > should remain in those directories. If any files are moved from /bin, > /lib* or /sbin into /usr after the Debian 12 release, they should be > moved back to their Debian 12 locations. > > This moratorium lasts until we vote to repeal it. We expect to do that > during the trixie development cycle, and sooner rather than later. > We will continue to facilitate efforts to resolve the remaining issues > that stand in the way of safely repealing the moratorium. > > OPTION B: > > As option A, except that only maintainers of essential and transitively > essential packages should refrain from proactively moving files from the > root filesystem to corresponding locations under /usr in the data.tar.* > of packages. > > OPTION N: > > None of the above. > > === END I vote A > B > N. Regards, Matthew - -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAmRjwrQACgkQEvTSHI9q Y8jZ2g//dP+kxRXBLe/GjgE54NsePfPFmXD4gFaOsr535M3IePVRqA7JNHs9g0Fj kCZLH0lZnM04pTp/EPqUas/9HY4wq6sVTo+SDjWe+seJu6ichdIqLmuKoKUF1jqp ps+ZBi0ppeQBrfirYU1i9xrKXQPMMfcQ+IRgyllvPSwuqB9lpFPDeIYsZGEJjaER KzZ4lm+/56F4SrnannYon5la8IO+nUQFvM3vWuaQJFENnTB8RaMjBm+29kvUnJEl 7JHVdKZppqwgiYtzaOkLfEdAv2zcfpk/fL6Zd/pe6p+nSPXWXzyhUVJvCcuRq6B+ uiGj8F7G0K35jSm/1wozSwE9iyeNfOi9QJS4XnRYT8t6VxUn8KfZUbMBtalh4fIN 3dt10eKkJEPBSNuMzky7uDQszbo6JaQIWRs0Jb7pYftpimcCf0OZ/3ICC/gTHm/I 63CFwXaIm/cSXEw/ol9GBJ1ZIh5zcRH95tK0bLDZtIs6KRMF0aqzUvwaYSBcxCuM sirbd+PaQ87I19nPyyFuwi6yhUDwWsnXCENc/GGsU9LQp/UDaG5Er8YVcfWkpMh2 lM+ih6qP9hLjeYBAywYJlzRWYVieiLvfaOQCrkOlfOSZKQD8tGqGTbBj6+9LTa9e YxJJrSiHXK3g8JY/GLvnIJLlvcEdsE1Ivkae8WaeHBuvc8JUs7w= =Dysi -END PGP SIGNATURE-
Bug#1036179: xss-lock: please consider upgrading to 3.0 source format
Source: xss-lock Version: 0.3.0+git20230128.0c562b-1 Please switch xss-lock to the 3.0 (quilt) source format.
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
On 2023-05-16 14:46 +0200, Oliver Reiche wrote: >I'm basically aware of the build dependencies >policy and all of my binary and header-only dependencies are satisfied >from packages. However, my package additionally depends on 11 proto files >(i.e., architecture-independent interface of data encoding [1]) from >google-apis [2] and bazel-remote-apis [3] as a pure build dependency. ... >3. Taking the longer road and package google-apis and bazel-remote-apis >first. This is the right way to fix this. I noticed in 2021 whilst doing tensorflow packaging that quite a few packages were using parts of these but nearly everyone had just embedded some files. We do have parts of the api packaged (e.g ruby-googleapis-common-prootos-types, and there are also ITPs for python-google-api-core and ruby-google-apis-discovery-v1 from jan 2023) but not the whole thing for all the languages. So I started on fixing it properly, and have a build that works for C, C++, java, python3 and ruby, but some language bindings did not build, and clearly I stalled part-way through the process of fixing those. I'm not sure which bindings we actually care about and which we can leave for now. I think I started an email about this somewhere, but am failing to find it right now, so I can't remember exactly where I got to. >However, that raises a few more questions: > a. google-apis is not versioned/tagged upstream. What version would I >use? I've seen that Fedora uses the version string >"0-1.git". I used 0~0-1 to start with. 0~ is a quite a good way of versioning things like this that don't have versions. (that 0~ lets you switch neatly to real versions in the future should they appear). Adding git hashes mostly makes for unreadable versions and doesn't add much IMHO, but we can do that if it's important. > b. Where should proto files be installed to? I know that libprotobuf-dev >puts it in /usr/include, but /usr/share could be also viable. What is the >recommended location? Good question. The right answer may depend on the language. > c. As the file structure of google-apis changes rather frequently, >should there be any prefix, so multiple versions could be installed in >parallel? Debian generally tries to pick a version and make depending packages work with it, rather than try to suport multiple versions unless it really is necessary. I do not have a good feel for what the best approach here is, and would greatly appreciate input from someone more familiar with the codebase on what the best approach in debian might be. >Could you please comment on which option you would suggest to take, and >also briefly address the potential follow-up questions? I suggest we compare notes on this in a specific ITP bug for google-apis. If you have a bit of time to put into this it would be great to actully (finally) get this fixed for the general case. I can provide debian packaging and build expertise to complement your knowledge of google-apis. (and then maybe we can give bazel-remote-apis a very similar treatment). I will put my unfinished project on salsa, file an ITP, and find my notes, then mail you and we can see if we can sort this with a reasonable level of effort. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1036178: systemd unit file in wrong place
Package: lprint Severity: important As per bug #1036022, it appears that lprint is delivering a systemd unit file to a place in the file system where it will never be acted on. Because the immediate motivation for that bug, a file overlap conflict with the altos package, was resolved in the latest altos upload, I went ahead and closed that bug. But, the lprint package really should be updated to deliver the systemd unit file correctly. Bdale signature.asc Description: PGP signature
Bug#1036177: glslang: please consider upgrading to 3.0 source format
Source: glslang Version: 12.0.0-2 Severity: wishlist Please switch to the 3.0 (quilt) source format.
Bug#1036176: mesa: please consider upgrading to 3.0 source format
Source: mesa Version: 22.3.6-1+deb12u1 Severity: wishlist Please switch xss-lock to the 3.0 (quilt) source format.
Bug#1035568: dnsmasq is broken on new bookworm installations
Control: severity -1 normal On Fri, 05 May 2023 15:17:37 + =?utf-8?q?Jens_Mei=C3=9Fner?= wrote: > Package: dnsmasq > Version: 2.89-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: heptal...@gmx.de > > Hello, > > dnsmasq on bookworm fails to start after installation because the dns port 53 > is already is use by systemd-resolved. > After stopping systemd-resolved dnsmasq will start but refuses all dns > queries with the Extended DNS Error Code 14 "Not Ready". > This error is reproducible on new installation. > > Setting severity to grave because it affects clean installs. This is a bug that needs fixing, for sure. But systemd-resolved is installed by default only on the cloud images, and not on all Debian installs. Therefore this does not really affect all users, and grave severity does not apply. Enabling (uncommenting) the `bind-interfaces` in /etc/dnsmasq.conf fixes the issue on my tests, and maybe that should be set by default. signature.asc Description: PGP signature
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
Hello, On Mon 15 May 2023 at 09:21PM +02, Paul Gevers wrote: > Hmm, OK. Can you please share the debdiff? Unless I see very weird > things, I'll approve it. Thanks. David Bremner is hoping to work on this shortly. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Package: e2fsprogs Followup-For: Bug #1035543 X-Debbugs-Cc: a...@debian.org, bi...@debian.org I'm having trouble reconciling these two log lines during the upgrade without systemd: ls: cannot access '/etc/systemd/system/multi-user.target.wants': No such file or directory ... (deb-systemd-helper DEBUG) All links present, considering e2scrub_reap.service was-enabled. Could those indicate some kind of inconsistency/bug?
Bug#1036175: unblock: mksh/59c-28
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: m...@packages.debian.org, t...@mirbsd.de
Control: affects -1 + src:mksh
Please unblock package mksh
[ Reason ]
Some bugfixes regarding formatting, shift/rotate arithmetics,
and a few cases where the parser was not properly reentrant
leading to use-after-free/double-free for recursive parsing.
Also add some tests for the printf builtin to the testsuite.
[ Impact ]
Probably low. I haven’t hit any of these in practice, but
fuzzing would find them.
[ Tests ]
There is a new test for the printf builtin, but the other
changes have only been manually tested to not crash (also
with Valgrind and ASan/UBSan) after the change.
[ Risks ]
I’ve only cherry-picked the changes I’m fully confident of
and that do not touch larger areas of code. They have been
in use for several weeks, and no new issues popped up.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[↓] attach debdiff against the package in testing
[ Other info ]
Instead of a debdiff, because all changes are contained in
d/patches/debian-changes, I attached a diff of the unpacked
and patched package minus d/patches/.
The changes to Build.sh and check.t are to test the printf builtin.
The change to mbsdint.h is the arithmetic fix: a % b instead of a & (b-1)
The change to shf.c is to fix the formatting stuff.
The changes to sh.h and syn.c are the parser fixes, plus sh.h
assigns a unique upstream revision date to the so-patched version
to ease $KSH_VERSION-based bugspotting.
I cherry-picked the fixes only but kept the RCS IDs as is in order
to not clutter the diff for easier review.
unblock mksh/59c-28
diff -pruN mksh-59c-26/Build.sh mksh-59c-28/Build.sh
--- mksh-59c-26/Build.sh2023-05-16 19:13:21.0 +0200
+++ mksh-59c-28/Build.sh2023-05-16 19:13:32.0 +0200
@@ -2805,6 +2805,7 @@ fi
if test 1 = "$USE_PRINTF_BUILTIN"; then
cpp_define MKSH_PRINTF_BUILTIN 1
+ check_categories="$check_categories printf-builtin"
else
USE_PRINTF_BUILTIN=0
fi
diff -pruN mksh-59c-26/check.t mksh-59c-28/check.t
--- mksh-59c-26/check.t 2023-05-16 19:13:21.0 +0200
+++ mksh-59c-28/check.t 2023-05-16 19:13:32.0 +0200
@@ -31,7 +31,7 @@
# (2013/12/02 20:39:44)
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress/bin/ksh/?sortby=date
expected-stdout:
- KSH R59 2023/01/31
+ KSH R59 2023/04/28
description:
Check base version of full shell
stdin:
@@ -14254,3 +14254,43 @@ expected-stdout:
2 eh .
3 eh .
---
+name: optional-printf-builtin
+description:
+ printf(1) minimal tests
+category: printf-builtin
+stdin:
+ t() {
+ o=$(\\builtin printf "$@"; echo .)
+ r=$?
+ print -r -- "$((++n)) ${o%.} : $r"
+ }
+ t '<%s>' a b\ c
+ t '%s - %c %s %d %i %o %u %x %X %b' 3
+ t '%% %c %s %d %i %o %u %x %X' 72 73 74 75 76 77 78 79
+ t '\\\a\b\f\n\r\t\v\01234'
+ let n+=2
+ t '%b foo %s bar' '\\\a\b\f\n\r\t\v\01234\cdefg'
+ let ++n
+ t '<%d>' 1 +2 -3 0x1a 0X1B 010 -011 +012 \'1 \"2
+ t '<%d|%d><%+d|%+d><% d|% d><%+ d|%+ d>' 1 -1 1 -1 1 -1 1 -1
+ t '<%o|%#o><%x|%#x><%X|%#X>' 8 9 10 11 12 13
+ #XXX replace with below
+ t '|%3d|%-3d|%+3d|%-+3d|%03d|%-03d|%3d|%.3d|notyet|' \
+ 1 2 3 4 5 6 8
+ #t '|%3d|%-3d|%+3d|%-+3d|%03d|%-03d|%3d|%.3d|%5.3d|' \
+ #1 2 3 4 5 6 8 9
+ #12 | 1|2 | +3|+4 |005|6 ||008| 009| : 0
+expected-stdout:
+ 1 : 0
+ 2 3 - 0 0 0 0 0 0 : 0
+ 3 % 7 73 74 75 114 77 4e 4F : 0
+ 4 \
+
+ 34 : 0
+ 7 \
+
S4 : 0
+ 9 <1><2><-3><26><27><8><-9><10><49><50> : 0
+ 10 <1|-1><+1|-1>< 1|-1><+1|-1> : 0
+ 11 <10|011> : 0
+ 12 | 1|2 | +3|+4 |005|6 ||008|notyet| : 0
+---
diff -pruN mksh-59c-26/debian/changelog mksh-59c-28/debian/changelog
--- mksh-59c-26/debian/changelog2023-02-15 16:04:53.0 +0100
+++ mksh-59c-28/debian/changelog2023-04-28 23:34:20.0 +0200
@@ -1,3 +1,21 @@
+mksh (59c-28) unstable; urgency=medium
+
+ * Revert 59c-27 changes as mksh is, surprisingly, still a key
+package for this release, shunit check-B-D
+ * Add cherry-picked individual fixes
+- fix some formatting routine corner cases
+- check the optional printf builtin (used for lksh) in the
+ testsuite, to avoid the issues reappearing
+ * Cherry-pick more individual fixes from upstream
+- fix shift/rotate for nōn-power-of-two-sized bit quantities
+- correct 59c regression in recursive parser for command
+ substitution and fix the other place it was not reentrant
+ as well (by moving function-static storage to stack/heap);
+ crash discovered by Riccardo Felici, USI Lugano
+ * Revert
Bug#1034261: autofs attempts communication with portmapper (port 111) even for NFS4 mounts
I consider this bug quite severe as it may break working setups after an update. The corresponding bug report for Ubuntu might be this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034261 It is the same bug reported on the autofs mailing list here: https://www.spinics.net/lists/autofs/msg02389.html Apparently, it has been introduced in the transition of autofs from 5.1.7 to 5.1.8. A fix has been posted here: https://www.spinics.net/lists/autofs/msg02391.html and again https://www.spinics.net/lists/autofs/msg02434.html
Bug#1035677: sane-utils: preinst deletes file owned by libsane-common: /usr/share/man/man5/sane-umax_pp.5.gz
Hello Andreas, please can you check the changes from dget -x https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.2.1-2.dsc or from git https://jff.email/cgit/sane-backends.git?h=release%2Fdebian%2F1.2.1-2 Many thanks CU Jörg Am Sonntag, dem 07.05.2023 um 18:38 +0200 schrieb Andreas Beckmann: > Package: sane-utils > Version: 1.2.1-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package removes files that > were installed by another package. > This was observed after an upgrade from bullseye to bookworm. > > From the attached log (scroll to the bottom...): > > 1m1.4s ERROR: FAIL: debsums reports modifications inside the chroot: > debsums: missing file /usr/share/man/man5/sane-umax_pp.5.gz (from > libsane-common package) > > I don't get what sane-utils.preinst is intended to do. Both files > it is going to delete were owned by sane-utils in bullseye, so dpkg > will take care of them. Appropriate Breaks+Replaces seem to be in > place for moving one of the files to libsane-common. > > cheers, > > Andreas -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: HU6U7Z6H Wire: @joergfringsfuerst Skype:jff-skype@jff.email Ring: jff Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#1036174: FTBFS with nocheck option
Package: python-biopython Version: 1.80+dfsg-4 When doing a build via pbuilder/sbuild and setting the `nocheck` profile, the build-dependency on hevea is disabled (!nocheck). However, it is still executed. Log excerpt below: cd Doc && make make[2]: Entering directory '/<>/Doc' sed "s/\@VERSION\@/1.80/g" version.in > version.sh chmod +x version.sh hevea -exec ./version.sh -exec xxdate.exe -fix Tutorial.tex make[2]: hevea: No such file or directory make[2]: *** [Makefile:18: Tutorial.html] Error 127 make[2]: Leaving directory '/<>/Doc' make[1]: *** [debian/rules:65: override_dh_auto_build] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:42: binary-indep] Error 2 dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit status 2 - I guess it was meant to be "!nodoc" instead of "!nocheck"?
Bug#1035568: dnsmasq is broken on new bookworm installations
On Fri, 05 May 2023 15:17:37 + =?utf-8?q?Jens_Mei=C3=9Fner?= wrote: > Package: dnsmasq > Version: 2.89-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: heptal...@gmx.de > > Hello, > > dnsmasq on bookworm fails to start after installation because the dns port 53 > is already is use by systemd-resolved. > After stopping systemd-resolved dnsmasq will start but refuses all dns > queries with the Extended DNS Error Code 14 "Not Ready". > This error is reproducible on new installation. > > Setting severity to grave because it affects clean installs. Simon, since this is a bug of high severity and we are close to bookworm release, would you consider taking a quick look at it? Thanks Nilesh signature.asc Description: PGP signature
Bug#1017144: gammaray: FTBFS: test failed
Control: severity -1 important On Sun, Aug 14, 2022 at 09:13:36AM +0200, Lucas Nussbaum wrote: > Source: gammaray > Version: 2.11.3-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220813 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > Start 2: connectiontest-preload-filter > > > [...] > > Injector error: Process crashed I acknowledge that a few tests are flaky, but it does not mean that this package fails to build completely. Since this bug was filed on 2022-08-14, it built successfully on amd64 buildds on 2022-10-01, 2022-12-21, 2022-12-24, 2023-01-15 and 2023-03-02. Downgrading severity to important so it doesn't block bookworm release. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1036173: nvidia-legacy-340xx-kernel-dkms: dkms module does not build against kernel 6.3
Package: nvidia-legacy-340xx-kernel-dkms Version: 340.108-18 Severity: important Dear Maintainer, * What led up to the situation? When compiling the module when installing a 6.3.2 linux kernel, the dkms modules compilation failed with: /var/lib/dkms/nvidia-legacy-340xx/340.108/build/nv-mmap.c:315:23: error: assignment of read-only member ‘vm_flags’ See the cause explained in: https://lore.kernel.org/lkml/za7x9y60sfgoa...@kroah.com/T/ The write access to vm_flags needs to be done now through some wrappers. * What exactly did you do (or not do) that was effective (or ineffective)? The fix is applying this patch: https://gist.github.com/vejeta/9078219f082d2bfd62b08b6eada780e6 by copying it to: /usr/src/nvidia-legacy-340xx-340.108/patches and adding the file name "nvidia-340xx-fix-linux-6.3.patch" to line 12 in /usr/src/nvidia-legacy-340xx-340.108/dkms.conf like: PATCH=(bashisms.patch 0001-backport-error-on-unknown-conftests.patch 0002-backport-error-on-unknown-conftests-uvm-part.patch unregister_procfs_on_failure.patch kmem_cache_create_usercopy.patch buil nvidia-340xx-fix-linux-6.3.patch) * What was the outcome of this action? The kernel could compile the nvidia 340 module and the system worked perfectly after it. -- Package-specific info: uname -a: Linux camelot 6.3.2-1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 6.3-1.1~bookworm (2023-05-13) x86_64 GNU/Linux /proc/version: Linux version 6.3.2-1-liquorix-amd64 (ste...@liquorix.net) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 ZEN SMP PREEMPT liquorix 6.3-1.1~bookworm (2023-05-13) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 12.2.0 (Debian 12.2.0-14) lspci 'display controller [030?]': 04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G86 [GeForce 8400 GS] [10de:0422] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Point of View BV G86 [GeForce 8400 GS] [1acc:0853] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia /etc/X11/xorg.conf.d/: total 12 drwxr-xr-x 2 root root 4096 Jan 17 01:14 . drwxr-xr-x 11 root root 4096 Jan 21 16:51 .. lrwxrwxrwx 1 root root 53 Jan 17 01:14 20-nvidia-legacy-340xx.conf -> /etc/alternatives/nvidia--20-nvidia-legacy-340xx.conf -rw-r--r-- 1 root root 79 Oct 28 2019 20-nvidia.conf /etc/nvidia/: total 24 drwxr-xr-x 4 root root 4096 Mar 19 21:14 . drwxr-xr-x 199 root root 12288 May 16 14:46 .. drwxr-xr-x 2 root root 4096 Jan 17 00:15 current drwxr-xr-x 2 root root 4096 Mar 19 21:16 legacy-340xx lrwxrwxrwx 1 root root56 Jan 17 00:15 nvidia-blacklists-nouveau.conf -> /etc/alternatives/nvidia--nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root53 Jan 17 00:15 nvidia-drm-outputclass.conf -> /etc/alternatives/nvidia--nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root12 Mar 17 20:36 nvidia-legacy-340xx-340.108 -> legacy-340xx lrwxrwxrwx 1 root root42 Jan 17 00:15 nvidia-load.conf -> /etc/alternatives/nvidia--nvidia-load.conf lrwxrwxrwx 1 root root46 Jan 17 00:15 nvidia-modprobe.conf -> /etc/alternatives/nvidia--nvidia-modprobe.conf Files from nvidia-installer: Config and logfiles: << /etc/modprobe.d/nvidia-blacklists-nouveau.conf >> # You need to run "update-initramfs -u" after editing this file. # see #580894 blacklist nouveau ^^ /etc/modprobe.d/nvidia-blacklists-nouveau.conf ^^ << /etc/X11/xorg.conf.d/20-nvidia-legacy-340xx.conf >> # The EoL driver does not get updated to support newer Xserver versions. Section "ServerFlags" Option "IgnoreABI" "1" EndSection ^^ /etc/X11/xorg.conf.d/20-nvidia-legacy-340xx.conf ^^ Kernel modules: nvidia.ko /lib/modules/6.2.13-1-liquorix-amd64/updates/dkms/nvidia-legacy-340xx.ko /lib/modules/6.2.13-1-liquorix-amd64/updates/dkms/nvidia-legacy-340xx-uvm.ko /lib/modules/6.1.0-9-amd64/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko /lib/modules/6.1.0-7-amd64/updates/dkms/nvidia-legacy-340xx.ko /lib/modules/6.1.0-7-amd64/updates/dkms/nvidia-legacy-340xx-uvm.ko /lib/modules/6.1.0-7-amd64/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing'), (500, 'oldstable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.2-1-liquorix-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages nvidia-legacy-340xx-kernel-dkms
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 09:31:20AM -0500, Dirk Eddelbuettel wrote: > > On 16 May 2023 at 19:49, Nilesh Patra wrote: > | On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > | > I personally prefer "1" over 2 as it is less noise (and effort). > | > | On second thoughts, I think sending it via testing-proposed-updates > | would be a better thing to do, as this case perfectly fits the problem. > | > | It's be same effort in both cases (one upload + filing a bug with release > team). > > Reading 'https://wiki.debian.org/TestingProposedUpdates' does indeed suggest > that this may be one of those situations. I can easily prepare a 4.3.0-2 > with that destination but would prefer if someone from the release could > 'nod', maybe in reply to this email. Uh, no. Maybe you misunderstood my suggestion. The t-p-u way was for r-cran-shiny not the r-base package. This is because r-cran-shiny would want to build against r-base in testing (and not unstable). Uploading a 4.3.0-2 of r-base would mean uploading a new r-base to testing without a proper transition and without re-compilation of API-incompatible graphics related packages -- that'd be quite the havoc in testing (and eventually next stable). It also violates some of the rules of t-p-u -- more details here[1] in case you are interested. r-base can continue to stay where it already is at the moment :) [1]: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra: > On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > > I personally prefer "1" over 2 as it is less noise (and effort). > > On second thoughts, I think sending it via testing-proposed-updates > would be a better thing to do, as this case perfectly fits the problem. Seems to be an appropriate solution - given we should stick to smallest changes in packaging if possible. > It's be same effort in both cases (one upload + filing a bug with release > team). Since I will not manage to do so in the next 16 hours I'd be happy if someone might beat me in doing so. Otherwise I can catch up tomorrow. Thanks a lot for your hint Andreas. > > Let me know what you think. > > > > [1] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > [2] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > [3] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > [4] > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > [5] https://wiki.debian.org/TestingProposedUpdates > > -- > Best, > Nilesh -- http://fam-tille.de
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 19:49, Nilesh Patra wrote: | On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: | > I personally prefer "1" over 2 as it is less noise (and effort). | | On second thoughts, I think sending it via testing-proposed-updates | would be a better thing to do, as this case perfectly fits the problem. | | It's be same effort in both cases (one upload + filing a bug with release team). Reading 'https://wiki.debian.org/TestingProposedUpdates' does indeed suggest that this may be one of those situations. I can easily prepare a 4.3.0-2 with that destination but would prefer if someone from the release could 'nod', maybe in reply to this email. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1034824: tomcat9 should not be released with Bookworm
Timo Aaltonen kirjoitti 16.5.2023 klo 10.12: Markus Koschany kirjoitti 13.5.2023 klo 23.38: Hi Salvatore, adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso: Hi Markus, On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote: I have just pushed the necessary changes to our Git repository. https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993 Do we need to have done more here? When Paul asked on #debian-release I noted that pki-server depends on tomcat9-user, so reducing libtomcat9-java only would now cause a broken dpeends for pki-server: $ dak rm --suite=bookworm -n -R -b tomcat9-user Will remove the following packages from bookworm: tomcat9-user | 9.0.70-1 | all We could simply replace tomcat9-user with tomcat10-user because it only ships a script to create a standalone tomcat instance. We have to do s/tomcat9/tomcat10/ in some debian service files as well. The question is: If we ship libtomcat9-java in Bookworm and change the dependency from tomcat9-user to tomcat10-user, will a web application like dogtag-pki, which is designed for Tomcat 9, continue to work with Tomcat 10? I don't know yet and maybe Timo can chime in here. I don't know, dogtag uses the skel files from tomcat9-user, but I diffed them between tomcat9 and 10 and couldn't see why it would regress. Had a closer look at dogtag, and it's launching the tomcat instance from CATALINA_HOME, so it's a one-way ticket to migrate an installed instance to use tomcat10 in the configuration, so I don't think moving to tomcat10-user would fly.. -- t
Bug#1036154: Temporary fix - issue connected with [DSA 5340-1] webkit2gtk security update?
(Added Alberto in CC, as the issue might be connected with the webkit2gtk security update: https://lists.debian.org/debian-security-announce/2023/msg00029.html ) Through /var/log/dpkg.log I checked which upgrades of libwebkit2gtk-4.0-37 and libgtk-3-0 took place in my previous apt upgrade. With: apt install libwebkit2gtk-4.0-37=2.38.5-1~deb11u1 libjavascriptcoregtk-4.0-18=2.38.5-1~deb11u1 gir1.2-javascriptcoregtk-4.0=2.38.5-1~deb11u1 gir1.2-webkit2-4.0=2.38.5-1~deb11u1 I was then able to downgrade the packages and afterwards put libwebkit on hold with: apt-mark hold libwebkit2gtk-4.0-37 After this temporary fix, I can again read my e-mails with astroid. Thank you. -- Matthias Kirschner - President - Free Software Foundation Europe Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290 Registered at Amtsgericht Hamburg, VR 17030 |(fsfe.org/support) Contact (fsfe.org/about/kirschner) Weblog k7r.eu/blog.html pgp4UMTqcGIdg.pgp Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > I personally prefer "1" over 2 as it is less noise (and effort). On second thoughts, I think sending it via testing-proposed-updates would be a better thing to do, as this case perfectly fits the problem. It's be same effort in both cases (one upload + filing a bug with release team). > Let me know what you think. > > [1] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > [2] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > [3] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > [4] > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > [5] https://wiki.debian.org/TestingProposedUpdates -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 19:25, Nilesh Patra wrote: | On Tue, May 16, 2023 at 03:01:10PM +0200, Andreas Tille wrote: | > when fixing bug #1035428 I realised test suite issues with | > | > r-cran-thematic [1] | >-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, | > always_valid)`: Graphics API version mismatch | > | > r-cran-treescape [2] | > r-cran-treespace [3] | >-> error is given if lambda is outside of [0,1] --- | > `medTree(trees, -1)` did not throw an error. | > | > As far as I can guess at least the first type of error (Graphics API | > version mismatch) is caused by the fact that a new upstream version of | > r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to | > experimental so it seems by accident). | | I can think of two ways: | | 1. r-cran-shiny is an arch:all package, so the package itself being | built against r-base 4.3.0 is not an issue. The issue is the | "r-base-core (>= 4.3.0-1)" that dh-r injects, which is being pulled in | the autopkgtests of its reverse-depends. | Changing that to "r-base-core (>= 4.2.2.20221110-2)" manually should do | the trick. | | Something on the lines of: | | override_dh_gencontrol: | dh_gencontrol | sed "s/r-base-core (>= 4.3.0-1)/r-base-core (>= 4.2.2.20221110-2)" -i debian/r-cran-shiny/DEBIAN/control | | Ofcourse, the hard-coding of 4.3.0-1 can be converted to some better | regular expression. Nice catch and suggestion! On 16 May 2023 at 19:27, Nilesh Patra wrote: | On Tue, May 16, 2023 at 08:26:21AM -0500, Dirk Eddelbuettel wrote: | > Note that none of this affects the release. My recommendation is temporarily | > suspend the autopkgtest in those affected packages. | | No, don't do that as they indicate a new r-base being pulled as one of | the dependencies (which would be incorrect for a package). In this case, | r-cran-shiny has a hard-dependency on r-base. | | Once that is fixed, rest of the things should be sorted out. I agree. Thanks for pointing that out. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1034378: Allow Percentage Formatting in apt
Hello, > Thanks – but could you perhaps create a merge request on salsa [0] > rather than attaching patches to bug reports as that is easier to > review and less likely to get lost. It also runs out test and all > such, so it gives you and reviewers some direct visible feedback. Thanks for the reply. I’ve tried to register on Salsa, but my accounts have not been approved yet. I’ve tried two times with usernames bitigchi and emirsari. Is it possible to direct me to a support channels about this? I will look at the patch and try to modify as per your comments. Best, Emir
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 08:26:21AM -0500, Dirk Eddelbuettel wrote: > Note that none of this affects the release. My recommendation is temporarily > suspend the autopkgtest in those affected packages. No, don't do that as they indicate a new r-base being pulled as one of the dependencies (which would be incorrect for a package). In this case, r-cran-shiny has a hard-dependency on r-base. Once that is fixed, rest of the things should be sorted out. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Hi On Tue, May 16, 2023 at 03:01:10PM +0200, Andreas Tille wrote: > when fixing bug #1035428 I realised test suite issues with > > r-cran-thematic [1] >-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, > always_valid)`: Graphics API version mismatch > > r-cran-treescape [2] > r-cran-treespace [3] >-> error is given if lambda is outside of [0,1] --- > `medTree(trees, -1)` did not throw an error. > > As far as I can guess at least the first type of error (Graphics API > version mismatch) is caused by the fact that a new upstream version of > r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to > experimental so it seems by accident). I can think of two ways: 1. r-cran-shiny is an arch:all package, so the package itself being built against r-base 4.3.0 is not an issue. The issue is the "r-base-core (>= 4.3.0-1)" that dh-r injects, which is being pulled in the autopkgtests of its reverse-depends. Changing that to "r-base-core (>= 4.2.2.20221110-2)" manually should do the trick. Something on the lines of: override_dh_gencontrol: dh_gencontrol sed "s/r-base-core (>= 4.3.0-1)/r-base-core (>= 4.2.2.20221110-2)" -i debian/r-cran-shiny/DEBIAN/control Ofcourse, the hard-coding of 4.3.0-1 can be converted to some better regular expression. 2. It makes a valid and strong case to use t-p-u (see here[5]) for such an upload, as it isn't a possibility to build against R in testing. You might want to ask release team about it, by filing a bug for release.d.o pseudo-package and/or asking in #debian-release on OFTC. I personally prefer "1" over 2 as it is less noise (and effort). Let me know what you think. > [1] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > [2] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > [3] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > [4] > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ [5] https://wiki.debian.org/TestingProposedUpdates -- Best, Nilesh signature.asc Description: PGP signature
Bug#1036168: Typo
Sorry, the correct question is: "Is this a problem with the Debian package or should I report this to the NetCDF developers?"
Bug#1034378: Allow Percentage Formatting in apt
Hi, (sry, I seem to be either chronically out of time currently) On Fri, May 05, 2023 at 04:10:35PM -, Emir SARI wrote: > Hello,I'm attaching a patch that enables translations, Thanks – but could you perhaps create a merge request on salsa [0] rather than attaching patches to bug reports as that is easier to review and less likely to get lost. It also runs out test and all such, so it gives you and reviewers some direct visible feedback. [0] https://salsa.debian.org/apt-team/apt/-/merge_requests > and fixes an issue that creates extra spaces when the percentage sign is > prepended to the "Progress: [100%]" string, due to the fixed layout. I have only very quickly looked at the patch, so only two quick remarks: The first hunk seems wrong as our 'strprintf' 'prints to a std::string' given as first argument and doesn't return anything. Meantime, your change also uses std::printf which means it would print directly to stdout, which this code shouldn't do either. In general, I suppose the formatting currently is "Progress: [ 42%]" so "Progress: [ %42]" is your target? I think we could go with a "%d%%" string for all (four) cases (which is my other remark) and assemble the individual strings with e.g. "Progress: [%s]". The code could format a "%100" first to establish the maximum length and prepend spaces as needed for the real value. Oh, and one more thing: Comments in code meant for translators are per convention prefixed with: "TRANSLATORS: " (see existing usages) and should try a little harder to convey what a string is used for, meanwhile a "localize according to your locale settings" could be said about each and every string… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1036172: unblock: gnome-dvb-daemon/1:0.2.91~git20170110-5
Package: release.debian.org Control: affects -1 + src:gnome-dvb-daemon X-Debbugs-Cc: gnome-dvb-dae...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock Please unblock package gnome-dvb-daemon and reduce the days required to reach Testing. [ Reason ] The gnome-dvb-control app doesn't run because it needed to be updated for Python >= 3.8. https://bugs.debian.org/1036124 [ Impact ] The gnome-dvb-daemon binary packages have no reverse dependencies in Debian and have a low popcon. [ Tests ] dh_auto_test runs some basic checks and would fail the build for failures (but aren't testing this specific bug) gnome-dvb-daemon has no autopkgtest and doesn't trigger other autopkgtests I installed the new version of gnome-dvb-daemon on Debian Bookworm and was able to successfully run gnome-dvb-control. [ Risks ] [ 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 testing [ Other info ] A minimal debian/upstream/metadata file was also added in this upload (I thought I had reverted the change but it is harmless). Please lower the days required to reach Testing because I don't believe there is time for this package to migrate before the "complete" freeze and letting this bugfix in won't disrupt the release process. unblock gnome-dvb-daemon/1:0.2.91~git20170110-5 Thank you, Jeremy Bicha gnome-dvb-daemon-bookworm-unblock.debdiff Description: Binary data
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#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 15:01, Andreas Tille wrote: | Hi, | | when fixing bug #1035428 I realised test suite issues with | | r-cran-thematic [1] |-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, | always_valid)`: Graphics API version mismatch | | r-cran-treescape [2] | r-cran-treespace [3] |-> error is given if lambda is outside of [0,1] --- | `medTree(trees, -1)` did not throw an error. | | As far as I can guess at least the first type of error (Graphics API | version mismatch) is caused by the fact that a new upstream version of | r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to | experimental so it seems by accident). Yes. It was very much by accident, and my bad. When the freeze hardened and I switched uploading from unstable to experimental (on March 15 per my mail folder of installer replies, and coincidentally with the R 4.2.3-1 upload), I managed to update the distribution field (often using 'C-x d' in the handy Emacs mode) in the debian/changelog file each and every time --- with the one exception of the next update of r-base to the 4.3.0 release :-/ | I wonder what might be the most sensible strategy to fix this. Since | an epoch is considered ugly I've seen some kind of | 4.3.0+really+4.2.2.20221110 | version number. However, in case of R it might not be the best idea | to use this kind of fake version in a stable release. I think we shouldn't. Apart from this test issue, the binary sits in unstable and will remain in unstable. The change is graphics format is a repeat of previous micro-API changes from upstream where Paul Murrell (who is the one taking care of the graphics device) enhances its capabilities (often in quite meaningful ways). The R Core team does not consider this a breaking change, and does recommend or mandate rebuilds of the nearly 20k CRAN packages. I happen to concur. However, when a package built with such a graphics api version 'A' is loaded by R of version 'B' (and it usually happens to us the other way) the package load simply errors out with a message. This is not fatal -- it is just a hint to rebuild the package under the R version used. I have always been of the pragmatic view that is indeed good enough. (Johannes of the back-porters team disagrees, he reminded me of a simple search for the one code line doing the check. Running that at the GitHub mirror of CRAN (which is a superset as it includes packages that once were on CRAN but are no longer) I identified ten packages of which about half or more are no longer on CRAN. For us it is likely `ragg` and `svglite`. I can dig out the details from my reply to Johannes.) Note that none of this affects the release. My recommendation is temporarily suspend the autopkgtest in those affected packages. They did their job and found the mismatch with the R 4.3.0 in unstable that shouldn't have been uploaded there. Out the about fifty package uploads I made since I switched to experimental, one went to wrong repo. That was not intentional but I think we can manage. Best, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Hi, when fixing bug #1035428 I realised test suite issues with r-cran-thematic [1] -> Error in `svglite_(filename, bg, width, height, pointsize, standalone, always_valid)`: Graphics API version mismatch r-cran-treescape [2] r-cran-treespace [3] -> error is given if lambda is outside of [0,1] --- `medTree(trees, -1)` did not throw an error. As far as I can guess at least the first type of error (Graphics API version mismatch) is caused by the fact that a new upstream version of r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to experimental so it seems by accident). I wonder what might be the most sensible strategy to fix this. Since an epoch is considered ugly I've seen some kind of 4.3.0+really+4.2.2.20221110 version number. However, in case of R it might not be the best idea to use this kind of fake version in a stable release. Kind regards Andreas. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz [2] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz [3] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz [4] https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ -- http://fam-tille.de
Bug#1036169: ITP: jl -- Pretty Viewer for JSON logs
Package: wnpp Severity: wishlist Owner: Andrej Shadura * Package name: jl Version : 0.1.0-1 Upstream Author : Yunchi Luo * URL : https://github.com/mightyguava/jl * License : Expat Programming Lang: Go Description : Pretty Viewer for JSON logs jl (JL) is a parser and formatter for JSON logs, making machine-readable JSON logs human readable again. . jl currently supports 2 formatters, with plans to make the formatters customizable. . The default is -format compact, which extracts only important fields from the JSON log, like message, timestamp, level, colorizes and presents them in a easy to skim way. It drops un-recongized fields from the logs. . The other option is -format logfmt, which formats the JSON logs in a way that closely resembles logfmt (https://blog.codeship.com/logfmt-a-log- format-thats-easy-to-read-and-write/). This option will emit all fields from each log line. Packager’s comment: I’m not sure which binary name should I choose, since jl is a bit too short, and provides an opportunity for a future name collision. Please comment and let me know if you have a better idea. I think in any case it makes sense to name the source package golang-github-mightyguava-jl. -- Cheers, Andrej
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
Hi Paul, On Tue, May 16, 2023 at 5:07 AM Paul Wise wrote: > Generally all build dependencies should be packaged separately instead. > > https://wiki.debian.org/EmbeddedCopies > > Many thanks for that hint. I'm basically aware of the build dependencies policy and all of my binary and header-only dependencies are satisfied from packages. However, my package additionally depends on 11 proto files (i.e., architecture-independent interface of data encoding [1]) from google-apis [2] and bazel-remote-apis [3] as a pure build dependency. In the past, it seems that there was made an exception for packages that depend on these proto files: - buildstream and bazel-bootstrap (both only build-dep) - bazel-bootstrap-source (seems temporary/hackish though) - golang-github-gogo-googleapis-dev and golang-github-grpc-ecosystem-grpc-gateway-dev (both even shipping these files in their deb package) Interestingly, none of these packages is mentioned in the list of source packages that embed code from other projects [4]. For that reason, I was initially hoping that embedding these files would be fine for my package as well, albeit as a tarball. Currently, I see 3 options: 1. Keep the tarballs in debian/third_party, which would be the cleanest solution for our bootstrap, _but_ according to your last message this is probably not a viable option for Debian. 2. If the problem is only the tarballs, I could unpack them and embed only the exact 11 proto files that we need and explicitly mention them in the copyrights file of course. 3. Taking the longer road and package google-apis and bazel-remote-apis first. However, that raises a few more questions: a. google-apis is not versioned/tagged upstream. What version would I use? I've seen that Fedora uses the version string "0-1.git". b. Where should proto files be installed to? I know that libprotobuf-dev puts it in /usr/include, but /usr/share could be also viable. What is the recommended location? c. As the file structure of google-apis changes rather frequently, should there be any prefix, so multiple versions could be installed in parallel? Could you please comment on which option you would suggest to take, and also briefly address the potential follow-up questions? Many thanks in advance, I really appreciate your help! Kind regards, Oliver [1] https://protobuf.dev/ [2] https://github.com/googleapis/googleapis [3] https://github.com/bazelbuild/remote-apis [4] https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies
Bug#1036168: libnetcdf-mpi-dev: bad includedir in netcdf-mpi.pc
Package: libnetcdf-mpi-dev
Version: 1:4.8.1-2
Severity: normal
Dear Maintainer,
In the installed file:
/usr/lib/x86_64-linux-gnu/pkgconfig/netcdf-mpi.pc
I think the line:
includedir=/usr/include
is not correct. It should be:
includedir=${prefix}/include
(which evaluates to a different path).
Is this a problem with the Ubuntu package or should I report this to the NetCDF
developers?
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'),
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-69-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libnetcdf-mpi-dev depends on:
ii libnetcdf-mpi-19 1:4.8.1-2
ii pkg-config0.29.2-1ubuntu3
libnetcdf-mpi-dev recommends no packages.
Versions of packages libnetcdf-mpi-dev suggests:
ii netcdf-bin 1:4.8.1-1
pn netcdf-doc
-- no debconf information
Bug#1035960: All of sudden, the Spanish PO debconf templates is getting full of alien translators :-)
Hello
The spiderinit job took very long but finally it re-created all the status
files and the html pages, and I think it worked well.
I have added code to use lockfiles in the spiderbts job:
https://salsa.debian.org/l10n-team/dl10n/-/commit/5d518000bf15762dde13ed7cd56dee77a2bf757b
And reenabled the cron.hourly job
I'll try to keep an eye on things these days, please report if you notice any
issue.
Kind regards
El 12 de mayo de 2023 23:50:54 CEST, Laura Arjona Reina
escribió:
>Thanks everybody for the extra info and Cyril for the research
>
>I have killed the spider jobs.
>I have modified the crontab in tye.debian.org to disable cron.hourly job
>(spiderbts) for now.
>
>I have removed the status files [1] and launched a job spiderinit [2] to
>re-create them.
>
>[1] in /srv/i18n.debian.org/dl10n/data/spiderbts/data/status.??
>[2] sudo -u debian-i18n /srv/i18n.debian.org/dl10n/git/cron/spiderinit &
>
>Tomorrow I'll have a look at the logs of the spiderinit job [3] and launch the
>cron.hourly job once.
>
>[3] /srv/i18n.debian.org/log/spiderinit/spiderinit.20230512-2134.[err|log]
>
>
>Then I'll see how long does it take and if there is any issue.
>If everything went well the webpages should show correct data. Then I'll set
>the "hourly" job to run 6 times a day and will keep an eye these days.
>
>I agree that a lockfile is needed, I'll try to work on that too and when it's
>set, and the issue is fixed, I'll update the cron to run hourly again.
>
>Kind regards
>
>
>El 12/5/23 a las 12:04, Cyril Brulebois escribió:
>> Cyril Brulebois (2023-05-12):
>>> I'll keeping looking at what's supposed to happen on tye, but I'm not
>>> sure I'll be able to get to the bottom of it on my own.
>>
>> At least there's a HUGE red flag on tye. Load to the roof, RAM/swap
>> almost full, lots of dl10n-spider processes running for the same
>> language, some of them started May 9th.
>>
>> kibi@tye:~$ uptime
>> 10:02:58 up 12 days, 21:47, 2 users, load average: 63.24, 64.57,
>> 66.51
>>
>> kibi@tye:~$ free -h
>> totalusedfree shared buff/cache
>> available
>> Mem: 1.9Gi 1.7Gi69Mi 1.0Mi 125Mi
>> 57Mi
>> Swap: 511Mi 511Mi 0.0Ki
>>
>> kibi@tye:~$ ps faux|grep dl10n-spider|grep -o -- '--check-bts
>> ..'|sort|uniq -c
>>4 --check-bts ca
>>1 --check-bts cs
>>1 --check-bts da
>> 51 --check-bts de
>>7 --check-bts es
>>2 --check-bts fr
>>
>> kibi@tye:~$ ps faux|awk '/CRON/ {print $9}'|sort|uniq -c
>> 11 May09
>> 23 May10
>> 23 May11
>>1 00:15
>>1 02:15
>>1 03:15
>>1 04:15
>>1 05:15
>>1 06:15
>>1 07:15
>>1 08:13
>>1 08:15
>>1 09:15
>>2 10:00
>>1 10:01
>>
>> Note that many de.po occurrences appear in the status file for other
>> languages, looks like processes heavily stomping onto others' feet?
>>
>>
>> It looks to me there should be some locking at the very least to avoid
>> that amount of concurrency. And that it would probably be best to start
>> afresh, killing all those processes, maybe disabling the cron jobs,
>> cleaning temporary and maybe corrupted data files, and triggering a
>> single run manually to see if it works.
>>
>> But then, I have 0 knowledge about the spider, and I'll leave that up to
>> someone else: I don't want to risk making the matter worse!
>>
>>
>> Cheers,
>
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail
Bug#1036167: flask-appbuilder: Fails to build against python3-flask-sqlalchemy 3.0.3-1
Package: flask-appbuilder Version: 4.1.4+ds-3 Severity: serious Justification: Fails to build from source X-Debbugs-Cc: bdr...@debian.org Dear Maintainer, flask-appbuilder fails to build from source in Debian unstable due to python3-flask-sqlalchemy 3.0.3-1: ``` PYTHONPATH=. python3 -m sphinx -N -bhtml docs/ build/html Running Sphinx v5.3.0 Configuration error: There is a programmable error in your configuration file: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/sphinx/config.py", line 350, in eval_config_file exec(code, namespace) File "/<>/docs/conf.py", line 23, in import flask_appbuilder File "/<>/flask_appbuilder/__init__.py", line 5, in from .api import ModelRestApi # noqa: F401 ^ File "/<>/flask_appbuilder/api/__init__.py", line 21, in from .convert import Model2SchemaConverter File "/<>/flask_appbuilder/api/convert.py", line 3, in from flask_appbuilder.models.sqla import Model File "/<>/flask_appbuilder/models/sqla/__init__.py", line 5, in from flask_sqlalchemy import ( ImportError: cannot import name '_QueryProperty' from 'flask_sqlalchemy' (/usr/lib/python3/dist-packages/flask_sqlalchemy/__init__.py) ``` Updating to 4.3.1 (plus the ustream commits until 2023-05-16) is not enough to address the build failures. Upstream bug report: https://github.com/dpgaspar/Flask-AppBuilder/issues/2038 Ubuntu bug: https://launchpad.net/bugs/2019860 -- Benjamin Drung Debian & Ubuntu Developer
Bug#1012222: linux: please enable the CONFIG_X86_KERNEL_IBT configuration option
Version: 6.3.1-1~exp1 Hi Laurent, Le 2022-06-01 18:53, Laurent Bonnaud a écrit : > Package: src:linux > Version: 5.18.0-trunk > Severity: wishlist > > > Dear kernel Maintainers, > > the CONFIG_X86_KERNEL_IBT configuration option is currently not enabled in > Debian kernels: > > $ grep CONFIG_X86_KERNEL_IBT /boot/config* > /boot/config-5.18.0-trunk-amd64:# CONFIG_X86_KERNEL_IBT is not set > /boot/config-5.18.0-trunk-rt-amd64:# CONFIG_X86_KERNEL_IBT is not set > > It is an important protection against ROP/JOP attacks. Could you please > enable it in Debian kernels? Let's close this report since kernel IBT is enabled by default starting with Linux 6.2+ [1]. > Thanks, > > -- > Laurent. Cheers, Vincent [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4fd5f70ce14da230c6a29648c3d51a48ee0b4bfd signature.asc Description: PGP signature
Bug#1036166: diffpdf: Text differences because one is strikethrough and the other not, are not noticed as differences.
Package: diffpdf Version: 2.1.3-2 Severity: normal X-Debbugs-Cc: vapori...@gmail.com Dear Maintainer, * What led up to the situation? Usual compare of two pdf, working nicely except the bug reported * What exactly did you do (or not do) that was effective (or ineffective)? Try Compare Words and Characters options. No effect. Screenshot attached Thanks for your work! -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages diffpdf depends on: ii libc62.31-13+deb11u6 ii libgcc-s110.2.1-6 ii libgomp1 10.2.1-6 ii libpoppler-qt5-1 20.09.0-3.1+deb11u1 ii libqt5core5a 5.15.2+dfsg-9 ii libqt5gui5 5.15.2+dfsg-9 ii libqt5printsupport5 5.15.2+dfsg-9 ii libqt5widgets5 5.15.2+dfsg-9 ii libstdc++6 10.2.1-6 diffpdf recommends no packages. diffpdf suggests no packages.
Bug#1035056: [pre-approval] plasma-desktop 5.27.X
Dear Paul, Le dimanche 14 mai 2023, 22:05:19 CEST Paul Gevers a écrit : > Control: tags -1 moreinfo > > Hi, > > On 28-04-2023 15:29, Hefee wrote: > > before invest time, to do the debdiff and all paperwork for Plasma 5.27.X LTS > > packages, there's need to be a idea, how to get it into stable. > > Please read the freeze policy [2] and the FAQ [3] very carefully and > make sure your request meets the requirements of this phase of the > freeze and make sure you can answer every relevant question from the > FAQ. Please only pursue if you convinced the answer is yes. we know the freeze policy and we know our request doesn’t meet the freeze policy requirements to the letter. What we’re asking for is an exception because we think the current policy isn’t helping with release quality for a project the size and complexity of Plasma and with such a level of upstream activity. As Patrick wrote there are over a hundred bugs fixed in 5.27.3, .4 and .5 releases that we’re currently not shipping in bookworm. We don’t have the personpower to backport all these fixes to 5.27.2 individually and even if we did it would be a questionable option. We consider the risk of introducing new bugs by not shipping all upstream changes to be higher than shipping complete point releases. In addition we would be creating a Debian-specific version of Plasma unsupported by upstream, in parallel to their very own bugfix release branch that they maintain with a very close target to ours : only bugfixes to avoid regressions. So the remaining options we can think of are : - Ship bookworm with Plasma as it is : good for the release policy and our team’s workload, certainly bad for our users and the image of Plasma on Debian. - Remove Plasma from stable : not doable for bookworm as it is in the essential set like you wrote below, not a good move for Debian anyway I hope we would agree. - Ship the point releases to stable : won’t follow the freeze policy to the letter, manageable work on our side, certainly good for our users besides possible regressions introduced upstream, regressions will be looked at by upstream if they happen. > > Currently 5.27.3 on experimental. Upstream is relasing with a fibbonacci > > time frame, > > What does that mean (sorry, I don't have the energy to look this up, too > many unblock requests to process)? Each point release is made further away in time from the previous, as Plasma 5.27 LTS stabilizes. > > when stable will be release, we would be at ~5.27.5. I > > wanted to ask, if we find a solution together to get the new version > > into bookworm. Upstream wants to give bugfix releases over 2 years. > > So you consider bumping 5.27.2 to 5.27.5 a targeted fix? Would you > request the same in a stable point update (because that's about the same > level at this phase of the release)? We consider it a better option for bookworm, being overall a big collection of fixes. We don’t pretend it meets the targeted fix policy for each and every commit that goes in. And yes, we would like to be able to ship Plasma point releases to stable. This hasn’t been discussed with the relevant teams yet. > > Plasma 5.27 is a LTS branch, that is stable and only bug fixes with be > > released with next minor versions. No transitions nor API changes. > > [From FAQ] can you point at an upstream document that explains their policy? You may find the Plasma release page at [1] which only says : This is the last Plasma 5 release and will receive bugfixes only, no new features. The bugfixes are intended to continue being integrated into 5.27 until a first version of Plasma 6 can be released (and might continue longer). [1] https://community.kde.org/Schedules/Plasma_5#LTS_releases So they commit on putting only bugfixes in their LTS releases, but not only targeted bugfixes like we do. > > Plasma is ~50 pacakges - see a list of packages: > > I think you know by now, this fits extremely bad with the way the Freeze > is handled as we review everything and need to watch that everything > migrates. We're not going to give a set of key packages a cart blanch > this late in the freeze especially when we've NACK-ed already easier > things. E.g. although we're convinced the MariaDB unblock [4] really had > all best intentions and we hate to deny unblocks, it contained a bunch > of changes not meeting the freeze policy. I don’t want to compare situations but would like to discuss the merits of pushing Plasma point releases in bookworm. > We're frozen to ensure > stability and no surprises. The freeze policy is not ment to manage > packages (that's up to the maintainers), it's meant to ensure we can > manage the release process. And we do value your work on the release process and share the goal of releasing a stabilized Debian. We are not convinced that the process is helping us reaching that goal for Plasma, however. > In this particular case, we also don't have > tools to
