Hi @mak,
It looks like we are missing the pristine-tar / upstream branches for this repo and/or the tarballs. Any chance you have these locally? (Happy to import tarballs and fix this up so it's easier for anyone to jump on in future.)
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | None | T444 Update flashrom and coreboot-utils packages | ||
| Resolved | chris.lamb | T452 Please update coreboot package | ||
| Resolved | mak | T467 https://source.puri.sm/pureos/packages/coreboot missing pristine-tar/upstream branches? |
Event Timeline
Comment Actions
@chris.lamb I don't really recall why I did that back then, but this is debian/ directory only style packaging with Git. This is completely valid packaging, and gbp will happily use it. It's used inside Debian by a bunch of projects, most notably the KDE/Qt packaging team.
To use the package, just get the latest or latest-packaged upstream version with uscan, and then run gbp buildpackage as usual. Advantages of this packaging style are much smaller disk space requirements, ease of use and setup, reduction to the essentials, easy upgrade-ability by automation and no need for a pristine-tar branch (the tarball is always pristine).
Drawbacks are that the upstream sources need to be fetched as an additional step (branch isn't instantly ready), and that applying patches is much less convenient compared to e.g. using the upstream Git branch and patch-queue.
EDIT, FTR: This is how this looks like in Debian itself: https://salsa.debian.org/qt-kde-team/kde/plasma-desktop - it's actually a quite common style.
Personally I don't care much how the repo layout looks like, as long as I can figure out how to use the repo quickly enough (obviously for automation having a more limited set of Git packaging styles would be much nicer, but that ship has sailed).
Comment Actions
This is completely valid packaging, and gbp will happily use it.
It's used inside Debian by a bunch of projects, most notably the
KDE/Qt packaging team.
I think you misunderstood my query - I am very well aware of this
style of packaging and it's usage within Debian. :p
However, it does not fit the rest of the PureOS packages (thus causing
excessive context-switching) and furthermore introduces a "speedbump"
to anyone wanting to quickly contribute. These disadvantages outweigh
all of possible advantages you list IMHO (especially as disk space is
surely not a concern in 2018).
Your remarks around upstream tarballs being ipso facto pristine is
also a little misleading in the general case, due to (at least)
Github's non- deterministic generatation of tarballs...
Anyway, debian/gbp.conf would need an update to /disable/ pristine-
tar :p
having a more limited set of Git packaging styles would be
much nicer, but that ship has sailed).
That is no reason to make it any worse, nor to "tidy up" when one sees
something slightly out place. Be the change you want to see in this
world.
Comment Actions
Your remarks around upstream tarballs being ipso facto pristine is
also a little misleading in the general case, due to (at least)
Github's non- deterministic generatation of tarballs...
Are you sure about that? I tested that about a year ago, and over months Github's tarballs remained the same.
However, it does not fit the rest of the PureOS packages (thus causing
excessive context-switching) and furthermore introduces a "speedbump"
to anyone wanting to quickly contribute. These disadvantages outweigh
all of possible advantages you list IMHO (especially as disk space is
surely not a concern in 2018).
Yeah... The original reason for this package being different was that back then I was working on maintaining every single PureOS package in Git (including those imported from Debian), and in that scenario I would have gone with keeping the debian/ directory (and it's history) only in the auto-generated Git repos and merges. And in that world, the coreboot repo would have fit in quite well.
Anyway, debian/gbp.conf would need an update to /disable/ pristine-tar :p
That's not the case, at least not on my machine - here, gbp only seems to generate/update pristine-tar branches if they were created in the first place, and it for sure never tries to use them if they don't exist. No other package with debian/ only packaging has such a setting.
In any case, I imported to upstream sources of coreboot into the repository now, so it looks like (most) of the other repos in PureOS.