** Changed in: linux (Ubuntu)
Status: Incomplete => Triaged
** Tags added: apport-collected
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1936237
Title:
use the upstream version for the kernel packaging
Status in linux package in Ubuntu:
Triaged
Bug description:
please use the upstream version for the kernel packaging.
<doko> apw, sforshee, xnox: is there any way to see which upstream version
the linux package is based on?
<apw> doko, if you are running it? /proc/version_signature has the full
upstream version
<apw> doko, for general inquiries we also have:
https://people.canonical.com/~kernel/info/kernel-version-map.txt though impish
is missing for some reason
<doko> apw, no, just looking at the package
<apw> doko, with like apt-cache ... likely no
<doko> apw, could you add that information to the changlog, when you're
uploading?
<apw> doko, i guess it would be reasonably easy to do... what is going to
consume it?
<apw> doko, are you interested in when it changes?
<doko> just *knowing* which upstream version is used
<apw> it feels like it should be in the package description for "something"
<doko> or even better, a linux-libc-dev with a real upstream version in the
package version
<apw> we have always avoided having the third digit so we don't explode the
librarian with new orig files all the time
<apw> perhaps we could put somehting on that linux-libc-dev though with the
upstream version in it
<apw> if that would make life easier for you?
<doko> documenting it in the changelog would be ok as well, assuming that you
can parse that kind of information
<apw> are you intending to consume it as a human, or scripted
<doko> yes, or have a different binary version for every binary package built
<doko> human
<apw> i almost want to put a versioned provides on it
<apw> then if something ever did care it could actually do something about it
<doko> and what would be the package that you provide?
<apw> linux-libc-dev-mainline (= foo) perhaps
<cjwatson> apw: TBH I wonder whether the "avoid new orig files" is still the
right tradeoff. The size of a linux orig tarball looks rather less significant
now than it did when we started this practice
<apw> cjwatson, we would provide a new .orig for every single SRU cycle in
the normal run of things, for every single kernel. so 180M for each of 82
kernels.
<apw> which by my calculation is 14TB every 3 weeks?
<cjwatson> Hm yeah, I suppose ...
<cjwatson> I always forget what an absurdly enormous number of kernels you
have
<apw> or are you able to collesce the orig by contents? as there is more
like only 4 for every cycle.
<cjwatson> No
<cjwatson> Well maybe if they're actually bitwise-identical
<apw> they are bitwise identicle
<apw> i assume you _arn't_ currently sharing the bits, but you might be able
to?
<cjwatson> I think we are actually
<cjwatson> But I'll check after this meeting
<apw> ack and thanks
<cjwatson> apw: Oh right, yeah, they get temporarily added as duplicates and
then librarian-gc deduplicates them
<doko> so the space usage wouldn't be an issue in the end?
<cjwatson> So it'd still be a TB a month or so, which isn't entirely
insignificant
<cjwatson> Maybe better not change it until the librarian is on PS5 and we
get a feel for what space usage looks like there
<cjwatson> Actually no, neither apw nor I can multiply apparently
<cjwatson> 180M * 82 is 14G not 14T
<doko> ;p
<cjwatson> That makes rather more sense, I was wondering how you'd manage to
generate like a sixth of the librarian's total storage size in three weeks
<cjwatson> So <1G extra per three weeks is noise and will not really be
noticed from our point of view. I can't speak to whatever extra rebase work it
might require of course.
<cjwatson> And of course it would presumably require some tooling changes. I
do think it would be ultimately the right thing to do though.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1936237/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
