Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Matthias Klumpp]

Am Di., 19. März 2024 um 22:25 Uhr schrieb Simon McVittie :
>
> On Tue, 19 Mar 2024 at 22:14:12 +0100, Matthias Klumpp wrote:
> > Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> > > libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> > > to be replaced by libgtk-3-0t64 after checking that the functions that
> > > interact with time_t (methods of GtkRecentInfo) are handled correctly.
> >
> > Will this be the new name on all platforms?
>
> Yes, the library is renamed on all architectures. (On architectures where
> the ABI didn't actually break, like amd64, it Provides the old name.)
>
> The same is true for essentially all of the libraries involved in this
> transition: there are hundreds of them.
>
> > Annoyingly, libgtkd does not depend on
> > libgtk properly on its own via linking it, and instead will dlopen it
> > at runtime.
>
> One way I've sometimes seen this handled is by making a list of the
> SONAMEs that will be dlopen'd, linking them into a dummy C executable
> with -Wl,--no-as-needed, and letting dpkg-shlibdeps inspect that executable
> and generate dependencies.

So, in that case the most straightforward way to fix this would just
be to rename the dependency to libgtk-3-0t64?
(making a mock library is possible, but I'd prefer the easiest way in
this case, as it's just one library...)

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Matthias Klumpp]

Hi Simon!

Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> to be replaced by libgtk-3-0t64 after checking that the functions that
> interact with time_t (methods of GtkRecentInfo) are handled correctly.

Will this be the new name on all platforms? If not, can we detect the
name automatically somehow? Annoyingly, libgtkd does not depend on
libgtk properly on its own via linking it, and instead will dlopen it
at runtime. So that dependency has to be added manually for the Debian
package.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1066030: Please move packagekit plugin to Recommends

[Matthias Klumpp]

Am Mo., 11. März 2024 um 13:06 Uhr schrieb Jeremy Bícha
:
>
> On Mon, Mar 11, 2024 at 7:54 AM Guido Günther  wrote:
> > Would it be possible to move
> >
> > /usr/lib/*/gnome-software/plugins-20/libgs_plugin_packagekit.so
> >
> > and related files to a separate package and make it a Recommends rather
> > than a dependency?
> >
> > This would allow to use gnome-software without package kit for
> > e.g. managing flatpaks only.
> >
> > This is useful on device with restricted resources like phones where the
> > packagekit backend takes lots of RAM and slows down initial app startup
> > although it's often not used since people use `apt` for the OS side
> > packages.
>
> I have a WIP split of the GNOME Software packaging because other
> people have been asking for this too. I need to clean it up just a bit
> and make a merge proposal for some people to check.

Please keep in mind that GNOME Software on Debian GUI systems is
responsible for refreshing the APT cache and notifying about system
updates, and this functionality will no longer work if the PK backend
is not there - so people might miss important (security) updates.
Having it as recommends may be strong enough to pull it in on standard
systems though...

Best,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1065072: packagekit spinning cpu

[Matthias Klumpp]

Am Sa., 9. März 2024 um 07:30 Uhr schrieb Joey Hess :
>
> Joey Hess wrote:
> > It may also be relevant somehow that the topmost update was a thinkpad
> > AMD firmware update which "requires restart".
>
> I masked and stopped packagekit again and now in gnome-software, it
> displays only the thinkpad amd firmware update, and it's no longer
> alternating with the loading updates screen.
> This makes me think that firmware update is not related to the problem.
>
> The other updates gnome-software displays when packagekit is running are
> debian package updates. My last upgrade was an apt-get safe-upgrade,
> because dist-upgrade wants to remove several packages, including gnome.
> (I'm tracking unstable, this is typical transient dependency issues I
> suppose. Also I have bluez on hold at an older version due to #1060224)
>
> So maybe gnome-software gets confused in this kind of situation and keeps
> retrying?

That is the current hypothesis, yes - the change that broke this was
introduced by Fedora, and they do not observe this behavior. So,
either GNOME Software is wrong (I think it unconditionally has a
problem, it should never retry a cache refresh at that insane
frequency), or the APT backend in PackageKit does something wrong and
emits package changes for blocked packages when it shouldn't do so.
I guess as soon as your system is up-to-date (with no blocked
packages), this issue will go away temporarily.

TBH, at this point I think there's probably a bug in GS as well as in
PK-Apt, but we haven't found the culprit yet (except for the GS patch
that caused this issue to appear,
https://gitlab.gnome.org/GNOME/gnome-software/-/commit/b8cf52e9c001064eebfe86ce801541ca211e
)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1065072: packagekit spinning cpu

[Matthias Klumpp]

Hi!

Am Sa., 9. März 2024 um 04:09 Uhr schrieb Joey Hess :
>
> I'm confident I saw this same problem today, with packagekit repeatedly
> updating and spinning a CPU for 10 minutes. It only stopped at that
> point because I stopped and masked it. (Stopping it was not enough,
> something was restarting the service every time I stopped it.) See
> attached log.
>
> I did not capture the trigger for that pkmon, but just before it started I
> had used window+s in gnome and typed in "paperwm", before remembering that
> doesn't find anything and pressing escape.
>
> When I repeat that with pkmon open, I see it does trigger packagekit:
>
> root@darkstar:/home/joey>pkmon
> Transactions:
>  [none]
> daemon connected=1
> network status=online
> Transactions:
>  1  /14317_cdeeebeb
> /14317_cdeeebeb allow_cancel 1
> /14317_cdeeebeb percentage   -1
> /14317_cdeeebeb role resolve
> /14317_cdeeebeb sender   /usr/bin/gnome-software
> /14317_cdeeebeb status   setup

Unfortunately there isn't much we can do - this is GNOME Software
polling PackageKit again and again, and other than adding more rate
limitations, we can't fix that in PK and PK is behaving correctly.
The real solution would be to make the tool that is causing this stop
its behavior and not ask PackageKit to update the cache every second.

I reassigned it to GS, which already had a bug describing this issue exactly.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1064166: ldc: NMU diff for 64-bit time_t transition

[Matthias Klumpp]

Am Sa., 24. Feb. 2024 um 08:00 Uhr schrieb Steve Langasek :
>
> Hi Matthias,
>
> I see you've implemented this as:
>
> ifneq (,$(filter $(DEB_HOST_ARCH), armhf))
> export DEB_BUILD_MAINT_OPTIONS += abi=+time64,+lfs
> endif
>
> Please note that armhf is not the only architecture affected by this ABI
> change: armel is also a release architecture affected, and there are a
> number of other 32-bit ports architectures which are affected (hppa,
> powerpc, ...)

I know, but LDC does not exist on these architectures ;-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1060016: packagekit: CVE-2024-0217

[Matthias Klumpp]

Am Mi., 21. Feb. 2024 um 16:05 Uhr schrieb Moritz Muehlenhoff :
>
> On Tue, Feb 20, 2024 at 10:11:35PM +0100, Matthias Klumpp wrote:
> > The CVE page lists that commit as "patch" now, and given that emitting
> > a finished transaction as finished multiple times could indeed cause
> > issues (and use-after-free issues potentially as well), I am inclined
> > to think that that's indeed the issue here and that the patch fixes
> > it.
>
> Ok.
>
> > That would mean though that all PK versions starting from and
> > including 1.2.7 are not vulnerable... But the CVE tells otherwise.
> > Very odd.
>
> But https://www.cve.org/CVERecord?id=CVE-2024-0217 only states
> "unaffected at 1.2.7", which seems to be based on the git tag of
> the referenced commit?

We are all confused. Neal and I asked on the RHEL bug report again:
https://bugzilla.redhat.com/show_bug.cgi?id=2256624#c6
We really need more information here.

I'd read the "unaffected at 1.2.7" as version 1.2.7 and higher not
having the bug... But then again, on another page it said that the
respective patch only lowered the impact...
I remember merging that patch, and it was a pretty good robustness
improvement, we didn't talk about any use-after-free issue there
though (so it's not obvious why this changes anything either).

Let's see if we get a reply from the CVE reporter!
Best,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1060016: packagekit: CVE-2024-0217

[Matthias Klumpp]

Hi!

Am Fr., 5. Jan. 2024 um 18:57 Uhr schrieb Salvatore Bonaccorso
:
> [...]
> Got a reply from Pedro Sampaio in 
> https://bugzilla.redhat.com/show_bug.cgi?id=2256624#c3
>
> It is mentioned that although the following is not a direct fix for
> the issue, that the commit in v1.2.7 to reduce the impact is the
> following:
>
> https://github.com/PackageKit/PackageKit/commit/64278c9127e342b56ead99556161f7e86f79
>
> Does that help you with your upstream hat on, and downstream in
> Debian?

Not at all... I also don't know why I should hunt around the code to
find an issue that someone else has found but where they don't tell me
where the problem even is.
The CVE page lists that commit as "patch" now, and given that emitting
a finished transaction as finished multiple times could indeed cause
issues (and use-after-free issues potentially as well), I am inclined
to think that that's indeed the issue here and that the patch fixes
it.
That would mean though that all PK versions starting from and
including 1.2.7 are not vulnerable... But the CVE tells otherwise.
Very odd.

Best,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1064302: enforcing time64 on 32-bit architectures is wrong for i386

[Matthias Klumpp]

Am Mo., 19. Feb. 2024 um 21:45 Uhr schrieb Matthias Klose :
>
> Package: src:ldc
> Version: 1:1.36.0-1
> Severity: serious
> Tags: sid trixie
>
> Just reading the changelog:
>
> * LDC should already work fine with 64-bit time on 32-bit
>   architectures, just to be on the safe side though, enforce
>   time64,lfs on 32-bit architectures for C code as well (Closes:
> #1064166)
>
> this is wrong for i386, which will keep the 32bit time_t.

You are right! I am pretty sure I've seen this approach in other
packages too though...
Anyway, it's adjusted now to follow the Debian wiki.

Thanks for the quick heads up!!
Best,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1062190: packagekit: locks the dpkg frontened in the middle of a running update by synaptic package manager

[Matthias Klumpp]

Hi Julian (now CC'ed)!

Do you have any idea how this would be possible? Both PK and Synaptic
should hold the APT frontend lock, so they should never be able to run
at the same time.
I also have never once observed this behavior...

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1060803: gnome-software: Please don't depend on `software-properties-gtk`

[Matthias Klumpp]

Am Di., 16. Jan. 2024 um 20:03 Uhr schrieb Julian
:
>
>
> > Fair point. We could maybe make it so g-s-p is only a recommended
> > dependency
>
> That is what this request is requesting. Just a change from depend to
> recommend
>
> > and modify the code so when g-s-p is not available, it
> > falls back to the GS dialog.
>
> I'm not sure what code you're referring to, but when running GNOME
> Software on Debian without s-p-gtk installed, the GS dialog is instead
> used.

Neat, looks like I wrote it properly back then :-)
Also appears like the change was reverted upstream a few months ago, I
wonder why... (we patch it back in at Debian/Ubuntu anyway)

In any case, I have no objections to moving g-s-p to recommends under
these circumstances :-)
Thanks for reporting this issue!

Best,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1060803: gnome-software: Please don't depend on `software-properties-gtk`

[Matthias Klumpp]

Am Di., 16. Jan. 2024 um 18:21 Uhr schrieb Julian
:
>
> > That is false, GNOME Software on Debian does depend on s-p-gtk. The
> > reason this was implemented is that the PackageKit repository
> > preferences dialog does not cover all the options needed on a Debian
> > system, and especially not when used on an Ubuntu system.
> > Instead of giving users an inferior and possibly broken way of
> > adjusting package sources, we'd rather provide them with a proper
> > selection dialog.
> >
>
> That is a notable endeavour, but I don't see why it has to be forced on GNOME 
> Software users in this way. It would be entirely possible to install the app 
> without overriding the way GNOME Software works, or simply to recommend it 
> rather than requiring it.

Without that change, users would have had broken repository
management. We do not want to ship broken things.

> > Certainly not, Debian's job is to integrate software to form a
> > cohesive operating system, and adding/removing dependencies, changing
> > compiler flags that affect dependency selection and applying
> > integration patches is an integral part of that.
> >
>
> For mobile devices, this actually makes the experience of using Debian worse. 
> s-p-gtk is not an adaptive app, and there is no way to prevent it from 
> overriding GNOME Software's functionality, or to uninstall it without also 
> being forced to uninstall GNOME Software along with it.

Fair point. We could maybe make it so g-s-p is only a recommended
dependency, and modify the code so when g-s-p is not available, it
falls back to the GS dialog. I think I fixed things enough so that at
the very least you can enable/disable repositories without running
into problems, and most basic features should actually work (you can
not manage keys or add repositories though).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1060803: gnome-software: Please don't depend on `software-properties-gtk`

[Matthias Klumpp]

Am So., 14. Jan. 2024 um 15:27 Uhr schrieb Arnaud Ferraris
:
> [...]
> GNOME Software does not depend on the Software Properties app.
> Installing it changes the way GNOME Software works (for example, with
> the source settings).
> [...]

That is false, GNOME Software on Debian does depend on s-p-gtk. The
reason this was implemented is that the PackageKit repository
preferences dialog does not cover all the options needed on a Debian
system, and especially not when used on an Ubuntu system.
Instead of giving users an inferior and possibly broken way of
adjusting package sources, we'd rather provide them with a proper
selection dialog.

I have since fixed a lot of PackageKit issues which caused the native
repo dialog in GS to be an abysmal experience, but tbh, it's still not
a great experience, and it doesn't cover all the features and context
s-p-g provides (that point is a bit less relevant to Debian now than
it is for Ubuntu, and the latter is dropping GS entirely from its
base, so the point for it is certainly weaker than years ago, but I
think it still stands).

> [...]
> For that reason, some people may not want it installed. And, in my
> opinion, Debian developers should not add dependencies to software they
> did not create. If a dependency should be added to GNOME Software, it
> should be done by the GNOME developers.

Certainly not, Debian's job is to integrate software to form a
cohesive operating system, and adding/removing dependencies, changing
compiler flags that affect dependency selection and applying
integration patches is an integral part of that.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1060284: ITP: laniakea -- Repository management suite for Debian-based OSes

[Matthias Klumpp]

Package: wnpp
Owner: Matthias Klumpp 
Severity: wishlist

 Package name: laniakea
 Version : 0.1
 Upstream Contact: Matthias Klumpp 
 URL : https://github.com/lkhq/laniakea
 License : LGPL-3.0
 Programming Lang: Python
 Description : Repository management suite for Debian-based OSes

Laniakea is a software suite to manage Debian derivatives. It provides
tooling to maintain an APT archive (and multiple individual package
repositories), perform QA on it, autobuild packages, and provides
various tools for better insight into the archive, such as web
applications to view archive details, a Matrix bot and a ZeroMQ-based
message bus to plug in custom tooling.

In order to make this useful as a Debian package, quite a bit of
preparation still has to be done upstream, especially some crucial
parts need better documentation, so the project can be used by people
outside its two original Debian derivatives, Tanglu and PureOS. Having
a package for it will make the project a lot more accessible though.
I expect packaging this to take a while, some dependencies like
Mautrix are not yet in Debian, and JavaScript components are always a
pain (fortunately, Laniakea only has few of those).

Packaging will be maintained at https://salsa.debian.org/laniakea-team/laniakea

Cheers,
Matthias

Bug#1058924: gnome-software: does not list or find any apt package

[Matthias Klumpp]

Am Fr., 5. Jan. 2024 um 18:20 Uhr schrieb Jeremy Bícha
:
>
> On Fri, Jan 5, 2024 at 11:08 AM Matthias Klumpp  wrote:
> > I do recall something being fixed on that front months ago, but I
> > couldn't find  the patch (so maybe testing with 46.beta is a good
> > plan, to see if that one resolves the issue).
>
> GNOME Software 46 Alpha was released today. I installed it and it
> didn't fix my problem. I guess I could upload it to Unstable or
> Experimental.

Sorry, I got a bit confused since my local Git copy showed 46 Beta ^^
I poked it a bit and it looks like
https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1862
fixes the issue completely for me and OS applications show up again.
So, this would be a MIME detection issue, unless it's a combination of
separate problems that we are dealing with.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1058924: gnome-software: does not list or find any apt package

[Matthias Klumpp]

Am Fr., 5. Jan. 2024 um 15:04 Uhr schrieb Jeremy Bícha
:
>
> Matthias,
>
> I am experiencing this issue on Debian Testing and that was before
> appstream 1.0 migrated to Testing today.

Very odd...

> I am also experiencing this issue with Ubuntu 24.04 but not with the
> stable Ubuntu 23.10, even if I am using the same version of
> gnome-software. https://launchpad.net/bugs/2047818
>
> Did something change with appstream-generator or something else at a
> lower level?

AppStream 1.0 is a fairly huge update, and GNOME Software is not using
libappstream facilities for everything but is often doing its own
thing, making GS sometimes the odd one out by behaving differently
from everything else. We might have some of that here, however if I
run GS in verbose mode I get this:

14:56:38:467 XbSilo ignoring invalid file
/var/lib/swcatalog/yaml/deb.debian.org_debian_dists_testing_main_dep11_Components-amd64.yml.gz:ctime=170
4463598.154626:func-id=AddIcons@2:func-id=AppStreamUpgrade2@3:func-id=AddOriginKeyword@1:func-id=TextTokenize@2:func-id=MediaBaseUrl@3:scope=syste
m:filename=/var/lib/swcatalog/yaml/deb.debian.org_debian_dists_testing_main_dep11_Components-amd64.yml.gz:
cannot process content type application
/yaml
14:56:38:467 XbSilo ignoring invalid file
/var/lib/swcatalog/yaml/deb.debian.org_debian_dists_testing_contrib_dep11_Components-amd64.yml.gz:ctime=
1704463598.154626:func-id=AddIcons@2:func-id=AppStreamUpgrade2@3:func-id=AddOriginKeyword@1:func-id=TextTokenize@2:func-id=MediaBaseUrl@3:scope=sy
stem:filename=/var/lib/swcatalog/yaml/deb.debian.org_debian_dists_testing_contrib_dep11_Components-amd64.yml.gz:
cannot process content type appli
cation/yaml
14:56:38:467 XbSilo ignoring invalid file
/var/lib/swcatalog/yaml/deb.debian.org_debian_dists_testing_non-free_dep11_Components-amd64.yml.gz:ctime
=1704431294.941037:func-id=AddIcons@2:func-id=AppStreamUpgrade2@3:func-id=AddOriginKeyword@1:func-id=TextTokenize@2:func-id=MediaBaseUrl@3:scope=s
ystem:filename=/var/lib/swcatalog/yaml/deb.debian.org_debian_dists_testing_non-free_dep11_Components-amd64.yml.gz:
cannot process content type app
lication/yaml
14:56:38:467 XbSilo ignoring invalid file
/var/lib/swcatalog/yaml/deb.debian.org_debian_dists_testing_non-free-firmware_dep11_Components-amd64.yml
.gz:ctime=1704195943.915785:func-id=AddIcons@2:func-id=AppStreamUpgrade2@3:func-id=AddOriginKeyword@1:func-id=TextTokenize@2:func-id=MediaBaseUrl@
3:scope=system:filename=/var/lib/swcatalog/yaml/deb.debian.org_debian_dists_testing_non-free-firmware_dep11_Components-amd64.yml.gz:
cannot proces
s content type application/yaml

This is actually strongly hinting at the issue not being with
AppStream, but with GNOME Software's or libxmlb's MIME handling
instead.
I do recall something being fixed on that front months ago, but I
couldn't find  the patch (so maybe testing with 46.beta is a good
plan, to see if that one resolves the issue).

I also tested this before, so it's really odd that this broke
somehow... (maybe in addition to the new MIME detection issue, we now
*also* have GS not liking some YAML change, but I don't know what that
would be - the fact that this also happens in Ubuntu, which didn't
update its metadata generation, hints at the issue not being related
to the data itself).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1060016: packagekit: CVE-2024-0217

[Matthias Klumpp]

Hi!

Am Do., 4. Jan. 2024 um 20:51 Uhr schrieb Salvatore Bonaccorso
:
>
> Source: packagekit
> Version: 1.2.6-5
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
>
> Hi,
>
> The following vulnerability was published for packagekit.
>
> CVE-2024-0217[0]:
> | A use-after-free flaw was found in PackageKitd. In some conditions,
> | the order of cleanup mechanics for a transaction could be impacted.
> | As a result, some memory access could occur on memory regions that
> | were previously freed. Once freed, a memory region can be reused for
> | other allocations and any previously stored data in this memory
> | region is considered lost.
>
> The only reference know so far is [1] which say as well that the issue
> should be fixed in 1.2.7 upstream. Do you happen to know more on it?

This might be the worst CVE I've seen in a while... PackageKit has
backends, so at the very least this CVE should state whether this
affects a backend only (in which case we might even be fine if we
don't ship it) or the daemon core, or a library. Judging from how this
is worded, it's likely one of the latter, which would be worse.
On the bug report, it is stated that "It was observed that under some
conditions, the order of cleanup mechanics for a transaction could be
impacted.", but there are no details given what these circumstances
even are.
Furthermore, Philip Withnall did quite a bit of larger rework on
PackageKit's transaction logic for 1.2.7, so whatever the issue is it
might have been accidentally fixed in a larger commit of that series.

But tbh, this CVE is so vague that I have no idea where I'd even look
for this (unless I wanted to repeat the work that went into finding
this and create random transaction states while running with address
sanitizer on).
Let's hope the reporter replies to the request in RH bugzilla.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1058924: gnome-software: does not list or find any apt package

[Matthias Klumpp]

Hi!

Very odd issue... If you run `apt update` in a terminal, do you see
any "Components" YAML files being downloaded?
What is in /var/lib/swcatalog/?

Cheers,
Matthias

Bug#1058908: plasma-workspace 4:5.27.10-1 loses appstream and breeze support

[Matthias Klumpp]

Am Mo., 18. Dez. 2023 um 09:09 Uhr schrieb Adrian Bunk :
> [...]
> ...
> -- The following OPTIONAL packages have not been found:
>
>  * Breeze (required version >= 5.27.10)
>For setting the default window decoration plugin
>  * AppStreamQt5 (required version >= 0.10.6), Access metadata for listing 
> available software, 
> 
> ...

Damn, I checked for AppStream, but must have missed that - and Breeze!

Sorry for that, I will look into fixing that issue ASAP today or tomorrow!
Breeze will likely just need a version update, AppStream I am not sure
about yet...

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1056543: isenkram: No new firmware package with requested firmware detected (but firmware files are missing)

[Matthias Klumpp]

Actually, this would even have backwards compatibility - but I haven't
tested anything, so not sure if this works:

diff --git a/appstream2modaliases b/appstream2modaliases
index 1c3e6a2..f7077c9 100755
--- a/appstream2modaliases
+++ b/appstream2modaliases
@@ -11,15 +11,13 @@ gi.require_version('AppStream', '1.0')
 from gi.repository import AppStream
 import re

+pool = AppStream.Pool()
+pool.load()
 try:
-pool = AppStream.Pool()
-pool.load()
-cpts = pool.get_components()
+cpts = pool.get_components().asArray()
 except AttributeError:
-# Handle old API too (before version 0.10)
-db = AppStream.Database()
-db.open()
-cpts = db.get_all_components()
+# Handle old API too (before version 1.0)
+cpts = pool.get_components()

 ma_cpts = list()
 fwr_cpts = list()
diff --git a/isenkram/lookup.py b/isenkram/lookup.py
index e10a999..eb3e4f6 100644
--- a/isenkram/lookup.py
+++ b/isenkram/lookup.py
@@ -71,15 +71,14 @@ def pkgs_handling_appstream_modaliases(modaliaslist):
 from gi.repository import AppStream
 except ValueError:
 return []
+
+pool = AppStream.Pool()
+pool.load()
 try:
-pool = AppStream.Pool()
-pool.load()
-cpts = pool.get_components()
+cpts = pool.get_components().asArray()
 except AttributeError:
-# Handle old API too (before version 0.10)
-db = AppStream.Database()
-db.open()
-cpts = db.get_all_components()
+# Handle old API too (before version 1.0)
+cpts = pool.get_components()
 ma_cpts = list()
 for cpt in cpts:
 provided = cpt.get_provided_for_kind(AppStream.ProvidedKind.MODALIAS)
diff --git a/appstream2modaliases b/appstream2modaliases
index 1c3e6a2..f7077c9 100755
--- a/appstream2modaliases
+++ b/appstream2modaliases
@@ -11,15 +11,13 @@ gi.require_version('AppStream', '1.0')
 from gi.repository import AppStream
 import re
 
+pool = AppStream.Pool()
+pool.load()
 try:
-pool = AppStream.Pool()
-pool.load()
-cpts = pool.get_components()
+cpts = pool.get_components().asArray()
 except AttributeError:
-# Handle old API too (before version 0.10)
-db = AppStream.Database()
-db.open()
-cpts = db.get_all_components()
+# Handle old API too (before version 1.0)
+cpts = pool.get_components()
 
 ma_cpts = list()
 fwr_cpts = list()
diff --git a/isenkram/lookup.py b/isenkram/lookup.py
index e10a999..eb3e4f6 100644
--- a/isenkram/lookup.py
+++ b/isenkram/lookup.py
@@ -71,15 +71,14 @@ def pkgs_handling_appstream_modaliases(modaliaslist):
 from gi.repository import AppStream
 except ValueError:
 return []
+
+pool = AppStream.Pool()
+pool.load()
 try:
-pool = AppStream.Pool()
-pool.load()
-cpts = pool.get_components()
+cpts = pool.get_components().asArray()
 except AttributeError:
-# Handle old API too (before version 0.10)
-db = AppStream.Database()
-db.open()
-cpts = db.get_all_components()
+# Handle old API too (before version 1.0)
+cpts = pool.get_components()
 ma_cpts = list()
 for cpt in cpts:
 provided = cpt.get_provided_for_kind(AppStream.ProvidedKind.MODALIAS)

Bug#1056543: isenkram: No new firmware package with requested firmware detected (but firmware files are missing)

[Matthias Klumpp]

This patch is probably all you need:

diff --git a/appstream2modaliases b/appstream2modaliases
index 1c3e6a2..7408107 100755
--- a/appstream2modaliases
+++ b/appstream2modaliases
@@ -14,7 +14,7 @@ import re
try:
pool = AppStream.Pool()
pool.load()
-cpts = pool.get_components()
+cpts = pool.get_components().asArray()
except AttributeError:
# Handle old API too (before version 0.10)
db = AppStream.Database()
diff --git a/isenkram/lookup.py b/isenkram/lookup.py
index e10a999..ee13c1b 100644
--- a/isenkram/lookup.py
+++ b/isenkram/lookup.py
@@ -74,7 +74,7 @@ def pkgs_handling_appstream_modaliases(modaliaslist):
try:
pool = AppStream.Pool()
pool.load()
-cpts = pool.get_components()
+cpts = pool.get_components().asArray()
except AttributeError:
# Handle old API too (before version 0.10)
db = AppStream.Database()

The queries are very inefficient though, those can likely be optimized
a lot. I'll look into that at a later time.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1056543: isenkram: No new firmware package with requested firmware detected (but firmware files are missing)

[Matthias Klumpp]

Am Fr., 15. Dez. 2023 um 10:53 Uhr schrieb Petter Reinholdtsen
:
>
> [Petter Reinholdtsen]
> >> But it'll all be doable (from last time I looked, the change will
> >> likely just be a one-liner).
> >
> > Perhaps you have time to prepare a patch?  I have not had time to
> > study the changes.  I am happy to coordinate a migration any time, but
> > would prefer the code to be backportable without modifications to
> > Debian Stable.
>
> Or perhaps you have a link to a description of the changes needed, so I
> could have a go myself?

There is no official list, you would need to run it and see if there
are any issues (which is why I don't want to make these changes
(besides having very little time) because I don't know the software
well and can't test it properly).
There have been no behavior changes without function renames, and the
changes are also not that radical - it is extremely likely that all
you will need to do is to add a ".asArray()" to the result of your
search calls you made on AsPool, and that would be it to make things
work as before :-) (and with the improved language binding support,
this should no longer break, with me having to choose between breaking
it for Vala users and breaking it for Python users).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1056543: isenkram: No new firmware package with requested firmware detected (but firmware files are missing)

[Matthias Klumpp]

Am Mi., 22. Nov. 2023 um 20:35 Uhr schrieb Petter Reinholdtsen
:
>
> [Alexey Kuznetsov]
> > It is working. Huge output https://paste.debian.net/1298974/
>
> I am not convinced.  It seem to claim that the file is in several
> packages, which can not be correct.  Matthias, any idea what is going
> wrong with the appstreamcli call?  See
> https://bugs.debian.org/1056543 > for the details.

Ooof, good find! Looks like this broke with a libxmlb upgrade, but is
actually (as far as I can tell) still an issue in libappstream.
It's fixed now:
https://github.com/ximion/appstream/commit/d2eb316884c3a213e959d40ae9ad18d5f590bd17

There is an AppStream 1.0 transition coming up which will need most
dependencies to be adjusted, including Isenkram. But you'll gain a
much more stable binding interface with 1.0.
I don't know if the timing works out to be quick enough that this fix
would just be in 1.0.1 uploaded to unstable- there's a few things on
the KDE side that need some porting, and Isenkram would too - and
making it work for both versions will be slightly annoying due to a
binding versioning issue in pre-1.0.
But it'll all be doable (from last time I looked, the change will
likely just be a one-liner).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1055293: dub: Please upgrade to a new version

[Matthias Klumpp]

Hi Nilesh!

Am Fr., 3. Nov. 2023 um 17:54 Uhr schrieb Nilesh Patra :
> [...]
> dub seems to be at a really old version and it is just "limping" to stay
> in testing at the moment and the version there was released 3 years
> back, this is behind a bunch of new releases.
>
> I noticed there is a new version committed to salsa but it does not
> build and this seems unfixed upstream as well. I however did find a
> (unmerged) PR that fixes it:
>
> https://github.com/dlang/dub/pull/2623
>
> IMHO dub should be updated to latest version once those rough edges are
> sorted out.

It does not, unfortunately. I just tried building the package using
the latest Dub version, and the actual blocking issue, which is
https://github.com/dlang/dub/issues/2577, still exists.
We need to resolve that or find a workaround in order to update dub.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1053852: btrfsd: Segfault in libgobject-2.0.so.0.7800.0[7fcec2dff000+34000]

[Matthias Klumpp]

Am Fr., 13. Okt. 2023 um 12:27 Uhr schrieb Vincent Blut
:
> [...]
> I built btrfsd with 59145f1 (utils: Don't free result twice when checking if 
> device is on
> battery) applied, that fixes the issue. Thanks!

Indeed, it was a really dumb oversight to free things manually that
automatic cleanup was already taking care of.
Sorry for that! There will be a new release today :-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1053852: btrfsd: Segfault in libgobject-2.0.so.0.7800.0[7fcec2dff000+34000]

[Matthias Klumpp]

Hi!

Thank you for the issue report!
How did you run btrfsd exactly? Did you set anything specific in its
configuration file? Can you generate a backtrace with debug symbols
for btrfsd installed?

Cheers,
Matthias

Bug#1051471: btrfsd: cron job for calling btrfsd

[Matthias Klumpp]

Hi Martin!

Am Fr., 8. Sept. 2023 um 15:24 Uhr schrieb Martin :
> [...]
> would you consider to include a cron job into the package in order to
> make btrfsd installable on systems without Systemd? Of course a change
> regarding package dedepencies would also be required.

Sure, that should actually be extremely low-maintenance, there isn't
any hard dependency the daemon has on systemd - with one exception: It
uses libsystemd to write to the journal if that's available, and I
would like to keep that feature. It will however already fall back to
syslog in case sd-journal isn't available, and libsystemd is inert on
systems without systemd.

> I have seen btrfsd in mailing list "debian-devel-changes" but could not
> find it on my Devuan system.
>
> If yes, I would aim to provide a merge request.

This could go upstream, I think.
I do not know if there is a no-overhead way to ship both the cron job
and systemd timer in the same package with recompilation. But if
that's not possible, I think at the very least we could provide a
configuration option upstream to select one or the other, so
derivatives that don't use systemd could switch to the cron version by
simply recompiling the package (by checking dpkg vendor strings).

What do you think? Unfortunately I know little how to make both
systems interoperate and avoid having the timer and cron job calling
the service, so patches would be very welcome.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1037214: bullseye-pu: package appstream-glib/0.7.18-1+deb11u1

[Matthias Klumpp]

Am Do., 8. Juni 2023 um 21:18 Uhr schrieb Simon McVittie :
>
> On Wed, 07 Jun 2023 at 21:33:29 +0100, Simon McVittie wrote:
> >   [x] attach debdiff against the package in (old)stable
>
> That was, in fact, a lie. See attached (or the nmudiff on #1037206 if
> you'd prefer the unfiltered version).

Thank you for working on this! It will be nice to have this issue
fixed in bullseye soon, as it seems to affect quite a bunch of users!

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1036984: unblock: packagekit/1.2.6-5

[Matthias Klumpp]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package packagekit.

[ Reason ]
Three things fixed:
* A tiny memory leak has been addressed
* The daemon package now recommends the tools package again, this was
changed late in release and apparently caused issues to some people
(see the referenced bug)
* Many parts of the documentation reference the old packagekit.org
domain, which is now taken over by a 3rd-party who is playing ads on
it - so far it's harmless, but we do not know what will happen with
this domain in future, so we should avoid referencing it and rather
point at the right location @ freedesktop.org

[ Impact ]
People could click through to a defunct website with tracking ads when
trying to reach the PackageKit documentation or information about e.g.
missing codecs.

[ Tests ]
The memleak fix has been upstreamed for a while and is harmless, the
changed recommendation restores previous behavior, and the
documentation changes do not have any behavioral change.

[ Risks ]
Very low, as the only functional change is adding a missing free() for
a memory leak fix, every other change is either purely in the
documentation or restores previously tested behavior.

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

Thank you!

unblock packagekit/1.2.6-5


packagekit_1.2.6-4_to_1.2.6-5.debdiff
Description: Binary data

Bug#1036982: unblock: debspawn/0.6.2-1

[Matthias Klumpp]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package debspawn.

[ Reason ]
Packaging of the 0.6.2 bugfix release which contains three changes only:
 * Fixes issue where users could not build packages against
NotAutomatic suites like Debian experimental when the
"experimental"-like suite did not contain enough of the required
dependencies (APT's solver was too limited)
 * Python 3.11 support (minimal changes)
 * Fixes a crash when regenerating an image with `update --recreate`
in case the image had a custom name

[ Impact ]
People would not be able to build packages for experimental, using
`update --recreate` for images with custom names would crash.

[ Tests ]
Tested by upstream, used in production at Purism already for a few
weeks, so far no issues have been found.

[ Risks ]
The worst that could happen is that building experimental packages
stays broken, so no regression would happen. Apart from that, this
change is very small and should be fairly safe.

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

Thank you!

unblock debspawn/0.6.2-1


debspawn_0.6.1-1_to_0.6.2-1.debdiff
Description: Binary data

Bug#1036979: unblock: appstream/0.16.1-2

[Matthias Klumpp]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package appstream.

[ Reason ]
Backports a few fixes from the 0.16.2 release:
 * Fixes two crashes that can happen when the tool is fed invalid or
unexpected input
 * Correctly validates some valid license expressions (LibreOffice was
affected by this)
 * Fixes an issue where component-IDs weren't reproducibly
synthesized, leading to ratings/reviews not showing up for these apps
 * Adds a fix for a noisy warning with newer GLib versions that is
inert on older releases

[ Impact ]
More crashes and invalid evaluation of valid license terms, if not updated.

[ Tests ]
Tested by upstream and other distros for months already, does not
break API/ABI, we already use these changes on Debian's appstream.d.o
service to avoid crashes with Qt apps.

[ Risks ]
None that I can think of.

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

Thank you for your work on getting the release out!

unblock: appstream/0.16.1-2


appstream_0.16.1-1_to_0.16.1-2.debdiff
Description: Binary data

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Matthias Klumpp]

Am Do., 18. Mai 2023 um 20:39 Uhr schrieb Luca Boccassi :
> [...]
> We heard so much in the past couple of weeks about how important it is
> for the project not to cause issues for derivatives and
> cross-compatibility use cases, even speculatively. This is not even
> speculative, it is certain to cause damage (as we experienced first
> hard last year), I don't see how we can ignore it after all of these
> discussions.

Speaking as maintainer of two Debian derivatives (PureOS and an
internal one), keeping this warning means we will need to patch dpkg
which of course is possible, but also a bit annoying. It is also odd
that Debian's configuration suddenly becomes "invalid" just by
changing the name of the OS.
(FWIW, PureOS has been usrmerged before Debian did that officially,
and so was Ubuntu - so far we haven't experienced any issues and our
users are happy - syncing dpkg without patching it will for sure cause
a lot of confusion though).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1035567: debootstrap: Does not support APT repositories with modern split arch:all support

[Matthias Klumpp]

Package: debootstrap
X-Debbugs-Cc: m...@debian.org
Version: 1.0.128+nmu2
Severity: normal
Tags: patch

Dear Maintainer,
currently debootstrap fails to work with APT repositories that have
arch:all split out exclusively into a separate Packages file, instead
of having arch:all merged into every arch:any Packages file in archive
metadata.
APT has already been supporting the new scheme for multiple releases,
so it would be nice if debootstrap supported it too (so far, it is the
only tool I found that doesn't do that). This would enable us in
PureOS to use the new APT repository style, as well as potentially
other derivatives and Debian itself in future as well.

The APT repository format (for both styles and the current
"compatibility mode" that the Debian archive runs on) is described
here: https://wiki.debian.org/DebianRepository/Format#Architectures

I attached a patch which implements support for this feature in
debootstrap. So far it has been working find for bootstrapping both
Debian (with the "compatibility" archive metadata mode) as well as a
PureOS scratch repository which uses the newer-style APT repository
mode.

You can also review this patch as MR @ Salsa:
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/92

Thank you for considering!
I've set this bug as "normal", since I do consider bringing
debootstrap on-par with what features APT supports for a while as
important, but feel free to reduce it to "whishlist" priority if you
think that is more appropriate for a feature request like this.

With kind regards,
Matthias Klumpp

-- 
I welcome VSRE emails. See http://vsre.info/
From 5dd4cef1a5a03dc180eb2ec1d2bfc97023f74d2b Mon Sep 17 00:00:00 2001
From: Matthias Klumpp 
Date: Sun, 23 Apr 2023 22:30:02 +0200
Subject: [PATCH] Implement support for repos with modern-style arch:all
 support

This implements support for modern APT repositories which have arch:any
and arch:all packages in separate Packages files, as outlined in the
Debian
repository documentation:
https://wiki.debian.org/DebianRepository/Format#Architectures
---
 functions | 274 +-
 1 file changed, 168 insertions(+), 106 deletions(-)

diff --git a/functions b/functions
index 0ff5379..8bffbc6 100644
--- a/functions
+++ b/functions
@@ -557,6 +557,24 @@ extract_release_components () {
 	fi
 }
 
+repo_supports_arch_all () {
+	local a no_arch_all_support
+	local reldest="$1"; shift
+	TMPARCHS="$(sed -n 's/Architectures: *//p' "$reldest")"
+	ARCH_ALL_SUPPORTED=0
+	for a in $TMPARCHS ; do
+		if [ "$a" = "all" ]; then
+			ARCH_ALL_SUPPORTED=1
+			break
+		fi
+	done
+
+	no_arch_all_support=$(grep "^No-Support-for-Architecture-all: Packages$" "$reldest" || true)
+	if [ "$no_arch_all_support" != "" ]; then
+		ARCH_ALL_SUPPORTED=0
+	fi
+}
+
 CODENAME=""
 validate_suite () {
 	local reldest suite s
@@ -667,7 +685,7 @@ download_release_sig () {
 download_release_indices () {
 	local m1 inreldest reldest relsigdest totalpkgs \
 	  subpath xzi bz2i gzi normi i ext \
-	  donepkgs pkgdest acquirebyhash s c m
+	  donepkgs pkgdest acquirebyhash archs s c a m
 	m1="${MIRRORS%% *}"
 	for s in $SUITE $EXTRA_SUITES; do
 		inreldest="$TARGET/$($DLDEST rel "$s" "$m1" "dists/$s/InRelease")"
@@ -680,70 +698,80 @@ download_release_indices () {
 
 		extract_release_components "$reldest"
 
+		repo_supports_arch_all "$reldest"
+
+		archs="$ARCH"
+		if [ $ARCH_ALL_SUPPORTED -eq 1 ]; then
+			archs="all $ARCH"
+		fi
+
 		acquirebyhash=$(grep "^Acquire-By-Hash: yes$" "$reldest" || true)
-		totalpkgs=0
-		for c in $COMPONENTS; do
-			subpath="$c/binary-$ARCH/Packages"
-			xzi="$(get_release_checksum "$reldest" "$subpath.xz")"
-			bz2i="$(get_release_checksum "$reldest" "$subpath.bz2")"
-			gzi="$(get_release_checksum "$reldest" "$subpath.gz")"
-			normi="$(get_release_checksum "$reldest" "$subpath")"
-			if [ "$normi" != "" ]; then
-i="$normi"
-			elif in_path bunzip2 && [ "$bz2i" != "" ]; then
-i="$bz2i"
-			elif in_path unxz && [ "$xzi" != "" ]; then
-i="$xzi"
-			elif in_path gunzip && [ "$gzi" != "" ]; then
-i="$gzi"
-			fi
-			if [ "$i" != "" ]; then
-totalpkgs=$(( $totalpkgs + ${i#* } ))
-			else
-mv "$reldest" "$reldest.malformed"
-error 1 MISSINGRELENTRY "Invalid Release file, no entry for %s" "$subpath"
-			fi
-		done
 
-		donepkgs=0
-		progress 0 $totalpkgs DOWNPKGS "D

Bug#777595: update-notifier: Wrong license in debian/copyright (compared to COPYING)

[Matthias Klumpp]

Hi Andreas!

This RC bug has nothing to do with gnome-packagekit, and
update-notifier was deleted from the archive in 2014. Was this issue
reassigned in error?

Thanks!
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1033814: apper: An update for it to fix the kded5 crashing problem

[Matthias Klumpp]

Am So., 2. Apr. 2023 um 09:15 Uhr schrieb Bob Wong :
>
> Package: apper
> Version: 1.0.0-4
> Severity: important
> X-Debbugs-Cc: ybx...@gmail.com
>
> Dear Maintainer,
>
> The upstream has released a new version of the apper to fix the kded5 crashing
> problem in their Github repo, hope we can get it fixed before the release of
> the Debian bookworm.

What kind of crash are you talking about? Can you give more details,
e.g. a bug report link?
I also can not see any new release of Apper...

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1026062: kded5: kded crashes with signal 11

[Matthias Klumpp]

Am Sa., 11. März 2023 um 17:00 Uhr schrieb Aurélien COUDERC :
>
> Many thanks to all for tracking this bug, adding info, coordinating with 
> upstream, following progress, testing the fix, and thanks to Matthias for 
> uploading the fixed upstream version.
>
> @Matthias I think we really shouldn't release without the fix so an upgraded 
> severity to >= serious would be appropriate for this bug. But I'll leave you 
> judge on that.

Odd, I was sure the bug was already marked as RC, but it looks like it
wasn't. It really should be though, I'll change that.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1031091: dep11 files missing for bookworm (non-free-firmware)

[Matthias Klumpp]

Hi!

Am Sa., 11. Feb. 2023 um 16:44 Uhr schrieb Cyril Brulebois :
> Steve McIntyre  (2023-02-11):
> > As part of the nff changes, debian-cd now looks for dep11 metadata to
> > help work out what firmware might be needed. We have that working for
> > all other arches, but *not* mipsel. Builds are failing looking for
> >
> > /dists/bookworm/main/dep11/Components-mipsel.yml.gz
> >
> > Please fix up archive config so this works.
>
> The problem is the configuration on mekeel (appstream.d.o), see
> /srv/appstream.debian.org/workspace/asgen-config.json
>
> I'd suggest proposing a patch for Matthias to apply.

Looks like we simply didn't generate data for that architecture. I've
added it to the list, as data should be created for all architectures
that Debian supports officially.
See 
https://salsa.debian.org/pkgutopia-team/debian-asgen-config/-/commit/6de08ba2795f39b7171315d580201f1040afd9b7

It will take a few hours, depending on how the archive syncs up even a
day, for changes to take effect.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1030719: RM: webapps-metainfo -- ROM; Superseded

[Matthias Klumpp]

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

Hi!
Please remove webapps-metainfo from unstable/testing.
It was a nice idea years ago to provide metainfo files for suitable
web applications as a package, but this method has been replaced by a
more flexible Git based workflow, and we do not need this package
anymore.

Thank you!
Matthias

Bug#1030718: RM: stdx-allocator -- ROM; Dead upstream

[Matthias Klumpp]

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

Hi!
Please remove stdx-allocator from unstable/testing. It has been dead
upstream for a while, and people seem to generally use the version
available in the D standard library now, which is much easier to
maintain anyway and recent enough.

Thank you!
Matthias

Bug#1027831: libpackagekitqt5-1: Discover does not notify about pending updates

[Matthias Klumpp]

Hi!
Can you please report this against PackageKit-Qt so we have a reference there?
It's an odd bug for sure, the amount of changes for the new QPK was
quite small and overall the library seems to be working fine. I wonder
whether this is a case of Discover not having adjusted to handle
plural signals from PK properly.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1026076: gnome-software: Download size is unknown for apps from Debian archive

[Matthias Klumpp]

Hi!

Am Mi., 14. Dez. 2022 um 11:51 Uhr schrieb Danial Behzadi
:
> [...] It couldn't be so hard to fix this as we already
> have download size for packages in apt lists and it could be even port
> to upstream. [...]

It's actually not that easy, because a package has a bunch of
dependencies that would be needed to be included in the total download
size, so we would need to resolve the dependency graph for the
to-be-installed package first, and then calculate the total, which
isn't that fast.
That being said, it can be done (as a background task if it may take
longer), or we could display only the size of the currently referenced
package. At least the latter should already be the case, and
PackageKit has that information, so it's a bit odd that it isn't
shown.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1018801: stdx-allocator ftbfs: assertThrown failed: No Exception was thrown.

[Matthias Klumpp]

Am Mi., 31. Aug. 2022 um 03:01 Uhr schrieb Steve Langasek
:
>
> Source: stdx-allocator
> Version: 3.1.0~beta.2-3
> Severity: serious
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu kinetic
>
> Hi Matthias,
>
> After fixing up stdx-allocator build-deps so that they're installable,
> stdx-allocator fails to build from source due to a test failure:
>
> [...]

Hah! I need to test this, but this *may* just be related to removing
the dip1008 flag from the mir-core flags list entirely - it may be
needed after all.
Or this is completely unrelated to that and a completely different bug
- unfortunately, I can only really dive into this at the weekend...

Thanks!
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1018796: mir-core: FTBFS with gdc: unrecognized commandline option -preview=dip1008

[Matthias Klumpp]

Am Mi., 31. Aug. 2022 um 01:09 Uhr schrieb Steve Langasek
:
>
> Package: mir-core
> Version: 1.1.111-1
> Severity: serious
> Tags: patch
> Justification: ftbfs
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu kinetic ubuntu-patch
>
> Hi Matthias,
>
> The mir-core package is failing to build on all gdc archs in unstable
> because meson.build includes a compiler option, '-preview=dip1008', which is
> ldc-specific and not understood by gdc.
>
> Patching this option out lets the package build on all archs, including
> those using ldc, so it doesn't appear to be needed.

How odd, that particular DIP was apparently postponed:
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
Not sure if we can just drop the flag, but I assume the answer is yes,
in which case we should forward this patch upstream as well.
If not, then the Meson code needs to pass "-fpreview=dip1008" (instead
of -preview...) to the compiler if its identifier is gnu.
Thanks for looking into this!

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1018795: dh-dlang: support for mapping dpkg-buildflags for ldc but it's not used

[Matthias Klumpp]

Hi!

Am Mi., 31. Aug. 2022 um 00:57 Uhr schrieb Steve Langasek
:
>
> Package: dh-dlang
> Version: 0.6.5
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu kinetic ubuntu-patch
>
> Hi Matthias,
>
> I noticed in Ubuntu when trying to rebuild most packages against ldc 1.30.0
> that they were now failing to build with current dh-dlang, because including
> /usr/share/dh-dlang/dlang-flags.mk caused dpkg-buildflags' LDFLAGS to be
> exported and these flags are not understood by ldc (specifically:
> -Wl,-Bsymbolic-functions and -Wl,-z,relro on Ubuntu).  This can be seen in
> Debian in the failed build of gir-to-d:
>
> [...]
> ../meson.build:1:0: ERROR: Unable to detect linker for compiler `ldc2 
> -L=--version /tmp/tmpsh_a2h39.d -Wl,-z,relro -O -g -release -wi --allinst`
> stdout:
> stderr: ldc2: Unknown command line argument '-Wl,-z,relro'.  Try: 'ldc2 
> --help'
> ldc2: Did you mean '--icp-lto'?
> [...]
>
>   
> (https://buildd.debian.org/status/fetch.php?pkg=gir-to-d=amd64=0.22.0-3%2Bb1=1661202072=0)

So, this is actually a Meson regression, that is tracked as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017087 and already
fixed upstream, but sadly not yet resolved in Debian.
IMHO the right place to fix this issue is in Meson, and not to work
around it in dh-dlang, because the Meson fix will even work for
packages which don't use dh-dlang, although there also *should* not be
any harm in applying a workaround - however

> Paradoxically, there is support in dh-dlang for mapping these flags for ldc,
> but this support is not included automatically in dlang-flags.mk.

... AFAIR using this for LDFLAGS caused problems with other D tools (I
specifically recall dub), but this has been long ago and the D
toolchain was much buggier than it is today (yes, even more! :-P), so
maybe that issue was solved...

TBH, I genuinely don't know what the best course of action is here -
obviously we need the Meson regression fixed, but I'm not sure if we
should also apply this patch and possibly thereby mask future problems
(or create new ones, but we'd notice these rather quickly!).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1018732: mir-core: FTBFS: ERROR: Unable to detect linker for compiler `ldc2 -L=--version /tmp/tmpq8z68wht.d -Wl,-z,relro -O -g -release -wi`

[Matthias Klumpp]

Control: reassign -1 meson 0.63.1-1
Control: forcemerge -1 1017087
Control: affects 1017087 + mir-core

This is due to a regression in Meson itself reported as bug #1017087
Hopefully we will get a fix into Debian soon, merging this with the
original bug.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1017087: meson: All ldc related packages FTBFS with 0.63.1-1

[Matthias Klumpp]

Hi!

I was going to report this bug, but fortunately checked whether
someone already created it beforehand :-)
So, the culprit is highly likely
https://github.com/mesonbuild/meson/commit/0ec039d2597526c670f7e0478a7b5008e14ff474
This passes LDFLAGS from the environment to the compiler to figure out
the linker. However, for LDC, you can't simply do that - the
environment linker flags would need to be preprocessed first in order
to be suitable for LDC, like so:
https://github.com/mesonbuild/meson/blob/master/mesonbuild/compilers/d.py#L286

This is really a Meson bug, as we can not expect LDFLAGS to be passed
to anything but the linker, so sanitizing these beforehand does not
make much sense (especially since this worked before).

I'll report it upstream.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1017077: sets compiler and flags wrong for armhf

[Matthias Klumpp]

Hi!
I haven't looked deeply into this, bit for armhf using GDC is the intended
choice - it has way fewer bugs than LDC, which generally seems to work
better on 64bit architectures. That's why this was changed in the past (so
at least of stuff compiles with gdc, the resulting binary will work).
I'm currently traveling, so I'll look at this issue properly later.
Cheers,
Matthias

Nilesh Patra  schrieb am Sa., 13. Aug. 2022, 08:42:

> Package: dh-dlang
> Version: 0.6.5
> Severity: important
> X-Debbugs-Cc: m...@debian.org
>
> Hi,
>
> dh-dlang seems to export flags for armhf incorrectly. ldc is
> supported on armhf and hence this should be exported if available
> however dh-dlang does not seem to honor that[1]
>
> Furthermore, it has a snippet in the same condition to set
> extra DFLAGS for armhf[2] which makes it a no-op.
> Similar modifications should probably be done on default-d-compiler
> metapkg too.
>
> This was making diet-ng FTBFS for a while, so I added a workaround for
> it there.
>
> [1]: https://sources.debian.org/src/dh-dlang/0.6.5/dlang-flags.mk/#L27
> [2]: https://sources.debian.org/src/dh-dlang/0.6.5/dlang-flags.mk/#L32
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages dh-dlang depends on:
> ii  debhelper   13.8
> pn  default-d-compiler  
> ii  python3 3.10.5-3
>
> dh-dlang recommends no packages.
>
> dh-dlang suggests no packages.
>

Bug#1010421: gir-to-d: FTBFS with ldc 1.29

[Matthias Klumpp]

severity 1010421 important
thankyou

Hi!
I'm reducing the severity since an easy-ish workaround is available and 
keeping this at a blocking severity prevents the workaround-included 
gir-to-d version to migrate.


This is still an important issue though which should be fixed for the 
release, as it might be triggered by pretty much any D code at compile-time.

Bug#1008687: FTBFS: as-test_pool FAIL killed by signal 6 SIGABRT

[Matthias Klumpp]

Hi Florian!

Am Mo., 11. Apr. 2022 um 09:30 Uhr schrieb Florian Ernst
:
>
> Hello Matthias,
>
> thank you for your reply and for the appstream update.
>
> On Sun, Apr 10, 2022 at 11:08:40PM +0200, Matthias Klumpp wrote:
> > Am Mi., 30. März 2022 um 20:21 Uhr schrieb Florian Ernst 
> > :
> > > during a rebuild of the reverse b-d of libyaml I found that this package
> > > failed to build on my amd64.
> > >
> > > In addition, the build also failed on amd64, i386, arm64, and armhf,
> > > each both in unstable and in bookworm, cf.
> > > <https://tests.reproducible-builds.org/debian/rb-pkg/appstream.html>
> > > where you will also find full logs.
> >
> > I can't reproduce this issue at all, and a recent upload of AppStream
> > is building fine on all architectures...
> > Does this issue still exist? Maybe it was a fluke or fixed in some
> > other component meanwhile...
>
> I agree that the new upload appears to be building just fine on the
> official buildd, so thanks for that.
>
> Unfortunately, for me both the previous version and the current version
> still FTBFS on my local setup, with exactly the same error message. Of
> course, that by itself could all too easily be a local fluke that I'd
> have to investigate and that you could safely ignore, if it weren't for
> reproducible-builds indicating the very same FTBFS as well.
> [...]
> All in all this hints at some issue still lingering around, but I cannot
> exactly pinpoint what it might be.
>
> I'd say let's wait until reproducible-builds attempts to build 0.15.3-1
> and see what the results are. Or feel free to downgrade this issue here
> as you deem fit, for on the official buildd and on your machine
> everything seems to be working juts fine.

I'll likely downgrade this bug, but this is fairly odd! If the tests
fail on some building machines, there is a chance that the actual
application also doesn't work everywhere. I can say though that this
works on the buildds, on my local machine and on GitLab. Is there
anything that's different in the reproducible build machines compared
to the buildds? Is there anything special about your local machine?

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1008687: FTBFS: as-test_pool FAIL killed by signal 6 SIGABRT

[Matthias Klumpp]

Hello!

Am Mi., 30. März 2022 um 20:21 Uhr schrieb Florian Ernst
:
>
> Source: appstream
> Version: 0.15.2-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
>
> Hello there,
>
> during a rebuild of the reverse b-d of libyaml I found that this package
> failed to build on my amd64.
>
> In addition, the build also failed on amd64, i386, arm64, and armhf,
> each both in unstable and in bookworm, cf.
> 
> where you will also find full logs.
>
> The relevant part from my build log (hopefully, full log attached):

I can't reproduce this issue at all, and a recent upload of AppStream
is building fine on all architectures...
Does this issue still exist? Maybe it was a fluke or fixed in some
other component meanwhile...

Cheers,
Matthias


-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1006949: src:ldc: fails to migrate to testing for too long: FTBFS on armhf and i386

[Matthias Klumpp]

Hi Paul!

Am Sa., 9. Apr. 2022 um 17:30 Uhr schrieb Paul Gevers :
>
> Hi,
>
> On Tue, 8 Mar 2022 21:00:25 +0100 Paul Gevers  wrote:
> > Your package fails to build from
> > source on armhf and i386 while it successfully built there before.
>
> > This bug will trigger auto-removal when appropriate. As with all new
> > bugs, there will be at least 30 days before the package is auto-removed.
>
> ldc is a key package so will not be autoremoved. Is there any progress
> on fixing this issue?

I am currently really tid up with other stuff, so I do not have much
time (or actually, any...) to work on Debian's D toolchain, so help is
absolutely wanted here!
However, I hope that this particular issue will just solve itself with
the next LDC release which I'd submit as soon as it is available - at
least this bug report makes me think that LDC 1.29.x will resolve the
issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000919
That new version should actually happen rather soon, so maybe it's
okay to just wait a bit.
Unfortunately I really can't do any deeper investigation into this right now :-/

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1006269: appstream: apt hook shows non-actionable warnings if Flathub metadata has issues

[Matthias Klumpp]

Hi!

Am Di., 22. Feb. 2022 um 11:33 Uhr schrieb Simon McVittie :
>
> Package: appstream
> Version: 0.15.1-1
> Severity: normal
>
> I cannot reproduce this right now (it seems to be intermittent?), but
> the steps that previously reproduced it were:
>
> * Have flatpak installed
> * Have Flathub configured as a remote in the system repository
>   /var/lib/flatpak: https://flatpak.org/setup/Debian
> * Have appstream installed
> * `sudo apt update`, or the equivalent in aptitude

You will be able to reproduce this all the time by running:
sudo appstreamcli refresh --force

> Expected result: no error messages unless there is something that the
> sysadmin needs to resolve.
>
> Actual result, as reported at https://github.com/flatpak/flatpak/issues/4642
> and https://github.com/flathub/cc.nift.nsm/issues/3:
>
> ** (appstreamcli:11481): WARNING **: 21:53:33.554: Found icon of unknown 
> type 'unknown' in 'system/flatpak/flatpak/cc.nift.nsm/*', skipping it.
> ** (appstreamcli:11481): WARNING **: 21:53:33.554: Found icon of unknown 
> type 'unknown' in 'system/flatpak/flatpak/cc.nift.nsm/*', skipping it.
>
> If this happens again I'll try to capture the Appstream XML that Flathub was
> sending at the time.

This is an odd one... While there is nothing the user can do here, we
do want to know if the server was sending bad data. This was
originally intended to alert when there's bad data in the Debian
repositories, but since Flatpak data is cached too now in the same
pass, we get this message as well now. I am not sure if that's a good
or a bad thing though ^^
Potentially we could only generate caches for the OS data on APT
updates, and not Flatpak as well.

> appstreamcli should perhaps have a --quiet option that tries to recover
> from this sort of thing without issuing warnings, which could be used
> in the apt hook?

It actually does run in quiet mode :-) However, if there's an issue
that results in metadata being dropped entirely for $reasons, it
currently complains quite loudly so the server side can be fixed.

There seems to be something wrong with Flatpak's or Flathub's
AppStream generator (even if the input is bad, the output of the
server shouldn't be bad too!) - I was meaning to report that, but so
far didn't have the time. Looks like others were faster now :-D

Cheers,
Matthias


-- 
I welcome VSRE emails. See http://vsre.info/

Bug#971241: debconf-kde-helper: Boolean inputs are always set to true/yes position, no matter what the actual state is

[Matthias Klumpp]

Hi Jaakko!

Thank you *very* much for the script to reproduce this, thanks to the 
script I was able to fix this in a few minutes after years of not 
touching debconf-kde (in preparation of a bugfix release).


This issue will be resolved with the next upload.

Cheers,
Matthias

Bug#1001460: debspawn: Remove downloaded .deb files from the tarball

[Matthias Klumpp]

Am Fr., 10. Dez. 2021 um 15:24 Uhr schrieb Alberto Garcia :
>
> Package: debspawn
> Version: 0.5.0-1
> Severity: normal
>
> Hi,
>
> Creating a new image with e.g. 'debspawn create sid' leaves a lot of
> .deb files in /var/cache/apt/archives/, making the resulting tarball
> bigger.
>
> Those files are not even accessible because /var/cache/apt/archives/
> inside the container is hidden by a bind mount.

Yes, this is an oversight! Should be fixed in the next release
(originally `apt clean` was called, but when that was dropped, the
"unwanted files" removal code wasn't adjusted to match...)
Thanks for noticing!

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#997960: Debspawn deletes anything mounted in a container

[Matthias Klumpp]

Hi Sam!

Am Mi., 27. Okt. 2021 um 21:24 Uhr schrieb Sam Hartman :
>
> Package: debspawn
> Version: 0.5.0-1
> Severity: serious
> Justification: Significant data loss
>
> I used debspawn interact to  interactively explore what I needed to do to get 
> a new upstream package building.
> To make that easier, I mounted my source trees and debian working environment 
> in the container.
>
> On exit, debspawn deleted everything.
> In retrospect, I can understand why this is, but it's pretty hostile to the 
> developer.
> I might be alone, but I find it very helpful to mount various things into 
> containers when exploring why things don't work.

Ha! First of all, I'm very sorry for this issue, and I hope this
didn't cause any bigger problems or a long recovery session.
Debspawn does not really expect users to mount things as well behind its back...
Bindmounts are evil sometimes, but ever since I deleted my whole root
filesystem by accident, I became a lot more careful :-D

> My recommendation would be to check for bind mounts and make sure they can be 
> unmounted before cleaning up.

That is actually a rather annoying operation, as you need to parse
`/proc/self/mountinfo` or call `findmnt` on every directory in order
to not only find "real" mountpoints but also bindmounts.
I tried the latter option though, and on my system I could only
measure a slowdown of a few milliseconds, so that's IMHO perfectly
fine as safety measure.

> A fix that would have worked in my case but that may not generally be good 
> enough would have been to restrict the container deletion to one-file-system.

That wouldn't find bindmounts though, and I'd rather catch these too :-)
The new 0.5.1 release will have the change included and will just
unmount any directory mountpoints upon container deletion - if the
user decided to create mountpoints on *files*, deletion of those will
likely just fail, which is fine with me (no data is lost and the user
knows what (not) to do next time).

Please give it a test with some scratch directory though before using
this with important data - just in case! ;-)

Cheers,
Matthias

Bug#998810: debspawn: does not honor InjectedPkgsDir

[Matthias Klumpp]

Hi Ritesh!

Am Mo., 8. Nov. 2021 um 08:33 Uhr schrieb Ritesh Raj Sarraf :
>
> As per the manual page, settings defined in /etc/debspawn/global.json
> should override the defaults.

I think you read the manual page wrong: It's
`/etc/debspawn/global.toml` (see
https://manpages.debian.org/unstable/debspawn/debspawn.1.en.html )

> [...]
> But the same is not honored by debspawn. It does not pick the local debs
> from the specified InjectedPkgsDir path. OTOH, if I go with the
> defaults, i.e. `/var/lib/debspawn/injected-pkgs/`, it works.
> [...]

Can you try creating the TOML file instead? That should fix your issue! ;-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#989907: debspawn filesystems are non-minimal/fat by default

[Matthias Klumpp]

Hi Helmut!

Am Di., 15. Juni 2021 um 19:09 Uhr schrieb Helmut Grohne :
> I looked into why the .tar.zst images for debspawn are so big. Indeed,
> they contain a lot of stuff that does not belong there. Examples
> include:
>
>  * dmidecode
>  * fdisk
>  * ifupdown
>  * init
>  * isc-dhcp-client
>  * kmod
>  * nftables
>  * rsyslog
>  * systemd
>  * tasksel
>  * vim-tiny
>
> When one passes --variant buildd to debspawn create, the size is much
> smaller. When doing so, one has to pass --variant buildd to every
> debspawn build and debspawn login invocation. That's quite annoying.
> Given that debspawn's primary use is building, how about defaulting the
> variant to buildd?

I actually wanted to make this change, however for some reason when I
create "buildd" variant images, despite having less pages, the images
turn out larger (233.4 MiB for a default bullseye image, and 259.6 MiB
for a build bullseye image).
This makes no sense to me at all, so I'll defer this change a bit
until I've figured out what is actually consuming this space.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#991471: ITP: systemd-zram-generator -- Auto generator for zram devices to systemd service.

[Matthias Klumpp]

Hi Heysion!

Are there any news or progress on this packaging effort? We would like
to use the zRAM-generator in the PureOS Debian derivative, and
therefore packaging it for Debian makes a lot of sense.
So, if you need any help with this, be it packaging, maintenance or
upload sponsorship, please let me know!

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#981078: transition: libxmlb (freeze exception)

[Matthias Klumpp]

Hi!

Am Fr., 20. Aug. 2021 um 00:21 Uhr schrieb Sebastian Ramacher
:
> [...]
>
> Please go ahead.

Done, and it looks like everything has rebuilt just fine :-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#991244: Support extra-package and extra-repository options

[Matthias Klumpp]

Hi!

Am So., 18. Juli 2021 um 16:57 Uhr schrieb Pirate Praveen
:
>
> Package: debspawn
> Version: 0.5.0-1
> Severity: wishlist
>
> Extra package option is very useful when you have a build dependency
> still in NEW but you don't want to wait for it to clear NEW before
> building other packages.
>
> extra-repository option is very useful to share a stable rootfs for
> building stable-backports suite.
>
> Both options are available in sbuild and I have to switch to sbuild for
> these two options.

The option to add external packages already exists, you just need to
throw your packages into `/var/lib/debspawn/injected-pkgs/` (or
`/var/lib/debspawn/injected-pkgs/` to limit them to one
image). The path can be configured globally (see
https://manpages.debian.org/unstable/debspawn/debspawn.1.en.html#CONFIGURATION
), but setting it on the command-line is not currently possible.

I don't know if I understand the extra-repository suggestion - when
creating an image, debspawn supports a `--extra-sourceslist-lines`
option to set custom sources.list lines, and you can also log into the
image with `debspawn login --persistent ` and make changes that
survive after you log out and are saved to the image.
Does that help?

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#988827: appstream: Please disable libappstream-compose library on architecture where librsvg is not building

[Matthias Klumpp]

Am Do., 20. Mai 2021 um 08:24 Uhr schrieb Laurent Bigonville :
> Hello,
>
> libappstream-compose library requires librsvg library, but librsvg is
> not building anymore as it has been rewritten to rust.
>
> https://buildd.debian.org/status/package.php?p=librsvg=unstable
>
> Not building libappstream-compose might be a good idea as appstream is
> either depending on a really version of librsvg (2018) or is not
> building at all (ie. kfreebsd).
>
> https://buildd.debian.org/status/package.php?p=appstream=sid

Sure :-) I am deferring this change to post-bullseye at the moment, to
avoid even more last minute changes.
But it's on the todo list for when bullseye is released. The only
annoying thing which I don't really like is that once rsvg builds and
works on the architectures that currently don't have it, people need
to walk through the dependency chain to re-enable all the bits that
were previously disabled.
But since appstream is a dependency of quite a lot of stuf that
doesn't necessarily need the compose library, not building it for
bootstrapping new architectures is probably a desired feature anyway.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#990213: pre-approval unblock: appstream/0.14.4-1

[Matthias Klumpp]

Control: tags -1 - moreinfo

Hi Graham!

Am Sa., 10. Juli 2021 um 13:21 Uhr schrieb Graham Inggs :
> [...]
> On Wed, 23 Jun 2021 at 03:12, Matthias Klumpp  wrote:
> > Let me know what you think!
>
> Assuming it can happen soon, please go ahead upload to unstable, and
> remove the moreinfo tag once it has built.

Uploaded, and the package has built on all architectures where it
built previously.
Thanks! :-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#990637: Why do marble have several .desktop files?

[Matthias Klumpp]

Am Di., 6. Juli 2021 um 23:02 Uhr schrieb Petter Reinholdtsen :
>
> [Sune Stolborg Vuorela]
> > I hope this is sufficient response to "is there a good reason", and I
> > think the script you use should be adapted to work with this pattern.
>
> Note, the  script I use operate on the appstream data set, so the fix
> need to be done in the input system for appstream, not in my script.  Or
> in marble. :)

Nah, AppStream is fine - it's just a misconception that AppStream
would work on all desktop files - it interacting with desktop-files is
mostly a convenience feature with limited applicability. The MetaInfo
files are the actual true source for metadata.
If a software ships addons, upstream needs to provide matching addon
AppStream component definitions (see
https://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html
) otherwise their data will not show up in the component index (and
the addons will not be installable or removable via a GUI software
center).

Cheers,
Matthias.

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#990213: pre-approval unblock: appstream/0.14.4-1

[Matthias Klumpp]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package appstream
This is currently a pre-approval request, as the changes - even though
almost all of them are bugfixes - are larger, in a key package, and
we're close to the final release.

[ Reason ]

AppStream has had two bugfix-only releases, and rather than
backporting a lot of interdependent patches, I would much rather like
to upload the 0.14.4 release as-a-whole. There are very few changes in
there that are not bugfixes, and I consider those low-risk.
As maintainer of the AppStream project upstream as well as in Debian,
I have a good overview of what went into the code.

Here's the individual changes made with explanations on why we want
them in Debian for the release. I have stripped out all translation
updates and documentation changes, as those will not change how the
program works.

* compose: Don't loop endlessly if external desktop l10n function is set
This change is only relevant for Ubuntu, without it the Ubuntu
AppStream metadata generator will loop endlessly. We still want this
in Debian in case someone processes an Ubuntu archive on a Debian
host, as it's a rather annoying issue to run into when processing
metadata.

* Never create a predictable dir in /tmp for caching
AppStream in current bullseye may create /tmp/appstream, which
wouldn't be an issue unless the program using it is run as root.
Unfortunately we run `appstreamcli` as roo all the time as part of an
apt update, so this may be a security issue with a predictable folder
being created in /tmp with elevated privileges.

* component: Don't strip ";" from keywords before translating them
Again, only relevant for Ubuntu which translates desktop-entry files
differently than Debian (but also won't affect Debian, only people who
process Ubuntu archives on a Debian host)

* utils: Don't strip modifiers when stripping encoding
Previously we generated invalid YAML by creating multiple entries with
the same value for YAML dicts, when stripping "ca.UTF-8" and
"c...@valencia.utf-8" both to "ca". This fixes both the issue of
modifiers being ignored by AppStream and the YAML corruption.

* compose: Check optipng is there before we use it
Fix for a rare configuration issue.

* Improve text line wrapping, especially if many newlines are present
We previously wrapped text output from `appstreamcli` on the terminal
incorrectly of lists where contained within it, leading to
weird-looking output. This is a cosmetic fix for human-readable CLI
output (obviously doesn#t affect the tool's structured data output
modes).

* Make word-wrap function unicode-aware
Same, wraps e.g. Japanese text correctly now on the console.

* Make license_is_metadata_license parse more complex expressions
This is a fix for an issue Debian developers reported upstream but
which was actually a fault in appstream-compose. See
https://gitlab.gnome.org/GNOME/evince/-/merge_requests/346 for an
example.

* Improve cache refresh code, don't flag cache as updated if update failed
Kills a race condition, and also prevents AppStream from marking a
cache as valid even though it wasn't. This appears mostly in cases
where 3rd-party repositories are added which have broken data or data
(Debian's archive never triggers this, unless something went wrong).

* Use system cache even if we had to drop some invalid metadata
This ties in with the fix from above and affects cases where 3rd-party
repositories are used. Without this patch, software centers may load
all data twice each run, leading to extreme startup times on slower
devices.

* Assign more string class members safely
This is some API hardening that prevents crashes if an API user does
something like `as_set_string_member (object, as_get_string_member
(object))` where we'd get a segmentation fault. Generally good to
have, even though I am not aware of any client triggering this.

* Fix flashed firmware generating incorrect XML
* Fix YAML having wrong names for the firmware data
"flashed" and "runtime" firmware had wrong metadata in both XML and
YAML, which resulted in them being ignored by some tools. This change
fixes this and makes firmware work as specified.

By uploading the 0.14.4 release, we'll also drag in a few features,
here's an explanation for these:
* qt: Expose setter and getter for pool cache location
Just exposes some more API for Qt users and is otherwise inert.

* utils: Use GLib's gstring_replace if available
Just some cleanup in AppStream's utility code, which was required for
the "ca@valencia" fix series.

 * its: Allow to mark release descriptions as non-translatable
Allows upstream projects to mark release descriptions as
non-translatable, but does nothing if not used explicitly (it's a
one-line config change).

* compose: Point people at the specification if metadata license is invalid
This is an explanation string change, that does not have any functional impact.

You can find the 

Bug#989884: isenkram-cli: isenkram-autoinstall-firmware doesn't find any firmware packages

[Matthias Klumpp]

Am Di., 15. Juni 2021 um 11:19 Uhr schrieb Petter Reinholdtsen
:
> [...]
> I ran this test on a few of my machines, and it provide several matches:
>
>   for f in $(find /lib/firmware/ -type f |sed s%/lib/firmware/%%); do
> appstreamcli what-provides firmware:runtime $f
>   done

Without having looked too deeply into this, maybe you are running into
https://github.com/ximion/appstream/pull/328 ?
Could be fixed in time for bullseye if I manage to get a freeze
exception for a whole batch of AppStream bugfixes (otherwise maybe
cherry-picking changes like this is an option too).

You could verify whether this is indeed the issue by trying to
reproduce it with AppStream 0.14.4

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#987547: Touch RC bugs to (maybe) prevent package autoremoval

[Matthias Klumpp]

Hi!
This mail just touches the debspawn RC bugs to maybe prevent an early
autoremoval, if that's still a thing during soft-freeze.
I need some extra time to sort out the package's migration, as it will
not automatically migrate due to Debian's CI not having the machines
to run the autopkgtest of this package.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#989481: unblock: debspawn/0.5.0-1

[Matthias Klumpp]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package debspawn

[ Reason ]
Debspawn is a nspawn-based package builder for Debian with a popcon
value of 52, therefore it would normally migrate in this phase of the
freeze via its autopkgtest.
Unfortunately, that autopkgtest can't currently run on Debian's CI
because Debian has no CI runners which provide machine-level
isolation, a feature that debspawn needs as it will itself spawn
containers and therefore can't run in one (an issue that the CI team
is aware of, but that I didn't know until recently).
The new release in unstable, while being a feature release, fixes two
RC bugs, one being a potential security issue (#989049 - debspawn:
privilege escalation via uid reuse) and one dependency issue (#987547
- missing dependency on dpkg-dev).
In addition to that, the changes also resolve a lot of papercuts and
minor feature requests. They also ready debspawn for using the cgroups
v2 layout, which Debian's systemd uses by default now (and which broke
a few features of debspawn in testing).

[ Impact ]
If the unblock isn't granted, the package would be removed from
testing in 4 days due to its security-issue RC bug, even though it had
a test and technically fit the requirements for migration.
This would lead to sad users and a sad maintainer. Debspawn has no
reverse dependencies though, so no other package would be directly
impacted.

[ Tests ]
The autopkgtest of Debspawn works well locally and apparently does run
well on Ubuntu's CI systems as well.
Furthermore, we are using Debspawn excessively at Purism to build the
PureOS Debian derivative, so the current version has received quite a
bit of real-world testing in building a lot of Debian packages on our
autobuild machines.

[ Risks ]
The package is a leaf package, so any issue will only affect Debspawn.
While new features have been added, they received excessive testing or
were included to resolve other issues (like the new logic to not reuse
UIDs from the host to fix a security issue), therefore the overall
risk for including these changes is low.

[ Other info ]
Upstream NEWS file with all the changes done compared to the version in testing:

Version 0.5.0
~~
Features:
 * maintain: Add new flag to print status information
 * maintain: status: Include debootstrap version in reports
 * docs: Document the `maintain` subcommand
 * Install systemd timer to clear all caches monthly
 * Unconditionally save buildlog

Bugfixes:
 * Rework how external system files are installed
 * Include extra data in manifest as well
 * Fix image creation if resolv.conf is a symlink

Version 0.4.2
~~
Features:
 * Add "maintain" subcommand to migrate or reset settings & state
 * Configure APT to not install recommends by default (deb: #987312)
 * Retry apt updates a few times to protect against bad mirrors
 * Add tmpfiles.d snippet to manage debspawn's temporary directory
 * Allow defining custom environment variables for package builds (deb: #986967)
 * Add maintenance action to update all images

Bugfixes:
 * Interpret EOF as "No" in interactive override question
 * Implement privileged device access properly
 * Move images to the right default location
 * Don't try to bindmound KVM if it doesn't exist
 * Use dpkg --print-architecture to determine arch (deb: #987547)
 * run: Mount builddir in initialization step
 * Don't register any of our nspawn containers by default
 * Check system encoding properly (deb: #982793)
 * Atomically and safely copy files into unsafe environments
 * Run builds as user with a random free UID (deb: #989049)

unblock debspawn/0.5.0-1

Bug#989049: debspawn: privilege escalation via uid reuse

[Matthias Klumpp]

Am Di., 25. Mai 2021 um 13:21 Uhr schrieb Salvatore Bonaccorso
:
> [...]
> >
> > Can you please elaborate on why you reopened this issue? I believe it
> > has indeed been addressed with version 0.4.2-1, there is no more uid
> > reuse for the build user and Debspawn will pick a free uid that is not
> > in use on the host system for building packages.
>
> The reason ist very simple, because I messed up the 'found' version :)

Ah, that makes sense - at least it got be to take another look at the
patch that fixed this to look for issues, which is never a bad thing
:-)
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#989049: debspawn: privilege escalation via uid reuse

[Matthias Klumpp]

Hi Salvatore!

Am Di., 25. Mai 2021 um 06:51 Uhr schrieb Debian Bug Tracking System
:
>
> Processing commands for cont...@bugs.debian.org:
>
> > found 989049 0.4.2-1
> Bug #989049 {Done: Matthias Klumpp } [debspawn] debspawn: 
> privilege escalation via uid reuse
> There is no source info for the package 'debspawn' at version '0.4.2-1' with 
> architecture ''
> Unable to make a source version for version '0.4.2-1'
> Marked as found in versions 0.4.2-1; no longer marked as fixed in versions 
> debspawn/0.4.2-1 and reopened.
> > thanks
> Stopping processing here.

Can you please elaborate on why you reopened this issue? I believe it
has indeed been addressed with version 0.4.2-1, there is no more uid
reuse for the build user and Debspawn will pick a free uid that is not
in use on the host system for building packages.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#987312: please allow ignoring recommends/suggests

[Matthias Klumpp]

Am Mi., 21. Apr. 2021 um 15:51 Uhr schrieb Marc Haber
:
>
> Package: debspawn
> Version: 0.4.1-1
> Severity: wishlist
>
> Hi,
>
> I would like to have a possibility to not install recommends/suggests in
> the container, to keep the containers small.

Does passing `--variant=minbase` to `debspawn create` work for you?
Suggests should never be auto installed, and if Recommends are
installed at package build time, that would actually be a bug - those
should not be present in the build environment...

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#980686: ldc: FTBFS: dh_auto_configure: error: cd bootstrap-stage2

[Matthias Klumpp]

Hi Ivo!

Am Di., 23. Feb. 2021 um 00:03 Uhr schrieb Ivo De Decker :
>
> Hi Matthias,
>
> On Wed, Jan 20, 2021 at 09:48:32PM +0100, Lucas Nussbaum wrote:
> > Source: ldc
> > Version: 1:1.24.0-1
> > Severity: serious
> > Justification: FTBFS on amd64
> > Tags: bullseye sid ftbfs
> > Usertags: ftbfs-20210120 ftbfs-bullseye
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
>
> Are you aware of this bug? Looking at
> https://tests.reproducible-builds.org/debian/history/ldc.html
> it seems the change that triggered it must have been uploaded fairly recently
> (probaby in January).

No I didn't, thanks for the ping!
The problem is dpkg adding DFLAGS="-frelease" to the environment,
which messes up ldmd2. I'll have a look at fixing that.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#981229: dub: autopkgtest regression

[Matthias Klumpp]

Am Do., 28. Jan. 2021 um 00:33 Uhr schrieb Sebastian Ramacher
:
>
> Source: dub
> Version: 1.24.0-1
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
>
> | autopkgtest [03:11:10]: test run: [---
> | Package dub not found for registry at https://code.dlang.org/ (fallbacks 
> registry at https://codemirror.dlang.org/, registry at 
> https://dub.bytecraft.nl/, registry at https://code-mirror.dlang.io/): Failed 
> to download 
> https://code.dlang.org/api/packages/infos?packages=%5B%22dub%22%5D_dependencies=true=true
> | Getting a release version failed: No package dub was found matching the 
> dependency >=0.0.0
> | Retry with ~master...
> | Package dub not found for registry at https://code.dlang.org/ (fallbacks 
> registry at https://codemirror.dlang.org/, registry at 
> https://dub.bytecraft.nl/, registry at https://code-mirror.dlang.io/): Failed 
> to download 
> https://code.dlang.org/api/packages/infos?packages=%5B%22dub%22%5D_dependencies=true=true
> | No package dub was found matching the dependency ~master
> | autopkgtest [03:11:10]: test run: ---]
> | autopkgtest [03:11:11]: test run:  - - - - - - - - - - results - - - - - - 
> - - - -
> | run  FAIL non-zero exit status 2
>
> See
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dub/10040021/log.gz

Weird, I just tested this locally and it worked fine... Hopefully it's
not another GDC issue...

Regards,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#906072: ITP: ogon -- ogon session manager and RDP server

[Matthias Klumpp]

Hi Mike and everyone else involved with this packaging project!

First of all, thank you for working on this, ogon looks like a rather
complicated thing to package.
I would like to ask what the status of this project currently is. Do
you think that there is any chance this could still make it into
bullseye? Is there anything you would need help with?

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#981078: transition: libxmlb (freeze exception)

[Matthias Klumpp]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: mario.limoncie...@dell.com
Severity: normal

Hi!
As we are already in transition freeze for bullseye, I would like to
request permission to do a transition of libxmlb1 --> libxmlb2 which
unfortunately missed the deadline by accident.
The only packages impacted by this transition are fwupd and
gnome-software, which are handled by the same people who also handle
libxmlb.

The updated version includes multiple performance and robustness fixes
as well as reduced memory requirements, which will be very beneficial
for users of gnome-software and fwupd and are inherently tied to the
API break.
Updating libxmlb now would greatly simplify future backports and also
would be great for supporting fwupd updates in the stable Debian
release for robust firmware updates (so ideally we could just update
fwupd and wouldn't be hindered by an old version of libxmlb that
gnome-software also depends on).

GNOME Software and fwupd should already support the new API and just
need a rebuild.

Summary of the libxmlb changes:

Important:
- This release breaks API and ABI and bumps the version of libxmlb.so and so
packages that depend on this library (e.g. fwupd or gnome-software) will need
to be rebuilt at the same time.

New Features:
- Add the missing TEXT:INTE XPath support (Richard Hughes)
- Add variant of xb_silo_query_with_root() avoiding XbNode creation
(Philip Withnall)
- Add XB_BUILDER_SOURCE_FLAG_WATCH_DIRECTORY flag (Philip Withnall)
- Allow specifying the node cache behaviour for the query (Richard Hughes)

Bugfixes:
- Avoid recursion when setting flags if possible (Philip Withnall)
- Avoid using weak pointers when building the silo (Philip Withnall)
- Change the default value for the node cache (Richard Hughes)
- Do not allocate opcodes individually (Philip Withnall)
- Do not show a critical warning for invalid XML (Richard Hughes)
- Do not unconditionally create GTimer objects (Philip Withnall)
- Do not use the node cache when building indexes (Richard Hughes)
- Lazy load more arrays to reduce RSS usage (Philip Withnall)
- Report silo versions when versions mismatch (Robert Ancell)
- Do not assume g_content_type_guess() always returns valid results
(Richard Hughes)
- Make the build reproducible (Richard Hughes)
- Revert "Do not show a critical warning for invalid XML" (Richard Hughes)
- Update the header location to reflect the new API (Richard Hughes)

Thank you for considering!
Cheers,
Matthias

Ben file:

title = "libxmlb";
is_affected = .depends ~ "libxmlb1" | .depends ~ "libxmlb2";
is_good = .depends ~ "libxmlb2";
is_bad = .depends ~ "libxmlb1";

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#978703: gives strange error messages on outdated images

[Matthias Klumpp]

Am Mi., 30. Dez. 2020 um 14:57 Uhr schrieb Marc Haber
:
>
> Package: debspawn
> Version: 0.4.1-1
> Severity: minor
>
> Hi,
>
> I recently tried to use debspawn build building into a slightly outdated
> image of Debian sid and received a message that dsrun didn't like the
> "--suite sid" option that was given to it. Updating the image solved the
> issue for me.
>
> I suspect that the "outside" debspawn calls things that are inside the
> image, and while the outside debspawn was a 0.4.1, the inside was still
> at 0.4.0 or even older and the interface between the outside and inside
> code changed with the 0.4.0 to 0.4.1 transition. If my suspicion is
> true, than this might also apply to images of testing or stable, but
> without the possibility of just fixing this by updating the image.
>
> I understand that this issue is probably hard to fix, but if it doesn't
> seem possible to just inject the code needed on the inside from the
> outside at run time (therefore forcing them to be in sync, but possibly
> introducing python version issues) then there should be at least a more
> helpful error message than just bombing out with a usage message of an
> internal tool.

Hi!
I'll probably address this properly in future by making this
automatic, but this kind of issue can be fixed relatively easily by
running `debspawn update ` - that will make sure older images
run with newer debspawn versions.
In the long run, this step should either happen in postinst for the
deb package, or, even better, debspawn could auto-update older images
on the first time they are used.
For now though, the debspawn update command has to be run manually (or
via cron scripts - on my system I have a few systemd timer units which
update debspawn container automatically, which is probably why I
hadn't noticed this issue immediately).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#978636: move to merged-usr-only?

[Matthias Klumpp]

Am Di., 29. Dez. 2020 um 17:39 Uhr schrieb Marco d'Itri :
>
> On Dec 29, Ansgar  wrote:
>
> > as suggested in [1], I would like to see Debian to move to support
> > only the merged-usr filesystem layout.  This would simplfy things for
> > the future and also address the problem with installing files under
> > aliased trees that dpkg has to do for both variants to be supported.
> As the architect of the Debian merged-usr transition, I agree: removing
> support for unmerged systems would simplify many things.
> Thank you Ansgar for bringing this to the CTTE.

Indeed!

> > I'm not asking the committee to decide on a concrete technical
> > implementation for this.  Obviously we would need to also implement a
> > migration path for legacy installations for a move to merged-usr-only
> > to be implemented.  This also isn't relevant for Debian 11 (bullseye),
> > but I would like to have enough time in the Debian 12 (bookworm)
> > cycle.
> Agreed.
> FWIW: we have had for a long time a reliable migration method, the
> usrmerge package.
> Except that on a live system it requires a reboot mid-conversion (due to
> bind mounts created by systemd): since this is inconvenient and mildly
> scary I did not propose wider adoption for buster.
> The best workaround would probably be to run it from the initramfs, but
> I have not been able to actually make this[1] work: I expect that
> somebody who knows initramfs-tools better than I do can fix it quickly.

For package upgrades, we can already perform so-called "offline
upgrades", where the system reboots into a smaller systemd target,
applies all updates and then reboots again into the updated system.
This is implemented in PackageKit as an option and used by GNOME.
Fwupd uses similar concepts for certain firmware updates as well.
Maybe hooking into these facilities is also an option for the usrmerge
upgrade? (unless of course systemd is still interfering even in a
minimal target, that would be a dealbreaker).
More info about offline-upgrades can be found at [1], could be
interesting to look into.

This discussion is probably OT through for the issue at hand (*if* we
make that switch, not the *how* we make it in particular).

Cheers,
Matthias

[1]: 
https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#974107: Segfault when running isenkram-lookup

[Matthias Klumpp]

Am Fr., 13. Nov. 2020 um 01:28 Uhr schrieb Gunnar Hjalmarsson
:
>
> On 2020-11-12 23:20, Matthias Klumpp wrote:
> > You want this patch for AppStream:
> > https://github.com/ximion/appstream/commit/b52858bff55d358f925b8e64bab77b953067f248
>
> But only comments are changed there!?
>
> Still... I built AppStream with that commit applied:
>
> https://launchpad.net/~gunnarhj/+archive/ubuntu/appstream
>
> and that miraculously fixes it. Thanks!
>
> (I'm getting old.)
>
> > In any case, it'll be fixed in Debian soon-ish with the new AppStream
> > release, but Ubuntu will need a backported fix.
>
> Right, we'll need to backport to Ubuntu 20.10. For some reason isenkram
> is not present in the archive for Ubuntu 20.04. Is there any other
> reason for such an appstream backport to 20.04?
>
> On 2020-11-12 23:54, Petter Reinholdtsen wrote:
> > Should this BTS report be reassigned somewhere, given that the
> > code issue is not in isenkram?
>
> Yeah, looks like it should be reassigned to the appstream package.

Looks like I was speaking too soon and this isn't actually an issue in
AppStream - my fix resolves the issue with Python, but breaks the Vala
bindings instead: https://github.com/ximion/appstream/issues/289
So, this has to be fixed in some other tool...
Also, please don't backport that patch.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#974107: Segfault when running isenkram-lookup

[Matthias Klumpp]

Am Do., 12. Nov. 2020 um 23:20 Uhr schrieb Matthias Klumpp :
> [...]
> You want this patch for AppStream:
> https://github.com/ximion/appstream/commit/b52858bff55d358f925b8e64bab77b953067f248
> Basically, Python thought it could free more objects than it should
> actually have freed - not sure why this has worked before, this
> behavior was apparently broken for quite a while. Maybe it just worked
> by accident, or another bug was fixed in Python which triggered this
> issue.
>
> In any case, it'll be fixed in Debian soon-ish with the new AppStream
> release, but Ubuntu will need a backported fix.
> [...]

Oh, btw: Thank you all for the last messages, knowing which commands
to run to reproduce this easily helped quite a bit with finding the
culprit quite quickly (and I also looked in the code for other
instances of this, but found only the ones in AsPool).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#974107: Segfault when running isenkram-lookup

[Matthias Klumpp]

Am Do., 12. Nov. 2020 um 22:21 Uhr schrieb Gunnar Hjalmarsson
:
>
> On 2020-11-12 21:28, Petter Reinholdtsen wrote:
> > [Gunnar Hjalmarsson]
> >> Additional observations:
> >>
> >> * The testing failure in Ubuntu started around October 31.
> >>
> >> * The test-command-line script fails on amd64 and i386 but succeeds on
> >> other architectures.
> >
> > Is it possible to 'diff' the logs from a successful and a failing test,
> > to see what changed?  Perhaps a new version of some package or
> > something?
> >
> > I get the following when running in my Sid chroot:
> >
> >isenkram-lookup
> >
> >(process:10498): GLib-GObject-CRITICAL (recursed) **:
> >g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failedAborted
> >
> > No idea what it mean. :)
>
> Unfortunately I don't have the knowledge to help with the analysis. But
> yes, since isenkram hasn't changed recently, the explanation ought to be
> changes in some other package(s).
>
> Anyway, I attached two logs from test runs in Ubuntu's autopkgtest which
> passed. One is on amd64 from October 29 and one is on arm64 from
> yesterday. They both show a bunch of warning messages, but lack the
> "KeyError" from a recent amd64 test run (attached in my last message).

You want this patch for AppStream:
https://github.com/ximion/appstream/commit/b52858bff55d358f925b8e64bab77b953067f248
Basically, Python thought it could free more objects than it should
actually have freed - not sure why this has worked before, this
behavior was apparently broken for quite a while. Maybe it just worked
by accident, or another bug was fixed in Python which triggered this
issue.

In any case, it'll be fixed in Debian soon-ish with the new AppStream
release, but Ubuntu will need a backported fix.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#974107: Segfault when running isenkram-lookup

[Matthias Klumpp]

Am Di., 10. Nov. 2020 um 01:08 Uhr schrieb Petter Reinholdtsen
:
>
> [Gunnar Hjalmarsson]
> > On an updated Debian testing:
> >
> > $ isenkram-lookup
> > /usr/lib/python3/dist-packages/isenkram/lookup.py:85: Warning invalid
> > uninstantiatable type '(null)' in cast to 'AsProvided'
> >provided = cpt.get_provided_for_kind(AppStream.ProvidedKind.MODALIAS)
> > Segmentation fault
> >
> > I'm not really an isenkram user, but stumbled upon this issue in
> > connection with Ubuntu's testing of package uploads. The isenkram-lookup
> > command is included in the debian/tests/test-command-line script, which
> > causes various tests to fail.
>
> Thank you for the heads up.  I'm involving the appstream maintainer,
> perhaps he got an idea how to fix this.  Look like that part has changed
> since the code was written.

Can you give me some context for this code? If this is a warning
coming from libappstream, it means that it somehow got fed a null
pointer instead of a valid AsProvided object into its list, which
shouldn't happen - is your code doing that? Are you feeding it some
special metadata? What is the component name where this is failing?

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#966914: sambamba: FTBFS: collect2: error: ld returned 1 exit status

[Matthias Klumpp]

Am Di., 4. Aug. 2020 um 11:23 Uhr schrieb Andreas Tille :
>
> Control: tags -1 help
>
> Hi,
>
> On Mon, Aug 03, 2020 at 10:06:32AM +0200, Lucas Nussbaum wrote:
> > > lto1: fatal error: bytecode stream in file 
> > > ‘/usr/lib/x86_64-linux-gnu/libhts.a’ generated with GCC compiler older 
> > > than 10.0
>
> I've uploaded a new htslib that is now build with GCC 10 and used a
> versioned Build-Depends inside sambamba.  Now the build issue changed
> to:
>
> [38/41] ldc2 -enable-color -O -g -release -wi -I/usr/include/x86_64-linux-gnu 
> -I/usr/include/d/bio -O3 -release -enable-inlining -boundscheck=off -J../ 
> -I=.. -I=. -I=sambamba.p -I=sambamba.p 
> -of=sambamba.p/_build_sambamba-0.7.1_obj-x86_64-linux-gnu_utils_ldc_version_info_.d.o
>  -c /build/sambamba-0.7.1/obj-x86_64-linux-gnu/utils/ldc_version_info_.d
> [39/41] ldc2 -enable-color -O -g -release -wi -I/usr/include/x86_64-linux-gnu 
> -I/usr/include/d/bio -O3 -release -enable-inlining -boundscheck=off -J../ 
> -I=.. -I=. -I=sambamba.p -I=sambamba.p 
> -of=sambamba.p/thirdparty_unstablesort.d.o -c ../thirdparty/unstablesort.d
> [40/41] ldc2 -enable-color -O -g -release -wi -I/usr/include/x86_64-linux-gnu 
> -I/usr/include/d/bio -O3 -release -enable-inlining -boundscheck=off -J../ 
> -I=.. -I=. -I=sambamba.p -I=sambamba.p -of=sambamba.p/sambamba_view.d.o -c 
> ../sambamba/view.d
> [41/41] ldc2  -of=sambamba sambamba.p/sambamba_main.d.o 
> sambamba.p/sambamba_depth.d.o sambamba.p/sambamba_fixbins.d.o 
> sambamba.p/sambamba_flagstat.d.o sambamba.p/sambamba_index.d.o 
> sambamba.p/sambamba_markdup2.d.o sambamba.p/sambamba_markdup.d.o 
> sambamba.p/sambamba_merge.d.o sambamba.p/sambamba_pileup.d.o 
> sambamba.p/sambamba_slice.d.o sambamba.p/sambamba_sort.d.o 
> sambamba.p/sambamba_subsample.d.o sambamba.p/sambamba_utils_common_bed.d.o 
> sambamba.p/sambamba_utils_common_file.d.o 
> sambamba.p/sambamba_utils_common_filtering.d.o 
> sambamba.p/sambamba_utils_common_intervaltree.d.o 
> sambamba.p/sambamba_utils_common_ldc_gc_workaround.d.o 
> sambamba.p/sambamba_utils_common_overwrite.d.o 
> sambamba.p/sambamba_utils_common_pratt_parser.d.o 
> sambamba.p/sambamba_utils_common_progressbar.d.o 
> sambamba.p/sambamba_utils_common_queryparser.d.o 
> sambamba.p/sambamba_utils_common_readstorage.d.o 
> sambamba.p/sambamba_utils_common_tmpdir.d.o 
> sambamba.p/sambamba_utils_view_alignmentrangeprocessor.d.o 
> sambamba.p/sambamba_utils_view_headerserializer.d.o 
> sambamba.p/sambamba_validate.d.o sambamba.p/sambamba_view.d.o 
> sambamba.p/utils_lz4.d.o sambamba.p/utils_strip_bcf_header.d.o 
> sambamba.p/utils_version_.d.o sambamba.p/cram_exception.d.o 
> sambamba.p/cram_htslib.d.o sambamba.p/cram_reader.d.o 
> sambamba.p/cram_reference.d.o sambamba.p/cram_slicereader.d.o 
> sambamba.p/cram_wrappers.d.o sambamba.p/cram_writer.d.o 
> sambamba.p/thirdparty_mergesort.d.o sambamba.p/thirdparty_unstablesort.d.o 
> sambamba.p/_build_sambamba-0.7.1_obj-x86_64-linux-gnu_utils_ldc_version_info_.d.o
>  -L=--allow-shlib-undefined -link-defaultlib-shared -O -g -release -wi -L=-z 
> -L=relro -L=/usr/lib/x86_64-linux-gnu/libbiod.a 
> -L=/usr/lib/x86_64-linux-gnu/libz.a -L=/usr/lib/x86_64-linux-gnu/libhts.a 
> -L=-z -L=relro -L=-z -L=now -L=-flto -fvisibility=hidden 
> -L=/usr/lib/x86_64-linux-gnu/libbz2.a 
> -L=/usr/lib/x86_64-linux-gnu/libdeflate.a -L=-lm -L=-lpthread 
> -L=/usr/lib/x86_64-linux-gnu/liblzma.a 
> /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/liblz4.so 
> /usr/lib/x86_64-linux-gnu/libcurl.so /usr/lib/x86_64-linux-gnu/libcrypto.so 
> /usr/lib/x86_64-linux-gnu/liblzma.so -L=-rpath 
> -L=/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu
>  -L=-rpath-link -L=/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu 
> -L=-rpath-link -L=/usr/lib/x86_64-linux-gnu
> FAILED: sambamba
> ldc2  -of=sambamba sambamba.p/sambamba_main.d.o sambamba.p/sambamba_depth.d.o 
> sambamba.p/sambamba_fixbins.d.o sambamba.p/sambamba_flagstat.d.o 
> sambamba.p/sambamba_index.d.o sambamba.p/sambamba_markdup2.d.o 
> sambamba.p/sambamba_markdup.d.o sambamba.p/sambamba_merge.d.o 
> sambamba.p/sambamba_pileup.d.o sambamba.p/sambamba_slice.d.o 
> sambamba.p/sambamba_sort.d.o sambamba.p/sambamba_subsample.d.o 
> sambamba.p/sambamba_utils_common_bed.d.o 
> sambamba.p/sambamba_utils_common_file.d.o 
> sambamba.p/sambamba_utils_common_filtering.d.o 
> sambamba.p/sambamba_utils_common_intervaltree.d.o 
> sambamba.p/sambamba_utils_common_ldc_gc_workaround.d.o 
> sambamba.p/sambamba_utils_common_overwrite.d.o 
> sambamba.p/sambamba_utils_common_pratt_parser.d.o 
> sambamba.p/sambamba_utils_common_progressbar.d.o 
> sambamba.p/sambamba_utils_common_queryparser.d.o 
> sambamba.p/sambamba_utils_common_readstorage.d.o 
> sambamba.p/sambamba_utils_common_tmpdir.d.o 
> sambamba.p/sambamba_utils_view_alignmentrangeprocessor.d.o 
> sambamba.p/sambamba_utils_view_headerserializer.d.o 
> sambamba.p/sambamba_validate.d.o sambamba.p/sambamba_view.d.o 
> 

Bug#966249: appstream-generator FTBFS with gdc: error: undefined identifier ‘JSONType’

[Matthias Klumpp]

severity 966249 whishlist
thankyou

Am Sa., 25. Juli 2020 um 15:30 Uhr schrieb Adrian Bunk :
>
> Source: appstream-generator
> Version: 0.8.2-2
> Severity: important
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=appstream-generator
>
> ...
> ../src/asgen/config.d:443:61: error: undefined identifier ‘JSONType’
>   443 | suite.isImmutable = sn["immutable"].type == 
> JSONType.true_;
>   | ^
> ...

That's actually an issue with GDC, it only supports a really old
standard library version currently (will be resolved with GDC 11,
apparently), and supporting multiple standard library versions is a
massive pain. I lowered the issue priority to wishlist, since GDC has
never built this package successfully on the platforms where it is
default so far - maybe GCC 11 will resolve this for good :-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#961490: fwupd: version in stable too old, no updates possible

[Matthias Klumpp]

Am Di., 26. Mai 2020 um 20:24 Uhr schrieb :
>
> > -Original Message-
> > From: Ansgar 
> > Sent: Tuesday, May 26, 2020 8:01 AM
> > To: Steffen Schreiber; 961...@bugs.debian.org
> > Subject: Bug#961490: fwupd: version in stable too old, no updates possible
> >
> >
> > [EXTERNAL EMAIL]
> >
> > Hi,
> >
> > On Tue, 2020-05-26 at 13:56 +0200, Steffen Schreiber wrote:
> > > So I see you marked this bug as fixed/resolved.
> >
> > Someone (not the maintainer) did so, but please note that the bug
> > remains open even when marked as fixed in a newer version.  Debian's
> > stable release team prefers bugs to be fixed in unstable/testing before
> > they get fixed in (old)stable, so this is good.
>
> The particular circumstances of this issue are that the update in question 
> requires
> a newer version of fwupd than is in stable.  This is not a matter of just 
> backporting
> a change or two and it works.  There are daemon and plugin level changes that 
> have to
> go together to guarantee a proper update.
>
> This seems incompatible with the documentation around uploading to stable.
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> >
> > > What's the way going forward for users of stable? Installing packages
> > > from testing? Are you recommending to just forget about running Debian
> > > stable as is?
> >
> > The maintainer hasn't yet commented on how he wants to proceed.
> > Reasonable options seem to be to either update stable to the version
> > currently in testing (1.3.9) or to update to a later version of 1.2.X.
> >
> > Ansgar
>
> If a particular update requires a newer fwupd version I don't think it's 
> reasonable
> to push that version to all Debian users who may not need the newer fwupd 
> version
> and might not be willing to accept the risk of regressions in a newer version.
>
> "Fixes must be minimal and relevant"
>
> So in this circumstance if your device needs the newer version you should 
> probably
> take the package from testing instead.

Maybe talk to the release-team - they will probably not like adding a
change this big, but exceptions are always possible (e.g. firefox-esr
is exempt from this rule).
In any case though, you could provide a backport of the latest version
for easy installation by stable users as the next-best option :-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#959893: appstream-generator: Link against libglibd-2.0.so broken

[Matthias Klumpp]

Am Mi., 6. Mai 2020 um 19:57 Uhr schrieb Markus Frosch :
>
> Package: appstream-generator
> Version: 0.8.1-1+b1
> Severity: grave
> Justification: renders package unusable
>
> Hi maintainer,
> the package possible needs rebuilding.
>
> > appstream-generator: error while loading shared libraries: libglibd-2.0.so:
> > cannot open shared object file: No such file or directory
>
> libglibd-2.0 now has an explicit .0 suffix version:
>
> > $ apt-file search libglibd-2.0.so
> > libglibd-2.0-0: /usr/lib/x86_64-linux-gnu/libglibd-2.0.so.0
> > libglibd-2.0-0: /usr/lib/x86_64-linux-gnu/libglibd-2.0.so.2.1.0
> > libglibd-2.0-dev: /usr/lib/x86_64-linux-gnu/libglibd-2.0.so
>
> Adding a symlink helps, but not sure why this happened.
>
> > ln -s libglibd-2.0.so.0 /usr/lib/x86_64-linux-gnu/libglibd-2.0.so

Very odd, I wonder whet broke this as it's not an issue in
appstream-generator... I suspect either Meson failed here, or even the
LDC compiler.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#932747: apt-get: AppStream system cache updated, failing on APT::Update::Post-Invoke-Success

[Matthias Klumpp]

Am Do., 2. Apr. 2020 um 23:35 Uhr schrieb shirish शिरीष :
>
> at bottom :-
>
> On 02/04/2020, Matthias Klumpp  wrote:
>
> 
> >
> > In the case of newer Debian releases, the issue is actually a regression
> > in GNOME Software, which is fixed now, once again.
> >
> > Cheers,
> >  Matthias
> >
> Dear Matthias,
> I do have gnome-software 3.36.0-1 as well as gnome-software-common
> both the same version. Using $ sudo appstreamcli refresh --force
> --verbose I am getting things such as -
>
> ** (appstreamcli:2002138): DEBUG: 02:51:00.351: Metadata ignored:
> Detected colliding IDs: system/os/package/fontmatrix.desktop was
> already added with the same priority.
>
> These I guess I can understand but -
>
> ** (appstreamcli:2002138): DEBUG: 02:51:00.463: WARNING: Ignored
> component 'org.videolan.VLC': The component is invalid.
> ** (appstreamcli:2002138): DEBUG: 02:51:00.755: WARNING: Ignored
> component 'com.calibre_ebook.calibre': The component is invalid.
> ** (appstreamcli:2002138): DEBUG: 02:51:00.782: WARNING: Ignored
> component 'org.gnome.Podcasts': The component is invalid.
> ** (appstreamcli:2002138): DEBUG: 02:51:00.918: WARNING: Ignored
> component 'org.kde.kdenlive': The component is invalid.
> ** (appstreamcli:2002138): DEBUG: 02:51:00.951: WARNING: Ignored
> component 'inkscape.desktop': The component is invalid.
>
> There are many such components which it says are invalid. Why they are
> invalid, it doesn't say. I have just shared a few, there are many like
> that.
>
> Looking forward to guidance.

Invalid components are AppStream components which do not even have the
bare minimum of required metadata. So they either lack an id, valid
type, name or summary.
This is usually a bug only the distributor or the author of a package
repository can fix, but in this case it's actually a GNOME bug, more
specifically a gnome-software bug.
If you look at `/usr/share/app-info/xmls/org.gnome.Software.Featured.xml`
you can see that GNOME Software wants to extend possibly existing
metadata with new information that it needs to show featured apps.
Only that it doesn't tell AppStream that these components are not
supposed to be new components, but rather metadata extensions to
existing components. So AppStream things someone injected invalid
metadata and complains.
The solution is to mark these metadata extensions properly as "merge
components" by adding the `merge="append"` property, like this:
https://gitlab.gnome.org/GNOME/gnome-software/-/commit/bb7f58f5f88381857cd9b5dbe608e75d459873f1
This change was reverted twice by accident now at GNOME, so that's why
we have this issue. It's fixed in Debian's gnome-software package
though.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#932747: apt-get: AppStream system cache updated, failing on APT::Update::Post-Invoke-Success

[Matthias Klumpp]

On Mon, 22 Jul 2019 19:39:10 +0200 Jo Drexl  wrote:

[...]
I've seen this error being persistent on some machines, while others
were thrown off repeatedly. A popular suggestion on the internet is to
comment out the test statement and proceed without a refreshed appstream
cache, which seems to work, so I suggest this being rolled out at least
to Debian Stretch.


This is a pretty terrible suggestion, because doing so will break every 
software center application on the system, possibly in subtle ways.
A much better solution is to actually find the culprit and fix it - 
usually the issue is a PPA or 3rd-party repository injecting invalid 
metadata, or some other application on the system installing invalid data.
Try `sudo appstreamcli refresh --force --verbose` to get information on 
what's going on (or attach the log to a bug report in case you are 
experiencing this issue again).


In the case of newer Debian releases, the issue is actually a regression 
in GNOME Software, which is fixed now, once again.


Cheers,
Matthias

Bug#947847: please install systemd-sysusers using update-alternatives

[Matthias Klumpp]

Am Mi., 29. Jan. 2020 um 20:39 Uhr schrieb Simon McVittie :
> [...]
> I think there are three categories of systems that it might make sense
> to consider separately here. In ascending order of "amount of systemd":
>
> - non-Linux ports to which systemd does not intend to be portable (and
>   I think we can treat non-systemd-by-policy derivatives like Devuan as
>   basically equivalent to these), where the systemd implementation of
>   -sysusers simply does not exist
>
> - Linux systems not booted with systemd
>   (either no init system at all, like a typical schroot or Docker
>   container, or a non-systemd init system like sysvinit)
> [...]

For this particular case it's probably worthwhile to also consider
Zbigniew Jędrzejewski-Szmek's comment on debian-devel a while back,
where they extended systemd's interface stability and compatibility
promise based on our discussions back then.
Namely:

> Independent operation of a bunch of
> programs is now explicitly covered, and the stability promise
> has been extended to more interfaces.

>From 
>https://systemd.io/PORTABILITY_AND_STABILITY/#independent-operation-of-systemd-programs
systemd-sysusers and tmpfiles are covered by this promise, as well as
a few other utilities.
So, especially for container usecases it may actually be reasonable
for the systemd maintainers to make those utilities available in a
separate package to be installed without the daemon components. That
way they would be readily available and working even on systems where
systemd isn't PID1 (of course, the daemons should also be inert until
an alternative init system starts to parse systemd service files, so
at the moment even installing the systemd package itself for these
binaries is safe).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#936551: C++ help for freebayes needed

[Matthias Klumpp]

Am Di., 17. Dez. 2019 um 15:08 Uhr schrieb Andreas Tille :
>
> Hi,
>
> I intended to upgrade freebayes to its latest upstream version.  Unfortunately
> it does not build against the Debian packaged libs.  I've reported this 
> upstream
> as issue
>
> https://github.com/ekg/freebayes/issues/579
>
> May be it makes sense to discuss the issue there since upstream might want to
> take over latest versions of the used libraries sooner or later as well.
>
> Kind regards and thanks for any hint to solve the build issue

I just took a really, really quick look at it (< 5min). Looks like
there are multiple issues to be solved, for example the IntervalTree
template accepts two class types (Value and Scalar) and only one is
provided. That's an upstream bug that upsteam needs to solve, so there
isn't much you can do. I am very certain this build fails in any
circumstance, unless IntervalTree is downgraded, maybe.
Additionally, in
https://sources.debian.org/src/htslib/1.10-2/cram/cram_io.h/#L511
(included by this software) implicitly casting void* to something else
is illegal in C++. So either `unsigned char *tmp = realloc(b->data,
len);` has to be changed to `unsigned char *tmp = (unsigned char *)
realloc(b->data, len);` to be valid in both C and C++ (a clean
solution, but possibly impractical), or, the better way in this case,
the C library headers need to be wrapped in a block like this:
```

#ifdef __cplusplus
extern "C" {
#endif

/* include all C headers here */

#ifdef __cplusplus
}
#endif
```

Usually, many C headers already have this, but apparently this one
hasn't. That may fix this and any other issues as well (I haven't
tested that though). If it doesn't, the compiler has to be told that
this instruction is okay to use in the particular header, or the C
code has to be fixed to accomodate for that.

I hope this helps.
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#907489: Fixing sambamba 0.8.6

[Matthias Klumpp]

Am So., 15. Dez. 2019 um 10:16 Uhr schrieb Pjotr Prins :
> [...]
> > Therefore, the way of least resistance was to just use Meson for
> > building, as that does everything we need in Debian. Both BioD and
> > Sambamba build well with Meson.
>
> That is great. We can add the meson builds in the repos.

That's something I forgot in my last mail: I didn't create PRs,
because Meson support was upstream once but was removed. Also because
it's understandable if upstream projects want to reduce the amount of
ways a software can be built.
As it happens though, I have already created (by accident) build
definitions that work for the current upstream code of BioD/Sambamba.
I've created PRs for those now. Having this upstream would obviously
be great, and if there are issues with it, I can help. (The
definitions are really straightforward to use though)

See https://github.com/biod/BioD/pull/54 and
https://github.com/biod/sambamba/pull/419

Integration with CI is possible, but your Travis YAML will become a
bit bigger ^^

> > I applied a few tweaks to the packages, that haven't been there
> > before: BioD is now built as a shared as well as a static library, so
> > applications can choose between the two. That's pretty common in
> > Debian, and as a sideeffect this also guarantees that things are
> > rebuilt properly when a transition happens. The Sambamba package will
> > now prefer statically linking BioD if possible (so BioD is statically
> > linked by default now in Debian).
> > Additionally both packages now apply the optimization flags upstream
> > has set for releases (-O3, no bounds checks, etc.). Combined, these
> > two changes should make the Debian builds comparably fast to the
> > upstream builds, but I haven't tested that yet.
>
> > There are also two brand new remaining issues: Apparently, for some
> > reason, SONAME isn't set correctly for BioD, producing a Lintian error
> > - not sure what happens there, and which component is to blame for
> > that (Meson or LDC, most likely). Also, Sambamba doesn't *actually*
> > build yet:
> > ```
> > roup -L=-rpath 
> > -L=/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu
> > slicereader.d:71: error: undefined reference to 'cram_to_bam'
> > collect2: error: ld returned 1 exit status
> > ```
> > The cram_to_bam is private in htslib, so it shouldn't be used by other
> > applications. Not sure whether htslib or Sambamba needs to be changed
> > here, I simply worked around this issue for testing, and when this is
> > resolved, Sambamba builds & works.
>
> Sambamba ships with an old version of htslib that is patched for that
> function call. I plan to drop CRAM support and htslib. No one I know
> uses the CRAM functionality in sambamba.

It certainly wasn't needed for the tests :-D
I don't think we should silently comment that out from the Debian
builds though...

> > Unfortunately I briefly forgot that this issue existed, so I already
> > uploaded the new sambamba package with this issue still present (I
> > remembered literally the moment the upload finished), so its builds
> > will fail. This is probably something for Andreas to look into :-)
> >
> > Anyway, I hope this is helpful to you and the resulting binaries are
> > performant :-)
>
> Thanks Matthias!

If the last issues can be fixed, this may just be in time for the next
Ubuntu LTS release, which is probably something that you'll want ;-)
Currently, BioD fails to build on x86:
https://buildd.debian.org/status/fetch.php?pkg=libbiod=i386=0.2.3%2Bgit20191120.b8eecef-1=1576379323=0
This issue looks trivial to me, it's probably a matter of using size_t
instead of plain ints.
There's of course also the question of whether we need to support x86
with this package, but in any case, this FTBFS will block the package
in unstable until it has either been removed from i386 or the build
failure has been fixed.
The good news is that the package builds on arm64 now though - yay? ^^

Sambamba is only failing on missing cram_to_bam, so once that's fixed,
it should be good to go as well.

Cheers,
Matthias




-- 
I welcome VSRE emails. See http://vsre.info/

Bug#938431: Fixing sambamba 0.8.6

[Matthias Klumpp]

Am Do., 28. Nov. 2019 um 16:37 Uhr schrieb Pjotr Prins :
>
> When 1.18 arrives I think it is a good time to get sambamba and biod
> in Debian again.

They always were in Debian, just not in a release because the packages
were broken ^^
The LDC transition went really well this time, I don't think it has
ever been this smooth! No regressions this time, hurray!
I had a bit of time to look into the sambamba/biod packages today, and
fixing them was actually really easy. Originally, I wanted to just
make use of the upstream-provided Makefiles, but unfortunately it was
really annoying to make them produce a proper static and dynamic
library, and then I would still have had the problem of installing all
pieces to the right locations and to write a pkg-config file.
Therefore, the way of least resistance was to just use Meson for
building, as that does everything we need in Debian. Both BioD and
Sambamba build well with Meson.

I applied a few tweaks to the packages, that haven't been there
before: BioD is now built as a shared as well as a static library, so
applications can choose between the two. That's pretty common in
Debian, and as a sideeffect this also guarantees that things are
rebuilt properly when a transition happens. The Sambamba package will
now prefer statically linking BioD if possible (so BioD is statically
linked by default now in Debian).
Additionally both packages now apply the optimization flags upstream
has set for releases (-O3, no bounds checks, etc.). Combined, these
two changes should make the Debian builds comparably fast to the
upstream builds, but I haven't tested that yet.

There are also two brand new remaining issues: Apparently, for some
reason, SONAME isn't set correctly for BioD, producing a Lintian error
- not sure what happens there, and which component is to blame for
that (Meson or LDC, most likely). Also, Sambamba doesn't *actually*
build yet:
```
roup -L=-rpath 
-L=/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu
slicereader.d:71: error: undefined reference to 'cram_to_bam'
collect2: error: ld returned 1 exit status
```
The cram_to_bam is private in htslib, so it shouldn't be used by other
applications. Not sure whether htslib or Sambamba needs to be changed
here, I simply worked around this issue for testing, and when this is
resolved, Sambamba builds & works.
Unfortunately I briefly forgot that this issue existed, so I already
uploaded the new sambamba package with this issue still present (I
remembered literally the moment the upload finished), so its builds
will fail. This is probably something for Andreas to look into :-)

Anyway, I hope this is helpful to you and the resulting binaries are
performant :-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#946188: RM: tilix [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Matthias Klumpp]

Package: ftp.debian.org
Severity: normal

Hi!
Please remove the tilix package binaries for the armhf architecture
temporarily.
The armhf arch is affected by GDC bug #944380 for a while now, and the
package does not migrate to testing while it's not built on armhf.
Meanwhile, all packages depending on it are broken on all
architectures until the new version migrates (due to LDC ABI issues),
so in this particular instance I think it is justified that the
package is removed on armhf temporarily, to allow it to migrate.
The armhf binaries will highly likely be reintroduces as soon as the
issue is fixed in GDC or worked around there, and glib-d built on armhf
with gdc.
RM issues were filed against appstream-generator, glib-d and gtk-d as
well in the past, but tilix was missed out somehow until now.
With GDC 10, these issues will hopefully be fixed and we can have
armhf back, but until then having a working Tilix in testing on the
other architectures would be nice.

Thanks for considering!
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#907489: Fixing sambamba 0.8.6

[Matthias Klumpp]

Am Do., 28. Nov. 2019 um 15:19 Uhr schrieb Andreas Tille :
>
> Hi Pjotr,
>
> On Thu, Nov 28, 2019 at 07:50:34AM -0600, Pjotr Prins wrote:
> > Dear Andreas and Matthias,
> >
> > Good news, I think I have fixed the Sambamba bug! After a 3 day bug
> > hunt. Thanks Andreas for pushing me again. Let me ping you when I have
> > a new release. I need to do some performance testing still. But no
> > more segfaults using the Debian ldc 1.17 compiler.
>
> Very cool!  Just waiting for your ping. :-)
>
> > With regard to BioD I suggest the following:
> >
> > 1. We create libraries libbiod.so and libbiod.a which ship with D
> >source code - they act like header files in C.
> > 2. sambamba uses these header files to build (not linking against the
> >shared lib)
> >
> > The reason is simply performance. The ldc compiler is capable of heavy
> > optimizations (mostly unrolling loops and inlining code) when it has
> > all code available. Point I am making that code is available anyway.
> >
> > You can choose to change that compile time behaviour by linking
> > against a shared lib, but just realise you'll end with a much slower
> > sambamba. The BioD source code shoud be included because you can't
> > build anything without it.
>
> As we discussed at BioHackathon: I just got your point but I have no
> idea how to implement that source code shipping model for the
> libbiod-dev package.  I'm fine with whatever is done with D packaging
> in Debian.
>
> To get some numbers:  Do you think rinning test/test_suite.sh could
> give some impression about the performance gain / loss?

So, we absolutely have to build this separately, ideally using Meson,
in Debian - otherwise transitions to newer or different D compilers
will become an even bigger mess than they already are. Also, embedded
code copies are explicitly forbidden by the Debian Policy.
So, libbiod needs a Meson build file or Makefile or anything that
generates a library installed to a system path that sambamba can find
later.
BUT it doesn't mean that the library has to be a shared library. If
you find that linking libbiod statically into sambamba increases
performance significantly, we can make the libbiod package generate
both a shared and static library and then make sambamba prefer the
static library. This should make transition handling possible as it
used to (our tracker is smart enough to detect this), satisfy Debian
policy and reduce the speed impact on sambamba.

I have been on vacation for a while and then needed to go through a
lot of stuff @work, so sorry for replying late and also I hope I
understand the problem correctly.
FWIW, very, very soon (maybe this week) LDC 1.18 will land in Debian,
so these packages will go through yet another transition. If you can
make sure they build & work with LDC 1.18, it would be very great.

Cheers,
Matthias




-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944640: gtk-d: FTBFS on armel/armhf with many "multiple definition" messages

[Matthias Klumpp]

Am Mi., 13. Nov. 2019 um 08:45 Uhr schrieb Raphaël Hertzog
:
>
> Source: gtk-d
> Version: 3.9.0-2
> Severity: important
> Tags: ftbfs
>
> Hi,
>
> can you make a new source upload to let the package migrate to testing
> please ?
>
> I also noticed that the package still fails to build on armel/armhf with
> hundreds of message like these:
>
> /usr/bin/ld: ./libgtkd-3.a(ColorSelection.o): in function 
> `_D3std4conv110__T8textImplTAyaTAyaTPvTAyaTiTAyaTiTAyaTaTAyaThTAyaThTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTAxaTAyaTAxaTAyaZ8textImplFNaNfAyaPvAyaiAyaiAyaaAyahAyahAyabAyabAyabAyabAyabAyabAyaAxaAyaAxaAyaZAya':
> ./generated/gtkd/gtk/ColorSelection.d:401: multiple definition of 
> `_DT24_D3gtk6Widget6Widget10__mixin37720setBuildablePropertyMFC3gtk7Builder7BuilderAyaC7gobject5Value5ValueZv';
>  ./libgtkd-3.a(Button.o):./generated/gtkd/gtk/Button.d:565: first defined here
> /usr/bin/ld: ./libgtkd-3.a(ColorSelection.o): in function 
> `_D3std4conv110__T8textImplTAyaTAyaTPvTAyaTiTAyaTiTAyaTaTAyaThTAyaThTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTAxaTAyaTAxaTAyaZ8textImplFNaNfAyaPvAyaiAyaiAyaaAyahAyahAyabAyabAyabAyabAyabAyabAyaAxaAyaAxaAyaZAya':
> ./generated/gtkd/gtk/ColorSelection.d:401: multiple definition of 
> `_DT24_D3gtk6Widget6Widget10__mixin37716buildableSetNameMFAyaZv'; 
> ./libgtkd-3.a(Button.o):./generated/gtkd/gtk/Button.d:565: first defined here
> collect2: error: ld returned 1 exit status
> make[2]: *** [GNUmakefile:252: TestWindow] Error 1
> make[2]: Leaving directory '/<>'
> dh_auto_build: make -j8 "INSTALL=install --strip-program=true" test shared 
> prefix=/usr returned exit code 2
> make[1]: *** [debian/rules:19: override_dh_auto_build] Error 255

The cause of this is a GDC bug, the bugtracker should actually have
marked this package to be affected, but somehow that isn't the case...
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944380 for
details.
I will leave this issue open until the compiler issue is resolved.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944380: GDC generates duplicate symbols when using mixins/interfaces

[Matthias Klumpp]

Am Sa., 9. Nov. 2019 um 16:04 Uhr schrieb Matthias Klose :
>
> Control: found -1 9.2.1-16
> Control: severity -1 important
>
> according to the upstream report, also with 9.2.0.
>
> On 08.11.19 23:18, Matthias Klumpp wrote:
> > Package: gdc-9
> > Version: 9.2.1-17
> > Severity: serious
> >
> > Hi!
> > Currently, GDC can't build package like gtk-d because it generates
> > duplicate non-weak symbols in object files, causing a collision when
> > linking. This seems to happen when using mixins / interfaces.
> > For more information and a workaround, please check the upstream bug report.
>
> if there's a workaround, please don't set the severity to serious.

The workaround needs to be applied to GDC, there is nothing we can do
in the affected packages. I also haven't tested the workaround and it
doesn't look like a good solution to me.
So, since this is breaking other packages, a high severity seemed justified.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944383: RM: gtk-d [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Matthias Klumpp]

Am Sa., 9. Nov. 2019 um 03:54 Uhr schrieb Scott Kitterman
:
> On November 9, 2019 1:58:50 AM UTC, Matthias Klumpp  wrote:
> >Am Fr., 8. Nov. 2019 um 23:29 Uhr schrieb Matthias Klumpp
> >:
> >> [...]
> >> Please remove the gtk-d package binaries for the armhf architecture
> >temporarily.
> >> [...]
> >
> >Speaking of which, could the armhf packages of appstream-generator and
> >glib-d also be removed? The former suffers from a different issue (but
> >one that will only be fixed in a more recent GDC version (10), as the
> >package depends on a higher D language version), and the latter has
> >the exact same issue as described here (and appstream-generator
> >depends on glib-d, so removing the armhf binaries together makes
> >sense)
>
> Please file separate bugs for those.

I kind of expected that reply ^^
Separate issues for those two packages are filed as well now.
Thanks!
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944395: RM: glib-d [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Matthias Klumpp]

Package: ftp.debian.org
Severity: normal

Hi!
Please remove the glib-d package binaries for the armhf architecture
temporarily.
The armhf arch is affected by GDC bug #944380 for a while now, and the
package does not migrate to testing while it's not built on armhf.
Meanwhile, all packages depending on it are broken on all
architectures until the new version migrates (due to LDC ABI issues),
so in this particular instance I think it is justified that the
package is removed on armhf temporarily, to allow it to migrate.
The armhf binaries will highly likely be reintroduces as soon as the
issue is fixed in GDC or worked around there, and glib-d built on armhf
with gdc.
RM issues were filed against appstream-generator and glib-d as well.

Thanks for considering!
Cheers,
Matthias

Bug#944394: RM: appstream-generator [armhf] -- ROM; FTBFS because it needs newer D features

[Matthias Klumpp]

Package: ftp.debian.org
Severity: normal

Hi!
Please remove the appstream-generator package binaries for the armhf
architecture temporarily.
The armhf arch is affected by GDC bug #944380 for a while now, and
appstream-generator depends on glib-d which is affected by this issue.
Furthermore, asgen depends on D features the gdc compiler does not yet
provide (version 10 is needed for that), so the package can't be
introduced on armhf until GDC 10 is available in the archive.

Thanks for considering!
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944383: RM: gtk-d [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Matthias Klumpp]

Am Fr., 8. Nov. 2019 um 23:29 Uhr schrieb Matthias Klumpp :
> [...]
> Please remove the gtk-d package binaries for the armhf architecture 
> temporarily.
> [...]

Speaking of which, could the armhf packages of appstream-generator and
glib-d also be removed? The former suffers from a different issue (but
one that will only be fixed in a more recent GDC version (10), as the
package depends on a higher D language version), and the latter has
the exact same issue as described here (and appstream-generator
depends on glib-d, so removing the armhf binaries together makes
sense)

Thanks!

Bug#944383: RM: gtk-d [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes

[Matthias Klumpp]

Package: ftp.debian.org
Severity: normal

Hi!
Please remove the gtk-d package binaries for the armhf architecture temporarily.
The armhf arch is affected by GDC bug #944380 for a while now, and the
package does not migrate to testing while it's not built on armhf.
Meanwhile, all packages depending on it are broken on all
architectures until the new version migrates (due to LDC ABI issues),
so in this particular instance I think it is justified that the
package is removed on armhf temporarily, to allow it to migrate.
The armhf binaries will highly likely be reintroduces as soon as the
issue is fixed in GDC or worked around there, and gtk-d built on armhf
with gdc.

Thanks for considering!
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944380: GDC generates duplicate symbols when using mixins/interfaces

[Matthias Klumpp]

Package: gdc-9
Version: 9.2.1-17
Severity: serious

Hi!
Currently, GDC can't build package like gtk-d because it generates
duplicate non-weak symbols in object files, causing a collision when
linking. This seems to happen when using mixins / interfaces.
For more information and a workaround, please check the upstream bug report.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/