date:20230520

reopen 1036444
severity 1036444 grave
tags 1036445 patch
thanks

> #1036444: elinks: relies on file extension for files instead of content
> 
> It has been closed by أحمد المحمودي .

Please, don't close bug reports until you are sure the bug is fixed.

> 
> 
>  para1
>  para2
> 
> 

This file is not conforming XHTML 1. It's just HTML. As I explained you
in #1036382, XHTML 1 is a subset of HTML 4 that is also XML conformant.
So there are additional elements to add in this file, namely the
opening XML version line, the XHTML 1 DOCTYPE, the xmlns and xml:lang
attributes to the html tag, and closing tags for the paragraphs, since
it's mandatory to close all tags.

You have the simplest you example of a valid XHTML 1.1 document you can
find on the hello-world.xhtml file I attached you on #1036382, in case
you want to see a whole and save it for testing.

> I tested the version in experimental using the attached file, and it 
> worked correctly.

Please, don't close bugs that you think are fixed on experimental until
the fix is already on all supported releases containing the bug and you
are sure the bug is fixed.

In this case your test file wasn't conforming XHTML 1.1, as I
explained, so it's not good to reproduce it.

> > Version: 0.13.2-1+b1
> 
> Could you test the version in experimental (0.16.1.1) /?

No, I have no box available with experimental at this time, sorry.

But it makes little difference. The bug was filed for version
0.13.2-1+b1 so it's in all supported releases this version exists where
you have to test it, besides sid.

Please, also note experimental is not the right release for development
usually, that would be sid (unstable).

> > Tags: upstream, patch
> 
> No patch attaxhed, removing patch tag.

Patch tag does not mean necessarily that a patch is attached. A simple
description for fixing it is enough:

   patch
  A patch or some other easy procedure for fixing the bug is
  included in the bug logs. [...]

In this case my procedure was at the bottom of my report. It should be
easy enough for the developers.

As in #1036382, all you have to do is confirm you can reproduce it with
the same package version, confirm the bug is not caused by a Debian
patch, and forward the report to upstream. Also try to reproduce
through network, if you can.

> > Severity: grave
> Quoting https://www.debian.org/Bugs/Developer :
> "
> grave
>  makes the package in question unusable or mostly so, or causes data 
>   loss, or introduces a security hole allowing access to the accounts of 
>   users who use the package.
> "
>
> hence severity is either normal or important.

I wonder why you think severity is normal or important, and more so why
you don't even seem to know which of these is supposedly. Quoting the
severity's description doesn't provide your reason :)

My reasoning is analogue to the one I had for #1036382 initially, which
is provided there and in this report.

> > ELinks is not recognizing MIME type text/xml+xhtml nor text/xml, which
> > are the recommended types for XHTML, on added file extensions. This
> > means that, despite XHTML 1.0 and XHTML 1.1 documents are valid HTML 4
> > they are not recognized unless you use text/html type.
>
> Please attach a file that I can use to test the issue.

Considering you are maintaining a web browser you should be able to
make up an elementary XHTML 1.1 test file yourself. Anyway, as I said,
I provided one also to you in #1036382, named hello-world.xhtml. Just
rename to

  hello-world.xhtml.en

Bug#1036384: dillo: Open file dialog pops up in /tmp

2023-05-20 Thread Axel Beckert

Control: severity -1 minor
Control: tag -1 upstream

Hi,

José Luis González wrote:
> When I pop up the Open file dialog it always opens in /tmp, forcing you
> to change to home, which is where it should open.

Where it should open is actually very subjective. And most open
dialogs don't open in $HOME either but usually where you opened a file
the last time. Which dillo does btw. to. (Ok, maybe not after it has
been closed and started again.)

/tmp/ is not the best choice but IMHO a valid one. At least I manually
open HTML files in a browser most times in /tmp/ and not in $HOME.
(And not, the fact that dillo does that is not a patch of mine, just
coincidence. And probably the reason why I never noticed it.)

Additionally there is the short cut Alt-H to directly jump to your
home directory.

> Besides, if I click on FLTK's shortcut for /, right up the Filename
> text entry, it only displays kernel fs dirs: sys, proc, dev, run, and
> subdirs of these.

Indeed. But it actually shows all mount points (including /home/ for
me). Which is maybe not expected, but kinda makes sense. It also
includes / itself and when you click on that you get all files and
directories in there.

> The whole issue is a very serious usability issue.

No, it's not. From my point of view both issues are actually very
minor.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1036382: dillo: doesn't recognize XHTML 1.1 as HTML

retitle 1036382 dillo: meta http-equiv makes .xhtml files not be recognized
severity 1036382 important
thanks

On Sat, 20 May 2023 21:39:29 +0400
Andrey Rakhmatullin  wrote:

> Control: tags -1 + unreproducible
> 
> On Sat, May 20, 2023 at 11:23:19AM +0200, José Luis González wrote:
> > When I open an XHTML 1.1 file dillo doesn't recognize it as HTML,
> > displaying it as plain text, despite the file being correct XHTML. It
> > happens with any extension, including .html and .xhtml.
> I can't reproduce this.

I took the time to nail it down:

- hello-world.html works, but hello-world.xhtml doesn't, for the same
  content. .xhtml extension just makes dillo not recognize the file as
  HTML, for any content. This is not the bug I had reported, though but
  a new one. I will let you file it.

- The offending line that made my two .xhtml files not be recognized was

which is perfectly valid XHTML 1 as well as HTML, and works in
all .html files I have tried, including "hello-world plus
http-equiv.html.

I attach these new, simplified, test files. You should be able to
reproduce it with them. They are as simple as a conforming XHTML 1
document can get, except the one with the added http-equiv,
obviously. Please, unmark the report as unreproduceable then.

On a personal side, I would have appreciated if you had told me you
hadn't tried .xhtml extension. You would have saved me test time.

> > Considering XHTML 1.1 is valid HTML 4, which dillo supports, and XHTML
> > is nowadays and shall be widely supported, this makes the package
> > mostly unusable.

> I don't think not supporting XHTML would make it "mostly unusable" but
> *shrug*.

XHTML 1 is just a subset of HTML 4 that is XML conformant, so it has
been basically supported by dillo since its very first release, back in
1999. XHTML 1.0 became a W3C recommendation on 26 January 2000, when
dillo was just at version 0.0.4, and a lot of things have happened ever
since. XHTML is mentioned in the ChangeLog for version 0.8.4, which was
released on the 11 of January 2005, but that was so far as to the
validation feature, so it doesn't mean it wasn't supported beforehand.
application/xhtml+xml was finally accepted in version 2.2.1 (July
2011), so since then XHTML 1 should have worked flawlessly.

My reasoning for the severity is XHTML 1 has been there for ages and is
trivial to implement. There are tons of documents tagged as such around
on the web, so not supporting it makes it impossible to use dillo
nowadays as a general browser, which renders the package unusable
except for particular cases, hence mostly unusable.

Having found out the bug was just in accepting the http-equiv, and not
in any XHTML I document I am lowering severity to important.

If I had the time I would volunteer to provide a proper patch, but I
don't know this browser's code as well as ELinks', so can't promise
anything at this time. It should be trivial for the developers, though.
All I ask you is to confirm the bug was not coming from a
Debian patch and forward the full report to upstream. That's all.
Title: Hello, world!

foo

hello-world.xhtml
Description: application/xhtml
Title: Hello, world!

foo

Bug#1036446: Please enable udhcpc6

2023-05-20 Thread Ben Hutchings

Package: udhcpc
Version: 1:1.35.0-4+b2
Severity: wishlist
Tags: ipv6

Busybox has a DHCPv6 client (udhcpc6) but this is not included
in the Debian packages.

Please enable CONFIG_UDHCPC6 and the dependent features.

Ben.

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages busybox depends on:
ii  libc6  2.36-8

busybox recommends no packages.

busybox suggests no packages.

-- debconf-show failed

Bug#1036445: elinks: doesn't recognize recommended XHTML 1.0/1.1 MIME type on files

2023-05-20 Thread أحمد المحمودي

tag 1036445 -patch
severity 1036445 important
quit

On Sun, May 21, 2023 at 03:09:48AM +0200, José Luis González wrote:
> Version: 0.13.2-1+b1

Could you test the version in experimental (0.16.1.1) /?

> Tags: upstream, patch

No patch attaxhed, removing patch tag.

> Severity: grave
Quoting https://www.debian.org/Bugs/Developer :
"
grave
  makes the package in question unusable or mostly so, or causes data 
  loss, or introduces a security hole allowing access to the accounts of 
  users who use the package.
"

hence severity is either normal or important.

> ELinks is not recognizing MIME type text/xml+xhtml nor text/xml, which
> are the recommended types for XHTML, on added file extensions. This
> means that, despite XHTML 1.0 and XHTML 1.1 documents are valid HTML 4
> they are not recognized unless you use text/html type.

Please attach a file that I can use to test the issue.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#981466: kiwix: switch data feed and download URLs to https

2023-05-20 Thread Paul Wise

Control: fixed -1 2.3.0-1

On Sat, 2023-05-20 at 12:38 +0300, Kunal Mehta wrote:
> On 1/5/23 10:49, Emmanuel Engelhart wrote:
> > I wonder why this ticket is still open? AFAIK all of this has been fixed 
> > quite a while ago (HTTPS feed included).
> 
> Marking as done accordingly, thanks!

Please use versioned -done messages to close bugs that were fixed:

https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1036445: elinks: doesn't recognize recommended XHTML 1.0/1.1 MIME type on files

Package: elinks
Version: 0.13.2-1+b1
Tags: upstream, patch
Severity: grave

ELinks is not recognizing MIME type text/xml+xhtml nor text/xml, which
are the recommended types for XHTML, on added file extensions. This
means that, despite XHTML 1.0 and XHTML 1.1 documents are valid HTML 4
they are not recognized unless you use text/html type.

I haven't been able to test through HTTP yet, though. Severity is
assuming the bug happens also on network, so lower to important if it
isn't the case.

The solution depends on whether the problem is just a file handling
issue or general, but it's trivial in both cases:

- If it's a file handling issue (it works on HTTP) it's just a matter of
  finding out why only text/html is accepted in the case of files. I'm
  sure it is straightforward, and can volunteer for a patch in this
  case.

- If it's general all necessary is accepting both types and assuming
  they are valid HTML. Parts of XHTML 2 might not display correctly yet,
  but this has ever happened with all newer versions of HTML on legacy
  browsers, and is not a problem until it gets supported. I have no
  doubt XHTML 1 is fully supported, though, and has ever been, except
  for this MIME type issue.

Bug#1036444: elinks: relies on file extension for files instead of content

Package: elinks
Version: 0.13.2-1+b1
Severity: important

I have all my personal web pages ending in the their ISO language code
as extension, so the Apache server chooses the appropriate one
according to the Accepted-Language HTTP header from the browser. This
means all my files are named like

foo.xhtml.en
foo.xhtml.es

This is necessary in my case, and common practice. ELinks chokes at
this, though, because it relies on extension rather than content for
identifying HTML and the extension isn't .xhtml nor .html. The
consequence is they aren't recognized as HTML, but as
application/something, forcing you to open the file as binary and parse
it afterwards as HTML with ^\.

As soon as I link any of these files to .xhtml extension and open them
from that name they are recognized immediately. It's the same
with .html.

I think there are two possible solutions to this:

1. Adapting to Apache's naming convention and so recognizing all ISO
   language codes as extension.

2. Relying on content instead of extension, which means just making
   Elusive try to parse the file, and is, IMHO, the correct solution.

Bug#1036442: Additional Information

2023-05-20 Thread Bob Hauck


I am also seeing this error in the journal when I check mail in kmail:

kalendarac[20390]: org.kde.pim.imapresource: Crypto not supported!

That traces back to kdepim-runtime-22.12.3/resources/imap/sessionpool.cpp:

if (m_account->encryptionMode() != KIMAP::LoginJob::Unencrypted && 
!QSslSocket::su pportsSsl()) {
   qCWarning(IMAPRESOURCE_LOG) << "Crypto not supported!"; 
   Q_EMIT connectDone(EncryptionError,
  i18n("You requested TLS/SSL to connect to %1, but 
your "
   "system does not seem to be set up for that.",
   m_account->server()));
   disconnect();
   return;
   }

So I guess somehow Qt is thinking I don't have SSL installed, but I do.

ii  libssl3:amd64 3.0.8-1   
 amd64
   Secure Sockets Layer toolkit - shared libraries
ii  libxmlsec1-openssl:amd64  1.2.37-2  
 amd64
   Openssl engine for the XML security library
ii  openssl   3.0.8-1   
 amd64
   Secure Sockets Layer toolkit - cryptographic utility



Again, this is a fresh install using the RC3 netinstall ISO. I selected "KDE 
Desktop" in the task list.

