[05:03] <tsimonq2> doko: Mind if I steal your anthy merge?
[17:17] <andreas> let's say I have an ubuntu native package in the archive: package-2.0
[17:17] <andreas> it has a bug I want to fix, but I can't commit to its upstream
[17:18] <andreas> I'm looking at the version table at https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[17:18] <andreas> looks like my case is:
[17:18] <andreas> 2.0                           2.0ubuntu0.1
[17:19] <andreas> so it remains a native package in the update? How is the fix applied? I just re-tarball it after applying the fix manually? No patch file in d/patche?
[17:22] <jbicha> andreas: it's helpful if you tell us what package you are wanting to update
[17:23] <andreas> jbicha: ubuntu-advantage-tools
[17:23] <andreas> I need to update it to version 10, and backport some fixes from version 13
[17:23] <andreas> v13 is in bionic-proposed for a couple of days, looks like some big migration is going on and blocking everything
[17:24] <andreas> it being a native package is messing with my head
[17:26] <jbicha> well y'all should use a more sane versioning system, snapd's versioning is very non-standard but it manages to work
[17:27] <andreas> hm?
[17:28] <jbicha> are you going to be sruing to artful at the same time?
[17:29] <andreas> jbicha: yes: t, x, z and aa. As soon as b has v13
[17:30] <jbicha> I suggest version numbers like: 10.17.10.1, 10.16.10.1, 10.16.04.1, etc.
[17:31] <jbicha> or 10+17.10.1 if you don't like that many ...'s
[17:31] <jbicha> the trailing .1 allows someone to easily do a bugfix .2 release
[17:31] <andreas> so it remains a native package?
[17:32] <jbicha> yes, the native package is fine in this case
[17:32] <andreas> how do I apply the fix I want? Essentially making a new tarball, as if there had been a new upstream release?
[17:32] <andreas> I can't just use a new version number, there is no corresponding upstream release with that version
[17:33] <jbicha> I think 'debuild -S' should make the tarball for you?
[17:33] <andreas> it asks when it can't find an orig one
[17:33] <andreas> but I have to apply my fixes directly, not via d/patches right
[17:33] <jbicha> there's so many different possible packaging workflows it's hard for me to give you specific advice
[17:33] <jbicha> yes, you won't use debian/patches/ if it's native
[17:34] <andreas> ok
[17:34] <jbicha> doesn't this work?
[17:34] <jbicha> apt source ubuntu-advantage-tools; cd ubuntu-advantage-tools;
[17:35] <jbicha> (make your changes and update debian/changelog)
[17:35] <jbicha> debuild -S
[17:35] <andreas> it's like I'm creating a new upstream version with my fixes, that's what is confusing me
[17:35] <jbicha> that's how native packaging works
[17:35] <andreas> 2.0                           2.0ubuntu0.1 <-- like this example
[17:35] <andreas> from https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[17:36] <andreas> except I would use the release number in the suffix, because I'll do it for several releases
[17:36] <andreas> so I would have a tarball with version "2.0ubuntu0.14.04.1" in the example above
[17:36] <jbicha> the "ubuntu" in the version number is not necessary
[17:37] <jbicha> please don't number the package as "2" if it is really "10"
[17:37] <andreas> I won't, I was just continuing with the example
[17:39] <jbicha> why don't you want to use 13 as your base instead of 10?
[17:39] <andreas> it has other changes and the sru would have to start from scratch
[17:39] <andreas> 10 as is was rejected and particular fixes from 13 were requested, then 10+fixes would be approved
[17:40] <andreas> in particular, v13 runs tests at package build time. That's what was requested for the sru
[17:40] <jbicha> sru already is starting from scratch isn't it?
[17:40] <andreas> no, the sru reviewer said all that was required now was to bring those tests in to v10
[17:40] <andreas> if we bring v13 instead, then there is another change in there that he has to review, that wasn't there before
[17:41] <jbicha> are you sure y'all don't want the 'ua' symlink too?
[17:41] <andreas> we do, and another sru will do that, but right now the pressing feature is fips support
[17:42] <andreas> I also suggested we start over with v13, but it took so long to get an sru team member to look at it that it was feared it would take weeks again
[17:42] <jbicha> but each SRU takes what ~2 weeks? I don't understand why you don't just do both issues at once
[17:42] <jbicha> but I think all these decisions are above my paygrade ;)
[17:43] <andreas> we now have the attention of an sru team member, and he is just waiting for these tests-at-build-time. That was his review point
[17:43] <andreas> but this native package business is ugly
[17:44] <jbicha> the native part itself is fine (with me), the tricky part is that you always need a newer version in newer supported releases
[17:45] <jbicha> so maybe even a 10~17.10.1, 10~17.04.1, etc. would work
[17:46] <jbicha> when sorting Debian version numbers: 10~17.10 < 10 < 10+17.10
[17:46] <andreas> that was my first attempt, when artful/bionic had 10, but now that 13 is in proposed I thought I could stick with 10ubuntu
[17:46] <andreas> I thought I had to signal somehow that it had ubuntu changes
[17:46] <andreas> hence the "ubuntu" word in it
[17:46] <andreas> again, following the security team wiki page
[17:46] <jbicha> that's how the snapd version manages to work although it's odd to have xenial as the focus instead of the dev branch of Ubuntu
[17:47] <jbicha> you don't need to signal that, it's an Ubuntu native package that didn't come from Debian