Bug#1042947: UDD: create a duck importer

[Lucas Nussbaum]

Hi Baptiste,

On 07/08/23 at 22:07 +0200, Baptiste Beauplat wrote:
> Hi Lucas,
> 
> On 2023-08-03 10:30, Lucas Nussbaum wrote:
> > duck-as-a-service (duck.debian.net) has been broken for a long time,
> > and
> > the corresponding UDD importer is broken as well (see #949009,
> > #963887).
> > In the meantime, duck continued evolving (was rewritten?) and is now
> > checking a lot more places for URLs.
> > 
> > It would probably be useful to re-create a way to provide duck
> > results
> > as a service, based on UDD, similarly to what is done for upstream or
> > lintian data.
> > 
> > Ideally, this would be done in cooperation with the duck maintainer
> > to
> > do the following changes:
> > - in duck, separate the logic to get URLs from sources, from the
> > logic
> >   to check those URLs (for example, allow dumping a list of URLs, and
> >   also using a list of URLs as source)
> > - in duck, provide machine-readable outputs (JSON?)
> 
> Currently duck has two features which can help us:
> 
> - The `-n` switch, which gets all URLs and prints them to stdout
> - The `-l filename` switch, which takes a file with one URL per line
> and checks them
> 
> Theoretically, what's missing in only a `--json` switch, which would
> change the output from console/text to JSON.
> 
> But, as I see it, the `-l` argument is limited in two aspects:
> 
> - It provides only the URL, loosing the checker type which is used to
> select what kind of validation will be performed.
> 
>   For instance, a https://salsa.debian.org/rfrancoise/tmux.git of type
> VCS-Git would be tested as a standard URL in the `-l` context, instead
> of a git repository.
> 
> - It requires a file
> 
> I'm thinking of implementing a new JSON specific input format
> (`--input-json`?), including the two information, which would read from
> stdout instead of a file.
> 
> The format would be as simple as:
> 
> ```json
> [
>    {"type": "VCS-Git",
>     "url": "https://salsa.debian.org/rfrancoise/tmux.git;,
>     "filename": "debian/control",  # optional key
>     "line_number": 10},    # optional key
>    ...
> ]
> ```
> 
> Following this logic, the output format for checking URLs would be the
> same, as to have `duck --json -n | duck --input-json` working.
> 
> The JSON result would hold an additional dictionary for each URL
> entries
> named "result", described as follows:
> 
> ```json
> [
>    {"type": "VCS-Git",
>     "url": "https://salsa.debian.org/rfrancoise/tmux.git;,
>     "filename": "debian/control",  # optional key
>     "line_number": 10, # optional key
>     "result": {
>    "state": 0,  # 0 for OK, 1 for Error, 2 for Information
>    "detail": "Informative message",
>    "certainty": "possible" # optional key
>    }},
>    ...
> ]
> ```
> 
> Let me know what you think of it.

That would be perfect!

In the context of UDD, I will probably implement that as two tables:
- one to store the mapping between source packages and urls
  (source, version, url, type, filename, line_number)
  which would be updated when a new source version gets uploaded
- one to store the status of urls
  (url, type, result, timestamp of last check)
  which would be updated with a retry policy to be defined

I would not use (filename, line_number) in the input of the URL
testing part.
The reason for that design is that it will easily allow to gather the
status for several versions of the package (testing + unstable +
experimental for example), while not duplicating the checks for URLs.

Lucas

Bug#1043261: libgtk-4-1: Sidebar item titles in file chooser dialog are not fully displayed (cropped)

[Yevhen Popok]

Package: libgtk-4-1
Version: 4.8.3+ds-2
Severity: normal
X-Debbugs-Cc: xalt7x.serv...@gmail.com

Dear Maintainer,

GTK4 version 4.8.3 found in Debian Bookworm  has bug with a cropped content in 
a file chooser sidebar.
This bug was fixed upstream and backported to GTK 4.8 series.
Upstream merged changes but didn't release newer minor version.
Please consider cherry-picking patches.

How to reproduce bug:
1. Make sure you have English locale and standard DPI (96)
2. Open GNOME Settings > Accessibility
3. In a "Seeing" section enable "Large Text"
4. Open GTK4 filechooser dialog (e.g. using GNOME Text Editor)
5. Notice that icons beside item titles ("Recent", "Home", "Documents" etc) are 
not fully displayed (cropped)

Upstream bug report:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4710

Upstream fix:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5471

Upstream backport for 4.8 series:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5573


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/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 libgtk-4-1 depends on:
ii  adwaita-icon-theme43-1
ii  hicolor-icon-theme0.17-2
ii  libc6 2.36-9+deb12u1
ii  libcairo-gobject2 1.16.0-7
ii  libcairo-script-interpreter2  1.16.0-7
ii  libcairo2 1.16.0-7
ii  libcloudproviders00.3.1-2
ii  libcolord21.4.6-2.2
ii  libcups2  2.4.2-3+deb12u1
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.14.1-4
ii  libfribidi0   1.0.8-2.1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-2
ii  libgraphene-1.0-0 1.10.8-1
ii  libgtk-4-common   4.8.3+ds-2
ii  libharfbuzz0b 6.0.0+dfsg-3
ii  libjpeg62-turbo   1:2.1.5-2
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libpangoft2-1.0-0 1.50.12+ds-1
ii  libpng16-16   1.6.39-2
ii  libtiff6  4.5.0-6
ii  libwayland-client01.21.0-1
ii  libwayland-egl1   1.21.0-1
ii  libx11-6  2:1.8.4-2+deb12u1
ii  libxcursor1   1:1.2.1-1
ii  libxdamage1   1:1.1.6-1
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8-1+b1
ii  libxinerama1  2:1.1.4-3
ii  libxkbcommon0 1.5.0-1
ii  libxrandr22:1.5.2-2+b1
ii  shared-mime-info  2.2-1

Versions of packages libgtk-4-1 recommends:
ii  iso-codes4.15.0-1
ii  libgtk-4-bin 4.8.3+ds-2
ii  librsvg2-common  2.54.5+dfsg-1

Versions of packages libgtk-4-1 suggests:
ii  gvfs  1.50.3-1
pn  libgtk-4-media-gstreamer | libgtk-4-media-ffmpeg  

-- no debconf information

Bug#1043253: tuxguitar: Missing java class ZipArchiveInputStream when opening .gp files

[tony mancill]

On Mon, Aug 07, 2023 at 11:51:51PM +0200, Jérôme Lafréchoux wrote:
> Package: tuxguitar
> Version: 1.5.6+dfsg1-6
> Severity: normal
> 
> Dear Maintainer,
> 
> I get a missing java class error when opening .gp files.
> 
> I can open .gpx and .gp5 files but all .gp files fail with the following
> error:
> 
> org.herac.tuxguitar.action.TGActionException: 
> org/apache/commons/compress/archivers/zip/ZipArchiveInputStream

Hello Jérôme,

Thank you for the bug report and for providing a repro case.

More soon,
tony

Bug#1043260: ITS: ink-generator

[Boyuan Yang]

Source: ink-generator
Version: 0.4-2.2
Severity: important
X-Debbugs-CC: aur...@gmail.com

Dear package ink-generator maintainer in Debian,

After looking into the package you maintain (ink-generator, 
https://tracker.debian.org/pkg/ink-generator), I found that this package
received no maintainer updates in the past 15 years and has unsolved open
bugs. Besides, the upstream project homepage has been defunct since 2015 with
no replacement available on the internet. As a result, I am filing an ITS
(Intent to Salvage) request against your package according to section 5.12 in
Debian's Developers' Reference [1].

My current plan is to clean up packaging and review/fix all Debian bug
reports.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Aug 29, 2023) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#1043258: texlive-latex-extra-doc: moderncv.tex fails to build

[Nick Hastings]

Hi,

sorry the bug subject line is wrong/bad. Better would be something
like: "template.tex for moderncv.cls fails to build".

Regards,

Nick.

Bug#1043259: ArgumentCountError: Too few arguments to function (set_error_handler)

[James Valleroy]

Package: shaarli
Version: 0.12.1+dfsg-8
Severity: important
Tags: upstream
X-Debbugs-Cc: jvalle...@mailbox.org

Whenever I try to access Shaarli, it shows a blank page. apache error
log shows the following:

[proxy_fcgi:error] [pid 146598:tid 146598] [client ...:35052] AH01071: Got 
error 'PHP message: PHP Fatal error:  During inheritance of ArrayAccess: 
Uncaught ArgumentCountError: Too few arguments to function {closure}(), 4 
passed in /usr/share/php/Slim/Collection.php on line 20 and exactly 5 expected 
in /usr/share/shaarli/index.php:50\nStack trace:\n#0 
/usr/share/php/Slim/Collection.php(20): {closure}()\n#1 
/usr/share/php/Slim/autoload.php(68): require('...')\n#2 
/usr/share/php/Slim/Container.php(83): {closure}()\n#3 
/usr/share/php/Pimple/Container.php(122): 
Slim\\Container->Slim\\{closure}()\n#4 /usr/share/php/Slim/Container.php(109): 
Pimple\\Container->offsetGet()\n#5 
/usr/share/php/Slim/DefaultServicesProvider.php(84): Slim\\Container->get()\n#6 
/usr/share/php/Pimple/Container.php(122): 
Slim\\DefaultServicesProvider->Slim\\{closure}()\n#7 
/usr/share/php/Slim/Container.php(109): Pimple\\Container->offsetGet()\n#8 
/usr/share/php/Slim/App.php(267): Slim\\Container->get()\n#9 
/usr/share/shaarli/index.php(95): Slim\\App->group()\n#10 {main} in 
/usr/share/php/Slim/Collection.php on line 20', referer ...

The 5th parameter of set_error_handler, $errcontext, has been removed
in PHP 8, so it must be given a default value.

I found an upstream fix for the issue:
https://github.com/shaarli/Shaarli/pull/1915

However, I don't see the issue on a new Shaarli install. I'm not sure
what conditions lead to the error currently.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/1 CPU thread; 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 shaarli depends on:
ii  gettext   0.21-12
ii  javascript-common 11+nmu1
ii  libapache2-mod-php8.2 [php-json]  8.2.7-1~deb12u1
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-lazyload 1.9.7-2
ii  libjs-jquery-ui   1.13.2+dfsg-1
ii  php   2:8.2+93
ii  php-arthurhoaro-web-thumbnailer   2.1.0+dfsg-2
ii  php-common2:93
ii  php-curl  2:8.2+93
ii  php-fpm   2:8.2+93
ii  php-gd2:8.2+93
ii  php-intl  2:8.2+93
ii  php-klogger   1.2.2-1
ii  php-ldap  2:8.2+93
ii  php-malkusch-lock 2.2.1+ds-1
ii  php-mbstring  2:8.2+93
ii  php-netscape-bookmark-parser  3.2.0-1
ii  php-oscarotero-gettext4.8.7-1
ii  php-parsedown 1.7.4-1
ii  php-parsedown-extra   0.8.1-2
ii  php-pubsubhubbub-publisher0~~20181009-2
ii  php-slim  3.12.4-1
ii  php8.2 [php]  8.2.7-1~deb12u1
ii  php8.2-cli [php-json] 8.2.7-1~deb12u1
ii  php8.2-curl [php-curl]8.2.7-1~deb12u1
ii  php8.2-fpm [php-json] 8.2.7-1~deb12u1
ii  php8.2-gd [php-gd]8.2.7-1~deb12u1
ii  php8.2-intl [php-intl]8.2.7-1~deb12u1
ii  php8.2-ldap [php-ldap]8.2.7-1~deb12u1
ii  php8.2-mbstring [php-mbstring]8.2.7-1~deb12u1

Versions of packages shaarli recommends:
ii  apache2 [httpd]  2.4.57-2

shaarli suggests no packages.

-- no debconf information

Bug#1034711:

[Boian Bonev]

Hi,

Making gpsd depend on python3-gps, will void all reasons for python3-gps to
exist as a separate package.

I'd rather separate ubxtool in gpsd-ubxtool, which in turn will depend on
python3-gps and gpsd will recommend gpsd-ubxtool.

What do you think?

--
With best regards,
b.


signature.asc
Description: This is a digitally signed message part

Bug#1043232: gimp-plugin-registry: Incompatible with gimp 3

[PaulLiu]

Hi Jeremy,

I think I'll keep this package to continue work with gimp3.
I'll test it very soon.
I still use one of the plugins very often.

Yours,
Paul



On Tue, Aug 8, 2023 at 2:24 AM Jeremy Bícha 
wrote:

> Source: gimp-plugin-registry
> Version: 9.20200928
> Severity: important
>
> gimp-plugin-registry is not compatible with gimp 2.99 which is
> currently in Debian Experimental. When the new version of gimp is
> uploaded to Unstable, this bug will be upgraded to Serious.
>
> Do you intend to keep this package around after gimp 3 is released? Or
> will it be removed from Debian?
>
> Thank you,
> Jeremy Bícha
>

Bug#1043258: texlive-latex-extra-doc: moderncv.tex fails to build

[Nick Hastings]

Package: texlive-latex-extra-doc
Version: 2022.20230122-4
Severity: normal
X-Debbugs-Cc: nicholaschasti...@gmail.com

Dear Maintainer,

I have been unable to build a document using moderncv.cls. It seems
that either the documentation of the immplementaion of moderncv.cls
has a problem. The /usr/share/doc/texlive-doc/latex/moderncv/README.md
indicates that the example should be compiled with: `latexmk -pdf 
./template.tex`
Following this documentation:

mkdir ~/tmp
cd tmp
zcat /usr/share/doc/texlive-doc/latex/moderncv/template.tex.gz > template.tex
cp /usr/share/doc/texlive-doc/latex/moderncv/picture.jpg .
latexmk -pdf template.tex 2>&1 | tee build.log

This results in the build hanging and the error:

.
.
.
*geometry* driver: auto-detecting
*geometry* detected driver: pdftex
(/usr/share/texmf/tex/latex/lm/ot1lmr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/microtype/mt-cmr.cfg)
(/usr/share/texmf/tex/latex/lm/omllmm.fd)
(/usr/share/texmf/tex/latex/lm/omslmsy.fd)
(/usr/share/texmf/tex/latex/lm/omxlmex.fd)
Underfull \hbox (badness 1) in paragraph at lines 93--93

! Missing number, treated as zero.
 
   }
l.95 \section{Education}

The build.log and template.log are attached.

Regards,

Nick.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-latex-extra-doc depends on:
ii  tex-common6.18
ii  texlive-base  2022.20230122-3

texlive-latex-extra-doc recommends no packages.

texlive-latex-extra-doc suggests no packages.

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.4

Versions of packages texlive-latex-extra-doc is related to:
ii  tex-common6.18
ii  texlive-binaries  2022.20220321.62855-5.1+deb12u1

-- no debconf information


build.log.gz
Description: application/gzip


template.log.gz
Description: application/gzip

Bug#1043256: man.local: missing font transformation for 'C'

[G. Branden Robinson]

X-Debbugs-CC: Bjarni Ingi Gislason 

In my opinion, this bug should be reassigned to the zip package.

Also, the correct term is "font translation", not "font transformation".

https://www.gnu.org/software/groff/manual/groff.html.node/Selecting-Fonts.html

At 2023-08-07T22:11:43+, Bjarni Ingi Gislason wrote:
> Package: man-db
> Version: 2.11.2-3
> Severity: normal
> 
> Dear Maintainer,
> man zip > /dev/null 
> 
>* What was the outcome of this action?
> 
> troff::175: warning: cannot select font 'C'
> ...

Can reproduce.  This warning occurs many times, along with two others.

troff:zip.1:1675: warning: cannot select font 'N'
troff:zip.1:2636: warning: escape character ignored before 'i'

These two appear to be due to typos.

>* What outcome did you expect instead?
> 
> No warnings.

These messages arise due to errors in the page sources; the formatter is
unable to do what is being asked of it.

> File "/etc/groff/man.local" needs a font transformation
> 
> .if n .ftr C R

Colin Watson rejected this idea when Python docutils-generated man pages
exhibited the same problem.  This issue has now been fixed upstream in
python-docutils--the right place, in my opinion--and uploaded to Debian.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041809

zip(1) appears to have been composed directly by a human.  The page is
(strictly speaking) buggy, and use of the `\fC` escape sequence is not
portable across *roff implementations.  It is also ineffectual on
terminal output devices regardless of implementation.

There are a number of related problems here.

* It's impossible to change font family or type size in an nroff
  document.  Nevertheless, it is attempted commonly enough that GNU
  troff (and all other troffs I know of) silently ignore such attempts.
* Not all troffs even support the _concept_ of "font families"; you will
  not find it in Ossanna troff or Kernighan troff.
* Portable man pages must use only fonts named `R`, `I`, and `B`.  It is
  consequently better to use man(7)'s facilities for switching fonts.
* Even on typesetting devices, a font named `C` is not guaranteed to
  exist.  As far as I can tell from my research over the years, this
  font name was never supported by the troff in BSD Unix until it
  replaced its AT troff with GNU troff.
* AT device-independent troff, in lines of descent from Kernighan
  troff (ca. 1980), _sometimes_ supported a font named `C`.  Sometimes
  it was called `CW` instead.  Sometimes both were available.  Sometimes
  it wasn't available at all.
* There is no portable interface for testing the availability of a font
  in the output device.  GNU troff supports `.if F` for this purpose;
  AT troff and at least some of its descendants do not.

It appears to me that in most or all cases, zip(1) uses this 'C' font
mark up literal input, like examples of command-line usage, on their own
output lines.  That's good, because it suggests that the page can easily
migrate to the EX/EE man(7) extension, first developed in Research Ninth
Edition Unix (1986) and adopted by groff in 2007-2009.

To retain portability, since Info-ZIP likely wants to retain support for
a huge variety of systems, the page could take the approach recently
adopted by lexgrog(1) in the man-db project.

It looks like the upstream package hasn't been updated in 15 years.  I'm
happy to prepare some patches to improve its man pages for the Debian
package.  It looks like most of the corrections relevant to this bug
report can be straightforwardly automated with sed(1).

I'm also happy to contribute some further correctness and portability
issues to the page per groff_man_style(7).

Let me know.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Trent W. Buck]

On Tue 13 Dec 2022 22:04:40 +0200, Damyan Ivanov wrote:
> The package is more or less ready at
>  (-high-dpi at
> , probably
> needs a bit more work).

FYI I had a go this morning and got a "clean room" version working with 
cmake+ninja, ignoring scons.
This seems to be consistent with what upstream docs currently recommend.

https://github.com/cyberitsolutions/bootstrap2020/tree/twb/debian-12-PrisonPC.packages/endless-sky/debian

I only got it working enough for me, so e.g. debian/copyright isn't set up 
properly.
It builds and installs and runs, though - I did the tutorial mission string as 
a test.

I did not get the tests working, because I think cmake+make was
starting $(nproc) separate instances of the game at once to do tests,
and my laptop kept OOMing.  I didn't go back after I switchde to cmake+ninja.

Looking at Damyan's version from last year,
I think the only novel/interesting thing in mine is the rules file.
The rest is pretty boring.
I also used upstream's current README text for Description, instead
of Michael's original description from 5+ years ago.


endless-sky_0.10.2-1~PrisonPC1.debian.tar.xz
Description: application/xz


endless-sky_0.10.2-1~PrisonPC1_amd64.build.xz
Description: application/xz
Format: 1.0
Source: endless-sky
Binary: endless-sky endless-sky-data
Architecture: all amd64 source
Version: 0.10.2-1~PrisonPC1
Checksums-Md5:
 0c4c33d4e5f6a34cf75eca6ce29ae4e5 1097 endless-sky_0.10.2-1~PrisonPC1.dsc
 6d563dcdb4cb3f37042844e1361925c0 241438272 
endless-sky-data_0.10.2-1~PrisonPC1_all.deb
 b25a4ee7116bfcf2f47a004fea2dfcd8 1556788 
endless-sky_0.10.2-1~PrisonPC1_amd64.deb
Checksums-Sha1:
 af3ac77f2ba6e593e7ae6c31a59dee26f63e7cd1 1097 
