Dear colleagues, I have taken a look on this ubuntu-import/rebase thing, thanks a lot for your suggestions and advice.
Unfortunately, I can't see any possibility to follow this Ubuntu-import way. Because the last Debian-based version of the LXC package was in 2012 (!) [ https://git.launchpad.net/ubuntu/+source/lxc/commit/?id=b0c54a19dda57a37294b244982bcfd425db8dbd8 ]. As I can see from https://github.com/canonical/ubuntu-maintainers- handbook/blob/main/PackageMerging.md#identify-logical-changes I have to go through *all* the git history from 2012 and split all the changes to a separate commits, then do a lot of other stuff. I can barely imagine doing all of that without making a single mistake in the middle which, effectively, will make all the rest of the a rebase job completely wrong (and I'll have to start everything from the beginning). >In the debian/tests/control file you need to add a comma (',') between the two restriction names. A comment here is that if you merge the changes from Debian we will get 2 more DEP-8 tests (autopkgtest) in the package. Thanks, will do. >Nitpick: you committed the debian/files file which is not necessary. Thanks, I'll remove it. So, my question is, that if it's possible just to take a clean debian/sid branch, then merge *only* debian/changelog somehow and *manually* put all the necessary Ubuntu-specific patches on top without using all of this heavy machinery with rebasing and editing thousands of commits? I understand that we have a very strict processes around importing packages, and I understand why. But it looks like this processes are suitable for regularly sync-able packages. Which is not the case for LXC, because most of LXC developers used to be a Canonical employees and Ubuntu LXC package was an independent from the Debian one (for 12 years!). And another question is that if it would be possible to me to *only* fix the LXC_DEVEL issue without rebasing anything and updating anything to make things just work. Then one day, when we decide how to sort this rebase stuff out with such an deeply out-of-sync package I'll be happy to do a rebase on the debian/sid. I want to avoid Noble to be released with this LXC_DEVEL issue because it bothers developers/users of LXC/LXD. Kind regards, Alex -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu 22.04 and later releases Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
