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.
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:
apport-collect 1936237
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.