1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1099068: RFH: ostree -- content-addressed filesystem for operating

    From =?UTF-8?Q?Dylan_A=C3=AFssi?=@21:1/5 to smcv@debian.org on Thu Mar 6 11:00:01 2025
    Hi Simon,

    On Thu, 27 Feb 2025 20:38:13 +0000 Simon McVittie <smcv@debian.org> wrote:
    I request assistance with maintaining the ostree package.
    (Other Uploaders cc'd.)

    I'm willing to help maintaining this package.

    src:ostree currently has one RC bug, #1098951, a test failure involving
    its interaction with GPG signature verification: updates to GPG
    have caused it to report a missing key (GPGME_SIGSUM_KEY_MISSING, OSTREE_GPG_ERROR_MISSING_KEY, "Can't check signature: public key not
    found") instead of an expected failure mode like "key expired". I have
    been unable to identify whether this is a GPG bug or an ostree bug, and
    would particularly welcome help with this.

    Things seem to be progressing on the upstream side of gnupg. I'm going
    to closely follow the status of this regression to ensure fixes land as
    soon as possible in Debian.

    I first uploaded this package in 2016 as a dependency of Flatpak. It
    is team-maintained by the Utopia team (approximately a "freedesktop.org stuff" team) and has other Uploaders, but in practice I have effectively
    been maintaining it alone, which was not really my intention.

    I'm already a member of the Utopia team for pipewire/wireplumber.

    Some Debian-derived operating systems like Endless OS (and
    non-Debian-derived OSs like Fedora Silverblue) make use of ostree for
    their OS binaries, but I don't use it in that mode myself and have no particular expertise in how that works, so it would be helpful if someone
    who *is* using it in that mode could assist.

    As you know, we use ostree for Apertis image, this seems to be the
    expertise you're looking for.

    Best regards,
    Dylan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to All on Thu Mar 20 18:40:01 2025
    On Thu, 06 Mar 2025 at 10:50:24 +0100, Dylan Aïssi wrote:
    On Thu, 27 Feb 2025 20:38:13 +0000 Simon McVittie <smcv@debian.org> wrote:
    I request assistance with maintaining the ostree package.
    (Other Uploaders cc'd.)

    I'm willing to help maintaining this package.

    Thanks! Please add yourself to its Uploaders on Salsa (no need to do an
    upload just for that) and subscribe to its bugs (tracker.debian.org is
    usually the easiest way).

    src:ostree currently has one RC bug, #1098951, a test failure involving
    its interaction with GPG signature verification

    Things seem to be progressing on the upstream side of gnupg. I'm going
    to closely follow the status of this regression to ensure fixes land
    as soon as possible in Debian.

    Yes, it was eventually resolved from the gnupg side; and we are up to
    date vs upstream at the moment, so there isn't actually anything needing
    action right now.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Dylan_A=C3=AFssi?=@21:1/5 to All on Fri Mar 28 14:30:01 2025
    Hi,

    Le jeu. 20 mars 2025 à 18:37, Simon McVittie <smcv@debian.org> a écrit :

    Yes, it was eventually resolved from the gnupg side; and we are up to
    date vs upstream at the moment, so there isn't actually anything needing action right now.

    Since v2025.2 is out, I tried to update our package but I failed to
    understand what was your usual workflow. I locally merged the upstream
    tag "v2025.2" into the branch "upstream/latest" and then merged this
    branch into "debian/latest", but I get conflicts because some files have
    been removed from this branch (mainly all files related to rust). I
    didn't go any further so as not to break anything. Could you clarify how
    you update the branch "debian/latest"? This way I can use the same workflow.

    Thank you

    Best,
    Dylan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to All on Fri Mar 28 15:30:02 2025
    On Fri, 28 Mar 2025 at 14:18:04 +0100, Dylan Aïssi wrote:
    Since v2025.2 is out, I tried to update our package but I failed to >understand what was your usual workflow. I locally merged the upstream
    tag "v2025.2" into the branch "upstream/latest" and then merged this
    branch into "debian/latest", but I get conflicts because some files
    have been removed from this branch (mainly all files related to rust).
    I didn't go any further so as not to break anything. Could you clarify
    how you update the branch "debian/latest"? This way I can use the same >workflow.

    Thanks for looking into doing this update!

    I'm using the official upstream source release tarballs (with the Autotools-generated files, and with subprojects expanded, but without
    the Rust) as the canonical .orig.tar.whatever source code, as
    recommended by Policy and devref. I have not reviewed the Rust code or
    listed its full copyright information in debian/copyright (and I don't
    know how to maintain Rust code myself).

    However, I'm using `gbp import-orig --upstream-vcs-tag=...` to get the
    upstream git tags merged into the upstream/latest branch, for easy
    reference to upstream git commits. This is similar to how the GNOME team operates (and I thought pipewire was the same, but perhaps that has
    changed since last time I looked).

    My usual workflow to import a new upstream release would be something
    like this:

    ostree$ git checkout debian/latest
    ostree$ gbp dch --full # if d/changelog needs updating before import
    ostree$ uscan --download # optionally --verbose to see what's happening
    ostree$ gbp import-orig /path/to/ostree_2025.2.orig.tar.whatever
    ostree$ git diff origin/debian/latest..
    ostree$ dch -v 2025.2-1 "New upstream release"

    and then update the packaging from there.

    debian/gbp.conf should already set up the --upstream-vcs-tag for you automatically, so you shouldn't need to specify it explicitly; but if
    you would prefer to specify it explicitly, it would be --upstream-vcs-tag=v2025.2 in this case.

    Similarly I'm using pristine-tar to store the delta between the imported upstream/latest branch and the actual upstream source release tarballs,
    but debian/gbp.conf should already enable that automatically, so you
    shouldn't need to do anything special to enable this.

    The uscan default is to download into the parent directory, but I've
    configured a USCAN_DESTDIR in ~/.devscripts so it downloads into ~/tmp/deb/uscan instead, to avoid clutter in my source code directory.
    This isn't configured in debian/ because it's a personal preference
    thing, you can put the tarballs wherever is most convenient to you.

    I upload using dgit, but it's completely fine if you prefer to generate,
    sign and dput a _source.changes file some other way (I'm used to
    interoperating with non-dgit-using co-maintainers in the GNOME team).
    The important thing for interop is that the repository is in 3.0 (quilt) patches-unapplied format, which appears to be the same as pipewire.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)