endless-sky_0.10.2-1~PrisonPC1.dsc
 dfd0bb8cd6fd0ad1387f5bccc820cdd8e8d05aa1 241438272 
endless-sky-data_0.10.2-1~PrisonPC1_all.deb
 25e3059720203be0bd8ba48278f4540ef801bb9d 1556788 
endless-sky_0.10.2-1~PrisonPC1_amd64.deb
Checksums-Sha256:
 d55f14608580506c69cb1f2601692ec7919192b36061b178c0633381ff9a6433 1097 
endless-sky_0.10.2-1~PrisonPC1.dsc
 56e50c354b18747a4cf5bd9d074b3402eabb836497bb831139ad55acb15efe9b 241438272 
endless-sky-data_0.10.2-1~PrisonPC1_all.deb
 d8acf681f605bb7a19f1071b24924327c332708e5131c22997b1b22b3b415931 1556788 
endless-sky_0.10.2-1~PrisonPC1_amd64.deb
Build-Origin: Debian
Build-Architecture: amd64
Build-Date: Mon, 07 Aug 2023 21:17:25 +
Build-Tainted-By:
 merged-usr-via-aliased-dirs
Installed-Build-Depends:
 autoconf (= 2.71-3),
 automake (= 1:1.16.5-1.3),
 autopoint (= 0.21-12),
 autotools-dev (= 20220109.1),
 base-files (= 12.4+deb12u1),
 base-passwd (= 3.6.1),
 bash (= 5.2.15-2+b2),
 binutils (= 2.40-2),
 binutils-common (= 2.40-2),
 binutils-x86-64-linux-gnu (= 2.40-2),
 bsdextrautils (= 2.38.1-5+b1),
 bsdutils (= 1:2.38.1-5+b1),
 build-essential (= 12.9),
 bzip2 (= 1.0.8-5+b1),
 cmake (= 3.25.1-1),
 cmake-data (= 3.25.1-1),
 coreutils (= 9.1-1),
 cpp (= 4:12.2.0-3),
 cpp-12 (= 12.2.0-14),
 dash (= 0.5.12-2),
 debconf (= 1.5.82),
 debhelper (= 13.11.4),
 debianutils (= 5.7-0.4),
 dh-autoreconf (= 20),
 dh-strip-nondeterminism (= 1.13.1-1),
 diffutils (= 1:3.8-4),
 dpkg (= 1.21.22),
 dpkg-dev (= 1.21.22),
 dwz (= 0.15-1),
 file (= 1:5.44-3),
 findutils (= 4.9.0-4),
 g++ (= 4:12.2.0-3),
 g++-12 (= 12.2.0-14),
 gcc (= 4:12.2.0-3),
 gcc-12 (= 12.2.0-14),
 gcc-12-base (= 12.2.0-14),
 gettext (= 0.21-12),
 gettext-base (= 0.21-12),
 gir1.2-glib-2.0 (= 1.74.0-3),
 gir1.2-ibus-1.0 (= 1.5.27-5),
 grep (= 3.8-5),
 groff-base (= 1.22.4-10),
 gzip (= 1.12-1),
 hostname (= 3.23+nmu1),
 init-system-helpers (= 1.65.2),
 intltool-debian (= 0.35.0+20060710.6),
 libacl1 (= 2.3.1-3),
 libarchive-zip-perl (= 1.68-1),
 libarchive13 (= 3.6.2-1),
 libasan8 (= 12.2.0-14),
 libasound2 (= 1.2.8-1+b1),
 libasound2-data (= 1.2.8-1),
 libasound2-dev (= 1.2.8-1+b1),
 libasyncns0 (= 0.8-6+b3),
 libatomic1 (= 12.2.0-14),
 libattr1 (= 1:2.5.1-4),
 libaudit-common (= 1:3.0.9-1),
 libaudit1 (= 1:3.0.9-1),
 libbinutils (= 2.40-2),
 libblkid-dev (= 2.38.1-5+b1),
 libblkid1 (= 2.38.1-5+b1),
 libbrotli1 (= 1.0.9-2+b6),
 libbsd0 (= 0.11.7-2),
 libbz2-1.0 (= 1.0.8-5+b1),
 libc-bin (= 2.36-9+deb12u1),
 libc-dev-bin (= 2.36-9+deb12u1),
 libc6 (= 2.36-9+deb12u1),
 libc6-dev (= 2.36-9+deb12u1),
 libcap-ng0 (= 0.8.3-1+b3),
 libcap2 (= 1:2.66-4),
 libcc1-0 (= 12.2.0-14),
 libcom-err2 (= 1.47.0-2),
 libcrypt-dev (= 1:4.4.33-2),
 libcrypt1 (= 1:4.4.33-2),
 libctf-nobfd0 (= 2.40-2),
 libctf0 (= 2.40-2),
 libcurl4 (= 7.88.1-10+deb12u1),
 libdb5.3 (= 5.3.28+dfsg2-1),
 libdbus-1-3 (= 1.14.8-2~deb12u1),
 libdbus-1-dev (= 1.14.8-2~deb12u1),
 libdebconfclient0 (= 0.270),
 libdebhelper-perl (= 13.11.4),
 libdecor-0-0 (= 0.1.1-2),
 libdecor-0-dev (= 0.1.1-2),
 libdpkg-perl (= 1.21.22),
 libdrm-amdgpu1 (= 2.4.114-1+b1),
 libdrm-common (= 2.4.114-1),
 libdrm-dev (= 2.4.114-1+b1),
 libdrm-intel1 (= 2.4.114-1+b1),
 libdrm-nouveau2 (= 2.4.114-1+b1),
 libdrm-radeon1 (= 

Bug#1043225: qt6-base: Please add patch to re-enable support for SuperH (sh4)

[Lisandro Damián Nicanor Pérez Meyer]

Hi again!

On Mon, 7 Aug 2023 at 21:19, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
>
> On Mon, 7 Aug 2023 at 12:45, John Paul Adrian Glaubitz
>  wrote:
> >
> > Source: qt6-base
> > Version: 6.4.2+dfsg-17
> > Severity: normal
> > User: debian-sup...@lists.debian.org
> > Usertags: sh4
> > X-Debbugs-Cc: debian-sup...@lists.debian.org
> >
> > Hello!
> >
> > For some reason, upstream disabled the platform detection for SuperH (sh4) 
> > in
> > src/corelib/global/qprocessordetection.h by simply commenting the 
> > corresponding
> > code out.
> >
> > As demanded by upstream in [1], I will provide a screenshot of Qt running 
> > on SH
> > later this week.
> >
> > Adrian
> >
> > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025823
>
> Yes please, and when you do please CCme, mention me (if you go trough
> a bug report) and/or add me as reviewer.

You are better off sending a patch that also set the byte order,
matching the patch you sent us here.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1043225: qt6-base: Please add patch to re-enable support for SuperH (sh4)

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 7 Aug 2023 at 12:45, John Paul Adrian Glaubitz
 wrote:
>
> Source: qt6-base
> Version: 6.4.2+dfsg-17
> Severity: normal
> User: debian-sup...@lists.debian.org
> Usertags: sh4
> X-Debbugs-Cc: debian-sup...@lists.debian.org
>
> Hello!
>
> For some reason, upstream disabled the platform detection for SuperH (sh4) in
> src/corelib/global/qprocessordetection.h by simply commenting the 
> corresponding
> code out.
>
> As demanded by upstream in [1], I will provide a screenshot of Qt running on 
> SH
> later this week.
>
> Adrian
>
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025823

Yes please, and when you do please CCme, mention me (if you go trough
a bug report) and/or add me as reviewer.

Bug#1043250: tzdata: bring back top-level UTC

[Thorsten Glaser]

Benjamin Drung dixit:

>Can you point to examples for it? Most of these cases should probably
>use TZ=UTC0 which work without having any timezone data files.

Except that tzif files contain more than DST info, such as the
name of the zone, but also leap second information (not in Debian
currently), which TZ=UTC0 would lose, therefore it’s not an option.

I’m using that heavily, for example.

>> A second candidate, although less used recently, is the top-level
>> GMT symlink.
>
>I haven't used GMT myself and I am not aware of any users. Do you know

Yeah, me either, I was guessing legacy scripts.

>codesearch.debian.net.

I’m much more concerned about scripts and other stuff that people
have locally on their systems, especially portable stuff, than
Debian package content here.

>Why isn't Etc/UTC an alternative to UTC?

It’s not as portable, it binds to the Olson database whereas
an otherwise unqualified UTC is pretty standard. Worse, if
Etc/UTC is not available, the fallback makes it assume Etc,
not UTC, as timezone name.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#563828:

[Cesar octavio Vega chacon]

Ese me sirve

Bug#698640: gvfs-bin: gfvs-trash can not trash on fs that is bind mounted

[Christian Pernegger]

Hi,

thanks for the detailed answer, I appreciate it!

I'm well aware this isn't a solution, but it's better than nothing,
and, more importantly, it restores the behaviour I am used to, warts
and all. I didn't mean to imply, apply this patch to the package, it's
just that while scratching my head and trying to find out why my trash
of all things wasn't working any more, I came across many confused
users. Maybe some will find this, and decide it's worth the trade-off.
It's not like Joe Newbie can patch and rebuild a package. ;)

I almost dare not admit it here, but I've been using Ubuntu 18.04 on
btrfs from about the day it released until last week. Nautilus, eog,
and friends would trash files just fine back in 2018, pretty much
wherever they were, and undo would work. I couldn't swear to the fact
that all the files in weird locations would show up in the trash GUI
now, maybe not, but, I mean, find the .Trash-1000 directory, find the
file. Ideal? No. Not standardised? Probably. But it's how it worked
for the longest time, for lots of users, and that makes it a de-facto
standard in my book.

Contrast with the new way, where trash simply won't work at all, for
files that are, from the user's perspective, seamlessly part of $HOME.
I mean, I know that this directory is actually the mount point for my
data drive, that that directory is really a subvolume--I set it up
that way, didn't I?--but it's not something I think about *using* the
box day-to-day. It shouldn't matter one bit.
Now every attempt to delete something throws up a warning dialogue.
Have you tried to go through a few hundred photos, weed out the bad
ones, like this? You know what this does? Train users to ignore
warning dialogues and/or delete everything with shift-del by default
...
That's way worse than not having a copy for "undelete" at all, even if
you have to hunt for it.

Never ever change how a piece of software behaves without a good
*practical* reason, never ever take functionality away without a
better replacement ready to go. Data loss bugs and/or critical
security vulnerabilities are a reason where it might be necessary to
yank functionality away as a last resort, the functionality being a
hack, the functionality not working perfectly in some circumstances,
the functionality not being in the spec, not so much.

Or look at it from the outside. A graphical desktop. Without working
trash. In 2023. It's absurd when you think about it.

As for deriving a trash path from any path deterministically, I only
see two options:
- Use one central trash directory (per user) for everything and live
with the fact that you'll have to do an expensive move sometimes
instead of a rename, deal with ENOSPC issues, etc.
- Prioritise that the trash should always be reachable via rename.

In the latter case I'd walk up the directory tree component by
component, starting from the directory the file to be deleted is in,
and check:
* whether rename would work here. If not, we've crossed (V)fs
boundaries; abort traversal and return the list of candidate dirs for
further consideration. In other words, if rename() can complain/fail
when trying to rename across subvolume boundaries or bind mounts,
there must be a way to test whether file-to-be-deleted and
prospective-trash-location are rename-compatible.
* whether .Trash-$UID exists. If yes, abort traversal. If it is a
directory and the user has the necessary permissions, designate it the
trash, otherwise disable trash (for the current operation).
* Add the current dir to the list of candidates and continue with the
parent dir.
---
* Now walk back down the list of candidate dirs, topmost to
bottommost. The first candidate dir that will let us create a
.Trash-$UID dir wins. If all candidates fail, disable trash (for the
current operation).

This should almost always give you a valid trash dir, considering the
file's directory (in which you can delete) will usually be a valid
candidate. No need to know about mount points or subvokumes at all. It
also allows some control over the behaviour. Don't want deleted files
from your project cluttering up the main trash, so you can delete it
separately? Make a .Trash-$UID dir in the project's root folder. Want
to disable trash somewhere? Make a trash dir and write-protect it.
Bonus: Will work on mounted network shares as-is.

Finding the trashes again ... Nothing to it but running something akin
to find / -type d -name .Trash-$UID whenever something or someone
wants to access the global trash. It's not that expensive, especially
if you cache the result.

This is the first thing that came to mind, so it's probably asinine,
but you did ask.

The point is, as a regular user, doing regular user thing with files
via the GUI, I expect trash to work everywhere I have write access to
in the first place. There's simply no need to exclude system fs paths
(except /proc and /sys and so on), because users can't write there,
and if they can, there's a reason. I'd disable it outright for 

Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends

[Scott Kitterman]

On Thu, 03 Aug 2023 23:52:10 -0400 Scott Kitterman  
wrote:
> Source: pdm
> Version: 2.2.1+ds1-1
> Severity: important
> 
> The python3-pep517 package has been replaced by python3-pyproject-hooks.
> Please update your package depends and build-depends (this may required
> a new upstream release - I did check and the current upstream release
> supports using pyproject-hooks).
> 
> Once I request removal, I'll raise the severity of this to serious.  I
> expect that by next week we'll be down to only two or three packages
> left that use pep517, so I'll probably request it then.  If you need
> more time to update this package, I can wait, please let me know.

RM has been requested (See #1043255).  Bumping to serious.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#1042965: py7zr: Remove unneeded build-depends on deprecate pep517

[Scott Kitterman]

On Thu, 03 Aug 2023 08:02:16 -0400 Scott Kitterman  
wrote:
> Source: py7zr
> Version: 0.11.3+dfsg-5
> Severity: important
> Tags: patch
> 
> The pep517 package has been superceded by python-pyproject-hooks.  It
> looks like this package added a build-depends on python3-pep517
> relatively early in our fielding of the ability to build Debian packages
> based on pyproject.toml.  This build dependency is no longer needed and
> can be simply removed.
> 
> I did test that the package built without it.  See the attached patch.
> I am happy to address this as a team upload if you would prefer.  I will
> soon be requesting removal of the pep517 package and I intend to bump
> the severity of this when I do if it's not resolved by then.

RM has been requested (See #1043255).  Bumping to serious.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#1043257: auctex: New upstream release 13.2

[Xiyue Deng]

Package: auctex
Version: 12.2-1
Severity: wishlist
X-Debbugs-Cc: none, Xiyue Deng 

Dear maintainers,

A new upstream release of auctex has been available for a while, and
I've prepared a (somewhat crude) merge request[1] with refreshed patches
which maybe useful as a base to work on.  There are still several
lintian warnings that I haven't figured out how to fix and will add new
commits once those are resolved.  PTAL.

Thanks in advance!

[1] https://salsa.debian.org/salve/auctex/-/merge_requests/2

-- Package-specific info:

Content of '/usr/share/auctex'

364d5de2337d7cb3a0f572f398d061a3  /usr/share/auctex/bib-cite.el
ab7fa94a4405b729aec22d88b9a8f7ee  /usr/share/auctex/context.el
9bec7c2dcf0179d8a4b7bf59e9398ca2  /usr/share/auctex/context-en.el
8667f268ce0eabaa7aa99fb961be71c1  /usr/share/auctex/context-nl.el
f1ea037263d610d7f15b92c79bd8cde6  /usr/share/auctex/font-latex.el
f176261b5a5511cbe1401ee72ffb8947  /usr/share/auctex/images/amstex.xpm
d33121019448617a3ad3bcafdeb8db40  /usr/share/auctex/images/bibtex.xpm
1a43d6438010bceb374ab0a5f2bd05a8  /usr/share/auctex/images/dropdown.xpm
41f1ae0341ae2e307d92a7b8b815f868  /usr/share/auctex/images/dvipdf.xpm
2e4b8669b0168f32247411be3f999437  /usr/share/auctex/images/dvips.xpm
55f7600cadc3a209e94bacf6bbc42a7c  /usr/share/auctex/images/error.xpm
79b958849511c67d6b13ef9f5b3673e8  /usr/share/auctex/images/execbibtex.xpm
a8570e26e9f96b6f527cdbe218d6c55f  /usr/share/auctex/images/execdvips.xpm
e647bc601aef2dc71b134a989df1adff  /usr/share/auctex/images/execerror.xpm
4610ec6133f89ceb441c43dfee077361  /usr/share/auctex/images/execpdftex.xpm
c9cd1fc9fe4fd122cbf900fae654a67b  /usr/share/auctex/images/exectex.xpm
6a6b9af945d4735f048ea8e475f8d9b8  /usr/share/auctex/images/execviewdvi.xpm
466466f6d1867510b058a9c184ffce5d  /usr/share/auctex/images/execviewpdf.xpm
39d8ccaffb40b0c118e000f45272db05  /usr/share/auctex/images/execviewps.xpm
c29ad797273fd27201a40bd939a95fe0  /usr/share/auctex/images/exec.xpm
6767e2583c668dcb47495197b9e8cb65  /usr/share/auctex/images/gv.xpm
ff9c61ef5148a0cacd5422d7c0d99396  /usr/share/auctex/images/jumpdvi.xpm
ece6608586b591f50f20d17cdb316a1c  /usr/share/auctex/images/ltx-symb-turn-off.xpm
b1f10de33dcf1b5ca9ac6155c13683a3  /usr/share/auctex/images/ltx-symb-turn-on.xpm
44e35faa18ab34f3c13ac3b0082bcc47  /usr/share/auctex/images/pdftex.xpm
84673eb20ac3be7bf0eb4e84e23e828f  /usr/share/auctex/images/prverr16.xpm
59e6a0dddb00ab16c4209a2e4c6e283d  /usr/share/auctex/images/prverr20.xpm
225929f8131bdd7b9b8207494a59619a  /usr/share/auctex/images/prverr24.xpm
e1b3c9d6a6eb6fb6f096736cdfc059cf  /usr/share/auctex/images/prvtex12.xpm
cc4101ee6a3ab6a1f4e9991b91b3ff0b  /usr/share/auctex/images/prvtex16.xpm
d4dbe057a8d3b2facd61cf7583c1e97c  /usr/share/auctex/images/prvtex20.xpm
28ac0855d853f606dd91e3cfacaa8a14  /usr/share/auctex/images/prvtex24.xpm
0dac3d8eb00c902037cc5fa6a03e53e3  /usr/share/auctex/images/prvtex-cap-up.xpm
6ce704103821329336489e990bc6f267  /usr/share/auctex/images/prvwrk12.xpm
5607f4e8bc0eb555206e6a3542205f45  /usr/share/auctex/images/prvwrk14.xpm
878a72cde3bb6f0ea6d586cff56e619c  /usr/share/auctex/images/prvwrk16.xpm
41811748a97673381115957d42a6529b  /usr/share/auctex/images/prvwrk20.xpm
9690511307f3693e6f28e4db93fdc58c  /usr/share/auctex/images/prvwrk24.xpm
e30a80ecb0711ceb42a2ca966ad74bbb  /usr/share/auctex/images/pspdf.xpm
5cc696e2c69ae401c0c223d84d013c8e  /usr/share/auctex/images/sep.xpm
e975868b87770a0e1a404292a314d246  /usr/share/auctex/images/spell.xpm
861fc288565e624ce8b34c1fc42e3496  /usr/share/auctex/images/tex.xpm
8147722e0061799437edf36d4466e5ab  /usr/share/auctex/images/viewdvi.xpm
67d7ed652615a027038610f8370ba172  /usr/share/auctex/images/viewpdf.xpm
000ba76725a4fb8489916250544310c7  /usr/share/auctex/images/viewps.xpm
338158cc358b16daf9b58ee54bd14bad  /usr/share/auctex/images/view.xpm
8e57849ce1b32fdc79f3af9a531f3c5f  /usr/share/auctex/latex.el
c80a148fe783337369442e6b7bc1e9a1  /usr/share/auctex/latex-flymake.el
33695ffcb286ad2f6d4a1c141afd5997  /usr/share/auctex/multi-prompt.el
bb4bd6f32da75c8abfb8b3ba2e4cb1a1  /usr/share/auctex/plain-tex.el
ad9fe893c52c9aa2dc8c58d2408060d1  /usr/share/auctex/preview.el
a4571ecde21c37163c25a2661be73f9e  /usr/share/auctex/prv-emacs.el
b2f7fec24beb1618ef9403ea480d8b24  /usr/share/auctex/style/acro.el
98172ba71dbfede787fbd8adce1fcf1a  /usr/share/auctex/style/acronym.el
6372c3c56c5fde251e63f5c712bceb5d  /usr/share/auctex/style/afterpage.el
9e97d5c15649144da8cf3c0c42325c56  /usr/share/auctex/style/Alegreya.el
5cf77acd7dded30324812467c9acad44  /usr/share/auctex/style/AlegreyaSans.el
06c93bf07caf76e6df0ed21184f8bc81  /usr/share/auctex/style/alltt.el
e1f6ad4e33c78d334be4758c8cf45a3a  /usr/share/auctex/style/alphanum.el
d7929d0be7ae2a95448c3c6331910b9c  /usr/share/auctex/style/amsart.el
ebc0470ca534d78dca178e4487cad5c0  /usr/share/auctex/style/amsbook.el

Bug#1042869: sniffles: Please update to newer version without python3-pep517 requirement

[Scott Kitterman]

On Tue, 01 Aug 2023 22:36:34 -0400 Scott Kitterman  
wrote:
> Source: sniffles
> Version: 2.0.7-1
> Severity: important
> 
> Currently sniffles build-depends on python3-pep517.  This package has
> been replaced upstream by python3-pyproject-hooks, which is now in
> Debian.  As a result, python3-pep517 will be removed soon.
> 
> There appears to be a newer version of sniffles that does not use
> python3-pep517 (I did not check if the current version acutally requires
> it of the the build-depend is unneeded).  Please upgrade to the newer
> version or otherwise remove the build-depends on python3-pep517.
> 
> Once I file the rm bug for it, I'll increase this to serious, so please
> address it now.

RM has been requested (See #1043255).  Bumping to serious.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#1043256: man.local: missing font transformation for 'C'

[Bjarni Ingi Gislason]

Package: man-db
Version: 2.11.2-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

man zip (run as root)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

with

export MANOPT=-E latin1 --no-hyphenation --no-justification --warnings=w
export MAN_KEEP_STDERR=yes

man zip > /dev/null 

   * What was the outcome of this action?

troff::175: warning: cannot select font 'C'
...

   * What outcome did you expect instead?

No warnings.

-.-.

File "/etc/groff/man.local" needs a font transformation

.if n .ftr C R

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-security')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.4-2 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages man-db depends on:
ii  bsdextrautils  2.39.1-3
ii  bsdmainutils   12.1.8
ii  debconf [debconf-2.0]  1.5.82
ii  groff-base 1.23.0-2
ii  libc6  2.37-6
ii  libgdbm6   1.23-3
ii  libpipeline1   1.5.7-1
ii  libseccomp22.5.4-1+b3
ii  zlib1g 1:1.2.13.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor   
ii  elinks [www-browser]   0.16.1.1-4
ii  firefox-esr [www-browser]  115.1.0esr-1
ii  groff  1.23.0-2
ii  less   590-2
ii  lynx [www-browser] 2.9.0dev.12-1
ii  w3m [www-browser]  0.5.3+git20230121-2

-- Configuration Files:
/etc/manpath.config changed [not included]

-- debconf information:
  man-db/auto-update: true
  man-db/install-setuid: false

Bug#1043255: RM: pep517 -- ROM; Obsolete, replaced by python-pyproject-hooks

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Python-pyproject-hooks has replaced pep517, so it should be removed once
there are no more reverse Build-Depends.  Most packages have been
updated and bugs have been filed for the three remaining.

Scott K

Bug#1043254: libsource-highlight-common: move src-hilite-lesspipe.sh to package source-highlight?

[Christoph Anton Mitterer]

Package: libsource-highlight-common
Version: 3.1.9-4.2
Severity: wishlist

Hey.

src-hilite-lesspipe.sh depends on the source-highlight binary,
which is however not part of libsource-highlight-common nor does
that depend on the package which contains it.

Perhaps src-hilite-lesspipe.sh should be better part of the
source-highlight package?!


Cheers,
Chris.

Bug#1043250: tzdata: bring back top-level UTC

[Benjamin Drung]

On Mon, 2023-08-07 at 23:20 +0200, Thorsten Glaser wrote:
> Package: tzdata
> Version: 2023c-8
> Severity: important
> X-Debbugs-Cc: t...@mirbsd.de
> 
> Please bring back at the *very* least the top-level UTC symlink,
> as TZ=UTC is used in *so* many places to get UTC it’s not funny.

Can you point to examples for it? Most of these cases should probably
use TZ=UTC0 which work without having any timezone data files.

Moving it back will be fine to unbreak those cases.

I searched for TZ=UTC on codesearch.debian.net and all hits that I
looked at were false positives for Python code that uses tz=utc (where
utc = datetime.UTC).

> A second candidate, although less used recently, is the top-level
> GMT symlink.

I haven't used GMT myself and I am not aware of any users. Do you know
packages that use/hardcode GMT? I haven't found TZ=GMT on
codesearch.debian.net.

> These are bound to be hardcoded in so many places, and Etc/UTC is
> *not* a substitute, nor is running that without the files (in some
> corner cases).

Why isn't Etc/UTC an alternative to UTC?

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty

[Philip Hands]

Steve McIntyre  writes:

> On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote:
>>Hi Michael,
>>
>>Cyril Brulebois  (2023-06-28):
>>> Control: reassign -1 busybox-udeb 1:1.36.1-3
>>
>>[…]
>>
>>> With a local build, confirmed -3 is buggy, and that reverting only
>>> busybox-udeb to -1 is sufficient to restore syslog support in the
>>> installer.
>>> 
>>> Reassigning there; the GRUB thing can be filed separately once we have
>>> actual information via syslog.
>>
>>A fix would be appreciated, we've got reports piling up about things we
>>have no logs for.
>
> After weeks with this breakage, I've just uploaded a minimal NMU to
> fix it, reverting the syslog changes since -1. I've buit and tested
> successfully locally.

Thanks -- and I agree, it works :-)

  https://openqa.debian.net/tests/178534/logfile?filename=DI_syslog.txt

As it happens, over the weekend it occurred to me that I might be able
to pave the way to a fix for this bug by coming up with a test for the
failure.

Awkwardly, syslogd wants to open /dev/log and bails out if it's already
in use, so I resorted to (the somewhat disgusting hack of) using podman:

   
https://salsa.debian.org/philh/busybox/-/commit/2697f7cce81d1a70de202a30e7062dc9f64a94b1

At least it allows syslogd to run well enough to succeed or fail
similarly to the behaviour seen in the bug.

Here it is going wrong with the -3 code:

  https://salsa.debian.org/philh/busybox/-/jobs/4523822#L3963
  (lines 3969-3975, with the last line showing the entire syslog)

and here is an example of it going right:

  https://salsa.debian.org/philh/busybox/-/jobs/4523808#L3668

  Line 3668 here, saying "PASS: syslogd-works" indicates that we
  succeeded in grepping the test string in /var/log/syslog

The difference between these two is simply disabling
CONFIG_FEATURE_REMOTE_LOG, as seen here:

  
https://salsa.debian.org/philh/busybox/-/commit/89c253f75690dd41487b6fd6f9356a1e890a6ac2

I'm not proposing that as a fix, but it does seem to indicate where the
problem may be located. I'm afraid I've failed to work out what's
actually going wrong here (my C's pretty rusty).

BTW At one point I thought I'd narrowed it down to the while loop here:

  
https://salsa.debian.org/philh/busybox/-/commit/328fdfbe43cd8d9e4425c3ee1c68aadfa44ee434

but if that did work, it does no longer. Either I was mistaken about it
having worked earlier (I'm at least 80% sure that's not the case) or
something non-deterministic is going on ... which makes me wonder if the
underlying cause might be something to do with using uninitialised data
somewhere.

Hopefully this will be of some use to those more familiar with the code.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1043253: tuxguitar: Missing java class ZipArchiveInputStream when opening .gp files

[Jérôme Lafréchoux]

Package: tuxguitar
Version: 1.5.6+dfsg1-6
Severity: normal

Dear Maintainer,

I get a missing java class error when opening .gp files.

I can open .gpx and .gp5 files but all .gp files fail with the following
error:

org.herac.tuxguitar.action.TGActionException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:35)
at 
org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24)
at 
org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67)
at 
org.herac.tuxguitar.app.action.impl.file.TGOpenFileAction$1$1.run(TGOpenFileAction.java:40)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.herac.tuxguitar.action.TGActionException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:48)
at 
org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24)
at 
org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67)
at 
org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:33)
... 4 more
Caused by: org.herac.tuxguitar.io.base.TGFileFormatException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:28)
at 
org.herac.tuxguitar.io.base.TGSongReaderHelper.read(TGSongReaderHelper.java:28)
at 
org.herac.tuxguitar.io.base.TGFileFormatManager.read(TGFileFormatManager.java:49)
at 
org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:40)
... 7 more
Caused by: java.lang.NoClassDefFoundError: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.io.gpx.v7.GPXFileSystem.getFileContentsAsStream(GPXFileSystem.java:39)
at 
org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:23)
... 10 more
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream
... 12 more
Exception in thread "Thread-51" org.herac.tuxguitar.action.TGActionException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:35)
at 
org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24)
at 
org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67)
at 
org.herac.tuxguitar.app.action.impl.file.TGOpenFileAction$1$1.run(TGOpenFileAction.java:40)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.herac.tuxguitar.action.TGActionException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:48)
at 
org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24)
at 
org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67)
at 
org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:33)
... 4 more
Caused by: org.herac.tuxguitar.io.base.TGFileFormatException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:28)
at 
org.herac.tuxguitar.io.base.TGSongReaderHelper.read(TGSongReaderHelper.java:28)
at 
org.herac.tuxguitar.io.base.TGFileFormatManager.read(TGFileFormatManager.java:49)
at 
org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:40)
... 7 more
Caused by: java.lang.NoClassDefFoundError: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.io.gpx.v7.GPXFileSystem.getFileContentsAsStream(GPXFileSystem.java:39)
at 
org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:23)
... 10 more
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream
... 12 more

