[09:12] <xnox> teward, sarnold - https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-February/016208.html
[09:13] <xnox> teward, sarnold - we still use the Ogre Onion model from Shrek; however we only make sure that binary packages are a closed set which ever expands as main) restricted) universe) multiverse)
[09:13] <xnox> things have binary depends on its own layer, and anything to the left of it.
[09:14] <xnox> and yes we do split publishing a lot, i.e. src:main can produce bin:main bin:restricted bin:universe bin:multiverse from a single build. In practice, producing both bin:main and bin:universe is the most common results of split publishing. Ie. see boost
[09:16] <sarnold> ogre onion? :)
[09:27] <andrewsh[m]> hi everyone
[09:28] <andrewsh[m]> what’s the procedure to RM obsolete and insecure packages from old releases?
[09:29] <andrewsh[m]> matrix-synapse’s upstream says they’re unhappy with bionic and cosmic shipping old releases without security fixes, so I’m contemplating what can be done about them
[09:29] <sarnold> https://launchpad.net/ubuntu/+source/bitcoin/+changelog
[09:29] <andrewsh[m]> if they cannot be bumped them to the latest upstream release, it would be better to actually remove them
[09:30] <sarnold> https://launchpad.net/ubuntu/+source/owncloud/+changelog
[10:05] <cjwatson> xnox: It's still slightly onioned even for build-dependencies, just simplified to consider only the freeness axis
[10:05] <cjwatson> (which I'm sure you know, but it occasionally comes up and is worth being clear)
[10:07] <RAOF> <andrewsh[m] "matrix-synapse’s upstream says t"> Have they considered providing a snap? 😛
[10:08] <andrewsh[m]> they provide debs, and I tried to convince them to provide a flatpak, but that’s not the point I was trying to make
[10:08]  * RAOF would consume such a thing.
[10:08] <andrewsh[m]> the point is that those releases captured whatever I uploaded to Debian at that time
[10:09] <andrewsh[m]> and that’s not necessarily what’s best for the users
[10:09] <RAOF> Oh, absolutely. Probably what you want to do is get an empty package SRUed.
[10:09] <RAOF> I was just being snarky.
[10:09] <sarnold> well, bitcoin crashed 90% and no one even remembers owncloud any more -- I'm not saying they are correlated to being yanked from our archive .. but .. :)
[10:09] <mdeslaur> lol
[10:10] <andrewsh[m]> an empty package SRUed? how exactly does that work?
[10:10] <mdeslaur> andrewsh[m]: look at the two links sarnold provided for examples
[10:10] <andrewsh[m]> oh, I hadn’t realised it was related to my questions
[10:11] <RAOF> An empty packaged SRUed is the closest to “remove from the archive” we can do.
[10:12] <andrewsh[m]> right, do I need to prepare the upload myself and then prod someone?
[10:12] <andrewsh[m]> or do I just need to prod someone to do both? 😀
[10:13] <sarnold> definitely it'll go way faster if you prepare the upload; I can't promies it'll happen, but it'll definitely go smoother if you do a ton of the work :)
[20:51] <ahasenack> doko: I'm thinking we cannot upgrade pmdk to 1.5 at this time
[20:51] <ahasenack> doko: 1.4 -> 1.5 is a big change, never mind the minor version bump
[20:51] <ahasenack> biggest issue I see is this:
[20:51] <ahasenack> """
[20:51] <ahasenack> Beyond that, it introduces
[20:51] <ahasenack>     new APIs, new tools and many other improvements. As a side effect
[20:51] <ahasenack>     of performance optimizations, the libpmemobj on-media layout had to be
[20:51] <ahasenack>     changed, which means that old pools have to be converted using pmdk-convert.
[20:51] <ahasenack> """
[20:51] <ahasenack> problem is, pmdk-convert is a new source
[20:52] <ahasenack> it used to be part of the pmdk tools package, in the "pmempool(1)" command
[20:52] <ahasenack> but in 1.5 the removed it from the pmdk source and made a new project in github: https://github.com/pmem/pmdk-convert
[20:52] <ahasenack> and debian hasn't packaged that as far as I can see
[20:52] <ahasenack> so it would be a NEW package in ubuntu
[20:53] <ahasenack> "    - pmempool: "convert" subcommand is now a wrapper around pmdk-convert
[20:53] <ahasenack>       (please see https://github.com/pmem/pmdk-convert)
[20:53] <ahasenack> "