[12:35] <nzt48> Hi channel, I'm wondering if my messages can be seen on this channel, can somebody confirm for me?
[13:22] <nzt48> debian/scripts/misc command doesn't appear to be working for the bionic kernel at Ubuntu-hwe-5.4-5.4.0-67.75_18.04.1 (c39022329294). I've posted the detailed info here: https://gist.github.com/YorkZ/f18a1edf23237d6de75ff9a56a00b262. Please help, thanks in advance.
[13:29] <nzt48> Hi there, I posted here yesterday and also a few minutes ago, but I haven't got any response yet. Since I'm a new user to IRC, I'm wondering if the problem is at my IRC clinet. So could anyone do me a favor to respond me a word if you see my messages?
[13:39] <klebers> hi nzt48, we can see your message :)
[13:40] <nzt48> Thank you very much klebers for confimming, I was really confused.
[13:41] <klebers> nzt48, can you explain what are you trying to do? Usually we don't need to call that script manually
[13:51] <nzt48> According to the bash trace the problem is that the file linux-buildinfo-5.4.0-67-generic_5.4.0-67.75_armhf.deb is not on any of the 5 urls (defined in repo_list in "getabis").
[13:55] <nzt48> We channged something on the Ubuntu kernel, and would like to start a new release. The changes are mostly configuration changes which have no value for anyone else except our team. So what we wanted to do is to be able to change the version number by adding a debian revison suffix for our product.
[13:59] <nzt48> klebers, I was following this article https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Starting_a_new_release. So is this article up-to-date?
[14:00] <nzt48> Is this article still relevant?
[15:30] <klebers> nzt48, that wiki page is outdated and was more relevant for building official ubuntu kernel releases
[15:30] <klebers> nzt48, I recommend looking at this page instead: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[15:32] <klebers> nzt48, basically you don't need to run the "getabis" script to create a new version. The best option would be to edit the changelog file (likely debian.master/changelog) and append some suffix to the topmost version (e.g. "+mykernel)
[15:33] <nzt48> I'm read the BuildYourOwnKernel page, but it doesn't have instructions on how to start a new release.
[15:33] <klebers> nzt48, the reason for this is that it would be clear that you are taking an official ubuntu kernel and adding something to it. Using the other procedure similar to the offical one you would produce an entirely new version, which will likely clash with the next official one.
[15:34] <klebers> nzt48, you don't need to start a new release, you can amend the current version
[15:38] <nzt48> klebers, I used to use the approach you suggested, i.e., simply add our version suffix, e.g. "+pod01". The problem is that at the time we need another version, e.g., +pod02, we would still have to change "+pod01" into "+pod02". The problem is that we can only have one revison history but can't have the revison history for both pod01 and pod02.
[15:49] <klebers> nzt48, understand. Indeed you can't have these two versions installed on the same system as they will have the same ABI number
[15:49] <klebers> let me think what would be the best way to do this
[15:51] <nzt48> Thanks klebers. I think by following the offical Ubuntu kernel development cycle, I'm also able to take advantage of ABI checking during the build, right?
[15:52] <klebers> nzt48, the ABI checking nowadays is not very used, as we always bump the ABI for every new release
[15:52] <nzt48> I mean build time ABI and module check.
[15:53] <klebers> nzt48, the module check is also more useful for the official release, its purpose is to make sure we don't disable any module by accident. But if you are building your custom kernel this is less relevant.
[15:53] <klebers> nzt48, actually, do you need to have these two versions installed on the same system or are you just saying that you can't have both version on the changelog?
[15:57] <nzt48> No, we don't need to have both versions installed on the same system, but different versions may be installed on different products. The major issue is that we couldn't have both versions (and actually more than two coporate specific versions) in the changelog.