From TuxGuitar, I can save as .gp3, .gp4 and .gp5 and then reopen, but I
can't open .gp files.

Here's a file that can be used to reproduce the error:
https://blog.guitar-pro.com/wp-content/uploads/2021/07/ACDC-The_Jack-2.gp

Thanks.

Jérôme



-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 

Bug#1043252: Ocaml 5.0.0

[Yuri D'Elia]

Package: ocaml
Version: 4.13.1-4
Severity: wishlist

Is there any plan to eventually package ocaml 5.0.0?

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ocaml-base depends on:
ii  libc6  2.37-7

ocaml-base recommends no packages.

ocaml-base suggests no packages.

Bug#1043251: fdisk: sfdisk output displays more partitions created than intended

[sz4eaa+4ui0l7mvepwv0]

Package: fdisk
Version: 2.38.1-5+b1
Severity: normal

Dear Maintainer,

This dumpfile defines 3 partitions to be created:

```
label: gpt
unit: sectors
first-lba: 2048
sector-size: 512

1: size=512MiB, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
2: size=512MiB, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
3: type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
```

Using sfdisk:
# sfdisk /dev/sdb >> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Created a new GPT disklabel (GUID: 21A415C2-8B45-9A40-B25E-4FBD0667FED4).
/dev/sdb1: Created a new partition 1 of type 'EFI System' and of size 10 MiB.
/dev/sdb2: Created a new partition 2 of type 'Linux filesystem' and of size 10 
MiB.
/dev/sdb3: Created a new partition 3 of type 'Linux filesystem' and of size 78 
MiB.
/dev/sdb4: Done.

New situation:
Disklabel type: gpt
Disk identifier: 21A415C2-8B45-9A40-B25E-4FBD0667FED4

Device StartEnd Sectors Size Type
/dev/sdb1   2048  22527   20480  10M EFI System
/dev/sdb2  22528  43007   20480  10M Linux filesystem
/dev/sdb3  43008 202751  159744  78M Linux filesystem

The partition table has been altered.
Syncing disks.
```

Notice this part:

```
/dev/sdb1: Created a new partition 1 of type 'EFI System' and of size 10 MiB.
/dev/sdb2: Created a new partition 2 of type 'Linux filesystem' and of size 10 
MiB.
/dev/sdb3: Created a new partition 3 of type 'Linux filesystem' and of size 78 
MiB.
/dev/sdb4: Done.
```

The /dev/sdb4 is not supposed to be there. It appears sfdisk is reusing the 
partition counter for line numbers.

If this is an upstream bug, please forward it on my behalf, I cannot github 
from where I live.

Thank you!

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fdisk depends on:
ii  libc6  2.36-9+deb12u1
ii  libfdisk1  2.38.1-5+b1
ii  libmount1  2.38.1-5+b1
ii  libncursesw6   6.4-4
ii  libreadline8   8.2-1.3
ii  libsmartcols1  2.38.1-5+b1
ii  libtinfo6  6.4-4

Versions of packages fdisk recommends:
ii  sensible-utils  0.0.17+nmu1

fdisk suggests no packages.

-- no debconf information

Bug#1043242: highlight: new upstream version

[Unit 193]

Howdy,

Actually at the time of this writing, 4.7 is the current release.  I had 
gone ahead and jumped to the latest version a while ago, mainly to unify 
my system on one Lua version, and I've attached the debdiff (debian/ only) 
to this message.


Use it, don't use it, or laugh at it.  I don't care about attribution so 
just claim it even if you want.


Note: The only place I use highlight is with cgit.


Regards,

~Unit 193
Unit193 @ Libera
Unit193 @ OFTCdiff -Nur highlight-3.41/debian/changelog highlight-4.7/debian/changelog
--- highlight-3.41/debian/changelog 2018-07-27 05:25:44.0 -0400
+++ highlight-4.7/debian/changelog  2023-08-07 17:21:57.862529038 -0400
@@ -1,3 +1,27 @@
+highlight (4.7-0) UNRELEASED; urgency=medium
+
+  * New upstream release.
+- Refresh patches.
+  * d/compat, d/control: Replace d/compat with debhelper-compat, bump to 13.
+  * d/control:
+- R³: no.
+- Replace Lua Build-Depend to liblua5.4-dev.
+  * d/docs: Update paths and drop TODO.
+  * d/highlight-common.install: Update paths and install plugins, completions.
+  * d/highlight.(examples,install): Update paths.
+  * d/libhighlight-perl.(examples,install): Ditto.
+  * d/highlight.manpages: Update name and add filetypes.conf.5.
+  * d/not-installed: Add otherwise installed and extraneous files.
+  * d/rules:
+- Drop get-orig-source target.
+- Override dh_installchangelogs to install ChangeLog.adoc.
+- Enable all hardening options.
+- Pass LUA_LIBS=-llua5.4.
+  * Update Standards-Version to 4.6.2.
+  * Remove trailing whitespace from previous changelog entries.
+
+ -- Unit 193   Thu, 03 Aug 2023 20:57:55 -0400
+
 highlight (3.41-2) unstable; urgency=medium
 
   * Fix location of examples (Closes: #904727).
@@ -171,7 +195,7 @@
 
   * New upstream version
 - restores @highlight pass-through
-
+
  -- David Bremner   Wed, 29 Dec 2010 16:16:12 -0400
 
 highlight (3.2+svn19-1) experimental; urgency=low
@@ -221,7 +245,7 @@
 
   * New Upstream 2.14
   * convert to 3.0 (quilt) source format to support tar.bz2 upstream
-  
+
  -- David Bremner   Mon, 15 Feb 2010 08:55:16 -0400
 
 highlight (2.12-1) unstable; urgency=low
@@ -236,7 +260,7 @@
   * New upstream version.
   * Change from co-maintainer/uploader to maintainer (Closes: #541332)
   * Update standards version to 3.8.3 (no changes)
-  
+
  -- David Bremner   Thu, 27 Aug 2009 22:45:19 -0300
 
 highlight (2.10-1) unstable; urgency=low
@@ -318,7 +342,7 @@
 
 highlight (2.2.6-2) unstable; urgency=low
 
-  * applied patch to fix amd64 building error using gcc-4.0 
+  * applied patch to fix amd64 building error using gcc-4.0
 Thanks to Andreas Jochens  (closes: #286352)
 
  -- Ayman Negm   Tue, 21 Dec 2004 21:09:35 +0100
@@ -386,5 +410,3 @@
   * Initial Release (closes: #218144).
 
  -- Ayman Negm   Fri,  20 Feb 2004 09:40:57 +0100
-
-  
diff -Nur highlight-3.41/debian/compat highlight-4.7/debian/compat
--- highlight-3.41/debian/compat2018-07-27 05:25:44.0 -0400
+++ highlight-4.7/debian/compat 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-10
diff -Nur highlight-3.41/debian/control highlight-4.7/debian/control
--- highlight-3.41/debian/control   2018-07-27 05:25:44.0 -0400
+++ highlight-4.7/debian/control2023-03-16 20:59:16.0 -0400
@@ -2,12 +2,13 @@
 Section: devel
 Priority: optional
 Maintainer: David Bremner 
-Build-Depends: debhelper (>= 10), swig, liblua5.2-dev, libboost-dev,
-  pkg-config
-Standards-Version: 4.0.0
+Build-Depends: debhelper-compat (= 13), swig, liblua5.4-dev, libboost-dev,
+   pkg-config
+Rules-Requires-Root: no
+Standards-Version: 4.6.2
 Homepage: http://www.andre-simon.de
 Vcs-Git: https://salsa.debian.org/bremner/highlight.git
-Vcs-Browser: https://salsa.debian.org/bremner/highlight.git
+Vcs-Browser: https://salsa.debian.org/bremner/highlight
 
 
 Package: highlight
@@ -23,7 +24,7 @@
 
 Package: highlight-common
 Architecture: all
-Depends:  ${misc:Depends}
+Depends: ${misc:Depends}
 Breaks: highlight (<<3.2), libhighlight-perl (<<3.2), gtk-doc-tools (<< 1.17-2)
 Replaces: highlight (<<2.9)
 Description: source code to formatted text converter (architecture independent 
files)
diff -Nur highlight-3.41/debian/docs highlight-4.7/debian/docs
--- highlight-3.41/debian/docs  2018-07-27 05:25:44.0 -0400
+++ highlight-4.7/debian/docs   2021-02-13 01:54:21.0 -0500
@@ -1,5 +1 @@
-README
-README_DE
-README_LANGLIST
-README_REGEX
-TODO
+usr/share/doc/highlight/README*
diff -Nur highlight-3.41/debian/highlight-common.install 
highlight-4.7/debian/highlight-common.install
--- highlight-3.41/debian/highlight-common.install  2018-07-27 
05:25:44.0 -0400
+++ highlight-4.7/debian/highlight-common.install   2022-10-15 
20:51:55.0 -0400
@@ -1,4 +1,7 @@
-usr/share/highlight/langDefs/* usr/share/highlight/langDefs
-etc/highlight/*etc/highlight

Bug#1043145: Upgraded ntpsec to 1.2.2+dfsg1-1+deb12u1: fewer servers remain

[Richard Laager]

The "pool" directive spins up more associations than it needs and then 
prunes them back (which takes a while).


https://docs.ntpsec.org/latest/quick.html#pool
https://docs.ntpsec.org/latest/discover.html#assoc

With 4 pool servers each returning 4 A records and one of them returning 
4  records, it seems to me you could end up with potentially 20 
servers initially, which will then be pruned back to 7 (per tos maxclock*).


* Note that tos maxclock is 11 in the Debian default, as pool entries 
themselves count. I personally think that's wrong, but changing it 
creates a compatibility concern.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043250: tzdata: bring back top-level UTC

[Thorsten Glaser]

Package: tzdata
Version: 2023c-8
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

Please bring back at the *very* least the top-level UTC symlink,
as TZ=UTC is used in *so* many places to get UTC it’s not funny.

A second candidate, although less used recently, is the top-level
GMT symlink.

These are bound to be hardcoded in so many places, and Etc/UTC is
*not* a substitute, nor is running that without the files (in some
corner cases).


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.82

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information:
* tzdata/Zones/Etc: UTC
* tzdata/Areas: Europe
  tzdata/Zones/Antarctica:
  tzdata/Zones/Arctic:
  tzdata/Zones/Australia:
  tzdata/Zones/US:
  tzdata/Zones/Pacific:
  tzdata/Zones/America:
  tzdata/Zones/Asia:
* tzdata/Zones/Europe: Berlin
  tzdata/Zones/SystemV:
  tzdata/Zones/Africa:
  tzdata/Zones/Atlantic:
  tzdata/Zones/Indian:

Bug#1043240: transition: pandas 1.5 -> 2.0

[Rebecca N. Palmer]

These packages appear to be broken *by* pandas 2.0 - I will file 
individual bugs when I have time:
augur cnvkit dask dials dyda emperor esda influxdb-python jsonpickle 
macsyfinder mirtop mlpack pyranges python-altair python-anndata 
python-biom-format python-feather-format python-nanoget python-pauvre 
python-pyani python-skbio python-ulmo python-upsetplot q2-cutadapt 
q2-demux q2-quality-control q2-taxa q2-types q2templates sklearn-pandas 
spyder-kernels


These packages have not been (fully) tested because they were already 
broken:

abinit python-cobra rdkit

Bug#965601: itop: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Bastian Germann]

I am uploading a NMU to fix this. The debdiff is attached.diff -Nru itop-0.1/debian/changelog itop-0.1/debian/changelog
--- itop-0.1/debian/changelog   2023-08-07 23:04:36.0 +0200
+++ itop-0.1/debian/changelog   2023-08-07 22:48:00.0 +0200
@@ -1,3 +1,13 @@
+itop (0.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove unavailable Homepage.
+  * Update debhelper to compat 10. (Closes: #965601)
+  * Split build target into build-{indep,arch}. (Closes: #999317)
+  * Convert to source format 3.0.
+
+ -- Bastian Germann   Mon, 07 Aug 2023 22:48:00 +0200
+
 itop (0.1-4) unstable; urgency=low
 
   * Removed debian/docs, hello Ubuntu! (Closes: #489956)
diff -Nru itop-0.1/debian/compat itop-0.1/debian/compat
--- itop-0.1/debian/compat  2023-08-07 23:04:36.0 +0200
+++ itop-0.1/debian/compat  1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-5
diff -Nru itop-0.1/debian/control itop-0.1/debian/control
--- itop-0.1/debian/control 2023-08-07 23:04:36.0 +0200
+++ itop-0.1/debian/control 2023-08-07 22:48:00.0 +0200
@@ -1,10 +1,9 @@
 Source: itop
 Section: admin
-Priority: extra
+Priority: optional
 Maintainer: Jose Parrella 
-Build-Depends: debhelper (>= 5)
+Build-Depends: debhelper-compat (= 10)
 Standards-Version: 3.8.0
-Homepage: http://www.hunz.org/
 
 Package: itop
 Architecture: any
diff -Nru itop-0.1/debian/patches/debian.patch 
itop-0.1/debian/patches/debian.patch
--- itop-0.1/debian/patches/debian.patch1970-01-01 01:00:00.0 
+0100
+++ itop-0.1/debian/patches/debian.patch2023-08-07 22:48:00.0 
+0200
@@ -0,0 +1,17 @@
+Description: Add a Makefile
+---
+--- /dev/null
 itop-0.1/Makefile
+@@ -0,0 +1,12 @@
++CC=gcc
++
++all: itop
++
++itop:
++  (cd src/ ; make)
++
++clean:
++  rm -f src/itop src/*.o src/*~
++
++install: itop
++  cp src/itop $(DESTDIR)/usr/bin
diff -Nru itop-0.1/debian/patches/max_ints.patch 
itop-0.1/debian/patches/max_ints.patch
--- itop-0.1/debian/patches/max_ints.patch  1970-01-01 01:00:00.0 
+0100
+++ itop-0.1/debian/patches/max_ints.patch  2023-08-07 22:48:00.0 
+0200
@@ -0,0 +1,9 @@
+Description: Increased MAX_INTS from 256 to 1024, thanks David Futcher
+Bug-Debian: https://bugs.debian.org/449246
+---
+--- itop-0.1.orig/src/config.h
 itop-0.1/src/config.h
+@@ -1,2 +1,2 @@
+ #define MAX_NAME_LEN 18
+-#define MAX_INTS 256
++#define MAX_INTS 1024
diff -Nru itop-0.1/debian/patches/series itop-0.1/debian/patches/series
--- itop-0.1/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ itop-0.1/debian/patches/series  2023-08-07 22:48:00.0 +0200
@@ -0,0 +1,2 @@
+debian.patch
+max_ints.patch
diff -Nru itop-0.1/debian/rules itop-0.1/debian/rules
--- itop-0.1/debian/rules   2023-08-07 23:04:36.0 +0200
+++ itop-0.1/debian/rules   2023-08-07 22:48:00.0 +0200
@@ -13,9 +13,9 @@
dh_testdir
touch configure-stamp
 
-build: build-stamp
+build: build-indep build-arch
 
-build-stamp: configure-stamp 
+build-arch: configure-stamp 
dh_testdir
$(MAKE)
touch $@
@@ -34,9 +34,9 @@
dh_installdirs
$(MAKE) DESTDIR=$(CURDIR)/debian/itop install
 
-binary-indep: build install
+binary-indep: build-indep install
 
-binary-arch: build install
+binary-arch: build-arch install
dh_testdir
dh_testroot
dh_installchangelogs CHANGELOG
@@ -53,5 +53,6 @@
dh_md5sums
dh_builddeb
 
+build-indep:
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+.PHONY: build build-indep clean binary-indep binary-arch binary install 
configure
diff -Nru itop-0.1/debian/source/format itop-0.1/debian/source/format
--- itop-0.1/debian/source/format   1970-01-01 01:00:00.0 +0100
+++ itop-0.1/debian/source/format   2023-08-07 22:48:00.0 +0200
@@ -0,0 +1 @@
+3.0 (quilt)
diff -Nru itop-0.1/debian/watch itop-0.1/debian/watch
--- itop-0.1/debian/watch   2023-08-07 23:04:36.0 +0200
+++ itop-0.1/debian/watch   1970-01-01 01:00:00.0 +0100
@@ -1,3 +0,0 @@
-version=3
-http://www.hunz.org/ itop/itop-(.*)\.tar\.bz2
-
diff -Nru itop-0.1/Makefile itop-0.1/Makefile
--- itop-0.1/Makefile   2023-08-07 23:04:36.0 +0200
+++ itop-0.1/Makefile   1970-01-01 01:00:00.0 +0100
@@ -1,12 +0,0 @@
-CC=gcc
-
-all: itop
-
-itop:
-   (cd src/ ; make)
-
-clean:
-   rm -f src/itop src/*.o src/*~
-
-install: itop
-   cp src/itop $(DESTDIR)/usr/bin
diff -Nru itop-0.1/src/config.h itop-0.1/src/config.h
--- itop-0.1/src/config.h   2023-08-07 23:04:36.0 +0200
+++ itop-0.1/src/config.h   2001-08-26 15:55:05.0 +0200
@@ -1,2 +1,2 @@
 #define MAX_NAME_LEN 18
-#define MAX_INTS 1024
+#define MAX_INTS 256

Bug#205702: lesspipe: Please consider using a more powerful version

[Christoph Anton Mitterer]

Hey.

Just for the records:
I've filed an RFP[0] for the lesspipe alternative from:
  https://github.com/wofr06/lesspipe
respectively
  https://www-zeuthen.desy.de/~friebel/unix/lesspipe.html
which, AFAICS, is also the one used in gentoo.


Should it get packaged, than maybe both could simply happily coexist
(and this bug would still become obsolete). :D


Cheers,
Chris.


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043249

Bug#1043243: libc-bin: locale displayed as .utf8 instead of the correct .UTF-8

[Aurelien Jarno]

control: severity -1 minor

Hi,

On 2023-08-07 20:22, sz4a6w+m7urcelry0i4@cs.email wrote:
> Package: libc-bin
> Version: 2.36-9+deb12u1
> Severity: normal
> 
> Dear Maintainer,
> 
> When I run `locale -a` I get output such as:
> 
> C
> C.utf8
> POSIX
> en_US.utf8
> 
> However, the correct names of the UTF-8 locales are supposed to be hyphenated 
> according to the standard, and uppercase according to convention:
> C.UTF-8
> en_US.UTF-8
> 
> Musl (alpine linux) shows the locales correctly.
> 
> The canonical UTF-8 is preferable to the utf8 synonym (if it can be called a 
> synonym, utf8 is not defined by IANA). It is especially important that the 
> C.UTF-8 locale contains the hyphen.
> 
> If you wish to see what the canonical character encoding is for a locale, you 
> can run for any locale `LC_ALL=en_US.utf8 locale charmap` and it will output 
> UTF-8.
> 
> A lot of additional information can be found here:
> https://unix.stackexchange.com/questions/605770/is-the-utf8-in-en-us-utf8-a-canonical-character-set/605777#605777
> 
> that post explains what glibc is doing and why it is incorrect in doing that.

This is purely an upstream issue, and for keeping consistency across
distributions, Debian will not change the output of 'locale -a' without
an upstream change.

Therefore the best is to report the bug upstream [1], so that you can
also provide answers directly. Please mention the bug number here so
that we can track the issue. Thanks.

Regards
Aurelien

[1] https://sourceware.org/bugzilla/

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#995947: less: miscellaneous improvements

[Christoph Anton Mitterer]

Hey Milan.

Have you already had a change to look at my "pull requests"?
https://salsa.debian.org/calestyo-guest/less/-/tree/misc-improvements
(Would love to see RPMs readable without having to install rpm. :-D)


And perhaps also at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988570



btw:
http://www-zeuthen.desy.de/~friebel/unix/lesspipe.html
respectively https://github.com/wofr06/lesspipe

might be an alternative which adds many nice features (e.g. syntax
highlighting, actually checking the file type).

I've filed RFP #1043249, should it get packaged, than maybe lesspipe
could suggest/recommend it as an alternative.


Thanks,
Chris.

Bug#1043138: thunderbird: cannot send OpenPGP signed message: rnp_op_sign_add_signature failed since upgrade to 115.1.0 (sid)

[Jamie McClelland]

On 8/7/23 11:46, Carsten Schoenert wrote:

Hello Jamie,

I can't reproduce this issue.


Thank you for the support and sorry to waste your time.

I think the problem is that I didn't have a Primary password set. I set 
a primary password, then re-imported my secret key and now it seems to work.


jamie



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1043249: RFP: lesspipe -- a preprocessor for less

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist

* Package name: lesspipe
  Version : 2.08
  Upstream Contact: Wolfgang Friebel 
* URL : https://github.com/wofr06/lesspipe
* License : GPL2
  Programming Lang: Shell
  Description : a preprocessor for less

https://github.com/wofr06/lesspipe
and
https://www-zeuthen.desy.de/~friebel/unix/lesspipe.html


Not a 1:1 package description: ;-)
It's similar to the lesspipe shipped by Debian's less package, but seems to
provide a number of interesting additional features:
- uses file to determine the file's type (i.e. not extension based), which 
solves
  a number of bugs/issues in Debian's current lesspipe (in the less package).
- syntax highlighting via fall back to some colourisers (currently:
  bat batcat pygmentize source-highlight vimcolor code2color)
- apart from that, support for numerous file types:
gzip, compress requires gzip
bzip2 requires bzip2
lzma requires lzma
xz requires xz
zstd requires zstd
brotli requires bro
lz4 requires lz4
tar requires optionally archive_color for coloring
ar library requires bsdtar or ar
zip archive requires bsdtar or unzip
jar archive requires bsdtar or unzip
rar archive requires bsdtar or unrar or rar`
7-zip archive requires 7zr
lzip archive requires lzip
iso images requires bsdtar or isoinfo
rpm requires rpm2cpio and cpio or bsdtar
Debian requires bsdtar or ar
cab requires cabextract
- preprocessed file types
directory displayed using ls -lA
nroff(man) requires groff or mandoc
shared library requires nm
MS Word (doc) requires wvText or antiword or catdoc or libreoffice
Powerpoint (ppt) requires catppt
Excel (xls) requires in2csv (csvkit) or xls2csv
odt requires pandoc or odt2txt or libreoffice
odp requires libreoffice
ods requires xlscat or libreoffice
MS Word (docx) requires pandoc or docx2txt or libreoffice
Powerpoint (pptx) requires pptx2md or libreoffice
Excel (xlsx) requires in2csv or xlscat or excel2csv or libreoffice
rtf requires unrtf or libreoffice
epub requires pandoc
html,xml requires w3m or lynx or elinks or html2text
pdf requires pdftotext or pdftohtml
perl pod requires pod2text or perldoc
dvi requires dvi2tty
djvu requires djvutxt
ps requires ps2ascii (from the gs package)
mp3 requires id3v2
multimedia formats requires mediainfo or exiftools
image formats requires mediainfo or exiftools or identify
hdf, nc4 requires h5dump or ncdump (NetCDF format)
crt, pem, csr, crl requires openssl
matlab requires matdump
Jupyter notebook requires pandoc
markdown requires mdcat or pandoc
log requires ccze
java.class requires procyon
MacOS X plist requires plistutil
binary data requires strings
json requires jq
Device Tree Blobs(DTB) requires dtc


Cheers,
Chris.

Bug#1042482: multilib lsan packages: dysfunctional?

[Helmut Grohne]

Control: clone -1 -2
Control: retitle -2 gcc-13: missing debhelper dependency for cross toolchain 
builds
Control: tags -2 =
Control: severity -2 normal

Hi Matthias,

On Sun, Jul 30, 2023 at 09:40:35PM +0200, Helmut Grohne wrote:
> On Sun, Jul 30, 2023 at 07:10:09AM +0200, Matthias Klose wrote:
> > see src/libsanitizer/configure.tgt, it's unsupported, the empty packages
> > don't hurt. Feel free to send a patch not to build these packages, tested
> > please for amd64 and i386 builds, plus cross builds targeting these
> > architectures.
> 
> Thank you for pointing there. A key insight there is that lsan does not
> work for 32bit architectures at all. Therefore, we can entirely remove
> the 32bit lsan multilib packages. Surprisingly, the lib64lsan0 package
> is already commented, so we don't have to consider that. I've
> implemented the requested change and performed a local native build on
> amd64. I've also performed the requested i386 build (though lintian
> OOMed there). I've not performed cross builds since we know that those
> are broken.

