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.
** Changed in: linux (Ubuntu)
Status: New => Incomplete
--
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:
Incomplete
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