-- 
Sent from my private email server!

Bug#1036443: ntpsec: leftover files on purge

2023-05-20 Thread Christoph Anton Mitterer

Source: ntpsec
Version: 1:4.2.8p15+dfsg-1
Severity: important


Hey.

When upgrading from bullseye to bookworm (and thus chaning from
ntp to ntpsec), the following files are leftover:
dpkg: warning: unable to delete old directory '/var/lib/ntp': Directory not 
empty
dpkg: warning: unable to delete old directory '/var/lib/sntp': Directory not 
empty

# find /var/lib/ntp /var/lib/sntp
/var/lib/ntp
/var/lib/ntp/ntp.drift
/var/lib/sntp
/var/lib/sntp/kod

I think these packages should be upgraded to properly clean up those files
or they'll likely remain as cruft forever.


Cheers,
Chris.

Bug#1036366: libreoffice: fails to embed font subset, PDF not printable, no option to disable subsetting nor embedding

2023-05-20 Thread Rene Engelhard


Hi,

Am 20.05.23 um 23:52 schrieb Thorsten Glaser:

Rene Engelhard dixit:


You as DD should know that stable won't get any updates for this anymore. (And
it will be oldstable in a short time anyway, even.)

So, who cares?

me :)

So reporting this against stable does not make any sense at all.

It does: it records the issue, so others will know,

True

and requests
the maintainers (both in Debian and upstream) to do something about
it at least in future versions.


No, upstream doesn't do it when it just appears here. And I could 
forward it, but how does  that help?


I don't have enough info and no time to play proxy for every question.





Please try with bookworms package (that one has stable backports, but is

Please do so. You’re in a much better position than I am, I don’t
even have a bookworm/sid system and don’t plan on getting one either.


I don't even understand the problem. So you as the submitter is better 
suited to do this.




(And I still think such bugs should be reported upstream directly)

And I still counter that you are in a much better position than me to
do so.


I disagree. You know best what's the problem and what not :)



  I don’t have the bandwidth to do that, I already lost over an
hour fighting this (I ended up having to hack the font, renaming it in
FontForge), and every day I don’t need to touch an office program is a
better day.


I don't use it either...



I cannot

respond to the questions they will surely have and I cannot test their
proposed fixes either.

Exactly the same for a "simple" maintainer of the package without knowing the 
exact problem...

Regards,


Rene

Bug#1036442: kmail: TLS error message when receiving mail.

2023-05-20 Thread Bob Hauck

Package: kmail
Version: 4:22.12.3-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Installed a new bookworm with KDE an an N100 NUC.

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

Configured exactly the same email server that I have on another
machine with the same settings. Note that these settings work on 
a machine running bookworm that was upgraded from bullseye.

Initially kmail downloaded my mailboxes but on subsequent logins
it gives an error message on startup and whenever I check mail.

Korganizer works fine.

   * What was the outcome of this action?

Erorr notifcation saying: Resource b...@haucks.org is broken.
You requested TLS/SSL to connect to mail.haucks.org, but your system 
does not seem to be set up for that.

   * What outcome did you expect instead?

Receiving mmail.

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages kmail depends on:
ii  akonadi-server   4:22.12.3-1
ii  kdepim-runtime   4:22.12.3-1
ii  kio  5.103.0-1
ii  libc62.36-9
ii  libgcc-s112.2.0-14
ii  libgpgmepp6  1.18.0-3+b1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-22  4:22.12.3-1
.12]
ii  libkf5akonadicontact5 [libkf5akonadicontact5-22.12]  4:22.12.3-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]4:22.12.3-1
ii  libkf5akonadimime5 [libkf5akonadimime5-22.12]4:22.12.3-1
ii  libkf5akonadisearch-bin  4:22.12.3-1
ii  libkf5akonadisearch-plugins  4:22.12.3-1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug  4:22.12.3-1
5-22.12]
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-22  4:22.12.3-1
.12]
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22  4:22.12.3-1
.12]
ii  libkf5bookmarks5 5.103.0-1
ii  libkf5calendarcore5abi2  5:5.103.0-1
ii  libkf5calendarutils5 [libkf5calendarutils5-22.12]4:22.12.3-1
ii  libkf5codecs55.103.0-1
ii  libkf5completion55.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5contacts5  5:5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5grantleetheme-plugins  22.12.3-1
ii  libkf5gravatar5abi2 [libkf5gravatar5-22.12]  4:22.12.3-1
ii  libkf5guiaddons5 5.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5identitymanagement5 [libkf5identitymanagement  22.12.3-1
5-22.12]
ii  libkf5identitymanagementwidgets5 [libkf5identityman  22.12.3-1
agementwidgets5-22.12]
ii  libkf5itemmodels55.103.0-1
ii  libkf5itemviews5 5.103.0-1
ii  libkf5jobwidgets55.103.0-1
ii  libkf5kcmutils5  5.103.0-3
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-22  22.12.3-1
.12]
ii  libkf5ksieveui5 [libkf5ksieveui5-22.12]  4:22.12.3-1
ii  libkf5ldap5abi1 [libkf5ldap5-22.12]  22.12.3-1
ii  libkf5libkdepim5 [libkf5libkdepim5-22.12]4:22.12.3-1
ii  libkf5libkleo5 [libkf5libkleo5-22.12]4:22.12.3-1
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-22.12]  4:22.12.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-22.12]22.12.3-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportako  22.12.3-1
nadi5-22.12]
ii  libkf5messagecomposer5abi1 [libkf5messagecomposer5-  4:22.12.3-1
22.12]
ii  libkf5messagecore5abi1

Bug#1036441: RFS: streamlink/5.5.1-1~exp1 -- CLI for extracting video streams from various websites to a video player

2023-05-20 Thread Alexis Murzeau


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 5.5.1 to be uploaded to experimental.

   * Package name: streamlink
 Version : 5.5.1-1~exp1
 Upstream Author : Streamlink Team
   * URL : https://streamlink.github.io/
   * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
 Section : python

It builds those binary packages:

python3-streamlink - Python module for extracting video streams from
various websites
python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/streamlink


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

dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_5.5.1-1~exp1.dsc

Changes since the last upload to unstable:

streamlink (5.5.1-1~exp1) experimental; urgency=medium

   * New upstream version 5.5.1
   * d/patches: update patches
   * d/patches,control: use furo theme instead of sphinx-rtd-theme
   * d/patches,control: use fork-awesome as a replacement for font-awesome
   * d/s/lintian-overrides: remove obsolete override about a test file

  -- Alexis Murzeau   Sat, 20 May 2023 19:52:43 +0200


Regards,
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036366: libreoffice: fails to embed font subset, PDF not printable, no option to disable subsetting nor embedding

2023-05-20 Thread Thorsten Glaser

Rene Engelhard dixit:

> You as DD should know that stable won't get any updates for this anymore. (And
> it will be oldstable in a short time anyway, even.)

So, who cares?

> So reporting this against stable does not make any sense at all.

It does: it records the issue, so others will know, and requests
the maintainers (both in Debian and upstream) to do something about
it at least in future versions.

> Please try with bookworms package (that one has stable backports, but is

Please do so. You’re in a much better position than I am, I don’t
even have a bookworm/sid system and don’t plan on getting one either.

> (And I still think such bugs should be reported upstream directly)

And I still counter that you are in a much better position than me to
do so. I don’t have the bandwidth to do that, I already lost over an
hour fighting this (I ended up having to hack the font, renaming it in
FontForge), and every day I don’t need to touch an office program is a
better day. I don’t have accounts in upstreams’ bugtrackers, I cannot
respond to the questions they will surely have and I cannot test their
proposed fixes either. While I’m a DD, that does not mean I suddenly am
a developer of *everything* (I have enough with the things I actually
volunteered for), and as a package maintainer, it’s your responsibility
to gate between the users (which, in this case, I am one) and upstream.

> Oh, and I noticed #965236 is also still open, meaning PDF files
>> generated by LibreOffice aren’t legal to distribute…
>
> Similiar for that one ;)

Hmm, I wonder if the LO origtgz contains PDFs generated by LO and
if that’s grounds to file a request for removal…

Please let’s not go to petty infighting like this. I help out people
with shell, C, assembly, weird porting questions, but here’s where
you can help out with GUI things. I’d rather work in favour of a
better world, but to do that everyone has to help.

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#1036440: very similar to this https://askubuntu.com/questions/1265137/avoid-missing-kernel-linux-modules-extra-xx-generic-when-updating-kernel

2023-05-20 Thread slimshady

Package: upgrade-reports
Severity: grave
Tags: d-i
X-Debbugs-Cc: slimshad...@zohomail.eu

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

My previous release was: debian 10
I am upgrading to: debian 11
Archive date: 
Upgrade date: january 2022
uname -a before upgrade: 4.9
uname -a after upgrade: 5.10
Method: via changing the repo names - buster to bullseye

Contents of /etc/apt/sources.list:


- Were there any non-Debian packages installed before the upgrade?  If
  so, what were they?

- Was the system pre-update a pure sarge system? If not, which packages
  were not from sarge?

- Did any packages fail to upgrade?

- Were there any problems with the system after upgrading?


Further Comments/Problems: my system initially worked fine after upgrading. but 
after a few days the alsa drivers crashed and pulseaudio output was low 
quality. so finally had to reinstall via iso.
this time after removing the old kernels before 5.10.0-22-amd64 the same 
problem appeared. i somehow managed to install alsa drivers from source but my 
system started showing config files not writable error. so after rebooting my 
whole sound apparatus has disappeared. 

sudo modprobe --show-depends snd_hda_intel 
modprobe: ERROR: ../libkmod/libkmod-module.c:191 kmod_module_parse_depline() 
ctx=0x555cb300c2a0 
path=/lib/modules/5.10.0-22-amd64/kernel/sound/hda/snd-intel-dspcfg.ko error=No 
such file or directory
modprobe: ERROR: ../libkmod/libkmod-module.c:191 kmod_module_parse_depline() 
ctx=0x555cb300c2a0 
path=/lib/modules/5.10.0-22-amd64/kernel/sound/hda/snd-intel-dspcfg.ko error=No 
such file or directory
insmod /lib/modules/5.10.0-22-amd64/kernel/sound/pci/hda/snd-hda-intel.ko

the modules should be bound to the system.

Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...",
depending on your shell) from before and after the upgrade so that we
know what packages were installed on your system.

$ COLUMNS=200 dpkg -l
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   
 Architecture Description
+++-=-==--==>
ii  accountsservice   0.6.55-3  
 amd64query and manipulate user account information
ii  accountwizard 4:20.08.3-1   
 amd64wizard for KDE PIM applications account setup
ii  acl   2.2.53-10 
 amd64access control list - utilities
ii  acpica-tools  20200925-1.2  
 amd64ACPICA tools for the development and debug of ACPI>
ii  acpid 1:2.0.32-1
 amd64Advanced Configuration and Power Interface event d>
ii  adb   1:10.0.0+r36-7
 amd64Android Debug Bridge
ii  adduser   3.118 
 all  add and remove users and groups
ii  adwaita-icon-theme3.38.0-1  
 all  default icon theme of GNOME
rc  akonadi-backend-mysql 4:20.08.3-3   
 all  MySQL storage backend for Akonadi
ii  akonadi-backend-sqlite:amd64  4:20.08.3-3   
 amd64SQLite storage backend for Akonadi
ii  akonadi-contacts-data 4:20.08.3-1   
 all  Akonadi contacts access library - data files
ii  akonadi-mime-data 4:20.08.3-1   
 all  Akonadi MIME handling library - data files
ii  akonadi-server4:20.08.3-3   
 amd64Akonadi PIM storage service
ii  akregator 4:20.08.3-1+deb11u1   
 amd64RSS/Atom feed aggregator
ii  alsa-oss  1.1.8-1   
 amd64ALSA wrapper for OSS applications
ii  alsa-tools1.2.2-1   
 amd64Console based ALSA utilities for specific hardware
ii  alsa-topology-conf1.2.4-1   
 all  ALSA topology configuration files
ii  alsa-ucm-conf

Bug#173314: xcalc only accepts digits from the numeric pad

2023-05-20 Thread Alan Coopersmith


This should be fixed now in the new upstream xcalc-1.1.2 release.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Bug#932957: Please migrate Release Notes to reStructuredText

2023-05-20 Thread Holger Wansing

Hi,

James Addison  wrote (Fri, 19 May 2023 23:28:55 +0100):
> > Please note the  in the URL!
> > I could not get this working with sphinx (if someone knows better, please
> > contact me!)
> 
> Could the 'extlinks' feature[1] of Sphinx be helpful to migrate those?

Yes, thanks for the pointer! I used that now to get the manpage links fixed!