You privately clarified that you meant cross toolchain builds (build =
host != target) rather than cross builds (build != host = target).

I also attempted building a cross toolchain for i386 on amd64. Such
builds fail, because Build-Depends lack debhelper and therefore dh_clean
fails. DEBHELPER_BUILD_DEP is never set when DEB_CROSS equals yes and
therefore no debhelper dependency is emitted. This failure is unrelated
to my patch. Therefore, my patch does not regress this aspect.

> Do you need any artifacts? .debs? build logs? I think the patch is
> pretty straight forward.

Is there anything else you need?

Helmut

Bug#1043247: openjdk-21-jdk-headless fails foreign installation during ca-certificates-java.postinst

[Helmut Grohne]

Package: openjdk-21-jdk-headless,ca-certificates-java
Severity: normal
Control: affects -1 + src:openjdk-21
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian-cr...@lists.debian.org

Hi Matthias,

this is a little difficult and I don't see how this is supposed to work,
which is why this bug unfortunately comes without a patch. Can I ask you
to shed some light on how this is supposed to work?

openjdk-21 cannot be cross built at the moment. Its Build-Depends are
theoretically satisfiable, but since it also Build-Depends on
"openjdk-21-jdk-headless ", we need to install the foreign
development kit. Do you confirm that this is really needed? It also has
"openjdk-20-jdk-headless:native | openjdk-21-jdk-headless:native" and I
am wondering whether the native jdk would be sufficient.

Anyway, installing a foreign openjdk-21-jdk-headless fails. The easiest
way to see that is using mmdebstrap:

$ mmdebstrap --variant=essential --architectures=amd64,ppc64el 
--include=openjdk-21-jdk-headless:ppc64el unstable /dev/null
...
Processing triggers for ca-certificates-java (20230710) ...
/var/lib/dpkg/info/ca-certificates-java.postinst: 115: java: Exec format error
dpkg: error processing package ca-certificates-java (--configure):
 installed ca-certificates-java package post-installation script subprocess 
returned error exit status 126
...
$

As you can see, that foreign openjdk-21-jdk-headless ends up providing
the java executable an ca-certificates-java assumes it to be executable,
which it is not and thus ca-certificates-java.postinst fails.

If also installing openjdk-21-jdk-headless:amd64, then it ends up
providing the java name and ca-certificates-java.postinst works. I am
not sure which of the packages is at fault here.

Arguably, ca-certificates-java should be depending on a runnable
instance of the jdk, but I don't know how it would express that. Then
maybe default-jre-headless should provide a working java executable for
the native architecture? Or maybe openjdk-21 should also be depending on
the native jdk like this?

Build-Depends: openjdk-20-jdk-headless:native  | 
openjdk-21-jdk-headless:native , openjdk-21-jdk-headless:native 

Note that using this approach, we really must duplicate the dependency,
because the alternative is dropped too early.

Hope this makes sense to you

Helmut

Bug#1043246: libdbus-c++-glib-1-0/experimental: undeclared file conflict with libdbus-c++-1-0v5/unsable

[Helmut Grohne]

Package: libdbus-c++-glib-1-0
Version: 0.9.0-13
Severity: serious
Control: affects -1 + libdbus-c++-1-0v5
User: debian...@lists.debian.org
Usertags: fileconflict

Both libdbus-c++-glib-1-0/experimental and libdbus-c++-1-0v5/unstable
contain the files /usr/lib/x86_64-linux-gnu/libdbus-c++-glib-1.so.0 and
/usr/lib/x86_64-linux-gnu/libdbus-c++-glib-1.so.0.0.0 without resolving
this conflict via Conflicts, Replaces or diversions. This may result in
an unpack error from dpkg and is a serious issue.

I guess that you meant to restructure the library and that these files
are supposed to be moved between packages. In this case, please add
Breaks and Replaces declarations for libdbus-c++-1-0v5 to
libdbus-c++-glib-1-0.

Helmut

Bug#1043245: libdbus-c++-ecore-1-0/experimental: undeclared file conflict with libdbus-c++-1-0v5/unsable

[Helmut Grohne]

Package: libdbus-c++-ecore-1-0
Version: 0.9.0-13
Severity: serious
Control: affects -1 + libdbus-c++-1-0v5
User: debian...@lists.debian.org
Usertags: fileconflict

Both libdbus-c++-ecore-1-0/experimental and libdbus-c++-1-0v5/unstable
contain the files /usr/lib/x86_64-linux-gnu/libdbus-c++-ecore-1.so.0 and
/usr/lib/x86_64-linux-gnu/libdbus-c++-ecore-1.so.0.0.0 without resolving
this conflict via Conflicts, Replaces or diversions. This may result in
an unpack error from dpkg and is a serious issue.

I guess that you meant to restructure the library and that these files
are supposed to be moved between packages. In this case, please add
Breaks and Replaces declarations for libdbus-c++-1-0v5 to
libdbus-c++-ecore-1-0.

Helmut

Bug#1043244: libflatbuffers-dev/experimental: undeclared file conflict with libflatbuffers2/trixie

[Helmut Grohne]

Package: libflatbuffers-dev
Version: 23.5.26+dfsg-1~exp0
Severity: serious
Control: affects -1 + libflatbuffers2
User: debian...@lists.debian.org
Usertags: fileconflict

libflatbuffers-dev/experimental and libflatbuffers2/trixie both contain
/usr/lib/x86_64-linux-gnu/pkgconfig/flatbuffers.pc. Since this conflict
is not addressed with Conflicts, Replaces or diversions, an unpack error
may result. This is a serious bug.

I guess that you meant to restructure the package and move the file from
libflatbuffers2 to libflatbuffers-dev. If this is accurate, please add
versioned Breaks and Replaces for libflatbuffers2 to libflatbuffers-dev.

