Bug#1062703: (no subject)

[Miguel A. Rojas]

Control: retitle -1 firmware-iwlwifi: Please update to newest kernel version

Hi there,

any updates on this bug on when the new version will be uploaded?

Regards

Bug#1069191: glibc: GLIBC-SA-2024-0004/CVE-2024-2961: ISO-2022-CN-EXT: fix^J out-of-bound writes when writing escape sequence

[Miguel Jacq]

On Mon, 22 Apr 2024 09:31:39 +0200 Charlemagne Lasse 
 wrote:
> Hi,
> 
> Can this be backported to older Debian versions via the security repo?
> This bug can be used to execute code when using the PHP engine:
>
> * https://www.offensivecon.org/speakers/2024/charles-fol.html
> * https://www.openwall.com/lists/oss-security/2024/04/18/4
>

Indeed.. I know that buster is old-old stable, but starting to get nervous that 
it
doesn't contain the fix that Bullseye and Bookworm have. Especially as we 
approach
the date of a security conference that will talk about this issue.

Is anyone on the LTS team working on it for Buster? That might also help trickle
down to ELTS for Stretch/Jessie?


signature.asc
Description: PGP signature

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Miguel Landaeta]

On Sun, Apr 28, 2024 at 11:51 PM Guilherme Puida Moreira
 wrote:
>
> Hi Miguel,
>
> On Sun, Apr 28, 2024 at 10:54:54PM +0100, Miguel Landaeta wrote:
> > Can you also reach out to upstream and send your man page contribution
> > there, so you can gather feedback and other users can benefit if they
> > decide to merge it?
>
> Will do. Thanks for the ping!

qbe: https://ftp-master.debian.org/new/qbe_1.2-1.html

> By the way, you mentioned that you had a preliminary hare package on
> #1058645. If you need any help, just let me know.

I'll double check what's pending. Luckily these packages should be
very straightforward. I remember one concern from one of the
co-maintainers about maybe introducing a separate package for harec
and I think I also spotted a directory in the binary package that
could be not compliant with the Debian policy and the expected
filesystem layout.

However, those issues should be quick to sort, I hope. I'll check
what's up and post an update on the hare ITP bug (#1058645) soon.


--
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1058645: Do you need help with this package?

[Miguel Landaeta]

I apologize for dropping the ball on this one.

I just uploaded qbe to the archive and it's now waiting for NEW processing.

https://ftp-master.debian.org/new/qbe_1.2-1.html

The next step for me here is to get back to this bug report soon with
a link to the salsa repo for hare so other folks can take a look,
provide feedback and get this package uploaded in a reasonable time
frame.

--
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Miguel Landaeta]

Hi folks,

I apologize I took me this long to work on qbe upload.

Guilherme, thanks for contributing a man page for qbe. I just included
it in the package.
Can you also reach out to upstream and send your man page contribution
there, so you can gather feedback and other users can benefit if they
decide to merge it?

Amin, I took some bias for action and I just uploaded the latest
changes in debian/latest to the archive. However, my upload just got
rejected because I forgot to include the source changes and did only a
binary upload. I don't have time today to fix that and retry so I'll
do that tomorrow unless you do it first (if you want or if you have
more changes pending that you want to include in the first upload).

I'll paste a link to this package NEW queue entry later so other users
can have visibility on the progress.

Thanks for your contributions!
Cheers,

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Miguel Landaeta]

On Wed, Apr 10, 2024 at 2:51 PM Guilherme Puida Moreira
 wrote:
>
> Hi Miguel,
>
> [...]
>
> I have written a very simple man page for qbe (see attached patch). I
> have never actually used qbe directly, so I'm not sure what else should
> be documented there. I figured that the cli options were a good starting
> point, though.
>

Hi Guilherme,

Thanks for the patch!

As you mentioned, this package is almost ready to be uploaded so I'll
try to prioritize it and upload it during the weekend.

Cheers,
Miguel.

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1065831: document package specifiers for `upgrade`

[Miguel Angel Rojas]

Hi all,

>>  No. Without a package as an argument it won't.

Thanks! You're right. Let me write it down here again:

   - "apt upgrade" (no argument) will never remove a package, only upgrade
   or install
   - "apt upgrade pkg_name" will remove, upgrade or install the required
   package to satisfy its dependencies.
   - "apt upgrade foo- bar+": advanced option that can be used to
   specifically removed or install packages.

>> Julian provided an explanation in #74,
20240312113620.ga1944...@debian.org

I can't access this link..

>> I'm not a Debian developer, never have been. Just someone who submitted
a patch or two.

And your comments have been really valuable in figuring out what's going
on! Again, my confusion was because this was the first time I reported a
bug AND several people jumped in the conversation! It is not usually the
case ;)

Regards

Bug#1065831: document package specifiers for `upgrade`

[Miguel Angel Rojas]

Hi all,

>> (modifiers btw is not a good word. I guess it was never documented so
far partly as this is a rather advanced feature and mainly because  naming
things is hard)

yes, we brought it up in our conversation but I agree it was not directly
related to the subject as it was an apt advanced option. But it was good
because we were able to compare different situations (to spice things up).
We even talked about "apt-get" and "aptitude" but I understand they are
different commands and the purpose was not to compare behaviours among
different tools.

>> Well, does it really matter who is and who isn't?

No, it doesn't as long as they have the right information ;)

Of course, the more people involved in the issue, the better perspective we
have on the problem. But it is important to know how apt is
*currently* behaving to avoid misunderstanding and wrong assumptions (even
from my side as well). We discovered that it is a documentation bug but my
initial premise when I opened the bug was that the resolver wasn't working
properly. With the right information, we usuallly get faster to the
solution. Thank you all, guys!

>> Nobody is born an APT developer, they are chosen based on their patch
offerings!
;)

Bug#1065831: document package specifiers for `upgrade`

[Miguel Angel Rojas]

Hi there,

> If "apt upgrade" is saying that it removes packages, that is a bug, yes.

@david: it is not a bug, apparently.

To put everything in a nutshell:

   - "apt upgrade" can remove packages
   - "apt upgrade" accepts specific packages to be upgraded

Therefore, this behaviour is expected and documentation needs to be
modified.

In the meantime, while the documentation is modified, can some developer
provide some explanation to the current "apt upgrade" behaviour? (*)

Thanks

(*) I'm a bit confused because I don't know which of the people involved in
this bug are actually a developer of the apt package ;)

Bug#1065831: apt upgrade : it removes packages when it shouldn't.

[Miguel Angel Rojas]

Control: retitle -1 apt upgrade : it removes packages when it shouldn't.

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel Rojas]

Control: retitle -1 apt upgrade : it removes packages when it
shouldn't.

The case you mentioned is a tricky one, yes: *apt upgrade foo+ bar-* (I
really don't know how apt handles it internally but having this option is
very useful. Of course, I wouldn't remove it).

I think it makes a lot of sense for "apt upgrade" to allow packages as
arguments. There should be a possibility to upgrade only a set of packages
and it comes in handy in some situations (i.e.: t64 upgrade). "apt upgrade"
also doesn't mark upgraded packages as manually installed (as expected).
But "apt install" does mark them as manually installed (as expected too).

Therefore, I see 2 options here:

a) Change apt documentation to include the current behaviour. But if so, it
should *NOT* remove any packages.
b) Remove the possibility to specify packages to upgrade as arguments
(which I don't really recommend for the reasons stated above).

Anyway, I think some clarification is needed from the developers to shed
some light on this.

Regards

On Tue, Mar 12, 2024 at 3:12 AM Wesley Schwengle 
wrote:

> On Mon, Mar 11, 2024 at 11:32:24PM +0100, Miguel Angel Rojas wrote:
> > > I see. It looks like `apt upgrade ' behaves as `apt install
> > > '. Which (to me) is unexpected behaviour, as the man page is
> > quite
> > >clear on its behaviour (man 8 apt-get):
> >
> > Well, clearly it shouldn’t. To begin with, “apt install” should mark a
> > package as manual installed while “apt upgrade” shouldn’t (my
> assumption).
> > And you’re right that “apt install” can remove a package if needed to
> > satisfy dependencies.
> >
> > On top of that, documentation clearly states that “apt upgrade” should
> not
> > remove any package, but it does when you specify an individual package to
> > upgrade.
> >
> > If this is not the expected behavior, maybe this is a bug (unless I am
> > missing something here).
>
> I do not know what the bug here is, it could be one of these options:
>
> 1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
>doesn't. The behaviour needs to change to not accept packages.
>
> 2) apt-get/apt upgrade accepts packages and removes packages to satisfy
> deps
>where the docs state it doesn't. The behaviour need to change to not
> remove
>any packages. There is a small edge case where you can say: `apt
> upgrade foo
>bar-'. Technically, it shouldn't remove packages, yet you want and
> instruct
>it to remove bar.
>
> FWIW, aptitude does not remove packages where you call `aptitude
> safe-upgrade
> foo'. It does remove packages when you call `aptitude full-upgrade foo'. It
> also removes bar when you run `aptitude safe-upgrade foo bar-'.
>
> I'll leave this for the maintainers to answer.
>
> Cheers,
> Wesley
>
>

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel Rojas]

> I see. It looks like `apt upgrade ' behaves as `apt install
> '. Which (to me) is unexpected behaviour, as the man page is
quite
>clear on its behaviour (man 8 apt-get):

Well, clearly it shouldn’t. To begin with, “apt install” should mark a
package as manual installed while “apt upgrade” shouldn’t (my assumption).
And you’re right that “apt install” can remove a package if needed to
satisfy dependencies.

On top of that, documentation clearly states that “apt upgrade” should not
remove any package, but it does when you specify an individual package to
upgrade.

If this is not the expected behavior, maybe this is a bug (unless I am
missing something here).

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel Rojas]

Hi Wesley, David,

> You keep saying `apt upgrade' yet your command was `apt full-upgrade'.

Yes, maybe it didn't express itself properly. After your suggestion about
not using "apt full-upgrade" during this t64 migration, I followed your
advice and used only "apt upgrade" for individual upgrades. I was referring
to this comment you made below:

> My advice to you is: don't expect full-upgrade to work until the
transitioning
> is done. You can do `apt upgrade' without too much hassle. If you feel
like it
> you can inspect individual upgrades possibilities  via `apt list
--upgradable'
> and upgrade each package individually.

Therefore, that's the advice I'm following right now.

Now, If I type"apt upgrade" doesn't give me any option to update anything:

# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
 linux-headers-6.6.15-amd64 linux-headers-6.6.15-common
linux-image-6.6.15-amd64 linux-kbuild-6.6.15
Use 'apt autoremove' to remove them.
The following packages have been kept back:
 gstreamer1.0-plugins-bad gstreamer1.0-plugins-good
gstreamer1.0-plugins-ugly kaddressbook kmail knotes
 libgstreamer-plugins-bad1.0-0 libkf5akonadisearch-bin
libkf5akonadisearch-plugins
 libkf5messagecomposer5abi1 libkf5messagecore5abi1 libkf5messagelist5abi1
libkf5messageviewer5abi1
 libkf5mimetreeparser5abi1 libkf5pimcommonakonadi5abi1
libkf5templateparser5 libkf5webengineviewer5abi1
 libkpimaddressbookimportexport5 libldb2 libopenconnect5 libqt5webengine5
ppp samba-libs
0 upgraded, 0 newly installed, 0 to remove and 23 not upgraded.


But, in some situations, as you mentioned, individual package upgrades can
work and remove some problems. So what I did was to try some "apt upgrade"
on individual packages from that list. This time I try the ppp package:

# apt upgrade ppp
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
 linux-headers-6.6.15-amd64 linux-headers-6.6.15-common
linux-image-6.6.15-amd64 linux-kbuild-6.6.15
Use 'apt autoremove' to remove them.
The following packages will be REMOVED: <--- PACKAGE TO BE REMOVED
 libpcap0.8
The following NEW packages will be installed:
 libpcap0.8t64
The following packages have been kept back:
 gstreamer1.0-plugins-bad gstreamer1.0-plugins-good
gstreamer1.0-plugins-ugly kaddressbook kmail knotes
 libgstreamer-plugins-bad1.0-0 libkf5akonadisearch-bin
libkf5akonadisearch-plugins
 libkf5messagecomposer5abi1 libkf5messagecore5abi1 libkf5messagelist5abi1
libkf5messageviewer5abi1
 libkf5mimetreeparser5abi1 libkf5pimcommonakonadi5abi1
libkf5templateparser5 libkf5webengineviewer5abi1
 libkpimaddressbookimportexport5 libldb2 libopenconnect5 libqt5webengine5
samba-libs
The following packages will be upgraded:
 ppp
1 upgraded, 1 newly installed, 1 to remove and 22 not upgraded.
Need to get 511 kB of archives.
After this operation, 15.4 kB disk space will be freed.
,

As you can see here, I'm typing "apt upgrade ppp" and it removes a package
in this case: libpcap0.8 (sometimes more packages are removed).

Which is good, because libpcap0.8 is replaced by libpcap0.8t64 (as expected
in this t64 migration) but "apt upgrade ppp" is REMOVING a package (which
contradicts the specification).

@David: I will send you the file as you requested.

Regards

On Mon, Mar 11, 2024 at 5:44 PM Wesley Schwengle 
wrote:

>
> Hi Miguel,
>
> On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote:
> > > I do not know, at times I'm also wondering why it doesn't do it, but I
> > didn't
> > > take time to look at the code to understand what the resolver is doing.
> > Also,
> > > it was sort of expected. I think we can probably solve this is a more
> > > controlled manner. With the current t64 transitioning in unstable it is
> > > difficult to track down. Many updates so the situation now may differ
> > from the
> > > situation in an hour from now.
> >
> > Yes, it is confusing for me too. Without considering this t64 migration,
> > “apt upgrade” should *NOT* remove any package (just upgrading a package
> to
> > a newer version or install new dependencies). But it is removing packages
> > right now! i.e. again, with this t64 migration, it makes the old
> libraries
> > to be uninstalled and install the new *t64 version.
> >
> > Any thoughts why “apt upgrade” is removing packages even when
> documentation
> > says it shouldn’t? or is it a bug?
>
> You keep saying `apt upgrade' yet your command was `apt full-upgrade'. As
> said
> earlier, full-upgrade does indeed remove packages to be able to perform an
> upgrade. I haven't seen `apt upgrade' do that. So I cannot comment on apt
> doing
> something wrong when it isn't :)
>
> Cheers,
> Wesley
>

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel Rojas]

Hi Wesley,

Good conversation here. Let me give you some comments from my side:

> No, there is (or was) something going on with the dependencies of
gdm-minimal
> for sure. I think it is related to libdebuginfod1, which has a t64
variant.
> This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64
> depends on libelf1t64 and libdw1t64. These two replace libelf1 and
libdw1, the
> former having a relative high count of reverse dependencies.

I didn’t catch this one (and I spent a fair amount of time trying to find
out what was going on) ;) Thank you for spotting it!

> I do not know, at times I'm also wondering why it doesn't do it, but I
didn't
> take time to look at the code to understand what the resolver is doing.
Also,
> it was sort of expected. I think we can probably solve this is a more
> controlled manner. With the current t64 transitioning in unstable it is
> difficult to track down. Many updates so the situation now may differ
from the
> situation in an hour from now.

Yes, it is confusing for me too. Without considering this t64 migration,
“apt upgrade” should *NOT* remove any package (just upgrading a package to
a newer version or install new dependencies). But it is removing packages
right now! i.e. again, with this t64 migration, it makes the old libraries
to be uninstalled and install the new *t64 version.

Any thoughts why “apt upgrade” is removing packages even when documentation
says it shouldn’t? or is it a bug?

> I disagree (or agree) to some extent. The gdb-minimal has been held back
on my
> system for a long time. I removed it after I saw it was a remnant of a KDE
> experiment I did. The fact that I can install it now is a change from a
couple
> of days ago. The bug may be the same, but with how unstable it is now with
> this big transition, it's wise to leave it where we are now and break it
down
> into a more controlled reproduction path, where we don't have so many
moving
> pieces.

Yes, I fully agreed with that! Let’s wait until packages are fully settled
down. I have a feeling that it is the same bug but there is no way to probe
it with this transition going on.

Regards



On Mon, Mar 11, 2024 at 3:04 PM Wesley Schwengle 
wrote:

>
> Hello Miguel,
>
> On Mon, Mar 11, 2024 at 09:50:12AM +0100, Miguel Angel Rojas wrote:
>
> > >This problem isn't because of apt, the problem is that gdb-minimal/gdb
> > >  dependencies cannot be satified. A full-upgrade is the equivalent of a
> > >  dist-upgrade which will remove packages to resolve the dependencies.
> The
> > > problem you are facing is the t64 transition[1][2] where not all
> packages
> > are
> > >  transitioned.
> >
> > I haven't detected any "gdb | gdb-minimal dependencies that can't be
> > satisfied at this point. Everything seems to be OK with those packages.
>
> No, there is (or was) something going on with the dependencies of
> gdm-minimal
> for sure. I think it is related to libdebuginfod1, which has a t64 variant.
> This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64
> depends on libelf1t64 and libdw1t64. These two replace libelf1 and libdw1,
> the
> former having a relative high count of reverse dependencies.
>
> > >  My advice to you is: don't expect full-upgrade to work until the
> > transitioning
> > >   is done.
> >
> > You nail it here! I have managed to upgrade package by package but it is
> a
> > tedious process until the whole transition is completed.
>
> Some of them yes, but often after doing one, you can use `apt upgrade' to
> see if it resolved other problems (which in my case it does from time to
> time).
>
> > But "apt upgrade"
> > should not remove any packages according to its documentation (man apt)
>
> That is correct, but you were executing full-upgrade:
>
> > > On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote:
> > >
> > > > # apt full-upgrade
> > > > Reading package lists... Done
> > > > Building dependency tree... Done
> > > > Reading state information... Done
> > > > Calculating upgrade... Error!
> > > > Some packages could not be installed. This may mean that you have
> > > > requested an impossible situation or if you are using the unstable
> > > > distribution that some required packages have not yet been created
> > > > or been moved out of Incoming.
> > > > The following information may help to resolve the situation:
>
> > Why is this t64 upgrade working then as it is removing deprecated
> packages
> > for *t64 packages?
>
> I do not know, at times I'm also wondering why it doesn't do it, but I
> didn't
> take time to

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel Rojas]

Hi Wesley,

>This problem isn't because of apt, the problem is that gdb-minimal/gdb
>  dependencies cannot be satified. A full-upgrade is the equivalent of a
>  dist-upgrade which will remove packages to resolve the dependencies. The
> problem you are facing is the t64 transition[1][2] where not all packages
are
>  transitioned.

I haven't detected any "gdb | gdb-minimal dependencies that can't be
satisfied at this point. Everything seems to be OK with those packages.

>  My advice to you is: don't expect full-upgrade to work until the
transitioning
>   is done.

You nail it here! I have managed to upgrade package by package but it is a
tedious process until the whole transition is completed. But "apt upgrade"
should not remove any packages according to its documentation (man apt)

*"upgrade is used to install available upgrades of all packages currently
installed on the system from the sources configured via sources.list(5).
New packages will be installed if required to satisfy dependencies, but
existing packages will never be removed. If an upgrade for apackage
requires the remove of an installed package the upgrade for thispackage
isn't performed."*

Why is this t64 upgrade working then as it is removing deprecated packages
for *t64 packages?

>  This seems to be an more of an actual issue where dependencies are
declared but
>apt doing something weird. But that is an issue on bookworm where we
aren't
>getting poluted results because of a transitioning.

I'm glad you were able to replicate in bookworm (stable) it but I don't
think (at least in this case) it is related to the t64 transition. Same
errors on both distributions and I checked that gdb dependencies were
satisfied in unstable (I don't have a system running stable).

> I don't know either and that question should be redirected to the
> plasma-workspace maintainer.

good advice! I will.

Appreciate your support.

Thanks!


On Sun, Mar 10, 2024 at 8:20 PM Wesley Schwengle 
wrote:

> On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote:
>
> > # apt full-upgrade
> > Reading package lists... Done
> > Building dependency tree... Done
> > Reading state information... Done
> > Calculating upgrade... Error!
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> >
> > The following packages have unmet dependencies:
> >  plasma-workspace : Depends: gdb-minimal but it is not going to be
> installed or
> >  gdb
> > E: Error, pkgProblemResolver::Resolve generated breaks, this may be
> caused by held packages.
> >
>
> This problem isn't because of apt, the problem is that gdb-minimal/gdb
> dependencies cannot be satified. A full-upgrade is the equivalent of a
> dist-upgrade which will remove packages to resolve the dependencies. The
> problem you are facing is the t64 transition[1][2] where not all packages
> are
> transitioned.
>
> My advice to you is: don't expect full-upgrade to work until the
> transitioning
> is done. You can do `apt upgrade' without too much hassle. If you feel
> like it
> you can inspect individual upgrades possibilities  via `apt list
> --upgradable'
> and upgrade each package individually. That has worked well for me in the
> past
> week with aptitude, but it requires going through many offered solutions.
>
> > I've seen other users are experimenting the same issue:
> > https://groups.google.com/g/linux.debian.user/c/7gpQImSH-Cs
>
> This seems to be an more of an actual issue where dependencies are
> declared but
> apt doing something weird. But that is an issue on bookworm where we aren't
> getting poluted results because of a transitioning. It differs from yours
> because your apt output says "gdb-minimal but it is not going to be
> installed
> or gdb" so apt sees the alternative, but cannot install it either. IMHO,
> that should
> be filed as a seperate bug against apt on bookworm. And if possible
> checked on
> testing as well. FWIW, I can reproduce it on bookwork with apt, apt-get and
> aptitude, where the latter offers a solution to install gdb and not
> deinstall
> plasma-workspace.
>
> > I don't know why plasma-workspace depends on gdb
>
> I don't know either and that question should be redirected to the
> plasma-workspace maintainer.
>
> Cheers,
> Wesley
>
> [1] https://lists.debian.org/debian-devel-announce/2024/02/msg0.html
> [2]
> https://www.reddit.com/r/debian/comments/1b2ncdn/64bit_time_t_transition_in_progress_in_unstable/
>
>

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel]

Package: apt
Version: 2.7.13+b1
Severity: normal
X-Debbugs-Cc: mianro...@gmail.com

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

The following packages have unmet dependencies:
 plasma-workspace : Depends: gdb-minimal but it is not going to be installed or
 gdb
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.

I don't know why plasma-workspace depends on gdb, but nevertheless,
full-upgrade doesn't work.

I've seen other users are experimenting the same issue: 
https://groups.google.com/g/linux.debian.user/c/7gpQImSH-Cs

If you mark plasma-workspace as hold, apt is still trying to remove
other kde & plasma package (its reverse dependencies).


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Key "";
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Miguel Landaeta]

On Thu, Feb 22, 2024 at 09:46:00PM +, Amin Bandali wrote:
> On Thu, Feb 22, 2024 at 09:23:20PM +0000, Miguel Landaeta wrote:
> > On Thu, Feb 22, 2024 at 02:19:21AM +, Amin Bandali wrote:
> > > Hi Miguel,
> > > 
> > > I'm interested in helping with this.  Do you have the current state 
> > > of your work available on Salsa or elsewhere that I could pull in
> > > and work on?  Otherwise I'll just start with a repo under my own
> > > account and we could later transfer it to the 'debian' group or
> > > elsewhere.
> > 
> > Hi Amin, thanks for reaching out.
> > 
> > I'll push my repo tomorrow or during the weekend to salsa and
> > update this thread with the link.

Hi again Amin,

I just pushed my repo to Salsa:

https://salsa.debian.org/debian/qbe

The package builds fine on my machine but I didn't test this
qbe release yet with hare. I'll try to do that tomorrow when I push
my hare repo as well.

I think qbe is almost ready for an upload but it's missing a man page
and probably just need a review from another DD to be sure I didn't
miss anything important.

Cheers,
Miguel.


-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1058645: Do you need help with this package?

[Miguel Landaeta]

On Thu, Jan 18, 2024 at 07:50:29PM +0100, Martin Quinson wrote:
> Hello,
> 
> I'm wondering whether you need some help with the packaging of Hare. Is your
> current state available somewhere?

Hi Martin,

I apologize that I somehow missed this message in January.

I prepared a package a few weeks ago but I was waiting for qbe new
upstream release (#1058646) before proceeding with uploads to the
archive. 

Since I'm now noticing there are more folks interested in collaborating,
I'll prioritize this to push my repo to salsa this weekend so other
folks can help to get it ready or just reuse bits from other packaging
efforts if they meet Debian archive expectations.

I don't have my debian laptop handy but tomorrow I'll spend some time
on this and update this bug report with the repo link.

Cheers,
Miguel.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Miguel Landaeta]

On Thu, Feb 22, 2024 at 02:19:21AM +, Amin Bandali wrote:
> Hi Miguel,
> 
> I'm interested in helping with this.  Do you have the current state 
> of your work available on Salsa or elsewhere that I could pull in
> and work on?  Otherwise I'll just start with a repo under my own
> account and we could later transfer it to the 'debian' group or
> elsewhere.

Hi Amin, thanks for reaching out.

I'll push my repo tomorrow or during the weekend to salsa and
update this thread with the link.

I started to work on this package a few weeks ago but I decided to
wait for qbe 1.2 before uploading a package and I just noticed
it finally happened this week so I was planning to resume my work
on it.

I don't have time to work on it this weekend but I'll publish it
in a few hours to unblock you and other folks interested in
collaborating.

If you want, I can add you as co-maintainer.

Cheers,
Miguel.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2

[Miguel Angel Rojas]

Hi Diederik,

> While 'annoying', this is expected behavior. It tries to load the newest
(-83)
Yes, this is the expected behavior from our Linux kernel. However, I agree
with you and these messages are very annoying and should be removed.

> It could be it wouldn't be shown if it had already found one of the
earlier logged firmware files.
Interesting theory! When the new version of the firmware packages is
uploaded, we can check again if the "'iwl-debug-yoyo.bin" message disappears

Why are you confused with the numbers?
>Bit confused about that version number, but looks like success.

And yes, wifi is working fine although I haven't properly done any
performance test yet.

Regards


On Sun, Feb 11, 2024 at 4:15 PM Diederik de Haas 
wrote:

> Hi Miguel,
>
> On Sunday, 11 February 2024 16:03:20 CET Miguel A. Rojas wrote:
> > I forgot to include you the dmesg as promised:
> >
> > [2.235947] iwlwifi :00:14.3: enabling device ( -> 0002)
> > [2.237778] iwlwifi :00:14.3: Detected crf-id 0x1300504, cnv-id
> > 0x80401 wfpm id 0x8030
> > [2.237805] iwlwifi :00:14.3: PCI dev 7a70/0074, rev=0x430,
> > rfid=0x10a100
> > [2.237845] iwlwifi :00:14.3: firmware: failed to load
> > iwlwifi-so-a0-hr-b0-83.ucode (-2)
> > [2.237867] iwlwifi :00:14.3: firmware: failed to load
> > iwlwifi-so-a0-hr-b0-83.ucode (-2)
> > ... more firmware load failures
> > [2.238098] iwlwifi :00:14.3: Direct firmware load for
> > iwlwifi-so-a0-hr-b0-73.ucode failed with error -2
> > [2.241012] iwlwifi :00:14.3: firmware: direct-loading firmware
> > iwlwifi-so-a0-hr-b0-72.ucode
>
> While 'annoying', this is expected behavior. It tries to load the newest
> (-83)
> and when it can't find that, it tries an older one and ends up with '-72'.
>
> > [2.247819] iwlwifi :00:14.3: api flags index 2 larger than
> > supported by driver
> > [2.247832] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version:
> > 0.0.2.36
> > [2.248049] iwlwifi :00:14.3: firmware: failed to load
> > iwl-debug-yoyo.bin (-2)
> <-
> > [2.248067] iwlwifi :00:14.3: firmware: failed to load
> > iwl-debug-yoyo.bin (-2)
> <-
>
> This 'iwl-debug-yoyo.bin' is a familiar one, but this file is NOT
> available in
> the upstream linux-firmware repo.
> It could be it wouldn't be shown if it had already found one of the
> earlier
> logged firmware files.
> I might look into this particular issue at some later date.
>
> > [2.248078] iwlwifi :00:14.3: loaded firmware version
> > 72.daa05125.0 so-a0-hr-b0-72.ucode op_mode iwlmvm
>
> Bit confused about that version number, but looks like success ...
>
> > [2.653952] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201
> > 160MHz, REV=0x430
> > [2.769070] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
> > [2.769102] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
> > [2.769110] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
> > [2.769118] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
> > [2.769154] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100
> > [2.834751] iwlwifi :00:14.3: base HW address: bc:09:1b:d3:e2:ee
> > [2.849492] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0
> > [6.570171] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
> > [6.570263] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
> > [6.570275] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
> > [6.570307] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
> > [6.644756] iwlwifi :00:14.3: Registered PHC clock: iwlwifi-PTP,
> > with index: 0
> > [6.809353] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
> > [6.809386] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
> > [6.809397] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
> > [6.809408] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
>
> ... and from this it seems the device appears to be working properly?
>
> If that's indeed the case then this bug would essentially be a request for
> a
> new upstream version.
>
> Cheers,
>   Diederik

Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2

[Miguel A. Rojas]

Hi Diederik,

I forgot to include you the dmesg as promised:

[    2.235947] iwlwifi :00:14.3: enabling device ( -> 0002)
[    2.237778] iwlwifi :00:14.3: Detected crf-id 0x1300504, cnv-id 
0x80401 wfpm id 0x8030
[    2.237805] iwlwifi :00:14.3: PCI dev 7a70/0074, rev=0x430, 
rfid=0x10a100
[    2.237845] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-83.ucode (-2)
[    2.237867] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-83.ucode (-2)
[    2.237874] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-83.ucode failed with error -2 
<-
[    2.237879] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-82.ucode (-2)
[    2.237890] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-82.ucode (-2)
[    2.237896] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-82.ucode failed with error -2
[    2.237900] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-81.ucode (-2)
[    2.237916] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-81.ucode (-2)
[    2.237927] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-81.ucode failed with error -2
[    2.237932] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-80.ucode (-2)
[    2.237945] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-80.ucode (-2)
[    2.237955] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-80.ucode failed with error -2
[    2.237958] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-79.ucode (-2)
[    2.237968] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-79.ucode (-2)
[    2.237975] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-79.ucode failed with error -2
[    2.237978] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-78.ucode (-2)
[    2.237988] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-78.ucode (-2)
[    2.237994] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-78.ucode failed with error -2
[    2.237998] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-77.ucode (-2)
[    2.238007] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-77.ucode (-2)
[    2.238014] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-77.ucode failed with error -2
[    2.238018] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-76.ucode (-2)
[    2.238027] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-76.ucode (-2)
[    2.238034] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-76.ucode failed with error -2
[    2.238038] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-75.ucode (-2)
[    2.238052] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-75.ucode (-2)
[    2.238059] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-75.ucode failed with error -2
[    2.238062] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-74.ucode (-2)
[    2.238072] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-74.ucode (-2)
[    2.238078] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-74.ucode failed with error -2
[    2.238082] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-73.ucode (-2)
[    2.238091] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-73.ucode (-2)
[    2.238098] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-73.ucode failed with error -2
[    2.241012] iwlwifi :00:14.3: firmware: direct-loading firmware 
iwlwifi-so-a0-hr-b0-72.ucode
[    2.247819] iwlwifi :00:14.3: api flags index 2 larger than 
supported by driver
[    2.247832] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 
0.0.2.36
[    2.248049] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2) <-
[    2.248067] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2) <-
[    2.248078] iwlwifi :00:14.3: loaded firmware version 
72.daa05125.0 so-a0-hr-b0-72.ucode op_mode iwlmvm
[    2.653952] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 
160MHz, REV=0x430

[    2.769070] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
[    2.769102] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[    2.769110] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
[    2.769118] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
[    2.769154] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100
[    2.834751] iwlwifi :00:14.3: base HW address: bc:09:1b:d3:e2:ee
[    2.849492] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0
[    6.570171] iwlwifi :00:14.3: 

Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2

[Miguel Angel Rojas]

Hi Diederik,

My bad. Let me explain again. Taking into account the firmware errors:

   - Realtek messages are fixed now. There are no actions to be done here.
   - iwlwifi: If you are still working on a new version containing the -83
   file, that should fix some warning messages but not all of them. There is
   another message (*firmware: failed to load iwl-debug-yoyo.bin (-2)*)
   that I think is related to bug #966218. This bug has been there for a
   while, so I don't know what's happening here. Nobody explains what's going
   on or why this file is not included in the firmware package.

Thanks!


On Fri, Feb 9, 2024 at 7:48 PM Diederik de Haas 
wrote:

> Control: tag -1 moreinfo
>
> Hi,
>
> On Friday, 9 February 2024 19:35:01 CET Miguel A. Rojas wrote:
> > A few days ago, I went to
> >
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> > and update the missing loaded modules.
> >
> > Indeed, I noticed that I have another messages related to the iwlwifi
> > module: "kernel: iwlwifi :00:14.3: firmware: failed to load
> > iwlwifi-so-a0-hr-b0-83.ucode (-2)".
>
> The reason I asked for more dmesg lines is that it likely then tried
> (f.e.)
> -81, then -79 and then probably succeeded at some point.
> The Debian kernel (unfortunately imo) 'promoted' warning/info messages to
> errors, which make it appear more severe then they actually are.
>
> > I think the the root cause is that the current Debian packages firmware
> > packages are 6 months old and they need to be updated accordingly. New
> > Debian Linux kernel expects a specific version of the firmware or the
> > name of the firmware has changed.
>
> I do think that the old package versions are a problem, so I have been
> working
> on Merge Requests for updating them.
> Version 20230804 would make the -83 file available.
> But the device using and older version should still work. If it doesn't
> work
> with an older version, but it does work with a newer, that's important
> info.
>
> But I'm still a bit confused as this bug is about *realtek* firmware, not
> iwlwifi? Can you answer the question I asked previously?

Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2

[Miguel A. Rojas]

Hi Diederik,

A few days ago, I went to 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git 
and update the missing loaded modules.


Indeed, I noticed that I have another messages related to the iwlwifi 
module: "kernel: iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-83.ucode (-2)".


I think the the root cause is that the current Debian packages firmware 
packages are 6 months old and they need to be updated accordingly. New 
Debian Linux kernel expects a specific version of the firmware or the 
name of the firmware has changed.


Regards

O

Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2

[Miguel Angel]

Package: firmware-realtek
Version: 20230625-2
Severity: important
X-Debbugs-Cc: mianro...@gmail.com

At system boot, the following message is shown: 
"Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2".

It seesm that the firmware is not properly loaded by kernel at boot. 


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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1056612: retweet: Please remove this package

[Miguel Landaeta]

Control: severity -1 normal
Control: retitle -1 RM: retweet -- RoQA; unusable

Please remove retweet. It is unusable because of #996800 and even conceptually 
now that the Twitter API was hidden from public access.

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: qbe
  Version : 1.1
  Upstream Contact: Quentin Carbonneaux 
* URL : https://c9x.me/compile/
* License : MIT
  Programming Lang: C
  Description : Small embeddable C compiler backend

QBE is a compiler backend that aims to provide 70% of the performance
of industrial optimizing compilers in 10% of the code.
QBE fosters language innovation by offering a compact user-friendly
and performant backend. The size limit constrains QBE to focus on the
essential and prevents embarking on a never-ending path of diminishing
returns.

QBE is a build-dependency of Hare.
See https://c9x.me/compile/users.html for other QBE language frontends.

Bug#1058645: ITP: hare -- Hare is a systems programming language designed to be simple, stable, and robust.

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: hare
  Version : 2023.12.02
  Upstream Contact: Drew DeVault 
* URL : https://harelang.org/
* License : MPL/GPL-3
  Programming Lang: Hare
  Description : Hare is a systems programming language designed to be 
simple, stable, and robust.

Hare uses a static type system, manual memory management, and a
minimal runtime. It is well-suited to writing operating systems,
system tools, compilers, networking software, and other low-level,
high performance tasks.

Bug#1057843: (no subject)

[Miguel Jacq]

If it helps people, this is what I did on systems that automatically had 
rebooted into the problematic kernel.

First, I uninstalled the 6.1.0-14 kernel and rebooted back into 6.1.0-13.

Then I used `last` to identify the time between the problematic reboot into 
6.1.0-14 and the deliberate reboot (back in to 6.1.0-13)

This showed me that the 'problem time' was between 2023-12-10 06:00:00 and 
2023-12-10 19:00:00 (UTC).

>From there, I ran the followin gcommand to show me all files that were 
>modified more or less between that time. I ignore a bunch of things I don't 
>care about such as /var/log and other volatile parts of the filesystem.

find / -type f -newermt "2023-12-10 05:59:00" \! -newermt "2023-12-10 19:00:00" 
| egrep -v "/proc|/run|/sys|/var/log"

At least this gave me a somewhat small subset of files to manually check, which 
made it feel less daunting. Naturally it depends on your filesystem what files 
might've changed.

I was fortunate that none of the client applications I use, seem to use 
O_DIRECT, so I found no corrupted files (so far). 

Note that use of O_DIRECT is not a system-wide setting (e.g not one in 
/etc/fstab for the ext4 filesystem), it's something that each application can 
choose to use when working with files. For example, I have changed MySQL's 
innodb_flush_method to be O_DIRECT in the past (for performance), but it's not 
the default.

Out of the box, things like postgresql use fsync (not direct IO) by default.

I used some tools like 'git fsck' in git repositories that had changed during 
my 'problematic' time, and there were no issues - hopefully git does not use 
O_DIRECT.

I have not been able to find any definitive list of programs that use O_DIRECT 
out-of-the box. Maybe someone else will come up with such a list (if there even 
*are* programs that do so).

As others have said here, things like fsck won't likely help you, 
unfortunately. The nature of the bug is not one that corrupts the 
journaling/filesystem structure, it is more about the *contents* of the file, 
which fsck can't comment on.


Finally, I wanted to note: if you did `apt purge linux-image-6.1.0-14-amd64`, 
you might need to `apt install linux-image-amd64` (the meta package) before you 
can successfully pick up the new linux-image-6.1.0-15-amd64 automatically as a 
dependency (say, when doing apt update; apt dist-upgrade). At least, I needed 
to, as I think the purge automatically removed the meta package, leaving me 
with no *automatic* upgrade to the new kernel via those commands.

Good luck!

Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol

[Miguel Landaeta]

On Thu, Dec 7, 2023 at 3:46 PM Jérôme Charaoui  wrote:
>
> For the record, the upload is ready to go. I'm now only waiting for a
> new build-dependency to pass through NEW, jruby-mavengem.
>

Sounds great, I'll take a look at the new package. Thanks for working
on the 9.4 release.

On my side in the meantime, I recently have been refreshing and
updating several jruby build-dependencies like jnr-* package and a few
other related packages.

Bug#1057363: RM: twitterwatch -- RoQA; Upstream Dead; Useless with Twitter API Changes

[Miguel Landaeta]

On Tue, Dec 05, 2023 at 12:04:31AM -0500, Boyuan Yang wrote:
> 
> I am not the package maintainer for db2twitter or retweet, so I am not in the 
> position
> of saying whether I should object or not.
> 
> I see that you are also a Debian Developer; you should have the same 
> permission or right
> on RM bug submission as I do.

Ack.

I already pinged directly the maintainer for the packages I mentioned and I'll 
take action
soon if no answer is received.

I thought twitterwatch removal was asked as part of general QA process so 
that's why
I asked for those packages in the first place.

Cheers,
Miguel.

Bug#1057363: RM: twitterwatch -- RoQA; Upstream Dead; Useless with Twitter API Changes

[Miguel Landaeta]

On Mon, Dec 4, 2023 at 12:09 AM Boyuan Yang  wrote:
>
> [...]
>
> Dear Debian FTP Masters,
>
> As discussed in https://bugs.debian.org/1056613 , package twitterwatch makes 
> use
> of Twitter API, which is gone since 2023. Its upstream shows no activity for 
> 7 years,
> and the Debian package received no maintainer updates since 2016. As a 
> result, I
> believe we should have package twitterwatch removed from Debian archive.
>

Hi Boyuan,

Thanks for submitting this bug.

Do you have any objection to doing the same for db2twitter and retweet packages?

I think they are in the same situation.

Cheers,
Miguel.


-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1054747: ruby-octokit: FTBFS: ERROR: Test "ruby3.1" failed: Failure/Error: require 'pry-byebug'

[Miguel Landaeta]

On Fri, Oct 27, 2023 at 09:20:42PM +0200, Lucas Nussbaum wrote:
> Source: ruby-octokit
> Version: 4.20.0-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231027 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > Failure/Error: require 'pry-byebug'
> > 
> > Gem::MissingSpecError:
> >   Could not find 'pry' (~> 0.13.0) among 122 total gem(s)


A possible fix for this issue could be to just update pry-byebug package to a
more recent release.

https://github.com/deivid-rodriguez/pry-byebug/commit/a915f21fc63aa94473bbe7cb752c0fabacc3e567

pry-byebug 3.10.1 depends on a pry version that's in the archive.

https://packages.debian.org/source/unstable/pry

Bug#1057324: jcsp: Upgrade to 1.1.10

[Miguel Landaeta]

Source: jcsp
Version: 1.1-rc4-2.1
Severity: wishlist

I'm filing this mostly as help for the next maintainer (maybe myself in the 
future).

Upstream migrated to Github: https://github.com/CSPforJAVA/jcsp

1.1.10 release should be compatible with what is in the archive,
however upstream switched their Java package name from "org.jcsp" to "jcsp",
so probably new patches will be needed for some dependencies.

I don't have time now for work on this, that's why this is wishlist.


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1057042: [patch] Drop dependency on libjsr166y-java

[Miguel Landaeta]

tags 1057042 + patch
thanks

https://salsa.debian.org/clojure-team/clojure/-/merge_requests/3

diff --git a/debian/changelog b/debian/changelog
index bab9d0f0..138cc6b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+clojure (1.11.1-3) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Drop dependency on libjsr166y-java. (Closes: #1057042)
+
+ -- Miguel Landaeta   Sat, 02 Dec 2023 21:16:06 +
+
 clojure (1.11.1-2) unstable; urgency=medium
 
   * Change the symlinked maven artifact for libclojure-java from 1.11.x to
diff --git a/debian/control b/debian/control
index 0ccfb227..0d3523b4 100644
--- a/debian/control
+++ b/debian/control
@@ -50,7 +50,6 @@ Description: Lisp dialect for the JVM
 Package: libclojure-java
 Architecture: all
 Depends:
- libjsr166y-java,
  ${java:Depends},
  ${misc:Depends}
 Breaks: clojure (<< 1.9.0-3), clojure1.8 (<< 1.8.0-6), libclojure1.8-java (<< 
1.8.0-6)
diff --git a/debian/changelog b/debian/changelog
index bab9d0f0..138cc6b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+clojure (1.11.1-3) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Drop dependency on libjsr166y-java. (Closes: #1057042)
+
+ -- Miguel Landaeta   Sat, 02 Dec 2023 21:16:06 +
+
 clojure (1.11.1-2) unstable; urgency=medium
 
   * Change the symlinked maven artifact for libclojure-java from 1.11.x to
diff --git a/debian/control b/debian/control
index 0ccfb227..0d3523b4 100644
--- a/debian/control
+++ b/debian/control
@@ -50,7 +50,6 @@ Description: Lisp dialect for the JVM
 Package: libclojure-java
 Architecture: all
 Depends:
- libjsr166y-java,
  ${java:Depends},
  ${misc:Depends}
 Breaks: clojure (<< 1.9.0-3), clojure1.8 (<< 1.8.0-6), libclojure1.8-java (<< 1.8.0-6)

Bug#1056902: RM: libbytelist-java -- ROM; unused, obsolete

[Miguel Landaeta]

retitle 1056902 RM: libbytelist-java -- ROM; unused, obsolete
severity 1056902 normal
reassign 1056902 ftp.debian.org
thanks

As title says.

This package was used by JRuby but is obsolete nowadays.

All packages in the archive depending on this were migrated or removed,
so there is no more reason to keep it around.

Thanks,
Miguel.

Bug#1057042: libclojure-java: Please remove dependency on libjsr166y-java

[Miguel Landaeta]

Package: libclojure-java
Severity: normal
User: nomad...@debian.org
Usertags: cleanup

Dear Maintainer,

I think the dependency on libjsr166y-java should be dropped:

https://salsa.debian.org/clojure-team/clojure/-/blob/1c17628638ddee0073c7dfbfa911cd913f708ce1/debian/control#L53

clojure.parallel has been deprecated since several years ago:

https://groups.google.com/g/clojure-dev/c/zjm4eHy9vDE?pli=1

https://github.com/clojure/clojure/blob/master/src/clj/clojure/parallel.clj#L9

The code also provide instructions for anyone who still relies
on that deprecated feature on how to make it work.

I'd like to be able to ask for libjsr166y-java for removal from the
archive at some point in the future, if possible.

Thanks,


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libclojure-java depends on:
pn  libcore-specs-alpha-clojure  
pn  libjsr166y-java  
pn  libspec-alpha-clojure

libclojure-java recommends no packages.

libclojure-java suggests no packages.

Bug#1056692: libhamlib4: Add protective diversion for udev rules shared file

[Miguel Landaeta]

On Mon, Nov 27, 2023 at 6:54 AM tony mancill  wrote:
> Hello Miguel,
>
> Thank you for the patch.  I have applied it and tested locally and
> everything appears to be working correctly.  I have an upload ready
> prepared, but wanted to confirm with you that this lintian error is
> expected after applying the patch:
>
> E: libhamlib4: diversion-for-unknown-file 
> lib/udev/rules.d/60-libhamlib4.rules [preinst:14]
> N:
> N:   The named maintainer script adds a diversion for a file that is not 
> being provided by this package.
> N:
> N:   Visibility: error
> N:   Show-Always: no
> N:   Check: maintainer-scripts/diversion
>
> Should I add a lintian-override for it?

Hi Tony!

Yes, you are right.

I forgot to add the lintian override in my patch.

An override like the following should work for this:
https://salsa.debian.org/debian/libnjb/-/blob/master/debian/libnjb5.lintian-overrides

Thanks for looking at this patch.

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1056932: kakasi: Packaged version breaks transliteration to hiragana, doesn't happen with vanilla source build

[Miguel]

Package: kakasi
Version: 2.3.6-4.1
Severity: important
X-Debbugs-Cc: eseeseha...@yahoo.es

Dear Maintainer,

When using the prepackaged version of Kakasi in Debian 12, some texts are not
correctly transliterated from kanji to hiragana. Some characters just are
discarded. I think it did not happen in previous Debian releases but I'm not
fully sure. What I can certify is that:

- It works when building Kakasi from source in Debian 12, such as:

  $ apt-get source kakasi; rm -rf kakasi-2.3.6; tar xf kakasi-2.3.6.orig.tar.xz
  $ cd kakasi-2.3.6 ; ./configure ; make
  $ su -c "make install"

- It also works even when building Kakasi on Windows using MSVC (!)

To test the bug, execute the following command:

$ kakasi -iutf8 -s -JH

Then input the following text (the word "subetteru", "it's slipping"):

  滑ってる！？

The correct (expected) result should be:

  すべって る ！？

The current (broken) result is:

  て る ！？

Some transliterations are fine, some others are not. I don't know if it's a
build flag or what is exactly happening, but as I have managed to reproduce,
building Kakasi from source even in weird architectures (Android and Windows)
does not exhibit this behavior.

I am using the Kakasi dictionaries from Debian, just rebuilding the executable
/ library.

Thank you,
Miguel


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

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

Versions of packages kakasi depends on:
ii  kakasi-dic  2.3.6-4.1
ii  libc6   2.36-9+deb12u3

kakasi recommends no packages.

kakasi suggests no packages.

-- no debconf information

Bug#1056902: libbytelist-java: Package is obsolete and should be removed before trixie release

[Miguel Landaeta]

Package: libbytelist-java
Version: 1.0.15-1
Severity: serious

Filing this to get the package removed from testing.

No packages should add dependencies on libbytelist-java since this package is 
obsolete.
Its functionality is now included in JRuby (jruby.jar).

See note at https://github.com/jruby/bytelist

Once jvyamlb is removed (#1056899) from archive and ruby-psych its the 
dependency
on this package, it should be removed from unstable.


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libbytelist-java depends on:
ii  libjcodings-java  1.0.58-1

libbytelist-java recommends no packages.

libbytelist-java suggests no packages.

-- no debconf information

Bug#1056899: RM: jvyamlb -- ROM; obsolete, unneeded, dead upstream

[Miguel Landaeta]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: jvya...@packages.debian.org
Control: affects -1 + src:jvyamlb

As title says.

This package is unmaintained at upstream and in Debian.

No other packages are depending on this.

There are alternatives like SnakeYAML, Psych and others.

Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol

[Miguel Landaeta]

On Sat, Nov 25, 2023 at 12:29 AM Jérôme Charaoui  wrote:
>
> [...]
>
> I've been working on a 9.4 release, you can see the progress here:
> https://salsa.debian.org/lavamind/jruby
>
> I plan to upload this version to experimental within a few days, I still
> have some minor issues with the testsuite to iron out before.

Excellent, that's good to hear.
There is no point then just backporting the fix if you are close to
finishing preparing an upload.

Let me know if there is something else I can help with.
I think I'll take a look at some jnr-* dependencies packages that
could use a new upstream release and/or bugfixes.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol

[Miguel Landaeta]

Thomas and Jérôme,

Do you have any concerns with me uploading a fix for this issue?

I'm working with some folks here in Cambridge MiniDebConf and I
also have some cycles to spare to work on JRuby and maybe prepare
a new upstream release for 9.3 and/or 9.4 series (experimental).

Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol

[Miguel Landaeta]

tags 1042129 + patch
thanks

Upstream handled this when they upgraded Joni dependency to 2.2 on
JRuby 9.4 series.

https://github.com/jruby/jruby/commit/3c94d31f1e198f294e9bfcb96b4188c315252b6b

https://github.com/jruby/jruby/commit/783d14bcb140477bb2577310a90742d594a48896

See attached a fix for this issue.
diff -Nru jruby-9.3.9.0+ds/debian/changelog jruby-9.3.9.0+ds/debian/changelog
--- jruby-9.3.9.0+ds/debian/changelog   2023-01-16 21:08:51.0 +
+++ jruby-9.3.9.0+ds/debian/changelog   2023-11-24 11:48:05.0 +
@@ -1,3 +1,11 @@
+jruby (9.3.9.0+ds-9~miguel1) UNRELEASED; urgency=medium
+
+  * Fix FTBFS: adapt and backport changes from 9.4 releases
+to accomodate for changes in regexp library Joni 2.2.
+(Closes: #1042129)
+
+ -- Miguel Landaeta   Fri, 24 Nov 2023 11:48:05 +
+
 jruby (9.3.9.0+ds-8) unstable; urgency=medium
 
   * d/tests: flag jirb test as flaky
diff -Nru 
jruby-9.3.9.0+ds/debian/patches/0012-Use-Region-accessors-in-prep-for-privatizing-fields.patch
 
jruby-9.3.9.0+ds/debian/patches/0012-Use-Region-accessors-in-prep-for-privatizing-fields.patch
--- 
jruby-9.3.9.0+ds/debian/patches/0012-Use-Region-accessors-in-prep-for-privatizing-fields.patch
  1970-01-01 01:00:00.0 +0100
+++ 
jruby-9.3.9.0+ds/debian/patches/0012-Use-Region-accessors-in-prep-for-privatizing-fields.patch
  2023-11-24 11:48:05.0 +
@@ -0,0 +1,390 @@
+Subject: Use Region accessors in prep for privatizing fields
+Forwarded: 
https://github.com/jruby/jruby/commit/3c94d31f1e198f294e9bfcb96b4188c315252b6b
+--
+diff --git a/core/src/main/java/org/jruby/RubyMatchData.java 
b/core/src/main/java/org/jruby/RubyMatchData.java
+index 48fa92b..87e7c9d 100644
+--- a/core/src/main/java/org/jruby/RubyMatchData.java
 b/core/src/main/java/org/jruby/RubyMatchData.java
+@@ -175,11 +175,11 @@ public class RubyMatchData extends RubyObject {
+ private void updateCharOffsetOnlyOneReg(ByteList value, Encoding 
encoding) {
+ if (charOffsetUpdated) return;
+ 
+-if (charOffsets == null || charOffsets.numRegs < 1) charOffsets = new 
Region(1);
++if (charOffsets == null || charOffsets.getNumRegs() < 1) charOffsets 
= new Region(1);
+ 
+ if (encoding.maxLength() == 1) {
+-charOffsets.beg[0] = begin;
+-charOffsets.end[0] = end;
++charOffsets.setBeg(0, begin);
++charOffsets.setEnd(0, end);
+ charOffsetUpdated = true;
+ return;
+ }
+@@ -195,14 +195,14 @@ public class RubyMatchData extends RubyObject {
+ updatePairs(value, encoding, pairs);
+ 
+ if (begin < 0) {
+-charOffsets.beg[0] = charOffsets.end[0] = -1;
++charOffsets.setBeg(0, charOffsets.setEnd(0, -1));
+ return;
+ }
+ Pair key = new Pair();
+ key.bytePos = begin;
+-charOffsets.beg[0] = pairs[Arrays.binarySearch(pairs, key)].charPos;
++charOffsets.setBeg(0, pairs[Arrays.binarySearch(pairs, key)].charPos);
+ key.bytePos = end;
+-charOffsets.end[0] = pairs[Arrays.binarySearch(pairs, key)].charPos;
++charOffsets.setEnd(0, pairs[Arrays.binarySearch(pairs, key)].charPos);
+ 
+ charOffsetUpdated = true;
+ }
+@@ -211,14 +211,14 @@ public class RubyMatchData extends RubyObject {
+ if (charOffsetUpdated) return;
+ 
+ final Region regs = this.regs;
+-int numRegs = regs.numRegs;
++int numRegs = regs.getNumRegs();
+ 
+-if (charOffsets == null || charOffsets.numRegs < numRegs) charOffsets 
= new Region(numRegs);
++if (charOffsets == null || charOffsets.getNumRegs() < numRegs) 
charOffsets = new Region(numRegs);
+ 
+ if (encoding.maxLength() == 1) {
+ for (int i = 0; i < numRegs; i++) {
+-charOffsets.beg[i] = regs.beg[i];
+-charOffsets.end[i] = regs.end[i];
++charOffsets.setBeg(i, regs.getBeg(i));
++charOffsets.setEnd(i, regs.getEnd(i));
+ }
+ charOffsetUpdated = true;
+ return;
+@@ -229,23 +229,23 @@ public class RubyMatchData extends RubyObject {
+ 
+ int numPos = 0;
+ for (int i = 0; i < numRegs; i++) {
+-if (regs.beg[i] < 0) continue;
+-pairs[numPos++].bytePos = regs.beg[i];
+-pairs[numPos++].bytePos = regs.end[i];
++if (regs.getBeg(i) < 0) continue;
++pairs[numPos++].bytePos = regs.getBeg(i);
++pairs[numPos++].bytePos = regs.getEnd(i);
+ }
+ 
+ updatePairs(value, encoding, pairs);
+ 
+ Pair key = new Pair();
+-for (int i = 0; i < regs.numRegs; i++) {
+-if (regs.beg[i] < 0) {
+-charOffsets.beg[i] = charOffsets.end[i] = -1;
++for (int i = 0; i < regs.getNumRegs(); i++) {
++if (regs.getBeg(i) < 0) {
++charOff

Bug#1056692: libhamlib4: Add protective diversion for udev rules shared file

[MigueL Landaeta]

Package: libhamlib4
Version: 4.5.5-2
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: dep17p7
X-Debbugs-Cc: helm...@debian.org

Dear Maintainer,

libhamlib4 contains udev rules which are installed to /lib; these files
need to be moved to /usr/lib as part of Debian's usr-merge effort.
Because libhamlib4 is Multi-Arch: same, an unfortunate corner-case can
occur whereby shared files (such as the udev rules) may be erroneously
removed on upgrades (please see DEP17[1] P7: Shared multiarch file
loss).

I attached a patch which avoids the problem by implementating
DEP17 M10 (Protective diversions for shared files) for the affected files.

Please consider applying this patch at your earliest convenience. This
bug will be upgraded to release critical soon, as it blocks the overall
usr-merge effort which is being undertaken for the trixie release.

Best regards,
Miguel.

1. https://subdivi.de/~helmut/dep17.html



diff -Nru hamlib-4.5.5/debian/changelog hamlib-4.5.5/debian/changelog
--- hamlib-4.5.5/debian/changelog   2023-06-18 20:00:08.0 +0100
+++ hamlib-4.5.5/debian/changelog   2023-11-24 14:19:21.0 +
@@ -1,3 +1,9 @@
+hamlib (4.5.5-3) UNRELEASED; urgency=medium
+
+  * Install libhamlib4.rules into /usr, with protective diversion.
+
+ -- Miguel Landaeta   Fri, 24 Nov 2023 14:19:21 +
+
 hamlib (4.5.5-2) unstable; urgency=medium
 
   * Remove transitional packages libhamlib2-perl, libhamlib2-tcl,
diff -Nru hamlib-4.5.5/debian/libhamlib4.install 
hamlib-4.5.5/debian/libhamlib4.install
--- hamlib-4.5.5/debian/libhamlib4.install  2021-01-01 23:20:20.0 
+
+++ hamlib-4.5.5/debian/libhamlib4.install  2023-11-24 14:19:21.0 
+
@@ -1 +1,2 @@
 usr/lib/*/libhamlib.so.*
+debian/60-libhamlib4.rules usr/lib/udev/rules.d
diff -Nru hamlib-4.5.5/debian/libhamlib4.postinst 
hamlib-4.5.5/debian/libhamlib4.postinst
--- hamlib-4.5.5/debian/libhamlib4.postinst 1970-01-01 01:00:00.0 
+0100
+++ hamlib-4.5.5/debian/libhamlib4.postinst 2023-11-24 14:19:21.0 
+
@@ -0,0 +1,23 @@
+#!/bin/sh
+# postinst script for lihamlib
+
+set -e
+
+dpkg-maintscript-helper rm_conffile /etc/udev/60-libhamlib4.rules -- "$@"
+
+rm -f /etc/udev/rules.d/60-libhamlib4.rules
+
+# begin-remove-after: released:forky
+# protective diversion of files moved from / to /usr, to avoid file loss.
+# Only for upgrades.
+if [ "$1" = "configure" ]; then
+# At this point, the package will have installed the same file in */usr*.
+dpkg-divert --package usr-is-merged --no-rename \
+--divert /lib/udev/rules.d/60-libhamlib4.rules.usr-is-merged \
+--remove /lib/udev/rules.d/60-libhamlib4.rules
+fi
+# end-remove-after
+
+#DEBHELPER#
+
+exit 0
diff -Nru hamlib-4.5.5/debian/libhamlib4.postrm 
hamlib-4.5.5/debian/libhamlib4.postrm
--- hamlib-4.5.5/debian/libhamlib4.postrm   1970-01-01 01:00:00.0 
+0100
+++ hamlib-4.5.5/debian/libhamlib4.postrm   2023-11-24 14:19:21.0 
+
@@ -0,0 +1,21 @@
+#!/bin/sh
+# postrm script for libhamlib
+
+set -e
+
+dpkg-maintscript-helper rm_conffile /etc/udev/60-libhamlib4.rules -- "$@"
+
+# begin-remove-after: released:forky
+# protective diversion of files moved from / to /usr, to avoid file loss.
+# Only for upgrades.
+if [ "$1" = "remove" ] && [ "$DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT" = "1" ]; then
+# Cleanup in case package is removed before upgrade is finished (postinst 
ran).
+dpkg-divert --package usr-is-merged --no-rename \
+--divert /lib/udev/rules.d/60-libhamlib4.rules.usr-is-merged \
+--remove /lib/udev/rules.d/60-libhamlib4.rules
+fi
+# end-remove-after
+
+#DEBHELPER#
+
+exit 0
diff -Nru hamlib-4.5.5/debian/libhamlib4.preinst 
hamlib-4.5.5/debian/libhamlib4.preinst
--- hamlib-4.5.5/debian/libhamlib4.preinst  1970-01-01 01:00:00.0 
+0100
+++ hamlib-4.5.5/debian/libhamlib4.preinst  2023-11-24 14:19:21.0 
+
@@ -0,0 +1,20 @@
+#!/bin/sh
+# preinst script for libhamlib
+
+set -e
+
+dpkg-maintscript-helper rm_conffile /etc/udev/60-libhamlib4.rules -- "$@"
+
+# begin-remove-after: released:forky
+# protective diversion of files moved from / to /usr, to avoid file loss.
+# Only for upgrades.
+if [ "$1" = "upgrade" ]; then
+dpkg-divert --package usr-is-merged --no-rename \
+--divert /lib/udev/rules.d/60-libhamlib4.rules.usr-is-merged \
+--add /lib/udev/rules.d/60-libhamlib4.rules
+fi
+# end-remove-after
+
+#DEBHELPER#
+
+exit 0
diff -Nru hamlib-4.5.5/debian/60-libhamlib4.rules 
hamlib-4.5.5/debian/60-libhamlib4.rules
--- hamlib-4.5.5/debian/60-libhamlib4.rules 1970-01-01 01:00:00.0 
+0100
+++ hamlib-4.5.5/debian/60-libhamlib4.rules 2021-01-02 00:27:23.0 
+
@@ -0,0 +1,12 @@
+#
+# Enable uaccess for common embedded USB-serial converters so that
+# applications which call usb_detach_ker

Bug#1056625: RM: xhtmlrenderer -- ROM; outdated, unused

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

This package is obsolete.

No other package is the archive is depending on this.

Bug#1056623: RM: unsafe-mock -- ROM; unused, outdate

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

This package was used by JRuby during the transition to JDK >8.
There is no use for this anymore.

Bug#1056622: RM: unsafe-fences -- ROM; unused, obsolete

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

This package was used by JRuby during the transition to JDK >8.
There is no use for this anymore.

Bug#1056617: RM: yecht -- ROM; outdated, unused

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

JRuby stopped depending on yecht years ago.
There are no dependencies on this package in the archive.

Bug#1056614: RM: tweepy -- ROM; broken, obsolete, associated service doesn't exist anymore

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

This package and all Twitter related packages should be removed from the 
archive.

Twitter API access is broken, so there is no point keeping this in the archive.

Bug#1056613: twitterwatch: Please remove this package

[MigueL Landaeta]

Package: twitterwatch
Severity: important

Hi,

I intend to remove tweepy package from the archive since
Twitter service doesn't exist anymore and its API access
is also gone from quite some time, I believe.

Can you remove this package from the archive?

I don't think there is any use left for any Twitter related package
in Debian at this point.


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

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

Versions of packages twitterwatch depends on:
ii  python3 3.9.2-3
pn  python3-tweepy  

twitterwatch recommends no packages.

twitterwatch suggests no packages.

Bug#1056612: retweet: Please remove this package

[MigueL Landaeta]

Package: retweet
Severity: important

Hi,

I intend to remove tweepy package from the archive since
Twitter service doesn't exist anymore and its API access
is also gone from quite some time, I believe.

Can you remove this package from the archive?

I don't think there is any use left for any Twitter related package
in Debian at this point.


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

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

Bug#1056611: db2twitter: Please remove this package

[MigueL Landaeta]

Package: db2twitter
Severity: important

Hi,

I intend to remove tweepy package from the archive since
Twitter service doesn't exist anymore and its API access
is also gone from quite some time, I believe.

Can you remove this package from the archive?

I don't think there is any use left for any Twitter related package
in Debian at this point.


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

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

Versions of packages db2twitter depends on:
ii  python3 3.9.2-3
pn  python3-pil 
pn  python3-sqlalchemy  
pn  python3-tweepy  

db2twitter recommends no packages.

db2twitter suggests no packages.

Bug#1056610: RM: truffle-dsl-processor -- ROM; unused, outdated

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

It should be removed together with truffle.
See https://bugs.debian.org/1056609.

Bug#1056609: RM: truffle -- ROM; unused, outdated

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

This package was never really used for anything,
it was also never updated and as result the current
version in the archive is really outdated.

In its current state, it makes more sense to remove it,
until someone really has a real use and can provide an updated
version.

Bug#1056607: RM: modulator -- ROM; unused, obsolete

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

There is no use for this package and should be removed from the archive.

Bug#1010048: fs-uae-launcher: GUI is corrupted.

[Miguel A. Vallejo]

What a plot twist! :-)

Do you think there is any possibility to have fs-uae-launcher back in
Debian anytime soon?

Configuring FS-UAE by hand is tedious. we really need fs-uae-launcher
back in Debian

Thank you

Bug#1056339: graphicsmagick: providing graphicsmagick build with alternative quantum-depth

[David Miguel Susano Pinto]

Source: graphicsmagick
Version: 1.4+really1.3.40-4
Severity: wishlist
X-Debbugs-Cc: carandraug+...@gmail.com

Dear Maintainer,

A long time ago GraphicsMagick (and ImageMagick) were built with the
--quantum-depth option set to 8.  Both are now being built with it set
to 16.  I think that change was quite reasonable and a good default.

I'm requesting to have an alternative package built with quantum depth
set to 8.  This will reduce memory usage by half and make operations
faster for 8 bit (per channel) images (the vast majority).

The current package names already encode the quantum-depth option used
and in the case of ImageMagick, here's even packages built with and
without hdr support.  Because of this, I feel that a lot of the work
is already in place.

I'm happy to provide patches if this request meets with positive
interest and someone is willing to review the patches.

Best wishes
David

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

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

Bug#1010048: fs-uae-launcher: GUI is corrupted.

[Miguel A. Vallejo]

Hello

I revisited https://github.com/FrodeSolheim/fs-uae-launcher/issues/143
and I noticed user glaubitz is open to make the changes needed to have
this package back in Debian.

Dear maintainer, please explain to GitHub / glaubitz what is needed to
have fs-uae-launcher back in Debian.

Thank you

Bug#966218: firmware: failed to load iwl-debug-yoyo.bin (-2)

[Miguel A. Rojas]

found 966218 linux/6.5.6-1
found 966218 firmware-iwlwifi/20230515-3
Bug still running around ;)

regards

Bug#1053886: apt autoremove removes old kernel (ignoring default configuration)

[Miguel A. Rojas]

Hi there,

I think this could be related to the fact that current kernel packages 
naming convention don't match the regular expression in 
/etc/apt/apt.conf.d/01autoremove.


There are some '.' that the regular expression doesn't take care of.

NeverAutoRemove
 {
   "^firmware-linux.*";
   "^linux-firmware$";
   "^linux-image-[a-z0-9]*$";
   "^linux-image-[a-z0-9]*-[a-z0-9]*$";
 };

Regards

Bug#1053886: apt autoremove removes old kernel (ignoring default configuration)

[Miguel Angel]

Package: apt
Version: 2.7.3
Severity: normal
X-Debbugs-Cc: mianro...@gmail.com

Beside the fact that kernel packages should not removed by default
(according to /etc/apt/apt.conf.d/01autoremove), older kernel packages are 
removed
after executing 'apt autoremove'.

Regards

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Etc::preferencesparts "preferences.d";
Dir::Etc::trusted "trusted.gpg";
Dir::Etc::trustedparts "trusted.gpg.d";
Dir::Etc::apt-file-main "apt-file.conf";
Dir::Bin "";
Dir::Bin::methods "/usr/lib/apt/methods";
Dir::Bin::solvers "";
Dir::Bin::solvers:: "/usr/lib/apt/solvers";
Dir::Bin::planners "";

Bug#1051873: libcpucycles: Library was not compiled with architecture-specific options in some architectures like riscv64 or arm64

[Miguel Landaeta]

tags 1051873 + pending
thanks

https://salsa.debian.org/debian/libcpucycles/-/commit/6c83d7f861af9ed0db449407edfe792890e6bdc2

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons

[Miguel A. Rojas]

Hi,

When I described it as "horrible", I wanted to mean what you described 
(very small size and each character is 1 pixel or less, ;)). In my case, 
I have no background either and the button to select between X11 and 
Wayland can't be seen.


# ls -l /usr/share/sddm/themes/debian-breeze(4:5.27.7-2)
total 32
-rw-r--r-- 1 root root 23515 Aug  7 16:42 Main.qml
-rw-r--r-- 1 root root   543 Aug  7 16:42 metadata.desktop
-rw-r--r-- 1 root root   209 Aug  7 16:42 theme.conf


# ls -l /usr/share/sddm/themes/debian-breeze(4:5.27.8-1)
total 24
-rw-r--r-- 1 root root 23515 Sep 13 22:24 Main.qml

At least, metadata.desktop and theme.conf have disappeared with the new 
version of the package. When you restored those files from the previous 
packages, sddm seems to work fine (I haven't done any additional testing 
beside that the screen seems to look as it was).


Regards

On 16/9/23 12:55, Alexis Murzeau wrote:

Hi,

On Sat, 16 Sep 2023 00:55:12 +0200 Miguel Angel Rojas 
 wrote:

Hi there,

Downgrading the following packages:

   - sddm-themes-breeze
   - sddm-theme-debian-breeze

to version 4:5.27.7-2 makes sddm fully usable again with no issues.

It seems some changes have been made on version 4:5.27.8-1 that have 
broken

sddm.

I hope this helps.

Regards



I have issues too with sddm-theme-debian-breeze 5.27.8-1, but the 
symptom is different.
I get a correct screen, but the password field has a very small font 
size and each character is 1 pixel.


Using diffoscope, it appears sddm-theme-debian-breeze 5.27.8-1 doesn't 
have the theme.conf file.
Adding back theme.conf from version 5.27.7-2 with 5.27.8-1 installed 
fix the issue for me.


Note: metadata.desktop was also removed in 5.27.8-1, maybe it 
shouldn't too.



@Miguel, can you try to do the same to check if theme.conf is also the 
cause of your issues ?


That is, adding `/usr/share/sddm/themes/debian-breeze/theme.conf` with 
this content:


```
[General]
showlogo=hidden
logo=/usr/share/sddm/themes/breeze/default-logo.svg
type=image
color=#1d99f3
fontSize=10
background=/usr/share/desktop-base/active-theme/login/background.svg
needsFullUserModel=false
```


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

Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm-theme-debian-breeze depends on:
ii  plasma-framework   5.107.0-1
ii  plasma-workspace   4:5.27.8-1
ii  sddm-theme-breeze  4:5.27.8-1

Versions of packages sddm-theme-debian-breeze recommends:
ii  desktop-base  12.0.6+nmu1
ii  sddm  0.20.0-1

sddm-theme-debian-breeze suggests no packages.

-- no debconf information

Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons

[Miguel Angel Rojas]

Hi there,

Downgrading the following packages:

   - sddm-themes-breeze
   - sddm-theme-debian-breeze

to version 4:5.27.7-2 makes sddm fully usable again with no issues.

It seems some changes have been made on version 4:5.27.8-1 that have broken
sddm.

I hope this helps.

Regards

Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons

[Miguel Angel]

Package: plasma-workspace
Version: 4:5.27.8-1
Severity: important
X-Debbugs-Cc: mianro...@gmail.com

After upgrading from 4:5.27-7-1, sddm because unusuable. Background is
ignored (white), there are no button on the screen and the only thing you can
see on the screen is the icon showing the user and password field below
it (with very tiny asterisks) in a horrible format.


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

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

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus] 1.14.10-1
ii  drkonqi  5.27.8-1
ii  frameworkintegration 5.107.0-1
ii  gdb-minimal [gdb]13.2-1
ii  init-system-helpers  1.65.2
ii  iso-codes4.15.0-1
ii  kactivitymanagerd5.27.8-1
ii  kded55.107.0-1
ii  kinit5.107.0-1
ii  kio  5.107.0-1
ii  kpackagetool55.107.0-1
ii  kwin-common  4:5.27.8-1
ii  libappstreamqt2  0.16.3-1
ii  libc62.37-9
ii  libcolorcorrect5 4:5.27.8-1
ii  libcrypt11:4.4.36-2
ii  libfontconfig1   2.14.2-6
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-4
ii  libgps30 3.25-2
ii  libice6  2:1.0.10-1
ii  libicu72 72.1-3
ii  libkf5activities55.107.0-1
ii  libkf5activitiesstats1   5.107.0-1
ii  libkf5archive5   5.107.0-1
ii  libkf5authcore5  5.107.0-1
ii  libkf5baloo5 5.107.0-1
ii  libkf5bookmarks5 5.107.0-1
ii  libkf5calendarevents55.107.0-1
ii  libkf5completion55.107.0-1
ii  libkf5config-bin 5.107.0-1
ii  libkf5configcore55.107.0-1
ii  libkf5configgui5 5.107.0-1
ii  libkf5configwidgets5 5.107.0-2
ii  libkf5coreaddons55.107.0-1
ii  libkf5crash5 5.107.0-1
ii  libkf5dbusaddons55.107.0-1
ii  libkf5declarative5   5.107.0-1
ii  libkf5globalaccel-bin5.107.0-2
ii  libkf5globalaccel5   5.107.0-2
ii  libkf5guiaddons5 5.107.0-1
ii  libkf5holidays5  1:5.107.0-1
ii  libkf5i18n5  5.107.0-1+b1
ii  libkf5iconthemes55.107.0-1+b1
ii  libkf5idletime5  5.107.0-1
ii  libkf5jobwidgets55.107.0-1
ii  libkf5kcmutils5  5.107.0-2
ii  libkf5kexiv2-15.0.0  23.04.2-2
ii  libkf5kiocore5   5.107.0-1
ii  libkf5kiofilewidgets55.107.0-1
ii  libkf5kiogui55.107.0-1
ii  libkf5kiowidgets55.107.0-1
ii  libkf5networkmanagerqt6  5.107.0-1
ii  libkf5newstuff5  5.107.0-1
ii  libkf5newstuffcore5  5.107.0-1
ii  libkf5newstuffwidgets5   5.107.0-1
ii  libkf5notifications5 5.107.0-1
ii  libkf5notifyconfig5  5.107.0-1
ii  libkf5package5   5.107.0-1
ii  libkf5parts5 5.107.0-1
ii  libkf5people55.107.0-1
ii  

Bug#1051873: libcpucycles: Library was not compiled with architecture-specific options in some architectures like riscv64 or arm64

[Miguel Landaeta]

Source: libcpucycles
Version: 0~20230115-1
Severity: normal

After uploading 0~20230115-1 I inspected buildd logs and I noticed that on
several architectures like riscv64, arm64, ppc64el and a few others, the
package build failed to detect and use architecture-specific timer features
and ended using the default common OS-level mechanisms.

More details at: 
https://buildd.debian.org/status/package.php?p=libcpucycles=sid

riscv64 example:


[...]
riscv32-rdcycle.c:15:2: error: #error this code is only for riscv32 platforms
   15 | #error this code is only for riscv32 platforms
  |  ^
compilation terminated.
skipping option that did not compile
[...]

See more examples with full logs below:

https://buildd.debian.org/status/fetch.php?pkg=libcpucycles=arm64=0%7E20230115-1=1694543693=0

https://buildd.debian.org/status/fetch.php?pkg=libcpucycles=ppc64el=0%7E20230115-1=1694543637=0

https://buildd.debian.org/status/fetch.php?pkg=libcpucycles=riscv64=0%7E20230115-1=1694545286=0



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

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

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1032341: [INTL:ro] Romanian debconf templates translation of localepurge

[Miguel Figueiredo]

tags 1032341 + fixed peding

Bug#1051301: Package wavemon is outdated

[Miguel A. Vallejo]

Package: wavemon
Version: 0.9.1-1+b1
Severity: normal

Please, update the package wavemon. Current version in Debian unstable
is 0.9.1-1+b1 but the last version published is 0.9.4

A lot of improvements have been made, for example, splitting the TX
and RX lines (which solved bug 996671) or ipv6 support

Please upgrade it

Thanks in advance

Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot

[Miguel A. Vallejo]

Just after sending my previous message I noticed the following
versions were available after an apt upgrade:

grub2-common 2.12~rc1-9
grub-common 2.12~rc1-9
grub-efi-amd64 2.12~rc1-9
grub-efi-amd64-bin 2.12~rc1-9
grub-efi-amd64-signed 2.12~rc1-7

so I bit the bullet and made an upgrade.

It works. The computer boots normally. The only thing I noticed is the
grub screen saying version rc-1.7...

Shouldn't it be version rc-1.9?

Anyway, it works.

Thank you!

Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot

[Miguel A. Vallejo]

Hello

Just for your information.

I managed to get all grub packages

grub2-common
grub-common
grub-efi-amd64
grub-efi-amd64-bin
grub-efi-amd64-signed

updated to 2.12~rc1-7 and the system DOES NOT BOOT.

I downgraded all those grub packages to 2.06-3~deb11u5 (the one found
in stable) and it boots without problems.

So, I'm concerned if the  2.12~rc1-9 version will boot on my machine.

Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot

[Miguel A. Vallejo]

M. Zhou wrote:

> But after that I noticed that the most important
> package grub-efi-amd64-signed:amd64 (1+2.06+13,
> 1+2.12~rc1+7) was not upgraded along with the other
> grub packages.

You are right. I revised apt log and grub-efi-amd64-signed was NOT
updated, in fact, the version I have installed now is 1+2.06+13, but
all other grub packages have  2.06-3~deb11u5.

Now, if I run apt update, and apt list --upgradable it shows:

grub-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06-3~deb11u5]
grub-efi-amd64-bin/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06-3~deb11u5]
grub-efi-amd64-signed/unstable 1+2.12~rc1+7 amd64 [upgradable from: 1+2.06+13]
grub-efi-amd64/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06-3~deb11u5]
grub2-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06-3~deb11u5]


All of them with version 2.12~rc1-7

Is it safe to upgrade now? I'll wait a bit until I hear from the
package maintainers.

Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot

[Miguel A. Vallejo]

Package: grub2
Version: 2.12~rc1-7
Severity: critical

This morning I noticed an apt upgrade in Debian unstable/Sid upgraded
grub-common, grub2-common, grub-efi-amd64 and grub-efi-amd64-bin. The
upgrade went normally and no errors were shown. Then I turned the
computer off and after a few hours I tried to turn it on, but it
didn't boot, it tried to boot but finally showed the bios screen.

After booting with a live USB and chroot into the hard drive, I
downgraded those four packages to version 2.06-3~deb11u5, and after
run install-grub, the computer booted normally.

Anyone can confirm problems with version 2.12~rc1-7 and UEFI machines?

Thanks in advance.

Bug#1019494: localepurge: uses egrep and fgrep: fgrep/egrep: warning: egrep is obsolescent; using grep -F/-E

[Miguel Figueiredo]

tags 1019494 + fixed pending

Bug#1050940: linux: Enable Correctable Errors Collector RAS_CEC feature

[Miguel Bernal Marin]

Source: linux
Version: 6.5~rc7-1~exp1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com

Dear Maintainer,

Please enable the Reliability, Availability and Serviceability (RAS)
Correctable Errors Collector (RAS_CEC) feature on arch amd64/x86_64,
on Debian Trixie. 

RAS_CEC introduce a simple data structure for collecting correctable
errors along with accessors.

This is a small cache which collects correctable memory errors per 4K
page PFN and counts their repeated occurrence. Once the counter for a
PFN overflows, we try to soft-offline that page as we take it to mean
that it has reached a relatively high error count and would probably
be best if we don't use it anymore.

The error decoding is done with the decoding chain now and
mce_first_notifier() gets to see the error first and the CEC decides
whether to log it and then the rest of the chain doesn't hear about it -
basically the main reason for the CE collector - or to continue running
the notifiers.

When the CEC hits the action threshold, it will try to soft-offine the
page containing the ECC and then the whole decoding chain gets to see
the error.

To disable the Correctable Errors Collector, a kernel parameter is used:
>  ras=cec_disable

A MR was created with this proposal at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/827

Thanks,
Miguel Bernal Marin

Bug#1027976: ITP: libcpucycles -- Microlibrary for counting CPU cycles

[Miguel Landaeta]

https://ftp-master.debian.org/new/libcpucycles_0~20230115-1.html

Bug#1050353: linux: Enable System Trace Modules and Intel_TH_STH

[Miguel Bernal Marin]

Source: linux
Version: 6.5~rc6-1~exp1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com

Dear Maintainer,

Please enable the System Trace Module (STM) and the Intel Trace Hub Software
Trace Hub on arch amd64/x86_64, on Debian Trixie.

CONFIG_STM=m
CONFIG_STM_PROTO_BASIC=m
CONFIG_STM_PROTO_SYS_T=m
CONFIG_STM_DUMMY=m
CONFIG_STM_SOURCE_CONSOLE=m
CONFIG_STM_SOURCE_HEARTBEAT=m
CONFIG_STM_SOURCE_FTRACE=m
CONFIG_INTEL_TH_STH=m

System Trace Module (STM) is a kind of trace source device [1], which can not
only collect trace data from software sources, but also monitor hardware
events.

Any software program no matter where it is in kernel space or user space
can write STM device with message string (i.e. trace data), like using print
functions.

Each software or hardware trace source is assigned a unique pair of master
and channel, so that a decoder can know which source the trace data come
from by this.  As a kind of resource, the number of masters and channels
are limited, for example *Intel STH* has up to 65,536 masters
and up to 256 channels per master.

Unlike some traditional tracing approach which would lose all traces once system
crashed since the traces are stored in system memory, tracing with STM can
survive this kind of case because all traces collected via STM would end up in
sink device which can be still alive even the system is dead so long as the
hardware design allows it.There’s another benefit of using STM to collect
software traces or monitor hardware events.  Since everything is logged to the
same STM with timestamps, it is possible to correlate events happening in the
entire system rather than being confined to the logging facility of a single
entity.

A MR was created with this proposal at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/815

[1] https://www.linaro.org/blog/stm-and-its-usage/

Thanks,
Miguel Bernal Marin

Bug#1050342: linux: Enable Intel Trace Hub ACPI controller

[Miguel Bernal Marin]

Source: linux
Version: 6.5~rc7-1~exp1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com

Dear Maintainer,

Please enable the CONFIG_INTEL_TH_ACPI on arch amd64/x86_64 in Debian Trixie.

The Trace Hub devices now can be enumerated as ACPI devices, which
translates into "Host Debugger mode". There are two IDs: one for
PCH Trace Hub, and one for the uncore Trace Hub. These are expected
to stay the same across all platforms.

CONFIG_INTEL_TH_ACPI:

Intel(R) Trace Hub may exist as an ACPI device. This option enables
support glue layer for ACPI-based Intel TH. This typically implies
'host debugger' mode, that is, the trace configuration and capture
is handled by an external debug host and corresponding controls will
not be available on the target.


A MR was created with this proposal at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/814

Thanks,
Miguel Bernal Marin

Bug#1027976: Subject: Re: ITP: libcpucycles -- Microlibrary for counting CPU cycles

[Miguel Landaeta]

libcpucycles is ready to be uploaded.

I just pushed a new git repo for this package.

https://salsa.debian.org/debian/libcpucycles

I'll have to wait a few days to be able to upload the package,
I just updated my PGP key to add new subkeys, because the ones
in the debian keyring expired as I have been inactive for quite
some time.

I attempted an upload 2 days ago and it didn't go through, so the
archive tooling must be failing to validate my upload signature.

Anyway, I'll wait for a few days or nag a DD to do the upload on
my behalf.

Bug#1049901: linux: Enable Memory Hotplug default online

[Miguel Bernal Marin]

Source: linux
Version: 6.5~rc6-1~exp1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com

Dear Maintainer,

Please enable the CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE on arch amd64/x86_64,
on Debian Trixie.

Currently all newly hot-plugged memory remains in 'offline' state and manual
actions are required to bring it online.

To make things work automagically CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE option
was introduced. This option sets the default policy setting for memory hotplug
onlining policy (/sys/devices/system/memory/auto_online_blocks) which
determines what happens to newly added memory regions. Policy setting
can always be changed at runtime.

A MR was created with this proposal at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/810

Thanks,
Miguel Bernal Marin

Bug#1027976: ITP: libcpucycles -- Microlibrary for counting CPU cycles

[Miguel Landaeta]

owner 1027976 !
thanks

Nick reached out via private email and we agreed to share maintenance
for this package.

I'll prepare an upload in the next few days.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1027976: ITP: libcpucycles -- Microlibrary for counting CPU cycles

[Miguel Landaeta]

On Thu, Jan 05, 2023 at 08:01:21AM -0500, Nick Black (Public gmail account) 
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: nick black  
> X-Debbugs-Cc: debian-de...@lists.debian.org, dankamong...@gmail.com
> 
> * Package name: libcpucycles
>   Version : 20230105

Are you still working on this?

libcpucycles looks like a straightforward package with no more runtime
dependencies than glibc and no more build dependencies than python
and build-essential.

I'd like to see this package soon in Debian, I can help with the maintenance
package and/or sponsor uploads, if required.

--
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1037422: spamprobe crashing with emails containing an image attached

[Miguel Angel Varo Giner]

Package: spamprobe
Version: 1.4d-16
Followup-For: Bug #1037422

After upgrading from bullseye to bookworm I've found spamprobe is not
working with some emails. I've found that the emails spamprobe is having
problems with is the ones with images attached (jpg or png). Whenever it
processes one of those emails it fails with:

"caught signal 11: quitting
Aborted"


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

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

Versions of packages spamprobe depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u1
ii  libdb5.3   5.3.28+dfsg2-1
ii  libgcc-s1  12.2.0-14
ii  libgif75.2.1-2.5
ii  libjpeg62-turbo1:2.1.5-2
ii  libpng16-161.6.39-2
ii  libstdc++6 12.2.0-14

Versions of packages spamprobe recommends:
ii  procmail  3.22-27

spamprobe suggests no packages.

-- debconf information:
* spamprobe/db53_upgrade:
  spamprobe/db51_upgrade:

Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work

[José Miguel Gonçalves]

Hi Jeremy,

On 13/07/23 23:01, Jeremy Davis wrote:
Can you confirm that the current default bookworm fail2ban 
config/regex works with sshd with just this change (to 'backend' in 
/etc/fail2ban/jail.conf)? Or are further adjustments required? 


Yes, I can confirm that fail2ban sshd jail works fine using the default 
config and just changing the 'backend' to 'systemd'.


Best regards,
José Gonçalves

Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work

[José Miguel Gonçalves]

Hi,

As Debian opted by systemd journal as the default logging mechanism for 
bookworm, maybe a better option would be to change the default 
configuration in '/etc/fail2ban/jail.conf' to select journal as the 
logging source, i.e., instead of setting 'backend = auto', set 'backend 
= systemd'.


Best regards,
José Gonçalves

Bug#1040174: nvidia-driver: Can't upgrade to nvidia-driver-525.116.04-1 on debian unstable: build fails

[Miguel Angel Rojas]

Hi there,

I can confirm the bug is there. Libraries are not found and NVIDIA driver
fails to build.

Regards

Bug#1039015: About bug #1038014 and this one

[Antonio Miguel Ferreira Marques Trindade]

The patch included in bug #1038014 does not full resolve this issue.

I still got the following build error:

/var/lib/dkms/nvidia-legacy-390xx/390.157/build/nvidia-drm/nvidia-drm-fb.c: 
In function ‘nv_drm_internal_framebuffer_create’:
/var/lib/dkms/nvidia-legacy-390xx/390.157/build/nvidia-drm/nvidia-drm-fb.c:180:5: 
error: implicit declaration of function ‘drm_helper_mode_fill_fb_struct’ 
[-Werror=implicit-function-declaration]

  180 | drm_helper_mode_fill_fb_struct(
  | ^~
cc1: some warnings being treated as errors
make[3]: *** 
[/usr/src/linux-headers-6.3.0-1-common/scripts/Makefile.build:257: 
/var/lib/dkms/nvidia-legacy-390xx/390.157/build/nvidia-drm/nvidia-drm-fb.o] 
Error 1

make[3]: *** Waiting for unfinished jobs
[...]
make[2]: *** [/usr/src/linux-headers-6.3.0-1-common/Makefile:2050: 
/var/lib/dkms/nvidia-legacy-390xx/390.157/build] Error 2

make[2]: Leaving directory '/usr/src/linux-headers-6.3.0-1-amd64'
make[1]: *** [Makefile:238: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.3.0-1-common'
make: *** [Makefile:82: modules] Error 2

The included patch solves both #1038014 
 and the 
error above.

Bug#1038435: libmariadb-java: Request to upgrade

[Jose Miguel Goncalves]

Package: libmariadb-java
Version: 2.7.6-1
Severity: normal

Dear Maintainer,

Please consider upgrading the MariaDB Java connector to the 3.0 series in 
bookworm.
For OpenJDK 17 (the default JVM in bookworm) the 3.0 series is the recommended 
version:

* https://mariadb.com/kb/en/about-mariadb-connector-j/#java-compatibility

Best regards,
José Gonçalves

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT)
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

libmariadb-java depends on no packages.

libmariadb-java recommends no packages.

Versions of packages libmariadb-java suggests:
pn  libjna-java   
pn  libjna-platform-java  
pn  libslf4j-java 

-- no debconf information

Bug#1038204: tomcat10 complains about old Apache Tomcat Native library

[Jose Miguel Goncalves]

Package: tomcat10
Version: 10.1.6-1
Severity: normal

Dear Maintainer,

After installing tomcat10 in bookworm I see the following log message when I 
start the service:

INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent An 
older version [1.2.35] of the Apache Tomcat Native library is installed, while 
Tomcat recommends a minimum version of [2.0.1]

Please consider upgrading the libtcnative-1 package as recommended by the 
Tomcat developers.

Best regards,
José Gonçalves 

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT)
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 tomcat10 depends on:
ii  lsb-base11.6
ii  systemd [systemd-tmpfiles]  252.6-1
ii  sysvinit-utils [lsb-base]   3.06-4
ii  tomcat10-common 10.1.6-1
ii  ucf 3.0043+nmu1

Versions of packages tomcat10 recommends:
ii  libtcnative-1  1.2.35-1

Versions of packages tomcat10 suggests:
ii  tomcat10-admin 10.1.6-1
ii  tomcat10-docs  10.1.6-1
pn  tomcat10-examples  
pn  tomcat10-user  

-- no debconf information

Bug#1036714: linux: Add Intel Speed Select Tool to linux-cpupower

[Miguel Bernal Marin]

Source: linux
Version: 6.3.2-1~exp1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com

Dear Maintainer,

The Intel Speed Select Technology [1] was requested at Bug #1028344, and
enabled at 5a0e7e75be81 ("[x86] Enable Intel Speed Select Technology") in
salsa. This technology can be set via sysfs, but there is a tool [2] which
helps on this setup.

The tool can be integrated in the actual linux-cpupower package.

A MR was created with this proposal:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/732

[1] 
https://www.intel.la/content/www/xl/es/architecture-and-technology/speed-select-technology-article.html
[2] https://docs.kernel.org/admin-guide/pm/intel-speed-select.html

Thanks,
Miguel

Bug#1033061: linux: Enable Intel In-Field Scan (IFS)

[Miguel Bernal Marin]

Source: linux
Version: 6.1.15-1
Severity: wishlist
Tags: patch, sid
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com

Dear Maintainer,

Please enable the Intel In-Field Scan (IFS) driver as module.

Intel In-Field Scan is to be supported with upcoming CPUs (Xeon Saphire
Rapids) and allows for initiating circuit-level tests on a CPU core for
detecting hardware problems not caught by parity or ECC checks [1].
Future CPUs will support more than one type of test which will show up with
a new platform-device instance-id, for now only .0 is exposed [2].

As for what all of these silicon-level hardware tests that will be conducted,
that isn't entirely clear. This proposed Intel IFS kernel driver is just the
infrastructure for handling In-Field Scan while the tests themselves will be
loaded as a binary similar to the Intel CPU microcode. The Intel IFS tests will
be loaded from a file and are specific to particular CPU Family/Model/Stepping.
These files are authenticated prior to use and when loaded stored within secure
memory [3].

It was marked as BROKEN at c483e7ea10fa ("platform/x86/intel/ifs: Mark as
BROKEN") in v5.19-rc1 upstream because a suggested change to the IFS code
has shown that the userspace API needs a bit more work.

The solution finally landed at v6.2 and the BROKEN status was removed at
1a63b5808286 ("Revert "platform/x86/intel/ifs: Mark as BROKEN"") where the
issues with user interface [4] to load scan test images have been addressed.

The solutions is not a "bugfix" so the patches won't be backported to v6.1.

A MR was created at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/680

where the patches involved the solutions where backported and was enabled in
the Kconfig.

[1] https://www.phoronix.com/news/Intel-In-Field-Scan-IFS
[2] https://docs.kernel.org/x86/ifs.html
[3] https://www.phoronix.com/news/Intel-In-Field-Scan
[4] 
https://lore.kernel.org/lkml/26102aca-a730-ddf8-d024-2e7367696...@redhat.com/

Thanks,
Miguel

Bug#1032467: linux: Enable ACPI_APEI_EINJ and EDAC_IGEN6 for rasdaemon

[Miguel Bernal Marin]

Source: linux
Version: 6.1.12-1
Severity: wishlist
Tags: patch, sid
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, 
jair.de.jesus.gonzalez.plascen...@linux.intel.com

Dear Maintainer,

Please enable the APEI Error INJection (EINJ) (ACPI_APEI_EINJ) and
the Intel client SoC Integrated Memory Controller (EDAC_IGEN6). Both,
are used by the rasdaemon tool for the Intel platforms.

# Intel client SoC Integrated MC (EDAC_IGEN6)

  Support for error detection and correction on the Intel   

  client SoC Integrated Memory Controller using In-Band ECC IP. 

  This In-Band ECC is first used on the Elkhart Lake SoC but

  may appear on others in the future as Alder Lake SoC and Tiger
  Lake SoC.

# APEI Error INJection (EINJ) (ACPI_APEI_EINJ)

  EINJ provides a hardware error injection mechanism, it is 
  mainly used for debugging and testing the other parts of  
  APEI and some other RAS features.

  This one was added as commented out feature at f7d4f56521df
  ("x86 enable new acpi features").

A MR was created at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/672

Thanks,
Miguel

Bug#1032437: linux: Enable TDX Guest Support driver

[Miguel Bernal Marin]

Source: linux
Version: 6.1.12-1
Severity: wishlist
Tags: patch, sid
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, 
jair.de.jesus.gonzalez.plascen...@linux.intel.com

Dear Maintainer,

Please enable the Intel's Trust Domain Extensions (TDX) Guest driver.

Intel’s Trust Domain Extensions (TDX) protect confidential guest VMs from
the host and physical attacks by isolating the guest register state and by
encrypting the guest memory. In TDX, a special module running in a special
mode sits between the host and the guest and manages the guest/host
separation [2].

Since the host cannot directly access guest registers or memory, much normal
functionality of a hypervisor must be moved into the guest. This is
implemented using a Virtualization Exception (#VE) that is handled by the
guest kernel. A #VE is handled entirely inside the guest kernel, but some
require the hypervisor to be consulted.

TDX includes new hypercall-like mechanisms for communicating from the guest
to the hypervisor or the TDX module.

Intel® Trust Domain Extensions (Intel® TDX) is introducing new, architectural
elements to help deploy hardware-isolated, virtual machines (VMs) called trust
domains (TDs). Intel TDX is designed to isolate VMs from the virtual-machine
manager (VMM)/hypervisor and any other non-TD software on the platform to
protect TDs from a broad range of software [1]. These hardware-isolated TDs
include:

* Secure-Arbitration Mode (SEAM) – a new mode of the CPU designed to host
  an Intel-provided, digitally-signed, security-services module called the
  Intel TDX module.

* Shared bit in GPA to help allow TD to access shared memory.

* Secure EPT to help translate private GPA to provide address-translation
  integrity and to prevent TD-code fetches from shared memory. Encryption
  and integrity protection of private-memory access using a TD-private key
  is the goal.

* Physical-address-metadata table (PAMT) to help track page allocation, page
  initialization, and TLB consistency.

* Multi-key, total-memory-encryption (MKTME) engine designed to provide
  memory encryption using AES-128- XTS and integrity using 28-bit MAC and a
  TD-ownership bit.

* Remote attestation designed to provide evidence of TD executing on a
  genuine, Intel TDX system and its TCB version.

[1] 
https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html
[2] https://docs.kernel.org/x86/tdx.html

A MR was created at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/671

Thanks,
Miguel

Bug#1030280: general: General non-recognized errors (im novice) after the installation: drivers, battery, booting errors...

[Miguel González Jiménez]

Package: general
Severity: normal
X-Debbugs-Cc: migui...@hotmail.com

Dear Maintainer,

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

   * What led up to the situation?
After the installation, I proceed to use the hardware and no correct firmware 
had been installed. Couldn't use neither the touchpad, the wifi card (AX200 
Intel) nor several screen caracteristics.
I've tried to install its drivers but they dont work. I think something went 
wrong during the installation. Besides, battery is running out quite fast and 
fans are most of the time active. After installing wifi card Intel drivers, 
booting errors has became to show up on the log booting screen, refeering bugs 
about usb and bluetooth ports.
The partition on the solid disk (what also holds Windows 10) has been made fine 
I think.

Bug#1029674: linux: Enable the 5-level paging support

[Miguel Bernal Marin]

Source: linux
Version: 6.1.7-1
Severity: wishlist
Tags: patch, sid
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, 
jair.de.jesus.gonzalez.plascen...@intel.com

Dear Maintainer,

Please enable the 5-level paging support.

Original x86-64 was limited by 4-level paging to 256 TiB of virtual
address space and 64 TiB of physical address space. We are already
bumping into this limit: some vendors offers servers with 64 TiB of
memory today.

To overcome the limitation upcoming hardware will introduce support
for 5-level paging. It is a straight-forward extension of the current
page table structure adding one more layer of translation.

It bumps the limits to 128 PiB of virtual address space and 4 PiB of
physical address space.

In Debian this feature was added as disabled at 998b27af2f57 ("Explicitly
set various config symbols to their default values") [1], but in Linux
upstream at 18ec1eaf58fb ("x86/mm: Enable 5-level paging support by default")
[2] it was flip to default-y. 

A merge request against SID was made at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/647

I don't know if this fix should be propagated to others branches.

[1] https://salsa.debian.org/kernel-team/linux/-/commit/998b27af2f57
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18ec1eaf58fb

Thanks,
Miguel

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

Kernel: Linux 6.1.0-2-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

Bug#1029484: linux: Enable Intel Uncore frequency control driver

[Miguel Bernal Marin]

Source: linux
Version: 6.1.7-1
Severity: wishlist
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, 
jair.de.jesus.gonzalez.plascen...@intel.com

Dear Maintainer,

Please enable the Intel Uncore frequency control driver.
This driver allows control of uncore frequency limits on
supported server platforms.

# Intel Uncore frequency control driver

  CONFIG_INTEL_UNCORE_FREQ_CONTROL=m

  Some server users set limits on the uncore frequency using MSR 620H, while
  running latency sensitive workloads. This driver "the uncore frequency",
  controls RING/LLC (last-level cache) clocks.

  But MSR control is not always possible from the user space, so this driver
  provides a sysfs interface to set max and min frequency limits. This MSR
  620H is a die scoped in multi-die system or package scoped in non multi-die
  systems.

  When this driver is loaded, a new directory is created under
   /sys/devices/system/cpu.

  For example on a two package Skylake server:
  $ cd /sys/devices/system/cpu/intel_uncore_frequency

  $ ls
  package_00_die_00 package_01_die_00

  $ ls package_00_die_00
  max_freq_khz  min_freq_khz  initial_max_freq_khz
  initial_min_freq_khz

  $ grep . *
  max_freq_khz:240
  min_freq_khz:120
  initial_max_freq_khz:240
  initial_min_freq_khz:120

  Here, initial_max_freq_khz and initial_min_freq_khz are read only
  attributes to show power up or initial values of max and min frequencies
  respectively. Other attributes are read-write, so that users can modify.

A merge request was created at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/645

Thanks,
Miguel

Bug#1028463: linux: enable MEI options for Intel ARC

[Miguel Bernal Marin]

Control: tags -1 + patch 

Dear Maintainer,

> In order to fully use Intel ARC GPUs, the following options need to get
> enabled:
> 
> CONFIG_INTEL_MEI_GSC
> CONFIG_INTEL_MEI_PXP
> CONFIG_DRM_I915_PXP
> 

Below is the description of the features requested:

# Intel MEI GSC embedded device

  CONFIG_INTEL_MEI_GSC=m

  The Intel Management Engine Interface (Intel MEI) auxiliary
  driver for Graphics System Controller (GSC) devices embedded
  in Intel graphics devices.

  An MEI device here called GSC can be embedded in an
  Intel graphics devices, to support a range of chassis
  tasks such as graphics card firmware update and security
  tasks.

# Intel PXP services of ME Interface

  CONFIG_INTEL_MEI_PXP=m

  MEI Support for Protected Xe Path (PXP) Services on Intel platforms.

  Enables the ME FW services required for PXP support through
  I915 display driver of Intel.

# Enable Intel PXP support

  CONFIG_DRM_I915_PXP=y

  PXP (Protected Xe Path) is an i915 component, available on graphics
  version 12 and newer GPUs, that helps to establish the hardware
  protected session and manage the status of the alive software session,
  as well as its life cycle.

And a MR was created at:

MR: https://salsa.debian.org/kernel-team/linux/-/merge_requests/633

Regards,
Miguel

Bug#1028509: linux: Enable Intel Data Accelerators performance monitor

[Miguel Bernal Marin]

Source: linux
Version: 6.1.4-1
Severity: wishlist
Tags: patch, sid
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, 
jair.de.jesus.gonzalez.plascen...@intel.com

Dear Maintainer,

The last Octuber a request was made at Bug #1021337 to enable the
Intel Data Accelerators feature. It was merged at 5fbc3f893f3e ("[amd64]
drivers/dma: Enable INTEL_IDXD as module and INTEL_IDXD_SVM"), where the
feature was enabled as module and the Accelerator Shared Virtual Memory
feaure was integrated in the module (=y).

This request is to ask to inregrate the following feature to the IDXD
module:

# Intel Data Accelerators performance monitor support

  CONFIG_INTEL_IDXD_PERFMON=y

  Enable performance monitor (pmu) support for the Intel
  data accelerators present in Intel Xeon CPU.  With this
  enabled, perf can be used to monitor the DSA (Intel Data
  Streaming Accelerator) events described in the Intel DSA
  spec.

  This key integrated the prefmon.o logic to the IDXD module.

A MR was created for this request at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/630


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

Kernel: Linux 6.1.0-1-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

Bug#1028344: linux: Enable Intel Speed Select Technology

[Miguel Bernal Marin]

Hi Salvatore,

On Mon, Jan 09, 2023 at 09:25:28PM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi Miguel,
> 
> I have a question back on your request:
> 
> On Mon, Jan 09, 2023 at 12:29:31PM -0600, Miguel Bernal Marin wrote:
> > Source: linux
> > Severity: wishlist
> > Tags: sid
> > X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, 
> > jair.de.jesus.gonzalez.plascen...@intel.com
> > 
> > Dear Maintainer,
> > 
> > Intel is planing to release the next-generation Xeon products [1] and some
> > of the features are not enabled on Debian. It would be useful to have this
> > feature in Bookworm.
> > 
> > # Intel(R) Speed Select Technology
> > 
> >   CONFIG_INTEL_SPEED_SELECT_INTERFACE=m
> > 
> >   The Intel(R) Speed Select Technology (Intel(R) SST) provides a powerful
> >   new collection of features that give more granular control over CPU
> >   performance. With Intel(R) SST, one server can be configured for power
> >   and performance for a variety of diverse workload requirements.
> > 
> >   Refer to the links below for an overview of the technology:
> > 
> >   * 
> > https://www.intel.com/content/www/us/en/architecture-and-technology/speed-select-technology-article.html
> >   * 
> > https://builders.intel.com/docs/networkbuilders/intel-speed-select-technology-base-frequency-enhancing-performance.pdf
> > 
> >   These capabilities are further enhanced in some of the newer generations
> >   of server platforms where these features can be enumerated and controlled
> >   dynamically without pre-configuring via BIOS setup options. This dynamic
> >   configuration is done via mailbox commands to the hardware. One way to
> >   enumerate and configure these features is by using the Intel Speed Select
> >   utility.
> > 
> > [1] 
> > https://www.intel.com/content/www/us/en/newsroom/news/intel-technology-roadmaps-milestones.html
> 
> As we do not build those intel-speed-select too, does it still make
> sense to enable it, are there other ways to control the features? Or
> does it only make sense if we would build intel-speed-select as well?

The intel-speed-select utility is a helper to configure the profiles, but
you can set it via sysfs [2] (the hard way). This user utility is found
in the kernel source code.

The plan is to ask for the integration of the intel-speed-sect utility to
Debian if it is posible (before milestone 2). But if it is not posible the
user from a Data Center can compile the tool without compiling a new kernel.

I'm learning how to add the tool to debian linux source package and after  
make the request.

Also there are other Intel kernel features that will be requested for
Data Centers.

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/power/x86/intel-speed-select/isst-config.c?h=v6.1.4

Regards,
Miguel

Bug#1028344: linux: Enable Intel Speed Select Technology

[Miguel Bernal Marin]

Tags: patch

A MR was done at: 

https://salsa.debian.org/kernel-team/linux/-/merge_requests/627

Bug#1028344: linux: Enable Intel Speed Select Technology

[Miguel Bernal Marin]

Source: linux
Severity: wishlist
Tags: sid
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, 
jair.de.jesus.gonzalez.plascen...@intel.com

Dear Maintainer,

Intel is planing to release the next-generation Xeon products [1] and some
of the features are not enabled on Debian. It would be useful to have this
feature in Bookworm.

# Intel(R) Speed Select Technology

  CONFIG_INTEL_SPEED_SELECT_INTERFACE=m

  The Intel(R) Speed Select Technology (Intel(R) SST) provides a powerful
  new collection of features that give more granular control over CPU
  performance. With Intel(R) SST, one server can be configured for power
  and performance for a variety of diverse workload requirements.

  Refer to the links below for an overview of the technology:

  * 
https://www.intel.com/content/www/us/en/architecture-and-technology/speed-select-technology-article.html
  * 
https://builders.intel.com/docs/networkbuilders/intel-speed-select-technology-base-frequency-enhancing-performance.pdf

  These capabilities are further enhanced in some of the newer generations
  of server platforms where these features can be enumerated and controlled
  dynamically without pre-configuring via BIOS setup options. This dynamic
  configuration is done via mailbox commands to the hardware. One way to
  enumerate and configure these features is by using the Intel Speed Select
  utility.

[1] 
https://www.intel.com/content/www/us/en/newsroom/news/intel-technology-roadmaps-milestones.html

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

Kernel: Linux 6.0.0-6-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