User Details
- User Since
- Jan 20 2021, 20:11 (74 w, 1 d)
Tue, May 31
would be very neat if apt-file would be usable:
I often only know the name of the binary I want to execute, but not necessarily the binary package that contains it
Oct 7 2021
With https://source.puri.sm/Librem5/debs/pkg-phosh/-/merge_requests/21 merged this can be closed (unless it's preferred to wait for a new release incorporating those changes reaches the archive)
Oct 3 2021
Since I just saw this issue on the byzantium board I've opened https://source.puri.sm/Librem5/debs/pkg-phosh/-/merge_requests/21
/cc @guido
Sep 8 2021
This is probably a duplicate of https://tracker.pureos.net/T873 (see last comment by Guido).
May 6 2021
If you are interested, then I do have suggestions on how to try keep both qualities small - i.e. semi-automated routines - but they evolve around a core principle of treating the parent source (Debian) as the primary and PureOS getting applied on top.
May 5 2021
When you do a git merge then changelog files are meshed, and when you follow "strategy b)" you don't. That seems rather consequential to me, not orthogonal.
May 3 2021
@evangelos.tzaras: Is the issue you reported here broadly about any and all best any practice(s) in PureOS missing or undocumented?
Apr 30 2021
I would love to have https://tracker.debian.org/ also link to PureOS patches - and I see how that is doable by parsing Debian Policy standards-compliant source packages and look for DEP-5 standards-compliant patches. Which standards should I follow to implement such feature for git branches/commits?
Apr 29 2021
I could've maybe worded it more clearly in the OP: I was mostly concerned with how to update packages - especially when we're a downstream of Debian.
The question arose because of T1048 and the discussion that ensued around how d/changelog should look like.
I was mostly confused whether this would imply that we would have both pureos/latest and pureos/byzantium.
Apr 28 2021
For the record, this very issue report was not meant as "this package is totally WRONG" - which is the reason I marked it as severity normal.
I propose to reframe this issue to say "best practice(s) is missing/undocumented".
I opened https://tracker.pureos.net/T1049 for the meta discussion and will leave this open until the meta-issue has been clarified (as you suggested)
Rebasing? In the git sense of the word? Wouldn't that imply having to always force push to our packaging repositories (which would destroy/rewrite the git history)?
So would that be pureos/latest (instead of pureos/byzantium) and pureos/amber or pureos/amber-phone then?
Confusing!
Apr 25 2021
Feel free to delete my draft which arouse out of confusion around the Uploaders: field ;)
Mar 3 2021
Feb 15 2021
i was just wondering under which circumstances i would use dput?
my understanding was that when pushing a signed tag in the packaging repos (those which are pointed to from deb-build-jobs (?)) that the build server would automagically start the build.