Helmut

Bug#1043243: libc-bin: locale displayed as .utf8 instead of the correct .UTF-8

[sz4a6w+m7urcelry0i4]

Package: libc-bin
Version: 2.36-9+deb12u1
Severity: normal

Dear Maintainer,

When I run `locale -a` I get output such as:

C
C.utf8
POSIX
en_US.utf8

However, the correct names of the UTF-8 locales are supposed to be hyphenated 
according to the standard, and uppercase according to convention:
C.UTF-8
en_US.UTF-8

Musl (alpine linux) shows the locales correctly.

The canonical UTF-8 is preferable to the utf8 synonym (if it can be called a 
synonym, utf8 is not defined by IANA). It is especially important that the 
C.UTF-8 locale contains the hyphen.

If you wish to see what the canonical character encoding is for a locale, you 
can run for any locale `LC_ALL=en_US.utf8 locale charmap` and it will output 
UTF-8.

A lot of additional information can be found here:
https://unix.stackexchange.com/questions/605770/is-the-utf8-in-en-us-utf8-a-canonical-character-set/605777#605777

that post explains what glibc is doing and why it is incorrect in doing that.


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc-bin depends on:
ii  libc6  2.36-9+deb12u1

Versions of packages libc-bin recommends:
ii  manpages  6.03-2

libc-bin suggests no packages.

-- no debconf information

Bug#1042947: UDD: create a duck importer

[Baptiste Beauplat]

Hi Lucas,

On 2023-08-03 10:30, Lucas Nussbaum wrote:
> duck-as-a-service (duck.debian.net) has been broken for a long time,
> and
> the corresponding UDD importer is broken as well (see #949009,
> #963887).
> In the meantime, duck continued evolving (was rewritten?) and is now
> checking a lot more places for URLs.
> 
> It would probably be useful to re-create a way to provide duck
> results
> as a service, based on UDD, similarly to what is done for upstream or
> lintian data.
> 
> Ideally, this would be done in cooperation with the duck maintainer
> to
> do the following changes:
> - in duck, separate the logic to get URLs from sources, from the
> logic
>   to check those URLs (for example, allow dumping a list of URLs, and
>   also using a list of URLs as source)
> - in duck, provide machine-readable outputs (JSON?)

Currently duck has two features which can help us:

- The `-n` switch, which gets all URLs and prints them to stdout
- The `-l filename` switch, which takes a file with one URL per line
and checks them

Theoretically, what's missing in only a `--json` switch, which would
change the output from console/text to JSON.

But, as I see it, the `-l` argument is limited in two aspects:

- It provides only the URL, loosing the checker type which is used to
select what kind of validation will be performed.

  For instance, a https://salsa.debian.org/rfrancoise/tmux.git of type
VCS-Git would be tested as a standard URL in the `-l` context, instead
of a git repository.

- It requires a file

I'm thinking of implementing a new JSON specific input format
(`--input-json`?), including the two information, which would read from
stdout instead of a file.

The format would be as simple as:

```json
[
   {"type": "VCS-Git",
    "url": "https://salsa.debian.org/rfrancoise/tmux.git;,
    "filename": "debian/control",  # optional key
    "line_number": 10},    # optional key
   ...
]
```

Following this logic, the output format for checking URLs would be the
same, as to have `duck --json -n | duck --input-json` working.

The JSON result would hold an additional dictionary for each URL
entries
named "result", described as follows:

```json
[
   {"type": "VCS-Git",
    "url": "https://salsa.debian.org/rfrancoise/tmux.git;,
    "filename": "debian/control",  # optional key
    "line_number": 10, # optional key
    "result": {
   "state": 0,  # 0 for OK, 1 for Error, 2 for Information
   "detail": "Informative message",
   "certainty": "possible" # optional key
   }},
   ...
]
```

Let me know what you think of it.

> Then UDD could process source packages to extract URLs, check those
> URLs
> on a regular basis (similarly to what is done for lintian), and
> publish/export the results in all relevant places.

Best,
-- 
Baptiste Beauplat



signature.asc
Description: This is a digitally signed message part

Bug#1043242: highlight: new upstream version

[Christoph Anton Mitterer]

Package: highlight
Version: 3.41-2+b6
Severity: wishlist


Hey.

3.41 seems quite old (5 years ago?)... 4.4 is the most recent version as of now 
:-)

Cheers,
Chris.

Bug#1043237: Info received (Bug#1043237: Acknowledgement (RFP: libauthen-sasl-scram-perl -- SCRAM-SHA-1/256/512 support for Perl library Authen::SASL))

[Erik Huelsmann]

Control: close

Bug#1043237: Acknowledgement (RFP: libauthen-sasl-scram-perl -- SCRAM-SHA-1/256/512 support for Perl library Authen::SASL)

[Erik Huelsmann]

close

Bug#1043241: please support non-emulated RPMB

[dann frazier]

Source: optee-client
Version: 3.21.0-1
Severity: wishlist

tee-supplicant can be configured at build-time to either use a real RPMB
or to emulate one. The default is to emulate one, and that appears
to be what the Debian binary does today. Please provide support for using
a real RPMB.

Bug#1043238: libpfm4: crashes on initialization on 32bit arm in autopkgtest CI

[Samuel Thibault]

Control: forwarded -1 
https://sourceforge.net/p/perfmon2/libpfm4/merge-requests/23/

Samuel Thibault, le lun. 07 août 2023 21:29:03 +0200, a ecrit:
> It seems that it is crashing because /proc/cpuinfo is empty, and thus
> pfmlib_getl never allocates a buffer, and the trailing b[i] = '\0' thus
> becomes bogus. The attached patch fixes this in my tests.

I have forwarded it to upstream:

https://sourceforge.net/p/perfmon2/libpfm4/merge-requests/23/

Samuel

Bug#1043240: transition: pandas 1.5 -> 2.0

[Rebecca N. Palmer]

Package: python3-pandas
Version: 1.5.3+dfsg-4
Severity: wishlist
Control: block -1 by 1043093

pandas 2.0 is now in experimental.  However (as you might expect from 
that version number), it breaks around 40 other packages, and it is 
hence likely to be some time before it moves to unstable.


Upstream release notes:
https://pandas.pydata.org/docs/whatsnew/v2.0.0.html#backwards-incompatible-api-changes

Build test results:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p0/+packages

Autopkgtest results:
https://qa.debian.org/excuses.php?experimental=1=pandas

These packages have not been (fully) tested because they build- or 
test-depend on dask, which is already known to break (#1043093):
dask.distributed extra-data flox intake pint-xarray python-cooler 
python-geotiepoints python-streamz python-xarray sunpy xarray-safe-s1 
xarray-sentinel


These packages have not been build-tested because they do not exist in 
Ubuntu (probably because they were broken already, as none of them are 
in Debian testing either):

epigrass keras pynwb tpot

Bug#1043239: lemonldap-ng: FTBFS with Perl 5.38: test failures

[Niko Tyni]

Source: lemonldap-ng
Version: 2.16.1+ds-2
Severity: important
Tags: ftbfs trixie sid
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition

This package fails to build from source with Perl 5.38 (currently in 
experimental.)

  
http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/lemonldap-ng_2.16.1+ds-2/lemonldap-ng_2.16.1+ds-2_amd64-2023-08-04T06:12:12Z.build

   #   Failed test 'Found correct error message'
   #   at t/12-Lemonldap-NG-Handler-Jail.t line 114.
   #   'syntax error at (eval 52) line 1, at EOF
   # Execution of (eval 52) aborted due to compilation errors.
   # '
   # doesn't match '(?^:Missing right curly or square bracket)'
   # Looks like you failed 1 test of 22.
   
   #   Failed test 'Found correct error message'
   #   at t/13-Lemonldap-NG-Handler-Fake-Safe.t line 107.
   #   'syntax error at (eval 47) line 1, at EOF
   # Execution of (eval 47) aborted due to compilation errors.
   # '
   # doesn't match '(?^:Missing right curly or square bracket)'
   # Looks like you failed 1 test of 16.
   
   Test Summary Report
   ---
   t/12-Lemonldap-NG-Handler-Jail.t (Wstat: 256 (exited 
1) Tests: 22 Failed: 1)
 Failed test:  22
 Non-zero exit status: 1
   t/13-Lemonldap-NG-Handler-Fake-Safe.t(Wstat: 256 (exited 
1) Tests: 16 Failed: 1)
 Failed test:  16
 Non-zero exit status: 1
   Files=25, Tests=405,  7 wallclock secs ( 0.08 usr  0.03 sys +  4.03 cusr  
0.70 csys =  4.84 CPU)
   Result: FAIL
 
This looks like just an issue of changed diagnostics, but please don't
hesitate to file a bug against perl in case it turns out to have runtime
effects that warrant a Breaks entry.

-- 
Niko Tyni   nt...@debian.org

Bug#1040659: libtest-strict-perl: FTBFS with Perl 5.38: test failures

[Niko Tyni]

Control: tag -1 patch

On Sat, Jul 08, 2023 at 08:47:21PM +0300, Niko Tyni wrote:
> Source: libtest-strict-perl
> Version: 0.52-2
> Severity: important
> Tags: ftbfs trixie sid
> Forwarded: https://github.com/manwar/Test-Strict/issues/32
> User: debian-p...@lists.debian.org
> Usertags: perl-5.38-transition
> 
> This package fails to build with Perl 5.38 (currently in experimental).
> 
>#   Failed test 'Syntax check /tmp/RsMORA8Sdy/G9eCGgt__c.pl'
>#   at /<>/blib/lib/Test/Strict.pm line 435.

> The upstream ticket suggests a fix of separating runs with the -v and
> -c switches.

There's a patch at https://github.com/manwar/Test-Strict/pull/33
-- 
Niko Tyni   nt...@debian.org

Bug#1043238: libpfm4: crashes on initialization on 32bit arm in autopkgtest CI

[Samuel Thibault]

Package: libpfm4
Version: 4.13.0-1
Severity: important
Tags: patch

Hello,

We are seeing a crash at libpfm initialization in the starpu autopkgtest
CI testsuite. This can be easily reproduced in the autopkgtest CI
environment with:

#include 

int main(void) {
pfm_initialize();
}

gcc test.c -o test -lpfm



(gdb) r
Starting program: /root/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xf7f8f4e0 in pfmlib_getl (buffer=buffer@entry=0xfffefab0,
len=len@entry=0xfffefaac, fp=fp@entry=0x403190) at pfmlib_common.c:794
 794b[i] = '\0';
(gdb) bt
#0  0xf7f8f4e0 in pfmlib_getl (buffer=buffer@entry=0xfffefab0,
len=len@entry=0xfffefaac, fp=fp@entry=0x403190) at pfmlib_common.c:794
#1  0xf7f94124 in pfmlib_getcpuinfo_attr (attr=0xf7f977fc "CPU implementer",
ret_buf=0xf7f94124  "\020\260\235\345\001",
ret_buf@entry=0xfffefae4 "\304\373\376\367\001", maxlen=128)
at pfmlib_arm.c:78
#2  0xf7f94240 in pfm_arm_detect (this=) at pfmlib_arm.c:156
#3  0xf7f94980 in pfm_arm_detect_cortex_a7 (this=)
at pfmlib_arm_armv7_pmuv1.c:48
#4  0xf7f8fbf4 in pfmlib_init_pmus () at pfmlib_common.c:1139
#5  pfm_initialize () at pfmlib_common.c:1239
#6  0x00400588 in main ()

(gdb) bt full
#0  0xf7f8f4e0 in pfmlib_getl (buffer=buffer@entry=0xfffefac0,
len=len@entry=0xfffefabc, fp=fp@entry=0x403190) at pfmlib_common.c:794
b = 0x0
c = 
maxsz = 0
maxi = 4294967294
d = 
i = 0
#1  0xf7f94124 in pfmlib_getcpuinfo_attr (attr=0xf7f977fc "CPU implementer",
ret_buf=0xf7f94124  "\020\260\235\345\001",
ret_buf@entry=0xfffefaf4 "\304\373\376\367\001", maxlen=128)
at pfmlib_arm.c:78
fp = 0x403190
ret = -1
attr_len = 15
buf_len = 0
p = 
value = 
buffer = 0x0
#2  0xf7f94240 in pfm_arm_detect (this=) at pfmlib_arm.c:156
ret = 
buffer = 
"\304\373\376\367\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000X\372\376\367\000\000\000\000\360#\374\367(\374\376\3678\360\376\367",
 '\000' , "\377\377\377\377HE\370\367\360#\374\367", '\000' 
, 
"X\372\376\367\001\377\376\377p\375\376\377LI\000\000x\322\343\367\300\242\373",
 
#3  0xf7f94980 in pfm_arm_detect_cortex_a7 (this=)
at pfmlib_arm_armv7_pmuv1.c:48
ret = 
#4  0xf7f8fbf4 in pfmlib_init_pmus () at pfmlib_common.c:1139
p = 0xf7fb75a4 
i = 
ret = 0
nsuccess = -66220
p = 
i = 
ret = 
nsuccess = 
__func__ = "pfmlib_init_pmus"
#5  pfm_initialize () at pfmlib_common.c:1239
ret = 
__func__ = 
#6  0x00400588 in main ()


It seems that it is crashing because /proc/cpuinfo is empty, and thus
pfmlib_getl never allocates a buffer, and the trailing b[i] = '\0' thus
becomes bogus. The attached patch fixes this in my tests.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpfm4 depends on:
ii  libc6  2.37-6

libpfm4 recommends no packages.

libpfm4 suggests no packages.

-- no debconf information
Cope with empty /proc/cpuinfo file

--- a/lib/pfmlib_common.c
+++ b/lib/pfmlib_common.c
@@ -791,7 +791,8 @@ pfmlib_getl(char **buffer, size_t *len,
if (c == '\n')
break;
}
-   b[i] = '\0';
+   if (c != EOF)
+   b[i] = '\0';
return c != EOF ? 0 : -1;
 }
 
--- a/lib/pfmlib_arm.c
+++ b/lib/pfmlib_arm.c
@@ -97,6 +97,8 @@ pfmlib_getcpuinfo_attr(const char *attr,
if (!strncmp(attr, buffer, attr_len))
break;
}
+   if (!value)
+   goto error;
strncpy(ret_buf, value, maxlen-1);
ret_buf[maxlen-1] = '\0';
ret = 0;

Bug#1043237: RFP: libauthen-sasl-scram-perl -- SCRAM-SHA-1/256/512 support for Perl library Authen::SASL

[Erik Hulsmann]

Package: wnpp
Severity: wishlist

* Package name: libauthen-sasl-scram-perl
  Version : 0.04
  Upstream Author : Erik Huelsmann 
* URL : https://github.com/ehuelsmann/authen-sasl-scram
* License : Perl_5
  Programming Lang: Perl
  Description : SCRAM-SHA-1/256/512 support for Perl library Authen::SASL

This package adds SCRAM authentication mechanisms to Authen::Perl. By
installing
this library existing Perl applications depending on Authen::Perl are instantly
extended with these authentication mechanisms when they use the Perl backend
(as opposed to the other available backends [XS and Cyrus]).

