=== alan_g_ is now known as alan_g [09:12] teward, sarnold - https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-February/016208.html [09:13] 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] things have binary depends on its own layer, and anything to the left of it. [09:14] 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] ogre onion? :) [09:27] hi everyone [09:28] what’s the procedure to RM obsolete and insecure packages from old releases? [09:29] 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] https://launchpad.net/ubuntu/+source/bitcoin/+changelog [09:29] if they cannot be bumped them to the latest upstream release, it would be better to actually remove them [09:30] https://launchpad.net/ubuntu/+source/owncloud/+changelog [10:05] xnox: It's still slightly onioned even for build-dependencies, just simplified to consider only the freeness axis [10:05] (which I'm sure you know, but it occasionally comes up and is worth being clear) [10:07] Have they considered providing a snap? 😛 [10:08] 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] the point is that those releases captured whatever I uploaded to Debian at that time [10:09] and that’s not necessarily what’s best for the users [10:09] Oh, absolutely. Probably what you want to do is get an empty package SRUed. [10:09] I was just being snarky. [10:09] 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] lol [10:10] an empty package SRUed? how exactly does that work? [10:10] andrewsh[m]: look at the two links sarnold provided for examples [10:10] oh, I hadn’t realised it was related to my questions [10:11] An empty packaged SRUed is the closest to “remove from the archive” we can do. [10:12] right, do I need to prepare the upload myself and then prod someone? [10:12] or do I just need to prod someone to do both? 😀 [10:13] 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 :) === jamesh_ is now known as jamesh [20:51] doko: I'm thinking we cannot upgrade pmdk to 1.5 at this time [20:51] doko: 1.4 -> 1.5 is a big change, never mind the minor version bump [20:51] biggest issue I see is this: [20:51] """ [20:51] Beyond that, it introduces [20:51] new APIs, new tools and many other improvements. As a side effect [20:51] of performance optimizations, the libpmemobj on-media layout had to be [20:51] changed, which means that old pools have to be converted using pmdk-convert. [20:51] """ [20:51] problem is, pmdk-convert is a new source [20:52] it used to be part of the pmdk tools package, in the "pmempool(1)" command [20:52] 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] and debian hasn't packaged that as far as I can see [20:52] so it would be a NEW package in ubuntu [20:53] " - pmempool: "convert" subcommand is now a wrapper around pmdk-convert [20:53] (please see https://github.com/pmem/pmdk-convert) [20:53] "