> (it allows defining URL pattern aliases, so for example :oldreleasenotes: 
> could
> map to https://www.debian.org/releases/bullseye/releasenotes and 
> :releasenotes:
> could map to https://www.debian.org/releases/bookworm/releasenotes for D12)
> 
> Parameters are supported too, and that could be useful for package-or-filepath
> refs (re: grep -r '`.*<' source |grep -o '' | sort | uniq -c |sort 
> -n)

The drawback is, it is not as flexible as the entities in docbook.
For example, there is the following URL in this manual in docbook:

/debian/dists//main/binary-/...

You see, there are three entites in this URL!
This seems to be not supported by extlinks :-((


> > Beside this, I need help to adapt the buildchain, to get the possibility of
> > building the release-notes for the different architectures.
> > I have no python knowledge, so I will most likely not get this running 
> > myself.
> 
> I'll try to take a look into that soon to see what I can find out.  Do you
> know how the current docbook-based build varies by architecture?

There are some chapters, which are only visible for specific architectures, like
in installing.dbk:


  Cloud installations
  
The cloud team publishes
Debian  for several popular cloud computing services
including:


> Perhaps we can borrow some build scripting from developers-reference and/or
> debian-policy.. but I suppose those don't have per-architecture output.

I think so, yes. That will be of no help, I fear...

> > And the last point is the integration into the debhelper tools: I don't know
> > if it is required, to have the release-notes fit for building as a whole
> > package with sbuild or debuild or similar. Salsa tries to build it via CI
> > at every push, but currently fails.
> 
> It's possible I've misunderstood, but would be the goals here to be to get
> the release-notes documentation built by CI, and also for it to be distributed
> as a Debian package itself?
> 
> (someone who knows more may correct me, but I think it would be great to have
> the package available for install using apt in addition to the website)

That was my first thought as well, yes.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1036439: debian-installer: DLBD install failed, apparent typo.

2023-05-20 Thread Bud Heal

Package: debian-installer
Version: 20210731+deb11u8
Severity: important
Tags: d-i
X-Debbugs-Cc: budheal...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I copied the DLBD volumes to USB sticks and booted a desktop with a new
(M.2) SSD. I tried LVM and unencrypted. Then I tried with a laptop I had
previously installed bookworm into successfully.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
In each case, a message was emitted after partitioning (automatically)
from syslog:
May 20 01:33:10 debootstrap: /usr/sbin/debootstrap --components= 
--debian-installer --resolve-deps --no-check-gpg bookworm /ta
rget file:///cdrom/
May 20 01:33:10 debootstrap: /usr/sbin/debootstrap: eval: line 547: syntax 
error: unexpected "||" (expecting ")")

An internet suggestion was to re-mount the USB volume on /cdrom, but
/cdrom looked accurate. Any mount I tried was rejected anyway, and I was
able to save syslog (and the rest) using that share option.

I then compared the USB data to the .iso file to make sure they match.
   * What was the outcome of this action?
The install had to be aborted. 
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Foreign Architectures: [12-core AMD desktop] [14-core Intel (Nitro 5)]

-- no debconf information

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

2023-05-20 Thread Holger Wansing

Hi,

Richard Lewis  wrote (Fri, 19 May 2023 
00:58:26 +0100):
> On Thu, 18 May 2023 22:39:11 +0200 Holger Wansing  
> wrote:
> Unfortunately, my first impression is that it the output has quite a
> few issues which make it a lot harder to read than
> the docbook version - which im sure is because it's still only a
> prototype, but thought it might helpful to list the things that jumped
> out at me:
> - It is a lot more cluttered than the docbook version - it feels
> off-putting and dense to read
> - it's all a bit 'blue' - i'd suggest red is more on-brand for debian
> - the "next"/"prev" links at the bottom-right are white on green  ---
> I totally missed at first, and found hard to read

I copied style and font settings from developers-reference, another
document, which has been migrated recently from docbook to sphinx.
So I consider this as a quasi-standard at the moment.
I copied it by intent, to get a consistent look for all manuals generated
with sphinx.
We can work on that later on, as Laura already pointed out there is even
a bugreport for this.
So will ignore this for now here.

> - i was a bit confused by the "12.1" version number at the bottom of
> every page, and having 'sphinx' reminded me of websites with "hosted
> by geocities"

The first version I built with sphinx had version displayed
"release-notes 5.0.1" which confused me even more.
Therefore I changed that in the sense of "release-notes version 12 for
Debian release 12". Can still be changed in any way...

> - are the red hyphens in eg the 'deb...' line near the top of
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html
> meant to be red? (maybe it is a syntax error?)

I see this in other sphinx-generated manuals as well. So maybe a bug in sphinx?
Or a feature?

> - package names are no longer distinguished from other text (eg 'ntp'
> in 
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html#changes-to-packages-that-set-the-system-clock)

good catch, that should be changed - that's an easy one :-)

> - the order in the contents pane on the left is a bit...unusual: it
> starts with the current section, then does previous, then next, so eg
> on chapter 2,
>  
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/whats-new.html
> it lists chapters 2, then 1, then 3.

Seems to be the default in Sphinx? Currently I cannot see how I could change 
that.

> - 
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/genindex.html
> is completely blank

Yes, I already noticed that too.
And it's the same for the debian-policy and the developers-reference...
Needs to be investigated.

> - not sure "show source" on the left is all that useful for readers

That's a feature of sphinx, I guess.
And if a reader finds an error, or wants to make a proposal for a change, he
can easily access the source code and provide a patch against this.
So that's a good feature!

> I'm sure these are easy to fix!
> 
> > while the git repo containing the migration is at
> > https://salsa.debian.org/holgerw/release-notes
> 
> Im sure i am being dumb, but i couldnt spot where the actual rst files
> are? - i still see eg
> https://salsa.debian.org/holgerw/release-notes/-/blob/master/en/issues.dbk
> in XML

I have removed several old files from the repo now, amongst others the dbk
files in en.
The new rst files for English are in ./source/ (default for sphinx AFAICT).

> > as far as I know, sphinx/reStructuredText is still lacking some 
> > functionality,
> > which is heavily used in the release-notes.
> > That is the use of substitutions within URLs.
> 
> You could always keep the entities and do a 'sed
> s//bookworm/g' etc before "building" with sphinx.

That will not work. 
You cannot replace all 'bullseye' by 'bookworm'. There are places, where the
'bullseye' needs to stay. So that needs to be done selective one-by-one.

> Actually if i click 'show source'  l get to
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/_sources/about.rst.txt
> which seems to have |RELEASE| and |RELEASENAME| rather than 12 and
> bookworm: perhaps sphinx supports entities after all?

Sure, in sphinx that's called "substitution" and I use it already very much in
this manual.
The point is, that they do not work in all situations, where they did in docbook
(at least this is my current state of knowledge).

Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1003976: RFS: xmrig/6.16.2-1 [ITP] -- High performance, open source CPU/GPU miner and RandomX benchmark.

2023-05-20 Thread Ben Westover


Hello,

On 5/2/23 5:41 AM, Bastian Germann wrote:

Please have a closer look at the Copyright info.
I have only had a look at a few files but already found the general 
copyright header being misrepresented in d/copyright. It has to contain 
the following names:



> [snip]


Also, please have a look at the src/backend/opencl/wrappers/AdlLib*, 
src/base/io/Async.*, src/base/net/http*, 
src/base/net/stratum/DaemonClient.*, src/base/tools/Cvt.cpp, and 
src/base/crypto/keccak.* files for additional Copyright info.


I have gone back through the entire source and made the copyright info 
more accurate.


Thanks,
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036438: anki: Anki outdated and causing problems in synchronizing and importing decks

2023-05-20 Thread Pedro GONZÁLEZ MURILLO

Package: anki
Version: 2.1.15+dfsg-3
Severity: important
X-Debbugs-Cc: pedrogonzalezmurillo...@gmx.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Opening anki and
* Pressing sync and logging in; or
* Trying to import a deck with scheduling information
leads to an error and effectively blocks the importing and 
synchronizing of decks.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Install a newer version of anki through Flatpak
   * What was the outcome of this action?
Newer versions of anki work OK
   
   * What outcome did you expect instead?
For the deck to be imported or the sync function working correctly, a 
bug which is not present in newer versions.


The problem could be solved by packaging a newer version of anki 
*** End of the template - remove these template lines ***


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

Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
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 anki depends on:
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-flot   4.2.1+dfsg-5
ii  libjs-jquery-ui 1.12.1+dfsg-8+deb11u1
ii  libjs-mathjax   2.7.9+dfsg-1
ii  libqt5core5a5.15.2+dfsg-9
ii  python3 3.9.2-3
ii  python3-bs4 4.9.3-1
ii  python3-decorator   4.4.2-2
ii  python3-distro  1.5.0-1
ii  python3-distutils   3.9.2-1
ii  python3-jsonschema  3.2.0-3
ii  python3-markdown3.3.4-1
ii  python3-pyaudio 0.2.11-1.3+b1
ii  python3-pyqt5   5.15.2+dfsg-3
ii  python3-pyqt5.qtwebchannel  5.15.2+dfsg-3
ii  python3-pyqt5.qtwebengine   5.15.2-2
ii  python3-requests2.25.1+dfsg-2
ii  python3-send2trash  1.6.0~b1+git20210122.2eb3242-1

Versions of packages anki recommends:
ii  python3-matplotlib  3.3.4-1

Versions of packages anki suggests:
pn  dvipng 
pn  lame   
pn  mpv | mplayer  

-- no debconf information

Bug#1000029: PCRE to PCRE2 migration

2023-05-20 Thread Daniel Spiljar

On Tue, May 09, 2023 at 07:46:29PM +0530, Abhijith PA wrote:
> > Thank you for the heads-up! I added this to the TODO list, and will
> > inform you as soon as I'm done with porting.
> 
> Wonderful. Thank you.

Hello Abhijith,

I would like to inform you that I just released mboxgrep 0.7.12, which now 
compiles with pcre2:

https://git.datatipp.se/dspiljar/mboxgrep/releases/tag/0.7.12

Once again thanks for the heads-up!

Best regards,
Daniel

Bug#1036249: reopen #1036249

2023-05-20 Thread Markus Koschany

I have identified the rhino upstream commit which caused the FTBFS in closure-
compiler. If I revert said commit in rhino, then closure-compiler builds from
source without any additional patches needed. 

https://github.com/mozilla/rhino/commit/fb77164ac4889ffa4be26d5d24cb538a8dbd632b

However I still see the same runtime errors when I compile closure-compiler
against this new rhino version. At the moment I am running out of ideas. Given
that we approach full freeze in a few days, I am inclined to ship the last
rhino version that worked for closure-compiler and bundle it together with
src:closure-compiler. That should ensure all reverse-dependencies can be built
from source again. We also don't have to touch src:rhino again. 

After the Bookworm release I recommend to file an RC bug against closure-
compiler to ensure that someone either maintains it properly or it gets removed
from Debian. Currently src:rhino already ships patches to maintain
compatibility with a 10 year old version of closure-compiler and the burden
should not be placed on other maintainers to keep it in Debian.








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

Bug#1036437: furo.js fails to be loaded by firefox: Uncaught SyntaxError

2023-05-20 Thread Alexis Murzeau


Package: furo
Version: 2023.03.27+dfsg-1
Severity: normal

Dear Maintainer,

While using furo theme with sphinx to build streamlink's documentation, I found
that furo.js fails to be loaded by Firefox with this error:

Uncaught SyntaxError: import declarations may only appear at top level of a
module

I guess that the issue is the presence of this line in furo.js:
import Gumshoe from "./gumshoe-patched.js";

Upstream package use furo on their documentation page and their furo.js [1]
doesn't have it, it is instead minified.

The issue is that the theme doesn't handle properly the theme mode between dark
or light theme (it uses a mix of both).

[1]: https://streamlink.github.io/_static/scripts/furo.js


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 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=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages furo depends on:
pn  node-normalize.css  
ii  python3 3.11.2-1+b1
pn  python3-bs4 
pn  python3-pygments
pn  python3-sphinx  
pn  sphinx-basic-ng 

furo recommends no packages.

furo suggests no packages.

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036436: sylpheed: Select all and Select thread belong to Message menu, not Edit

Package: sylpheed
Version: 3.7.0-8
Tags: upstream
Severity: normal

Select all and Select thread are message operations, not edition
operations. Therefore they belong to Message menu, not Edit.

Bug#1035725: rdiff-backup bug

2023-05-20 Thread Henrik Riomar

Reproduction of the bug is simple with safekeep from a system running
Debian 11 trying to backup a system running Debian 12.

The backup can not even start, just get "Exception ''restrict_path'' raised
of class ''" from rdiff-backup on Debian 12.

Full back-trace from safekeep in the upstream bug report here:
https://github.com/rdiff-backup/rdiff-backup/issues/872

Bug#1036435: xpdf: belongs to Office menu category, not Graphics

Package: xpdf
Version: 3.04+git20210103-3
Severity: important

PDF is a document format. As such, xpdf is a document viewer, so it
belongs to the Office menu, not Graphics, as it currently is in.

Bug#1036306: unblock: ufw/0.36.2-1

2023-05-20 Thread Gunnar Hjalmarsson

I'm kind of 'hijacking' this bug instead of submitting an own. Hope you 
don't mind, Jamie. :/


I have the very same problem, i.e. piuparts failing due to the latest 
change in adduser:


https://tracker.debian.org/pkg/ibus-pinyin

So please add ibus-pinyin to the list of packages which probably need 
the release team's attention to resolve the adduser/piuparts situation.


I don't know how to identify other affected packages, but there is a 
related email list thread:


https://alioth-lists.debian.net/pipermail/piuparts-devel/2023-May/009566.html

(And with that I suppose that #1036307, which was mistakenly submitted 
as a new bug, can be closed.)


--
Cheers,
Gunnar Hjalmarsson

Bug#1036434: sylpheed: main window isn't sized adapting to messages container

Package: sylpheed
Version: 3.7.0-8
Severity: important
Tags: upstream

Sylpheed's main window isn't automatically sized to adapt to the
messages container width. A horizontal scrollbar is used instead, which
is not the right solution, since in this case you need to see all the
columns almost all the time, so scrolling makes no sense.

Bug#1036433: sylpheed: main window size not remembered when disabling separating folders tree

Package: sylpheed
Version: 3.7.0-8
Tags: upstream

If you separate the folders tree, resize Sylpheed's window, and disable
separate folders tree back, the size of Sylpheed's window is not
remembered.

Bug#1036249: reopen #1036249

2023-05-20 Thread Markus Koschany

reopen 1036249
thanks

The missing source files have been included with revision -14. Apparently
closure-compiler embeds rhino classes but renames them to avoid conflicts.
There is still a parsing error when closure-compiler tries to optimize
Javascript files at runtime. E.g. ERROR - Parse error. Unsupported syntax:
COMMENT

This is likely related to 

src/com/google/javascript/jscomp/parsing/IRFactory.java

method Node processUnaryExpression

This was the only part of the code that failed to build with rhino 1.7.14. My
patch to fix the FTBFS was incomplete and I am currently looking into a better
solution.


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

Bug#1036432: mirror submission for deb.mirror.deppen.biz

2023-05-20 Thread Eric Boltjes

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: deb.mirror.deppen.biz
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Eric Boltjes 
Country: DE Germany
Location: DÃ¼sseldorf




Trace Url: http://deb.mirror.deppen.biz/debian/project/trace/
Trace Url: 
http://deb.mirror.deppen.biz/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://deb.mirror.deppen.biz/debian/project/trace/deb.mirror.deppen.biz

Bug#1024098: celluloid: upgrade to 0.24 (GTK4) with a patch proposal

2023-05-20 Thread Patrice Duroux

Dear Maintainer,

DPT shows that the last upload is:

[2020-11-30] celluloid 0.20-2 MIGRATED to testing (Debian testing watch)
[2020-11-25] Accepted celluloid 0.20-2 (source) into unstable (Ximin Luo)
(signed by: infini...@debian.org) 

And there is now a mentor proposal for 0.25 since 2023-04-04:
https://mentors.debian.net/package/celluloid/

Does Debian 12 will ship the 0.20?
:-(

Thanks,
Patrice

Bug#1036431: sylpheed: + button in search messages dialog misplaced

Package: sylpheed
Version: 3.7.0-8
Tags: upstream
Severity: normal

The button to add additional conditions to the search messages dialog
is wrongly placed at right of each condition. This is complete nonsense,
since it's something that belongs logically to the conditions, not to
each condition, so it shall be before all the conditions, and there
shall be only one. Remaining consistent with the interface this should
also be a text button with an icon, not just an icon.

This important for two reasons. First and foremost because otherwise
the interface wouldn't be intuitive. You wonder where to add more
conditions until you figure out, and when you do it doesn't stay in
memory for long. Secondly, because it wastes space horizontally on this
place.

Bug#1036430: Debian 12 : wrong keyboard mapping for Français (Macintosh)

2023-05-20 Thread thomas . chandesris

Package: installation-reports
Severity: normal
Tags: l10n

Boot method: network
Image version: debian-bookworm-DI-rc3-amd64-netinst.iso
Date: 05/20/2023 5:00 PM

Machine: Apple Inc. MacBookAir3,2
Partitions: 
Sys. de fichiers Type blocs de 1K Utilisé Disponible Uti% Monté sur
udev devtmpfs 1839564   01839564   0% /dev
tmpfstmpfs 3745881596 372992   1% /run
/dev/sda2ext4   238658212 5072244  221389976   3% /
tmpfstmpfs1872928   01872928   0% /dev/shm
tmpfstmpfs   5120   8   5112   1% /run/lock
/dev/sda1vfat  523248   26700 496548   6% /boot/efi
tmpfstmpfs 374584 120 374464   1%
/run/user/1000


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[E]

Comments/Problems:

Insallation was 99% OK but the keyboard Français(Macintosh) was not
detected
during the installation.
So, I changed it after the first reboot but the 'mapping' is wrong :

2 keys are switched : @ (cap #) with < (cap >)
 
This problem didn't occure with debian 11.7

Thanks

-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230515"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux mac-debian 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.27-1 (2023-05-08) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: NVIDIA Corporation MCP89 HOST
Bridge [10de:0d60] (rev a1)
lspci -knn: 00:00.1 RAM memory [0500]: NVIDIA Corporation MCP89 Memory
Controller [10de:0d68] (rev a1)
lspci -knn: 00:01.0 RAM memory [0500]: NVIDIA Corporation Device
[10de:0d6d] (rev a1)
lspci -knn: 00:01.1 RAM memory [0500]: NVIDIA Corporation Device
[10de:0d6e] (rev a1)
lspci -knn: 00:01.2 RAM memory [0500]: NVIDIA Corporation Device
[10de:0d6f] (rev a1)
lspci -knn: 00:01.3 RAM memory [0500]: NVIDIA Corporation Device
[10de:0d70] (rev a1)
lspci -knn: 00:02.0 RAM memory [0500]: NVIDIA Corporation Device
[10de:0d71] (rev a1)
lspci -knn: 00:02.1 RAM memory [0500]: NVIDIA Corporation Device
[10de:0d72] (rev a1)
lspci -knn: 00:03.0 ISA bridge [0601]: NVIDIA Corporation MCP89 LPC
Bridge [10de:0d80] (rev a2)
lspci -knn: Subsystem: Apple Inc. Device [106b:cb89]
lspci -knn: 00:03.1 RAM memory [0500]: NVIDIA Corporation MCP89 Memory
Controller [10de:0d7b] (rev a1)
lspci -knn: 00:03.2 SMBus [0c05]: NVIDIA Corporation MCP89 SMBus
[10de:0d79] (rev a1)
lspci -knn: Subsystem: NVIDIA Corporation Device [10de:cb89]
lspci -knn: 00:03.3 RAM memory [0500]: NVIDIA Corporation MCP89 Memory
Controller [10de:0d69] (rev a1)
lspci -knn: 00:03.4 Co-processor [0b40]: NVIDIA Corporation MCP89 Co-
Processor [10de:0d7a] (rev a1)
lspci -knn: Subsystem: NVIDIA Corporation Device [10de:cb89]
lspci -knn: 00:04.0 USB controller [0c03]: NVIDIA Corporation MCP89
OHCI USB 1.1 Controller [10de:0d9c] (rev a1)
lspci -knn: Subsystem: NVIDIA Corporation Device [10de:cb89]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: Kernel modules: ohci_pci
lspci -knn: 00:04.1 USB controller [0c03]: NVIDIA Corporation MCP89
EHCI USB 2.0 Controller [10de:0d9d] (rev a2)
lspci -knn: Subsystem: NVIDIA Corporation Device [10de:cb89]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:06.0 USB controller [0c03]: NVIDIA Corporation MCP89
OHCI USB 1.1 Controller [10de:0d9c] (rev a1)
lspci -knn: Subsystem: NVIDIA Corporation Device [10de:cb89]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: Kernel modules: ohci_pci
lspci -knn: 00:06.1 USB controller [0c03]: NVIDIA Corporation MCP89
EHCI USB 2.0 Controller [10de:0d9d] (rev a2)
lspci -knn: Subsystem: NVIDIA Corporation Device [10de:cb89]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:08.0 Audio device [0403]: NVIDIA Corporation MCP89 High
Definition Audio [10de:0d94] (rev a2)
lspci -knn: Subsystem: NVIDIA Corporation Device [10de:cb89]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:0a.0 SATA controller [0106]: NVIDIA Corporation MCP89
SATA Controller (AHCI mode) [10de:0d88] (rev a2)
lspci -knn: Subsystem: Apple Inc. Device [106b:cb89]
lspci -knn: Kernel

Bug#1036382: dillo: doesn't recognize XHTML 1.1 as HTML

2023-05-20 Thread Andrey Rakhmatullin

Control: tags -1 + unreproducible

On Sat, May 20, 2023 at 11:23:19AM +0200, José Luis González wrote:
> When I open an XHTML 1.1 file dillo doesn't recognize it as HTML,
> displaying it as plain text, despite the file being correct XHTML. It
> happens with any extension, including .html and .xhtml.
I can't reproduce this.

> Considering XHTML 1.1 is valid HTML 4, which dillo supports, and XHTML
> is nowadays and shall be widely supported, this makes the package
> mostly unusable.
I don't think not supporting XHTML would make it "mostly unusable" but
*shrug*.

Bug#1035883: general: TMOUT and autologout are set to 3600, but logout occurs much earlier

2023-05-20 Thread Peter Wienemann


Dear Jim,

On 10.05.23 17:01, Jim Anderson wrote:

I realize that auto logout is a general security feature, but in my
case, I have a secrure environment where only my wife and I have access to
my computer. I strong prefer to NOT have my computer auto logout for 10 hours,
allowing me to leave my computer in the evening and return to it in the
morning without haveing to log on.

I have the enrivonment variables TMOUT and autologout both set to 36000,
or 10 hours, but these are not honored by the system.


from what does your computer log you out when it logs you out: A 
graphical user session or a shell session? TMOUT only controls the 
time-out of shell sessions.


Best regards,

Peter

Bug#1036428: libapache2-mod-apreq2: the package is missing from testing release and from i386 architecture

2023-05-20 Thread Rafal Pietrak

Package: libapache2-mod-apreq2
Version: 2.13-7+deb11u1
Severity: important

Dear Maintainer,

I've experieced problem after upgrading old (i386) machine to Debian-12
I've upgraded it from Debian-10, through Debian-11 (without testing this
step), ultimately to Debian-12.

My APACHE2 server was working correctly with libmason-perl while running
Debian-10, but after the upgrade it no longer works. Excerpts from log
is here:
--/var/log/apache2/error.log--
 192.168.1.47:52220] Can't locate object method "new" via package 
"Apache2::Request" at /usr/share/perl5/HTML/Mason/ApacheHandler.pm line 935.\n
--

I'm reporting from another machine (arch=amd64) which I keep at Debien-11.
Here the apache2 with my web-page works correctly (with libmason-perl and
libapreq2-mod-perl) and it does have libapreq2-mod-perl instaled. I tried
to download here the libapache2-mod-perl:i386, but the package is not
available on this release either.

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

Kernel: Linux 5.10.0-23-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libapache2-mod-apreq2 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.56-1~deb11u2
ii  libapr1 1.7.0-6+deb11u2
ii  libapreq2-3 2.13-7+deb11u1
ii  libaprutil1 1.6.1-5+deb11u1
ii  libc6   2.31-13+deb11u6

libapache2-mod-apreq2 recommends no packages.

libapache2-mod-apreq2 suggests no packages.

-- no debconf information

Bug#1036429: sylpheed: messages search dialog and other of its elements not sized correctly

Package: sylpheed
Version: 3.7.0-8
Tags: upstream

Several things in the search message dialog are not sized correctly.

Firstly, the search messages dialog window is too small. A container
would be mandatory here. Its width shall be at least that of the
conditions container, otherwise they don't fit. Additionally, height is
not enough to show more than three conditions, and considering fast
search is available, I would expect four, so bigger sizing is required
in this case. Also, it is not enough as well to show more than five
messages, as it's fairly common to look for more, so it becomes
uncomfortable to scroll; another place which requires bigger sizing.

Finally, the width of the message columns is too small for all but
date to fit what usually is there.

Bug#1036411: sylpheed: no option for getting thrash emptied on messages older than X days

2023-05-20 Thread Andrey Rakhmatullin

On Sat, May 20, 2023 at 05:17:57PM +0200, José Luis González wrote:
> Sorry Ricardo that I'm filing all these upstream bugs on Debian, but as
> far as I know Sylpheed doesn't have a BTS.
Even if that was true it wouldn't be a good reason to do this.
But then the top news entry on the official website is about its BTS so
it's one of the first things you see when opening that website (it's also
linked directly in the sidebar).

Bug#1036399: piuparts: false positives for unowned files left after purge

David Bremner  writes:

> David Bremner  writes:
>
>> Package: piuparts
>> Version: 1.1.7
>> Severity: normal
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> The following output from "piuparts -t /var/tmp --apt emacs" (also on 
>> piuparts.debian.org) looks suss to me:
>>
>> 0m43.8s INFO: Warning: Package purging left files on system:
>>   /root/.ssh/ not owned
>>   /var/cache/private/ not owned
>>   /var/lib/private/   not owned
>>   /var/lib/systemd/coredump/  not owned
>>   /var/lib/systemd/pstore/not owned
>>   /var/log/private/   not owned
>
> I just verified that something creates /root/.ssh when I run "apt
> install --no-install-recommends systemd" in a clean chroot.  So that
> part is a bug in some other package (presumably systemd or a
> dependency), not piuparts.

All of these directories are created by configuration in
/usr/lib/tmpfiles.d; in this case by systemd-tmpfiles.

Bug#1036427: O: coco-java -- Coco/R Compiler Generator (Java Version)


Package: wnpp

coco-java is obviously not maintained anymore. Therefore, I hereby orphan it.
Please only consider adopting if you have the skills and time to maintain it.

Bug#1036426: O: coco-cs -- Coco/R Compiler Generator (C-Sharp Version)


Package: wnpp

coco-cs is obviously not maintained anymore. Therefore, I hereby orphan it.
Please only consider adopting if you have the skills and time to maintain it.

Bug#1036098: autopkgtests fail when testbed has running dns server

2023-05-20 Thread Martin-Éric Racine

On Mon, May 15, 2023 at 4:25 PM Shengjing Zhu  wrote:
>
> On Mon, May 15, 2023 at 8:55 PM Martin-Éric Racine
>  wrote:
> > However, doing this one week away from Debian's final freeze is the
> > entirely wrong approach. This should have been done at least 2 months
> > ago, before the soft freeze started.
>
> I'm aware of the timeline. Thus I filed with normal severity that
> doesn't need to be fixed for Bookworm. And important for issue
> relevant for Bookworm.
> Debian doesn't run these autopkgtest at all, since the debci infra
> doesn't support isolation-machine.

I merged your change to the dnsmasq configuration. For some reason, it
makes 'piuparts' fail in the Salsa pipeline.

Martin-Éric

Bug#1036425: sylpheed: to not set automatically for sent messages

Package: sylpheed
Version: 3.7.0-8
Tags: upstream
Severity: important

If I reply to a message I sent, the To is not set to the addressee,
which is what would be expected, but to yourself.

The only reason I can think of replying a message you sent to yourself
would be a test or a note, which is way by far not the usual thing. On
such a case a follow-up to the addressee is usually what is intended,
and the common practice by MUAs.

Best,
JL

Bug#1036424: sylpheed: replying to an email you sent doesn't set account accordingly

Package: sylpheed
Version: 3.7.0-8
Severity: grave
Tags: upstream

If I reply to an email I sent the From account is not set to the
account I used to send it but to my default account.

See #1036388 for an explanation for severity.

Regards,
JL

Bug#1036423: unblock: uwsgi/2.0.21-5.1

2023-05-20 Thread James Valleroy


Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: uw...@packages.debian.org
Control: affects -1 + src:uwsgi

Please unblock package uwsgi/2.0.21-5.1.

This is an update to fix RC bug #1035005. I did an NMU as suggested by
the package maintainer.

[ Reason ]

Upgrades from Bullseye to Bookworm failed when
uwsgi-plugin-jvm-openjdk-11 is installed. This is solved by adding
versioned Breaks and Replaces to uwsgi-plugin-jvm-openjdk-17 binary
package.

[ Impact ]

uwsgi removed from the release, affecting many packages that depend on
it.

[ Tests ]

I tested by unpacking the package into a Debian bullseye VM where
uwsgi-plugin-jvm-openjdk-11 was already installed.

[ Risks ]

It is a small change and low risk.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

There is a piuparts regression, but it is due to a recent change in
adduser package, and not related at all to the change in uwsgi package.

unblock uwsgi/2.0.21-5.1
diff -Nru uwsgi-2.0.21/debian/changelog uwsgi-2.0.21/debian/changelog
--- uwsgi-2.0.21/debian/changelog   2023-02-24 06:50:43.0 -0500
+++ uwsgi-2.0.21/debian/changelog   2023-05-19 09:59:29.0 -0400
@@ -1,3 +1,10 @@
+uwsgi (2.0.21-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Replaces on uwsgi-plugin-jvm-openjdk-11 (Closes: #1035005)
+
+ -- James Valleroy   Fri, 19 May 2023 09:59:29 -0400
+
 uwsgi (2.0.21-5) unstable; urgency=medium
 
   * skip shellcheck test when DEB_BUILD_OPTIONS=nocheck;
diff -Nru uwsgi-2.0.21/debian/control uwsgi-2.0.21/debian/control
--- uwsgi-2.0.21/debian/control 2023-02-24 06:49:44.0 -0500
+++ uwsgi-2.0.21/debian/control 2023-05-19 09:59:29.0 -0400
@@ -616,6 +616,8 @@
  uwsgi-core (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends},
+Replaces: uwsgi-plugin-jvm-openjdk-11 (<< 2.0.21-1)
+Breaks: uwsgi-plugin-jvm-openjdk-11 (<< 2.0.21-1)
 Description: Java plugin for uWSGI (OpenJDK 17)
  uWSGI presents a complete stack for networked/clustered web applications,
  implementing message/object passing, caching, RPC and process management.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036313: php-slim-psr7: Useless (and harmful) dependency on (recent) php-symfony-polyfill-php80

2023-05-20 Thread William Desportes

Control: forwarded -1
https://salsa.debian.org/php-team/pear/php-slim-psr7/-/commit/d2e579fa2202265888baf9649cadce7f924fd93b
Control: found -1 php-slim-psr7/1.6.1-1~bpo11+1

Hi David,

This is a complicated subject that I already brought to you, but there is no
easy solution.

First, for the backports version: thank you for reporting this bug !
There is no change impacting the library in the diff:
https://github.com/symfony/polyfill-php80/compare/v1.22.0...v1.26.0
Lowering the version was already done for phpMyAdmin's PPA for Ubuntu jammy.
So I lowered the required version to symfony/polyfill-php80 1.22 available in
Bullseye to fix this bug.

Secondly, the subject that needs to be addressed: Users do what they want and
use php libraries on different versions that Debian was shipped with.
This is something some people want to avoid thinking about, but it's a reality.
- First point: Technically from a packaging stand point, there is no way to
block a library or app's usage with another version than the one shipped by
Debian.
It's only a deb file.
- Second point: if we could do that, the user could still run a library or app
on a different PHP version.

The only way is that the code must protect itself from being run on another
version of PHP.
So if "pkg-php-tools" autoloader tool would add some code in the autoloader to
ensure PHP classes are not run on a different PHP version then yes we can drop the
polyfill libraries.
The code would be protecting itself and we would avoid problems like:
https://bugs.launchpad.net/ubuntu/+source/phpmyadmin/+bug/2016016

The top stack solution we had to do on Ubuntu since one library did screw up
it's packaging was to force phpMyAdmin to require PHP 8.
Since the code did not protect itself, and this all resulted in a crash.
Ref:
https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/phpmyadmin/+git/phpmyadmin/+merge/442711

I am awaiting the proper changes in Debian's packaging tools to be able to move
out of polyfills.

PHP multi version support is complicated. Users do what they want. And as a
maintainer of the tools, I have the angry
users to handle when the proper safeties and polyfills are not in place when
they decide to use another PHP version to run the tool/library packaged.

https://github.com/phpmyadmin/phpmyadmin/issues/17523 and
https://github.com/phpmyadmin/phpmyadmin/issues/17503 reflect that.

I will not be dropping the dependency on the polyfill because upstream is
requiring it, and because users will run the code on other versions.
And you can not even argue with the users, that will not understand. Upstream
says it supports PHP 7.4 so it does:
https://github.com/slimphp/Slim-Psr7/blob/1.6.x/composer.json#L31
And makes the polyfill required.
The users do not even know how things are packaged and will blame you for it
anyway.
Conclusion: I am not considering going blind about what users do with their
Debian and Ubuntu releases. They install tools from other sources. Ref: deb
sury for other PHP versions.

I hope you understand, maybe something can be done to ensure the code protects
itself for example adding a bit of code to abort execution when it's used on
another version that for example:
- The php constraint on composer.json
(https://github.com/slimphp/Slim-Psr7/blob/1.6.x/composer.json#L31)
- Or the Debian shipped version of PHP

Let me know your thoughts.

--
William

Bug#1036422: RM: cgilib -- RoQA; low popcon; orphaned


Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Severity: normal

Please remove cgilib. The package has no reverse dependencies and a low popcon.
Upstream released a newer version 2009 but there has been no activity since.

Bug#563096: sylpheed: Hide update menu item

Hi Ricardo,

>  You can disable checking in configuration, no more spamming.
>  To me removing the option for checking is like self-cheating and
>  trusting the Debian version is always the latest.
>  As a user why should I trust the debian maintainer about that? :)
>  And as the debian maintainer I'd like to be notified by the users if
>  I miss some release [0], so really don't see the point of removing
>  the option.

There's a mailing list of release announcements:

  There is also the sylpheed-announce ML (sylpheed-annou...@sraoss.jp)
  which deals only with release announcements.

I suppose this has been added after the bug got reported. In any case
now you can disable it in configure, since I think makes little sense
in Debian, and close the bug.

Best regards,
José Luis

Bug#1036399: piuparts: false positives for unowned files left after purge

2023-05-20 Thread Patrice Duroux

Hi David,

My two cents as I am just a user, but I would like to say to not worry
too much about those messages.
Looking here: https://piuparts.debian.org/bookworm/, you will see that:

successfully-tested
[...]
- but logfile contains unowned files after purge: 4511 passed
[...]

failed-testing
[...]
- due to unowned files after purge: 1 failed
[...]

If you look at most of the 'successfully-tested' cases and the
'failed-testing' case, you will observe the same INFO messages.
This confirms that it is due to a dependency of the emacs package and
not from the package it-self.

Regards,
Patrice

Bug#1036421: brag: please consider upgrading to 3.0 source format


Source: brag
Version: 1.4.1-2.2
Severity: wishlist

Dear maintainer,

This package is among the few that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.

Thanks,
Bastian

Bug#1036415: sylpheed: all keymappings missing except Select all in searched messages list

retitle 1036415 sylpheed: all keymappings missing except Select all in search 
messages list
thanks

Hi again,

It seems all keyboard mappings are missing in this list except Select
all.

Retitling accordingly.

Bug#1036419: bplay: please consider upgrading to 3.0 source format


Source: bplay
Version: 0.991-10.1
Severity: wishlist

Dear maintainer,

This package is among the few that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.

Thanks,
Bastian

Bug#1036418: bonnie++: please consider upgrading to 3.0 source format


Source: bonnie++
Version: 2.00a+nmu1
Severity: wishlist

Dear maintainer,

This package is among the few that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.

Thanks,
Bastian

Bug#1036417: binfmtc: please consider upgrading to 3.0 source format


Source: binfmtc
Version: 0.17-2.2
Severity: wishlist

Dear maintainer,

This package is among the few that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.

Thanks,
Bastian

Bug#1036416: baycomusb: please consider upgrading to 3.0 source format


Source: baycomusb
Version: 0.10-15
Severity: wishlist

Dear maintainer,

This package is among the few that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.

Thanks,
Bastian

Bug#1036415: sylpheed: delete key doesn't work on esarch messages dialog

Package: sylpheed
Version: 3.7.0-8
Tags: upstream
Severity: important

Hi,

Delete key isn't mapped in the list of searched messages, so it just
doesn't work. This is most important in Thrash messages since you can't
use the workaround of moving them to the Thrash folder, and the context
menu entry is missing (recently reported), which makes them impossible
to delete.

Regards,
JL

Bug#1036414: sylpheed: Select all and Delete missing from Searched messages context menu

Package: sylpheed
Version: 3.7.0-8
Tags: upstream

The follwing entries are missing from search messages dialog on the
results context menu:

- Select all
- Delete

Delete is most important, since in this case the keyboard shorcut is
also missing (I'm reporting this as well), and you can't just move out
searched messages in Thrash to nowhere, which makes them impossible to
delete.

Bug#1036356: stress-ng: autopkgtest failures on 32 bit architectures

2023-05-20 Thread Colin King (gmail)

Thanks for the update, I'm planning to make a stress-ng release that 
contains this fix before the end of next week to address this and 
several other issues.


Colin


On 19/05/2023 16:21, Benjamin Drung wrote:

Package: stress-ng
Version: 0.15.07-1
Severity: serious
Tags: patch
Justification: autopkgtest failures
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

The autopkg tests on 32 bit architectures fail. In Ubuntu, the attached
patch was applied to fix the autopkgtest:

   * Cherry-pick upstream commit "stress-pthread: use 64 bit tid_addr to fix
 stack clobbering on 32 bit platforms" and "stress-pthread: fix big endian
 tid addr for 32 bit systems" to fix test failures on 32 bit architectures
 (LP: #2019079)


Thanks for considering the patch.

Bug#1036413: asterisk-prompt-fr-armelle: please consider upgrading to 3.0 source format


Source: asterisk-prompt-fr-armelle
Version: 20070613-2.2
Severity: wishlist

Dear maintainer,

This package is among the few that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.

Thanks,
Bastian

Bug#1036412: appconfig: Missing copyright info in d/copyright


Source: appconfig
Version: 1.71-2.1
Severity: serious

Andy Wardley's copyright is missing from debian/copyright.
Please document it there.

Bug#950268: sunxi-fel: commands spl and uboot does not work

2023-05-20 Thread Arjun


On 20/05/23 20:08, Ian Campbell wrote:

On Fri, 2020-01-31 at 01:11 +0530, Arjun wrote:

Thank you for your report. I'm very sorry, I seem to have somehow
missed this bug when it originally arrived, I don't know how.


Both commands fail with a "usb_bulk_send() ERROR -7: Operation timed out" but
if i pull the code from upstream, even with the same commit as the one used in
Debian(6d598a0), it works.


That is rather odd. There are no meaningful changes to the upstream
code in this version of the package.

Where did you get uart0-helloworld-sdboot.sunxi from, since it was not
shipped in version 1.4.2+git20181114.6d598a-3, did you use the same
binary in both tests?

Possibly your freshly built version ended up using a different libusb,
since that is what usb_bulk_send is reporting an error from.

Are you in a position to test 1.4.2+git20221128.530adf-2 from Bookworm?
It is a much newer upstream snapshot so may have resolved your issue.

Thanks,
Ian.



You may close this bug. Its been a long while and i don't remember what 
i was trying to do here. It might also be not reproducible anymore.


-
Arjun

Bug#1036411: sylpheed: no option for getting thrash emptied on messages older than X days

retitle 1036411 sylpheed: no option for getting messages deleted from thrash 
after X days of being deleted
thanks

On Sat, 20 May 2023 17:17:57 +0200
José Luis González  wrote:

> I find no option for getting messages older than X days deleted from
> Thrash, only on Sypheed's exit.

Sorry, I meant the messages from Thrash that had been deleted X days
ago or more, not the messages that were sent that days ago, obviously :)

Retitling consequently.

Bug#1036411: sylpheed: no option for getting thrash emptied on messages older than X days

Package: sylpheed
Version: 3.7.0-8
Severity: important
Tags: upstream

I find no option for getting messages older than X days deleted from
Thrash, only on Sypheed's exit.

Like my recent save message report, this is something elementary that
should have been there since about version 1, and has a major effect on
the usability of the program, so marking as important.

Sorry Ricardo that I'm filing all these upstream bugs on Debian, but as
far as I know Sylpheed doesn't have a BTS.

Bug#1036398: sylpheed: Messages menu entries don't belong logically to Tools

Hi again,

I mistakenly asked for a Messages menu to be added for this. Upon
review, I think it makes sense on the existing Message menu.

Sorry for the confusion.

Bug#1036410: sylpheed: save message missing from the interface

Package: sylpheed
Version: 3.7.0-8
Severity: important
Tags: upstream

Hi,

Save message is missing from the interface. It's only possible to do
this with "File" -> "Export mail", and you would have to mark "Export
only selected messages". This is something quite usual, and it's not
that intuitive to do it in the existing way, so it makes a lot of sense
that it exists both in the Message menu and messages context menu.

With the number of features of Sylpheed, and at version 3.7, this is
something that shall have been there a long time ago, before
version 1 IMHO. Marking it as an important bug for that reason.

Bug#1035725: rdiff-backup bug

2023-05-20 Thread Otto Kekäläinen

Severity: important

Hi!

Yes, we could try push this into Bookworm, but importance needs to be
justified.

Can you explain the problem and severity of the issue, steps to reproduce
and maybe copy-paste the command and resulting error message too?

Bug#1036409: sylpheed: spell check language detection badly missing

Package: sylpheed
Version: 3.7.0-8
Severity: wishlist
Tags: upstream

Hi,

I find it terribly cumbersome to have to choose the spelling language
of each email message I compose. Auto detection would be trivial to
implement. All is needed is to measure the number of spelling "errors"
in each language, choosing the one with least "mistakes".

I would appreciate if this is implemented.

Thank you so much in advance.

Bug#1036408: sylpheed: wrap paragraph doesn't format the paragraph on compose

Package: sylpheed
Version: 3.7.0-8
Severity: important
Tags: upstream

Format paragraph (Control + L & Control + Alt + L) on compose window
doesn't actually format paragraphs, which is what is needed most often,
and rather trivial to implement. The need for formatting is, actually,
rather common. I will elaborate.

I think this "feature", as it stands, is badly posed. It makes no sense
in a program to force the user to format manually with a ruler, which
by the way, doesn't extend for the whole editing window, and expecting
mails to be sent with no formatting would be a complete no sense as well
since line length is limited in the standard to 1023 characters, and
auto-formatting them on display is actually made with MIME-HTML, which
Sylpheed doesn't support.

Besides, a paragraph isn't usually "wrapped", but formatted. Wrapping
the last line is, basically, the unusual case. When you edit you
basically need to reformat the whole thing.

And turning on auto-wrap isn't the solution either, as it breaks lines
that need to be left longer, which happens often in the internet (a
URL, for instance). Turning it on by default is usually not an option.

Bug#950268: sunxi-fel: commands spl and uboot does not work

2023-05-20 Thread Ian Campbell

On Fri, 2020-01-31 at 01:11 +0530, Arjun wrote:

Thank you for your report. I'm very sorry, I seem to have somehow
missed this bug when it originally arrived, I don't know how.

> Both commands fail with a "usb_bulk_send() ERROR -7: Operation timed out" but
> if i pull the code from upstream, even with the same commit as the one used in
> Debian(6d598a0), it works.

That is rather odd. There are no meaningful changes to the upstream
code in this version of the package.

Where did you get uart0-helloworld-sdboot.sunxi from, since it was not
shipped in version 1.4.2+git20181114.6d598a-3, did you use the same
binary in both tests?

Possibly your freshly built version ended up using a different libusb,
since that is what usb_bulk_send is reporting an error from.

Are you in a position to test 1.4.2+git20221128.530adf-2 from Bookworm?
It is a much newer upstream snapshot so may have resolved your issue.

Thanks,
Ian.

Bug#1036381: gnubg: Remove libcanberra (sound support)

2023-05-20 Thread Russ Allbery

Bastian Germann  writes:

> The package builds without the libcanberra-gtk-dev build dependency.
> Dropping it would help with the removal of libcanberra's gtk2 flavor
> because gnubg is its last reverse dependency.

> This will remove sound in the game but I do not think that this is
> important to play it.

I'm still hoping that upstream will port to GTK+ 3 (or later) before I
have to start removing functionality.  I realize that it's on borrowed
time, though, and I totally understand if the GNOME maintainers want to
remove some of these old libraries before the next release.

-- 
Russ Allbery (r...@debian.org)

Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386

2023-05-20 Thread Justin B Rye

RL wrote:
> Ansgar  writes:
>> On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote:
>>> My plan is therefore to ship i386 installer images
>>> for bookworm as normal (including bookworm point releases going
>>> forwards), but to disable those builds for testing/trixie
>>> ~immediately after the release.
>>
>> I suggest to already document this in the release notes for bookworm,
>> possibly in Section 2.1 (Supported architectures) or a subsection in
>> Section 5 (Issues to be aware of for bookworm).
> 
> I suspect few would re-read 2.1 on upgrade... but is release-notes is
> the best place to document what new installs can use? (maybe doesnt
> matter as there wont be any new installs!)

I would expect a debian-announce message when it happens.

>> Maybe something along these lines:
>>
>> +---
>> | Debian 12 is expected to be the last Debian release providing
>> | full support for i386.  Debian 13 will only partially support
>> | i386 and no longer provide installation media for i386.
>> |
>> | We recommend hosts still running the i386 port to be upgraded
>> | to amd64.  Legacy i386 software can be run using multi-arch,
>> | chroot environments or containers.
>> +---
> 
> We already have a bit about i386 now meaning i686, but i think OK to
> keep separate as that one is bookworm, and this is for the future
> 
> Adding links to explain jargon and adding markup: im hope ive got the right
> arch-related entities right here...
> 
>   
>
> Bookworm is the last Debian release with full support for 
> 
>

Title lines don't need to be full sentences; this could be just
" support to be reduced from trixie".

>
> The next release, trixie, will not have full support for the
>  architecture, for example there will be no official
> installer. 
>

Do we need a mention of the reason (i.e. that an increasing number of
upstreams are no longer supporting it)?

Perhaps the angle the Release Notes should be taking on this is to
announce what's going to happen for dist-upgrades to trixie/forkie.
When do we stop producing official Release Notes?

>
> Debian recommends converting systems using the 
> architecture to the 64-bit
> PC architecture (known as amd64) before bookworm
> becomes unsupported: 

How about "https://wiki.debian.org/CrossGrading;? I was worried that it
might be a pre-systemd relic, but apparently not.

> most computers manufactured since 2000 can use
> amd64.

I'd have guessed later, given that the i386 arch held the lead in
popcon until 2012 ("https://www.debian.org/News/weekly/2012/17/;), but
this may just be because I use junk hardware.

>
>
> You can still run legacy 32-bit software on 64-bit systems using  url="SystemVirtualization">containers
> 
> or in  url="Multiarch/HOWTO">multi-arch
> chroots.
>
>  
> 
> (but shld use the  entity for wiki links)
> 
> Perhaps https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995397 (Xen no
> longer supports 32-bit Xen PV guests) also relevent to the last para.

It would make a relevant link for the "increasing number of upstreams"
I was mentioning.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1035710: unblock: doc-debian/11.3

2023-05-20 Thread Sebastian Ramacher

Control: tags -1 moreinfo cofnirmed

On 2023-05-14 06:47:18 +0200, Joost van Baal-Ilić wrote:
> reopen 1035710
> retitle 1035710 unblock: doc-debian/11.3
> thanks
> 
> Please unblock package doc-debian
> 
> [ Reason ]
> The doc-debian package claims to ship the Constitution for the Debian Project,
> the Debian Social Contract and other Debian documents.  The versions of those
> documents are obsolete [obsolete], which makes the package as now in testing
> very buggy.
> 
> [ Impact ]
> Shipping obsolete foundational documents is misleading and therefore might
> lead to confusion.
> 
> [ Tests ]
> None.  (The package ships documentation only, no code is shipped in the
> binary package.)
> 
> [ Risks ]
> None.  The doc-debian package is a key package due to Priority: standard.  It
> acts as a leaf package: Its only true reverse depends is the 
> live-task-standard
> package.[reverse-depends]  In bug #1035913 however, it was shown that some
> autopkgtests failed with the new doc-debian due to changes in build
> environment. This issue now has been properly documented.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> [ Other info ] I made a mistake uploading doc-debian 11.0 to unstable; that 
> got
> accepted.  The version 11.3 is now available from experimental.  I've kept the
> diff minimal.  Earlier planned and implemented non-related fixes will, via
> experimental and unstable, end up in 13/trixie.
> 
> unblock doc-debian/11.3

Please go ahead with the upload to unstable. Remove the moreinfo tag
once the package is available.

Cheers
-- 
Sebastian Ramacher

Bug#1036407: sylpheed: compose mail shortcut doesn't work in compose window

Package: sylpheed
Version: 3.7.0-8
Severity: important
Tags: upstream

Control + M shortcut doesn't work in compose windows, effectively
preventing from opening a new compose message window while composing a
current one. This is something that happens often so such a restriction
only makes it difficult and tiresome to use Sylpheed, as it forces
you to open Sylpheed's window to be able to create it, and locate the
existing compose window afterwards, as Sylpheed window is likely to have
concealed the already existing compose window.

Bug#1036406: xfwm4: Working area list width artificially limited

Package: xfwm4
Version: 4.16.1-1
Severity: important
Tags: upstream

The width of the Working Area list displayed middle-clicking on desktop
is severely limited for no reason, preventing enough of the window
titles to be seen when they are long enough, which has a very major
effect on the usability of the feature.

This is a bit variable, since this list is displayed with a variable
width font, but it more or less displays only 22 characters from the
title. This is clipping 5 out of 10 windows on my desktop at this time.

It makes no sense to place a width limit on this list, since the space
needed is variable, can be actually a lot, and it's not known in
advance how much is needed. If anything only preventing the
window from being larger than the screen is necessary.

Bug#1036405: sylpheed: message subject in compose windows get clipped in some window managers' list

Package: sylpheed
Version: 3.7.0-8
Tags: upstream

Compose windows feature the string "Compose *" after the subject in the
window's title. This string effectively clips the message's subject,
which is more important, in my Window's manager (xfwm4) working areas
list, which includes windows, because the width of the window list is
limited.

I'm going to file another bug to xfwm because of the artificial width
limit, but I suspect the clipping is a Sylpheed bug.

Bug#1036404: lxpanel segfaults when returning from suspend

2023-05-20 Thread Eric Van Buggenhaut

Package: lxpanel
Version: 0.10.1-2
Severity: normal
X-Debbugs-Cc: ericv...@gmail.com

After waking up from suspend, my lxpanel crashes, everytime. Segfaults seems to 
be related to libgtk2.0

 lxpanel[107889]: segfault at 7f6c616e ip 7fd337024823 sp 
7fff01f0dc70 error 4 in libgtk-x11-2.0.so.0.2400.33[7fd336e24000+275000]
[125195.305791] Code: 1f 84 00 00 00 00 00 41 54 55 48 83 ec 08 48 85 ff 74 4c 
48 89 fd 49 89 f4 e8 b9 23 ff ff 48 89 c6 48 8b 45 00 48 85 c0 74 05 <48> 39 30 
74 0c 48 89 ef e8 a0 3c e0 ff 85 c0 74 24 48 83 c4 08 4c



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

Kernel: Linux 5.10.0-22-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 lxpanel depends on:
ii  libasound2   1.2.4-1.1
ii  libc62.36-9
ii  libcairo21.16.0-5
ii  libcurl3-gnutls  7.88.1-9
ii  libfm-gtk4   1.3.2-1
ii  libfm-modules1.3.2-1
ii  libfm4   1.3.2-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.74.6-2
ii  libgtk2.0-0  2.24.33-2
ii  libiw30  30~pre9-13.1
ii  libkeybinder00.3.1-2.1
ii  libmenu-cache3   1.1.0-1.1
ii  libpango-1.0-0   1.46.2-3
ii  libwnck222.30.7-6
ii  libx11-6 2:1.8.4-2
ii  libxml2  2.9.10+dfsg-6.7+deb11u4
ii  lxmenu-data  0.1.5-2.1
ii  lxpanel-data 0.10.1-2

Versions of packages lxpanel recommends:
ii  dunst [notification-daemon]   1.5.0-1
ii  libnotify-bin 0.7.9-3
ii  lxterminal [x-terminal-emulator]  0.4.0-1
ii  notification-daemon   3.20.0-4
ii  pavucontrol   4.0-2
ii  xkb-data  2.29-2
ii  xterm [x-terminal-emulator]   366-1+deb11u1

Versions of packages lxpanel suggests:
ii  firefox-esr [www-browser]   102.10.0esr-1~deb11u1
ii  google-chrome-stable [www-browser]  113.0.5672.92-1
ii  menu2.1.48

-- no debconf information

Bug#1035757: unblock: org-mode/9.5.2+dfsh-5

David Bremner  writes:

> 1m1.2s ERROR: FAIL: Package purging left files on system:
>   /root/.ssh/ not owned
>   /var/cache/private/ not owned
>   /var/lib/private/   not owned
>   /var/lib/systemd/coredump/  not owned
>   /var/lib/systemd/pstore/not owned
>   /var/log/private/   not owned
>

I dove down this rabbit-hole a bit, not enough to figure the ultimate
cause, but enough to notice these files are also because of
"apt install systemd". So no related to org-mode. FWIW, systemd is
pulled in by emacs-gtk.

d

Bug#1036354: unblock: iptables-persistent/1.0.20

2023-05-20 Thread gustavo panizzo

Hi

On May 20, 2023 10:42:20 AM UTC, Luca Boccassi  wrote:
>On Sat, 20 May 2023 at 11:29, gustavo panizzo  wrote:
>>
>> Hi
>>
>> On May 20, 2023 10:20:50 AM UTC, Luca Boccassi  wrote:
>> >On Fri, 19 May 2023, 15:39 gustavo panizzo,  wrote:
>> >
>> >> Package: release.debian.org
>> >> Severity: normal
>> >> User: release.debian@packages.debian.org
>> >> Usertags: unblock
>> >> X-Debbugs-Cc: bl...@debian.org
>> >>
>> >> Please unblock package iptables-persistent
>> >>
>> >> (Please provide enough (but not too much) information to help
>> >> the release team to judge the request efficiently. E.g. by
>> >> filling in the sections below.)
>> >>
>> >> [ Reason ]
>> >> The package is using alternatives to manage (systemd) aliases,
>> >> this is not recommended by the systemd maintainers.
>> >>
>> >> See bug report #1036147
>> >>
>> >>
>> >> I've added alternatives to this package back in 2019 to solve #926927
>> >> as a point of coordination with other firewall managers in Debian
>> >> (see https://lists.debian.org/debian-firewall/2019/08/msg0.html) but
>> >> the initiative never took off
>> >>
>> >>
>> >> [ Impact ]
>> >> This is (was) the only package in Debian which uses alternatives to
>> >> manage aliases, which makes it different from what admins expect
>> >>
>> >> [ Tests ]
>> >> This version of the package is clean in lintian and piuparts,
>> >> I've upgraded my systems and found no problems
>> >>
>> >>
>> >> [ Risks ]
>> >> I see no risks, if an admin locally have changed the override files,
>> >> we'll keep them as dpkg-bak
>> >>
>> >>
>> >> [ Checklist ]
>> >>   [x] all changes are documented in the d/changelog
>> >>   [x] I reviewed all changes and I approve them
>> >>   [x] attach debdiff against the package in testing
>> >>
>> >>
>> >> unblock iptables-persistent/1.0.20
>> >>
>> >
>> >Thanks for taking care of this - I just checked and cannot see the upload
>> >to unstable though?
>>
>> I'd prefer to wait for an ack from the release team
>
>Ok, in that case I think it should be explicitly mentioned that this
>is a 'preapproval' request.


How to do that? I hope is done now 


>
>Kind regards,
>Luca Boccassi

Bug#1036403: Unable to accept server certificate in Kalendar

2023-05-20 Thread mikus mikuskowy

Package: kalendar
Version: 22.12.3-1
User: Mikolaj
Severity: important

When I try to add remote (from my Nextcloud instance) calendar in KDE's
Kalendar app, I am not able to accept the server's (self signed)
certificate - the window completely freezes (window's title:
Server-Authentifizierung -- akonadi_davgroupware_resource_4), I cannot
click any button, even the buttons don't change their state (appearance)
when I hover or click them. When I try to close the window by clicking the
close button, it doesn't work. I also noticed another probably related bug
- when I try to add remote directory (SFTP connection) in Dolphin (when you
open Dolphin, you have "Network" category on left), I wasn't able to accept
server's ssh certificate, because the window also freezes. After a few
tries (I don't know how) I accepted it, but also got the following message
from KDE Plasma Desktop:


KNetAttach
Prüfung (Fehlgeschlagen)
Die Anwendung wurde unerwartet beendet.


I think that the problem may also be related with apps like Akonadi and
KNetAttach (and Wayland?) and the bug may also affect other KDE
applications, that allow to connect with remote servers.

I am using Debian 12 Bookworm (testing), KDE Plasma Desktop (version:
4:5.27.2-2, but the bug occured also on version 4:5.27.2-1) and Wayland.
plasma-framework version: 5.103.0-1
Qt version: 5.18.8
Kernel version: 6.1.27-1 amd64

I am using swiss keyboard layout and system language is Schweizer
Hochdeutsch (swiss german).

Bug#1036399: piuparts: false positives for unowned files left after purge

David Bremner  writes:

> Package: piuparts
> Version: 1.1.7
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> The following output from "piuparts -t /var/tmp --apt emacs" (also on 
> piuparts.debian.org) looks suss to me:
>
> 0m43.8s INFO: Warning: Package purging left files on system:
>   /root/.ssh/  not owned
>   /var/cache/private/  not owned
>   /var/lib/private/not owned
>   /var/lib/systemd/coredump/   not owned
>   /var/lib/systemd/pstore/ not owned
>   /var/log/private/not owned

I just verified that something creates /root/.ssh when I run "apt
install --no-install-recommends systemd" in a clean chroot.  So that
part is a bug in some other package (presumably systemd or a
dependency), not piuparts.

Bug#1036402: doc-debian: forwarded missing from tags lists

Package: doc-debian
Version: 6.5
Severity: important

Hi,

forwarded tag is missing from 

- tags list on tags command on bug-maint-mailcontrol.txt.gz
- the tags definition list from bug-maint-info.txt.gz

Regards,
JL

Bug#1036401: tools-dep-clojure/0.16.1264-3

2023-05-20 Thread Jérôme Charaoui


Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: team+cloj...@tracker.debian.org
Control: affects -1 + src:tools-dep-clojure

I would like to request an unblock to upload 
tools-dep-clojure/0.16.1264-3 which fixes a FTBFS bug.


- #1036386 - tools-deps-clojure: FTBFS without network access

[ Reason ]
The package currently FTBFS because the testsuite which runs during 
build requires network access.


[ Impact ]
Accepting this release should not have any impact beyond 
tools-dep-clojure itself. libtools-dep-clojure has no rdeps in bookworm.


[ Tests ]
Test-related FTBFS issue was reproduced and fixed locally. Autopkgtest 
are passing.


[ Risks ]
None that I can imagine considering the very small delta.

[ Checklist ]
   [x] all changes are documented in the d/changelog
   [x] I reviewed all changes and I approve them
   [x] attach debdiff against the package in testing


Thanks!

-- Jérômediff -Nru tools-deps-clojure-0.16.1264/debian/changelog 
tools-deps-clojure-0.16.1264/debian/changelog
--- tools-deps-clojure-0.16.1264/debian/changelog   2023-01-22 
22:02:21.0 -0500
+++ tools-deps-clojure-0.16.1264/debian/changelog   2023-05-20 
08:54:30.0 -0400
@@ -1,3 +1,9 @@
+tools-deps-clojure (0.16.1264-3) unstable; urgency=medium
+
+  * d/run-build-tests: skip test that requires internet (Closes: #1036386)
+
+ -- Jérôme Charaoui   Sat, 20 May 2023 08:54:30 -0400
+
 tools-deps-clojure (0.16.1264-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru tools-deps-clojure-0.16.1264/debian/run-build-tests 
tools-deps-clojure-0.16.1264/debian/run-build-tests
--- tools-deps-clojure-0.16.1264/debian/run-build-tests 2023-01-22 
22:02:21.0 -0500
+++ tools-deps-clojure-0.16.1264/debian/run-build-tests 2023-05-20 
08:54:30.0 -0400
@@ -12,6 +12,5 @@
 -e "(require '[clojure.tools.deps.util.dir-test])" \
 -e "(System/exit (if (clojure.test/successful? (clojure.test/run-tests
 'clojure.tools.deps.extensions.faken
-'clojure.tools.deps.extensions.test-git
 'clojure.tools.deps.gen.test-pom
 'clojure.tools.deps.util.dir-test)) 0 1))"

Bug#1036400: partman-jfs: JFS is on its way out, please remove from the installer

2023-05-20 Thread Adam Borowski

Package: partman-jfs
Severity: important

Hi!
The JFS filesystem is deprecated in the kernel: on life support since 2009
and with talks of removal altogether.  Thus, we really shouldn't offer to
format new setups with it.  There are people who kind-of remember JFS being
the fastest back in the day, and it's irresponsible to set them for failed
upgrades past Bookworm.

Thus: please remove JFS from the installer.


Meow!

Bug#932957: Please migrate Release Notes to reStructuredText

2023-05-20 Thread RL

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.documentation as well.

James Addison  writes:

> (someone who knows more may correct me, but I think it would be great to have
> the package available for install using apt in addition to the website)

Interesting idea, but who would use it - won't a release-notes package
always be a whole release out of date?

(and the build-dependencies take a huge amount of disk space for
something you only read once a cycle, alhtough maybe sphinx fixes that)

Bug#1036388: sylpheed: account is reset when mail is checked

retitle 1036388 account reset when mail is checked
tags 1036388 upstream
thanks

Hi again,

It turns out the bug doesn't happen when email is received, but rather
when it was checked by sylpheed, which makes it even more grave, since
it's resetting it every X minutes, 10 in my case.

Bug#1036399: piuparts: false positives for unowned files left after purge

Package: piuparts
Version: 1.1.7
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The following output from "piuparts -t /var/tmp --apt emacs" (also on 
piuparts.debian.org) looks suss to me:

0m43.8s INFO: Warning: Package purging left files on system:
  /root/.ssh/not owned
  /var/cache/private/not owned
  /var/lib/private/  not owned
  /var/lib/systemd/coredump/ not owned
  /var/lib/systemd/pstore/   not owned
  /var/log/private/  not owned


- -- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'testing')
Architecture: amd64 (x86_64)

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

Versions of packages piuparts depends on:
ii  debootstrap  1.0.128+nmu2
ii  debsums  3.0.2
ii  libjs-sphinxdoc  5.3.0-4
ii  lsb-release  12.0-1
ii  lsof 4.95.0-1
ii  mount2.38.1-5+b1
ii  piuparts-common  1.1.7
ii  python3  3.11.2-1+b1
ii  python3-debian   0.1.49

Versions of packages piuparts recommends:
ii  adequate  0.15.7

Versions of packages piuparts suggests:
pn  docker.io  
ii  schroot1.6.13-3+b2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmRouNgACgkQA0U5G1Wq
FSHw/g//YwVnH0E80KXR/8+Jd0wxln+7uV0RL4+37tTVUnDEW1zpRATFJ/fPvzaO
Oih497KyhqQMGyAmXHyBE1dAuzkdH5c5njOwx+5xJwNEs13GKf1AIo6g25g2vBWp
2205rcaguq47+IMBp0TvkvqO5rMKblzkKoV1v4yik4qNmxZXLHW/asFEeWkyy3aV
vrOcfHpt+znmwsx68AoXLyWGdYeK3Gvkm4i7fNssVOD3Ybfw/7Mr0Md2aexrcKB0
n4BpchI1zamvo5awgyqY8yhXAJWsZfeEkOhcyQ6d1+vr3+Kw9VFqCDkfPwN1nUb7
+EM/cVyHOM4WF2yaiSn4VQgHgpt4aec2hKJ9Fi0hXyTwFOpjMett0zB22LthR5aF
MgEYIzY2T4WiwsbdfO6v239qTc4KSDWrXNqO4dpND1tpun5XNXO4HKQJnwmglVhy
HMj0xhsH3TcEnf9aWgRW4uSOijAQ3zPMA0oHCzc53CFeBI8JQqegJNjLtJJ0djGs
Cc1iVc6lvW4nk7m5u8ZWkss2ywtjmEiHCJwA5qCY7R9hiCpfp1bSOpAuYsTL24j2
EkbUXM/AX7CRBD9YsGSK7yVRjygP7RN/3bgG+cac86mSrUPHs+51PpipqLaqcVur
XEqOUTDM/baxLIAPpqSYjeTPnVCKJI6X/YJ7nxlNpJX4t1ktSYc=
=rY+H
-END PGP SIGNATURE-

Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386

2023-05-20 Thread RL

Ansgar  writes:

> On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote:
>> My plan is therefore to ship i386 installer images
>> for bookworm as normal (including bookworm point releases going
>> forwards), but to disable those builds for testing/trixie
>> ~immediately after the release.
>
> I suggest to already document this in the release notes for bookworm,
> possibly in Section 2.1 (Supported architectures) or a subsection in
> Section 5 (Issues to be aware of for bookworm).

I suspect few would re-read 2.1 on upgrade... but is release-notes is
the best place to document what new installs can use? (maybe doesnt
matter as there wont be any new installs!)

> Maybe something along these lines:
>
> +---
> | Debian 12 is expected to be the last Debian release providing
> | full support for i386.  Debian 13 will only partially support
> | i386 and no longer provide installation media for i386.
> |
> | We recommend hosts still running the i386 port to be upgraded
> | to amd64.  Legacy i386 software can be run using multi-arch,
> | chroot environments or containers.
> +---

We already have a bit about i386 now meaning i686, but i think OK to
keep separate as that one is bookworm, and this is for the future

Adding links to explain jargon and adding markup: im hope ive got the right
arch-related entities right here...

Bookworm is the last Debian release with full support for 

The next release, trixie, will not have full support for the
 architecture, for example there will be no official
installer. 

Debian recommends converting systems using the 
architecture to the 64-bit
PC architecture (known as amd64) before bookworm
becomes unsupported: 
most computers manufactured since 2000 can use
amd64.

You can still run legacy 32-bit software on 64-bit systems using containers

or in multi-arch
chroots.

(but shld use the  entity for wiki links)

Perhaps https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995397 (Xen no
longer supports 32-bit Xen PV guests) also relevent to the last para.

Bug#1036398: sylpheed: Messages menu entries don't belong logically to Tools

Package: sylpheed
Version: 3.7.0-8
Severity: important
Tags: upstream

There are six Tools menu entries that are not intrinsically tools
actions but Messages', and most are verbosely tagged as such in
their names instead of moving them their own menu, making Sylpheed hard
to use and inconvenient. A Messages menu would be necessary and
expected.

This seriously affects usability, so marking it as important.

Bug#1035436: rkdeveloptool: diff for NMU version 1.32+git20210408.46bb4c0-2.1

2023-05-20 Thread Christopher Obbard

Hi Andreas,

I uploaded a new version this morning with the fix; it has a -3 suffix so it 
should reject your NMU which had a -2.1 suffix.

As I am fairly new to Debian processes, it is great you have walked me through 
it.

Thank you!

On 20 May 2023 12:07:03 BST, Andreas Metzler  wrote:
>On 2023-05-20 Christopher Obbard  wrote:
>[...] 
>> > I've prepared an NMU for rkdeveloptool (versioned as
>> > 1.32+git20210408.46bb4c0-2.1) and uploaded it to DELAYED/1.
>[...]
>> Thank you for your contribution, but it seems like there is some
>> parallel work (this morning in fact).
>
>> I am currently in the process of uploading and the fixes for this
>> package. Is it possible to skip this delayed version in favour of the
>> version I am about to upload ?
>
>Hello Christopher,
>
>if you upload before the NMU is accepted the NMU will simply be
>rejected because there is already a higher numbered version of the
>package in the archive. I can also simply cancel the NMU or bump the
>delay if you want me to. - Just tell me what your preference is.
>
>cu Andreas
>-- 
>`What a good friend you are to him, Dr. Maturin. His other friends are
>so grateful to you.'
>`I sew his ears on from time to time, sure'

Bug#1035975: [pre-approval] unblock: mmdebstrap/1.3.5-X

2023-05-20 Thread Johannes Schauer Marin Rodrigues

Hi,

Quoting Sebastian Ramacher (2023-05-20 13:38:20)
> > some of the packages uploaded to unstable or experimental are breaking the
> > mmdebstrap autopkgtest:
> > 
> >  - doc-debian rebuilt with debhelper (>= 13.4) changes the doc-base paths. 
> > This
> >is recorded as #1035913 and the change is intentional. Thus the 
> > mmdebstrap
> >autopkgtest has to be adjusted. The unblock bug for doc-debian was 
> > #1035710.
> >  - dash has an upload in experimental which removes its diversions. See bug
> >#989632 for details. The unblock bug is #1035745. I also adjusted the
> >autopkgtest to cope with those changes.
> >  - if it is decided for adduser to become Essential:yes or pseudo-essential
> >(instead of using Protected:yes) more changes are required. I didn't
> >implement those yet, because I'm still hoping that it will be decided to 
> > use
> >Protected:yes (in which case no changes are needed). Please consider
> >replying to my idea in #1035654
> > 
> > All of the needed changes only affect the autopkgtest. Nothing touches the
> > functionality shipped by the mmdebstrap binary package and thus, this 
> > unblock
> > cannot break anything (other than autopkgtest results).
> 
> Could you please provide a debdiff of the proposed changes?

this is the debdiff between mmdebstrap in testing and unstable:

diff -Nru mmdebstrap-1.3.5/debian/changelog mmdebstrap-1.3.5/debian/changelog
--- mmdebstrap-1.3.5/debian/changelog   2023-03-20 08:05:19.0 +0100
+++ mmdebstrap-1.3.5/debian/changelog   2023-05-11 14:53:04.0 +0200
@@ -1,3 +1,29 @@
+mmdebstrap (1.3.5-5) unstable; urgency=medium
+
+  * tests/jessie-or-older: dash 0.5.12-3 dropped diversions
+
+ -- Johannes Schauer Marin Rodrigues   Thu, 11 May 2023 
14:53:04 +0200
+
+mmdebstrap (1.3.5-4) unstable; urgency=medium
+
+  * tests/eatmydata-via-hook-dir: dash 0.5.12-3 dropped diversions
+
+ -- Johannes Schauer Marin Rodrigues   Thu, 11 May 2023 
06:57:42 +0200
+
+mmdebstrap (1.3.5-3) unstable; urgency=medium
+
+  * fix regex in debian/tests/copy_host_apt_config to first remove
+non-free-firmware and then non-free or otherwise components like
+"main-firmware" will be the result
+
+ -- Johannes Schauer Marin Rodrigues   Wed, 10 May 2023 
22:41:17 +0200
+
+mmdebstrap (1.3.5-2) unstable; urgency=medium
+
+  * fix for doc-debian 11.0 changing the doc-base paths
+
+ -- Johannes Schauer Marin Rodrigues   Sat, 06 May 2023 
19:15:48 +0200
+
 mmdebstrap (1.3.5-1) unstable; urgency=medium
 
   * New upstream version 1.3.5
diff -Nru 
mmdebstrap-1.3.5/debian/patches/0001-tests-doc-debian-11.0-changed-the-doc-base-paths.patch
 
mmdebstrap-1.3.5/debian/patches/0001-tests-doc-debian-11.0-changed-the-doc-base-paths.patch
--- 
mmdebstrap-1.3.5/debian/patches/0001-tests-doc-debian-11.0-changed-the-doc-base-paths.patch
 1970-01-01 01:00:00.0 +0100
+++ 
mmdebstrap-1.3.5/debian/patches/0001-tests-doc-debian-11.0-changed-the-doc-base-paths.patch
 2023-05-11 14:53:04.0 +0200
@@ -0,0 +1,81 @@
+From e27a8d34724673f4df07b5827c921a9b63903095 Mon Sep 17 00:00:00 2001
+From: Johannes Schauer Marin Rodrigues 
+Date: Sat, 6 May 2023 08:33:15 +0200
+Subject: [PATCH] tests: doc-debian 11.0 changed the doc-base paths
+
+---
+ tests/include   | 2 +-
+ tests/install-doc-debian| 2 +-
+ tests/install-doc-debian-and-test-hooks | 2 +-
+ tests/multiple-include  | 2 +-
+ tests/unpack-doc-debian | 2 +-
+ 5 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/tests/include b/tests/include
+index 95c9c69..e284b7d 100644
+--- a/tests/include
 b/tests/include
+@@ -3,7 +3,7 @@ set -eu
+ export LC_ALL=C.UTF-8
+ trap "rm -rf /tmp/debian-chroot" EXIT INT TERM
+ {{ CMD }} --mode=root --variant=apt --include=doc-debian {{ DIST }} 
/tmp/debian-chroot {{ MIRROR }}
+-rm /tmp/debian-chroot/usr/share/doc-base/debian-*
++rm /tmp/debian-chroot/usr/share/doc-base/doc-debian.debian-*
+ rm -r /tmp/debian-chroot/usr/share/doc/debian
+ rm -r /tmp/debian-chroot/usr/share/doc/doc-debian
+ rm /tmp/debian-chroot/var/lib/apt/extended_states
+diff --git a/tests/install-doc-debian b/tests/install-doc-debian
+index 81cb513..27d7f3e 100644
+--- a/tests/install-doc-debian
 b/tests/install-doc-debian
+@@ -24,7 +24,7 @@ tar -C /tmp/debian-chroot --owner=0 --group=0 
--numeric-owner --sort=name --clam
+ tar tvf /tmp/debian-chroot.tar > doc-debian.tar.list
+ rm /tmp/debian-chroot.tar
+ # delete contents of doc-debian
+-rm /tmp/debian-chroot/usr/share/doc-base/debian-*
++rm /tmp/debian-chroot/usr/share/doc-base/doc-debian.debian-*
+ rm -r /tmp/debian-chroot/usr/share/doc/debian
+ rm -r /tmp/debian-chroot/usr/share/doc/doc-debian
+ # delete real files
+diff --git a/tests/install-doc-debian-and-test-hooks 
b/tests/install-doc-debian-and-test-hooks
+index 6ad36eb..e69066c 100644
+--- a/tests/install-doc-debian-and-test-hooks
 b/tests/install-doc-debian-and-test-hooks
+@@ -27,7 +27,7

Bug#1036389: sylpheed: notification window displayed as system dialog, not actually not displayed