I wrote this library to enhance the "sendxmpp" program which is included in
Debian under a package by the same name, because 99% of all XMPP servers don't
offer any of the authentication mechanisms supported by the standard
Authen::SASL
library anymore (PLAIN, CRAM-MD5, DIGEST-MD5, LOGIN; most don't offer GSSAPI).

Having locally installed this library next to sendxmpp, I was indeed able to
use
SCRAM-SHA-512 to authenticate to my XMPP server without one line of change to
the
sendxmpp application that comes with Debian.

Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails

[Markus Koschany]

Hello,

Am Montag, dem 07.08.2023 um 20:22 +0200 schrieb J. Tóth Tamás:
> Hi,
> 
> Did you notice my reply sent on 4 July?

Yes, I did. Please keep the bug report always in CC.

> We’d like to gradually upgrade 
> to Bookworm, but I don’t want to make sysops’ lives more complicated by 
> giving them one WAR file to install on Bookworm and another one to 
> install on Bullseye.

I haven't had the time to investigate this problem yet. You don't have to wait
for a solution of this bug though. You can just manually run the tomcat-
jakartaee-migration tool on your existing war files. All it mainly does is to
replace the old occurrences of javax.* with jakarta.*. You could also send a
patch with your proposed changes to Debian's tomcat10 package and I take a look
at it.

Markus


signature.asc
Description: This is a digitally signed message part

Bug#1043236: login: different encryption method is used than asked for

[sz47u6+6eabsrwazv5xo]

Package: login
Version: 1:4.13+dfsg1-1+b1
Severity: normal
Tags: patch

Dear Maintainer,

/etc/login.defs contains this:

#
# If set to MD5, MD5-based algorithm will be used for encrypting password
# If set to SHA256, SHA256-based algorithm will be used for encrypting password
# If set to SHA512, SHA512-based algorithm will be used for encrypting password
# If set to BCRYPT, BCRYPT-based algorithm will be used for encrypting password
# If set to YESCRYPT, YESCRYPT-based algorithm will be used for encrypting 
password
# If set to DES, DES-based algorithm will be used for encrypting password 
(default)
# MD5 and DES should not be used for new hashes, see crypt(5) for 
recommendations.
# Overrides the MD5_CRYPT_ENAB option
#
# Note: It is recommended to use a value consistent with
# the PAM modules configuration.
#
ENCRYPT_METHOD SHA512

Which would make the user think that SHA512 is being used. However, in reality, 
it's YESCRYPT that is being used, because that is what PAM uses.

Thefore the default debian configuration does not adhere to its own advice in 
the file, where the values should be consistent both in /etc/login.defs and in 
PAM.

Patch attached to make the value in /etc/login.defs consistent with PAM.



-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages login depends on:
ii  libaudit1   1:3.0.9-1
ii  libc6   2.36-9+deb12u1
ii  libcrypt1   1:4.4.33-2
ii  libpam-modules  1.5.2-6
ii  libpam-runtime  1.5.2-6
ii  libpam0g1.5.2-6

login recommends no packages.

login suggests no packages.

-- no debconf information
>From b12158ecf8c9f85a3870d5fca64335d09f339df6 Mon Sep 17 00:00:00 2001
From: Your Name 
Date: Mon, 7 Aug 2023 19:07:17 +
Subject: [PATCH] use consistent algorithm

---
 debian/login.defs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/login.defs b/debian/login.defs
index bc129779..40f8c74a 100644
--- a/debian/login.defs
+++ b/debian/login.defs
@@ -291,7 +291,7 @@ USERGROUPS_ENAB yes
 # Note: It is recommended to use a value consistent with
 # the PAM modules configuration.
 #
-ENCRYPT_METHOD SHA512
+ENCRYPT_METHOD YESCRYPT
 
 #
 # Only works if ENCRYPT_METHOD is set to SHA256 or SHA512.
-- 
2.39.2

Bug#1043235: crystal: Package `crystal` misses important dependencies

[Beta]

Package: crystal
Version: 1.9.2+dfsg
Severity: important
X-Debbugs-Cc: b...@manas.tech

Dear Maintainer,

  It was [brought to our
  
attention](https://forum.crystal-lang.org/t/whats-up-with-the-debian-packages/5913)
  that the official debian package for crystal 1.9.2+dfsg-1 is not
  usable as is, as it is not requiring the libevent-dev library.

  Let me say upfront that I understand that the issue is likely dragged
  from the previous version of the package (1.6.2+dfsg-1 IIRC). Another,
  related issue, is that it does not ship `shards`, another important
  part of the Crystal ecosystem.

  As official maintainer of the [official crystal 
package](https://software.opensuse.org/download.html?project=devel%3Alanguages%3Acrystal=crystal),
 we are very happy to see that Crystal is being updated to its recent version, 
and we would like to help to improve it. One way is to add the dependencies. To 
give you an idea, here is what the official package `apt info` says:
  
```
Package: crystal
Version: 1.9.2-1+2.15
Priority: extra
Section: devel
Maintainer: Crystal Team 
Installed-Size: 133 MB
Provides: crystal1.9
Depends: gcc, pkg-config, libpcre3-dev, libpcre2-dev, libevent-dev
Recommends: libssl-dev, libz-dev, libxml2-dev, libgmp-dev, libyaml-dev
Conflicts: crystal
Homepage: https://crystal-lang.org
Download-Size: 31.8 MB
APT-Sources: 
http://download.opensuse.org/repositories/devel:/languages:/crystal/Debian_Unstable
  Packages
Description: Crystal is a general-purpose, object-oriented programming language.
 With syntax inspired by Ruby, it is a compiled language with static 
type-checking,
 serving both, humans and computers.
```

  (Note: libpcre3-dev is not really required though, it could be in the
Recommends section, as it is there for backwards compatibility.)

  Another interesting addition is to compile it with interpreter
support (passing `interpreter=1` to `make`).

  Feel free to contact me for any information regarding this issue. The
  Crystal team would love to see the compiler working out-of-the-box in
  debian-based distros.

Thanks for your work!
Beta

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.49-linuxkit (SMP w/6 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages crystal depends on:
ii  libc6   2.37-6
pn  libevent-2.1-7  
pn  libgc-dev   
pn  libgc1  
ii  libgcc-s1   13.1.0-6
pn  libllvm14   
ii  libpcre2-8-010.42-2
ii  libstdc++6  13.1.0-6
pn  pkg-config  

crystal recommends no packages.

Versions of packages crystal suggests:
pn  crystal-doc  
pn  crystal-samples  

Bug#1043234: libmath-bigint-perl: subclassing breaks numeric comparison

[Niko Tyni]

Package: libmath-bigint-perl
Version: 1.999838-1
Severity: important
Tags: ftbfs upstream
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition
Control: affects -1 ledgersmb

ledgersmb fails to build with new versions of Math-BigInt,
including the one separately packaged (both in stable and unstable)
as libmath-bigint-perl, and the one bundled with Perl 5.38 (currently
in experimental.)

   #   Failed test 'form: 9.999,99 parsed as 1.000,00 - .99'
   #   at t/02-number-handling.t line 224.
   #  got: .99
   # expected: .99
   
   [...]
   
   Test Summary Report
   ---
   t/02-number-handling.t(Wstat: 5120 (exited 20) Tests: 374 Failed: 20)
 Failed tests:  336-340, 345-349, 354-358, 365-369
 Non-zero exit status: 20
   Files=20, Tests=1802, 17 wallclock secs ( 0.39 usr  0.06 sys + 14.92 cusr  
1.89 csys = 17.26 CPU)
   Result: FAIL

I was able to narrow it down to this test, which fails with newer versions:

---
package MyFloat;
use base qw(Math::BigFloat);
1;

print MyFloat->new(.99) == Math::BigFloat->new(.99) ? "ok\n": "not 
ok\n";
---

It bisects down to upstream commit 

  
https://github.com/pjacklam/p5-Math-BigInt/commit/46d1252c98f565ae787c840173e5f98acf8953f1

so it regressed with upstream version 1.999836.
-- 
Niko Tyni   nt...@debian.org

Bug#1043151: bookworm-pu: package network-manager-applet/1.32.0-2+deb12u1

[Michael Biebl]

Hi Jonathan

Am 07.08.23 um 18:46 schrieb Jonathan Wiltshire:

Control: tag -1 moreinfo

On Sun, Aug 06, 2023 at 08:06:55PM +0200, Michael Biebl wrote:

I'd like to make a stable upload for network-manager-applet, which fixes
a crash in nm-connection-editor when importing a VPN configuration.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042712

It's a targetted fix, the patch has been cherry-picked from upstream Git
and applied to the package in unstable with not reported regressions.

Full debdiff is attached.


There's an upload pending for bookworm which doesn't match this diff and
seems to be relative to sid, not stable - is that an error?


This was a mistake, yes. I'm very sorry for that.
When creating the bookworm branch I accidentally picked the tag
debian/1.32.0-2 instead of the intended debian/1.30.0-2.
Not sure how I missed that.

The debdiff was so small, that I directly uploaded.

I wonder what to do now?

The diff between 1.30.0 and 1.32.0 is still reasonably small (excluding 
translations):


git diff debian/1.30.0-2 debian/1.32.0-2+deb12u1 -- ":(exclude)po" | 
diffstat

...
 24 files changed, 269 insertions(+), 77 deletions(-)

Shall I roll back the changes and upload a 1.32.0really1.30.0-something 
to bookworm?

Shall we simply cancel the 1.32.0-2+deb12u1 upload to bookworm?
Or should we go with 1.32.0 in bookworm?

Given the small amount of changes, I slightly prefer the last option, 
but I would appreciate your feedback.



Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1043046:

[c . buhtz]

Please show the output of

cat /etc/anacrontab

Please also think hard about if you have configured something on your 
Debian 11 machines in the past?
I'm not an expert in cron and anacron but in my understanding anacron do 
not start cron-jobs after their scheduled time (in hours in minutes). 
But I might be wrong.


Maybe you manually configured your Debian 11 in the past that way and 
forgot it then?
The upgrade to Debian 12 might overwrite your anacron/cron config with 
some default behavior?


It is just an idea and I'll investigate further. It is also possible 
that there is a BIT bug.

Bug#1043233: exim4-base: On-connect auto-generated self-signed certificates have expired end date

[Björn Wiberg]

Package: exim4-base
Version: 4.96-15+deb12u1
Severity: normal

Hello,

When using built-in on-connect auto-generated self-signed certificates (i.e., 
not installing "real" SSL/TLS certificates), the ones that are auto-generated 
appear to have a date in the past (1970-01-01 02:00:00 UTC) as their end date:

glimmer:~$ gnutls-cli --starttls-proto=smtp 127.0.0.1
Processed 140 CA certificate(s).
Resolving '127.0.0.1:smtp'...
Connecting to '127.0.0.1:25'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=glimmer.localdomain,O=Exim Developers,C=UK', issuer 
`CN=glimmer.localdomain,O=Exim Developers,C=UK', serial 0x0100, RSA 
key 3072 bits, signed using RSA-SHA256, activated `2023-08-07 17:40:16 UTC', 
expires `1970-01-01 02:00:00 UTC', 
pin-sha256="40P5jkI8FD97/oh+CYdi4BJH1nfhpfk0BFH/25j3yK4="
Public Key ID:
sha1:179da7ef14d6fdcea2d6894405c3531976f5b4df

sha256:e343f98e423c143f7bfe887e098762e01247d677e1a5f9340451ffdb98f7c8ae
Public Key PIN:
pin-sha256:40P5jkI8FD97/oh+CYdi4BJH1nfhpfk0BFH/25j3yK4=

- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
The certificate chain uses expired certificate. The name in the certificate 
does not match the expected.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.

glimmer:~$ openssl s_client -starttls smtp -connect 127.0.0.1:25 -showcerts < 
/dev/null
CONNECTED(0003)
Can't use SSL_get_servername
depth=0 C = UK, O = Exim Developers, CN = glimmer.localdomain
verify error:num=18:self-signed certificate
verify return:1
depth=0 C = UK, O = Exim Developers, CN = glimmer.localdomain
verify error:num=10:certificate has expired
notAfter=Jan  1 02:00:00 1970 GMT
verify return:1
depth=0 C = UK, O = Exim Developers, CN = glimmer.localdomain
notAfter=Jan  1 02:00:00 1970 GMT
verify return:1
---
Certificate chain
 0 s:C = UK, O = Exim Developers, CN = glimmer.localdomain
   i:C = UK, O = Exim Developers, CN = glimmer.localdomain
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug  7 17:40:16 2023 GMT; NotAfter: Jan  1 02:00:00 1970 GMT
-BEGIN CERTIFICATE-
MIIECjCCAnKgAwIBAgIIAQAwDQYJKoZIhvcNAQELBQAwRTELMAkGA1UE
BhMCVUsxGDAWBgNVBAoTD0V4aW0gRGV2ZWxvcGVyczEcMBoGA1UEAxMTZ2xpbW1l
ci5sb2NhbGRvbWFpbjAeFw0yMzA4MDcxNzQwMTZaFw03MDAxMDEwMjAwMDBaMEUx
CzAJBgNVBAYTAlVLMRgwFgYDVQQKEw9FeGltIERldmVsb3BlcnMxHDAaBgNVBAMT
E2dsaW1tZXIubG9jYWxkb21haW4wggGiMA0GCSqGSIb3DQEBAQUAA4IBjwAwggGK
AoIBgQDGRNkITNJlkX7AuyCPPtsjyPXR0sPBi4AYCRAl+z6CDj5FnsS4Z9livnkj
gqImvcjPfCG4jgezIeOysrKMiDXKQ+qglVFRGrvEPBHyqdA1M184Ul3MqJhbhiKW
Gd1t9ApY8oaXE4KWQKMIaZccKWtGtwobe5RkqLbcCT3YzxXGiUIUogaYA1iaKlc+
08eCP4NoUZRpQG7Anl5QZAwrxqNx+VIc2rWcBl8QAXJ6+Fuo0QztXxEgYvKLZ3he
xgvT9d/Is5oOqHplzfuJTXlslDbyKCZICwwBiDg2zywa/B2ai769nJzTks1tOp10
2ZxtpV0qUV1QPH1nuus9hElEl6rzW7riI9ptrDQR8Jc3CmjCHcy6g8f+ZJTrB4Z3
sYwCXfZZo1W5nd+DNY9hhQatCYx5Tnz72vzOvRW+Jcjh6FMTEXi8akYvlFyXy+Op
4M5QKCoIPigOaUiu4+RAtKdV5sJJuBJ0VoF5T/K3QIfgWejdpORbxiZU4710FWAW
flBIl2UCAwEAATANBgkqhkiG9w0BAQsFAAOCAYEABpatvsQ+KjWFp+TskSYyVoib
Vsii1l2y99Dg6nxy8PGQz3hlt/olhIYwN3+X/DNL0Wrn6Rgx1HIeQICbMYryoKg3
Fv1+iqlLOtTYJ/kJJl1Gjx2PbOTrFlEcsP49dAHkHn+Jfvfb2k3LwsELv/Xs7+8N
qKp7lg+wwmEwCy5lAJDf/i9SF3kJFBm/HHt01MaHFpVo8zP02MoL2KRjBQOUAcRl
bxHkt7NZV+bpBFZxAJBJlJLqaCwwtYdfpgUytXxiOiHPOWBgL2vhBqGIuddha69W
6ISHD9auJuX1dxsyg7wWYhlt0P4JCPSXSfYx3vXY6kzQ3Snctwz3hVup4URsKtdJ
PvnEXUfLQwNE2Vg3Z4j6YL3y6xMFX0BpwiCIpgcRXv2KfoD/KG2NscXygXW+bYvb
3alu3U8KPVGFDToOleWmZ/1dCXZMv8fctsJD+tD3tvX07fEVa9TpI0tANM2tc0QH
BVVr/G5fBDmBcXc9ADmbUIT8yJ/JSXdCuskG35+M
-END CERTIFICATE-
---
Server certificate
subject=C = UK, O = Exim Developers, CN = glimmer.localdomain
issuer=C = UK, O = Exim Developers, CN = glimmer.localdomain
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1992 bytes and written 410 bytes
Verification error: certificate has expired
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 3072 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 10 (certificate has expired)
---
250 HELP
DONE

I would have expected the auto-generated certificates to have at least some 
limited validity period.

Best regards
Björn


-- Package-specific info:
Exim version 4.96 #2 built 02-Jul-2023 12:56:17
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2022
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS TLS_resume move_frozen_messages DANE 
DKIM DNSSEC Event I18N OCSP PIPECONNECT PRDR Queue_Ramp SOCKS SRS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd

Bug#1043232: gimp-plugin-registry: Incompatible with gimp 3

[Jeremy Bícha]

Source: gimp-plugin-registry
Version: 9.20200928
Severity: important

gimp-plugin-registry is not compatible with gimp 2.99 which is
currently in Debian Experimental. When the new version of gimp is
uploaded to Unstable, this bug will be upgraded to Serious.

Do you intend to keep this package around after gimp 3 is released? Or
will it be removed from Debian?

Thank you,
Jeremy Bícha

Bug#1043048: Please give back statsmodels on mips64el Re: (Bug#1043048: fixed in openblas 0.3.23+ds-3)

[Sébastien Villemot]

Le lundi 07 août 2023 à 19:13 +0100, Rebecca N. Palmer a écrit :
> This does seem to have worked: the openblas build log no longer contains 
> FATAL ERROR.
> 
> Hence, please give back statsmodels on mips64el.  (DMs aren't allowed to 
> use the self-service link.)

Done.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org




signature.asc
Description: This is a digitally signed message part

Bug#1043048: Please give back statsmodels on mips64el Re: (Bug#1043048: fixed in openblas 0.3.23+ds-3)

[Rebecca N. Palmer]

This does seem to have worked: the openblas build log no longer contains 
FATAL ERROR.


Hence, please give back statsmodels on mips64el.  (DMs aren't allowed to 
use the self-service link.)

Bug#1043231: ITP: node-quickjs-emscripten -- Javascript/Typescript bindings for QuickJS compiled to WebAssembly

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-quickjs-emscripten
  Version : 0.15.0
  Upstream Author : Jake Teton-Landis
* URL : https://github.com/justjake/quickjs-emscripten#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Javascript/Typescript bindings for QuickJS compiled 
to WebAssembly


Safely execute untrusted Javascript in your Javascript,
and execute synchronous code that uses async functions.
Create and manipulate values inside the QuickJS runtime.
Expose host functions to the QuickJS runtime.

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043230: perl: break libgnupg-interface-perl (<< 1.02-4)

[Niko Tyni]

Package: perl
Version: 5.38.0-1

As discussed in #1042985, we should add a

  Breaks: libgnupg-interface-perl (<< 1.02-4)

to support partial upgrades to 5.38.
-- 
Niko

Bug#1043229: bookworm-pu: package open-ath9k-htc-firmware/1.4.0-108-gd856466+dfsg1-1.3+deb12u1

[Bastian Germann]

Package: release.debian.org
Control: affects -1 + src:open-ath9k-htc-firmware
X-Debbugs-Cc: open-ath9k-htc-firmw...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal

[ Reason ]
This addresses #1038684 in bookworm.
A kernel module parameter is set that changes the name of the expected 
ath9k-htc firmware name.
This used to be in place for the time where the prebuilt firmware was part of 
another firmware package.

[ Impact ]
The firmware loading fails because the file is not found.

[ Tests ]
Load the module with the hardware available.

[ Risks ]
None.

[ 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 unstablediff -Nru 
open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/ath9k_htc.conf 
open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/ath9k_htc.conf
--- open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/ath9k_htc.conf  
2023-02-25 19:28:32.0 +0100
+++ open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/ath9k_htc.conf  
1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-options ath9k_htc use_dev_fw=1
diff -Nru open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog 
open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog
--- open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog   
2023-02-25 20:37:02.0 +0100
+++ open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog   
2023-08-07 19:36:01.0 +0200
@@ -1,3 +1,9 @@
+open-ath9k-htc-firmware (1.4.0-108-gd856466+dfsg1-1.3+deb12u1) bookworm; 
urgency=medium
+
+  * Prevent requesting dev firmware (Closes: #1038684)
+
+ -- Bastian Germann   Mon, 07 Aug 2023 19:36:01 +0200
+
 open-ath9k-htc-firmware (1.4.0-108-gd856466+dfsg1-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install
 
open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install
--- 
open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install
  2023-02-25 19:28:32.0 +0100
+++ 
open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install
  2023-08-07 19:32:46.0 +0200
@@ -1,3 +1,2 @@
-debian/ath9k_htc.conf etc/modprobe.d/
 target_firmware/htc_*.fw lib/firmware/ath9k_htc/
 debian/firmware-ath9k-htc.metainfo.xml usr/share/metainfo

Bug#1043228: adequate: FTBFS with Perl 5.38: deprecated keywords

[Niko Tyni]

Source: adequate
Version: 0.15.7
Severity: important
Tags: ftbfs sid trixie
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition

This package fails to build from source with Perl 5.38 (currently in
experimental.)

  
http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/adequate_0.15.7/adequate_0.15.7_amd64-2023-08-04T06:16:05Z.build

   TESTING: ./adequate --version
   given is deprecated at ./adequate line 93.
   when is deprecated at ./adequate line 94.
   when is deprecated at ./adequate line 97.
   when is deprecated at ./adequate line 100.
   Smartmatch is deprecated at ./adequate line 647.
   when is deprecated at ./adequate line 710.
   when is deprecated at ./adequate line 713.
   when is deprecated at ./adequate line 716.
   when is deprecated at ./adequate line 730.
   when is deprecated at ./adequate line 738.
   when is deprecated at ./adequate line 743.
   when is deprecated at ./adequate line 751.
   when is deprecated at ./adequate line 754.
   when is deprecated at ./adequate line 782.
   when is deprecated at ./adequate line 785.
   when is deprecated at ./adequate line 829.
   Smartmatch is deprecated at ./adequate line 929.
   make[1]: *** [debian/rules:17: override_dh_auto_test] Error 1
   make[1]: Leaving directory '/<>'
   make: *** [debian/rules:6: binary] Error 2
   dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2
 
-- 
Niko Tyni   nt...@debian.org

Bug#1042847: libstring-license-perl: broken with Perl 5.38: syntax error near "class String::License::Naming::Custom :"

[Niko Tyni]

Control: found -1 0.0.9-1
Control: tag -1 patch

On Tue, Aug 01, 2023 at 10:25:04PM +0300, Niko Tyni wrote:
> Package: libstring-license-perl
> Version: 0.0.2-1
> Severity: important
> Tags: ftbfs trixie sid
> Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148507
> User: debian-p...@lists.debian.org
> Usertags: perl-5.38-transition
> Control: affects -1 licensecheck
> 
> Some modules in this package report syntax errors with Perl 5.38
> (currently in experimental.)
> 
> This also makes the test suite fail, so the package fails to build
> from source.
> 
> When this is fixed, please file a bug on the perl package
> to add a Breaks entry for earlier versions so that partial
> upgrades cannot end up with a broken combination.

As seen in

  
http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libstring-license-perl_0.0.9-1/libstring-license-perl_0.0.9-1_amd64-2023-08-05T15:35:07Z.build

this has now turned into

  Class :isa attribute requires a class but "String::License::Naming" is not 
one at 
/home/ntyni/tmp/libstring-license-perl/blib/lib/String/License/Naming/Custom.pm 
line 64.

This looks like a bug in the current (still experimental) Perl
core implementation of the class feature.  I've just filed
https://github.com/Perl/perl5/issues/21332 about it.

Working around that reveals new errors:

  Bareword "__CLASS__" not allowed while "strict subs" in use at 
lib/String/License.pm line 59.
  Attempt to access disallowed key '__ANON__' in a restricted hash at 
lib/String/License.pm line 64.

String::License using the __CLASS__ keyword, which was not yet implemented
in the core version for 5.38. A quick fix is to just use Object::Pad
instead of Feature::Compat::Class, which fixes the other error as well.

Doing that shows one more instance of the first issue:

  Class :isa attribute requires a class but "String::License::Naming" is not 
one at 
/home/ntyni/tmp/libstring-license-perl/blib/lib/String/License/Naming/SPDX.pm 
line 57.

The attached patch has workarounds for all of these. It passes the
test suite for me on both Perl 5.36 (Debian sid) and 5.38 (Debian
experimental.)

Hope this helps,
-- 
Niko Tyni   nt...@debian.org
>From c266d3f0983eaf2155de693bf5d0efb90bfc1145 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 7 Aug 2023 18:32:10 +0100
Subject: [PATCH] Workarounds for the class feature on Perl 5.38

__CLASS__ is not implemented in 5.38 yet, so we need to use Object::Pad
for String::License instead of Feature::Compat::Class.

Hierarchical naming currently has a quirk with :isa(), see
https://github.com/Perl/perl5/issues/21332

Bug-Debian: https://bugs.debian.org/1042847
---
 lib/String/License.pm   | 2 +-
 lib/String/License/Naming/Custom.pm | 1 +
 lib/String/License/Naming/SPDX.pm   | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/String/License.pm b/lib/String/License.pm
index dd3d9aa..cdf27c2 100644
--- a/lib/String/License.pm
+++ b/lib/String/License.pm
@@ -4,7 +4,7 @@ use warnings;
 use feature qw(signatures);
 no warnings qw(experimental::signatures);
 
-use Feature::Compat::Class 0.04;
+use Object::Pad;
 
 =head1 NAME
 
diff --git a/lib/String/License/Naming/Custom.pm b/lib/String/License/Naming/Custom.pm
index 28e2941..b00de17 100644
--- a/lib/String/License/Naming/Custom.pm
+++ b/lib/String/License/Naming/Custom.pm
@@ -59,6 +59,7 @@ use Log::Any   ();
 use List::Util qw(uniq);
 use Regexp::Pattern::License 3.4.0;
 
+use String::License::Naming ();
 use namespace::clean;
 
 class String::License::Naming::Custom : isa(String::License::Naming);
diff --git a/lib/String/License/Naming/SPDX.pm b/lib/String/License/Naming/SPDX.pm
index b40ddf6..2b64598 100644
--- a/lib/String/License/Naming/SPDX.pm
+++ b/lib/String/License/Naming/SPDX.pm
@@ -54,6 +54,7 @@ use Regexp::Pattern::License 3.4.0;
 
 use namespace::clean;
 
+use String::License::Naming ();
 class String::License::Naming::SPDX : isa(String::License::Naming);
 
 field $log;
-- 
2.39.1

Bug#1043227: opm-common: test failure on ppc64el with -O3

[Gianfranco Costamagna]

Source: opm-common
Version: 2023.04+ds-2
Tags: patch
Forwarded: https://github.com/OPM/opm-common/issues/3620

Hello, as per upstream ticket, there is a build failure (test failure) on ppc64 
and ppc64el (confirmed on perotto and platti porter machines)

A simple fix is to make sure that O3 is not used on ppc64el (I don't care about 
ppc64 because it has ~12 test failures
regardless of the optimization level used).

This is the patch I used in Ubuntu

diff -Nru opm-common-2023.04+ds/debian/changelog 
opm-common-2023.04+ds/debian/changelog
--- opm-common-2023.04+ds/debian/changelog  2023-07-17 13:05:05.0 
+
+++ opm-common-2023.04+ds/debian/changelog  2023-08-04 06:33:40.0 
+
@@ -1,3 +1,9 @@
+opm-common (2023.04+ds-2.1) unstable; urgency=medium
+
+  * Reduce optimization on ppc64el to -O2 (Closes: #-1)
+
+ -- Gianfranco Costamagna   Fri, 04 Aug 2023 
08:33:40 +0200
+
 opm-common (2023.04+ds-2) unstable; urgency=medium
 
   * d/control: Correctly reflect the merge of opm-material into opm-common

diff -Nru opm-common-2023.04+ds/debian/rules opm-common-2023.04+ds/debian/rules
--- opm-common-2023.04+ds/debian/rules  2023-07-17 13:05:05.0 +
+++ opm-common-2023.04+ds/debian/rules  2023-08-04 06:33:40.0 +
@@ -7,6 +7,13 @@
 
 OPM_DEBIAN_CMAKE_FLAGS = -DOPM_ENABLE_PYTHON=1 -DOPM_INSTALL_PYTHON=1 -DPYTHON_EXECUTABLE=/usr/bin/python3 -DOPM_INSTALL_COMPILED_PYTHON=OFF -DOPM_ENABLE_EMBEDDED_PYTHON=1
 
+ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el))

+  export DEB_CFLAGS_MAINT_STRIP = -O3
+  export DEB_CXXFLAGS_MAINT_STRIP = -O3
+  export DEB_CFLAGS_MAINT_APPEND = -O2
+  export DEB_CXXFLAGS_MAINT_APPEND = -O2
+endif
+
 need_gb_ram_per_process=3
 free_ram=$(shell free -g | sed -n 2p| sed "s/ \+/ /g"| cut -d " " -f 2)
 max_procs=$(shell echo "$(free_ram)/$(need_gb_ram_per_process)" | bc)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040801: mcomix: pillow 10.0.0 not recognized as higher than 6.0.0

[Roy Clark (kralcyor)]

Package: mcomix
Version: 2.1.0-2
Followup-For: Bug #1040801

Dear Maintainer,

This bug was fixed in the upstream commit [04785a], which was included in the 
new upstream version 2.2.0(and 2.2.1, of course):
https://sourceforge.net/p/mcomix/git/ci/2.2.0/tree/ChangeLog

[04785a]: 
https://sourceforge.net/p/mcomix/git/ci/04785a835b6c0e0782c9d0689686b0c1139febb1/

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mcomix depends on:
ii  gir1.2-gtk-3.03.24.38-2
ii  python3   3.11.4-5
ii  python3-cairo 1.24.0-1
ii  python3-gi3.44.1-2
ii  python3-gi-cairo  3.44.1-2
ii  python3-pil   10.0.0-1

Versions of packages mcomix recommends:
ii  python3-chardet  5.1.0+dfsg-2

Versions of packages mcomix suggests:
pn  lhasa
pn  mupdf-tools  
ii  p7zip16.02+dfsg-8
ii  unrar1:6.2.9-1
ii  unzip6.0-28

-- debconf-show failed

Bug#1037346: Addressbooks not recovered

[Joachim Zobel]

The recovery script worked quite nicely. Thanks, I could not have done
it without. However my addressbook is not working yet. It has been
recovered, the links have been created:

mail:~# /usr/lib/cyrus/bin/mbpath 'user.jzobel.#addressbooks.Default'
/var/spool/cyrus/mail/uuid/n/c/ncp127mdldzs1jn8augq24jo
mail:~# ls -lrt /var/spool/cyrus/mail/uuid/n/c/ncp127mdldzs1jn8augq24jo
| head 
total 1220
-rw--- 2 cyrus mail518 Aug  9  2015 2.
-rw--- 2 cyrus mail536 Aug 16  2015 293.
-rw--- 2 cyrus mail609 Aug 16  2015 295.
...

But nothing is delivered to my client (evolution).

Sincerely,
Joachim
-- 
   Papier ist gebundenes CO2. Bitte drucken Sie diese EMail aus und
archivieren Sie sie.

Bug#1043151: bookworm-pu: package network-manager-applet/1.32.0-2+deb12u1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Sun, Aug 06, 2023 at 08:06:55PM +0200, Michael Biebl wrote:
> I'd like to make a stable upload for network-manager-applet, which fixes
> a crash in nm-connection-editor when importing a VPN configuration.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042712
> 
> It's a targetted fix, the patch has been cherry-picked from upstream Git
> and applied to the package in unstable with not reported regressions.
> 
> Full debdiff is attached.

There's an upload pending for bookworm which doesn't match this diff and
seems to be relative to sid, not stable - is that an error?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1040925: ca-certificates-java 20230620~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1040925 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: ca-certificates-java
Version: 20230620~deb12u1

Explanation: 

Bug#1030129: ca-certificates-java: openjdk-17 update caused install regressions

[Volker Theile]

This bug is still active in Debian 12, e.g. it is not possible to
install collectd. Please backport ca-certificates-java (20230710) from
Trixie/Sid.

Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

[Jonathan Carter]

Source: debian-installer
Version: 20230607+deb12u1
Severity: wishlist

Dear Maintainer,

When setting up users and passwords in debian-installer in a default install,
it prompts a user to set up a root password. In d-i, this works very different
than in other installers, which causes quite a bit of confusion for users.

Firstly, the instructions start off with "You need to set a password for
'root'", followed by seemingly uninteresting text about what a good password
should be, which makes it incredibly easy for users to miss the part that sudo
won't be set up for the first user.

So, many users, and especially newcomers to Debian, follow the instructions in 
the
first line and are then surprised when they can't use sudo from their user from
their newly installed system.

Would it perhaps make more sense to move the root password setup to the expert
install d-i preseed entirely? Since this is likely only something that expert
users would require in the first place? Either that, or move the explanation
of what happens upward so that it's more prominent and not so easy to miss. In
the latter case, it might also be worth while changing the first line that says
"you need to..." so that user won't feel compelled to immediately start typing
a root password and click on next.

Thank you for considering,

-Jonathan

Bug#1043225: qt6-base: Please add patch to re-enable support for SuperH (sh4)

[John Paul Adrian Glaubitz]

Hi!

Forgot to specify Q_BYTE_ORDER. Updated patch attached.

Adrian


-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Index: qt6-base-6.4.2+dfsg/src/corelib/global/qprocessordetection.h
===
--- qt6-base-6.4.2+dfsg.orig/src/corelib/global/qprocessordetection.h
+++ qt6-base-6.4.2+dfsg/src/corelib/global/qprocessordetection.h
@@ -294,12 +294,12 @@
 
 SuperH is bi-endian, use endianness auto-detection implemented below.
 */
-// #elif defined(__sh__)
-// #  define Q_PROCESSOR_SH
-// #  if defined(__sh4a__)
-// #define Q_PROCESSOR_SH_4A
-// #  endif
-// Q_BYTE_ORDER not defined, use endianness auto-detection
+#elif defined(__sh__)
+#  define Q_PROCESSOR_SH
+#  if defined(__sh4a__)
+#define Q_PROCESSOR_SH_4A
+#  endif
+#  define Q_BYTE_ORDER Q_LITTLE_ENDIAN
 
 /*
 SPARC family, optional revision: V9

Bug#884744: gpsd grabs cp2102 usb-serial converter

[Boian Bonev]

Hi,

On Sun, 2023-08-06 at 12:12 +0200, Grzegorz Szymaszek wrote:
> Hi,
> 
> FWIW, here are two upstream issues on this topic, where it appears
> gpsd.rules is considered a source of problems:
> - https://gitlab.com/gpsd/gpsd/-/issues/187
> - https://gitlab.com/gpsd/gpsd/-/issues/235
> 
> Here is a recent Ubuntu bug report with some more opinions:
> https://bugs.launchpad.net/ubuntu/+source/gpsd/+bug/2012207
> 
> And here's my patch that should fix this specific bug by disabling
> cp210x hotplugging rules:
> https://salsa.debian.org/debian-gps-team/pkg-gpsd/-/merge_requests/14

Thank you for bringing attention to this problem, the fix is pending with the
next upload.

--
With best regards,
b.


signature.asc
Description: This is a digitally signed message part

Bug#1012864: graphviz: new upstream version 7.0.0 is available

[GCS]

Hi,

On Mon, Aug 7, 2023 at 4:39 PM Bo YU  wrote:
> I'm currently experiencing a demand from Debian users who
> would like to upgrade this package. Really the upstream become very
> active. Do you have plan to upgrade the package recently?
 I've already updated the package to 8.0.5 [1] to be exact. Going to
further update it to 8.1.0 and accept upstream development advice.
At this point I'm not looking for co-maintainers.

Regards,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/graphviz_8.0.5-1.dsc

Bug#1019254: kexec-tools: FTBFS on riscv64

[Khalid Aziz]

On 8/4/23 2:08 PM, Chris Hofstaedtler wrote:

Hi Khalid,

* Khalid Aziz  on 2022-12-07:

On 9/6/22 05:24, Eric Long wrote:

[..]

There is a patch from openSUSE [1] that fixes build on riscv64. Tested on my
QEMU riscv64 sbuild and it works fine. Can you please apply this to Debian
package as well?


I am updating kexec-tools package to 2.0.25. I am going to hold off on
pulling riscv64 support in. That is a fairly substantial patch. I would like
to give it some soak time in upstream before pulling it into debian package.


It's been a while since this - did it soak well in upstream so far?

Chris


Hi Chris,

That patch from Nick did not go into Simon's upstream kexec-tools tree. 
There were some failures with the original patch sent on Oct 5, 2021. 
Ver 2.0.26 of kexec-tools from Simon does not include risc-v support 
yet. I will consider this patch after it is pulled into upstream tree.


Thanks,
Khalid

Bug#1043138: thunderbird: cannot send OpenPGP signed message: rnp_op_sign_add_signature failed since upgrade to 115.1.0 (sid)

[Carsten Schoenert]

Hello Jamie,

I can't reproduce this issue.

Am 06.08.23 um 16:10 schrieb Jamie McClelland:


After upgrading to 115.1.0, when sending a message with "Digitally sign"
selected I consistently receive an error that "Sending of the message
failed." (When
just encrypting it works fine.)

The error console reports:

CryptoAPI.sync() failed result:  Error: rnp_op_encrypt_add_signature failed
  encryptAndOrSign chrome://openpgp/content/modules/RNP.jsm:3526
  sync chrome://openpgp/content/modules/cryptoAPI/interface.js:56
  encryptMessageStart chrome://openpgp/content/modules/encryption.jsm:446
  finishCryptoEncapsulation
chrome://openpgp/content/modules/mimeEncrypt.jsm:516
  createMessageFile resource:///modules/MimeMessage.jsm:90
interface.js:46:17
Error: failure in finishCryptoEncapsulation, exitCode: -1
  finishCryptoEncapsulation
chrome://openpgp/content/modules/mimeEncrypt.jsm:537
  createMessageFile resource:///modules/MimeMessage.jsm:90
mimeEncrypt.jsm:554:15
mimeEncrypt.js: caught exception: Error
Message: 'failure in finishCryptoEncapsulation, exitCode: -1'
File:chrome://openpgp/content/modules/mimeEncrypt.jsm
Line:537
Stack:
finishCryptoEncapsulation@chrome://openpgp/content/modules/mimeEncrypt.jsm:537:15
createMessageFile@resource:///modules/MimeMessage.jsm:90:27


Error: failure in finishCryptoEncapsulation, exitCode: -1
mimeEncrypt.jsm:537:15
  finishCryptoEncapsulation
chrome://openpgp/content/modules/mimeEncrypt.jsm:537
  createMessageFile resource:///modules/MimeMessage.jsm:90
  InterpretGeneratorResume self-hosted:1455
  AsyncFunctionNext self-hosted:852
mailnews.send: NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "failure in finishCryptoEncapsulation, 
exitCode: -1" {file: "chrome://openpgp/content/modules/mimeEncrypt.jsm" line:> 537}]'[JavaScript Error: 
"failure in finishCryptoEncapsulation, exitCode: -1" {file: 
"chrome://openpgp/content/modules/mimeEncrypt.jsm" line: 537}]' when calling method:
[nsIMsgComposeSecure::finishCryptoEncapsulation]
  createMessageFile resource:///modules/MimeMessage.jsm:90
MessageSend.jsm:137:32
  createAndSendMessage resource:///modules/MessageSend.jsm:137
mailnews.send: Sending failed; , exitCode=2153185313, originalMsgURI=
MessageSend.jsm:362:32
  fail resource:///modules/MessageSend.jsm:362
  createAndSendMessage resource:///modules/MessageSend.jsm:145
Error: rnp_op_encrypt_add_signature failed RNP.jsm:3526:21


You don't give any further information so it's difficult to give some 
good advice.


There are some general suggestions how to narrow down potential issues 
while working with a somehow dysfunctional Thunderbird application in 
the Debian Wiki.



https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues


Taking parts of the log from your error messages let me think it's not a 
issue within Thunderbird itself, it looks like you've configured 
Thunderbird to use GPG and not the internal crypto handling.


So far I remember you need ensure you have commented out this line in 
~/.gnupg/gpg-agent.conf


$ grep pinentry  ~/.gnupg/gpg-agent.conf 
#allow-loopback-pinentry


And also don't have set "pinentry-mode loopback" in ~/.gnupg/gpg.conf.

To see more information you will need to enable some debugging.

https://www.gnupg.org/documentation/manuals/gpgme/Debugging.html

e.g.


$ GPGME_DEBUG=9:~/gpgme.log thunderbird --jsconsole


--
Regards
Carsten

Bug#1043225: qt6-base: Please add patch to re-enable support for SuperH (sh4)

[John Paul Adrian Glaubitz]

Source: qt6-base
Version: 6.4.2+dfsg-17
Severity: normal
User: debian-sup...@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-sup...@lists.debian.org

Hello!

For some reason, upstream disabled the platform detection for SuperH (sh4) in
src/corelib/global/qprocessordetection.h by simply commenting the corresponding
code out.

As demanded by upstream in [1], I will provide a screenshot of Qt running on SH
later this week.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025823

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- qt6-base-6.4.2+dfsg.orig/src/corelib/global/qprocessordetection.h
+++ qt6-base-6.4.2+dfsg/src/corelib/global/qprocessordetection.h
@@ -294,12 +294,12 @@
 
 SuperH is bi-endian, use endianness auto-detection implemented below.
 */
-// #elif defined(__sh__)
-// #  define Q_PROCESSOR_SH
-// #  if defined(__sh4a__)
-// #define Q_PROCESSOR_SH_4A
-// #  endif
-// Q_BYTE_ORDER not defined, use endianness auto-detection
+#elif defined(__sh__)
+#  define Q_PROCESSOR_SH
+#  if defined(__sh4a__)
+#define Q_PROCESSOR_SH_4A
+#  endif
+Q_BYTE_ORDER not defined, use endianness auto-detection
 
 /*
 SPARC family, optional revision: V9

Bug#1042897: aptitude: viewing a package's changelog from the TUI outputs a warning that is immediately erased

[Sven Joachim]

On 2023-08-06 23:54 +0200, Vincent Lefevre wrote:

> On 2023-08-05 13:04:56 +0200, Sven Joachim wrote:
>> Ah yes, Guillem implemented the "verbose" option three years ago in
>> reaction to #967911.  And it could not be used back then because the
>> dpkg version offering it was only uploaded several months later, but now
>> it certainly can be used. :-)
>>
>> Would you like to submit a merge request on salsa for the master branch?
>
> OK, done here:
>   https://salsa.debian.org/apt-team/aptitude/-/merge_requests/21

Thanks, I have updated
https://salsa.debian.org/apt-team/aptitude/-/merge_requests/20
accordingly.

Cheers,
   Sven

Bug#979688: Including u-boot-sunxi-with-spl.bin in the u-boot-sunxi binary package (see bug#979688)

[harry88]

On 25/07/2023 17:39, Vagrant Cascadian wrote:
> On 2023-07-25, Dave Jones wrote:
>> Heinrich Schuchardt and I were just having a look at this area for the
>> ubuntu packaging, specifically whether to include
>> u-boot-sunxi-with-spl.bin in the u-boot-sunxi build [...]
>>
> [...]
> I am also a bit inclined to adding u-boot-sunxi-with-spl.bin [...]


Hi Dave and Vagrant,

Thanks for taking an interest in this. I would like to see
u-boot-sunxi-with-spl.bin included for all boards in the u-boot-sunxi
binary package, for several reasons:

- it's the documented way to install U-Boot on all sunxi platforms (in
upstream's doc/board/allwinner/sunxi.rst and Debian's
debian/u-boot-sunxi.README.Debian)

- working with that single file is simpler than working with two files

- it works whatever the size of the SPL, whereas the current approach
assumes the SPL fits in 32K, which has not been guaranteed since commit
c0b417b2 (the SPL for H616 platforms needs about 36K)

- it's already there for all the 32-bit sunxi boards, so including it
for 64-bit boards too would be more consistent

- the currently used u-boot-sunxi-with-spl.fit.itb seems not to be a
documented file, but rather just an intermediate file produced when
binman is run (and for what it's worth, it doesn't conform to the FIT
specification in doc/usage/fit/source_file_format.rst because it lacks a
timestamp)

If u-boot-sunxi-with-spl.bin did end up being included for all boards,
then the u-boot-install-sunxi script could simply write that one file,
so its "splfiles" and "itbfiles" lists would no longer be needed. I've
suggested a patch below.

Best wishes,
Harold.


diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index b3af2c0b80..4a041652e9 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -1,9 +1,6 @@
 #!/bin/sh
 set -e

-splfiles="sunxi-spl.bin u-boot-sunxi-with-spl.bin"
-itbfiles="u-boot.itb u-boot-sunxi-with-spl.fit.itb"
-
 dtmodel="/sys/firmware/devicetree/base/model"
 if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
dtmodelname=$(cat $dtmodel)
@@ -97,35 +94,11 @@ if [ -z "$FORCE" ]; then
 fi
 fi

-spl=
-for i in $splfiles ; do
-i=${TARGET}/$i
-if [ -f "$i" ]; then
-spl=$i
-fi
-done
-
-if [ -z "$spl" ]; then
-echo >&2 "$0: no known .spl file in ${TARGET}"
+imfile="${TARGET}/u-boot-sunxi-with-spl.bin"
+if [ ! -f "$imfile" ]; then
+echo >&2 "$0: no image file at ${imfile}"
 exit 1
 fi

-if [ -n "$itbfiles" ]; then
-itb=
-for i in $itbfiles ; do
-i=${TARGET}/$i
-if [ -f "$i" ]; then
-itb=$i
-fi
-done
-fi
-
-echo "Writing u-boot SPL image"
-dd conv=notrunc if=${spl} of="$DEV" bs=8k seek=1
-
-if [ -n "$itb" ]; then
-echo "Writing u-boot FIT image"
-dd conv=notrunc if=${itb} of="$DEV" bs=8k seek=5
-fi
-
-sync "$DEV"
+echo "Writing U-Boot image ${imfile} to ${DEV}"
+dd conv=fsync,notrunc if="$imfile" of="$DEV" bs=8K seek=1
diff --git a/debian/targets.mk b/debian/targets.mk
index 8ef27133d7..ffc5da62bb 100644
--- a/debian/targets.mk
+++ b/debian/targets.mk
@@ -146,40 +146,40 @@ ifeq (${DEB_HOST_ARCH},arm64)
   a64-olinuxino_assigns := 
BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
   a64-olinuxino_targets := arch/arm/dts/sun50i-a64-olinuxino.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf u-boot-sunxi-with-spl.bin

   # Philip Rinn 
   u-boot-sunxi_platforms += a64-olinuxino-emmc
   a64-olinuxino-emmc_assigns := 
BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
   a64-olinuxino-emmc_targets := arch/arm/dts/sun50i-a64-olinuxino-emmc.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf u-boot-sunxi-with-spl.bin

   # Domenico Andreoli 
   u-boot-sunxi_platforms += nanopi_neo2
   nanopi_neo2_assigns := BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
   nanopi_neo2_targets := arch/arm/dts/sun50i-h5-nanopi-neo2.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf u-boot-sunxi-with-spl.bin

   # Steev Klimaszewski 
   u-boot-sunxi_platforms += nanopi_neo_plus2
   nanopi_neo_plus2_assigns := 
BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
   nanopi_neo_plus2_targets := arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf u-boot-sunxi-with-spl.bin

   # harr...@gmx.ph
   u-boot-sunxi_platforms += orangepi_one_plus
   orangepi_one_plus_assigns := 
BL31=/usr/lib/arm-trusted-firmware/sun50i_h6_no_pmic/bl31.bin
   orangepi_one_plus_targets := arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb \
 spl/sunxi-spl.bin u-boot-nodtb.bin u-boot-sunxi-with-spl.fit.itb \
-u-boot.bin uboot.elf
+u-boot.bin uboot.elf 

Bug#1024494: ITP fints

[Matthias Geiger]

The packaging is done and moved under the teams' umbrella: 
https://salsa.debian.org/python-team/packages/python-fints


Time permitting I'd appreciate an upload to NEW.


Thanks.


Matthias



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043224: r-bioc-decoupler: autopkgtest regression

[Graham Inggs]

Source: r-bioc-decoupler
Version: 2.6.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

The upload of r-bioc-decoupler 2.6.0+dfsg-1 is failing its own
autopkgtest [1].  I've copied what I hope is the relevant part of the
log below.  It seems r-bioc-decoupler has an autopkgtest dependency on
r-cran-glmnet (>= 4.1.0), but we have 4.1-7-1 in the archive.  Note
the hyphen in the 4.1-7 version.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-decoupler/testing/amd64/


 17s Broken autopkgtest-satdep:amd64 Depends on r-cran-glmnet:amd64 <
none -> 4.1-7-1 @un uN > (>= 4.1.0)
 17s Done
 17s Some packages could not be installed. This may mean that you have
 17s requested an impossible situation or if you are using the unstable
 17s distribution that some required packages have not yet been created
 17s or been moved out of Incoming.
 17s The following information may help to resolve the situation:
 17s
 17s The following packages have unmet dependencies:
 18s  autopkgtest-satdep : Depends: r-cran-glmnet (>= 4.1.0) but
4.1-7-1 is to be installed
 18s E: Unable to correct problems, you have held broken packages.

Bug#1043222: rust-pallete: uninstallable in sid, FTBFS in sid

[Andreas Hasenack]

Hi Jonas,

thanks for the fast reply!

On Mon, Aug 7, 2023 at 12:04 PM Jonas Smedegaard  wrote:
>
> Quoting Andreas Hasenack (2023-08-07 16:53:26)
> > since rust-phf 0.11.2-1, librust-palette-dev is currently uninstallable in 
> > sid:
>
> Hi Andreas,
>
> Thanks for the bugreport and the proposed patch.
>
> I have a corrected package lying on my local disk for some days, it just
> revealed a bug in related but not-strongly-related code that distracted
> me from releasing the fix.  I'll do that now...

Is that build-dep version change patch good? I can upload that to
ubuntu to unblock a rust migration, and sync the package again once
you do the debian upload. Or is that imminent?

Bug#1043223: r-cran-biocmanager: autopkgtest needs update for r-bioc-biocversion

[Graham Inggs]

Source: r-cran-biocmanager
Version: 1.30.21.1+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update

Hi Maintainer

Since the upload of r-bioc-biocversion 3.17.1-1, the autopkgtests of
r-cran-biocmanager are failing [1].  I've copied what I hope is the
relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-biocmanager/testing/amd64/


 38s > test_check("BiocManager")
 58s [ FAIL 1 | WARN 1 | SKIP 24 | PASS 84 ]
 58s
 58s == Skipped tests (24)
==
 59s * On CRAN (23): 'test_install.R:27:5', 'test_install.R:45:5',
 59s   'test_install.R:204:5', 'test_repositories.R:5:5',
 59s   'test_repositories.R:14:5', 'test_repositories.R:20:5',
 59s   'test_repositories.R:26:5', 'test_repositories.R:33:5',
 59s   'test_repositories.R:43:5', 'test_repositories.R:118:5',
 59s   'test_repositories.R:127:5', 'test_repositories.R:165:5',
 59s   'test_version.R:17:5', 'test_version.R:39:5', 'test_version.R:92:5',
 59s   'test_version.R:107:5', 'test_version.R:147:5', 'test_version.R:194:5',
 59s   'test_version.R:235:5', 'test_version.R:246:5', 'test_version.R:277:5',
 59s   'test_version.R:328:5', 'test_version.R:387:5'
 59s * too idiosyncratic for standardized testing (1): 'test_install.R:164:5'
 59s
 59s == Failed tests

 59s -- Failure ('test_install.R:355:5'): install() without package
names passes ... to install.packages --
 59s `object` is not TRUE
 59s
 59s `actual`:   FALSE
 59s `expected`: TRUE
 59s
 59s [ FAIL 1 | WARN 1 | SKIP 24 | PASS 84 ]

Bug#1043222: rust-pallete: uninstallable in sid, FTBFS in sid

[Jonas Smedegaard]

Quoting Andreas Hasenack (2023-08-07 16:53:26)
> since rust-phf 0.11.2-1, librust-palette-dev is currently uninstallable in 
> sid:

Hi Andreas,

Thanks for the bugreport and the proposed patch.

I have a corrected package lying on my local disk for some days, it just
revealed a bug in related but not-strongly-related code that distracted
me from releasing the fix.  I'll do that now...

Thanks for nudging me :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1042358: openvswitch: FTBFS: make[3]: *** [Makefile:6743: manpage-check] Error 1

[Colin Watson]

On Mon, Aug 07, 2023 at 04:45:30PM +0200, Thomas Goirand wrote:
> Ok, so if there's only 5 patches, not 6, then I should be able to manage
> (even though it's not the best convenient way). Thanks for your patches.

I think I possibly understand what you meant now.  Is this more
convenient?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]
>From 45a2a2245f6c73dc6898f63c8d30ffd138920066 Mon Sep 17 00:00:00 2001
From: Colin Watson 
Date: Fri, 4 Aug 2023 18:22:31 +0100
Subject: [PATCH v2 0/5] docs: Fix manpage-check warnings with groff 1.23.0

https://bugs.debian.org/1042358 reported a manpage-check failure with
groff 1.23.0 in Debian testing/unstable.  Fixing the immediate mistake
here exposed a few other issues in how the tables in ovs-fields(7) are
rendered.

Colin Watson (5):
  docs: Wrap more table entries in text blocks
  docs: Shorten overly-wide table heading
  docs: Tweak width of name column in field property tables
  docs: Fix rendering of VLAN Comparison Chart
  docs: Run tbl preprocessor in manpage-check rule

 Makefile.am  |  2 +-
 build-aux/extract-ofp-fields | 20 ++--
 lib/meta-flow.xml| 25 +
 3 files changed, 28 insertions(+), 19 deletions(-)

--
2.39.2

>From 97fb673b2b09747beabe8625ac86dbfc5aa0c023 Mon Sep 17 00:00:00 2001
From: Colin Watson 
Date: Fri, 4 Aug 2023 11:19:06 +0100
Subject: [PATCH v2 1/5] docs: Wrap more table entries in text blocks

This fixes a number of "table wider than line length minus indentation"
warnings from tbl.  The table cells are too narrow for centered text to
look good, so left-align the contents of the text blocks.

Reported-by: Lucas Nussbaum 
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson 
---
 build-aux/extract-ofp-fields | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index efec59c25..2f566d2b9 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -189,12 +189,14 @@ def field_to_xml(field_node, f, body, summary):
 ovs_version = [int(x) for x in ovs_version_s.split(".")]
 if min_ovs_version is None or ovs_version < min_ovs_version:
 min_ovs_version = ovs_version
-summary += ["\\fB%s\\fR" % f["name"]]
+summary += ["T{\n.ad l\n\\fB%s\\fR" % f["name"]]
 if f["extra_name"]:
 summary += [" aka \\fB%s\\fR" % f["extra_name"]]
-summary += [";%d" % f["n_bytes"]]
+summary += ["\nT}"]
+summary += [";T{\n.ad l\n%d" % f["n_bytes"]]
 if f["n_bits"] != 8 * f["n_bytes"]:
 summary += [" (low %d bits)" % f["n_bits"]]
+summary += ["\nT}"]
 summary += [";%s;" % {"MFM_NONE": "no", "MFM_FULLY": "yes"}[f["mask"]]]
 summary += ["%s;" % {True: "yes", False: "no"}[f["writable"]]]
 summary += ["%s;" % f["prereqs"]]
@@ -203,7 +205,7 @@ def field_to_xml(field_node, f, body, summary):
 support += ["OF %s+" % VERSION_REVERSE[min_of_version]]
 if min_ovs_version is not None:
 support += ["OVS %s+" % ".".join([str(x) for x in min_ovs_version])]
-summary += " and ".join(support)
+summary += ["T{\n.ad l\n", " and ".join(support), "\nT}"]
 summary += ["\n"]
 
 # Full description.
@@ -230,8 +232,10 @@ l lx.
 body += ["Width:;"]
 if f["n_bits"] != 8 * f["n_bytes"]:
 body += [
+"T{\n",
 "%d bits (only the least-significant %d bits "
-"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"])
+"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"]),
+"\nT}",
 ]
 elif f["n_bits"] <= 128:
 body += ["%d bits" % f["n_bits"]]
-- 
2.39.2

>From 36207097b0c3de75d562b93e666c54f954da763c Mon Sep 17 00:00:00 2001
From: Colin Watson 
Date: Fri, 4 Aug 2023 18:01:55 +0100
Subject: [PATCH v2 2/5] docs: Shorten overly-wide table heading

Using "NXM/OXM Support" makes these tables a little too wide to fit well
when rendered in 80 columns, causing warnings from groff.  There's
already some abbreviation going on here (e.g. "RW?"), so "NXM/OXM?"
seems acceptable.

Reported-by: Lucas Nussbaum 
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson 
---
 build-aux/extract-ofp-fields | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index 2f566d2b9..808c6527d 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -323,7 +323,7 @@ def group_xml_to_nroff(group_node, fields):
 ".TS\n",
 "tab(;);\n",
 "l l l l l l l.\n",
-"Name;Bytes;Mask;RW?;Prereqs;NXM/OXM Support\n",
+"Name;Bytes;Mask;RW?;Prereqs;NXM/OXM?\n",
 "\_;\_;\_;\_;\_;\_\n",
 ]
 content += summary
-- 
2.39.2

>From 7622daa80dad932cab11febfc8afa6a78b1f84ac Mon Sep 17 00:00:00 2001
From: Colin Watson 
Date: Fri, 4 Aug 2023 18:18:01 +0100
Subject: 

Bug#1043222: rust-pallete: uninstallable in sid, FTBFS in sid

[Andreas Hasenack]

Package: rust-palette
Version: 0.7.2+dfsg-2
Importance: normal

Dear Maintainer,

since rust-phf 0.11.2-1, librust-palette-dev is currently uninstallable in sid:

$ sudo apt install librust-palette-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 librust-palette-dev : Depends: librust-phf-0.10+macros-dev but it is
not installable
E: Unable to correct problems, you have held broken packages.

It's also an FTBFS because dependencies cannot be installed:
~/deb/rust-palette/rust-palette-0.7.2+dfsg$ sudo apt-get build-dep ./
Note, using directory './' to get the build dependencies
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:./ : Depends: librust-phf-0.10+macros-dev but it is not installable
E: Unable to correct problems, you have held broken packages.


The fix seems simple, just adjust the b-d:
--- debian/control.orig 2023-08-07 14:52:07.510428573 +
+++ debian/control  2023-08-07 14:52:14.966912620 +
@@ -12,7 +12,7 @@
  librust-image-0.24+png-dev ,
  librust-lazy-static-1+default-dev ,
  librust-libm-0.2-dev ,
- librust-phf-0.10+macros-dev ,
+ librust-phf-0.11+macros-dev ,
  librust-proc-macro2-1+default-dev ,
  librust-quote-1+default-dev ,
  librust-rand-0.8-dev ,
@@ -45,7 +45,7 @@
  librust-bytemuck-1+default-dev,
  librust-fast-srgb8-1+default-dev,
  librust-libm-0.2-dev,
- librust-phf-0.10+macros-dev,
+ librust-phf-0.11+macros-dev,
  librust-proc-macro2-1+default-dev,
  librust-quote-1+default-dev,
  librust-rand-0.8-dev,

Or make it take the default librust-phf+phf-macros-dev perhaps, unversioned?

Bug#1042358: openvswitch: FTBFS: make[3]: *** [Makefile:6743: manpage-check] Error 1

[Thomas Goirand]

On 8/7/23 12:10, Colin Watson wrote:

On Mon, Aug 07, 2023 at 10:54:52AM +0200, Thomas Goirand wrote:

I very much appreciate that you've sent patches for this bug, thanks for
this. However, it is difficult to apply your patches because they are sent
inline, and therefore hard to save on disk. Also, I would have done the work
by  hand to avoid annoying you, but your "Message part 2" doesn't contain
the patch at all, only a diffstat.

Could you send me the 6 patches as separate files, so I could more easily
add them to debian/patches? Or at least send the first patch that's
completely missing...


I don't mind sending you patches in a different format if it's helpful,
but I'm confused; I _did_ send them as separate files,
MIME-encapsulated.  How else would I have sent them as separate files?

The "PATCH v2 0/5" message is a cover letter for the patch set.  It's
not supposed to contain a patch itself.

Cheers,


Hi,

Ok, so if there's only 5 patches, not 6, then I should be able to manage 
(even though it's not the best convenient way). Thanks for your patches.


Cheers,

Thomas Goirand (zigo)

Bug#1043221: RFS: xutils-dev/1:7.7+7 [Team] -- X Window System utility programs for development

[Bo YU]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xutils-dev":

 * Package name : xutils-dev
   Version  : 1:7.7+7
   Upstream contact : [fill in name and email of upstream]
 * URL  : [fill in URL of upstream's web site]
 * License  : [fill in]
 * Vcs  : 
https://anonscm.debian.org/cgit/pkg-xorg/app/xutils-dev.git
   Section  : x11

The source builds the following binary packages:

  xutils-dev - X Window System utility programs for development

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/xutils-dev/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xutils-dev/xutils-dev_7.7+7.dsc

Changes since the last upload:

 xutils-dev (1:7.7+7) unstable; urgency=medium
 .
   * Team upload.
   * Add 08_support_riscv64.patch to support riscv64. Thanks to
 Manuel A. Fernandez Montecelo (Closes: #897655, #1026002, #1035848)

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1043204: A fix has been posted on the linphone emailing list

[ael]

This has been answered on the linphone-us...@nongnu.org list.
There is an icon which can be clicked to hide the keyboard window.

ael

Bug#1012864: graphviz: new upstream version 7.0.0 is available

[Bo YU]

Source: graphviz
Followup-For: Bug #1012864

I'm currently experiencing a demand from Debian users who 
would like to upgrade this package. Really the upstream become very
active. Do you have plan to upgrade the package recently?

I would like to ask you mind others to help to maintain the package?
If so I can maintain it with you given you have made the package in a
good shape.

Thanks.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1014420: gimp: Missing gir dependencies

[Jeremy Bícha]

Control: severity -1 important

I'm downgrading the severity because the app does still run. But if
you run it from the command line, there are lots of errors like this:

Traceback (most recent call last):
  File 
"/usr/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/python-console/python-console.py",
line 20, in 
gi.require_version('Gimp', '3.0')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 126, in
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gimp not available
GIMP-WARNING: gimp: gimp_wire_read(): error


Also, see my suggestion about whether it makes sense to reintroduce
the gimp-python binary package and then we could likely move this
dependency there.

Also, there are now JavaScript and Lua plugins. I explicitly disabled
them with my recent upload, in part because I don't know if we want
Gimp to depend on gjs and Lua or whether those plugins should be in a
separate binary package. (This should be a separate bug report but I'm
mentioning it here since it could be related.)

Thank you,
Jeremy Bícha

Bug#1043209: call updatedb.plocate explicitly

[Matus UHLAR - fantomas]

On 07.08.23 14:38, Alexandre Detiste wrote:

I would rather prefer that you explain to me first
your real-life usage and need for this.



My own need is to support Buster & Xenial for embedded devices at work
with only mlocate.
Hybriding updatedb would mean one more ugly #ifdef in the C code.
   https://sources.debian.org/src/cruft-ng/0.9.56/debian/rules/

Usage of plain old "locate" from findutils was never an option
as it is so slow and would be harmful to cruft(-ng) users.


I have configured locate.findutils to be my "locate" due to different 
behaviour when providing multiple file arguments.


I know it's slower, and I can live with that.

However, cruft-ng calling "updatedb" updates incorrect database this way, it 
also produces errors.


And since cruft-ng calls explicitly "plocate", it could as well call 
explicitly "updatedb.plocate"


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".

Bug#1043169: Acknowledgement (gnome-software: Application version number ( flatpak and deb source ) stopped showing in description.)

[sergio]

Hi,

apt update and solved today.

Regards.

El dom,  6 de ago de 2023 a las 20:45:04 PM, Debian Bug Tracking 
System  escribió:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1043169: 
.


This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded 
to

  sazamor...@gmail.com 
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 Debian GNOME Maintainers 
>


If you wish to submit further information on this problem, please
send it to 1043...@bugs.debian.org .

Please do not send mail to ow...@bugs.debian.org 
 unless you wish

to report a problem with the Bug-tracking system.

--
1043169: 
Debian Bug Tracking System
Contact ow...@bugs.debian.org  with 
problems

Bug#1043207: evolution: Please drop libunity support

[Jeremy Bícha]

On Mon, Aug 7, 2023 at 9:44 AM Renato Gallo  wrote:
> https://endoflife.date/unity

These 2 things are not the same. This conversation is about the Unity
alternative desktop originally created by Canonical.
https://en.wikipedia.org/wiki/Unity_(game_engine)
https://en.wikipedia.org/wiki/Unity_(user_interface)

Thank you,
Jeremy Bícha