Package request for Ubuntu

[PanderMusubi]

Plesae see and upvote the package request for Ubuntu at https://bugs.launchpad.net/ubuntu/+bug/1990764

[maxnet]

Isn't there already a package?

https://packages.ubuntu.com/jammy/rpi-imager

[XECDesign]

Oh, I didn't even notice. That's great! Hopefully there won't be as many issues caused by the snap package or people wanting an appimage version.

Although, it'll mean that it will install over the deb on our download page (since the version has a + suffix). Their version rightfully removes the nag message, but then if they don't keep it up to date users won't know there's a potentially important update.

@waveform80, would it be possible for the ubuntu version to use a ~ suffix instead or would it go against the versioning policy?

[waveform80]

Our version will install over the download page version, but only if it's at an equivalent (or earlier) level; the jammy package is currently 1.7.2+noembed-0ubuntu1 so 1.7.3 should install successfully over the top of it:

$ dpkg --compare-versions 1.7.2+noembed-0ubuntu1 lt 1.7.3 && echo lt || echo ge
lt

Of course, if I then bump the version in the archive to 1.7.3+noembed-0ubuntu1 that would again take precedence, but ... that seems correct to me? Shouldn't the version in the distro's own archive take precedence over the upstream version, if the upstream version is at the same level?

On the snap packaging: I've currently got a build of 1.7.3 in the beta channel of the snap but I've had no time to test it yet, so I've not promoted it to stable. I'll be bumping the deb package to 1.7.3 for the devel release (kinetic), and I'll try and SRU that to jammy but that'll take a little while to go through SRU team.

The snap co-exists happily with the deb, but obviously I don't recommend doing this (because ... why?! :-). I've got both installed, but only because I need to test both -- I think the deb takes precedence on the command line in this case as I see /usr/bin is before /snap/bin in my PATH, but whether that's universal I'm not sure.

[XECDesign]

Our version will install over the download page version, but only if it's at an equivalent (or earlier) level; the jammy package is currently 1.7.2+noembed-0ubuntu1 so 1.7.3 should install successfully over the top of it:

$ dpkg --compare-versions 1.7.2+noembed-0ubuntu1 lt 1.7.3 && echo lt || echo ge
lt

Of course, if I then bump the version in the archive to 1.7.3+noembed-0ubuntu1 that would again take precedence, but ... that seems correct to me? Shouldn't the version in the distro's own archive take precedence over the upstream version, if the upstream version is at the same level?

My concern, which is admittedly very minor, is the following situation:

1. The user installs from our download page.
2. It gets overwritten by the repo version
3. We update our package with an important fix required for an upcoming image
4. The ubuntu package does not get updated in time
5. The user doesn't receive the fix or notification that there's a newer version available

On the snap packaging: I've currently got a build of 1.7.3 in the beta channel of the snap but I've had no time to test it yet, so I've not promoted it to stable. I'll be bumping the deb package to 1.7.3 for the devel release (kinetic), and I'll try and SRU that to jammy but that'll take a little while to go through SRU team.

The snap co-exists happily with the deb, but obviously I don't recommend doing this (because ... why?! :-). I've got both installed, but only because I need to test both -- I think the deb takes precedence on the command line in this case as I see /usr/bin is before /snap/bin in my PATH, but whether that's universal I'm not sure.

The snap is fine for writing images, but it fails to write zip archives. It will say everything is fine, but there won't be any files on the disk. It's less of an issue now that eeprom updates are distributed as an image. Just tested it and I actually don't have as much of a problem with it now.

[maxnet]

The snap is fine for writing images, but it fails to write zip archives.

Didn't it also had problems with applying the advanced settings? Basically, with everything for which accessing the file system on the SD card is necessary...

[XECDesign]

The snap is fine for writing images, but it fails to write zip archives.

Didn't it also had problems with applying the advanced settings? Basically, with everything for which accessing the file system on the SD card is necessary...

I checked that it dropped a firstrun.sh and it seemed to be there. I haven't tried it in environments other than Ubuntu 22.04.1. I'm sure there may very well be issues depending on the environment.

[PanderMusubi]

@maxnet I 've searched but probably made a typo in my search. Great there is one and this accidental issue improves it a bit.

[waveform80]

My concern, which is admittedly very minor, is the following situation:

1. The user installs from our download page.
2. It gets overwritten by the repo version
3. We update our package with an important fix required for an upcoming image
4. The ubuntu package does not get updated in time
5. The user doesn't receive the fix or notification that there's a newer version available

Hmm, I'd argue 4 is "my fault, so my problem" but I understand the concern. I'm not aware of a general prohibition against us using ~ version numbers, but I do know the security team have rules which exclude such versioning (and the SRU team like us to follow those for backports). Still, this isn't technically a backport so ... I can try and see if anyone complains? :)

Didn't it also had problems with applying the advanced settings? Basically, with everything for which accessing the file system on the SD card is necessary...

It used to; when I took over ownership of the snap I made a concerted effort to fix as much of that stuff as I could, so the advanced settings stuff should work now.

There're still a couple of issues in the packaging I'd like to fix, most notably the fact it's bundling almost the entirety of Qt because something is up with the Qt content snap on non-amd64 archs (that I don't pretend to understand yet). The result of that is:

1. The resulting snap is huge (~200MB (!) vs about 1/1000th that for the deb)
2. I'm rebuilding the damned thing almost every week because some library somewhere in Qt gets a security issue and so it's rebuild time

Still, at least it's functional, and gives people a way to access the latest version without me having to jump through all the SRU hoops. Anyway, I'll go finish the repacking of 1.7.3 for kinetic and see what happens when I change the version number :)

[waveform80]

My apologies, unfortunately the version number tweak turned out to cause more problems than it solved as it resulted in the d/changelog "going backwards" from the point of view of moving from 1.7.3 to 1.7.3~noembed-0ubuntu1. I could amalgamate the log entries into one, but that in turn causes potential problems in future if we ever manage to get a sync set up from raspios (the tooling involved in part of that interrogates the changelog to determine parent branch points). I'm afraid for now I'll have to stick to "traditional" versioning. On the plus side, I found a little time to squash another lintian warning by whipping up a manpage; will PR that in a mo

[XECDesign]

Yeah, that makes sense. Thanks for taking a look!

[tdewey-rpi]

Closing as 'Won't Fix'.

While we provide a Debian package as part of our releases, Canonical handle including Imager in their repositories.